Co stało się ze wzorem „Zespołu chirurgicznego” z „Mitycznego miesiąca człowieka”?

164

Wiele lat temu, kiedy czytałem The Mythical Man-Month, znalazłem wiele rzeczy, które znałem już z innych źródeł. Pojawiły się jednak nowe rzeczy, mimo że książka pochodzi z 1975 roku. Jedną z nich była:

Zespół chirurgiczny

Mills proponuje, aby każdy segment dużej pracy zajął się zespołem, ale aby zespół był zorganizowany jak zespół chirurgiczny, a nie zespół rzeźników. Oznacza to, że zamiast każdego członka eliminującego problem, jeden wykonuje cięcie, a pozostali zapewniają mu wszelkie wsparcie, które poprawi jego skuteczność i wydajność.

Jest to bardzo interesujący wzorzec organizowania zespołu programistów, ale nigdy nie znalazłem go opisanego w żadnej innej książce o inżynierii oprogramowania, nawet nigdzie nie wspomnianej.

Dlaczego?

  • Czy wtedy „zespół chirurgiczny” był nawet niezwykły?
  • Czy też próbowano i nie powiodło się?
    • Jeśli tak, jak to się nie udało?
    • Jeśli nie, dlaczego nie widzimy tego wzorca zaimplementowanego w dzisiejszych projektach oprogramowania?
vog
źródło
12
Powiedziałbym, że może to przynieść tylko oparte na opiniach odpowiedzi. Moim skandalicznym zdaniem jest to, że żaden „inżynier oprogramowania” nie chce być postrzegany jako rola „wsparcia”. Chcą być postrzegani jako równi wszyscy inni w zespole. Może to być związane z faktem, że większość programistów jest wyjątkowo młoda. Większość zespołów nie ma nikogo, kto mógłby ubiegać się o staż pracy i być uważany za „chirurga” zespołu.
Euforia
43
Potencjalnym problemem, który widzę, gdy celowo próbujesz zorganizować zespół w ten sposób, jest prawidłowe określenie, kim powinien być chirurg.
Bart van Ingen Schenau
9
@Euphoric Nie zapomnij o niektórych menedżerach, którzy łudzą się, że mają już programistę super-uber-guru-gwiazdy-chirurga, więc po co zatrudniać tych wszystkich chłopów wspierających? Widziałem moją grupę mgrów, którzy nie wykazywali dowodów na zrozumienie rozwoju oprogramowania i związanych z nim wyzwań podczas „zarządzania” zespołami oprogramowania, lub znacznie więcej poza ich kolorowymi arkuszami kalkulacyjnymi Excel, niestety (zwykle, choć nie zawsze, ludzie bliscy przejścia na emeryturę ).
code_dredd
7
Może mieć to coś wspólnego z faktem, że „chirurgia” jest jedną z najbardziej perspektywicznych dziedzin medycyny - w rzeczywistości jest to znany żart w Wielkiej Brytanii, że chirurdzy spędzają 7 lat na nauce, aby mogli zostać nazwani „lekarzami”, a następnie kolejne 7 lat, aby znów mogli zostać nazwani „Pan” lub „Pani”! W rzeczywistości reorganizacja chirurgii w celu poprawy jej działania poprzez stosowanie „najlepszych praktyk” innych branż o znacznie niższym poziomie błędu itp. (W szczególności lotnictwa cywilnego) jest ciągłym wysiłkiem w zawodzie lekarza. ...
alephzero,
6
@alephzero: To kilka zabawnych twierdzeń. Gdzie dokładnie ćwiczyłeś operację? Tutaj ilość bzdur, które nazywasz „najlepszą praktyką”, zajmuje większą część czasu chirurga i przynosi zerową korzyść. Super mądrzy ludzie [ironicznie] bardzo starają się ulepszyć coś, czego nie rozumieją, dodając do tego więcej biurokratycznych bzdur prawie co tydzień. Wręcz przeciwnie, przyczyny wspomnianego wskaźnika awaryjności nie zostały usunięte. Prawie wszystkie niepowodzenia wynikają z niedostatku snu, niedostatecznej edukacji i przeszacowania. Często wszystkie trzy razem.
Damon,

Odpowiedzi:

103

