Wie können die Auswirkungen des Monats des mythischen Mannes gemindert werden?

Brooks 'Gesetz: Wenn man einem späten Softwareprojekt mehr Personal hinzufügt, wird es später.

In seinem Buch No Silver Bullet - Essenz und Unfälle der Softwareentwicklung definiert Frederick Brooks das Konzept des Mythical Man Month :

Brooks geht davon aus, dass komplexe Programmierprojekte nicht perfekt in diskrete Aufgaben unterteilt werden können, an denen gearbeitet werden kann, ohne dass eine Kommunikation zwischen den Mitarbeitern stattfindet und komplexe Wechselbeziehungen zwischen den Aufgaben und den Mitarbeitern hergestellt werden, die sie ausführen .

Seit 1982 sind wir sicherlich weiter vorangekommen und haben mehr Erfahrung bei der Minderung dieses Problems gesammelt. Was sind einige der Lösungen, die Sie bei Ihrer Arbeit erfolgreich angewendet haben, um einem Projekt Ressourcen hinzuzufügen, ohne weitere Probleme zu verursachen?

Was ist das MMM?

Zunächst möchte ich den Kontext für Brooks Gesetz erläutern. Was war die Annahme, die ihn veranlasste, es 1975 zu schaffen?

Ein Mannmonat ist eine hypothetische Arbeitseinheit, die die Arbeit einer Person in einem Monat darstellt. Brooks 'Gesetz besagt, dass es unmöglich ist, nützliche Arbeit in Mannmonaten zu messen.

^{Quelle: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

Früher bedeuteten komplexe Programmierprojekte große Monolithsysteme. Und Brooks behauptet, dass diese Aufgaben nicht perfekt in einzelne Aufgaben unterteilt werden können, an denen gearbeitet werden kann, ohne dass eine Kommunikation zwischen den Entwicklern stattfindet und keine komplexen Beziehungen zwischen den Aufgaben und den Personen hergestellt werden, die sie ausführen.

Dies gilt vor allem für Software-Monolithen mit hohem Zusammenhalt. Unabhängig davon, wie weit die Entkopplung fortgeschritten ist, gibt der große Monolith den neuen Programmierern dennoch Zeit, sich mit dem Monolith vertraut zu machen. Und mehr Kommunikationsaufwand, der immer mehr Zeit in Anspruch nimmt.

Aber muss es wirklich so sein? Müssen wir Monolithen schreiben und Kommunikationskanäle zu halten , n(n − 1) / 2wo ndie Zahl der Entwickler ist?

Wir wissen, dass es Unternehmen gibt, in denen Tausende von Entwicklern an großen Projekten arbeiten ... und das funktioniert. Es muss also etwas geben, das sich seit 1975 geändert hat.

Möglichkeit zur Minderung des MMM

2015 veröffentlichten PuppetLabs und IT Revolution die Ergebnisse des State of DevOps-Berichts 2015 . In diesem Bericht konzentrierten sie sich auf die Unterscheidung zwischen leistungsfähigen Unternehmen und nicht leistungsfähigen Unternehmen.

Die leistungsstarken Organisationen weisen einige unerwartete Eigenschaften auf. Zum Beispiel haben sie die beste Projektlaufzeit in der Entwicklung. Beste Betriebsstabilität und Zuverlässigkeit im Betrieb. Sowie die beste Sicherheits- und Compliance-Bilanz.

Eines der überraschenden Dinge, die im Bericht hervorgehoben werden, ist die Metrik "Bereitstellungen pro Tag". Aber nicht nur Bereitstellungen pro Tag, sondern auch Bereitstellungen / Tag / Entwickler und was ist der Effekt des Hinzufügens von mehr Entwicklern in leistungsfähigen Organisationen im Vergleich zu nicht leistungsfähigen.

Dies ist die Grafik aus diesem Bericht -

Unternehmen mit geringer Leistung stimmen zwar mit den Annahmen von Mythical Man Month überein. Die leistungsstarken Organisationen können die Anzahl der Bereitstellungen / Tage / Entwickler linear mit der Anzahl der Entwickler skalieren.

Eine exzellente Präsentation von Gene Kim auf den DevOpsDays London 2016 spricht über diese Ergebnisse.

Wie es geht

Wie wird man eine leistungsstarke Organisation? Es gibt ein paar Bücher, die darüber sprechen, nicht genug Platz in dieser Antwort, also werde ich nur auf sie verlinken.

• Gut bis großartig: Warum manche Unternehmen den Sprung machen ... und andere nicht von Jim Collins
• High-Velocity Edge: Wie Marktführer Operational Excellence nutzen, um die Konkurrenz von Steven Spear zu schlagen
• Die New Economics für Industrie, Regierung, Bildung von W. Edwards Deming

Für Software- und IT-Organisationen ist einer der entscheidenden Faktoren für die Entwicklung einer leistungsstarken Organisation: Konzentration auf Qualität und Geschwindigkeit .

Zum Beispiel erklärt Ward Cunningham Technical Debt als all die Dinge, die wir nicht reparieren durften. Dies wird vom Management akzeptiert, da es immer mit dem Versprechen verbunden ist, dass es repariert wird, wenn Zeit ist.

Es gibt nie genug Zeit und die technischen Schulden werden immer schlimmer.

Was sind diese Dinge, die dazu führen, dass die technische Verschuldung wächst?

• Legacy-Code
• Manuelle Konfiguration von Umgebungen
• manuelle Prüfung
• manuelle Bereitstellungen

Legacy-Code Wie in Effektiv mit Legacy-Code arbeiten von Michael Feathers definiert, handelt es sich um jeden Code, der nicht über automatisierte Tests verfügt.

Jederzeit werden Verknüpfungen verwendet, um den Code zur Produktion zu bringen. Der Betrieb ist für immer mit der Aufrechterhaltung dieser Schulden belastet. Dann wird der Bereitstellungsprozess immer länger.

Gene erzählt in seiner Präsentation eine Geschichte über ein Unternehmen, das sechs Wochen im Einsatz ist. Zehntausende von extrem fehleranfälligen, langwierigen Schritten, die 400 Menschen binden und dies viermal im Jahr tun würden.

Einer der Grundsätze von DevOps ist, dass Zuverlässigkeit durch häufigere kleinere Bereitstellungen entsteht.

Beispiel

• Jon Jenkins auf der Velocity 2011 : Amazon führt 15.000 Bereitstellungen pro Tag durch
• Ken Exner auf dem AWS Summit 2015 : Amazon führt 136.000 Bereitstellungen pro Tag durch

Diese beiden Präsentationen zeigen alles, was Amazon getan hat, um den Zeitaufwand für die Bereitstellung von Code in der Produktion zu verringern.

Laut Gene ist das einzige, was sich im Laufe der Zeit in diesen leistungsstarken Unternehmen ändert, die Anzahl der Entwickler. Aus dem Amazon-Beispiel könnte man also sagen, dass sie in vier Jahren ihre Bereitstellungen zehnmal vergrößerten, indem sie einfach mehr Leute hinzufügten.

Dies bedeutet, dass unter bestimmten Bedingungen mit der richtigen Architektur, den richtigen technischen Praktiken, den richtigen kulturellen Normen und der Produktivität der Entwickler skaliert werden kann , wenn die Anzahl der Entwickler erhöht wird. Und DevOps ist definitiv mittendrin.

Was ich getan habe (und das ist nur subjektiv) ist wie folgt:

Wenn ein Manager, der über ein Fälligkeitsdatum nachdenkt, Mitarbeiter in mein Team aufnehmen möchte, um die benötigte Zeit zu verkürzen, und unter MMM zu stehen scheint, diskutiere ich zuerst mit ihm, warum dies schlecht sein könnte. Meine liebste Analogie ist, sie daran zu erinnern, dass neun Frauen, wenn eine Frau in neun Monaten ein Baby bekommen kann, in einem Monat kein Baby bekommen, aber in neun Monaten neun Babys. Die Zeit wird nicht verkürzt, nur die Parallelverarbeitung ist besser.

Wenn die Entscheidung unserem Team auferlegt wird, versuchen wir normalerweise, einige Aufgaben weiter aufzuteilen, und wenn dies nicht möglich ist, verlassen wir uns normalerweise auf die Paarprogrammierung , bei der ein Programmierer für die Eingabe verantwortlich ist und der andere den Code diktiert (und periodisch wechselt) ).

