Jaki jest najlepszy sposób podziału pracy między programistami

Mój zespół i ja przebudowujemy witrynę, którą opracowaliśmy około 10 lat temu, i chcemy to zrobić w Agile.

Więc po spędzeniu dużo czasu na czytaniu (prawdopodobnie za mało) mam problem z pytaniem, jak podzielić pracę między programistami.

Będę bardziej konkretny i powiem, że strona jest podzielona na osobne moduły, które nie mają ze sobą dużej integracji.

Jaki jest najlepszy / najczęściej akceptowany sposób podziału pracy między programistami?

• Dając każdej osobie inny moduł do pracy.
• Przypisz wszystkich programistów do tego samego modułu i podziel pracę na różne części modułu (UnitTesting, DAL and Mapping, Logics, UI)
• Przypisz wszystkich programistów do tego samego modułu i podziel pracę według różnych logik (na przykład każdy programista odpowiada za konkretną logikę (prawdopodobnie metodę w BL) i jego testy jednostkowe, DAL i mapowanie oraz interfejs użytkownika ...

A może coś zupełnie innego?

Mój zespół starał się „zwinnie” od kilku wydań, ale bycie częścią dużej korporacji nie ułatwiło tego. Nie będę udawał, że mam odpowiedź, ale mogę podzielić się moimi spostrzeżeniami.

• Podział programistów na moduł:

  • Musisz być ostrożny, ponieważ jeśli ludzie pracują zbyt dużo w izolacji, twój zespół nie korzysta z dzielenia się umiejętnościami i wiedzą
  • Planowanie spotkań i codziennych stand-upów może stać się niezwykle nudne dla wszystkich, jeśli ludzie za bardzo skupią się na swoich modułach i nie zobaczą większego obrazu. Kiedy ludzie się nudzą, zaczynają sprawdzać, a Ty tracisz wiele korzyści, jakie zwinne przynosi na stole
  • Może się zdarzyć, że niektóre komponenty będą napisane naprawdę dobrze, a inne komponenty, no cóż ... nie za bardzo. Jeśli ludzie pracują w izolacji, twoi starsi faceci nie będą mogli szkolić młodszych.

• Wszyscy pracują na tym samym module w tym samym czasie

  • Próbowaliśmy tego w jednym wydaniu, gdy kierownictwo zdecydowało, że narzucą zwinność całemu zespołowi i będzie to całkowicie po ich myśli. To absolutny wrak pociągu. W ciągu roku mieliśmy zespół 9 programistów, co zwykle robiłby 1 programista. (Być może przesadzam tutaj, ale nie za dużo).
  • Nikt nie miał ochoty oddychać. Ci, którym nie zależało na oprogramowaniu, czuli się jak w domu, ponieważ będąc częścią większej paczki, po prostu rozrzedzali się w grupie. Ci z nas, którzy pasjonowali się oprogramowaniem, czuli się całkowicie zduszeni, ponieważ nie było możliwości poruszania się i wychodzenia poza granice, na co zgodziło się 9 osób.
  • Wszystkie spotkania trwały wiecznie do tego stopnia, że ​​chciałem się zastrzelić. Zbyt wiele osób z opiniami w tym samym pokoju zmuszonych było pracować nad tą samą dziwaczną biblioteką DLL. Horror.
• W ostatnim wydaniu postanowiliśmy spróbować czegoś innego
  • Przede wszystkim podziel grupę programistów na mniejsze zespoły 3-4 programistów. Każdy zespół pracował w względnej izolacji od siebie, ale w zespole ludzie pracowali o wiele bardziej spójnie
  • Przy takim podejściu wstawanie jest szybkie, a planowanie spotkań zajmuje 1-2 godziny w porównaniu do 4 godzin.
  • Wszyscy czują się zaangażowani, ponieważ każdy zespół omawia tylko to, o co dbają programiści tego zespołu.
  • Kierownik techniczny każdego zespołu co jakiś czas rozmawia z innymi potencjalnymi pracownikami technicznymi, aby upewnić się, że cały projekt jest na dobrej drodze.
  • Zamiast uczynić ludzi „właścicielami” określonego modułu, powierzyliśmy ludziom obszary specjalizacji, więc kiedy zaczynaliśmy projekt, wydawało się, że ludzie mają swój własny moduł, ale po kilku miesiącach programiści zaczęli patrzeć na siebie nawzajem jako obszary zaczęły się pokrywać.
  • Przeglądy kodu są niezbędne. To było drugie wydanie, w którym mieliśmy surowe zasady sprawdzania kodu i wszyscy w zespole je uwielbiają. Ekspert określonego obszaru jest zawsze w trakcie przeglądu kodu, gdy ktoś inny modyfikuje ten kod.
  • Dzięki przeglądom kodu mamy mnóstwo dzielenia się wiedzą i możesz wyraźnie zobaczyć ogólną poprawę jakości kodu naszych zespołów. Również dlatego, że kod jest tak często sprawdzany, kiedy ludzie wchodzą w czyjąś specjalizację, są szanse, że widzieli go już co najmniej kilka razy.
  • Większa część każdego zespołu jest wciągana w spotkania przeglądowe projektu, więc nawet jeśli nigdy nie widzieli kodu, wszyscy znają ogólny przepływ wszystkich modułów, za które odpowiedzialny jest ich zespół.
  • Robiliśmy to przez około 10 miesięcy i wydaje się, że zaczęliśmy od izolowanego modułu i przekształciliśmy się we wszystkich, którzy pracują nad wszystkim. Ale jednocześnie nikt nie czuje się skrępowany lub ograniczony. Aby upewnić się, że chłopaki nadal mają poczucie autorytetu, zostawiliśmy ich jako ekspertów terenowych, mimo że obecnie jest to w większości formalność.

Robiliśmy tę ostatnią rzecz i chociaż jest mnóstwo miejsca na ulepszenia, ogólnie cały nasz zespół był bardzo szczęśliwy i to wiele mówi, kiedy jesteśmy częścią gigantycznej korporacji.

Jedną ważną rzeczą, którą popełniliśmy źle za pierwszym razem, gdy „zwiniliśmy się”, jest to, że ludzie mówili, jak pracować, i powiedziano im, nad czym pracować. To najlepszy sposób, aby Twój zespół całkowicie stracił zainteresowanie projektem i wtedy masz poważne kłopoty.

Zamiast tego spróbuj odwrotnie. Powiedz zespołowi, że mogą robić, co chcą, a jako kierownik / lider (jeśli jesteś jednym z nich, jeśli nie, spraw, aby kierownik powtórzył te słowa), Twoim zadaniem jest upewnienie się, że są tak produktywni i szczęśliwi, jak to możliwe. Proces nie jest złą rzeczą, ale proces powinien być po to, aby pomóc zespołowi, gdy zdaje sobie sprawę, że potrzebuje jednego, a nie na odwrót.

Jeśli niektórzy członkowie twojego zespołu wolą pracować w izolacji, pozwól im (do pewnego stopnia). Jeśli wolą pracować w parach, pozwól im to zrobić. Upewnij się, że Twoi ludzie wybierają swoją pracę tak często, jak to możliwe.

Wreszcie jest to bardzo ważne i zawsze jest pomijane. NIE OTRZYMASZ TEGO PRAWA (chyba że jesteś supermanem, a przynajmniej batmanem). Regularne spotkania retrospektywne są niezwykle ważne. Kiedy wprowadziliśmy retrospektywy, zrobili to zgodnie z książką i wydawało się, że to kolejny proces, przez który musicie usiąść. Nie po to jest retrospektywa. Służy do słuchania zespołu, identyfikowania obszarów, które powodują najwięcej bólu i ich naprawiania, aby każdy mógł kontynuować pracę. Najwyraźniej inżynierowie oprogramowania, którzy lubią dostarczać produkty i funkcje, a najważniejsze przesłanie retrospektywne, które musi się komunikować, polega na tym, że służy to wyłącznie ich korzyściom. Chcesz identyfikować i pokonywać przeszkody, zaczynając od największych (lub najłatwiejszych tam)

Spotkaj się z zespołem, pokaż listę rzeczy do zrobienia i zapytaj, kto chce co robić.

Nie myśl w modułach. Pomyśl o elementach funkcjonalnych. Opisz te elementy funkcjonalności według historii użytkowników (lub w inny sposób) i nie zapomnij opisać kryteriów akceptacji (prawdopodobnie określonych przez twoją obecną aplikację i zmiany, których oczekuje firma). Umieść swoje elementy funkcjonalne w zaległościach. Następnie pozwól, aby firma ustaliła, które funkcje należy dostarczyć w pierwszej kolejności (będziesz pracował przyrostowo i iteracyjnie, a priorytet powie Ci, co należy najpierw wdrożyć).

Gdy masz to przynajmniej część oryginalnej aplikacji, jesteś gotowy do rozwoju. To, co będzie dalej, zależy od wybranej metodyki zwinnej. Ważną częścią jest to, że każdą funkcjonalność można zwykle podzielić na wiele zadań, a członkowie zespołu wybiorą zadania, które chcą wykonać - nazywa się to samoorganizacją. Kiedy zaczynasz od zwinnego, samoorganizacja może potrzebować pomocy, gdy ktoś upewni się, że niepopularne i popularne zadania są równo dzielone przez zespół. Gdy zespół stanie się bardziej dojrzały, programiści nie zawahają się wyrazić sprzeciwu wobec obecnej samoorganizacji, co zostanie automatycznie rozwiązane w zespole.

Myślenie w modułach od samego początku nie musi być dobrym sposobem. Z jakiegoś powodu przepisujesz aplikację i być może obecna architektura aplikacji oparta na nieprawidłowym rozdzieleniu modułów jest jedną z ukrytych przyczyn widocznych problemów. Ponadto można zauważyć, że niektóre funkcje istniejących modułów zostaną całkowicie przedefiniowane i przeniesione w inne miejsce.

Chociaż zgadzam się z odpowiedzią Davida, czułem, że przydałoby się to trochę rozwinięcia:

• Zwinny oznacza, że ​​nie podejmujesz tych decyzji i nie wpychasz ich do zespołu. Nie ma takiego kierownika / lidera projektu. Tylko zespół.
• Ci, którzy najlepiej wiedzą, jak dzielić pracę, to sami członkowie zespołu.
• Omów swoje zaległości i dowiedz się, co chcesz zrealizować w następnej iteracji / sprincie.
• Użyj planowania pokera lub podobnych metod, aby dowiedzieć się, ile pracy i tak zamierzasz podzielić, a dopiero potem zacznij dzielić rzeczywiste pakiety pracy razem .

Zasadniczo, podstawową kwestią jest: nikt tutaj w SE nie może odpowiedzieć na to pytanie, ani nie ma na to większego sensu, ponieważ znacznie lepiej jest, jeśli wymyślisz odpowiedź jako zespół.

Najprostsze podejście jest często najlepsze.

Unikałbym dzielenia zadań na grupy, takie jak testowanie / log / UI / etc, chyba że można zdefiniować bardzo dobre i jasne powody tego. Moje rozumowanie jest takie, że jeśli pozwalasz programistom pracować poza zwykłymi obszarami specjalizacji, może to uczynić je bardziej interesującymi i stanowiącymi dla nich wyzwanie oraz pozwolić im się rozwijać i rozwijać w swojej dziedzinie. Jeśli uważasz, że ograniczenia czasowe wymagają podziału pracy opartej na wiedzy specjalistycznej, przynajmniej upewnij się, że każdy programista jest nadal zobowiązany do przeprowadzenia własnych testów jednostkowych, a także przejrzyj kod i testy akceptacyjne, aby wykryć problemy. Pisanie własnych testów jest bardzo zwinne, a czekanie na dostępność testerów może być bardzo marnotrawstwem.

W obliczu tego samego rodzaju dylematu zastosowałem następujące podejście:

• Zakres projektu. Pomyśl o tym, w co się pakujesz i opracuj listę funkcji, dzieląc projekt na szereg zadań.

• Określ priorytety funkcji. Zdecyduj, które funkcje muszą zostać ukończone wcześniej, a które zapewnią natychmiastową wartość Twoim klientom. Nie martw się, jeśli twoi programiści będą pracować na tych samych modułach, ale upewnij się, że masz dobry proces i narzędzia do zarządzania scalaniem kodu.

• Zaangażuj swój zespół i poproś programistów o pomoc w podzieleniu funkcji na listę łatwiejszych zadań. Przejrzyj jako grupę i dostosuj zadania zgodnie z potrzebami, aby można je było łatwiej oszacować.

• Poproś każdego programistę, aby wybrał zadanie do wdrożenia - lub grupę zadań w zależności od tego, jak będą przebiegać Twoje iteracje - z góry kolejki priorytetowej, nad którą programista chciałby pracować.

• Niech każdy programista będzie pracował tylko nad jedną rzeczą, dopóki nie zostanie ukończony, zanim przejdzie do wybierania następnego elementu z góry kolejki priorytetowej. Możesz mieć ochotę od czasu do czasu zmieniać zadania, ale doprowadzi to do marnowania czasu dewelopera. Jeśli natrafisz na wąskie gardła w zależnościach, musisz dostosować priorytety zadań i zminimalizować straty.

• Nie obawiaj się, że programiści będą działać z nakładającymi się iteracjami i odpowiednio zarządzaj swoimi wydaniami. Pomoże to zminimalizować straty czasu między wydaniami, czekając na zakończenie zadań.

Ostatecznie bycie zwinnym polega na znalezieniu rozwiązania, które dobrze sprawdza się w zespole, firmie i klientach. Do ciebie należy dostrojenie procesu poprzez znalezienie równowagi praktyk, które będą dla ciebie najlepsze. Sposób podziału zadań będzie bardzo ważną częścią znacznie większego procesu, ale powinien być tak prosty, jak to tylko możliwe, aby zachęcić do dobrowolnego udziału i uniknąć trudnych do rozwiązania problemów związanych z procesem, które rozwijają się później.

Żadna dyskusja organizacyjna zespołu programistów nie byłaby kompletna bez wspomnienia zespołu chirurgicznego dr Freda Brooksa .

Podstawowa formuła to: jeden zespół chirurgiczny na jednostkę pracy

Definiowanie zespołu chirurgicznego

Koncepcja zespołu chirurgicznego opiera się na dwóch podstawowych ideach:

1. Mniej programistów jest lepszych na jednostkę pracy, ponieważ cross-talk zabija produktywność.
2. Deweloperzy o wysokiej wydajności znacznie wyprzedzają programistów o niskiej wydajności (i według Brooksa nie ma czegoś takiego jak programista o średniej wydajności), więc lepiej dać im najważniejszą pracę do wykonania i ograniczyć ich rozproszenie.

Zespół chirurgiczny składa się z 3-10 programistów:

1. Główny programista. Wysokowydajny programista, który wykonuje większość rzeczywistego programowania.
2. Drugi pilot. Kolejny wysoko wydajny programista, który zajmuje się programowaniem, ale także zadaniami administracyjnymi, takimi jak uczestnictwo w spotkaniach i zbieranie wymagań.
3. 1-8 asystentów. Brooks opisuje je jako programistów odpowiedzialnych za takie rzeczy, jak dokumentacja, czyszczenie kodu, badania, narzędzia / algorytmy pisania, testowanie itp. W latach 60. Brooks zaproponował dokładnie 8 ról, ale z nowoczesnymi narzędziami możesz potrzebować zaledwie 1 lub 2, a prawdopodobnie powinien zostać przypisany na podstawie potrzeb twojego projektu.

Definiowanie jednostki pracy

Więc teraz, kiedy możemy stworzyć zespół, co im przypisujemy?

• Jeśli projekt jest bardzo mały , jest to łatwe. Przypisujesz jeden zespół chirurgiczny do całego projektu.
• W przeciwnym razie musisz zacząć od osoby lub zespołu odpowiedzialnego za architekturę całego projektu . Ich zadaniem będzie odpowiednia modularyzacja oprogramowania, aby można było podzielić pracę na dodatkowe podgrupy. Zespół achitecture może również podjąć inne prace, aby nie rozprowadzać programistów zbyt cienko.

Powinieneś zobaczyć trzy podstawowe, akceptowalne wzorce:

1. Dokładnie 1 podgrupa dla każdej warstwy (interfejs użytkownika, DAL itp.)
2. Dokładnie 1 podgrupa dla każdego modułu (strona główna, strona pomocy technicznej, sklep)
3. Połączenie tych dwóch (zespół niskiego poziomu i zespół skoncentrowany na interfejsie użytkownika dla każdego modułu)

W zależności od liczby programistów i modułów (i harmonogramów) generalnie wybieram moich programistów do wyboru jednego interesującego modułu (dla nich) i jednego trudnego modułu (najlepiej czegoś, czego nie zrobili), a następnie resztę dzielę według poziomu umiejętności i ograniczenia czasowe. Uważam, że daje to moim programistom coś, nad czym chcą popracować, i coś, co ich popycha.

Oczywiście to nie zawsze działa ...

Oto co bym zrobił:

Jeśli wszystkie moduły są małe, możesz dać każdemu modułowi do pracy. W przeciwnym razie wykonaj następujące czynności:

1. Określ każdy rozmiar modułu, złożoność, umiejętności wymagane do tego.
2. Zdefiniuj umiejętności każdego członka zespołu.
3. Określ, którzy ludzie dobrze ze sobą współpracują, a którzy nie.
4. Przypisuj duże moduły zespołom ludzi, które dobrze ze sobą współpracują w oparciu o wymagania dotyczące umiejętności modułu i umiejętności zespołu.
5. Przydziel pozostałe moduły osobom, które nie mogą dobrze współpracować z innymi ludźmi na podstawie wymagań dotyczących umiejętności modułu i umiejętności zespołu.

Powyższe nie zadziała, jeśli osoby, które nie lubią pracować z innymi, są najbardziej sprawne i jest to częsty przypadek, więc zrób wyjątek odpowiednio do 4 i 5