„The Mythical Man-Month” ukazał się w roku, w którym rozpocząłem studia, i użyłem obecnej wersji językowej UUUGE! :-) To, co musisz zrozumieć, to różnica w sposobie tworzenia oprogramowania NASTĘPNIE vs. TERAZ. Back In The Day (tm) prawie całe kodowanie zostało najpierw zrobione na papierze, a następnie zostało wciśnięte klawisze na (zgadłeś) kartach dziurkowanych, a następnie wczytane, skompilowane, połączone, wykonane, uzyskano wyniki i proces powtórzono. Czas procesora był kosztownyi ograniczone zasoby, a ty nie chciałeś ich zmarnować. To samo dotyczy miejsca na dysku, czasu napędu taśmowego itp., Bla. Marnowanie idealnie dobrego czasu procesora na kompilację, co skutkowało błędami (wstrząs i horror!), Było ... cóż, stratą idealnie dobrego czasu procesora. I to było w 1975 roku. W tym czasie Fred Brooks rozwijał swoje pomysły, a procesor od połowy do końca lat 60. był jeszcze większydrogie, pamięć / dysk / cokolwiek jeszcze WIĘCEJ ograniczone, itp. itd. Ideą zespołu chirurgicznego było zapewnienie, że One Super Great Rockstar Developer nie będzie musiał marnować swojego czasu na zwykłe zadania, takie jak sprawdzanie kodu biurka, uruchamianie klawiatury, przesyłanie zadań, czekanie (czasem godzinami) na wyniki. Rockstar Dude Developer Man miał być KODEM PISANIA. Jego legion groupies / urzędników / młodszych programistów miał robić rzeczy przyziemne.

Problem polegał na tym, że w ciągu 2 lat od opublikowania książki Brooks załamały się podstawowe idee zespołu chirurgicznego:

  1. Terminale CRT i pliki dyskowe zaczęły zastępować klawisze i talie kart. Czas na komputery stał się tańszy, stało się dostępnych wiele komputerów, a czas realizacji zadań znacznie się skrócił. Kiedy dostałem się na studia (Miami University, Oxford, Ohio, klasa '79, dziękuję za pytanie) dobrzezmiana pracy trwała około godziny. Podczas tygodnia finałów - może cztery godziny, czasem sześć. (Walczyliśmy o czas procesora z wieloma firmami komercyjnymi i uniwersytetami - a użytkownicy komercyjni otrzymali pierwszeństwo). Podczas mojego ostatniego roku, kiedy Miami wyszło z konfiguracji „wspólnego komputera”, zainstalowało na swoim kampusie IBM 370/145 i miałem fajne HP mini, nad którym pracowałem, które działało jako stacja RJE, którą mogliśmy zmienić na mainframe miejsc pracy w około pięć minut lub krócej. Teraz warto było wbić kod w HP, wysłać go z HP do komputera mainframe, przekręcić kciuki / zapalić papierosa i odzyskać wydajność na długo przed zakończeniem sprawdzania kodu na biurku.

  2. Zespół chirurgiczny opiera się na założeniu, że ty (lub „zarządzanie”, Boże, pomóż nam wszystkim) możesz zidentyfikować kolesia z zespołu Rockstar Surgical Developer. Wątpię, czy to możliwe. Tam Rockstar deweloperzy, każdy wie, że - badania wykazały różnice w wydajności pomiędzy najlepszymi i najgorszymi deweloperów aż o 2000% - ale identyfikację tej osoby bez konieczności pisania kodu je przez dłuższy okres czasujest najprawdopodobniej niemożliwe. Jedynym sposobem, aby dowiedzieć się, czy ktoś jest deweloperem rockstar, jest faktyczne opracowanie kodu - ale jeśli NIE jest to gość Rockstar Surgical Developer, robią ekscytujące rzeczy, takie jak sprawdzanie kodu na biurku, wciskanie go na karty i schlepping pudełka z dziurkowanymi kartami do działu Job Entry, a następnie stojąc i czekając na wyniki, aby mogli je schlepić z powrotem do pana Rockstar Surgical Developer Dude zamiast nauczyć się kodować jedyny sposób, który naprawdę działa - przez pisanie kodu, debugowanie kodu, itd. Back In The Day (tm) nie było konkursów programistycznych, nie było przepełnienia stosu, nie miałeś komputera, na którym mógłbyś pisać kod, kiedy tylko miałbyś na to ochotę, nie było książek o algorytmach dla idiotów - jedynym sposobem na naukę programowania było pójście do szkoły i specjalizacja w czymś, w czym trzeba trochę programować. Ale programowanieper se nie było traktowane poważnie i zakładano, że jest to coś, czego ludzie nie chcą robić . Na moim pierwszym kursie uniwersyteckim (SAN151 - Wprowadzenie do analizy systemów, dr Tom Schaber - dzięki, Tom :-) instruktor powiedział nam, że „... po prostu musieliśmy zmierzyć się z faktem, że musieliśmy wydać kilka lat jako programistów, zanim mogliśmy zostać analitykami systemów ”. „Dwa lata?”, Pomyślałem. „MUSZĘ TO ROBIĆ TYLKO NA DWA LATA?!?”. Byłem poważnie oszołomiony. Na szczęście się mylił i od tego czasu prawie koduję. :-)

  3. Zespół chirurgiczny zakłada, że ​​programiści są stosunkowo rzadkim zasobem. Zajęło to jeszcze kilka lat, ale wraz z pojawieniem się komputerów na początku lat 80. programowanie stało się czymś, w co mógł zaangażować się każdy maniak. Cena komputerów zaczęła spadać, cena narzędzi programistycznych zaczęła spadać, i to wszystko grad Turbo Pascal - według dzisiejszych standardów było niewiele, ale w tym czasie był to kompletny Pascal IDE za około 40 dolców, co było absolutnie szalone! Teraz KAŻDY mógł zająć się programowaniem - gdybyś mógł sobie pozwolić na komputer, a kiedy IBM postanowił umieścić PCjr (tak, mój pierwszy komputer był jednym z największych błędów IBM :-) w sprzedaży za około 500 USD, aby pozbyć się tych indyków, gotówki -pasujący geekowie na całym świecie pomijali swoje opłaty czynszowe na miesiąc („Taaa, wiem, ale ja ... złamałem moją uuvulę i musiałem mieć operację i ... .uh ... tak, w przyszłym tygodniu, nie ma problemu, dzięki, stary ...) i wyssałem ich po cenach sprzedaży ogniowej. Następnie wydaliśmy więcej niż zapłaciliśmy za komputer na dodatki, aby był on użyteczny. („Tak, stary, na pewno w przyszłym tygodniu prawdopodobnie…” :-).

