Czy zbyt wielu starszych programistów w jednym zespole może okazać się czymś złym?
Po powiedzeniu 4-5 starszych programistów w zespole 6-7 osób. Jaka jest optymalna liczba / stosunek w tego rodzaju sytuacjach?
Czy może to prowadzić do zbyt dużej filozofii i dyskusji na temat pomysłów?
Czy ktoś miał takie doświadczenie, które może się ze mną podzielić?
Odpowiedzi:
Gdybym mógł wybrać, miałbym 6-7 seniorów w zespole (zakładając, że projekt potrzebuje tylu).
Jedyny raz widzę, że jest to problem, gdy seniorzy są starsi w postrzeganiu siebie, a nie etyce pracy.
Nie ma nic lepszego niż praca z grupą ludzi, którzy doceniają to, że każdy element tworzenia oprogramowania jest ważny - dokumentacja, planowanie, kod, kawa, to wszystko ma znaczenie, a dojrzali (prawdziwi starsi) programiści są „wyżej” nic ”i odpowiednio wykonać pracę.
EDYCJA : Wiele innych odpowiedzi mówiło, że zbyt wielu liderów stanowi problem - ale dlaczego istnieje przekonanie, że senior musi przewodzić? Senior powinien być wystarczająco dojrzały, aby wybrać lidera i podążać za nim. Liczy się projekt - wybierz / zdobądź rolę i głupio!
źródło
Największym problemem, jaki widzę przy ładowaniu zespołu ze starszymi programistami, jest to, że może osłabić inne zespoły. Jeśli masz młodszych programistów w innych zespołach, którzy potrzebują mentoringu i wskazówek, być może trzeba będzie zmieniać ludzi.
Pewnie, że można , ale powinny być one wystarczająco dojrzałe, aby poznać różnice znaczenia i co z nich po prostu nie. Jeśli wyznaczyłeś szanowanego lidera zespołu, tego rodzaju argumenty filozoficzne należy ograniczyć do minimum przy niewielkim wysiłku.
źródło
Zdecydowanie.
Jestem wielkim zwolennikiem schematu zespołu chirurgicznego Freda Brooksa .
Biorąc to pod uwagę, jeśli seniorzy w zespole deweloperskim nie wiedzą, kim jest „główny chirurg”, będą sprzeczać się z ważnymi decyzjami architektonicznymi i będą podążać w różnych kierunkach ze szkodą dla zespołu.
PS Zapotrzebowanie zespołu programistów na „głównego chirurga” jest podobne do zapotrzebowania orkiestry na dyrygenta. W obu przypadkach prawdopodobnie będziesz mieć wielu weteranów; ale będziesz miał niezły bałagan bez jednej osoby, która jest bezsprzecznie odpowiedzialna.
źródło
Zależy to od tego, jak dystrybuowane są elementy odpowiedzialne. Jeśli WSZYSTKIE starsze deweloperzy mają mieć taką samą odpowiedzialność za projektowanie, przegląd kodu itp., To może to stać się problemem. Jeśli powierzono im różne obowiązki, tak aby mogli pracować bez walki o kontrolę nad domenami innych osób, nie powinno to stanowić problemu - na przykład jeden Starszy deweloper ponosi główną odpowiedzialność za projektowanie, a drugi odpowiada za konfigurowanie i utrzymywanie repozytorium źródeł, inny będzie odpowiedzialny za testy jednostkowe itp.
źródło
Niekoniecznie. Pracowałem w małych zespołach starszych programistów, którzy byli bardzo produktywni. Poziom dyskursu był bardzo wysoki i nie było urazy.
Dzięki TDD istnieje bardzo niewiele dużych zobowiązań dotyczących architektury oprogramowania, więc nie trzeba się o nie kłócić. Decyzje projektowe można rozwiązać, po prostu wdrażając oba podejścia i sprawdzając, które z nich działa najlepiej. Ponieważ programiści są bardzo szybcy, koszt tych prób jest bardzo niski.
źródło
Tak, może występować problem posiadania zbyt dużej liczby kucharzy w kuchni dla jednej metafory, która może mieć zastosowanie. Może to być również dość kosztowne, jeśli wszyscy oczekują wysokich wynagrodzeń. Zauważ, że jest to tylko weryfikacja istnienia złego przypadku i nic nie mówi o jego prawdopodobieństwie.
Optymalne zależy od wielu zmiennych, których nie ujawniasz. Jakich wskaźników chcesz użyć, wiedząc, że istnieje duża szansa, że niektóre gry tutaj będą dostępne. Podobnie, jakie masz ograniczenia w swoim świecie, które mogą odróżniać go od tego, co Google lub Microsoft może mieć w przeciwieństwie do tego.
Zbyt wielu starszych programistów może mieć problem z brakiem konwencji lub zbyt wieloma konwencjami. Podczas gdy niektórzy starsi programiści mogą być dobrzy w adaptacji, jeśli żaden z nich prawdopodobnie nie wprowadzi konwencji, to gdzie miałby zacząć zespół? I odwrotnie, niektórzy starsi programiści są zagorzałymi fanami niektórych konwencji, które mogą wymagać rozwiązania konfliktu w celu ich rozwiązania.
źródło
Myślę, że to zależy od osobowości seniorów. Jeśli są aroganccy i kłótliwi, może to być zła rzecz. Ale jeśli wszyscy są pełni szacunku, otwarci na inne punkty widzenia i chętni do uczenia się od siebie, masz świetny zespół.
Obecnie pracuję w 8-osobowym zespole, w którym 5 lub 6 osób jest starszych, i to działa naprawdę dobrze dla nas. Dobrze się dogadujemy, uczymy się od siebie i jest to świetne środowisko mentorskie dla nowszych facetów, których mamy.
źródło
Pracowałem w zespole, w którym było 1 główny programista, 4 starszych programistów i 1 średni programista. I z powodu tego, że jeden „starszy” członek zespołu nie był naprawdę dojrzałą osobą (choć dobrym deweloperem), okazało się, że to koszmar. Cały czas próbował (domyślnie lub jawnie) udowodnić, że inni członkowie zespołu nie są wystarczająco starsi. Nie zrozumiał także podstawowych zasad tworzenia oprogramowania i specyfiki naszego produktu, dlatego arogancko i uparcie próbował udowodnić, że ma rację. W rezultacie poważnie wpłynęło to na efektywność zespołu. Smutne jest to, że nie był to nawet zbyt duży spór o pomysły / rozwiązania - był to spór o nic . Na przykład:
Ale przyznaję, że był to raczej wyjątek. Chcę wierzyć, że seniorzy zachowują się właściwie przez większość czasu :)
źródło