Software-Schätzung: Warum sie schwer ist und wie man sie weniger schlecht macht

Jeder Entwickler wurde schon gefragt "Wie lange dauert das?" und hat irgendwann eine Antwort gegeben, die um den Faktor zwei oder mehr daneben lag. Software-Schätzung ist der Teil des Jobs, in dem die meisten am schlechtesten sind und es am wenigsten zugeben wollen. Kunden erleben das als gebrochene Versprechen. Manager erleben es als Roadmaps, die jedes Quartal ein Stück weiter rutschen.

In diesem Beitrag geht es darum, warum Schätzungen schiefgehen und was wir bei Wolf-Tech dagegen tun. Niemand schätzt Software gut. Das realistische Ziel ist, sie weniger schlecht zu schätzen und ehrlich zu sein über die Teile, die man noch nicht wissen kann.

Warum Software-Schätzung scheitert

Entwickler sind Optimisten, aber die nützlichere Beobachtung ist, dass Schätzungen auf wiederholbare Weise scheitern. Sobald du die Fehlermuster benennen kannst, kannst du Abwehrmechanismen dagegen aufbauen.

Das erste sind unbekannte Unbekannte. Wenn du ein Feature schätzt, zerlegst du es in die Teile, die du sehen kannst: eine Migration, einen Endpoint, ein Formular, ein paar Tests. Was du nicht sehen kannst: dass die Drittanbieter-API, die du anbindest, dich auf 10 Anfragen pro Sekunde drosselt, dass die Legacy-Tabelle, die du lesen musst, keinen Primärschlüssel hat oder dass der SSO-Anbieter des Kunden den Flow nicht unterstützt, den du angenommen hast. Nichts davon stand auf der Liste, weil du nicht wusstest, dass es existiert. Bottom-up-Schätzung zählt nur die Arbeit, die du dir vorstellen kannst, und die Arbeit, die du dir nicht vorstellen kannst, ist die, in die die Zeit fließt.

Das zweite ist der Planungsfehlschluss. Kahneman und Tversky haben ihn in den 1970ern beschrieben, und er hat sich bestätigt: Menschen schätzen ihre eigenen Aufgaben, indem sie sich den besten Fall vorstellen, in dem nichts schiefgeht, selbst wenn sie persönlich viele Fälle erlebt haben, in denen etwas schiefging. Du weißt, dass deine letzten fünf Migrationen jeweils eine Woche länger gedauert haben als geplant. Trotzdem schätzt du die sechste so, als wäre sie die erste saubere.

Das dritte ist fehlendes Referenzmaterial. Die meisten Teams halten nicht fest, wie lange Dinge tatsächlich gedauert haben, also entsteht jede Schätzung neu, aus dem Bauch, mit demselben Optimismus wie die letzte.

Das vierte Problem betrifft eher das Vokabular als die Psychologie.

Aufwand ist nicht Dauer

"Drei Tage" kann drei Tage konzentrierte Arbeit einer Person bedeuten, oder dass das Feature in drei Tagen ab jetzt fertig ist. Das sind Aufwand und Dauer, und sie zu verwechseln ist wahrscheinlich die häufigste Ursache für eine verpasste Deadline, die nichts mit dem Code zu tun hatte.

Aufwand sind verbrauchte Arbeitsstunden. Dauer ist Kalenderzeit zwischen Start und Ende. Die Dauer ist immer länger, denn die Person, die die Arbeit macht, sitzt auch in Meetings, reviewt Pull Requests, wartet auf Staging, wartet auf die Antwort des Kunden auf eine Frage und wird am Dienstag in einen Produktionsvorfall gezogen. Ein nominell in Vollzeit arbeitender Entwickler hat oft 50 bis 60 Prozent seiner Stunden für die Umsetzung verfügbar. Aus drei Tagen Aufwand wird eine Woche Dauer, ohne dass irgendetwas schiefgeht.

