Der mythische Mann-Monatbearbeiten

Brooks diskutiert mehrere Ursachen für Planungsfehler. Am nachhaltigsten ist seine Diskussion des Brooks’schen Gesetzes: Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später. Der Mannmonat ist eine hypothetische Arbeitseinheit, die die Arbeit einer Person in einem Monat darstellt; Brooks ‚Gesetz sagt, dass die Möglichkeit, nützliche Arbeit in Mannmonaten zu messen, ein Mythos ist und daher das Herzstück des Buches ist.

Komplexe Programmierprojekte können nicht perfekt in diskrete Aufgaben unterteilt werden, an denen gearbeitet werden kann, ohne dass die Arbeiter miteinander kommunizieren und komplexe Zusammenhänge zwischen Aufgaben und den sie ausführenden Arbeitern hergestellt werden.

Wenn Sie also einem Projekt, das hinter dem Zeitplan läuft, mehr Programmierer zuweisen, wird es noch später. Dies liegt daran, dass die Zeit, die die neuen Programmierer benötigen, um sich über das Projekt zu informieren, und der erhöhte Kommunikationsaufwand eine immer größere Menge der verfügbaren Kalenderzeit in Anspruch nehmen. Wenn n Personen miteinander kommunizieren müssen, nimmt ihre Leistung ab, wenn n zunimmt, und wenn sie negativ wird, verzögert sich das Projekt mit jeder hinzugefügten Person weiter.

• Gruppeninterkommunikationsformel: n(n – 1) / 2
• Beispiel: 50 Entwickler geben 50 · (50 – 1) / 2 = 1225 kanäle der Kommunikation.

Keine silberne Kugelbearbeiten

Brooks fügte „No Silver Bullet — Essence and Accidents of Software Engineering“ — und weitere Überlegungen dazu, „‚No Silver Bullet‘ Refired“ — zur Jubiläumsausgabe des Mythical Man-Month hinzu.Brooks besteht darauf, dass es keine Wunderwaffe gibt – „es gibt keine einzige Entwicklung, weder in der Technologie noch in der Managementtechnik, die allein schon eine Verbesserung der Produktivität, der Zuverlässigkeit und der Einfachheit innerhalb eines Jahrzehnts verspricht.Das Argument beruht auf der Unterscheidung zwischen zufälliger Komplexität und essentieller Komplexität, ähnlich wie das Amdahlsche Gesetz auf der Unterscheidung zwischen „streng seriell“ und „parallelisierbar“ beruht.

The second-system effectEdit

The second-System effect schlägt vor, dass, wenn ein Architekt ein zweites System entwirft, es das gefährlichste System ist, das sie jemals entwerfen werden, weil sie dazu neigen werden, alle Ergänzungen zu integrieren, die sie ursprünglich aufgrund von inhärenten Zeitbeschränkungen nicht zum ersten System hinzugefügt haben. Daher sollte ein Ingenieur beim Start eines zweiten Systems darauf achten, dass er anfällig für Überentwicklungen ist.

Die Tendenz zur irreduziblen Anzahl von Fehlernbearbeiten

Der Autor macht die Beobachtung, dass es in einem entsprechend komplexen System eine gewisse irreduzible Anzahl von Fehlern gibt. Jeder Versuch, beobachtete Fehler zu beheben, führt tendenziell zur Einführung anderer Fehler.

Progress trackingEdit

Brooks schrieb: „Frage: Wie kommt ein großes Softwareprojekt ein Jahr zu spät? Antwort: Ein Tag nach dem anderen!“ Inkrementelle Schlupflöcher an vielen Fronten akkumulieren sich schließlich, um eine große Gesamtverzögerung zu erzeugen. Auf jeder Managementebene ist weiterhin darauf zu achten, kleine individuelle Meilensteine zu erreichen.

Konzeptionelle Integritätbearbeiten

Um ein benutzerfreundliches System zu erstellen, muss das System konzeptionelle Integrität aufweisen, die nur durch die Trennung von Architektur und Implementierung erreicht werden kann. Ein einzelner Chefarchitekt (oder eine kleine Anzahl von Architekten) entscheidet im Namen des Benutzers, was in das System aufgenommen wird und was nicht. Der Architekt oder das Architektenteam sollte eine Vorstellung davon entwickeln, was das System tun soll, und sicherstellen, dass diese Vision vom Rest des Teams verstanden wird. Eine neuartige Idee von jemandem kann nicht enthalten sein, wenn sie nicht nahtlos in das Gesamtsystemdesign passt. Um ein benutzerfreundliches System zu gewährleisten, kann ein System absichtlich weniger Funktionen bereitstellen, als es kann. Der Punkt ist, wenn ein System zu kompliziert zu bedienen ist, werden viele Funktionen ungenutzt bleiben, weil niemand Zeit hat, sie zu lernen.

The manualEdit

