Zbyt wielu seniorów w jednym zespole? [Zamknięte]

15

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ć?

TheBoyan
źródło
Czy jest jakiś architekt? Zbyt wielu deweloperów alfa potrzebuje kogoś ponad nimi, koordynującego cały „kreatywny” potencjał ;-). Ostatnim razem, gdy pracowałem nad projektem z tyloma seniorami, pierwszym miesiącem był hilarius. Było zbyt wiele „refaktoryzacji” i „przeprojektowania”, ponieważ zbyt wiele „kreatywnych” punktów widzenia :-)
Laiv

Odpowiedzi:

40

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!

Stephen Bailey
źródło
1
To prawda, Sr. Devs nie mają prowadzić, ale często mają jakąś główną odpowiedzialność. To może się różnić w zależności od organizacji ...
FrustratedWithFormsDesigner
10
Zgodzić się! Prawdziwy specjalista ds. Oprogramowania powinien posiadać umiejętności i dojrzałość zawodową, aby móc wchodzić i wychodzić z pozycji kierowniczych zgodnie z potrzebami organizacji. Zespół prawdziwych seniorów działa bardziej jak zespół jazzowy niż orkiestra.
bit-twiddler
O! Oto odpowiedź, którą starałem się napisać wcześniej, ale nie mogłem całkiem się skupić. +1
pdr
10

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.

Czy może to prowadzić do zbyt dużej filozofii i dyskusji na temat pomysłów?

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.

Bill jaszczurka
źródło
Również wartość edukacyjna seniorów jest zmniejszona przez fakt, że nie mają oni nikogo do nauczania.
Basilevs,
7

Czy zbyt wielu starszych programistów w jednym zespole może okazać się czymś złym?

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.

Jim G.
źródło
7
Tylko zespoły, w których senior oznacza „pięć lat doświadczenia”, potrzebują „głównego chirurga”. Wszyscy w moim zespole mają ponad czterdzieści lat. Używamy modelu w pełni opartego na współpracy, aby podzielić projekt. Jesteśmy jak zespół jazzowy.
bit-twiddler
2
Schemat zespołu chirurgicznego może działać dla jednego lub dwóch projektów, podobnie jak mikrozarządzanie. W rzeczywistości mikrozarządzanie jest często najlepszym podejściem, jeśli zależy Ci tylko na krótkoterminowości. Jednak na dłuższą metę ostatecznie prowadzi to do zdemoralizowanych pracowników, którzy nie są kwestionowani do poziomu umiejętności. Wtedy najlepsi pracownicy odejdą na lepsze możliwości, a leniwi i mniej kompetentni pozostaną, ponieważ dość łatwo jest wykonać pracę, gdy powie się ci dokładnie, co robić bez konieczności samodzielnego myślenia.
Dunk
1
I czy można słusznie założyć, że postrzegasz siebie jako głównego chirurga?
William Pietri,
3

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.

FrustratedWithFormsDesigner
źródło
2
Każdy praktykujący oprogramowanie w moim zespole ma jednakową odpowiedzialność i równy autorytet. Jesteśmy małym, ale bardzo doświadczonym zespołem, który wykonuje prace znacznie większego zespołu mieszanego.
bit-twiddler
1
Jeśli programiści nie wiedzą, jak współpracować, bez potrzeby definiowania domen, nie są jeszcze starszymi członkami.
William Pietri,
3

Czy zbyt wielu starszych programistów w jednym zespole może okazać się czymś złym?

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.

Kevin Cline
źródło
2

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.

JB King
źródło
2

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.

Randy Coulman
źródło
2
Moim skromnym zdaniem tytuł „seniora” oznacza również poziom dojrzałości zawodowej.
bit-twiddler
Jeśli starsi programiści są aroganccy i kłótliwi, będą źli w każdym zespole. Jest to po prostu bardziej oczywiste w przypadku innych starszych deweloperów, ponieważ wiedzą, że nie znoszą bzdur.
William Pietri,
1

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:

  • który zepsuł kompilację (która przez większość czasu była zielona i technicznie nie została zepsuta. UI nie działał często bardzo często z powodu złych rozwiązań architektonicznych)
  • dlaczego występują regresje (moduły nie były objęte testami jednostkowymi, do których nie mieliśmy dostępu, aby się przyczynić)
  • spieranie się o rozwiązanie architektoniczne w module, za które odpowiedzialność ponosi ktoś inny, nie wiedząc nic na temat wymagań i specyfiki modułu.
  • ...

Ale przyznaję, że był to raczej wyjątek. Chcę wierzyć, że seniorzy zachowują się właściwie przez większość czasu :)

altern
źródło
Osoba, którą opisujesz, nie jest wystarczająco dojrzała, aby uznać ją za osobę wyższą, nawet jeśli ma to stanowisko.
bikeman868