The Mythical Man-Month: Essays on Software Engineering (deutsch Vom Mythos des Mann-Monats: Essays über Software-Engineering) ist ein Buch des US-amerikanischen Informatikers Fred Brooks über Software-Engineering und Projektmanagement. Seine Kernbotschaft, vom Autor selbst (wenn auch „unerhört vereinfachend“) als Brooks’sches Gesetz bezeichnet, lautet:
“Adding manpower to a late software project makes it later.”
„Der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch mehr.“
Brooks’ Erfahrungen beruhen auf seinen Beobachtungen bei IBM als Leiter der Entwicklung von OS/360. So hatte er damals einem Teilprojekt, das in Zeitverzug geraten war, mehr Programmierer zugewiesen; später kam er zu dem Schluss, dass diese Entscheidung – entgegen aller Intuition – die Verzögerung noch verschlimmerte. Auch erwies sich seine Behauptung als falsch, ein gewisses Projekt (das Schreiben eines ALGOL-Compilers) werde sechs Monate dauern, unabhängig von der Anzahl der Mitarbeiter; tatsächlich dauerte es länger. Angesichts der Neigung von Projektmanagern zu solchen Fehlern spöttelte Brooks, sein Buch werde „Bibel des Software-Engineerings“ genannt, weil:
“Everybody quotes it, some people read it, and a few people go by it.”
„Alle zitieren es, einige lesen es und ein paar Leute befolgen es.“
Das Buch wird weithin als Klassiker zu den menschlichen Faktoren des Software-Engineering angesehen.
Die englischsprachige Originalausgabe erschien 1975, eine korrigierte Neuauflage 1982, die deutsche Übersetzung 1991. Im Jahr 1995 erschien eine Jubiläumsausgabe mit vier zusätzlichen Kapiteln sowie dem Essay No Silver Bullet: Essence and Accident in Software Engineering und einem Kommentar des Autors, deutsch 2003.
Ideen und Konzepte Bearbeiten
Der Mythos „Mann-Monat“ Bearbeiten
Brooks diskutiert verschiedene Ursachen für Planungsfehlschläge. Den meisten Raum nimmt seine Diskussion des Brooks’schen Gesetzes ein: „Der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch mehr.“ Mannmonat ist eine hypothetische Maßeinheit für die Menge an Arbeit, die eine Person durchschnittlich in einem Monat schafft; das Brooks’sche Gesetz besagt, dass es ein Mythos sei, nützliche Arbeit in Mannmonaten messen zu können, und ist insofern die Kernaussage des Buchs.
Komplexe Programmierprojekte können nicht vollkommen in getrennte Aufgaben aufgeteilt werden, die ohne Kommunikation zwischen den Bearbeitern und ohne ein komplexes Beziehungswerk zwischen Aufgaben und Bearbeitern zu erledigen sind.
Bereits verzögerte Softwareprojekte werden daher durch Einsatz zusätzlicher Arbeitskräfte nur noch weiter verzögert. Das liegt daran, dass die Einarbeitungszeit und der erhöhte Kommunikationsbedarf der neuen Programmierer einen immer höheren Anteil der verfügbaren Projektlaufzeit verschlingt. Wenn n Personen untereinander kommunizieren müssen, sinkt ihr Output mit wachsendem n, und sobald er negativ wird, verzögert sich das Projekt mit jeder zusätzlich eingesetzten Person.
- Anzahl der Kommunikationsbeziehungen: n(n − 1) / 2
- Beispiel: 50 Entwickler ergeben 50 · (50 – 1) / 2 = 1225 Kommunikationskanäle.
Keine „Silberkugeln“ Bearbeiten
Brooks fügte der Jubiläumsausgabe seines Buches den Essay No Silver Bullet – Essence and Accidents of Software Engineering sowie weitere Überlegungen unter dem Titel “No Silver Bullet” Refired hinzu. In der Mythologie stellt eine aus Silber gegossene Gewehrkugel oft die einzig wirksame Waffe gegen Werwölfe, Hexen und andere Ungeheuer dar; Brooks postuliert, dass es keine solche „Silberkugel“ gebe:
“There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.”
„Es gibt keine einzige Entwicklung, weder technologisch noch bei den Techniken des Managements, die für sich allein versprechen könnte, im Laufe von zehn Jahren wenigstens eine Größenordnung [das Zehnfache] an Verbesserungen bei Produktivität, Zuverlässigkeit oder Einfachheit zu garantieren.“
Sein Argument beruht auf der Unterscheidung zwischen zufälliger und wesentlicher Komplexität, ähnlich wie das Amdahlsche Gesetz zwischen „strikt seriellen“ und „parallelisierbaren“ Prozessen unterscheidet.
Das Problem des zweiten Systems Bearbeiten
Der von Brooks geprägte Begriff Second-system effect postuliert, dass die zweite Version eines Systems die bei weitem gefährlichste wird, denn Architekten neigten dazu, hier alle Erweiterungen aufzunehmen, die bei der ersten Version dem unvermeidlichen Zeitmangel zum Opfer gefallen sind. Der Autor benennt verschiedene IBM-Produkte zur Stützung seiner These, u. a. den Stretch-Computer und OS/360, und gibt Ratschläge zur Vermeidung.
Die nicht weiter reduzierbare Fehlerzahl Bearbeiten
Der Autor macht die Beobachtung, dass jedes hinreichend komplexe System immer eine Mindestanzahl von Fehlern aufweist. Jeder Versuch, erkannte Fehler zu beseitigen, resultiert in neuen Fehlern.
Terminmanagement Bearbeiten
Brooks schreibt: „Frage: Wie kommt es, dass sich ein großes Softwareprojekt um ein Jahr verspätet? Antwort: Jedesmal um einen Tag!“ Geringfügige Verzögerungen an vielen Fronten laufen so zu einer großen Gesamt-Verspätung auf. Dagegen hilft nur eine ständige Überprüfung der einzelnen Meilensteine auf allen Managementebenen.
Konzeptionelle Integrität Bearbeiten
Voraussetzung für ein benutzerfreundliches System ist die Integrität seines Konzepts, die nur durch eine Trennung von Architektur und Implementierung erreicht werden kann. Im Namen und Auftrag des Nutzers entscheidet ein Chefarchitekt (oder eine kleine Anzahl von Architekten), was in das System eingeht und was draußen bleibt. Der Chefarchitekt sollte eine Idee entwickeln, was das System leisten soll, und sicherstellen, dass diese Vision vom Rest des Entwicklungsteams verstanden wird. Etwaige neue Vorschläge Einzelner werden nicht mit einbezogen, wenn sie sich nicht nahtlos in das Gesamtdesign einfügen.
Um ein benutzerfreundliches System zu gewährleisten, kann ein System absichtlich weniger Funktionen aufweisen als möglich wäre. Wenn es nämlich zu kompliziert zu benutzen ist, werden viele seiner Funktionen ungenutzt bleiben, weil niemand die Zeit hat, ihre Bedienung zu erlernen.
Das „Handbuch“ Bearbeiten
Der Chefarchitekt erstellt ein Handbuch der Systemspezifikationen, das die äußeren Eigenschaften des Systems genau beschreibt, d. h. alles, was der Nutzer sieht. Je nach den Rückmeldungen von Implementationsteams und Nutzern ist es zu aktualisieren.
Das Pilotsystem für den Abfalleimer Bearbeiten
Wenn ein Team ein neuartiges System entwickelt, wird es – ob absichtlich oder nicht – zunächst ein „Wegwerfsystem“ erstellen. Dieses System dient als „Versuchsanlage“, um sogleich solche Verfahrensweisen aufzudecken, die später ein komplettes Redesign des Systems erfordern würden. Erst dieses zweite, smartere System sollte an den Kunden ausgeliefert werden, denn das Pilotsystem würde nichts als Qualen beim Kunden auslösen und womöglich den Ruf des Systems oder gar die ganze Firma ruinieren.
Formelle Dokumente Bearbeiten
Jeder Projektleiter sollte einen kleinen Satz von Dokumenten erstellen, die die Projektziele definieren, wie, durch wen und wann diese erreicht werden, und was dies kosten wird. Diese Dokumente können auch Unstimmigkeiten aufdecken, die anders schwer zu erkennen wären.
Schätzung des Zeitbedarfs Bearbeiten
Bei der Abschätzung von Projektzeiten sollte man bedenken, dass sowohl Programmprodukte (für zahlende Kunden) als auch Programmsysteme mindestens dreimal so aufwendig zu schreiben sind wie einfache, eigenständige innerbetriebliche Programme., S. 5 Fig. 1.1 Man sollte berücksichtigen, welcher Anteil an Arbeitszeit tatsächlich für technische Fragen aufgewendet wird, gegenüber administrativen oder anderen nicht-technischen Aufgaben wie (insbesondere Gesamt-) Teambesprechungen.
Kommunikation Bearbeiten
Um Unheil zu vermeiden, sollten alle an einem Projekt arbeitenden Teams auf möglichst vielfältige Weise miteinander in Kontakt bleiben – E-Mail, Telefon, Besprechungen, Memos usw. Statt bei einer zu implementierenden Funktion irgendetwas anzunehmen und mit einer möglicherweise falschen Annahme weiterzuarbeiten, sollten die Implementierer den (bzw. die) Architekten bitten, die mit dieser Funktion verfolgten Absichten zu erläutern. Der Architekt ist verantwortlich dafür, ein Gesamtbild des Projekts zu formulieren und den Anderen zu kommunizieren.
Das Ärzteteam Bearbeiten
Ähnlich wie ein Ärzteteam von einem Chefarzt geleitet wird, der selbst operiert und von seinem Team bestmögliche Hilfestellung erhält, erscheint es vernünftig, kritische Systemkomponenten von einem „guten“ Programmierer entwickeln zu lassen, während der Rest des Teams nach Bedarf zuliefert. Brooks sinniert weiter, dass „gute“ Programmierer meist fünf- bis zehnmal so produktiv seien wie mittelmäßige.
Code-Freeze und Versionsverwaltung Bearbeiten
Software ist unsichtbar. Daher wird bei einem neuen System manches erst dann augenfällig, wenn ein gewisser Entwicklungsaufwand erbracht ist, der dem Nutzer eigene Erfahrung mit dem System erlaubt. Diese Erfahrung kann zu Erkenntnissen führen, die die Anforderungen des Nutzers (oder deren Wahrnehmung) ändern. Dann sollte das System dementsprechend geändert werden, um den geänderten Anforderungen zu genügen. Dies kann jedoch nur bis zu einem gewissen Punkt geschehen, sonst wird das System womöglich nie fertig. Ab einem bestimmten Datum sollten keine Codeänderungen des Systems mehr erlaubt werden; der Code wird „eingefroren“ und alle weiteren Änderungsanforderungen werden bis zur nächsten Systemversion aufgeschoben.
Spezialwerkzeuge Bearbeiten
Statt dass jeder einzelne Programmierer seinen eigenen Satz an Spezialwerkzeugen nutzt, sollte jedem Team ein benannter „Werkzeugmacher“ angehören, der solche Werkzeuge erstellt, die den Aufgaben des Teams genau angepasst sind, z. B. ein Codegenerator, der Code entsprechend einer Spezifikation erzeugt. Zusätzlich sollten systemweit eingesetzte Werkzeuge von einem zentralen Werkzeugteam unter Aufsicht des Projektleiters geschaffen werden.
Reduzierung der Softwareentwicklungskosten Bearbeiten
Brooks beschreibt zweierlei Techniken, um Softwareentwicklungskosten zu senken:
- Implementierer werden erst beschäftigt, nachdem die Systemarchitektur fertiggestellt ist – ein Punkt, bis zu dem es mehrere Monate dauern kann, währenddessen vorzeitig eingestellte Implementierer nichts zu tun hätten.
- Alternativ erwähnt Brooks, Software überhaupt nicht zu entwickeln, sondern nach Möglichkeit einfach Standardsoftware einzusetzen.
Siehe auch Bearbeiten
Weblinks Bearbeiten
Einzelnachweise Bearbeiten
- ↑ Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on Software Engineering. Addison-Wesley, 1975, ISBN 978-0-201-00650-6 (amerikanisches Englisch, archive.org).
- ↑ Frederick P. Brooks: Vom Mythos des Mann-Monats. Essays über Software-Engineering. Addison Wesley, 1991, ISBN 978-3-925118-09-8 (amerikanisches Englisch: The Mythical Man-Month. Übersetzt von Arne Schäpers, Armin Hopp).
- Daniel Roth: Quoted Often, Followed Rarely. In: CNN. 12. Dezember 2005, abgerufen am 23. Oktober 2010.
- Jess Johnson: The Top 9½ In a Hacker’s Bookshelf. Abgerufen am 23. Oktober 2010.
- Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on Software Engineering. Addison-Wesley, 1995, ISBN 978-0-201-83595-3 (amerikanisches Englisch).
- ↑ Frederick P. Brooks: Vom Mythos des Mann-Monats. Essays über Software-Engineering. MITP, 2003, ISBN 978-3-8266-1355-5 (amerikanisches Englisch: The Mythical Man-Month. 1995. Übersetzt von Arne Schäpers).
- ↑ Hector Correa: The Mythical Man-Month. In: All Blog Posts. 28. Juni 2007, abgerufen am 8. Januar 2017 (englisch).
- Frederick. P., Jr. Brooks: No Silver Bullet – Essence and Accident in Software Engineering. In: Computer. Band 20, Nr. 4, 1987, S. 10, doi:10.1109/MC.1987.1663532 (salisbury.edu [PDF; abgerufen am 19. Januar 2017]).