Behandelt Fred Brooks '"Surgical Team" effektiv den Busfaktor?

Mein Team von 4 erfahrenen Entwicklern arbeitet an einer großen, modularen Windows-Anwendung (ca. 200 KLoC). Ich habe mich seit Beginn des Projekts (vor 3 Jahren) auf die Kerncodebasis konzentriert und bin allmählich zu einer semi-leitenden Entwicklerposition übergegangen, obwohl ich nicht der Teammanager bin.

Unsere aktuelle Iteration ist eine vom oberen Management angeforderte Aktualisierung der Benutzeroberfläche mit hoher Priorität, die etwa 15 Änderungen an der Kerncodebasis umfasst. Wenn von dem Manager gefragt, schätzte ich , dass jeder der 15 Änderungen würde weniger als vier Stunden für mich komplette , insgesamt weniger als 7 Werktage. Ich habe mich dann freiwillig gemeldet, um die Arbeit auszuführen. Stattdessen beschloss der Manager, alle 15 Aufgaben gleichmäßig auf alle vier Entwickler aufzuteilen.

In den drei Tagen seit Beginn unserer Arbeit habe ich zwei Dinge beobachtet:

1. Die anderen unerfahrenen Teammitglieder erledigten jeweils etwa eine oder weniger Aufgabe.

2. Brooks Gesetz in Aktion: Ich habe ungefähr die Hälfte meiner Zeit damit verbracht, Hilfe zu leisten (um zu versuchen, sie in der Verwendung der Komponenten zu coachen). Infolgedessen habe ich nur 2 Aufgaben selbst erledigt, anstatt der erwarteten 5 oder 6.

Ich wandte mich mit der Sorge an meinen Manager, dass wir spät dran waren, und schlug erneut vor, die verbleibenden Aufgaben zu erledigen. Meine Anfrage wurde freundlicherweise abgelehnt, und es gab zwei Gründe, die Ladung gleichmäßig aufzuteilen:

1. Begrenzen Sie den Lkw- / Bus-Faktor - steigern Sie jetzt andere Entwickler auf diese Fähigkeiten, damit in Zukunft jede Arbeit an jeden vergeben werden kann, nicht nur an mich.
2. Um einen "Engpass" (mich) zu beseitigen und die Arbeit schneller zu erledigen.

Um es klar auszudrücken, ich habe keine Probleme mit: a) dem Investieren der Zeit, b) Leuten, die meinen Code berühren, oder c) der Arbeitsplatzsicherheit. Tatsächlich schlage ich dem Teamleiter regelmäßig vor, andere Entwickler in bestimmten Aspekten der Kerncodebasis zu schulen, um das Risiko zu verringern.

In dieser Iteration haben wir auch eine große Sammlung von Fehlerkorrekturen mit hoher Priorität, sodass gezielt weitere Fortschritte erzielt werden könnten, wenn die Arbeitslast neu verteilt würde.

In Mythical-Man-Month schlägt Brooks ein " Surgical Team " vor, bei dem jedes Team aus einem Lead + Sub-Lead (dem Manager und mir) und einigen Nebenrollen besteht. Ich habe das Gefühl, dass wir natürlich in diese Organisation fallen, aber mein Manager arbeitet dagegen. Ich bin der Meinung, dass der Busfaktor bereits behoben ist (der Manager ist mit dem Kerncode bestens vertraut) und dass der Engpass tatsächlich nicht besteht (mehr Entwickler werden die Arbeit nicht beschleunigen). Ich denke, dass in dieser Hinsicht ein Operationsteam eine gute Sache ist.

Dies sind meine Gefühle, aber ich bin kein erfahrener Manager, noch mussten wir uns mit dem Busfaktor (Klopfen auf Holz) auseinandersetzen. Hatte Brooks recht? Haben Sie in einem "Surgical Team" gearbeitet, in dem der Busfaktor ins Spiel kam? Gibt es bessere Techniken für das Management von Vertriebskompetenz?

Ähnliche Fragen:

• Wie kann man den Busfaktor erhöhen und sich gleichzeitig spezialisieren?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

Eigentlich würde ich argumentieren, dass Sie dem Modell des "Operationsteams" folgen. Glücklich!

Ein Teil des Punktes dieses Modells ist, dass die unteren Teammitglieder eine Assistentenrolle haben. Wenn das Team keine Herzoperation durchführt, ist es in Ordnung, sich langsamer zu bewegen und ihnen die Möglichkeit zu geben, einige ihrer Fähigkeiten zu üben oder Verantwortlichkeiten zu trainieren.

Es ist die Aufgabe des Chirurgen, sein Team zu untersuchen und zu leiten, indem er nach Schwachstellen sucht und diese behebt sowie der Top-Entwickler ist. Sie können dies nicht von einem Nicht-Chirurgen (Business Manager) ausführen lassen, da dieser die erforderlichen Fähigkeiten nicht versteht, ähnlich wie ein Lehrling eines Handwerksmeisters.

Der Manager nutzt diese Gelegenheit, um an einem seiner anderen Ziele zu arbeiten. Wenn im Laufe der Zeit ein Fehler im Team aufgedeckt wird, kann er sich damit befassen, bevor es zu einem Problem wird. Sagen wir, indem Sie einen anderen Entwickler einstellen.

