- 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
Noch keine Kommentare.