Jak to jest pracować w dużym zespole programistycznym?

Zawsze miałem szczęście pracować w małym zespole programistycznym. Myślę, że najbardziej pracowałem z 11 programistami. Jak to jest pracować nad projektem z setkami programistów? Tysiące? Co to jest skala, a co nie?

EDYCJA: Dzięki za wszystkie odpowiedzi! Wydaje się, że jest bardzo mało pozytywów:

• możliwa praca na bardzo dużych bazach kodów
• lepszy wewnętrzny rozwój kariery
• ochrona pracowników przed nadużyciami w zarządzaniu (jest to bardziej -ve dla małych niż + ve dla dużych)

Czy są jakieś inne korzyści dla dużych zespołów?

Uważam, że skala biurokracji jest naprawdę dobra.

Poza tym nie za dużo. Duże projekty mają duże zespoły, ponieważ nie ma innego wyjścia, nie dlatego, że jest bardziej wydajny (na programistę). Płacisz koszt, jak tylko dodasz drugą osobę do miksu pod względem nieefektywności (tj. Transferu wiedzy i komunikacji).

Największy projekt, nad którym pracowałem, miał około 70 deweloperów w 5 różnych witrynach. Nawet zmiana jednej linii zajęła minimum dzień, chociaż było to częściowo spowodowane faktem, że kompilacja trwała ponad 45 minut przez łącze sieciowe z Zurychu do Londynu, a uruchomienie aplikacji trwało kolejne 45 minut. Zameldowanie zajęło około 5 minut na plik. Nie żartuję. Londyńscy programiści mogli to zrobić w ułamku czasu.

W każdym razie często zdarza się, że przy dużych projektach masz grupę członków zespołu, z którymi nie wchodzisz zbyt często w interakcje. To bardziej jak luźno powiązana kolekcja mini projektów. Kiedyś przeczytałem, że rozwój Microsoft miał tendencję do dzielenia projektów na zespoły 5-7 programistów, nawet w przypadku dużych projektów, takich jak Microsoft Office.

Częścią różnicy jest także różnica między małymi i dużymi firmami: większe mają zwykle więcej procesów, więcej zasad, mniejszą elastyczność i tak dalej. Ale to wcale nie jest gwarantowane.

Może to być dobre dla rozwoju kariery. W małej firmie ktoś musi odejść lub umrzeć, zanim będzie można uzyskać awans (lub firma musi się rozwijać tak, że zespół się powiększa, a ty przesuwasz się w górę), podczas gdy w większych działach deweloperów możesz przemieszczać się między zespołami i tak dalej.

Ponadto czasami można znaleźć naprawdę inteligentnych ludzi, z którymi można się przywiązać i uczyć. W małych firmach izolacja i samowystarczalność mogą sprzyjać programistom nieco „dziwnym”, trochę jak pustelnik.

Uważam, że komunikacja jest największą rzeczą, która zaczyna się pogarszać wraz ze wzrostem liczebności zespołu. Trudniej jest uzyskać komunikację i trudniej jest upewnić się, że wszyscy są na tej samej stronie. Pracuję pośrednio w zespole około 75 programistów, używamy wspólnej bazy kodu, ale wielu z 75 dzieli się na mniejsze grupy dla poszczególnych „działań”. Dla nas komunikacja to tylko koszmar.

Zarządzanie większymi grupami jest również trudniejsze, ponieważ w większości środowisk po 8-12 osób angażują się dodatkowi członkowie kierownictwa, co niestety przesadza z problemem komunikacji, ponieważ zwykle tworzy środowisko typu „silos”, w którym poszczególne podzbiory zaczynają się odrywać duża grupa i staraj się zachować wiedzę w ich grupie.

Kiedy tworzyłem oprogramowanie dla systemów uzbrojenia, mieliśmy DUŻE zespoły programistów. Ponieważ żadna osoba nie może owinąć głowy wokół wymagań (niektóre z nich zostały sklasyfikowane), chodziło tylko o zespoły i sposób, w jaki zespoły współdziałały ze sobą.

1. Zarządzanie konfiguracją - nocny proces kompilacji - było bardzo ważną sprawą. W tamtych czasach potrzeba było dużego klastra przetwarzania rozproszonego, aby co noc rekompilować świat.

2. Zezwolenia na pracę - i naliczanie czasu na właściwy element zamówienia w ogólnym harmonogramie projektu głównego - były dużym utrapieniem. Do 0,1 godz. przyrosty.

Ale największą ofertę stanowiło powiadomienie o zmianie. W szczególności zmiany interfejsu.

To było tak ważne, że wymyślili ten szalony dwuwarstwowy proces. Większość wysiłku włożono w upewnienie się, że Żądanie powiadomienia o zmianie interfejsu (nie samo powiadomienie, ale prośba o powiadomienie) zawierało rozbudowane oprogramowanie pomocnicze z bazą danych i raportami.

Po zatwierdzeniu wniosku faktyczne powiadomienie było mniej więcej oczywiste. Oznacza to, że tak naprawdę był to proces jednowarstwowy, a żądanie było skutecznie zawiadomieniem. Ale kiedy tworzysz wodospad, wszystko musi być przemyślane na długo, zanim pojawią się deweloperzy.