Oder die Junioren könnten einen Fehler machen. Dies ist der perfekte Zeitpunkt für sie, da sie jemanden haben, der über ihre Schulter wacht. Oscar Wilde sagte

Erfahrung ist einfach der Name, den wir unseren Fehlern geben.

Wenn diese Junioren niemals die Möglichkeit haben , Fehler zu machen, werden sie sich niemals verbessern. Es raubt Ihrem Team nicht nur erfahrene zukünftige Entwickler, sondern beraubt sie gewissermaßen einer Chance, die sie hätten haben sollen.

Unsere Firma hat früher so gearbeitet, wie Sie es vorgeschlagen haben. Wir hatten nur zwei Leute, die einen kritischen Teil des Codes verstanden haben. Wann immer eine Aufgabe in diesem Teil des Codes auftauchte, anstatt ein paar Wochen damit zu verbringen, jemanden auf den neuesten Stand zu bringen, wurde die Aufgabe ihm zugewiesen, weil er sie in ein paar Tagen erledigen konnte. Das hat tatsächlich eine Weile ziemlich gut funktioniert.

Was schließlich geschah, war, dass ihr Teller so voll wurde, dass es Wochen dauern würde, bis sie ganz oben auf ihrer Liste stehen, obwohl sie eine Aufgabe in zwei Tagen erledigen könnten. Manager würden heftige verbale Kämpfe führen, deren Aufgabe dringender war. Dringende abhängige Aufgaben würden rückgängig gemacht.

Schließlich hatten die Manager das Warten satt und begannen, ihre eigenen Teams auszubilden. Ja, es war eine Weile viel langsamer, aber jetzt ist unser Durchsatz viel besser.

Möglicherweise befinden Sie sich jetzt in der ersten Phase, in der Sie die Arbeit erledigen können, aber Sie können nicht vorhersagen, wann Sie in die zweite Phase übergehen werden. Hier ist ein Hinweis: Es geschieht immer zum ungünstigsten Zeitpunkt. Ihr Manager hat Recht, den Treffer zu erzielen, wenn Sie noch etwas Luft zum Atmen haben.

Ja, es ist frustrierend zu sehen, wie jemand mit etwas kämpft, das Sie viel schneller und einfacher selbst erledigen können. Versuchen Sie, irgendwann einen Zweijährigen zu erziehen. Sie tun es, weil es dem gesamten Team hilft, sich zu verbessern. Es ist die Aufgabe Ihres Managers, sich um den Zeitplan zu kümmern. Wenn Sie sich Sorgen über die rückgängig gemachten Fehler mit hoher Priorität machen, fordern Sie sich heraus, wie schnell Sie sie beheben können.

Sie sind jetzt vielleicht kein Engpass, aber irgendwann werden Sie es sein, wenn Sie die ganze Arbeit weiterhin selbst erledigen. Ihr Manager erkennt, dass es wichtig genug ist, dass Sie lernen, zu delegieren, um zu riskieren, dass Ihr Projekt zu spät kommt - vertrauen Sie ihm. Sobald Sie lernen, loszulassen, werden Ihre Junioren unter Ihrer Anleitung viel mehr lernen und produzieren.

Sie wenden eine Einschränkung an, die möglicherweise nicht vorhanden oder so bedeutend ist, wie Sie glauben. Insbesondere sorgen Sie sich um die Zeit bis zur Fertigstellung. Ihr Manager hingegen scheint von den wahrgenommenen Zeitbeschränkungen nicht betroffen zu sein.

Wenn Sie die Lieferzeit aus Ihrer Frage herausnehmen, werden Sie sich schnell fragen, warum Sie die Frage überhaupt stellen.

Das heißt nicht, dass immer Zeit verfügbar ist, und Sie haben angegeben, dass dies eine Anfrage des oberen Managements mit hoher Priorität ist. Aber Sie sind nicht in alle Gespräche eingeweiht, die Ihr Chef mit ihnen geführt hat. Möglicherweise hat er länger verhandelt, damit Sie diese Zeit damit verbringen, die anderen Mitglieder des Teams zu trainieren.

Und während Sie der Meinung sind, dass der Busfaktor bereits angesprochen wurde, freut sich Ihr Chef möglicherweise auf die nächste Anfrage, die nicht einfach in die 7-tägige Arbeit eines seiner Star-Entwickler passt. Es ist weitaus sicherer, das Team auf einer kleineren Iteration zu schulen, bei der das objektive Ausmaß des Risikos viel geringer ist.

Ich war schon einmal ein kritischer Engpass. und ehrlich gesagt ist es kein angenehmer Ort. In meinem Fall sprachen der IT-Vizepräsident und ich miteinander und wir hatten einen Plan, um das Problem dauerhaft zu beheben. Es tat weh, aber es tat viel weniger weh als ich.

Es ist einfach, sich in die Denkweise von allem hineinzuversetzen, was so schnell wie möglich ausgeschaltet werden muss. Ein guter Manager erkennt die seltenen Gelegenheiten, bei denen sich eine kleine Verzögerung (für Cross-Training / Ausbildung) später erheblich auszahlen kann.