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

15

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?

Jiri Klouda
quelle
5
Ich stimme dafür, diese Frage als "Off-Topic" zu schließen, da sie besser in Software Engg passt. SE ( softwareengineering.stackexchange.com ), und auch weil es nicht streng devopspezifisch ist
Dawny33
2
Dies ist eine strikte DevOps-spezifische Frage. Es bezieht sich direkt auf den Prozess rund um die Softwarelieferung. Bist du sicher, dass du wirklich verstehst, was DevOps bedeutet?
Jiri Klouda
3
Sie sagen immer wieder DevOps, ich glaube nicht, dass es bedeutet, was Sie denken, dass es bedeutet.
Jiri Klouda
3
@ Dawny33: Bitte lesen Sie eines der grundlegenden Bücher von DevOps - The Phoenix Project. Sie werden keine einzige Erwähnung von AWS, Docker, Jenkins oder anderen Tools finden. Das gesamte Buch handelt von Prozessen, organisatorischen Hierarchien und Strukturen sowie der Art und Weise, wie man in Teams arbeitet. DevOps ist eine Möglichkeit, die wissenschaftlichen Ideen, die die Fertigung in Japan und später in den USA verbessert haben, in den Prozess der Softwareentwicklung einzubringen. Ideen basierend auf der Arbeit von Edward W. Deming und Eliyahu M. Goldratt. Was Sie als DevOps sehen, ist nur die Oberfläche, die Werkzeuge, die Ergebnisse. Die überflüssigen Teile davon.
Jiri Klouda
5
@ Dawny33 Diese Frage ist nicht für Software Engineering geeignet. Obwohl dieses allgemeine Thema ist, ist die Frage viel zu weit gefasst. Es geht eher um Meinungen als um den Versuch, ein Problem zu lösen. Bitte schlagen Sie keine anderen Communities vor, wenn Sie nicht verstehen, welche Arten von Fragen sie akzeptieren. Wenn diese Frage auf Software Engineering veröffentlicht würde, würde sie sehr schnell abgelehnt, geschlossen und wahrscheinlich gelöscht. Das führt zu einer schlechten Benutzererfahrung.
Thomas Owens

Antworten:

17

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 -

Bereitstellungen pro Tag und Entwickler

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.

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

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.

Evgeny
quelle
4

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.

Tensibai
quelle
1
Ich mag die Idee der Paarprogrammierung. Das ist tatsächlich etwas, das helfen könnte. Vielleicht kann ich später anhand der Theorie, an der ich gearbeitet habe, erklären, warum.
Jiri Klouda
Bitte warten Sie darauf!
Peter
4

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.

Dan Cornilescu
quelle
In leistungsstarken Organisationen bedeutet das Hinzufügen weiterer Entwickler in der Regel die Schaffung unabhängigerer Teams, die entkoppelte Software schreiben. Dadurch können mehr Menschen mehr und schneller erreichen. Alle über einen einzigen Integrationszweig kommunizieren zu lassen, ist ein Anti-Pattern und wird höchstwahrscheinlich die Dinge erheblich verlangsamen.
Evgeny
Having them all communicate via a single integration branch is an anti-pattern- Warum? Wenn sie in dem Sinne entkoppelt sind, dass sie ihre Arbeit nicht mehr integrieren müssen, berühren sie den Zweig in einer nicht überlappenden / nicht widersprüchlichen Weise. Wenn ihre Arbeit noch integriert werden muss, verzögert und verkompliziert der Wechsel zu weiteren Zweigen die Integration, indem er von der CI-Methodik abweicht und alle seine Vorteile verliert.
Dan Cornilescu
Ich denke, wir sind uns nicht einig über die Bedeutung von "Zweig". Es ist in Ordnung, ein einziges großes Repository mit einem einzelnen Zweig (git oder svn) zu haben und den Overhead aller zu tragen, die an demselben arbeiten. Es ist auch in Ordnung, mehrere Repositorys zu haben, in denen jedes Repository einen Zweig hat, der diesen bestimmten entkoppelten Service verfolgt. Dies hängt vom Tool und dem zusätzlichen Aufwand für das Festschreiben und das Auschecken des Codes ab.
Evgeny
Ah, sorry, ja - ich bin so daran gewöhnt und vergesse immer wieder, dass andere es nicht sind. Unter Zweigstelle verweise ich auf die allgemeine Darstellung der SCM-Zweigstelle auf hoher Ebene. Es spielt keine Rolle, welche Besonderheiten die eigentlichen zugrunde liegenden SCM-Systeme aufweisen, sofern sie auf monolithische Weise zusammen verwaltet werden . 1 großes Repo mit einer mainFiliale oder 10 nebeneinander liegende Repos (Git-Module?) Mit je einer mainFiliale sollten der CI-Perspektive ziemlich ähnlich sein.
Dan Cornilescu
Dann gilt meine Aussage aus dem ersten Kommentar. Unabhängigkeit kann nicht in einem Turm aus Babel erreicht werden. Wenn Sie einen Monolithen haben, ist der Overhead für alle sehr hoch - daher sind alle belastet. Es ist viel besser, entkoppelte Projekte als entkoppelte kleine VCS-Systeme darzustellen, die verwaltet werden sollen. Wenn Sie sich weit genug erinnern, verwendeten einige Unternehmen ClearCase und andere VCS, um den gesamten Buchungskreis zu verwalten - der Overhead war schrecklich.
Evgeny