Potrzebuję tego dziecka za miesiąc - wyślij mi dziewięć kobiet!

W jakich okolicznościach - jeśli w ogóle - czy dodanie programistów do zespołu faktycznie przyspiesza rozwój już opóźnionego projektu?

Dokładne okoliczności są oczywiście bardzo specyficzne dla twojego projektu (np. Zespół programistów, styl zarządzania, dojrzałość procesu, trudność przedmiotu itp.). Aby rozszerzyć to nieco lepiej, abyśmy mogli mówić o tym w niczym innym, jak tylko w nadmiernych uproszczeniach, powtórzę twoje pytanie:

W jakich okolicznościach, jeśli w ogóle, czy dodanie członków zespołu do projektu rozwoju oprogramowania, który jest realizowany z opóźnieniem, może spowodować skrócenie faktycznej daty wysyłki z poziomem jakości równym temu, gdyby istniejący zespół mógł pracować do zakończenia?

Istnieje wiele rzeczy, które moim zdaniem są konieczne , ale niewystarczające, aby do tego doszło (w dowolnej kolejności):

• Proponowane osoby do dodania do projektu muszą mieć:
  • Przynajmniej rozsądne zrozumienie problematycznej dziedziny projektu
  • Umiejętność posługiwania się językiem projektu i konkretnymi technologiami, których użyliby do powierzonych zadań
  • Ich biegłość musi / nie / być znacznie mniejsza lub znacznie większa niż odpowiednio najsłabszego lub najsilniejszego istniejącego członka. Słabi członkowie wyczerpią twój obecny personel z trzeciorzędnymi problemami, podczas gdy nowa osoba, która jest zbyt silna, zakłóci zespół, gdy wszystko, co zrobili i robią, jest złe.
  • Mają dobre umiejętności komunikacyjne
  • Bądź silnie zmotywowany (np. Być w stanie pracować niezależnie bez marnowania czasu)
• Obecni członkowie zespołu muszą mieć:
  • Doskonałe umiejętności komunikacyjne
  • Doskonałe umiejętności zarządzania czasem
• Kierownik projektu / kierownictwo musi posiadać:
  • Dobre możliwości ustalania priorytetów i alokacji zasobów
  • Wysoki poziom szacunku ze strony obecnych członków zespołu
  • Doskonałe umiejętności komunikacyjne
• Projekt musi mieć:
  • Dobra, kompletna i udokumentowana specyfikacja projektu oprogramowania
  • Dobra dokumentacja rzeczy już zaimplementowanych
  • Modułowa konstrukcja pozwala na wycięcie wyraźnych kawałków odpowiedzialności
  • Wystarczające zautomatyzowane procesy zapewniania jakości dla wymaganego poziomu defektów Mogą to być między innymi: testy jednostkowe, testy regresyjne, automatyczne wdrożenia kompilacji itp.)
  • System śledzenia błędów / funkcji, który jest obecnie stosowany i używany przez zespół (np. Trac, SourceForge, FogBugz itp.).

Jedną z pierwszych rzeczy, które należy omówić, jest to, czy datę wysyłki można przesunąć, czy funkcje można skrócić, i czy niektóre kombinacje tych dwóch elementów pozwolą ci zadowolić wydanie z obecnego personelu. Wiele razy jest to kilka funkcji, które naprawdę pochłaniają zasoby zespołu, który nie zapewni wartości równej inwestycji. Dlatego poważnie przeanalizuj priorytety swojego projektu.

Jeśli wynik powyższego akapitu nie jest wystarczający, odwiedź powyższą listę. Jeśli wcześniej zdążyłeś złapać harmonogram, dodanie odpowiednich członków zespołu we właściwym czasie może uratować wydanie. Niestety, im bliżej przewidywanej daty wysyłki, tym więcej rzeczy może pójść nie tak z dodawaniem ludzi. W pewnym momencie przekroczysz „punkt bez powrotu”, w którym żadna zmiana (poza wysłaniem bieżącej gałęzi programistycznej) nie uratuje Twojej wersji.