Kunden hören Dauer. Entwickler meinen meist Aufwand. Sag jedes Mal, welches von beiden du meinst. Wir nennen beides: Aufwand in Personentagen und das früheste realistische Kalenderdatum angesichts der verfügbaren Personen.

Reference Class Forecasting

Die beste Korrektur für den Planungsfehlschluss ist, die Aufgabe von außen zu betrachten. Statt zu fragen "Was sind die Schritte und wie lange dauert jeder", frag "Als wir so etwas früher gemacht haben, wie lange hat es gedauert?"

Das ist Reference Class Forecasting. Es wurde für große Infrastrukturprojekte entwickelt und funktioniert im Maßstab eines Zwei-Wochen-Features genauso gut. Du brauchst eine Referenzklasse (vergangene Aufgaben, die ähnlich genug sind, um vergleichbar zu sein) und eine Aufzeichnung dessen, was tatsächlich mit ihnen passiert ist.

Die Referenzklasse muss nicht präzise sein. "Integrationen mit einem Zahlungsanbieter, den wir noch nicht genutzt haben" ist eine Referenzklasse. Wenn deine letzten vier 6, 9, 11 und 14 Personentage gebraucht haben, beginnt deine Schätzung für die fünfte bei dieser Verteilung, und du passt nur an, wenn du auf einen konkreten Grund zeigen kannst, warum diese anders ist. "Diese wirkt einfacher" ist der Planungsfehlschluss, der da spricht.

Die meisten Teams halten die Daten nicht fest. Fang jetzt an. Eine Tabelle mit Aufgabenname, Kategorie, ursprünglicher Schätzung und tatsächlichem Aufwand reicht. Nach sechs Monaten ist sie mehr wert als jede Schätztechnik.

Drei-Punkt-Schätzungen

Wenn du doch bottom-up schätzen musst, weil die Arbeit neu ist oder die Referenzklasse leer, ist eine einzelne Zahl das falsche Ergebnis. Nimm drei.

Schreib für jede Aufgabe eine optimistische Schätzung auf (alles läuft glatt), eine realistische (die übliche Menge Reibung) und eine pessimistische (das, wovor du dich fürchtest, tritt ein). Die klassische PERT-Gewichtung kombiniert sie als (optimistisch + 4 × realistisch + pessimistisch) / 6, was einen Erwartungswert ergibt, der zum realistischen Fall tendiert, aber vom pessimistischen Ende nach oben gezogen wird.

Die Zahl ist weniger wichtig als die Übung. Einen pessimistischen Fall aufzuschreiben zwingt dich, das Risiko zu benennen. "Pessimistisch: 8 Tage, falls die API-Sandbox des Kunden so unzuverlässig ist, wie seine Doku vermuten lässt" ist etwas, worauf man reagieren kann; jemand kann die Sandbox prüfen, bevor das Projekt startet. Eine einzelne Schätzung von "4 Tagen" versteckt dieses Risiko.

Auch die Spanne ist Information. Eine Aufgabe, die auf 2 bis 3 Tage geschätzt wird, ist gut verstanden. Eine Aufgabe mit 2 bis 12 Tagen ist es nicht, und sie sollte nicht als 5-Tage-Aufgabe behandelt werden, nur weil das der gewichtete Durchschnitt ist. Sie braucht Untersuchung, bevor sich jemand auf ein Datum festlegt.

Der Cone of Uncertainty

Der Cone of Uncertainty, bekannt gemacht von Steve McConnell, beschreibt, wie Schätzungen besser werden, je mehr du lernst: Ganz am Anfang eines Projekts, bevor die Anforderungen feststehen, kann eine Schätzung um den Faktor vier in beide Richtungen danebenliegen. Sobald die Anforderungen abgestimmt sind, verengt sich die Spanne auf etwa plus oder minus 50 Prozent; nach Design und etwas Implementierung auf plus oder minus 20 Prozent. Erst gegen Ende konvergiert sie auf den tatsächlichen Wert.

