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

164

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?
vog
quelle
12
Ich würde sagen, das kann nur meinungsbasierte Antworten bringen. Meine ruckelige Meinung ist, dass kein "Software-Ingenieur" als "Support" -Rolle gesehen werden will. Sie wollen allen anderen im Team gleichgestellt sein. Dies kann mit der Tatsache zusammenhängen, dass die Mehrheit der Softwareentwickler extrem jung ist. Die meisten Teams haben niemanden, der das Dienstalter in Anspruch nehmen und als "Chirurg" des Teams gelten könnte.
Euphoric
43
Ein potenzielles Problem, das ich sehe, wenn Sie absichtlich versuchen, ein Team auf diese Weise zu organisieren, ist die korrekte Identifizierung des Chirurgen.
Bart van Ingen Schenau
9
@Euphoric Vergessen Sie nicht, dass einige der Manager glauben, sie hätten bereits einen Super-Guru-Star-Chirurgen-Programmierer. Warum also überhaupt alle diese Hilfsbauern einstellen? Ich habe meinen Anteil an Managern gesehen, die beim "Verwalten" von Softwareteams oder vielem anderen, was über ihre farbenfrohen Excel-Tabellen hinausgeht, keine Anzeichen dafür zeigten, dass sie die Softwareentwicklung und die damit verbundenen Herausforderungen verstanden haben ).
Code_dredd
7
Dies hat möglicherweise etwas mit der Tatsache zu tun, dass "Chirurgie" einer der rückständigsten Bereiche der Medizin ist - in der Tat ist es ein bekannter Witz in Großbritannien, dass Chirurgen sieben Jahre lang studieren, damit sie "Arzt" genannt werden können. und dann weitere 7 Jahre, damit sie wieder "Mr" oder "Mrs" genannt werden können! Tatsächlich ist es eine ständige Anstrengung in der Ärzteschaft , die Chirurgie neu zu organisieren , um ihre Leistung zu verbessern, indem die "Best Practice" anderer Branchen mit viel geringeren Fehlerraten usw. (insbesondere der Zivilluftfahrt) befolgt wird. ...
Alephzero
6
@alephzero: Das sind ein paar lustige Behauptungen. Wo genau haben Sie operiert? Hier nimmt die Menge an Mist, die Sie als "Best Practice" bezeichnen, einen Großteil der Zeit eines Chirurgen in Anspruch und bringt keinen Nutzen. Super kluge Leute [ironisch] versuchen so sehr, etwas zu verbessern, was sie nicht verstehen, indem sie fast jede Woche mehr bürokratischen Mist hinzufügen. Die Ursachen der von Ihnen genannten Ausfallrate werden im Gegenteil jedoch nicht angesprochen. Fast alle Ausfälle sind auf Schlafentzug, Untererziehung und Überschätzung zurückzuführen. Oft alle drei zusammen.
Damon

Antworten:

103

"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 ...: -}

Bob Jarvis
quelle
20
Wenn jemand, der dies liest, die 20. Jubiläumsausgabe des Buches hat, lohnt es sich, das neue Vorwort und das neue Kapitel 19 zu lesen. Auch wenn die 20. Jubiläumsausgabe ab 2017 über 20 Jahre alt ist, weist der Autor auf einige der Behauptungen in Diese Antwort, die in der Eile, das gesamte Buch zusammenzufassen, oft übersehen wird, da "das Hinzufügen von Ingenieuren zu einem bereits verspäteten Projekt die Verspätung noch verschärft".
1
Was in aller Welt bedeutet "UUGE"? Tolle Antwort übrigens.
Wayne Conrad
5
@ WayneConrad Umgangssprache für riesige .
zzzzBov
1
Nachdem schon ein IBM - System - Programmierer in dieser Zeit war es üblich , sehr eng definierte Rollen im Team zu haben, mit einer Spezialität in einem bestimmten Teil des Betriebssystemes. Von der Person in jeder dieser Rollen würde erwartet, dass sie alles darüber weiß oder erfährt und als Support-Mitarbeiter für jeden der anderen Experten fungiert. Am Ende hatten wir im Wesentlichen ein OP-Team pro Mitarbeiter, jedes mit seiner eigenen Spezialität.
Joe McMahon
1
Als Antwort auf Ihren Kommentar, immer wieder dieselben Fehler zu machen, enthält der Wikipedia-Artikel zu dem Buch ein Zitat des Autors, den Sie vielleicht mögen: Die Tendenz der Manager, solche Fehler in der Projektentwicklung zu wiederholen, veranlasste Brooks, den Titel seines Buches zu verfehlen "Die Bibel der Softwareentwicklung", weil "jeder sie zitiert, einige Leute sie lesen und einige Leute sie befolgen".
Ryan
87

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.

