Was ist mit dem "Surgical Team" -Muster aus "The Mythical Man-Month" passiert?

Als ich vor Jahren The Mythical Man-Month las, fand ich viele Dinge, die ich bereits aus anderen Quellen kannte. Es gab jedoch auch neue Dinge, obwohl das Buch aus dem Jahr 1975 stammt. Eines davon war:

Das chirurgische Team

Mills schlägt vor, dass jedes Segment eines großen Auftrags einem Team zugeordnet wird, das Team jedoch eher wie ein Operationsteam als wie ein Schweineschlachterteam organisiert wird. Das heißt, anstatt dass jedes Mitglied das Problem abschneidet, schneidet eines das Problem und die anderen geben ihm jede Unterstützung, die seine Effektivität und Produktivität erhöht.

Dies ist ein sehr interessantes Muster für die Organisation eines Software-Entwicklungsteams, aber ich habe es in keinem anderen Software-Engineering-Buch beschrieben, das nicht einmal irgendwo erwähnt wurde.

Warum ist das so?

• War das "Surgical Team" damals noch ungewöhnlich?
• Oder ist es versucht worden und gescheitert?
  • Wenn ja, wie ist es gescheitert?
  • Wenn nicht, warum sehen wir dieses Muster nicht in heutigen Softwareprojekten implementiert?

"The Mythical Man-Month" erschien in dem Jahr, in dem ich mit dem College begann, und war, um die gängige Umgangssprache zu verwenden, UUUGE! :-) Was Sie verstehen müssen, ist der Unterschied, wie Software DANN vs. JETZT entwickelt wurde. Back In The Day (tm) wurde so ziemlich die gesamte Codierung zuerst auf Papier durchgeführt, dann auf Lochkarten gelocht (Sie haben es erraten), dann eingelesen, kompiliert, verknüpft, ausgeführt, Ergebnisse erzielt und der Vorgang wiederholt. CPU-Zeit war teuerund begrenzte Ressource und Sie wollten es nicht verschwenden. Dito und ebenso Speicherplatz, Bandlaufzeit, etc, bla. Es war eine Verschwendung von perfekter CPU-Zeit auf einem Compiler, die zu (Schock- und Horrorfehlern!) Führte, eine Verschwendung von perfekter CPU-Zeit. Und das war 1975. Zu der Zeit, als Fred Brooks seine Ideen entwickelte, war die CPU-Zeit der mittleren bis späten 1960er Jahre noch größerteuer, Speicher / Festplatte / was auch immer noch begrenzt war, usw. usw. Die Idee hinter dem Surgical Team war es, sicherzustellen, dass der One Super Great Rockstar-Entwickler seine Zeit nicht mit alltäglichen Aufgaben wie dem Überprüfen des Codes am Schreibtisch, dem Tastenstanzen, Senden von Aufträgen, warten (manchmal stundenlang) auf Ergebnisse. Rockstar Dude Developer Man sollte WRITING CODE sein. Seine Legion von Groupies / Angestellten / Junior-Entwicklern sollte das Alltägliche erledigen.

Das Problem war, dass innerhalb von 2 Jahren nach der Veröffentlichung von Brooks 'Buch die Grundideen hinter The Surgical Team zusammenbrachen:

