Die Wikipedia-Seite zu Brook's Law enthält den folgenden Satz:
Der Bermuda-Plan, bei dem die meisten Entwickler eines Projekts entfernt werden ("nach Bermuda geschickt") und die verbleibenden die Software fertigstellen, wurde als Möglichkeit vorgeschlagen, das Gesetz von Brooks zu umgehen.
(Das Gesetz selbst formulierte kurz: „Personen zu einem späten Softwareprojekt hinzuzufügen, macht es später“.)
Dem Satz folgt ein Zitat, das aus einem Link zur Ausgabe von InfoWorld vom 7. Mai 1984 besteht, was deutlich macht, dass der Vorschlag mit einem Augenzwinkern präsentiert wird.
Ich bin jedoch neugierig, ob es jemals jemand versucht hat, und wenn ja, was die Ergebnisse waren. Ich weiß, dass es im Projektmanagement oft schwierig ist, gute Zahlen zu bekommen, aber wenn es Beispiele gibt, bei denen eine quantifizierbare Vorher-Nachher-Messung durchgeführt wurde, würden sie bevorzugt werden.
Ich erwarte nicht, dass irgendeine Organisation jemals buchstäblich Programmierer nach Bermuda geschickt hat. Ich gehe davon aus, dass ein wahrscheinlicheres Szenario darin besteht, dass einige Programmierer zu einem anderen Projekt versetzt wurden (oder vielleicht Entlassungen stattfanden, vielleicht sogar solche, die durch die jüngsten Ereignisse angespornt wurden), wodurch eine kleinere Anzahl von Programmierern in einem Projekt blieb.
Weiß jemand etwas über ein oder mehrere Fälle, in denen ein Softwareteam aus welchen Gründen auch immer kleiner wurde, und wir die Qualität und/oder das Volumen der Ausgabe vorher und nachher vernünftig vergleichen können?
Die drei Hauptgründe, warum ein spätes Projekt später endet, wenn mehr Leute hinzugefügt werden, sind - wie auf der Wikipedia-Seite ausgeführt :
Die neuen Leute müssen lernen, also nehmen sie sich Zeit von den bestehenden Leuten im Team, um Hilfe zu bekommen. Also weniger Ressourcen, um die Arbeit zu erledigen, während die neuen Leute produktiv werden und tatsächlich anfangen, etwas beizutragen.
Die Kommunikation nimmt zu. Auch hier weniger Ressourcen für die Arbeit, während die Mitarbeiter mehr Zeit damit verbringen, herauszufinden, was alle anderen tun.
Manche Arbeit lässt sich nicht schön in einzelne Teile aufteilen, die parallel erledigt werden können. Eine Person ist möglicherweise effizienter bei der Erledigung einer Aufgabe, als Zeit damit zu verbringen, die Aufgabe aufzuteilen, dann baut jeder ein Stück und verbringt dann Zeit damit, alles wieder zusammenzusetzen. Wenn Sie Multithread-Programmierung durchgeführt haben, wissen Sie, dass einige Jobs manchmal schneller sind, wenn sie in einem einzelnen Thread ausgeführt werden, als in mehreren Threads parallel.
Sehen wir uns also an, wo sich der Bermuda-Plan als mögliche Lösung erweisen könnte:
Es hilft mit 3, wenn Sie die Art von Aufgaben haben, die nicht gut aufgeteilt werden können, oder wenn Sie einen Manager haben, der versucht, die Leute zu 100% zu beschäftigen (und was gibt es Besseres, als jedem ein Stück davon zuzuwerfen größere Aufgabe, wenn keine andere Arbeit für sie verfügbar ist).
Es hilft bei 2, weil die Kommunikation abnimmt und mehr Ressourcen für die Arbeit aufgewendet werden. Wie bereits in einer anderen Antwort darauf hingewiesen, wissen wir aus Agile, dass kleinere Teams oft effektiver sind als größere.
Punkt 1 fällt weg, weil Sie niemanden schulen müssen. Das verbleibende Team konzentriert sich nur auf die Arbeit.
Garantieren diese Punkte also irgendetwas? Nein. In allen drei Fällen verringert der Bermuda-Plan nur die Anzahl der Ressourcen, während der Arbeitsaufwand gleich bleibt. Wir wissen, dass 9 Frauen in einem Monat kein Baby bekommen können, aber eine halbe Frau kann auch kein Baby nach dem ursprünglichen Zeitplan von 9 Monaten gebären .
Sie profitieren nur dann von der Entfernung von Personen, wenn der Kommunikationsaufwand und die Aufteilung von Aufgaben tatsächlich das Problem sind. Oder offensichtlich, ob das Hauptproblem für die Verzögerung bei den Leuten lag, die aus dem Team entfernt wurden.
Es kommt also sehr auf den Kontext an . Wenn das Problem und der Lösungsansatz übereinstimmen, kann der Bermuda-Plan eine mögliche Lösung sein. Keine Übereinstimmung, keine Lösung.
Brooks's Law muss vielleicht aktualisiert werden. Unter modernen Bedingungen ist die Teamgröße wahrscheinlich wichtiger als die Gesamtgröße eines Projekts oder Workstreams. Viele Organisationen organisieren ihre Softwareentwicklung in kleinen, funktionsübergreifenden Teams und stellen fest, dass mehrere kleine Teams (häufig weniger als 10 Personen) produktiver sein können als ein großes Team. Das wurde schon oft versucht, denn die Verkleinerung von Teams ist ein gängiges Thema agiler Transformationsprogramme.
Unabhängig vom Glauben an die eine oder andere Entwicklungsmethode oder den Glauben an dieses „Gesetz“ gilt für jede Aktivität, dass es eine unbekannte Anzahl von sowohl aleatorischen als auch epistemischen Treibern gibt, die die Ergebnisse des Zeitplans beeinflussen. Und Aufgaben haben unterschiedliche Grade an Ressourcenelastizität, und eine einzelne Aufgabe kann je nach Umgebung, in der die Aufgabe ausgeführt wird, unterschiedliche Grade an Elastizität haben. Der Versuch, einer Intervention die Güte zuzuschreiben – ob Sie die Teamgröße erhöhen, verkleinern oder eine Glühbirne austauschen (Hawthorne) – ist keine leichte Aufgabe, und man könnte leicht in das Geschäft geraten, zu bestätigen, was er glaubt wahr als das, was wirklich wahr ist. Ich kann mir nicht einmal die Meta-Längsschnittstudie vorstellen, die an einem umfangreichen Projektsatz – mit einem Kontrollsatz – mit dokumentierter „reduzierter Personalgröße“ durchgeführt und wiederholt werden müsste.
Was Sie zweifellos bekommen werden, sind Anekdoten und ein schwerer Fall von Bestätigungsverzerrung, insbesondere von denen, die die eine oder andere Methode strikt befolgen.
Was meiner Meinung nach wahr ist, ist, dass wir viel weniger Kontrolle über Kosten und Zeitplanergebnisse haben, als wir glauben wollen.
Tiago Cardoso