Das Schreiben von Code selbst ist langsamer, aber es gibt weniger Tippfehler und Fehler beim Testen, da während des Schreibens unvermeidliche Überprüfungen durchgeführt werden. Ich bin der Meinung, dass die Codequalität insgesamt auch etwas besser ist, aber ich habe keine Metriken, die diese Behauptung stützen könnten.

Wenn Sie ausschließlich aus CI-Sicht sprechen und die Anzahl der Entwickler erhöhen, die an einem Projekt arbeiten, bedeutet dies in der Regel, dass mehr Personen in derselben Branche arbeiten.

Herkömmliche CI-Systeme weisen in dieser Hinsicht ein Skalierbarkeitsproblem auf: Die Wahrscheinlichkeit von Brüchen / Regressionen / Blockaden verlangsamt die Integrationsgeschwindigkeit und fordert kleinere Teams auf, abzubrechen und zu untergeordneten Zweigen überzugehen (dh weitere Verlangsamungen). Siehe Wie kann die kontinuierliche Integration für sehr große Projekte / Teams skaliert werden? . Dies spielt genau nach dem Konzept des Mythical Man Month.

Die Lösung, die ich in meiner Antwort auf diese Frage vorschlage, ist ein hoch skalierbares CI-System, das die Migration zu einer echten CI-Integration auf Basis einer einzelnen Zweigstelle / eines Trunks für ganze größere Teams (auch bei großen Größen) ermöglicht.

Wenn alle Benutzer derselben Seite dieselben automatisierten Tools / Prozesse und den größten Teil der im CI-System selbst automatisierten QA-Überprüfungen verwenden, wird es viel einfacher, die Rollen und den Fokus zwischen den Teammitgliedern zu wechseln. Der gesamte Entwicklungsprozess wird reibungsloser, vorhersehbarer, entspannter.

Es ist daher einfacher, neue Mitarbeiter in einem solchen Umfeld an Bord zu holen und sie produktiv zu machen, indem weniger schwierige Aufgaben von den erfahreneren Teammitgliedern abgelöst werden, die dann schwierigere übernehmen können.

All dies kann, glaube ich, als lindernde Wirkung des Konzepts des Mythischen Mannesmonats angesehen werden.