Czy przyznanie nowym rekrutom osobnego podprojektu od doświadczonych programistów pomoże początkującym szybciej się rozwijać?

Mamy 7 programistów w zespole i musimy podwoić tempo rozwoju w krótkim czasie (około miesiąca). Wiem, że istnieje zasada zdrowego rozsądku, że „jeśli zatrudnisz więcej programistów, tracisz produktywność tylko przez kilka pierwszych miesięcy”. Projekt jest usługą e-commerce i ma około 270 000 linii kodu.

Moim pomysłem na razie jest podzielenie projektu na dwa mniej lub bardziej niezależne podprojekty i pozwolenie nowemu zespołowi pracować na mniejszym z dwóch podprojektów, podczas gdy obecny zespół pracuje nad głównym projektem. Mianowicie, nowy zespół będzie pracował nad funkcjonalnością kasy, która ostatecznie stanie się niezależną usługą internetową w celu zmniejszenia sprzężenia. W ten sposób nowy zespół pracuje nad projektami zawierającymi tylko 100 000 wierszy kodu.

Moje pytanie brzmi: czy takie podejście pomoże początkującym programistom łatwo dostosować się do nowego projektu? Jakie są inne sposoby szybkiego rozszerzenia zespołu programistów bez czekania dwóch miesięcy, aż nowicjusze zaczną produkować więcej oprogramowania niż błędów?

=======

AKTUALIZACJA

To przedsięwzięcie całkowicie zawiodło, ale nie z powodów, o których wspomnieliście. Po pierwsze, byłem źle poinformowany o wielkości i możliwościach nowego zespołu. Sam powinienem je ocenić. Po drugie, zatrudnienie okazało się trudną pracą w tym miejscu. Na miejscu w głównym biurze zatrudnienie było znacznie łatwiejsze, ale w mieście drugiego zespołu najwyraźniej brakowało programistów o wymaganych kwalifikacjach. W rezultacie, zamiast przewidywanych 1,5 miesiąca, praca przedłużyła się do około 4,5 miesiąca i została anulowana w połowie kadry kierowniczej.

Kolejnym błędem, który popełniłem (i ostrzegł o tym Alex D), jest to, że próbowałem sprzedać refaktoryzację najwyższemu kierownictwu. Nigdy nie sprzedajesz refaktoryzacji, tylko funkcje.

Uruchomienie i tak zakończyło się sukcesem. Refaktoryzacja, która nigdy nie miała miejsca, przekształciła się w dług techniczny: system stał się bardziej monolityczny i mniej konserwowalny, produktywność programistów stopniowo spadała. Nie jestem teraz w zespole, ale mam nadzieję, że ukończą go w najbliższej przyszłości. W przeciwnym razie nie dałbym ani grosza za przetrwanie projektu.

Pomyślałem, zgadzam się, jak wszyscy tutaj, że:

„... dodanie większej liczby programistów do opóźnionego projektu powoduje, że projekt opóźnia więcej ...”

Mam wrażenie, że zrobisz to wszędzie, więc ...

Twój pomysł może pomóc, jeśli istniejący projekt jest wystarczająco uporządkowany według modułów, podsystemów lub podprojektów.

To, co możesz spróbować, to dać im małe kawałki / moduły / formularze / klasy swojego projektu, do pracy, zamiast całego projektu.

Jeśli korzystasz z bazy danych, możesz chcieć wykonać kopię działającej bazy danych z danymi i uzyskać do nich dostęp z modułu lub podsystemu kodu, który będzie tam pracował.

Posiadanie nowych programistów znających język programowania lub środowisko programowania nie wystarczy, aplikacje mogą stać się bardzo złożone.

Czy masz jakąś dokumentację aplikacji, taką jak: UML, ER, Codd-Yourdon, cokolwiek?

Powodzenia.

Moje pytanie brzmi: czy to podejście pomoże początkującym programistom łatwo dostosować się do nowego projektu?

„Nowicjusz” może oznaczać dla ciebie nowość lub może oznaczać nowość w pracy jako twórca oprogramowania. Jeśli zamierzasz zatrudnić grupę programistów do pracy nad ważnym projektem zgodnie z harmonogramem, upewnij się, że przynajmniej większość nowych pracowników to doświadczeni programiści, a najlepiej ci, którzy napisali projekty podobne do tego, co próbujesz budować.

Jakie są inne sposoby szybkiego rozszerzenia zespołu programistów bez czekania dwóch miesięcy, aż zaczną produkować więcej oprogramowania niż błędów?

• Kup lub licencjonuj istniejący produkt zamiast próbować zbudować własny. Czy naprawdę potrzebujesz wynaleźć koło kasy?

• Jak powiedziałem powyżej, zatrudniaj ludzi, którzy mają doświadczenie w budowaniu takiego systemu, jaki chcesz.

• Nawet zanim zatrudnisz ten nowy zespół, powinieneś pomyśleć o tym, co powinni wiedzieć o twoich istniejących rzeczach. Upewnij się, że masz wystarczająco dużo czasu na treningi, aby pomóc im przyśpieszyć.

• Czy stworzyłeś pisemny zestaw wymagań? Jeśli nie, zrób to teraz. Jeśli spodziewasz się zaprojektować projekt zamiast pozwolić na to nowemu zespołowi, powinieneś również przygotować jasny dokument projektowy, ale bądź otwarty na zmiany w odpowiedzi na uwagi nowych członków zespołu.

• Czy masz dobrze zdefiniowany proces rozwoju? Baza danych błędów? Kontrola wersji? Proces przeglądu kodu? Przewodnik po stylu? Ułóż te rzeczy na miejscu.