Mógłbym kontynuować, ale myślę, że osiągnąłem najważniejsze punkty. Poza projektem, a także pod względem kariery, przyszły sukces firmy itp. Jedną z rzeczy, które powinieneś zdecydowanie zrobić, to dowiedzieć się, dlaczego się spóźniłeś, jeśli cokolwiek można było zrobić, ostrzec Cię wcześniej i jakie środki potrzebujesz podjąć, aby temu zapobiec w przyszłości. Późny projekt zwykle występuje, ponieważ albo:

• Spóźniłeś się, zanim zacząłeś (więcej rzeczy niż czas) i / lub
• poślizgnął 1 godzinę, 1 dzień na raz.

Mam nadzieję, że to pomaga!

Pomaga to tylko w przypadku projektu opartego na zasobach.

Rozważmy na przykład:

Musisz namalować duży plakat, powiedzmy 4 na 6 metrów. Plakat tak duży, że prawdopodobnie umieścisz przed nim dwie lub trzy osoby i pomalujesz je równolegle. Jednak umieszczenie przed nim 20 osób nie zadziała. Dodatkowo będziesz potrzebować wykwalifikowanych ludzi, chyba że chcesz gównianego plakatu.

Jeśli jednak twój projekt ma wypychać koperty gotowymi listami (np. MOŻESZ wygrać! ), To im więcej osób dodasz, tym szybciej. Rozłożenie stosów pracy wiąże się z pewnymi kosztami, więc nie możesz uzyskać zasiłków aż do momentu, w którym masz jedną osobę na osobę. kopertę, ale możesz uzyskać korzyści od znacznie więcej niż 2 lub 3 osób.

Więc jeśli twój projekt można łatwo podzielić na małe części i jeśli członkowie zespołu mogą szybko przyspieszyć (jak ... natychmiast), to dodanie większej liczby osób przyspieszy, do pewnego momentu.

Niestety, niewiele projektów jest takich w naszym świecie, dlatego wskazówka docgnome na temat książki o mitycznym człowieku jest naprawdę dobrą radą.

Może, jeśli spełnione są następujące warunki:

1. Nowi programiści już rozumieją projekt i nie potrzebują czasu na rozruch.
2. Nowi programiści są już biegli w środowisku programistycznym.
3. Dodanie programistów do zespołu nie wymaga czasu administracyjnego.
4. Prawie nie jest wymagana komunikacja między członkami zespołu.

Dam ci znać, kiedy zobaczę je wszystkie po raz pierwszy.

Według Mitycznego Miesiąca Człowieka głównym powodem dodawania ludzi do późnego projektu jest późniejszy koszt komunikacji O (n ^ 2).

Doświadczyłem jednego podstawowego wyjątku: jeśli w projekcie jest tylko jedna osoba, prawie zawsze jest ona skazana na niepowodzenie. Dodanie drugiego przyspiesza go prawie za każdym razem. To dlatego, że komunikacja nie jest napowietrznych w tym przypadku - jest to pomocne okazja do wyjaśnienia swoje myśli i uczynić mniej głupich błędów.

Ponadto, jak oczywiście wiedziałeś, kiedy opublikowałeś swoje pytanie, rada z Mitycznego Miesiąca Człowieka dotyczy tylko późnych projektów. Jeśli twój projekt nie jest jeszcze spóźniony, jest całkiem możliwe, że dodanie ludzi nie zrobi tego później. Oczywiście zakładając, że robisz to poprawnie.

Jeśli obecni programiści są całkowicie niekompetentni, dodanie kompetentnych programistów może pomóc.

Mogę sobie wyobrazić sytuację, w której miałeś bardzo modułowy system, a istniejący programista nie uruchomił się nawet na bardzo izolowanym module. W takim przypadku pomocne może być przypisanie tylko tej części projektu nowemu programistowi.

Zasadniczo odniesienia do Miesiąca Mitycznego Człowieka są poprawne, z wyjątkiem wymyślonych przypadków, takich jak ten, który wymyśliłem. Pan Brooks przeprowadził rzetelne badania, aby wykazać, że po pewnym czasie koszty sieci i komunikacji związane z dodawaniem nowych programistów do projektu przeważą nad wszelkimi korzyściami wynikającymi z ich wydajności.