Naprawdę zasmuciło mnie to, że nawet dzisiaj, jeśli zapytasz ludzi, czy kiedykolwiek przeczytali „Mityczny miesiąc człowieka” lub zrozumieli jego główną lekcję („Dodanie zasobów do późnego projektu sprawia, że ​​później”), dają ci puste gap - a następnie przystąp do popełniania dokładnie takich samych błędów, jakie popełniono przez całe te lata podczas opracowywania systemu OS / 360. Wszystko, co stare, znów jest nowe ...: -}

Bob Jarvis
źródło
20
Jeśli ktoś, kto to czyta, ma wydanie z okazji 20. rocznicy, warto przeczytać nową przedmowę i nowy rozdział 19. Chociaż nawet wydanie z 20. rocznicą ma ponad 20 lat od 2017 r., Autor wskazuje kilka twierdzeń w odpowiedź ta jest często pomijana w pośpiechu, aby podsumować całą książkę, ponieważ „dodanie inżynierów do już spóźnionego projektu powoduje, że jest jeszcze bardziej późno”.
1
Co na świecie oznacza „UUGE”? Nawiasem mówiąc, świetna odpowiedź.
Wayne Conrad,
5
@WayneConrad język ojczysty dla ogromnych .
zzzzBov
1
Mając już programista systemów IBM w tym okresie, było wspólne mają bardzo ściśle określone role w zespole, ze specjalizacją w danej części systemu operacyjnego. Oczekuje się, że osoba w każdej z tych ról będzie wiedzieć lub uczyć się wszystkiego, co można było o niej wiedzieć, i działać jako personel pomocniczy dla każdego z pozostałych ekspertów. Zasadniczo skończyliśmy z zespołem chirurgicznym na członka personelu, każdy z własną specjalnością.
Joe McMahon,
1
W odpowiedzi na Twój komentarz dotyczący wielokrotnego popełniania tych samych błędów artykuł w Wikipedii dotyczący książki zawiera cytat autora, który może Ci się spodobać: Tendencja kierowników do powtarzania takich błędów w rozwoju projektu skłoniła Brooksa do stwierdzenia, że ​​jego książka nazywa się „Biblia inżynierii oprogramowania”, ponieważ „wszyscy ją cytują, niektórzy ją czytają, a niektórzy ją czytają”.
Ryan
87

Istnieją pewne aspekty tej koncepcji, które czasami obecnie wdrażane, są też inne aspekty, których należy unikać .

Utrzymywanie małych drużyn jest jedną z podstawowych cech Metod Agile, ale jest również praktykowane poza Agile.

Zespoły interdyscyplinarne są również podstawową sprawnością Agile, ale są również popularne poza Agile.