Über die exakten Multiplikatoren wird gestritten. Was zählt, ist die Form. Wenn jemand im ersten Meeting nach einer Zahl fragt, hat die ehrliche Antwort eine weite Spanne, und eine enge in diesem Stadium ist eine Vermutung mit ernster Miene.

Wir nutzen den Kegel, um unsere Schätzungen zu kennzeichnen. Eine Zahl nach einem einstündigen Kennenlerngespräch ist eine "grobe Größenordnung", und das sagen wir schriftlich. Eine Zahl nach der Discovery ist eine "Budgetschätzung" mit angegebener Spanne. Eine Zahl nach dem ersten Sprint auf einer gut verstandenen Codebasis ist eine Zusage. Kunden, die wissen, in welchem Stadium sie sich befinden, hören auf, die erste Zahl als Versprechen zu behandeln.

Spike-Stories für die Teile, die du nicht schätzen kannst

Manche Arbeit widersetzt sich der Schätzung, weil niemand im Team sie je gemacht hat. Ein Spike ist eine zeitlich begrenzte Untersuchung, deren Ergebnis eine Antwort ist statt eines Features. "Verbring einen Tag damit herauszufinden, ob die Webhook-Payload des Anbieters die Felder enthält, die wir brauchen, und ob sein Retry-Verhalten dokumentiert ist." Entweder du bekommst die Antwort oder du lernst, dass die Frage schwieriger ist als erwartet, und beides ist nützlich. Der Spike selbst ist leicht zu schätzen, weil er gedeckelt ist.

Spikes funktionieren gut für Drittanbieter-Integrationen, Performance-Fragen ("Hält diese Abfrage bei 10 Millionen Zeilen durch?") und alles in einer Legacy-Codebasis, wo die Antwort auf "Wie funktioniert dieses Modul?" lautet: "Niemand weiß es." Bei Legacy-Modernisierungsprojekten stellen wir manchmal eine Woche Spikes voran, bevor wir überhaupt eine Schätzung abgeben, denn die Alternative wäre, eine Codebasis zu schätzen, die wir nicht gelesen haben.

Schätzungen gegenüber Kunden präsentieren

Die Techniken oben erzeugen Spannen. Kunden wollen Zahlen. Wie du diese Lücke überbrückst, entscheidet, ob die Schätzung der Beziehung hilft oder sie vergiftet.

Präsentiere die Spanne und erkläre, was das Ergebnis an das eine oder andere Ende treiben würde. "Das sind 15 bis 25 Personentage. Das untere Ende setzt voraus, dass eure API-Dokumentation korrekt ist und die Staging-Umgebung ab Tag eins verfügbar ist. Das obere Ende deckt den Fall ab, dass wir die fehlenden Primärschlüssel in der Orders-Tabelle umgehen müssen." Die Spanne liest sich jetzt als konkrete Liste von Risiken statt als Vagheit, und der Kunde kann darauf reagieren. Eine überraschende Zahl von Schätzproblemen löst sich, weil ein Kunde jetzt weiß, dass er seiner IT-Abteilung wegen des Staging-Zugangs hinterherlaufen muss.

Präsentiere keine einzelne Zahl mit stillem Puffer. 10 Tage auf 15 aufzupolstern funktioniert, bis der Kunde es herausfindet, und danach wird jede künftige Schätzung abgezinst. Die Spanne mit Begründungen ist der Puffer, sichtbar gemacht.

Wenn ein Kunde auf einem Festpreis für einen Umfang besteht, der noch nicht klar ist, ist es der falsche Schritt, den Preis zu akzeptieren und zu hoffen. Ändere stattdessen, was fixiert wird. Fixiere den Preis einer Discovery-Phase, deren Ergebnis eine Spezifikation und eine Schätzung mit enger Spanne ist. Dann fixiere den Preis der Umsetzung gegen diese Spezifikation. Wenn ein Kunde selbst eine Discovery-Phase ablehnt und eine feste Zahl für ein Briefing von einem Absatz will, sagt das viel darüber, wie das Projekt laufen wird, und es ist fair, abzulehnen. Über die Abwägungen zwischen Festpreis, Time and Materials und Retainer für EU-Kunden haben wir separat geschrieben.

