Niedawno dołączyłem do projektu rozwojowego i nagle dostałem pracę jako główny programista. Moim głównym obowiązkiem jest rozbicie części programistycznej projektu na zadania, przekazanie tych zadań innym programistom, a następnie upewnienie się, że elementy będą ze sobą współpracować.
Problem jednak polega na tym, że nie mam pojęcia, jak to zrobić. Spędziłem weekend z ołówkiem i papierem, próbując to rozgryźć, ale ciągle wymyślam listę zadań do wykonania sekwencyjnie zamiast równolegle. Pomyślałem, że może podzielę to na funkcje, ale wtedy skończysz z zadaniami, które wymagają edycji tych samych plików, co może wymagać całkowitego przepisania całego zadania ze względu na to, jak wcześnie jesteśmy w fazie rozwoju. Mógłbym poprosić niektórych programistów, aby program był nieco bardziej kompletny i łatwiejszy do tworzenia zadań, ale wtedy kazałbym ludziom siedzieć na rękach, kto wie, ile tygodni.
Rozmawiałem z moim szefem o moich kwalifikacjach, aby to zrobić i nie miałem wyboru w tej sprawie. Nie mam pojęcia, co robię, więc wszelkie wskazówki i wskazówki we właściwym kierunku byłyby bardzo mile widziane.
Odpowiedzi:
Prawidłowa odpowiedź na twoje pytanie wypełnia kilka książek . Wymyślę listę wypunktowanych słów, które przychodzą mi na myśl, Google i książki zrobią za ciebie resztę.
Powyższa lista jest z pewnością niekompletna, a niektóre części mogą być nawet sporne!
Jeśli to wszystko Cię przeraża - nie martw się, bo powinno cię przestraszyć! Realizacja projektów tworzenia oprogramowania w zespołach nie jest łatwym zadaniem i rzadko ludzie są odpowiednio przeszkoleni i wykształceni w tej dziedzinie. Jeśli cię to przeraża, twoja intuicja działa poprawnie, posłuchaj jej. Chcesz być przygotowany Porozmawiaj z szefem, poświęć trochę czasu i trenuj.
Zobacz też
Dalsza lektura (online)
Dalsze czytanie (książki)
źródło
Addison Wesley - The Pragmatic Programmer, From Journeyman To Master by Andrew Hunt, David Thomas & Addison Wesley - 1999
,O'reilly - The Productive Programmer by Neal Ford
,Prentice Hall - Clean Code, a Handbook of Agile Software Craftsmanship ny Robert C. Martin, ...
,O'Reilly - Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, Gary Pollice & David West
, i wiele innych ...Zyskaj zwinność
Sugerowałbym następujące:
Edycja tych samych plików
Najpierw użyj Git (lub podobnego współbieżnego systemu wersjonowania). Tak długo, jak edytujesz różne części tych samych plików, nie będziesz mieć konfliktów. Jeśli wystąpią konflikty, zostaną one wyraźnie oznaczone jako takie.
Próba zarządzania projektem z wieloma programistami bez Git jest jak próba zrobienia puddingu bez puddingowej miski. Jest to możliwe, ale szybko stanie się dość niechlujny.
Jak zauważono w komentarzach, Git nie jest panaceum, ale w połączeniu z automatycznymi testami z pewnością bardzo pomaga.
Wymień wszystkie funkcje
Po drugie, podziel projekt na widoczne dla użytkownika funkcje. Na przykład „gdy użytkownik się zarejestruje, powinien otrzymać wiadomość e-mail” lub „Użytkownik może dodać element”. Zaangażuj tutaj wszystkich interesariuszy. Zaproś wszystkich do pokoju i niech wszyscy wykrzyczą swoje funkcje.
Powinny to być funkcje widoczne dla użytkownika, możesz później porozmawiać o strategii wdrażania.
Zapisz wszystkie sugestie na kartach indeksowych, nawet te głupie. Szybko zracjonalizuj listę, aby usunąć duplikaty, i ułóż wszystkie karty na dużym stole, a nawet na podłodze.
Dodaj wszystkie potrzebne karty. Powiedz, że Twoja aplikacja wyśle powiadomienia SMS. Być może nie wiesz, jak to zrobić, więc masz pytanie. Napisz „Zbadaj portale SMS” na karcie. Podobnie w przypadku innych wielkich niewiadomych. Będziesz musiał rozpakować je później. Te funkcje prawdopodobnie nie dadzą rady do pierwszego sprintu.
Teraz posortuj swoje karty na grupy, przetasuj je, poczuj ich smak. To jest zakres twojego projektu.
Planowanie pokera
Spróbuj planowania pokera. Nadal ze wszystkimi razem, daj wszystkim kartom programistów, które mówią „1 punkt”, „2 punkty” itd., Aż do „4 punktów”. Również karta „więcej”. Punkt jest w przybliżeniu równy godzinie.
Przejrzyj listę funkcji jeden po drugim. Podczas czytania funkcji każdy musi zagrać kartę. Jeśli jedna osoba gra 1, a inna gra 4, oznacza to problem z komunikacją. Jedna osoba rozumie tę funkcję jako coś innego niż druga osoba. Porozmawiaj i ustal, co naprawdę oznaczało, i zanotuj to na karcie.
Jeśli zgadzasz się, że funkcja jest „większa”, jest ona zbyt duża. Musisz rozbić tę funkcję. Zrób to w taki sam sposób jak poprzednio.
Zgodnie z umową napisz cyfry na kartach pisakiem w innym kolorze.
Punkty są lepsze niż godziny
Używanie punktów zamiast godzin odbiera macho „patrz, jak szybko mogę kodować”, w co często programiści się angażują. To subtelna różnica, ale przekonałem się, że działa całkiem dobrze.
Teraz skomponuj sprint
Sprint to szybki wybuch w kierunku bramki. Zdecyduj o długości sprintu, być może 5 lub 10 dni. Pomnóż liczbę dni przez liczbę programistów przez liczbę punktów dziennie.
Początkowo zakładaj 6 punktów dziennie na programistę. Jest to liczba osiągalna. Jeśli masz 5 osób, to 5 * 5 * 6 = 150 punktów. W połączeniu ze wszystkimi programistami i zarządem wybierz funkcje z listy do 150 punktów. To twój sprint.
Nigdy nie daj się skusić, aby wcisnąć więcej, niż zmieści się. Nadmiernie obiecujące boli wszystkich na dłuższą metę, w tym ciebie.
Musisz tutaj wziąć pod uwagę zależności. Na przykład konfiguracja środowiska oczywiście musi zostać uwzględniona w pierwszym sprincie. W rzeczywistości jest to stosunkowo łatwe, gdy wszyscy są obecni. W pokoju jest 6 mózgów, wszyscy mówią „to zależy od tego” itp. Następnie możesz potasować karty, aby pokazać zależności.
Po zakończeniu sprintu nie można do niego nic dodać, jest on zablokowany na 5 dni. Pełzanie funkcji będzie stresować drużynę, morale obrażeń i spowolni wszystkich. Ostatecznie pełzanie opóźni projekt. Jako lider zespołu musisz chronić swój zespół przed pełzaniem funkcji. Jeśli pojawi się nowe żądanie funkcji, należy je dodać do następnego sprintu. JEŚLI następny sprint jest już pełny, należy coś jeszcze wyjąć.
Nigdy nie ulegaj pokusie wyciskania dodatków. Nadmiernie obiecujące daje około jednego dnia zadowolonego klienta, po którym następuje 4 dni stresu w zespole, a ostatecznie, najprawdopodobniej, kilku niezadowolonych klientów, gdy zespół nie może dostarczyć na czas.
Teraz idź do tego.
Rozdaj karty, zapytaj, kto chce co robić. Masz pełną widoczność tego, co się robi, i możesz policzyć zaznaczone punkty do zera. Przygotuj się na starcie każdego dnia, aby wszyscy wiedzieli, kto nad czym pracuje i co zostało zrobione.
5 lub 6 dobrze zmotywowanych programistów pracujących razem jako jednostka nad jasno określonymi celami, które można zrealizować, może osiągnąć całkiem sporą ilość rzeczy podczas 5-dniowego sprintu.
Zachowaj widoczność
Upewnij się, że wszyscy mogą zobaczyć status projektu. Bluetack wszystkie karty do ściany. Po lewej stronie są karty, które nie zostały jeszcze opracowane. Po prawej stronie są gotowe karty.
Gdy programista pracuje nad kartą, zdejmuje ją ze ściany i kładzie na biurku. Utrzymuje to widoczność i powstrzymuje ludzi od nadmiernego stąpania po sobie.
Istnieją technologiczne alternatywy dla kart indeksowych, ale nic nie przebije ogromnego papierowego wyświetlacza statusu projektu na ścianie.
Jeśli to możliwe, przechowuj wszystkich w tym samym pokoju na czas trwania projektu. Poproś interesariuszy o jak najwięcej, najlepiej codziennie.
Spalić
Możesz wykreślić swoje punkty idące w kierunku zera na wykresie wypalenia. Jeśli linia najlepszego dopasowania przekroczy zero, zanim osiągniesz limit czasu, prawdopodobnie jesteś na dobrej drodze. Jeśli nie, być może będziesz musiał powiadomić swojego klienta teraz, zanim zbliżysz się do terminu.
Jeśli zawiedziesz, zawiodłeś wcześnie.
Możesz zrobić wypalenie za pomocą oprogramowania, ale ja wolę tylko duży kawałek papieru na ścianie. Rysuj i pisz po całym nim.
Zautomatyzowane testowanie
Kiedy wielu programistów pracuje nad tymi samymi rzeczami w tym samym czasie, prawdopodobnie od czasu do czasu łamią sobie nawzajem swój kod. Pomaga w tym komunikacja i widoczność, ale prawdopodobnie będziesz chciał wprowadzić technologię, która pomoże znaleźć problemy.
Testowanie jednostkowe to proces pisania testów dla każdej części bazy kodu (najlepiej każdej metody). Testy jednostkowe powinny być przeprowadzane często, z każdym zapisem, jeśli to możliwe. Istnieje wiele narzędzi, które mogą w tym pomóc, na przykład Karma lub Rspec.
Kompleksowe testy obejmują testowanie całego projektu, traktując elementy wewnętrzne jako czarną skrzynkę. Oprzyj te testy na wysokich wymaganiach biznesowych, na przykład: „Użytkownik może się zarejestrować” lub „Użytkownik może zobaczyć listę elementów”. Kątomierz jest dobrym przykładem kompleksowego środowiska testowego opartego na sieci.
Na temat testowania napisano całe książki, ale przeprowadzenie przynajmniej testów akceptacyjnych może pomóc upewnić się, że nic nie zostanie zepsute podczas pracy nad projektem.
Unikanie długów technicznych i załatwianie spraw
Dług techniczny to koncepcja opisująca rzeczy, które będą musiały zostać później uporządkowane. Powszechnym źródłem długu są cechy, które zostały oznaczone jako wykonane, ale nigdy nie zostały „wykonane”. Wykonana funkcja jest sprawdzana w Git, została zatwierdzona przez interesariusza i ma test.
Nie wyłączaj swoich funkcji, dopóki nie zostaną zakończone. Nigdy nie masuj wykresu. Ponownie boli to wszystkich na dłuższą metę, w tym ciebie.
Jest to jeden z powodów, dla których początkowo podajemy tylko 6 punktów na programistę dziennie. Wykonanie wymaga dodatkowej pracy, ale czuje się świetnie i daje impuls zespołowi.
źródło
Edycja tych samych plików sama w sobie nie stanowi problemu. Problem stanowi jedynie edycja tej samej funkcji w celu wykonania dwóch różnych czynności.
Zasadniczo chciałbym podzielić projekt na osobne „funkcje”. Jedna może być związana z obsługą protokołu sieciowego, inna z plikiem konfiguracyjnym, a jeszcze inna z obsługą DB. Funkcje to wielkie rzeczy.
Następnie chcesz podzielić te funkcje na zadania (historie). Powinny to być proste rzeczy, takie jak „gdy użytkownik kliknie przycisk, program załaduje plik”, „gdy program się uruchomi, załaduje plik konfiguracyjny” itp.
Niektóre zadania będą musiały być wykonywane sekwencyjnie („program przeanalizuje wszystkie pola w pliku konfiguracyjnym” będzie musiał nadejść po „program załaduje plik konfiguracyjny”). Inni nie będą (możesz jednocześnie pracować z DB i siecią).
Ale najprawdopodobniej zrobisz to źle i tam właśnie pojawia się doświadczenie. Nie uda ci się ani trochę (lub dużo), błędnie oszacujesz czas, a Twój projekt zajmie trochę więcej czasu, niż powinien. Następnym razem będziesz lepszy.
Sugerowałbym również przeczytanie „Extreme Programming” autorstwa Kenta Becka. Świetna książka, która pomogła mi, gdy miałem zostać kierownikiem projektu.
źródło
Sprowadza się to do tego, że musisz rozbić aplikację na moduły funkcjonalne, a następnie wprowadzić umowy (interfejsy i umowy danych) między różnymi modułami. Każdy moduł można następnie przekazać innemu deweloperowi. Po ponownym złożeniu wszystkiego umowy zapewnią, że moduły te poprawnie się ze sobą komunikują.
Upewnij się, że wymuszasz TDD na programistach, aby zagwarantować, że wszystkie moduły działają indywidualnie.
Aby dać przykład, co mam na myśli:
Załóżmy, że chcesz, aby jeden z programistów zbudował program rejestrujący SQL.
Definiujesz interfejs i pytasz jednego ze swoich programistów ( lub tworzysz historię, jeśli korzystasz z Agile ), że chcesz logger specyficzny dla SQL zgodnie z następującą specyfikacją:
Następnie oczekuję od dewelopera:
Implementacja specyficzna dla SQL dla programu rejestrującego
Dowolny kod zależny, na przykład implementacja dla
SqlLogRepository
Testy jednostkowe lub próbne w zależności od potrzeb. Test próbny w powyższym przypadku (gdzie mamy inne zależności zewnętrzne) lub jeśli jest to np. Prosta funkcja użyteczności, taka jak
String.ReverseCharacters(string input)
, to po prostu chciałbym zobaczyć testy jednostkowe, które testują kilka różnych scenariuszy.To znaczy że:
Ty i Twój zespół możecie teraz kontynuować rozwój za pomocą tego interfejsu. na przykład
a jeśli musisz uruchomić kod przed jego
SqlLogger
wprowadzeniem, możesz po prostu utworzyćNullLogger
:I w międzyczasie możesz to przetestować (sugeruję, aby spojrzeć na ICO w celu wstrzyknięcia zależności)
Podsumowanie
Nie mam pojęcia o wielkości twojego projektu, ale może to być dość zniechęcające zadanie, a jeśli nigdy wcześniej nie prowadziłeś prac rozwojowych, sugeruję, abyś potraktował to zadanie bardzo poważnie i spędził kilka następnych tygodni czytając tyle samo, co Ty potrafi na projektowaniu oprogramowania i architekturze. I bądź bardzo przejrzysty w swojej pracy ( jakość oprogramowania itp. ), W przeciwnym razie szybko znajdziesz się w głębokim bałaganie, z którego nie wiesz, jak się wydostać.
Gorąco sugeruję również zapoznanie się z projektem i paradygmatem obiektowym. Będziesz w dużym stopniu polegać na OOP w tym projekcie.
źródło
Inne odpowiedzi mówiły o aspektach programowania, ale chciałem tylko wspomnieć o aspekcie zarządzania programem. Zacznę od zrzeczenia się odpowiedzialności: nie jestem menedżerem programu. Wziąłem jeden kurs na poziomie magisterskim w zakresie zarządzania programem, a moje doświadczenie zawodowe polega na licytowaniu godzin dla małych projektów, które zwykle trwają krócej niż 500 godzin i nigdy nie przekraczają 1000 godzin.
Ale musiałem pomóc w zdefiniowaniu zadania dla laboratorium, w którym musiałem utrzymywać 2-3 osoby zajęte przez 2-4 miesiące (pół etatu i pełny etat). Jedną z rzeczy, która naprawdę mi pomogła, było korzystanie z oprogramowania do zarządzania projektami, takiego jak Microsoft Project (nie jestem pewien, czy dostępna jest tam wersja bezpłatna, ale twój pracodawca prawdopodobnie ma coś takiego ... zapytaj swojego przełożonego, jakie oprogramowanie do zarządzania programem jest używane w twojej firmie). W szczególności dość często korzystam z wykresów Gantta, co jest domyślnym widokiem w Microsoft Project. Określając wszystkie zadania i czas ich trwania, możesz uzyskać wizualizację do zabawy.
Wykres Gantta najbardziej mi pomaga ze względu na jego wizualizację. Widzenie zadań na papierze niewiele mi pomaga, ale z pewnością ładne zdjęcia i wykresy. Microsoft Project pozwala również na ustawienie poprzedników i dat rozpoczęcia, przy czym głównym założeniem jest „Znajdź minimalną liczbę zadań wymaganych do uruchomienia, aby zadanie X mogło się rozpocząć”. Przynajmniej w moich małych projektach liczba „prawdziwych” poprzedników jest dość niewielka. W rzeczywistości przy jednym projekcie miałem problem, że prawie wszystko można zrobić jednocześnie, i musiałem zsyntetyzować dwie współbieżne ścieżki, które były dość spójne. Np. Starałem się upewnić, że jeśli programista A dotknie GUI, pracują również nad zadaniami, które są zbliżone do GUI.
Wygląda na to, że robiłeś już dużo tego, jeśli chodzi o papier i długopis, ale zawsze uważam, że naprawdę pomocne jest zobaczenie wykresów Gantta. Patrzenie na kolejno ustawione zadania naprawdę sprawia, że myślę: „Czekaj, czy zadanie X naprawdę musi zostać wykonane przed zadaniem Y? (Z mojego dotychczasowego doświadczenia byłem zaskoczony, jak często odpowiedź brzmi„ nie ”)”
źródło
Wygląda na to, że ukończyłeś programistę i zostałeś inżynierem oprogramowania. Zdaj sobie sprawę, że zarządzanie pracą nie jest ćwiczeniem projektowym, ale oba idą w parze. Musisz zarządzać wykonywaną pracą, a to zależy od rozwoju Twojej firmy. Jeśli masz czas i zasoby, przyjrzyj się zwinnej metodologii - w Internecie jest mnóstwo materiałów pisemnych. Znajdź taki, który Ci odpowiada, ale pamiętaj, że podobnie jak wszystko inne, nie jest bezpłatny. Zastosowanie wszelkich technik obejmuje szkolenie, naukę i porażkę, zanim odniesiesz sukces. Jeśli nie masz wystarczającej przepustowości, aby poradzić sobie z przyjęciem bardziej kompleksowej techniki, wówczas planowanie kamienia milowego może być dla Ciebie odpowiedzią. Jeśli masz listę zadań sekwencyjnych, być może nie znalazłeś sekwencji, które mogąbyć zrównoleglony. Może się zdarzyć, że chcesz podzielić swój rozwój na bardziej ogólne zadania, takie jak testowanie i implementacja. To samo w sobie nie rozwiązuje problemu z raportowaniem, ale zarządzasz jakością. Twój postęp może być sekwencyjną listą, ale twoje role są równoległe. Tylko sugestia. Projekt odwzorowujący pracę wykonaną przez ludzi nazywany jest strukturą podziału pracy.
Istnieje wiele dobrych sugestii, które zaoferowały inne osoby, ale pamiętaj, że zarządzasz pracą. Czasami możesz mapować koncepcje pracy do projektu / architektury, czasem nie możesz tego zrobić tak łatwo. Zawsze istnieje sposób na uporządkowanie pracy, aby można ją było śledzić. Proponuję wrócić do swojego kierownika i zapytać go, co jest dla niego ważne, jeśli chodzi o komunikację o stanie projektu. To zacznie mówić, jak podejść do tego, co robisz. Jeśli jest to harmonogram, warto skupić się na raportowaniu postępów. Jeśli jest to jakość, chcesz zgłosić zestaw wskaźników, które musisz wymyślić. Jeśli to kosztuje, prawdopodobnie będziesz chciał spojrzeć na wysiłek. Wszystkie te rzeczy można również przypisać do zadań lub z zadań.
źródło