Rola programisty jest w dużej mierze przejmowana przez systemy komputerowe, takie jak systemy kontroli wersji, systemy zarządzania konfiguracją oprogramowania, systemy zarządzania zmianami, systemy zarządzania dokumentami, wiki, systemy ciągłego budowania z repozytoriami artefaktów i tak dalej. Mam na myśli, czy naprawdę możesz sobie wyobrazić płacenie pracownikowi zatrudnionemu w pełnym wymiarze godzin za wydrukowanie kodu źródłowego oraz ręczne indeksowanie i archiwizowanie go?

Podobnie rola administratora systemu (nie należącego do zespołu chirurgów Millsa, ale część typowego zespołu wielofunkcyjnego ostatnich lat) jest przestarzała z powodu takich koncepcji jak DevOps (przejmowanie roli Sysadmina w roli inżyniera oprogramowania) , Platform-as-a-Service, Infrastructure-as-a-Service i Utility Computing (czyniąc rolę Sysadmin „czyimś problemem”) lub Infrastructure-as-Code (przekształcając Administrację Systemu w Inżynierię Oprogramowania).

Jednym z aspektów, których staramy się dziś unikać, jest to, że najwyżej dwie osoby rozumieją system. Tylko chirurg ma gwarancję pełnego zrozumienia systemu, drugi pilot może, ale nie musi. Daje to współczynnik autobusu od 1 do 2. Jeśli chirurg zachoruje, projekt jest martwy. Kropka. Zwinną odpowiedzią na to jest Collective Code Ownership, co jest dokładnym przeciwieństwem tego modelu: nikt nie jest wyjątkowo odpowiedzialny za jakąkolwiek część systemu. Zamiast tego wszyscy są odpowiedzialni za wszystko jako grupa .

Wreszcie, w tej koncepcji są pewne założenia, które są nieaktualne. Na przykład, mimo że nie jest to wyraźnie określone, zespół jest skonfigurowany w taki sposób, że tylko jedna osoba w zespole (chirurg) faktycznie ma komputer. Jest tak, oczywiście, ponieważ w momencie pisania artykułu nawet pomysł, że cały zespół miałby jeden komputer dla siebie, nie mówiąc już o jednej osobie w zespole, był trudny. (Nawet w 1980 r., Kiedy wydano Smalltalk, jedną z rzeczy, które przyczyniły się do jego awarii, był fakt, że system został skonfigurowany tak, że każdy programista i każdy użytkownik miał własny komputer - wówczas zupełnie nie do pomyślenia).

Krótko mówiąc: nie sądzę, aby koncepcja została wdrożona dokładnie tak, jak opisano, ale niektóre jej aspekty zdecydowanie zostały wdrożone, niektóre aspekty są postrzegane jako niepożądane i aktywnie omijane, niektóre są przestarzałe, a niektóre są prawdopodobnie Dobrymi Pomysłami ™, ale nikt tego nie robi.

Jörg W Mittag
źródło
1
Jeśli chodzi o akapit od drugiego do ostatniego, myślę, że chirurg miał pracować z piórem i papierem, a urzędnik byłby jedynym członkiem zespołu z dostępem do komputera.
Bart van Ingen Schenau
15
„czy naprawdę możesz sobie wyobrazić płacenie pracownikowi zatrudnionemu w pełnym wymiarze godzin za wydrukowanie kodu źródłowego oraz ręczne indeksowanie i archiwizowanie go? Nie, ale zdecydowanie mogę sobie wyobrazić płacenie pełnoetatowemu pracownikowi za zarządzanie kontrolą wersji i systemami ciągłej kompilacji, aw rzeczywistości w każdej średniej lub większej firmie jest to normą. W rzeczywistości zarządzanie stronami wiki, systemami zarządzania dokumentami i tym podobnym jest całkowicie odrębną, jeszcze większą rolą, że zwykle jest cały czas poświęcony pisarzom technicznym na pełny etat.
Miles Rout,
9
„cały zespół miałby jeden komputer dla siebie ... to był odcinek” - na początku lat 80. orgy miały system minikomputer + systemy terminalowe, więc chociaż był to ten sam komputer, użytkownicy nadal mieliby do niego dostęp na równym poziomie podstawa i zdolność do uruchamiania własnych programów (przy założeniu przyzwoitej izolacji użytkownika i bezpieczeństwa).
Dai,
2
Podczas gdy komputery były drogie w 1975 r., Skróty klawiszowe były dość tanie. Kiedy po raz pierwszy programowałem komputery mainframe (nie w wersji 75, ale 77), zapisywaliśmy kod na papierze, dziurawiliśmy go na kartach, dostarczaliśmy do furtki, a następnie okresowo sprawdzaliśmy, czy wydruk został dostarczony z powrotem. (Czas zawracania może wynosić dla nas 2 godziny, a na niektórych stronach więcej niż jeden dzień.) Urzędnik byłby bardzo przydatny do wszystkich zadań oprócz pierwszego. Nie widziałem terminali do około 1979 roku.
Theodore Norvell,
1
Re: Smalltalk - nie tylko każdy twórca i każdy użytkownik miał mieć własny komputer, te komputery miały być również potężnymi komputerami z dużą ilością pamięci i graficznym interfejsem użytkownika . Pomyśl „stacja robocza” zamiast „komputer”. Oryginalne komputery IBM nie miały mocy, by uruchomić Smalltalk. Cholernie wstyd, moim zdaniem ...
Bob Jarvis,
20