• Jeśli nowi ludzie skupią się na testowaniu
• Jeśli potrafisz wyizolować niezależne funkcje, które nie tworzą nowych zależności
• Jeśli potrafisz ortogonalizować niektóre aspekty projektu (zwłaszcza zadania niekodujące, takie jak projektowanie / układ wizualny, strojenie / indeksowanie bazy danych lub konfiguracja serwera / konfiguracja sieci), aby jedna osoba mogła nad tym pracować, podczas gdy inne nadal pracują z kodem aplikacji
• Jeśli ludzie się znają, a technologia, wymagania biznesowe i projekt są wystarczająco dobre, aby móc robić rzeczy ze świadomością tego, kiedy nadepną sobie nawzajem i jak tego uniknąć (to, oczywiście jest to dość trudne do zorganizowania, jeśli tak nie jest)

Tylko wtedy, gdy masz na tym późnym etapie jakieś niezależne (prawie 0% interakcji z innymi częściami projektu) zadania, które nie zostały jeszcze podjęte przez nikogo, a możesz zaangażować zespół, który jest specjalistą w tej dziedzinie. Dodanie członka zespołu musi zminimalizować zakłócenia dla reszty zespołu.

Zamiast dodawać programistów, można pomyśleć o dodaniu pomocy administracyjnej. Pomocne może być wszystko, co usunie zakłócenia, poprawi koncentrację lub motywację. Obejmuje to zarówno system, jak i administrację, a także bardziej prozaiczne rzeczy, takie jak zdobywanie obiadów.

Oczywiście każdy projekt jest inny, ale większość zadań programistycznych może być zapewniona w celu zapewnienia pewnej współpracy między programistami. W tym przypadku z mojego doświadczenia wynika, że ​​nowe zasoby mogą faktycznie nieumyślnie spowolnić ludzi, na których polegają, aby przyspieszyć ich działanie, aw niektórych przypadkach mogą to być Twoi kluczowi ludzie (nawiasem mówiąc, zwykle ludzie „kluczowi” czas na edukację nowicjusza). Kiedy są do prędkości, nie ma gwarancji, że ich praca będzie pasować do ustalonych zasad lub „kultury pracy” z resztą zespołu. Więc znowu może wyrządzić więcej szkody niż pożytku. Poza tym są to okoliczności, w których może to być korzystne:

1) Nowy zasób ma trudne zadanie, które wymaga minimum interakcji z innymi programistami i zestawu umiejętności, który został już wykazany. (tj. przenoszenie istniejącego kodu na nową platformę, zewnętrzne refaktoryzowanie martwego modułu, który jest obecnie zamknięty w istniejącej bazie kodu).

2) Projekt jest zarządzany w taki sposób, że inni, starsi członkowie zespołu mogą być dzieleni, aby pomóc w przyspieszeniu newb i mentorować ich po drodze, aby upewnić się, że ich praca jest zgodna z tym, co już zostało zrobione.

3) Pozostali członkowie zespołu są bardzo cierpliwi.

Przypuszczam, że dodawanie ludzi pod koniec pracy może przyspieszyć, jeśli:

1. Praca może być wykonywana równolegle.

2. Ilość zaoszczędzona dzięki dodanym zasobom to więcej niż czas stracony, gdy ludzie doświadczeni w projekcie wyjaśniają rzeczy niedoświadczonym.

EDYCJA: Zapomniałem wspomnieć, że takie rzeczy nie zdarzają się zbyt często. Zwykle są to dość proste rzeczy, takie jak ekrany administracyjne, które wykonują proste CRUD na stole. Obecnie tego typu narzędzia i tak mogą być generowane automatycznie.

Uważaj jednak na menedżerów, którzy polegają na tego rodzaju pracy do przekazania. Brzmi świetnie, ale w rzeczywistości zwykle nie wystarcza na przycięcie znacznego czasu wolnego od projektu.

