Wie schätzt man Softwarearbeit?
(seangoedecke.com)- Eine genaue Schätzung der Dauer von Softwareprojekten ist unmöglich, und die meisten Aufgaben werden von unvorhersehbarer, „unbekannter Arbeit“ bestimmt
- Schätzungen werden nicht von Engineers, sondern als politisches Werkzeug des Managements genutzt und dienen dazu, Projektprioritäten und Mittelverteilung festzulegen
- In der Praxis definiert die Schätzung die Arbeit; Teams arbeiten also so, dass sie innerhalb des vorgegebenen Zeitraums einen technisch machbaren Ansatz finden
- Für effektive Schätzungen sollten Engineers sich auf das Verstehen des politischen Kontexts, die Bewertung unbekannter Risiken und das Aufzeigen mehrerer Umsetzungsszenarien konzentrieren
- Dieser Ansatz legt den Schwerpunkt eher auf Vertrauen und realistische Zusammenarbeit als auf Genauigkeit und betont technische Kompetenz beim Verständnis von Entscheidungsstrukturen in Organisationen
Die Fiktion der Softwareschätzung
- In der Branche existiert die „höfliche Fiktion“, dass erfahrene Teams mit genug Aufwand Zeitpläne präzise vorhersagen können
- Tatsächlich erkennen die meisten Engineers, dass genaue Vorhersagen unmöglich sind
- Manche Teams schätzen mit T-Shirt-Größen, doch am Ende werden diese trotzdem in Zeiteinheiten umgerechnet und an die Managementebene weitergegeben
- Mitunter werden unrealistische Heuristiken verwendet, etwa: „Nimm die erste Schätzung, verdopple sie und schlage 20 % drauf“
Warum Schätzungen unmöglich sind
- Kleine, klar definierte Aufgaben sind vorhersagbar, aber die meisten Projekte finden in unsicheren und komplexen Systemen statt
- Beispiel: Eine einfache Änderung des Linktexts lässt sich auf 45 Minuten schätzen, eine große Systemänderung dagegen nicht
- Der Großteil der Programmierung ist explorative Forschungsarbeit; allein durch Vorausplanung lässt sich nicht erkennen, welche Arbeit tatsächlich nötig sein wird
- Frühere zentralisierte Architekturplanungsansätze sind gescheitert; Entscheidungen müssen von den Entwicklern getroffen werden, die mit dem tatsächlichen Code arbeiten
- Im Ergebnis sind nur etwa 10 % der Arbeit bekannt, während die übrigen 90 % wegen unbekannter Faktoren nicht schätzbar sind
Schätzung ist ein Werkzeug des Managements, nicht der Engineers
- Schätzungen haben nichts mit der Produktivitätssteigerung von Teams zu tun, und viele leistungsfähige Teams arbeiten auch ganz ohne Schätzungen
- Das Management versucht, Schätzungen an das gewünschte Ergebnis anzupassen: lange Zeitpläne werden gekürzt, kurze Zeitpläne bekommen zusätzlichen Puffer
- Nur technisch unmögliche Projekte führen ausnahmsweise zu einer realistischen Neubewertung
- In Bereichen mit geringer organisatorischer Aufmerksamkeit bleiben formale Prozesse dagegen oft einfach bestehen
- Deshalb funktionieren Schätzungen als politisches Mittel, mit dem Nicht-Techniker Projekte auswählen oder stoppen
Die Schätzung definiert die Arbeit
- Anders als oft angenommen wird nicht zuerst die Arbeit festgelegt, sondern zuerst die Schätzung, und danach wird der passende technische Ansatz bestimmt
- Beispiel: Die Umsetzung einer Funktion zum „Mit PDFs chatten“ in sechs Monaten erfordert einen völlig anderen Ansatz als dieselbe Funktion an einem einzigen Tag
- Zeitliche Vorgaben bestimmen Tiefe und Qualität des Codedesigns, und Engineers wählen die innerhalb des gegebenen Zeitrahmens machbare Lösung
Wie tatsächlich geschätzt wird
- Zuerst muss man den politischen Kontext verstehen, also die Bedeutung des Projekts und den erwarteten Zeitrahmen
- Danach werden ausgehend vom bereits festgelegten Zeitraum mögliche Ansätze untersucht
- Je mehr unknowns es gibt, desto größer fällt die Schätzung aus und desto enger muss der Lösungsraum gefasst werden
- Am Ende präsentiert man nicht eine exakte Dauer, sondern eine Risikobewertung und mehrere Umsetzungsszenarien
- Zum Beispiel: alles selbst lösen, Teile umgehen oder Unterstützung von einem anderen Team anfordern
- Die Aufgabe von Engineers ist nicht „Wie lange dauert es?“, sondern „Welche Vorgehensweise ist im gegebenen Zeitrahmen möglich?“
Einwände und Reaktionen
- Manche Engineers vermeiden Schätzungen unter unsicheren Bedingungen, doch das führt nur dazu, dass Nicht-Techniker stattdessen schätzen
- Eine Haltung der ständigen Konfrontation statt Zusammenarbeit mit dem Management ist unproduktiv und untergräbt Vertrauen
- Teams, die keinen Druck spüren, arbeiten womöglich einfach in einem Bereich außerhalb des organisatorischen Fokus
Fazit
- In der Praxis treten Manager bereits mit einem Zeitrahmen an das Team heran, den sie im Kopf haben, und das Team sucht darin nach einer technisch machbaren Lösung
- Schätzungen sind ein Verhandlungswerkzeug zwischen Führungskräften, und nur unmögliche Projekte können ausnahmsweise die Realität klar vermitteln
- Eine gute Schätzung sollte nicht aus einer exakten Zahl bestehen, sondern Risiken und Optionen aufzeigen
- Eine präzise Schätzung von Softwarearbeit ist unmöglich, und erfolgreiche Schätzungen hängen davon ab, unbekannte Risiken zu erkennen und damit umzugehen
2 Kommentare
Oho
Hacker-News-Kommentare
Ich teile meine leicht scherzhaft gemeinte Projekt-Schätztabelle
Für interne Projekte (z. B. Vendor-Migrationen ohne Auswirkungen auf Nutzer) setze ich einen Zeitraum an, der gegenüber dem Management plausibel vermittelbar ist
Projekte mit Auswirkungen auf Nutzer (z. B. neue Features) laufen, solange der ROI positiv ist
Bei Projekten, die Zusammenarbeit mit externen Partnern erfordern, legt das Vertriebsteam den Liefertermin fest, und das Engineering-Team passt die Definition des MVP leicht an, damit sie in den Zeitplan passt
Ich habe mich gefragt, warum niemand über Planning Poker oder Story Points spricht
Nicht perfekt, aber eine ziemlich gute Methode. Alle Arbeiten sollten innerhalb eines Sprints abgeschlossen werden; wenn etwas zu groß ist, muss es aufgeteilt werden
Das ganze Team muss sich auf die Punkte einigen, und genau dabei entsteht der eigentliche Wert der Diskussion
Nach ein paar Monaten stabilisiert sich die Geschwindigkeit des Teams, und Vorhersagen werden mit einer Genauigkeit von etwa ±10 % möglich
Es ist keine Magie, aber es hilft dabei, kontinuierlich Wert zu liefern und in jedem Sprint den Nutzen im Verhältnis zu den Kosten neu zu bewerten
Bei jemandem, der neu im Team ist, kann dasselbe Ticket leicht mehr als doppelt so lange dauern
Außerdem schafft die Organisation Regeln wie „PR-Reviews müssen innerhalb von 24 Stunden abgeschlossen sein“, was eine Kluft zur Realität erzeugt
Entwickler und QA schätzen gemeinsam, indem sie die Komplexität vergleichen, und QA bewertet die Schwierigkeit der Tests oder die Möglichkeit zur Automatisierung
Dadurch sind die Metriken zur Entwicklungsgeschwindigkeit stabil, und auch die Schätzungen pro Version sind ziemlich genau
Sie sind nur sinnvoll, wenn das ganze Team ein gemeinsames Verständnis der kleinsten Einheit hat und diese in Zeit umrechnen kann
Dann kann man letztlich auch einfach direkt Zeit verwenden, wodurch die Punkte selbst überflüssig werden
Ich schätze auf Basis von Konfidenzintervallen, indem ich in den Einheiten „2 Stunden, 2 Tage, 2 Wochen, 2 Monate, 2 Jahre“ frage
Wenn die Spannweite zu groß ist, teile ich weiter auf; wenn das nicht möglich ist, entscheide ich, ob es sinnvoll ist, Zeit in zusätzliche Informationsbeschaffung zu investieren
Wenn nicht, wird das Projekt verworfen
Wenn man das Ergebnis klar definiert und die Idee in einzelne Schritte zerlegt, werden realistische Schätzungen möglich
Wenn man es nicht auf Tage oder Wochen herunterbrechen kann, ist die Planung noch nicht ausgereift
In solchen Fällen lernt man durch das fortlaufende Ausprobieren verschiedener Ansätze, deshalb halte ich Schätzungen dort für schwierig
Sie führen zu einem handlungsorientierten Denken statt zu bloßen Längenschätzungen
Ich hatte einmal einen Sprint dafür angesetzt, Passwörter von Klartext auf Hashes zu migrieren, tatsächlich dauerte es aber 6 Monate
Wir haben erst durch ein Video eines Kunden gemerkt, dass Passwörter dort ohne Unterscheidung von Groß- und Kleinschreibung verwendet wurden
Dazu kam noch ein Build-Fehler, weil ein PHP-Image gelöscht worden war
Schätzen ist immer ein unterhaltsames Abenteuer
Es zeigt auf Basis realer Projektdaten Statistiken zu Budgetüberschreitungen
IT-Projekte liegen im Schnitt 73 % darüber und sind damit nach Atommülllagern, Olympischen Spielen und Wasserkraftprojekten die viertschlechtesten
18 % der IT-Projekte überschreiten das Budget um mehr als 50 %, und bei diesen liegt die durchschnittliche Überschreitung bei 447 %
Am Ende zeigt das, dass Schätzungen in den meisten Branchen strukturell optimistisch sein müssen
Ich finde es erstaunlich, dass viele Engineers und Manager nicht auf Basis von Metriken aus früheren Projekten schätzen
Wenn man die Durchsatzdaten des Teams hat, kann man grobe Zeiträume und Konfidenzintervalle (z. B. 90 %, 70 %, 50 %) berechnen
So kann man auch externen Stakeholdern einen probabilistischen Kontext geben
Viele Engineers empfinden das jedoch als administrativen Aufwand
Gute Praxis ist die Verwendung von Intervallschätzungen, bei denen wie bei PERT Best Case, Erwartungswert und Worst Case modelliert werden
Gerade die besten Techniker neigen bei ihren eigenen Zeitschätzungen zu Überconfidence
Dass jede Person ihre Schätzung abgibt und man danach 20 % aufschlägt, hat bei uns ziemlich gut funktioniert
Wenn das Management einen Termin vorgibt, sollte man erklären, welcher Umfang in dieser Zeit machbar ist, oder eine Neuschätzung nach klarer Scope-Definition vorschlagen
Referenz: PMI PMP, PMBOKs Lessons Learned Repository
Aus Vorhersagen lernt man über Fehler, während Vorgaben eher zu Produktivitätsdruck führen
Ich betrachte Schätzen als Verhandlungsprozess
Wie bei Autoausstattungen biete ich drei Optionen an: Economy, Mid-tier und Luxury
Das Business will immer die Funktionen von Option 3 zum Budget von Option 1, also passe ich am Ende die Lage entsprechend an
Wenn man einen Plan Nr. 1 vorbereitet hat, kann man in Krisen schnell umschalten und während der Verhandlung die Kosten von Abkürzungen sichtbar machen
So konnte ich schon mehrfach irrationale Entscheidungen von gestressten PMs oder Führungskräften vermeiden
Ich arbeite an großen verteilten Systemen auf FAANG-Niveau, und dort sind genaue Schätzungen fast unmöglich
Es gibt zu viele unknown unknowns, und schon Prototypen erfordern enorme Datenmengen und viel Zeit
Deshalb fokussiere ich mich eher auf Umgang mit Unsicherheit als auf Schätzungen
Die verlässlichste Methode ist der Vergleich mit ähnlichen Projekten
So nach dem Muster: „Das ist 20 % komplexer als Projekt X, also wird es 20 % länger dauern“
Dafür muss man allerdings die tatsächlichen Aufwandsdaten früherer Projekte konsequent erfassen
Anfangs wollte ich der Aussage widersprechen, dass „Schätzen unmöglich ist“, aber inzwischen glaube ich, dass die Rolle innerhalb der Organisation wichtiger ist
Selbst wenn das Team anhand seiner Kapazität und der Schätzung sagt, dass etwas nicht machbar ist, ändert sich der Termin nicht
Am Ende wird es dann durch Scope-Reduktion oder Qualitätskompromisse passend gemacht
Deshalb ist vielleicht die Aussage „Schätzungen sind nutzlos“ treffender
Ich habe das Gefühl, dass der Kern von Schätzungen Mehrdeutigkeit (ambiguity) ist
Etwas Kleines wie Feintuning an der UI wirkt harmlos, ist aber oft Arbeit, bei der man erst währenddessen lernt
Umgekehrt kann auch eine große Änderung schnell fertig sein, wenn sie klar definiert ist
Im Zeitalter der LLMs wird eher der Grad der Unsicherheit als die Größe der Veränderung darüber entscheiden, wie lange etwas dauert