Kiedyś wykształcenie wyższe było czymś wyjątkowym, a inżynierowie byli jednymi z niewielu wybranych. Komputery były drogie, a zespoły pracowały nad projektami o określonym biznesowym RoI. Nie były to bardzo częste.

To, co się stało, to mikrokomputery, wszechobecna edukacja studentów i systemy komputerowe, które nawet nie potrzebują stopni naukowych, aby robić postępy. Ponadto zmieniła się ekonomia i rosły koszty pracy.

Ekonomia stosunku wsparcia 8: 2 do inżyniera nie ma już sensu. Inżynierowie muszą być własnym wsparciem. Współczesny człowiek z wystarczającym wykształceniem i umiejętnościami, aby być skutecznie związanym z zespołem programistycznym, jest zbyt drogi, aby nie robić własnego rozwoju.

(Powiązanym terminem ekonomicznym jest „choroba kosztowa sektora usług”).

Jon Watte
źródło
5
Odrzuciłem głos z powodu absurdalnego twierdzenia dotyczącego rosnących kosztów pracy. Siła robocza, nawet specjalistyczna wiedza inżynierska, jest dziś tańsza niż w 1969 r. Rzeczywiście, koszt dzisiejszej pracy jest podstawą całej tej odpowiedzi i jest to fałszywe twierdzenie.
RibaldEddie,
2
@RibaldEddie w odniesieniu do czego? Jeśli porównujesz siłę roboczą z kosztami utrzymania, spada ona; godzina pracy może przynieść ci więcej jedzenia / mieszkań niż w 1969 r.
k_g
3
@k_g cóż, to zależy od lokalizacji. Jeśli chodzi o inflację, w większości miejsc w USA można dziś zatrudnić programistę za mniej dolarów skorygowanych o inflację niż w 1969 roku. Dla odniesienia w książce Brooks sugeruje 20 tysięcy za to, co dziś uważalibyśmy za starszego architekta programistów i 10 tys. za uruchomienie programatora młyna, który wykonuje większość pracy. W dzisiejszych dolarach 10 tys. To około 65 tys. Dzisiaj większość deweloperów w twoim zespole zarabiających 65 tys. To bardzo dobra cena.
RibaldEddie,
3
Zasadniczo płace za oprogramowanie nie uległy zmianie od 1969 r. Biorąc pod uwagę ogólną inflację i wyższe koszty utrzymania, programiści są dziś znacznie tańsi.
RibaldEddie,
11
Rzeczywiście wszystkie korzyści płynące z nowoczesnego środowiska gospodarczego pod względem wydajności i tańszej siły roboczej trafiły do ​​klasy wykonawczej i akcjonariuszy w biznesie. Jak powiedziałem, nawet skorygowane o inflację, pensje programistów pozostały takie same, podczas gdy wynagrodzenie dla kadry kierowniczej wzrosło setki razy więcej niż inflacja. Ponadto w wielu miejscach, szczególnie wzdłuż zachodniego wybrzeża Ameryki Północnej, koszty utrzymania wzrosły znacznie szybciej niż inflacja (patrz nieruchomości), a jednak profesjonalne zarobki deweloperów ledwo nadążały za inflacją.
RibaldEddie,
13

Te wzory brzmią dla mnie bardzo podobnie do programowania Mob:

Cała grupa (QA, programiści, a nawet w razie potrzeby właściciel produktu) pracuje w tym samym czasie z tym samym problemem. Bez wstawania, wysoka komunikacja, bezpośrednio wdrożony na żywo.

Od http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Podstawowa koncepcja programowania mobów jest prosta: cały zespół pracuje jednocześnie jako zespół nad jednym zadaniem. To znaczy: jeden zespół - jedna (aktywna) klawiatura - jeden ekran (oczywiście projektor). To tak jak w programowaniu parami dla całego zespołu.

Zobacz to w akcji tutaj: https://www.youtube.com/watch?v=dVqUcNKVbYg