• Samodzielne moduły, które jeszcze nie zostały uruchomione
• Brakuje narzędzi programistycznych, które można zintegrować (takich jak automatyczny menedżer kompilacji)

Przede wszystkim myślę o rzeczach, które pozwalają im trzymać się z daleka od obecnie rozwijających się ludzi. Zgadzam się z Mitycznym Miesiącem Człowieka, ale myślę też, że są wyjątki od wszystkiego.

Myślę, że dodanie ludzi do zespołu może przyspieszyć projekt bardziej niż dodanie ich do samego projektu.

Często napotykam problem posiadania zbyt wielu równoległych projektów. Każdy z tych projektów mógłby zostać ukończony szybciej, gdybym mógł skupić się tylko na tym projekcie. Dodając członków zespołu, mogłem zrezygnować z innych projektów.

Oczywiście zakłada to, że zatrudniłeś zdolnych, zmotywowanych programistów, którzy mogą dziedziczyć duże projekty i uczyć się niezależnie. :-)

Jeśli dodatkowy zasób uzupełnia istniejący zespół, może być idealny. Na przykład, jeśli masz zamiar skonfigurować sprzęt produkcyjny i sprawdzić, czy baza danych jest dostrojona, a nie tylko zwracać dobre wyniki (które Twój zespół zna jako eksperci w dziedzinie), pożyczając czas od dobrego dba, który pracuje nad projektem w następnej kolejności do twojego może przyspieszyć zespół bez większych kosztów szkolenia

Po prostu. Sprowadza się to do porównania pozostałego czasu i produktywności, które uzyskasz od kogoś, z wyłączeniem czasu potrzebnego na przyspieszenie dodatkowych zasobów i zwiększenie produktywności oraz odjęcie czasu poświęconego na nauczanie ich przez istniejące zasoby. Kluczowe czynniki (w kolejności według znaczenia):

1. Jak dobry jest zasób w podnoszeniu go. Najlepsi programiści mogą wejść na nową stronę i produktywnie naprawiać błędy niemal natychmiast przy niewielkiej pomocy. Ta umiejętność jest rzadka, ale można się jej nauczyć.
2. Segregacja zadań. Muszą być w stanie pracować nad obiektami i funkcjami bez potykania się o istniejących programistów i spowalniania ich.
3. Złożoność projektu i dostępnej dokumentacji. Jeśli jest to najlepsza praktyka ASP.Net i popularne dobrze udokumentowane scenariusze biznesowe, dobry programista może od razu utknąć. Ten czynnik bardziej niż jakikolwiek inny determinuje czas, jaki istniejące zasoby będą musiały zainwestować w nauczanie, a tym samym początkowy negatywny wpływ nowych zasobów.
4. Pozostały czas. Jest to często źle oszacowane. Często logika będzie taka, że ​​mamy tylko x tygodni i zajmie to x + 1 tygodni, aby kogoś przyspieszyć. W rzeczywistości projekt się poślizgnie i faktycznie pozostało 2x tygodni na opracowanie i zdobycie więcej zasobów wcześniej niż później pomoże.

Jeśli zespół jest już przyzwyczajony do parowania programowania, wówczas dodanie innego programisty, który ma już doświadczenie w parowaniu, może nie spowolnić projektu, szczególnie jeśli programowanie przebiega w stylu TDD.

Nowy programista będzie powoli stawał się bardziej produktywny, ponieważ lepiej rozumieją bazę kodu, a wszelkie nieporozumienia zostaną wykryte bardzo wcześnie albo przez ich parę, albo przez zestaw testów uruchamiany przed każdym zameldowaniem (najlepiej, by było czek co najmniej co dziesięć minut).

Należy jednak wziąć pod uwagę skutki dodatkowych kosztów ogólnych komunikacji. Ważne jest, aby nie rozcieńczać zbytnio istniejącej wiedzy o projekcie.

Dodanie programistów ma sens, gdy produktywność wniesiona przez dodatkowych programistów przewyższa produktywność utraconą podczas szkolenia i zarządzania tymi programistami.