1. CRT-Terminals und Plattendateien begannen, Tastaturen und Kartendecks zu ersetzen. Die Computerzeit wurde billiger, es standen mehrere Computer zur Verfügung, und die Bearbeitungszeit verringerte sich dramatisch. Als ich zum College kam (Miami University, Oxford, Ohio, Klasse '79, danke für die Nachfrage), gutDie Bearbeitungszeit betrug ungefähr eine Stunde. Während der Finalwoche - vier Stunden, vielleicht manchmal sechs. (Wir konkurrierten um die CPU-Zeit mit einer Reihe von kommerziellen Unternehmen und Universitäten - und die kommerziellen Benutzer erhielten erste Priorität). In meinem letzten Jahr, in dem Miami aus der "Shared Computer" -Vereinbarung ausgestiegen war, hatte Miami eine eigene IBM 370/145 auf dem Campus installiert und einen netten HP Mini, an dem ich gearbeitet hatte, als RJE-Station, die wir als Mainframe einsetzen konnten Jobs in fünf Minuten oder weniger. Es hat sich jetzt gelohnt, Ihren Code auf dem HP einzuspielen, ihn vom HP an den Mainframe zu senden, mit den Daumen zu drehen / eine Zigarette zu rauchen und Ihre Ausgabe zurückzuerhalten, lange bevor Sie mit der Überprüfung Ihres Codes fertig sind.

2. Das Surgical Team hat als Grundvoraussetzung die Idee, dass Sie (oder "das Management", Gott helfe uns allen) den Rockstar Surgical Developer Dude identifizieren können. Tatsächlich bezweifle ich, dass dies möglich ist. Es gibt Rockstar-Entwickler, jeder weiß es - Studien haben Produktivitätsunterschiede zwischen den besten und den schlechtesten Entwicklern von bis zu 2000% gezeigt -, die diese Person jedoch identifizieren, ohne dass sie über einen langen Zeitraum hinweg Code schreibtist höchstwahrscheinlich unmöglich. Die einzige Möglichkeit, um zu erfahren, ob jemand ein Rockstar-Entwickler ist, besteht darin, ihn tatsächlich Code entwickeln zu lassen - aber wenn er NICHT der Rockstar Surgical Developer Dude ist, werden sie aufregende Dinge tun, z. B. seinen Code am Schreibtisch überprüfen, ihn auf Karten stanzen und Schachteln mit Lochkarten in die Job Entry-Abteilung schleppen und dort auf die Ergebnisse warten, damit sie zu Mr. Rockstar Surgical Developer Dude zurückschleppen können, anstatt zu lernen, wie man wirklich codiert - durch Schreiben von Code, Debuggen von Code, und so weiter Back In The Day (tm) gab es keine Programmierwettbewerbe, es gab keinen Stapelüberlauf, Sie hatten keinen PC, auf den Sie Code schreiben konnten, wann immer Sie Lust dazu hatten. Es gab keine Bücher über Algorithmen für Idioten - die einzige Möglichkeit, Programmieren zu lernen, bestand darin, in die Schule zu gehen und etwas zu studieren, in dem man ein bisschen programmieren musste. Aber programmierenper se wurde nicht ernst genommen und es wurde angenommen, dass es etwas war, was die Leute nicht wollten . In meinem ersten College - Kurs (SAN151 - Einführung in die Systemanalyse, Dr. Tom Schaber - danke, Tom :-) wurde uns vom Ausbilder gesagt, dass "... wir uns nur der Tatsache stellen mussten, dass wir ein ... ausgeben müssten ein paar Jahre als Programmierer, bevor wir Systemanalytiker werden konnten ". "Zwei Jahre?", Dachte ich. "Ich darf das nur zwei Jahre lang machen?!?" Ich war ernsthaft verärgert. Zum Glück hat er sich geirrt und ich habe seitdem ziemlich viel programmiert. :-)

3. Das Operationsteam geht davon aus, dass Programmierer eine relativ seltene Ressource sind. Tatsächlich dauerte es noch ein paar Jahre, aber mit dem Aufkommen der PCs in den frühen 80ern wurde das Programmieren zu etwas, an dem sich jeder Geek beteiligen konnte Guten Tag Turbo Pascal - nach heutigen Maßstäben war es nicht viel, aber zu der Zeit war es eine vollständige Pascal-IDE für ungefähr 40 Dollar, was absolut verrückt war! Jetzt könnte JEDER in die Programmierung einsteigen - wenn Sie sich einen Computer leisten könnten, und als IBM sich entschloss, den PC zu installieren (ja, mein erster PC war einer der größten Fehler von IBM :-), der für etwa 500 USD verkauft wurde, um diese Truthähne loszuwerden, bares Geld Überall haben angeschnallte Freaks ihre Mietzahlungen für einen Monat übersprungen ("Ja, äh, ich weiß, aber ich, äh ... habe meine Uuvula gebrochen und musste operiert werden und ... .uh ... ja, nächste Woche, kein Problem, danke, Mann ...) und saugte sie zu feuerverkaufspreisen auf. Dann haben wir mehr Geld für Add-Ons ausgegeben, als wir für den Computer bezahlt haben, um ihn nutzbar zu machen. ("Ja, Mann, nächste Woche sicher, wahrscheinlich ..." :-).

Was mich wirklich traurig macht, ist, dass Sie auch heute noch eine Lücke erhalten, wenn Sie die Leute fragen, ob sie jemals "The Mythical Man-Month" gelesen oder die wichtigste Lektion verstanden haben ("Hinzufügen von Ressourcen zu einem späten Projekt macht es später") starren - und dann genau die Fehler machen, die vor all den Jahren bei der Entwicklung von OS / 360 gemacht wurden. Alles Alte ist wieder neu ...: -}