Chococroc
źródło
Ten cytat jest w zasadzie tym, o czym myślałem: brzmi to jak programowanie w parach, gdzie „chirurg” nazywamy „sterownikiem”, z wyjątkiem innej skali.
Izkata,
7
Wydaje mi się, że wymagałoby to od kompetentnych, zorientowanych na ludzi kompetentnych programistów. Powodzenia z tym.
Bob Jarvis,
Przybyłem tutaj, aby to powiedzieć; lub różne formy samoorganizacji zespołu.
Marcin,
2
@BobJarvis Nie zgadzam się. Odniosłem wielki sukces pracując w zespołach introwertyków (i myślę, że niektóre z nich obejmowały również ekstrawertyków). Kluczem jest stworzenie przestrzeni, w której ludzie czują się bezpieczni i otwarci na wniesienie wkładu i są gotowi na jakiś czas rozciągnąć swoje naturalne skłonności z korzyścią dla grupy. Susan Cain's Quiet była ogromną pomocą w zrozumieniu, jak dobrze pracować z różnymi temperamentami: ted.com/talks/susan_cain_the_power_of_introverts
David Carboni
12

Ten model zespołowy został ponownie wymieniony w Rapid Development - Taming Wild Software Schedules Steve McConnell na stronie 305. Tam nazywa się Zespół Głównego Programisty.

Ten model powstał, ponieważ zespół był geniuszem, a zasoby obliczeniowe były ograniczone. Wypadło to z łaski, ponieważ geniusz jest rzadki, a przy wszechobecnych komputerach i rozproszonej kontroli wersji mamy miejsce dla wielu rąk przy stole operacyjnym.

Inne referencje:

Baker, F. Terry. „Główny zespół programistów do zarządzania programowaniem produkcji”, IBM Systems Journal, vol. 11, nr 1, 1972, s. 56–73.

Baker, F. Terry i Harlan D. Mills. „Zespoły głównego programisty”. Datamation, tom 19, nr 12 (grudzień 1973), s. 58–61.

Matt Everson
źródło
9

Domyślam się, że większość małych samoorganizujących się zespołów i tak ma tendencję do przyjmowania de facto modelu zespołu chirurgicznego.

Ostatnie dwa zespoły, w których byłem, zwykle składały się z trzech lub czterech osób, zwykle jednej osoby starszej (chirurg), pośredniej (drugi pilot) i kilku juniorów / specjalistów. Niektóre z ról w zespole chirurgicznym, o których wspominają obecnie Brooks, są wypełniane przez mistrzów Scrum i administratorów systemów lub dostawców usług chmurowych. Pamiętaj, że kontrola źródła prawie wtedy nie istniała, nie mówiąc już o czymś tak potężnym jak git.

Pomyśl o zasadzie dwóch pizzy Bezosa. To właśnie twój samoorganizujący się zespół chirurgiczny.

RibaldEddie
źródło
1
więc w zasadzie nic się z tym nie stało. +
gordy
1
@gordy tak i nie. Zauważysz, że w przykładzie Potoka najprawdopodobniej od menedżerów zależeć będzie określenie, kto był w każdej roli w zespole, ale w nowoczesnej zwinnej koncepcji zespół sam się organizuje. Role chirurga lub drugiego pilota w naturalny sposób wypadają z pracy zespołu. Myślę, że to kluczowa różnica: samoorganizacja kontra dyktowanie firmy.
RibaldEddie,
Zmieniłbym „większość” na „niektóre”. To zależy od dynamiki zespołu. I zdecydowanie musi rosnąć organicznie, jeśli chirurg jest dyktowany z góry, wynik będzie nieoptymalny, więc +1 dla samoorganizacji.
Peter,
2
Powiedzenia z Tao oprogramowania: #IV - Tao pracy zespołowej: Dobre oprogramowanie jest pisane przez małe zespoły pracujące szybko. Złe oprogramowanie jest pisane przez duże zespoły pracujące powoli. Następstwa: - Optymalny rozmiar zespołu to 1; - Maksymalna praktyczna wartość dla wielkości zespołu wynosi 3; - W przypadku zespołów o wielkości> 3 (niewłaściwa) komunikacja staje się poważnym problemem; - W przypadku wielkości zespołu> 6 realizacja projektu staje się poważnie zagrożona. Zakończenie projektu w terminie najprawdopodobniej nie wchodzi w grę. W takich przypadkach mądrzejsi programiści skorzystają z drzwi ... Tak jest napisane ... ( BWOOoooonnnggggg !!! )
Bob Jarvis
6

Był artykuł od HP, który sugerował coś podobnego:

  • Każdy inżynier oprogramowania wymagałby wielu menedżerów i wielu osób wsparcia.
  • Dla każdego inżyniera powinien znajdować się pisarz techniczny, tester, menedżer kompilacji i producent narzędzi.