Der Chefarchitekt erstellt ein Handbuch mit Systemspezifikationen. Es sollte die externen Spezifikationen des Systems im Detail beschreiben, d. H. Alles, was der Benutzer sieht. Das Handbuch sollte geändert werden, wenn Feedback von den Implementierungsteams und den Benutzern eingeht.

Das Pilotsystembearbeiten

Beim Entwurf eines neuartigen Systems wird ein Team ein Wegwerfsystem entwerfen (ob beabsichtigt oder nicht). Dieses System fungiert als „Pilotplan“, der Techniken aufdeckt, die anschließend zu einer vollständigen Neugestaltung des Systems führen. Dieses zweite, intelligentere System sollte an den Kunden geliefert werden, da die Lieferung des Pilotsystems dem Kunden nur Qualen bereiten und möglicherweise den Ruf des Systems und vielleicht sogar das Unternehmen ruinieren würde.

Formelle Dokumentenbearbeiten

Jeder Projektmanager sollte einen kleinen Kernsatz formeller Dokumente erstellen, die die Projektziele definieren, wie sie erreicht werden sollen, wer sie erreichen wird, wann sie erreicht werden sollen und wie viel sie kosten werden. Diese Dokumente können auch Inkonsistenzen aufdecken, die sonst schwer zu erkennen sind.

Project estimationEdit

Bei der Schätzung der Projektzeiten sollte beachtet werden, dass Programmierprodukte (die an zahlende Kunden verkauft werden können) und Programmiersysteme dreimal so schwer zu schreiben sind wie einfache unabhängige interne Programme. Es sollte berücksichtigt werden, wie viel der Arbeitswoche tatsächlich für technische Fragen aufgewendet wird, im Gegensatz zu administrativen oder anderen nicht technischen Aufgaben wie Besprechungen und insbesondere „Stand-up“ – oder „All-Hands“ -Besprechungen.

Kommunikationbearbeiten

Um eine Katastrophe zu vermeiden, sollten alle Teams, die an einem Projekt arbeiten, auf so viele Arten wie möglich miteinander in Kontakt bleiben — E-Mail, Telefon, Besprechungen, Memos usw. Anstatt etwas anzunehmen, sollten Implementierer die Architekten bitten, ihre Absicht für ein Feature, das sie implementieren, zu klären, bevor sie mit einer Annahme fortfahren, die möglicherweise völlig falsch ist. Die Architekten sind dafür verantwortlich, ein Gruppenbild des Projekts zu formulieren und es anderen mitzuteilen.

Das Operationsteambearbeiten

So wie ein Operationsteam während der Operation von einem Chirurgen geleitet wird, der die kritischste Arbeit ausführt, während er das Team anweist, bei weniger kritischen Teilen zu helfen, scheint es vernünftig, einen „guten“ Programmierer zu haben, der kritische Systemkomponenten entwickelt, während der Rest eines Teams das bereitstellt, was zur richtigen Zeit benötigt wird. Darüber hinaus sinniert Brooks, dass „gute“ Programmierer im Allgemeinen fünf- bis zehnmal so produktiv sind wie mittelmäßige.

Code Freeze und System versioningEdit

Software ist unsichtbar. Daher werden viele Dinge erst sichtbar, wenn eine bestimmte Menge an Arbeit an einem neuen System geleistet wurde, sodass ein Benutzer es erleben kann. Diese Erfahrung wird Erkenntnisse liefern, die die Bedürfnisse eines Benutzers oder die Wahrnehmung der Bedürfnisse des Benutzers verändern. Das System sollte daher geändert werden, um den geänderten Anforderungen des Benutzers gerecht zu werden. Dies kann nur bis zu einem bestimmten Punkt geschehen, andernfalls wird das System möglicherweise nie abgeschlossen. Zu einem bestimmten Zeitpunkt sollten keine Änderungen mehr am System zulässig sein und der Code sollte eingefroren werden. Alle Änderungsanträge sollten bis zur nächsten Version des Systems verzögert werden.

Specialized toolsEdit

Anstatt dass jeder Programmierer seinen eigenen speziellen Satz von Werkzeugen hat, sollte jedes Team einen designierten Werkzeugmacher haben, der Werkzeuge erstellen kann, die für den Job, den das Team macht, stark angepasst sind, z. B. ein Code-Generator-Tool, das Code basierend auf einer Spezifikation erstellt. Darüber hinaus sollten systemweite Tools von einem gemeinsamen Tools-Team erstellt werden, das vom Projektmanager überwacht wird.

Senkung der Softwareentwicklungskostenbearbeiten

Es gibt zwei Techniken zur Senkung der Softwareentwicklungskosten, über die Brooks schreibt:

• Implementierer können erst eingestellt werden, nachdem die Architektur des Systems abgeschlossen ist (ein Schritt, der mehrere Monate dauern kann, in denen vorzeitig eingestellte Implementierer möglicherweise nichts zu tun haben).
• Eine andere Technik, die Brooks erwähnt, besteht darin, überhaupt keine Software zu entwickeln, sondern sie nach Möglichkeit einfach „von der Stange“ zu kaufen.