Jörg W. Mittag
quelle
1
In Bezug auf den vorletzten Absatz wurde vom Chirurgen erwartet, dass er mit Stift und Papier arbeitet, und der Angestellte wäre das einzige Teammitglied gewesen, das Zugang zum Computer hatte.
Bart van Ingen Schenau
15
"Können Sie sich wirklich vorstellen, einen Vollzeitbeschäftigten dafür zu bezahlen, Quellcode auszudrucken und manuell zu indizieren und abzulegen?" Nein, aber ich kann mir definitiv vorstellen, einen Vollzeitmitarbeiter für die Verwaltung der Versionskontrolle und die kontinuierliche Erstellung von Systemen zu bezahlen, und in der Tat ist dies in jedem mittelgroßen oder größeren Unternehmen die Norm. In der Tat ist die Verwaltung von Wikis, Dokumentenverwaltungssystemen und dergleichen eine völlig separate, noch größere Rolle, für die in der Regel eine ganze Zeit lang technische Redakteure bezahlt werden.
Miles Rout
9
"Das gesamte Team hätte einen Computer für sich ... war ein Problem" - in den frühen 1980er Jahren hatten Organisationen Minicomputer- und Terminal-basierte Systeme, so dass Benutzer, obwohl es sich um denselben Computer handelte, immer noch auf gleicher Höhe darauf zugreifen konnten Basis und die Fähigkeit, eigene Programme auszuführen (unter der Annahme, dass eine angemessene Benutzerisolation und -sicherheit vorhanden ist).
Dai
2
Während Computer 1975 teuer waren, waren Tastaturen ziemlich billig. Als ich das erste Mal Großrechner programmierte (nicht 75, sondern 77), haben wir den Code auf Papier geschrieben, auf Karten gestanzt, an einen Wicket übergeben und dann regelmäßig überprüft, ob der Ausdruck zurückgegeben wurde. (Die Bearbeitungszeit kann für uns 2 Stunden und an manchen Standorten mehr als einen Tag betragen.) Ein Angestellter wäre für alle Aufgaben bis auf die erste sehr praktisch gewesen. Ich habe erst 1979 oder so Terminals gesehen.
Theodore Norvell
1
Betreff: Smalltalk - nicht nur jeder Entwickler und jeder Benutzer sollte einen eigenen Computer haben, diese Computer sollten auch leistungsstarke Computer mit viel Speicher und einer grafischen Benutzeroberfläche sein . Denken Sie "Workstation" statt "PC". Die ursprünglichen IBM-PCs hatten nicht die Leistung, Smalltalk auszuführen. Eine Schande, meiner Meinung nach ...
Bob Jarvis
20

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