Artykuł był w czasach sprzed sieci i od czasu do czasu był przywoływany jako zabawny. Każdego roku, gdy był poruszany, komentarz zmieniał się nieco z „tak śmiesznego, że jest śmieszny” na „może powinniśmy to zrobić”.

Rzeczywiste testy są niezwykle trudne do zaprojektowania, więc prawdopodobnie nadal są opiniami. Mogą istnieć ankiety dotyczące projektów i wskaźników ich ukończenia.

Charles Merriam
źródło
9
To, co sprawia, że ​​się uśmiecham (?), To „... wielu menedżerów ...”. Jeden menedżer jest więcej niż wystarczający do zmniejszenia wydajności. Wielu menedżerów może doprowadzić programistów do myśli o samobójstwie (introwertycy) lub morderstwie (ekstrawertycy).
Bob Jarvis,
4
@BobJarvis - W zależności od projektu miałem aż pięciu jednocześnie „menedżerów” o różnych tytułach. Efekt jest taki, jak można sobie wyobrazić.
Rob Crawford,
1
Oczywiście jesteś ekstrawertykiem. Więc ... obrona szaleństwa? Meksyk? Lub… uzasadnione zabójstwo…? :-)
Bob Jarvis
Dlatego właśnie miałem pięciu szefów w jednej firmie. Gdy tam byłem, każdy problem, czy to mój, czy cudzy, słyszałbym o tym z 5 różnych perspektyw. Zwykle analizowałem go, zanim pojawiła się liczba 2, i było to po prostu denerwujące, gdy słyszałem o tym więcej razy.
Robert Baron,
Pierwotny pomysł nie polegał na tym, żeby „pięciu różnych menedżerów próbowało wtrącać się”, ale na przykład zapewnić „osobę do spraw HR” i „osobę do spraw rozwoju kariery HR” itp. Myślę, że wielu menedżerów działałoby, gdyby rozliczać się z działem każdego menedżera na podstawie jak często kontaktowali się z inżynierem. Byłaby fajna gra wideo!
Charles Merriam,
2

Zastanawiam się, jak bardzo potrzeba zespołu chirurgicznego stała się zbędna z powodu rozwoju Internetu, zintegrowanych środowisk programistycznych i zestawów programistycznych , które mogą przyjąć wiele funkcji przypisanych zespołowi chirurgicznemu Fredowi Brooksowi, w tym:

  • Chirurg: programista
  • Drugi pilot: sparuj programistów , współpracowników, społeczności online, takie jak StackExchange lub IRC
  • Administrator: rola zazwyczaj przejmowana przez kierownika projektu oprogramowania
  • Redaktor: IDE integrujące generatory dokumentacji, takie jak Javadoc lub Doxygen; dokumentacja z zestawów programistycznych
  • Sekretarz: klient poczty e-mail, narzędzia do zarządzania projektami, takie jak narzędzia do śledzenia problemów i żądania ściągania, firmowe czaty i listy mailingowe
  • Dyrektor programu: IDE przechowujący informacje o projekcie, z dodatkową możliwością zmiany kodu; dokumentacja i przykłady z zestawów programistycznych
  • Toolsmith: cała społeczność open source
  • Tester: natychmiastowe pakiety testowe i biblioteki testowe. Ale oczywiście kod produkcyjny wymaga osobnego procesu kontroli jakości.
  • Język prawnik: dokumentacja online, StackExchange
Gauraw
źródło
1

Myślę, że musisz przyjrzeć się założeniom Miesiąca Mitycznego Człowieka. Zatrudnienie większej liczby programistów tylko pogarsza problematyczny / opóźniony projekt oprogramowania. Problemem jest komunikacja i przyspieszenie prac nad nowo dodanymi programistami (wymaga czasu od istniejącego rozwoju), technologii, a czasem samej domeny.

Jeden dobrze obsługiwany programista eliminuje wiele czasu i koordynacji komunikacji. Załóżmy, że zatrudniłeś konsultanta ds. Technologii X. Zamiast przyspieszyć tego konsultanta w projekcie na tyle, aby ta osoba mogła wykonać całe kodowanie w tym obszarze, po prostu trenuje istniejącego programistę do tego stopnia, że ​​może coś zbudować z pewnym nadzorem.

Jednym z powodów, dla których nie widać tego zbyt wiele, jest to, że większość oprogramowania i tak jest pisana przez jedną osobę. Zespoły dzielą pracę i wszyscy idą i robią swoje. Parowanie programów, recenzji i wszystkiego, co pachnie mikrozarządzaniem, jest niezadowolone. Wielu nie uważa programowania za sport zespołowy. Jedna osoba rozwiązuje dany problem z pewnym uwzględnieniem ogólnych ograniczeń.

