Das Gesetz von Brooks ist ein Grundsatz in der Softwareentwicklung, die sagt, dass "das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt es später macht". Es wurde von Fred Brooks ins Leben gerufen seinen 1975 bestellen Den Mythischen Arbeitsmonat vor. Die Folgeerscheinung des Gesetzes von Brooks ist, dass es eine zusätzliche Person gibt, die, wenn hinzugefügt, zu einem Projekt, es mehr, nicht weniger Zeit nehmen lässt. Brooks fügt hinzu, dass "Neun Frauen kein Baby in einem Monat machen können".

Erklärungen

Gemäß Bächen selbst ist das Gesetz eine "unerhörte Vergröberung", aber es gewinnt die allgemeine Regel. Bäche weisen zu zwei Hauptfaktoren hin, die erklären, warum es dieser Weg arbeitet:

1. Es nimmt für die Leute Zeit in Anspruch hat zu einem Projekt beigetragen, produktiv zu werden. Bäche nennen das die "Rampe" Zeit. Softwareprojekte sind komplizierte Technikversuche, und neue Arbeiter auf dem Projekt müssen zuerst gebildet über die Arbeit werden, die ihnen vorangegangen ist; diese Ausbildung verlangt unterhaltsame Mittel, die bereits am Projekt provisorisch arbeiten, ihre Produktivität verringernd, während die neuen Arbeiter bedeutungsvoll noch nicht beitragen. Jeder neue Arbeiter muss auch mit einer Mannschaft integrieren, die aus vielfachen Ingenieuren zusammengesetzt ist, die den neuen Arbeiter in ihrem Gebiet des Gutachtens in der Codebasis tagtäglich erziehen müssen. Zusätzlich zum Reduzieren des Beitrags von erfahrenen Arbeitern (wegen des Bedürfnisses sich auszubilden) können neue Arbeiter sogar negative Beiträge - zum Beispiel haben, wenn sie Programmfehler vorstellen, die das Projekt weiter von der Vollziehung bewegen.
2. Die Nachrichtenzunahme der allgemeinen Kosten als die Anzahl der Leute nimmt zu. Die Zahl von verschiedenen Nachrichtenkanälen nimmt zusammen mit dem Quadrat der Anzahl der Leute zu; Verdoppelung der Anzahl der Leute resultiert in viermal so viel verschiedenen Gesprächen. Jeder, an derselben Aufgabe arbeitend, muss synchron so behalten, wie mehr Menschen hinzugefügt werden, verbringen sie mehr Zeit versuchend herauszufinden, was jeder sonst tut.

Ausnahmen und mögliche Lösungen

Das Gesetz von Bächen wird häufig zitiert, um zu rechtfertigen, warum Projekte fortsetzen, trotz Verwaltungsanstrengungen spät zu sein. Jedoch gibt es einige Stichpunkte im Gesetz von Bächen, die Ausnahmen erlauben und die Tür für mögliche Lösungen öffnen.

Der erste Punkt soll bemerken, dass das Gesetz von Bächen häufig für Projekte gilt, die bereits spät sind. Projekte können in zurückgebracht (oder in behalten werden) Kontrolle, wenn Leute früher im Prozess hinzugefügt werden. Es ist auch wichtig zu bestimmen, ob das Projekt wirklich spät ist, oder wenn die Liste ursprünglich allzu optimistisch war. Die Terminplanung von Fehlern ist für eine Vielzahl von späten Projekten verantwortlich. Das Korrigieren der Liste ist die beste Weise, einen bedeutungsvollen und zuverlässigen Zeitrahmen für die Vollziehung des Projektes zu haben.

Die Menge, Qualität und Rolle der Leute haben zum Projekt beigetragen auch muss in Betracht gezogen werden. Eine einfache Weise, das Gesetz über ein überflutetes Projekt zu überlisten, soll mehr Menschen hinzufügen als erforderlich auf solche Art und Weise dass die Extrakapazität die Ausbildung und Kommunikation oben ersetzt. Gute Programmierer oder Fachmänner können mit dem weniger oberirdischen für die Ausbildung hinzugefügt werden. Leute können hinzugefügt werden, um andere Aufgaben zu erledigen, die mit dem Projekt, zum Beispiel, der Qualitätssicherung oder der Dokumentation verbunden sind; vorausgesetzt, dass die Aufgabe, Rampe klar ist, wird Zeit minimiert.

