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

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?

„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 są 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 ...: -}

Istnieją pewne aspekty tej koncepcji, które czasami są 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.

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”).

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

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.

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.

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.

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

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ń.

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).

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.