• Nie oczekuj cudów. Państwo chce zatrudnić osobę siedem zespół i wszystko pracuje wydajnie w ciągu kilku tygodni, ale chcąc nie oznacza to, że można mieć. W zależności od tego, gdzie się znajdujesz, znalezienie siedmiu odpowiednich osób może potrwać dłużej niż miesiąc. Próba pośpiechu sprawi teraz ból i koszty tylko później.

IMHO umieszczając wszystkich nowych programistów w nowym projekcie, oddzielonych od istniejącego zespołu, na pewno przyniesie problemy. Tak, to (może) pozwoli twojemu staremu zespołowi pracować mniej więcej w obecnym tempie. Jednak nowi faceci nie będą mieli pojęcia o ogólnej architekturze i dużym obrazie, więc zajmą dużo czasu, aby przyspieszyć ... i nawet wtedy mogą iść w złym kierunku.

Sugeruję podzielenie istniejącego zespołu na dwie części i zatrudnienie nowych członków w obu zespołach. W ten sposób w obu zespołach są ludzie, którzy mogą mentorować nowo przybyłych i zapewnić utrzymanie wspólnej, spójnej wizji architektonicznej.

W przeciwnym razie zgadzam się z Calebem, że dokumentowanie jasnych wymagań, definiowanie procesu rozwoju i narzędzi oraz rezerwowanie czasu na szkolenie ... a także to, że oczekiwanie, że zespół 7 osób zostanie zatrudniony i przyspieszy w ciągu miesiąca, jest nierealne.

Dmitry, podwojenie tempa rozwoju w krótkim czasie jest niezwykle ambitnym celem. Opublikowano tu kilka dobrych sugestii; ale bez względu na to, co próbujesz, pamiętaj, że może się to nie zdarzyć . jeśli tempo rozwoju nie podwoi się, jakie byłyby konsekwencje z perspektywy biznesowej? Czy starasz się dotrzymać terminu?

Jeśli próbujesz dotrzymać terminu, czy możesz to zrobić bardziej niezawodnie, ograniczając funkcje? Znalazłem świetny sposób, aby „niedotrzymane terminy” były akceptowalne dla klienta, poprzez wprowadzanie przyrostowych wersji; wydać wersję, która ma podzbiór wymaganych funkcji, a następnie, gdy więcej funkcji jest gotowych, wypuszczaj je stopniowo, aż do ostatecznej wersji.

Więc starasz się być zespołem, który nie padnie ofiarą Miesiąca Mitycznego Człowieka . Będziesz miał kilka problemów, ktoś w zespole będzie musiał przeprowadzić wywiady techniczne, potem będziesz musiał poczekać kilka tygodni po zaakceptowaniu stanowiska, zanim będzie mógł zacząć. Może minąć dwa miesiące, zanim nowi programiści staną przed klawiaturami.

Każdy nowy pracownik ma ujemną produktywność w ciągu pierwszych kilku miesięcy. Jest jeszcze gorzej, ponieważ obecni programiści będą musieli ich mentorować, co jeszcze bardziej obniży wydajność programów.

Inną częścią MMM było to, że wraz ze wzrostem zespołu rosną również problemy z komunikacją. Spotkania stają się większe, łańcuchy e-mailowe stają się dłuższe ...

Sprowadzałbym je w mniejszych grupach i wiedziałbym, że przez długi czas wydajność nie będzie proporcjonalna do zwiększonego rozmiaru zespołu. Należy również zdawać sobie sprawę, że drenaż przepływów pieniężnych w ciągu pierwszych kilku miesięcy może być znaczny ze względu na koszty wejścia na pokład i wyposażenia.

W swoim komentarzu do Alexa D. wspomniałeś: „To nie ostateczne terminy, których dotrzymujemy, jego demonstrowalna zdolność do dostarczania nowych funkcji”. Przejdź więc do stylu programowania, który dzieli funkcje na mniejsze fragmenty i częściej. Poproś nowych członków zespołu o przetestowanie nowych funkcji, które pomogą im zrozumieć bazę kodu.

Lepiej byłoby nie zatrudniać nikogo nowego i patrzeć na swoje procesy, aby zobaczyć, gdzie można wprowadzić zmiany, aby przyspieszyć. Im szybciej zostaną znalezione błędy, tym mniej czasu zajmie ich usunięcie, więc jak testujesz? Czy robisz recenzje kodu? Czy zwracasz uwagę na jakość wymagań? Czy masz zautomatyzowane kompilacje i procesy depotymentu? Czy masz zautomatyzowane testy? Czy organizujesz codzienne spotkania stand-up (zdumiewające, o ile szybszy może być rozwój, gdy ktoś codziennie będzie Cię prosić o Twoją ofertę! Czy używasz zwinnych procesów? Czy masz jakieś podstawowe wady projektowe, którymi należy się zająć, aby przyspieszyć resztę rozwoju (zły projekt może niesamowicie spowolnić projekt)?

Proszę przeczytać miesiąc mitycznego człowieka. Najwyraźniej będziesz musiał to zrobić, aby móc powiedzieć wyższemu kierownictwu, dlaczego dokonują trudnych wyborów, aby przyspieszyć projekt. .

Chcesz zrzucić je z klifu i sprawdzić, czy potrafią latać? Myślę, że kiedy odkrywasz rzeczy na własną rękę, mają tendencję do trzymania się ciebie na dłuższą metę, a nie tylko dostarczania ci rozwiązań. Zakłada to jednak, że faktycznie odkrywasz lepsze rozwiązania. Nie rozumiem, dlaczego nie możesz pozwolić, aby ten zespół miał wykwalifikowanego lidera, który zrównoważy się, pozwalając im popełnić błędy samodzielnie, oraz udzielając im wskazówek i instrukcji, ucząc się na przykładach z dobrej jakości.