Jon Watte
quelle
5
Ich habe wegen der absurden Behauptung über steigende Arbeitskosten abgelehnt. Arbeit, selbst spezialisiertes Ingenieurwissen, ist heute billiger als 1969. Tatsächlich untermauern die heute teureren Arbeitskosten diese ganze Antwort und es ist eine falsche Behauptung.
RibaldEddie
2
@RibaldEddie in Bezug auf was? Wenn Sie die Arbeitskosten mit den Lebenshaltungskosten vergleichen, sind sie rückläufig. Eine Stunde Arbeit kann Ihnen mehr Nahrung / Unterkunft bringen als 1969
k_g
3
@ k_g Nun, es hängt vom Standort ab. In Bezug auf die Inflation kann man in den meisten Ländern der USA heute einen Entwickler für weniger inflationsbereinigte Dollars als 1969 einstellen. Als Referenz schlägt Brooks in seinem Buch 20.000 Dollar für das vor, was wir heute als Senior-Entwickler bezeichnen würden und 10k für einen Lauf des Mühlenprogrammierers, der den Großteil der Arbeit erledigt. In heutigen Dollars sind das 10.000 ungefähr 65.000. Heutzutage ist es ein sehr guter Preis, wenn die meisten Entwickler in Ihrem Team 65.000 verdienen.
RibaldEddie
3
Im Wesentlichen sind die Gehälter für Software gegenüber 1969 unverändert. Angesichts der Gesamtinflation und der höheren Lebenshaltungskosten sind Entwickler heute erheblich billiger.
RibaldEddie
11
Tatsächlich sind alle Vorteile des modernen wirtschaftlichen Umfelds in Bezug auf Produktivität und billigere Arbeitskräfte auf die Führungskräfte und Anteilseigner in der Wirtschaft übergegangen. Selbst inflationsbereinigt sind die Gehälter für Softwareentwickler gleich geblieben, während die Vergütung für Führungskräfte um ein Vielfaches höher war als die Inflation. Darüber hinaus sind an vielen Orten, insbesondere an der Westküste Nordamerikas, die Lebenshaltungskosten erheblich schneller gestiegen als die Inflation (siehe Immobilien), und dennoch haben die Gehälter professioneller Entwickler kaum mit der Inflation Schritt gehalten.
RibaldEddie
13

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

Chococroc
quelle
Dieses Zitat ist im Grunde das, was ich gedacht habe: Es klingt wie Paarprogrammierung, bei der der "Chirurg" der "Fahrer" ist, außer in einem anderen Maßstab.
Izkata
7
Mir scheint, das würde extrovertierte, personenorientierte und kompetente Softwareentwickler erfordern. Viel Glück damit.
Bob Jarvis
Kam hierher, um das zu sagen; oder verschiedene Formen der Teamselbstorganisation.
Marcin
2
@ BobJarvis Ich bin anderer Meinung. Ich hatte große Erfolge in Teams von Introvertierten (und ich denke einige, die auch Extrovertierte beinhalteten). Der Schlüssel besteht darin, einen Raum zu schaffen, in dem sich die Menschen sicher und offen fühlen, um Beiträge zu leisten, und bereit sind, ihre natürlichen Neigungen für eine gewisse Zeit zum Wohle der Gruppe zu strecken. Susan Cains Ruhe war eine große Hilfe, um zu verstehen, wie man gut mit verschiedenen Temperamenten umgeht
David Carboni
12

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.

Matt Everson
quelle
9

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.

RibaldEddie
quelle
1
Im Grunde ist nichts damit passiert. +
Gordon
1
@gordy ja und nein. Sie werden feststellen, dass es im Beispiel des Brook höchstwahrscheinlich Sache der Manager ist, zu bestimmen, wer in den einzelnen Rollen des Teams vertreten ist. In einem modernen, agilen Konzept organisiert sich das Team jedoch selbst. Daher fallen die Rollen des Chirurgen oder Kopiloten auf natürliche Weise aus der Art und Weise heraus, wie das Team arbeitet. Ich denke, das ist ein entscheidender Unterschied: selbstorganisierend oder unternehmensspezifisch.
RibaldEddie
Ich würde "die meisten" in "einige" ändern. Es kommt wirklich auf die Teamdynamik an. Und es muss auf jeden Fall organisch wachsen, wenn ein Chirurg von oben diktiert wird. Das Ergebnis ist suboptimal, also +1 für sich selbst organisiert.
Peter
2
Sprüche aus dem Tao der Software: #IV - Das Tao der Teamarbeit: Gute Software wird von kleinen Teams geschrieben, die schnell arbeiten. Schlechte Software wird von großen Teams geschrieben, die langsam arbeiten. Folgerungen: - Die optimale Größe eines Teams ist 1; - Der maximale praktische Wert für die Teamgröße beträgt 3; - Bei Teamgrößen> 3 wird (falsche) Kommunikation zu einem ernsten Problem. - Bei einer Teamgröße> 6 wird der Projektabschluss ernsthaft beeinträchtigt. Der Projektabschluss zum Stichtag ist wahrscheinlich aus dem Fenster. In solchen Fällen werden die klügeren Entwickler die Tür benutzen ... So steht es geschrieben ... ( BWOOoooonnnggggg !!! )
Bob Jarvis
6

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.