Gutes Management und Entwicklungsmethoden helfen auch, den Einfluss des Gesetzes von Bächen zu minimieren. Die modernen Methoden der dauernden Integration, prüfen Sie das erste Design, und wiederholende Entwicklung reduziert bedeutsam die Zwischenentwickler-Kommunikation oben, und berücksichtigt so bessere Skalierbarkeit. Neue Werkzeuge für die Softwareentwicklung und Dokumentation helfen auch, die Rampe Zeit zu minimieren, es einfacher für neue Programmierer machend, an der Arbeit beteiligt zu werden. Designmuster vereinfachen den Vertrieb der Arbeit, weil die komplette Mannschaft seinen Teil innerhalb des durch dieses Muster zur Verfügung gestellten Fachwerks tun kann. Das Designmuster definiert die Regeln, dass die Programmierer folgen, vereinfacht Kommunikation durch den Gebrauch einer Standardsprache, und stellt Konsistenz und Skalierbarkeit zur Verfügung. Schließlich hilft gute Segmentation durch die Minderung der Kommunikation oben zwischen Gruppenmitgliedern. Kleinere Teilprobleme werden von einer kleineren Mannschaft gelöst, und eine Mannschaft auf höchster Ebene ist für die Systemintegration verantwortlich. Für diese Methode, zu arbeiten, muss die Segmentation des Problems richtig an erster Stelle getan werden; wenn getan, falsch kann das das Problem schlechter, nicht besser, durch das Behindern der Kommunikation zwischen Programmierern machen, die an Teilen des Problems arbeiten, die wirklich nah verbunden werden, selbst wenn der Projektplan angeordnet hat, dass sie nicht sind.

Einige Autoren - sehen zum Beispiel, das Schaffen einer Softwaretechnikkultur durch Karl E. Wiegers - hat die Wichtigkeit von den sozialen und politischen Aspekten des Arbeitsklimas als Determinanten der Wirksamkeit von individuellen Programmierern und der Projektmannschaft als Ganzes betont. Anstatt abhängig von Helden, um mit außergewöhnlichen Anstrengungen den Sieg davonzutragen, behauptet Wiegers, dass eine Mannschaft von normalerweise Fachpersonen rechtzeitige Ergebnisse in der richtigen Arbeitsumgebung wiederholt liefern kann. Anstrengungen, die Wirksamkeit von Mannschaften zu verbessern, können sich bessern, wenn nicht, die Folgen des Gesetzes von Brooks beseitigen.

Offene Quellsoftwareentwicklung

Während offene Quellprojekte selten Listen haben, dennoch können sie einen Staat erreichen, in dem sie "spät" von ihren Förderern, Teilnehmern und Benutzern genannt werden. In solch einem Fall gilt das Gesetz von Brooks ("das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später"), sicher aus genau den Gründen, dass Brooks aufzählt: Zeit für die neuen Entwickler, um produktive und vergrößerte Kommunikation oben zu werden. Außerdem, wenn es strenge Steuerungen nicht gibt, können Neulinge die Produktivität von erfahrenen Entwicklern reduzieren, indem sie verwanzte oder unpassende Änderungen einchecken, die dann zurückgetreten werden müssen.

Siehe auch

• Trauermarsch
• Antimuster
• Liste von namensgebenden Gesetzen
• Liste von Softwareentwicklungsphilosophien

Zeichen

• Steve McConnell. "Das Aufgehobene Gesetz von Bächen," IEEE Software, vol. 16, Nr. 6, Seiten 6-8, November/Dez 1999. Auch verfügbar an der Autor-Website (das Gesetz von Bächen aufgehoben?).
• Pei Hsia, Chih-tung Hsu, David C. Kung. "Das Wieder besuchte Gesetz von Bächen: Eine Systemdynamik-Annäherung," compsac, p. 370, die Dreiundzwanzigste Jährliche Internationale Computersoftware und Anwendungskonferenz, 1999.
• R. L. Gordon und J. C. Lamb. "Ein Naher Blick auf das Gesetz von Bächen," Datamation, Juni 977, Seiten 81-86.
• Das Gesetz von Bächen und offene Quelle: Mehr das fröhlichere?
• Das Gesetz von Bächen ist auf viele zusammenarbeitende Menschentätigkeiten anwendbar