JeffO
źródło
0

Twierdziłbym, że im bardziej rozdzielamy projektowanie, wdrażanie, testowanie, dokumentację, kompilację, wdrażanie, operacje itp. Na unikalne role wykonywane przez specjalistów, tym bardziej postępujemy zgodnie z filozofią „zespołu chirurgicznego” (choć może nie w dokładnie opisany sposób ).

Z mojego doświadczenia wynika, że ​​filozofią devOps, że każda osoba powinna być zdolna do każdego zadania, jest powrót do modelu rzeźnika trzody chlewnej (nie mówiąc o tym, że jest zły, po prostu inny).

Mike Ounsworth
źródło
2
To zdecydowanie nie jest model DevOps.
RibaldEddie,
5
W rzeczywistości DevOps bardziej przypomina model zespołu chirurgicznego, ponieważ Operacje programistyczne sugerują, że operacje istnieją w służbie rozwoju. DevOps dotyczy dwóch podstawowych pojęć: że operacje należy postrzegać jako praktykę programistyczną, a zatem narzędzia i techniki stosowane w programowaniu, takie jak kontrola źródła i zwinne metody zarządzania, powinny być wykorzystywane przez operacje, a operacje mają wspierać rozwój.
RibaldEddie,
1
@RibaldEddie Interesujące. Moje doświadczenie z grupą DevOps w mojej firmie polega na tym, że zatrudniają tylko programistów i są odpowiedzialni za wszystko, od opracowywania produktu, testowania, dokumentacji, wdrażania itp. Przypomina mi się słowo „międzyfunkcjonalne”. No cóż, z 2 negatywnymi opiniami i usunięciem głosu w ciągu 15 minut, chyba będę trzymać się z dala od tej strony.
Mike Ounsworth,
1
Ach, więc mamy inną definicję „międzyfunkcyjnego”. Używam tego, aby oznaczać, że każdy członek zespołu jest w stanie wykonać każde zadanie - Jiras rutynowo jest rzucany między ludźmi, ponieważ porzucili specjalizację. Ktoś, kto rozwija tę funkcję, przetestuje lub udokumentuje następną funkcję. To właśnie „DevOps”, których doświadczyłem.
Mike Ounsworth,
1
@MikeOunsworth: to zespół funkcjonariuszy :-D
Jörg W Mittag
0

Jako programista, który często pełnił role DevOps i Build Master, czułem, że często kończyłem na tym stanowisku, że jestem zespołem chirurgicznym ... Eee ... facetem w zespole. Jako master kompilacji miałem przegląd całego kodu i był pierwszym wierszem, gdy zawiódł. Często sam to naprawiałem.
Często pisałem te systemy pomiarowe i mierzyłem punkty krytyczne w kodzie, części, które ulegałyby częstszym awariom, które przyciągały najwięcej raportów o błędach itp. Nie tylko opublikowałem wyniki zespołowi, ale też je przeanalizowałem, znajdowałem załamanie, które spowodowało problem i proponowane rozwiązania i zmiany architektoniczne, aby rozwiązać ten problem.

Jako DevOps automatyzowałbym ogromne procesy i koszty ogólne. Badałbym technologie i narzędzia, które ułatwiłyby życie zespołowi, całemu zespołowi, od programistów, testerów kontroli jakości aż po zarządzanie. Moja rola polegała na zrozumieniu procesu, tak; ale nie odrywając wzroku od zespołu (rzeczywistych ludzi) przy użyciu (cierpienia) tego procesu, mogłem go destylować do tego stopnia, że ​​stał się całkowicie przejrzysty, a jednocześnie otrzymywałem zbiór przydatnych danych, aby uzyskać obiektywny obraz tego zawsze nieuchwytny „duży obraz”.

To niewdzięczna pozycja i prawdopodobne, że tak bardzo jej się unika. Wiem, że dobrze wykonałem swoją pracę, gdy nikt nie zauważył tego procesu, kiedy nikt nie pomyślał o rurociągu kompilacji. Więc tak, dobrze naoliwiona maszyna jest szybko brana za pewnik. Wiedziałem jednak, że tak naprawdę zmierzyłem, multiplikatywny wpływ, jaki ta praca może mieć na produktywność zespołu i jest to warte inwestycji.

Więc tak, myślę, że ta rola jest nadal bardzo żywa, choć trzeba przyznać, że ewoluowała z tego, czym była wtedy.

Newtopian
źródło