Charles Merriam
quelle
9
Der Teil, der mich zum Lächeln bringt (?), Ist die Sache "... mehrere Manager ...". Ein Manager ist mehr als ausreichend, um die Produktivität zu senken. Mehrere Manager könnten Entwickler dazu bringen, an Selbstmord (introvertiert) oder Mord (extrovertiert) zu denken.
Bob Jarvis
4
@ BobJarvis - Ich hatte je nach Projekt bis zu fünf gleichzeitige "Manager" mit unterschiedlichen Titeln. Der Effekt ist so ziemlich so, wie Sie sich vorstellen können.
Rob Crawford
1
Offensichtlich sind Sie extrovertiert. Also ... Wahnsinnsabwehr? Mexiko? Oder ... justfiable Totschlag ..? :-)
Bob Jarvis
Deshalb hatte ich fünf Chefs in einer Firma. Während ich dort war, hörte ich jedes Problem, ob es von mir oder von jemand anderem war, aus 5 verschiedenen Perspektiven. Normalerweise ließ ich es analysieren, als Nummer 2 kam, und es war nur ärgerlich, dort mehrmals davon zu hören.
Robert Baron
Die ursprüngliche Idee war nicht, dass "fünf verschiedene Manager versuchen, sich einzumischen", sondern zum Beispiel "eine Person mit HR-Vorteilen" und "eine Person mit HR-Karriereentwicklung" usw. Ich denke, dass mehrere Manager arbeiten würden, wenn Sie die Abteilungen der einzelnen Manager basierend auf abrechnen würden Wie oft haben sie den Ingenieur kontaktiert? Würde ein lustiges Videospiel machen!
Charles Merriam
2

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
Gaurav
quelle
1

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.

JeffO
quelle
0

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

Mike Ounsworth
quelle
2
Das ist definitiv nicht das DevOps-Modell.
RibaldEddie
5
Tatsächlich ähnelt DevOps eher dem chirurgischen Teammodell, da Developer Operations impliziert, dass Vorgänge im Dienst der Entwicklung stehen. Bei DevOps geht es um zwei Kernkonzepte: dass Vorgänge als Entwicklungspraxis angesehen werden sollten und dass die in der Entwicklung verwendeten Tools und Techniken, wie Quellcodeverwaltung und agile Verwaltungsmethoden, von Vorgängen verwendet werden sollten und dass Vorgänge zur Unterstützung der Entwicklung dienen.
RibaldEddie
1
@RibaldEddie Interessant. Meine Erfahrung mit der DevOps-Gruppe in meinem Unternehmen zeigt, dass sie nur Entwickler einstellen und für alles verantwortlich sind, von der Produktentwicklung über das Testen und Dokumentieren bis hin zur Bereitstellung usw. Das Wort "funktionsübergreifend" fällt mir ein. Na ja, mit zwei Abstimmungen und einer Löschabstimmung innerhalb von 15 Minuten werde ich mich wohl von dieser Seite fernhalten.
Mike Ounsworth
1
Ah, dann haben wir eine andere Definition von "funktionsübergreifend". Damit meine ich, dass jedes Mitglied des Teams in der Lage ist, jede Aufgabe zu erledigen - Jiras wird routinemäßig zwischen den Leuten geworfen, weil sie die Spezialisierung aufgegeben haben. Jemand, der diese Funktion entwickelt, testet oder dokumentiert die nächste Funktion. Das sind die "DevOps", die ich erlebt habe.
Mike Ounsworth
1
@ MikeOunsworth: Das ist ein Team von funktionsübergreifenden: -D
Jörg W Mittag
0

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.

Newtopian
quelle