Vertragsstrukturen, die beide Seiten schützen

Ein Vertrag, der so tut, als wäre die Schätzung sicher, bestraft die Partei, die falsch geraten hat. Ein Vertrag, der Unsicherheit anerkennt, verteilt das Risiko so, dass beide Seiten damit leben können.

Eine kurze Discovery-Phase zum Festpreis (ein bis drei Wochen) liefert die Informationen, die der Cone of Uncertainty vor einer Zusage verlangt. Ihre Ergebnisse sind ein schriftlicher Umfang, ein priorisiertes Backlog, identifizierte Risiken und eine Schätzung mit einer Spanne, die der Kunde auf Wunsch auch zu jedem anderen Anbieter tragen kann. Keine Seite ist gebunden, bevor sie weiß, was sie kauft.

Danach kommen zeitlich gedeckelte Phasen. Statt eines Festpreises für die gesamte Umsetzung wird die Arbeit in Phasen aufgeteilt, jede mit einer Budgetobergrenze. Abgerechnet wird nach Aufwand bis zur Obergrenze. Wird sie erreicht, halten beide Parteien inne und entscheiden, ob sie verlängern, den Umfang kürzen oder ausliefern, was existiert. Das Risiko des Kunden ist pro Phase begrenzt, und der Entwickler trägt nicht die Kosten für unbekannte Unbekannte, die niemand sehen konnte.

Für Kunden, die wegen Beschaffungsregeln oder einer Finanzierungsrunde einen echten Festpreis brauchen, sollte der Preis an einer festen Spezifikation mit explizitem Änderungsprozess hängen. Alles außerhalb der Spezifikation wird separat geschätzt und bepreist. Nur so bleibt ein Festpreis ehrlich.

Wie wir bei Wolf-Tech schätzen

Unser Prozess für ein neues Projekt in der individuellen Softwareentwicklung folgt der Form oben. Nach dem ersten Gespräch geben wir eine grobe Größenordnung ab, als solche gekennzeichnet, meist mit einem Faktor zwei oder drei zwischen den Enden. Will der Kunde weitermachen, führen wir eine Discovery durch. Bei einer bestehenden Codebasis gehört dazu ein Code-Quality-Review, denn der Zustand des Codes ist die größte einzelne Variable in jeder Schätzung. Wir tun nicht so, als könnten wir eine Codebasis schätzen, die wir nicht gelesen haben.

Die Discovery liefert ein Backlog mit Drei-Punkt-Schätzungen, einen Referenzklassenvergleich, wo wir einen haben, und eine Liste offener Fragen, jede mit einem Spike daran. Die Schätzung geht als Spanne mit ausformulierten Risiken an den Kunden. Dann einigen wir uns auf eine Phasenstruktur und legen los.

Wir führen auch die Tabelle. Jede Aufgabe hat eine ursprüngliche Schätzung und einen Ist-Wert, und alle paar Monate schauen wir, wo wir danebenlagen. Kategorien, in denen wir konsequent zu optimistisch sind (undokumentierte APIs, alles rund um E-Mail-Zustellbarkeit), bekommen einen festen Korrekturfaktor. Unglamourös, aber deshalb sind unsere Spannen über die Jahre enger geworden.

Wenn du ein Projekt budgetierst und eine Schätzung willst, die du vertreten kannst, oder die Schätzung eines anderen Anbieters für die vorhandenen Informationen zu selbstsicher wirkt, schreib an hello@wolf-tech.io oder besuche wolf-tech.io. Wir sprechen den Umfang gern durch, bevor sich jemand auf eine Zahl festlegt.