Dlaczego dodanie większej liczby osób do późnego projektu powoduje, że później?

To dość powszechne powiedzenie, że dodanie większej liczby programistów do późnego projektu pogorszy sprawę. Dlaczego to?

Wprowadzenie narzutów

Każdy nowy programista musi zostać wprowadzony do podstawy kodu i procesu programistycznego, który zajmuje nie tylko czas nowej osobie, ale także wymaga pomocy ze strony starszych programistów (prowadząc ich przez proces kompilacji, wyjaśniając proces testowania, pomagając im z pułapkami w bazie kodu, znacznie bardziej szczegółowymi recenzjami kodu itp . ) .

Dlatego im więcej nowych programistów dodajesz do projektu, tym więcej czasu trzeba poświęcić, aby doprowadzić ich do punktu, w którym mogą faktycznie wnieść swój wkład w projekt.

Oprócz innych odpowiedzi: Innym czynnikiem, który należy wziąć pod uwagę, jest komunikacja.

Najgorszym przypadkiem ilości kanałów komunikacji w zespole (co nie jest rzadkie) jest pełny wykres . Jak możesz sobie wyobrazić, dodanie tylko 1 programisty może znacznie zwiększyć kanały komunikacji. Dzięki bardziej usprawnionym metodom komunikacji wpływ jest mniejszy ... ale wciąż się sumuje.

Problem cytowany w książce pierwotnie ogłoszonej tym prawem, The Mythical Man-Month , dotyczy komunikacji. Zaczyna od powiedzenia:

Mężczyźni i miesiące są towarami wymiennymi tylko wtedy, gdy zadanie można podzielić na wielu pracowników, bez żadnej komunikacji między nimi. Dotyczy to zbierania pszenicy lub zbierania bawełny; nie jest nawet w przybliżeniu prawdą w programowaniu systemów.

W ramach problemu wspomina o szkoleniu:

Dodatkowy ciężar komunikacji składa się z dwóch części: szkolenia i komunikacji wewnętrznej. Każdy pracownik musi być przeszkolony w zakresie technologii, celów wysiłku, ogólnej strategii i planu pracy. Szkolenia tego nie można podzielić, więc ta część pracy zmienia się liniowo w zależności od liczby pracowników.

... ale zauważa, że ​​komunikacja jest zdecydowanie większym czynnikiem:

Ponieważ konstrukcja oprogramowania jest z natury wysiłkiem systemowym - ćwiczeniem w złożonych wzajemnych powiązaniach - wysiłek komunikacyjny jest wielki i szybko dominuje skrócenie czasu wykonywania poszczególnych zadań spowodowane przez partycjonowanie. Dodanie kolejnych mężczyzn wydłuża, a nie skraca harmonogram.

Warto również zauważyć, że Fred Brooks (autor) ma doświadczenie, aby wiedzieć, o czym mówi. Większość książki opiera się na jego doświadczeniu w zarządzaniu projektem IBM OS / 360. Pomimo dziesięcioleci zwolenników głoszących wszelkiego rodzaju „ulepszone” metody zarządzania, a niektórzy nawet wymyślają fajne nazwy (eXtreme, Agile, Scrum itp.), Kiedy do tego dojdzie, wydaje się, że niewiele esencji ¹ zmieniło się od tego czasu.

¹ Definicja „istoty”, patrz samego autora za „No Silver Bullet: istota i wypadek w Inżynierii Oprogramowania”, zawarte w 20 ^th Anniversary Edition z mitycznym Man-Month .

To nie tylko przysłowie; jest weryfikowalny. Sprawdź „ The Mythical Man-Month ” Brooksa .

Oto kilka przemyśleń na ten temat ...

• Musisz użyć bieżących zasobów, aby przyspieszyć nowe zasoby na temat tego, co dzieje się w projekcie.
• Nowy zasób może nie być zaznajomiony z bazą kodu, dlatego wymaga więcej czasu, aby się przyzwyczaić do kodu.

teraz dodanie nowych zasobów do testowania może nie być złym pomysłem ... może przyspieszyć proces testowania (jeśli twoje przypadki testowe są dobrze napisane), i tak, użycie narzędzi testowych również pomoże.

Ponieważ programowanie nie jest podstawową pracą na linii produkcyjnej. Przyspieszenie projektu oprogramowania wymaga czasu. Nowi ludzie muszą zadawać wiele pytań, które prowadzą do negatywnej produktywności (tj. Uczenie się nowej osoby, nauczanie jej przez starszą osobę -> brak faktycznej pracy).

Aby to uprościć, wyobraź sobie stosunkowo prosty jednoosobowy projekt, który ma trwać 1 tydzień: w czwartek zdajesz sobie sprawę, że nie uda się go wykonać na czas, a zamiast tego zajmie to programistowi więcej niż 6-7 dni z 5. Jeśli w tym momencie dodasz innego programistę, będą oni musieli pracować z programatorem1 przez co najmniej kilka godzin lub dzień, zadaj wiele pytań, aby przyspieszyć itp. Prawdopodobnie nie dostaniesz dodatnia produktywność netto przez resztę tygodnia. Nowy programista prawdopodobnie również wprowadzi kilka dodatkowych błędów (ponieważ nie będzie znał istniejącego kodu tak samo jak programmer1), dzięki czemu cykl wdrażania i testowania zostanie wyparty o kolejny dzień lub dwa. Projekt z łatwością potrwa pełne dwa tygodnie robocze zamiast oryginalnego!

Fred Brooks napisał całą książkę „The Mythical Man-Month”, odpowiadając na to pytanie.

Oto szybka i brudna wersja:

1) Istnieje limit tego, ile możesz podzielić projekt na odrębne części, aby przypisać je większej liczbie programistów.