Przy tak wielu ludziach pracujących równolegle istniała płyta sterowania konfiguracją. Wszyscy różni menedżerowie zespołów, a także grupa ludzi, których zadaniem było po prostu koordynowanie zmian.

Moim pierwszym „prawdziwym” zadaniem programowania była współpraca z armią i innymi w celu opracowania międzynarodowych systemów kontroli ruchu lotniczego. Było to bardzo udane przedsięwzięcie i zostaliśmy uznani za środowisko 5 poziomu model dojrzałości zdolności. Od tego czasu jestem w średnich i małych sklepach. Więc jakie jest najlepsze miejsce? Osobiście każdego dnia przeniósłbym mniejszy sklep na duży. Chociaż niektórzy mogą uznać Poziom 5 za Świętego Graala, dla mnie był on duszący. Wszystko musi być udokumentowane, zatwierdzone, wyrejestrowane itp. Nie zrozumcie mnie źle, z pewnością dostrzegam w tym wartość, szczególnie w przypadku systemów tak krytycznych jak kontrola ruchu lotniczego, ale pytanie brzmi: jak chcesz wydać dzień? Czy chcesz mieć możliwość wymyślania różnych rzeczy, a następnie ich wdrażania, czy chcesz napisać do wymagań? Być może gdybym pozostał dłużej z systemem ATC, mógłbym wzrósł do poziomu umiejętności projektowania i rozwoju, ale nawet to wymagało X lat, Y zatwierdzeń, Z promocji - wszystko dobrze przepisane bez szans na odchylenie. To było duszne.

I na koniec, ogólnie rzecz biorąc, uważam, że jakość programistów jest znacznie wyższa w mniejszych firmach tylko dlatego, że nie mogą się ukryć. Nie jest trudno być przeciętnym w bardzo dużej firmie, ale staje się boleśnie oczywiste w małej i często nie trwa długo.

Pracowałem (krótko) w organizacji z co najmniej setkami programistów. Ale oczywiście (?) Organizacja jest wewnętrznie podzielona na partycje, abyś jako pojedynczy pracownik nie miał bezpośredniego kontaktu ze wszystkimi innymi, co byłoby bardzo trudne do nadążenia.

W tym konkretnym miejscu oprogramowanie zostało podzielone na komponenty, z zespołami utworzonymi wokół komponentów. Niektóre zespoły pracowałyby tylko z jednym (dużym) komponentem, podczas gdy wiele zespołów było odpowiedzialnych za kilka (mniejszych) komponentów.

Oczywiście oznacza to wszystko, co robi praca z bardzo dużą bazą kodu; rzeczy takie jak zarządzanie konfiguracją, budowanie, integracja itd. stają się ważnymi, dużymi rzeczami, które z kolei są tworzone przez wyspecjalizowane działy. I podziwiasz ich za to, że są w stanie zebrać wyniki wszystkich działów programistów i regularnie (raz w tygodniu, gdzie pracowałem) zintegrować wszystko razem w jedną spójną całość, która faktycznie działała.

Nigdy nie pracowałem dla dużego zespołu programistów , ale rezultatem powiększania się organizacji są zwykle więcej reguł. Nie zawsze jest to zła rzecz! Oprócz zasad, które utrudniają życie każdemu, istnieje również więcej zasad chroniących pracowników i zapewniających dobry proces.

Widziałem, jak menedżerowie w małych organizacjach uciekają przed rzeczami, które natychmiast spowodowałyby ich zakończenie przez dział HR przedsiębiorstwa.

Jedyną różnicą, którą zauważyłem przy dużych projektach, jest polityka biurowa. Im większe projekty, tym bardziej dominująca jest polityka.

Moim pierwszym projektem poza szkołą było kilkuset programistów. Jako zarozumiały i naiwny programista, świeżo po szkole, naprawdę nie byłem na to gotowy. Jedyną rzeczą, która uratowała mi hiney (i jest to jedyna rzecz, która nigdy naprawdę cię chronić) była ilość znajomych zrobiłem.

To największa lekcja, jaką z tego wyciągnąłem. Staraj się zaprzyjaźnić ze wszystkimi . Nawet szarpnięcia. W szczególności, jeśli masz szansę na chwilę przerwać pracę i porozmawiać z kimś, z kim nigdy wcześniej nie rozmawiałeś, zrób to.

Raz spędziłem rok pracując w zespole z ponad 500 osobami, z których około 200 było programistami. Dostarczaliśmy EOA, integrując kilka różnych rozwiązań SOA.

W praktyce było od 30 do 50 zespołów, każda z różną liczbą programistów (3 w naszym zespole), każdy odpowiedzialny za inny aspekt ogólnego rezultatu.

Największy zespół, nad którym kiedykolwiek pracowałem, liczył około 15 osób (było to tylko 3 lub 4 miesiące w innej firmie). Byłem kierownikiem technicznym zespołu i zabrałem się do pracy o siódmej rano, dostałem 2 godziny, zanim wszyscy inni wezmą udział, był to jedyny sposób na wykonanie dowolnego z moich własnych zadań.

Nie chciałbym pracować w zespole z więcej niż 8 lub 10 programistami, 15 było o wiele za dużo dla jednego zespołu (zespół mógł łatwo zostać podzielony na dwa, niestety nie mój telefon), 3 lub 4 deweloperów to ładny wygodny rozmiar IMHO