Es gibt einige Aspekte dieses Konzepts, die manchmal heute umgesetzt werden, andere Aspekte, die vermieden werden .

Teams klein zu halten, ist eine der Grundfunktionen von Agile Methods, wird aber auch außerhalb von Agile praktiziert.

Übergreifende Teams sind ebenfalls ein Grundnahrungsmittel von Agile, aber auch außerhalb von Agile üblich.

Die Rolle des Programmierers wird größtenteils von Computersystemen wie Versionskontrollsystemen, Softwarekonfigurationsmanagementsystemen, Änderungsmanagementsystemen, Dokumentenmanagementsystemen, Wikis, Continuous Build-Systemen mit Artefakt-Repositories usw. übernommen. Ich meine, können Sie sich wirklich vorstellen, einen Vollzeitmitarbeiter dafür zu bezahlen, den Quellcode auszudrucken und ihn manuell zu indexieren und abzulegen?

In ähnlicher Weise wird die Rolle eines Systemadministrators (nicht Teil von Mills 'Surgical Team, sondern Teil eines typischen funktionsübergreifenden Teams der letzten Jahre) durch Konzepte wie DevOps (Übernahme der Rolle von Sysadmin in die Rolle des Software Engineer) abgelöst. , Platform-as-a-Service, Infrastructure-as-a-Service und Utility Computing (wobei die Rolle von Sysadmin als "Problem eines anderen" bezeichnet wird) oder Infrastructure-as-Code (Verwandeln der Systemadministration in Software-Engineering).

Einer der Aspekte, die wir heute zu vermeiden versuchen, ist, dass höchstens zwei Menschen das System verstehen. Nur dem Chirurgen wird garantiert, dass er das System vollständig versteht, der Copilot kann oder nicht. Dies ergibt einen Busfaktor zwischen 1 und 2. Wenn der Chirurg krank wird, ist das Projekt tot. Zeitraum. Die agile Antwort darauf lautet Collective Code Ownership, was genau das Gegenteil dieses Modells ist: Niemand ist für einen Teil des Systems allein verantwortlich . Stattdessen ist jeder als Gruppe für alles verantwortlich .

Schließlich sind in dieses Konzept einige Annahmen eingearbeitet, die veraltet sind. Obwohl dies nicht explizit angegeben ist, ist das Team beispielsweise so aufgebaut, dass nur eine Person im Team (der Chirurg) tatsächlich einen Computer hat. Das liegt natürlich daran, dass zu der Zeit, als der Artikel geschrieben wurde, selbst die Idee, dass ein ganzes Team einen Computer für sich haben würde, geschweige denn eine Person im Team, ein Problem war. (Sogar 1980, als Smalltalk veröffentlicht wurde, war einer der Gründe für das Scheitern des Systems, dass jeder Entwickler und jeder Benutzer seinen eigenen Computer hatte - zu dieser Zeit völlig undenkbar.)

Also, kurz gesagt: Ich glaube nicht , das Konzept genau umgesetzt wurde , wie beschrieben, aber einige Aspekte der es auf jeden Fall werden umgesetzt werden einige Aspekte als unerwünscht angesehen und aktiv vermieden, einige sind veraltet, und einige sind wahrscheinlich gute Ideen ™, aber niemand tut es.

Früher war eine College-Ausbildung etwas Einzigartiges, und Ingenieure gehörten zu den wenigen Auserwählten. Computer waren teuer und Teams arbeiteten an Projekten mit definiertem Geschäfts-RoI. Diese waren nicht sehr verbreitet.

Was passierte, waren Mikrocomputer, eine allgegenwärtige Grundausbildung und Computersysteme, die nicht einmal einen Universitätsabschluss benötigen, um Fortschritte zu erzielen. Was passierte, war auch eine Verlagerung der Wirtschaft und steigende Arbeitskosten.

Die Wirtschaftlichkeit eines Verhältnisses von 8: 2 Support: Engineer ergibt keinen Sinn mehr. Ingenieure müssen ihre eigene Unterstützung sein. Ein moderner Mensch mit ausreichender Ausbildung und Fähigkeiten, um effektiv zu einem Entwicklungsteam zu gehören, ist zu teuer, um keine eigene Entwicklung zu betreiben.

(Ein verwandter wirtschaftlicher Begriff ist "die Kostenkrankheit des Dienstleistungssektors".)

Diese Patterns klingen für mich sehr nach Mob-Programmierung:

Die gesamte Gruppe (QS, Entwickler und bei Bedarf auch Product Owner) arbeitet zur selben Zeit am selben Problem. Kein Aufstehen, hohe Kommunikation, direkt ins Leben gerufen.

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

Das Grundkonzept der Mob-Programmierung ist einfach: Das gesamte Team arbeitet als Team an jeweils einer Aufgabe. Das heißt: ein Team - eine (aktive) Tastatur - eine Leinwand (Projektor natürlich). Es ist so, als würde man ein komplettes Teampaar programmieren.

Sehen Sie es hier in Aktion: https://www.youtube.com/watch?v=dVqUcNKVbYg

Dieses Teammodell wird in Rapid Development - Taming Wild Software Schedules von Steve McConnell auf Seite 305 erneut erwähnt. Dort heißt es Chief-Programmer Team.

Dieses Modell entstand, weil das Team ein Genie war und die Rechenressourcen begrenzt waren. Es ist in Ungnade gefallen, weil Genialität selten ist und wir mit allgegenwärtigen Computern und verteilter Versionskontrolle am OP-Tisch Platz für viele Hände haben.

Weitere Referenzen:

Baker, F. Terry. "Chief Programmer Team Management of Production Programming", IBM Systems Journal, vol. 11, nein. 1, 1972, S. 56-73.

Baker, F. Terry und Harlan D. Mills. "Chefprogrammierer-Teams." Datamation, Band 19, Nummer 12 (Dezember 1973), S. 58-61.

Ich vermute, dass die meisten kleinen, sich selbst organisierenden Teams sowieso eher zu einem de-facto-Modell eines chirurgischen Teams werden.

Die letzten beiden Teams, in denen ich gearbeitet habe, bestanden in der Regel aus drei oder vier Personen, in der Regel einem Senior (Chirurgen), einem Intermediate (Copiloten) und einigen Junioren / Spezialisten. Einige der Rollen im OP-Team, die Brooks heutzutage erwähnt, werden von Scrum-Mastern und -Sysadmins oder Cloud-Anbietern ausgefüllt. Denken Sie daran, dass die Quellcodeverwaltung zu dieser Zeit kaum existierte, geschweige denn etwas so Mächtiges wie Git.

Denken Sie an die Zwei-Pizza-Regel von Bezos. Das ist Ihr selbstorganisierendes Operationsteam.

Es gab ein Papier von HP, das etwas Ähnliches vorschlug:

• Jeder Softwareentwickler würde mehrere Manager und mehrere Supportmitarbeiter benötigen.
• Für jeden Ingenieur sollte es einen technischen Redakteur, Tester, Build-Manager und Werkzeugbauer geben.

Die Zeitung war in der Zeit vor dem Web und wurde von Zeit zu Zeit als witzig bezeichnet. Jedes Jahr, in dem es zur Sprache gebracht wurde, wechselte der Kommentar ein bisschen mehr von "so lächerlich, dass es lustig ist" zu "Vielleicht sollten wir das tun".

Tatsächliche Tests sind notorisch schwer zu entwerfen, daher bleibt es wahrscheinlich die Meinung. Möglicherweise gibt es einige Umfragen zu Projekten und deren Abschlussquoten.

Ich frage mich, wie viel der Bedarf an einem Operationsteam durch das Aufkommen des Internets, integrierter Entwicklungsumgebungen und Softwareentwicklungskits , die viele der Funktionen übernehmen können, die Fred Brooks dem Operationsteam zuschrieb, überflüssig geworden ist , einschließlich:

• Chirurg: ein Programmierer
• Co-Pilot: Programmierer , Mitarbeiter, Online-Communities wie StackExchange oder IRC
• Administrator: Rolle, die in der Regel von einem Software- Projektmanager übernommen wird
• Herausgeber: IDEs, die Dokumentationsgeneratoren wie Javadoc oder Doxygen integrieren; Dokumentation von Software-Entwicklungskits
• Sekretär: E-Mail-Client, Projektmanagement-Tools wie Issue-Tracker und Pull-Requests, Unternehmens-Chatrooms und Mailing-Listen
• Programmangestellter: IDE, die Informationen zum Projektdesign speichert, mit der zusätzlichen Möglichkeit, Code umzugestalten; Dokumentation und Beispiele aus Software Development Kits
• Toolsmith: die gesamte Open Source Community
• Tester: sofort Testsuiten und Testbibliotheken. Für den Produktionscode ist jedoch natürlich ein separater QS-Prozess erforderlich.
• Sprachanwalt: Online-Dokumentation, StackExchange

Ich denke, Sie müssen sich die Prämisse von The Mythical Man Month ansehen. Wenn mehr Programmierer eingestellt werden, wird ein problematisches / überfälliges Softwareprojekt nur noch schlimmer. Das Problem liegt in der Kommunikation und darin, neu hinzugekommene Programmierer für das Projekt auf den neuesten Stand zu bringen (dies kostet Zeit von der vorhandenen Entwicklung), in der Technologie und manchmal in der Domäne selbst.

Ein gut unterstützter Programmierer spart viel Zeit für Kommunikation und Koordination. Nehmen wir an, Sie beauftragen einen Berater für Technology X. Anstatt diesen Berater so schnell mit dem Projekt zu beschäftigen, dass er die gesamte Programmierung in diesem Bereich durchführen kann, coacht er den vorhandenen Entwickler nur bis zu dem Punkt, an dem er etwas bauen kann mit etwas Aufsicht.

Ein Grund, warum Sie nicht viel davon sehen, ist, dass die meiste Software sowieso von einer Person geschrieben wird. Teams teilen die Arbeit auf und jeder macht sein Ding. Pair Programming, Reviews und alles, was nach Mikromanagement riecht, ist verpönt. Viele sehen Programmieren nicht als Mannschaftssport. Eine Person löst ein gegebenes Problem unter Berücksichtigung aller Einschränkungen.

Ich würde argumentieren, dass wir, je mehr wir Design, Implementierung, Test, Dokumentation, Bau, Bereitstellung, Betrieb usw. in einzigartige Rollen unterteilen, die von Spezialisten ausgeführt werden, umso mehr der Philosophie des "Operationsteams" folgen (obwohl dies möglicherweise nicht genau der beschriebenen Weise entspricht) ).