2) Podział projektu na większą liczbę osób zwiększa ilość komunikacji wymaganej do koordynowania wszystkich części aplikacji. Więcej komunikacji = więcej pracy.

3) Do każdej osoby dodawanej do projektu dodajesz więcej niż jeden kanał komunikacji, który musi być nawigowany do zespołu. Liczba ta rośnie geometrycznie i zwiększa ilość komunikacji, która musi nastąpić. Więcej komunikacji = więcej pracy.

4) Po dodaniu każdego członka zespołu pojawia się „Krzywa J”. Oznacza to, że istniejące zasoby produkcyjne muszą poświęcić czas na przyspieszenie nowych ludzi, których w innym przypadku mogliby spędzić pracując nad projektem. Ostatecznie możesz zwiększyć pojemność, ale tymczasowo spowalnia projekt. Im później w projekcie, tym więcej trzeba się nauczyć, tym bardziej wyraźny efekt.

Innym czynnikiem, o którym nie wspomniałem, jest to, że niektóre zadania muszą być wykonane w określonej kolejności. Nie można wykonać zadania 4, dopóki zadanie 3 nie zostanie wykonane, ponieważ jest ono zależne od 3. Nie ma sensu zatrudniać kogoś do wykonania zadania 4 w tym samym czasie, gdy ktoś wykonuje zadanie 3. Często na końcu projektu , te zadania, które wymagają wykonania innych czynności w pierwszej kolejności, to pozostałe zadania.

Często są to jedne z najbardziej skomplikowanych zadań, które należy wykonać, te, które wymagają najlepszego zrozumienia całego projektu, aby uniknąć zniszczenia tego, co już zostało ukończone. Zazwyczaj wymagają one również najszerszej wiedzy na temat domen biznesowych. Może po miesiącach pracy nad projektem będę w stanie wykonać zadanie za tydzień lub krócej. Ktoś nowy poświęciłby więcej niż tydzień na przyśpieszenie (i odciągnięcie mnie od moich zadań, aby ochronić ten czas, aby odpowiedzieć na pytania) i prawdopodobnie nawet gdyby niezwykle wykwalifikowani zajęli się tym zadaniem dłużej. Nie dlatego, że nie jest on kompetentny, ale z powodu nieznajomości faktycznej struktury projektu lub zaplecza bazy danych.

Powiedzenie, które zawsze się dla mnie sprawdza, mówi, że nie można zmusić dziewięciu kobiet do zrobienia dziecka w ciągu jednego miesiąca.

Sugerowałbym także „Peopleware” autorstwa DeMarco i Lister.

„The Deadline” autorstwa DeMarco przedstawia to oraz szereg innych chorób i błędów zarządzania projektami oprogramowania w beztroski i bardzo czytelny sposób.

Zagłębia się także w dynamikę ludzi wykonujących pracę w projekcie / zespole i szczegółowo opisuje POZYCJE, takie jak komunikacja i wprowadzenie wyczerpują dostępny czas pracy zespołu.

Te książki są dość tanie, sugeruję, aby je zdobyć (mają je Amazon lub The Book Depository) i przeczytać. Krótkie odpowiedzi tutaj nie mogą naprawdę oddać zadanego pytania.

Ponieważ nikt nie ma czasu na przemyślany, zaplanowany i przetestowany proces: zatrudniania, szkolenia, rozwijania i nadzorowania programistów, nie mówiąc już o przyspieszeniu ich do określonego projektu.

Jeśli zarządzasz zespołem programistów, powinieneś mieć teraz kilka kontaktów z osobami, które chciałbyś zatrudnić, jeśli masz ofertę pracy. Dołącz do grup programistów.

Jak szybko można uzyskać nową konfigurację maszyny programistycznej i gotowe do pracy?

Czy kiedykolwiek testowałeś dokumentację i specyfikacje projektu, pokazując je deweloperowi przy innym projekcie? Czy spojrzeli na to i stwierdzili, że w razie potrzeby mogą rozpocząć pracę nad projektem?

Jak aktualny jest harmonogram każdego projektu?

Zaoszczędź na deszczowy dzień, ponieważ gdy projekt się opóźnia, przypomina bardziej huragan.

Oprócz problemu z komunikacją (o którym myślę, że wszystkie pozostałe odpowiedzi mówią), jest również bardzo możliwe, że osoba dodana do projektu tworzy błędy, ponieważ nie zna jeszcze dobrze kodu.

Ilekroć jestem dodawany do projektu, zawsze bardzo staram się nie rozbijać rzeczy. Oznacza to, że na początku znacznie wolniej naprawiam.

Chciałbym wskazać na coś całkowicie ignorowanego do tej pory przez inne odpowiedzi.

Zanim ludzie są dodawani do późnego projektu, zwykle wiele się nie udaje w całej organizacji. Zarząd i klient nie są zadowoleni. Ludzie byli zmuszani do kontynuowania tego. Rzeczy są dość napięte.

Teraz wyobraź sobie, że jesteś w tym zespole. Oczywiście to nie twoja wina. Planowanie (z których żaden nie był twój) było zbyt optymistyczne. Wszystkie złe decyzje zostały podjęte bez konsultacji z tobą. Próbujesz jak najlepiej to wykorzystać i nagle przyjeżdża mnóstwo nowych ludzi. Jakie przesłanie to przekazuje?

Ludzie na górze najwyraźniej stracili wiarę w ciebie. Wezwali dużych chłopców, aby nadrobili zaległości.

Czy nadal będziesz motywowany, aby osiągnąć sukces? A może ... czy będziesz coraz bardziej sfrustrowany i wolałbyś, żeby w końcu wszystko się zawiesiło?

Nie spiesz się :-).