Wissen Sie welches die effektivste Teamgröße für ein mittelgroßes Softwareprojekt ist ?

Es sind tatsächlich Teamgrößen von “nur” 2-7 Personen.
(https://www.qsm.com/process_improvement_01.html)

Jedes Team das größer ist, arbeitet langsamer, das Ergebnis hat mehr Fehler und das Produkt erfüllt weniger gut seine Anforderungen.

Aber woran liegt das ?

Eine sehr genaue und umfangreiche Betrachtung findet sich in dem Buch “The Mythical Man-Month” von Fred Brooks, deren Kern ich hier kurz zusammenfassen möchte:

Softwareentwicklung ist zwar eine Tätigkeit die viele Werkzeuge, Standards und Methoden hat und man sollte annehmen, ähnlich wie bei der Produktion eines Autos kann man diese Tätigkeit beliebig aufteilen und optimieren.

Hier liegt aber oft der Denkfehler in dieser Analogie – die Produktion eines Autos entspricht nicht der Tätigkeit einer Softwareentwicklung, der korrekte Vergleich wäre entweder zwischen Softwareentwicklung und Konstruktion eines Autos oder der Produktion eines Autos und das Kopieren einer Software.

Wir sehen, Softwareentwicklung ist nicht nur ein technischer Prozesse, sondern zusätzlich auch ein kreativer- oder genauer ein Lernprozess. Die Entwicklung gliedert sich in 3 Grundschritte, die immerwieder durchlaufen werden:

  1. Das Problem verstehen
  2. Eine passende Lösung erarbeiten
  3. Die Lösung in die schon gelösten Teile integrieren

Man kann erkennen, dass schon Schritt 2 und 3 eigentlich nicht losgelöst voneinander betrachtet werden können, weil eine “passende Lösung” auch immer eine Lösung sein muss, die sich integrieren lässt.

Hinzu kommt, dass die Komplexität exponentiell wächst mit jedem Problem/Lösung-Paar das hinzukommt, da jedes Teil der Software mit allen anderen Teile korrekt zusammenarbeiten muss.

Genau hier entsteht der Flaschenhals bei zuvielen Teammitgliedern, es ist nicht mehr möglich in einer angemessenen Zeit alle Teammitglieder auf dem aktuellen Stand zu halten und immer mehr Mitglieder erfassen immer nur noch einen Teil der Gesamtsoftware, nur noch wenige oder am Ende garkeiner hat mehr den kompletten Überblick.
Stellen Sie sich vier Maler vor, von denen jeder nur einen Teil eines Bildes malt, auch wenn diese vorher abgesprochen haben, was das Motiv (Requirements) sein soll, und wie die Übergänge (Interfaces) aussehen sollen, werden diese mit hoher Wahrscheinlichkeit immer ruppig oder sogar garnicht zusammenpassend sein, wenn nicht jeder Maler immerwieder nachschaut was sein Kollege “auf der anderen Seite” gemacht hat. 

Und warum gibt es dann so viele große Teams bei Softwareprojekten ?

Man kann große Softwareprojekte natürlich nicht mehr mit 5-7 Personen in einer angemessenen Zeit realisieren, deswegen muss ab einer gewissen Größe eines Projekts das Team größer werden.

Der Zugewinn an Zeit wird aber “teuer” erkauft indem deutlich mehr Verwaltungs-, Qualitätssicherungs- und Controllingaufwand betrieben werden muss.

Es gibt sicher viele Projekte die besser, schneller und fehlerfreier realisiert hätten werden können, wenn weniger Entwickler/innen beteiligt gewesen wären.

Und was heisst das jetzt ?

Bei Softwareentwicklung gilt definitv nicht “viel hilft viel”, deswegen, schauen Sie genau hin, wenn Ihnen ein Softwarehaus auffällig viele Entwickler verspricht und damit ein Projekt dann im Bruchteil der Zeit erledigen will – das könnte ins Auge gehen.

Auf der anderen Seite, trauen Sie kleinen Teams zu auch mittlgroße Projekte zu realisieren, Sie werden überrascht sein, wie schlagkräftig eine kleine Truppe sein kann.