Meiner Erfahrung nach ist die DevOps-Philosophie, dass jeder Mensch für jede Aufgabe geeignet sein sollte, eine Rückkehr zum Modell des Metzgens (um nicht zu sagen, dass es schlecht ist, nur anders).

Als Programmierer, der oft die Rollen von DevOps und Build Master ausfüllte, hatte ich das Gefühl, dass ich oft in der Position des Operationsteams gelandet bin ... äh ... Mann im Team. Als Baumeister hatte ich den Überblick über den gesamten Code und war die erste Zeile, wenn es fehlschlug. Oft habe ich es einfach selbst repariert.
Ich war oft derjenige, der diese Metriksysteme geschrieben und die Hotpoints im Code gemessen hat, Teile, die häufiger ausfallen würden, die die meisten Fehlerberichte angezogen haben usw. Ich habe nicht nur die Ergebnisse für das Team veröffentlicht, sondern auch sie analysiert Knick, der zu Problemen führte, und Lösungsvorschläge und architektonische Änderungen, um dies zu beheben.

Als DevOps würde ich riesige Prozess- und Overhead-Bereiche automatisieren. Ich würde nach Technologien und Tools suchen, die dem Team, dem gesamten Team, das Leben erleichtern würden, von Entwicklern, QS-Testern, IT-Mitarbeitern bis hin zum Management. Meine Aufgabe war es, den Prozess zu verstehen, ja; Aber indem ich den Blick auf das Team (die eigentlichen Menschen) richtete, das diesen Prozess anwendet (durchleidet), konnte ich ihn bis zu einem Punkt destillieren, an dem er vollständig transparent ist, während ich trotzdem eine Menge nützlicher Daten erhalte, um eine objektive Ansicht davon zu erhalten jemals schwer fassbares "großes Bild".

Es ist eine undankbare Position zu haben und wahrscheinlich, warum es so sehr gemieden wird. Ich weiß, dass ich meine Arbeit gut gemacht habe, als niemand diesen Prozess bemerkte, als niemand über die Build-Pipeline nachdachte. Also ja, eine gut geölte Maschine ist schnell eine Selbstverständlichkeit. Aber ich wusste, dass diese Arbeit einen multiplikativen Einfluss auf die Produktivität eines Teams haben kann und dass sich die Investition lohnt.

Also ja, ich denke, diese Rolle ist heute noch sehr lebendig, obwohl sie sich zugegebenermaßen von dem entwickelt hat, was sie damals war.