Wie genau kann eine Softwareschätzung sein? Der Schätzkorridor

01

Eine einzelne Zahl verspricht mehr, als sie halten kann

Zu Beginn eines Vorhabens ist nicht die Rechnung unsicher, sondern das Vorhaben selbst: Umfang, Sonderfälle, Fremdsysteme und Abnahme sind beschrieben, aber noch nicht geprüft. Eine einzelne Zahl verschweigt das. Eine Spanne mit unterer und oberer Grenze zeigt es stattdessen, und sie zeigt zugleich, was noch geklärt werden muss, bevor aus der Beschreibung ein geprüfter Umfang wird.

Nehmen wir ein ausgedachtes Beispiel. Ein Zulieferer hat sich für die eigene Qualitätssicherung ein Werkzeug für Reklamationen gebaut, mit einer Oberfläche, die überzeugt, und Testdaten, die gut aussehen. In der Vorführung nicken alle. Jetzt soll das Werkzeug im Alltag laufen, mit echten Fällen und angebunden an die Warenwirtschaft, und die Geschäftsführung fragt, wie viel Aufwand bis dahin noch bleibt.

Welche Fragen eine Anwendung im Betrieb beantworten muss, die im Prototyp niemand stellen musste, ordnet die Reihe Vom Prototyp zur produktionsreifen Anwendung. Jede offene Frage darin ist eine Quelle von Unsicherheit in der Schätzung. Die interessante Frage bleibt, wie sich diese Unsicherheit verkleinern lässt.

Eine einzelne Zahl versteckt diese Spanne. Ein Korridor zeigt sie.

02

Was beschreibt der Kegel der Unsicherheit?

Der Kegel der Unsicherheit beschreibt, wie weit Schätzungen erfahrener Schätzender zu verschiedenen Zeitpunkten eines Softwarevorhabens danebenliegen können. Am Anfang ist die Spanne am größten, und mit jedem Meilenstein wird sie schmaler, an dem Anforderungen, Oberfläche und Entwurf feststehen. Der Kegel zeigt den günstigsten Fall. Schlechter geht immer.

Steve McConnell beschreibt das Modell 2010 in einem Papier von Construx. Auf der waagerechten Achse stehen typische Meilensteine: erste Idee, abgestimmte Produktdefinition, abgeschlossene Anforderungen, fertiger Oberflächenentwurf, fertige Software, und auf der senkrechten Achse steht, um welchen Faktor eine Schätzung zu diesem Zeitpunkt danebenliegen kann. Vor allem in den ersten 20 bis 30 Prozent der Laufzeit eines Vorhabens verengt sich der Kegel, McConnell zufolge (Construx, 2010).

Zwei Einschränkungen gehören dazu. Der Kegel zeigt die bestmögliche Genauigkeit, schlechter schätzen geht immer, genauer nur mit Glück, und er verengt sich nicht von selbst. Wird ein Vorhaben so geführt, dass offene Punkte offen bleiben, bleibt auch die Unsicherheit bis zum Ende bestehen, und McConnell spricht dann von einer Wolke statt einem Kegel (Construx, 2010).

03

Zwischenstände verengen den Korridor, gutes Zureden nicht

Enger wird der Korridor an Zwischenständen. Jeder davon beantwortet eine offene Frage mit einem prüfbaren Ergebnis, etwa geschriebenen Anforderungen, einem getesteten Klickprototyp, dokumentierten Schnittstellen oder einem gebauten Kernablauf, und jeder Schritt endet mit etwas Vorzeigbarem statt mit einer Einschätzung.

In unseren Projekten sehen wir immer wieder dasselbe Muster: Die Demo überzeugt, die Fremdsystem-Anbindung bleibt am längsten offen, und genau sie bestimmt am Ende die obere Grenze. Für das Reklamationswerkzeug hieße das: Die Vorführung belegt, dass die Oberfläche verstanden wird. Sie belegt nicht, welche Auftragsdaten die Warenwirtschaft liefert, welche Sonderfälle bei Teillieferungen auftreten oder wann eine Reklamation als erledigt gilt.

04

Was passiert im Rechner, wenn Sie einen Beleg abhaken?

Jeder Beleg verschiebt beide Grenzen näher an den Basisaufwand, und jeder weitere Zwischenstand verschiebt sie noch einmal. Welcher fehlende Beleg die Spanne am stärksten verkleinern würde, ist die nützlichste Auskunft einer Schätzung, denn sie benennt den nächsten Arbeitsschritt und nicht bloß eine Zahl. Der Rechner unten zeigt das an Beispielwerten.

Wählen Sie zuerst die Phase, in der sich Ihr Vorhaben befindet, und haken Sie ab, was schon belegt ist. Setzen Sie einen Basisaufwand. Beobachten Sie dann, welche Häkchen den Balken kürzer machen und welche Lücke als größte offene Lücke gemeldet wird, denn genau die zeigt Ihnen, wo als Nächstes anzusetzen ist. Voreingestellt ist das Reklamationswerkzeug: Klickprototyp getestet, Nutzer haben ihn bedient, Basisaufwand 80 Personentage.

Mit diesen Werten reicht der Korridor von 61 bis 118 Personentagen. Die obere Grenze liegt damit fast doppelt so hoch wie die untere, und die größte offene Lücke sind die nicht dokumentierten Schnittstellen. Stellen Sie die Phase auf Idee und entfernen Sie alle Häkchen: Die Spanne wächst auf 32 bis 240 Personentage. Ist dagegen der Kernablauf gebaut und stehen alle vier Belege, bleiben nur noch 76 bis 85.

05

Der erwartete Wert liegt nicht in der Mitte

Die untere Grenze beschreibt den Aufwand, wenn offene Punkte einfach ausfallen. Die obere beschreibt ihn, wenn sie schwierig werden. Der erwartete Wert liegt meist näher an der unteren Grenze als an der oberen, weil er den wahrscheinlichsten Fall stärker gewichtet als die beiden Ränder. Wer nur ihn weitergibt, verschweigt, wie weit die obere Grenze entfernt liegt.

Der Rechner ermittelt den erwarteten Wert als Drei-Punkt-Schätzung: niedrig plus viermal wahrscheinlich plus hoch, geteilt durch sechs. Als wahrscheinlicher Wert dient dabei stets der Basisaufwand. Verbreitet ist diese Formel, weil sie den wahrscheinlichsten Fall stärker zählt, ohne die beiden Grenzen zu unterschlagen.

Auffällig ist die Schräglage. Die obere Grenze liegt weiter vom Basisaufwand entfernt als die untere, weil deutlich mehr Dinge Arbeit hinzufügen können als Arbeit wegnehmen: ein vergessener Sonderfall, eine Schnittstelle mit anderen Daten als gedacht, eine zusätzliche Abstimmungsrunde. Dass eine geplante Aufgabe überflüssig wird, kommt zwar auch vor, aber seltener, und selten in derselben Größenordnung.

06

So bauen Sie sich Ihre eigene Spanne

Der Mechanismus lässt sich auf jedes eigene Vorhaben übertragen, unabhängig davon, wer am Ende baut. Fünf Schritte reichen.

1. Stand benennen

   Legen Sie fest, wo das Vorhaben gerade steht: Idee, geschriebene Anforderungen, getesteter Klickprototyp oder gebauter Kernablauf. Der Stand bestimmt die Ausgangsbreite der Spanne.

2. Basisaufwand als Platzhalter setzen

   Ein grober Wert reicht. Er lässt den Mechanismus laufen und dient als Rechengröße für Ihre eigene Planung, keine Zusage an irgendjemanden.

3. Belege durchgehen

   Prüfen Sie anhand der Liste weiter unten, was an Ihrem Vorhaben schon belegt ist und was noch fehlt. Jeder fehlende Haken ist ein Grund für die obere Grenze.

4. Drei-Punkt-Wert rechnen

   Niedrig, wahrscheinlich, hoch. Diese drei Werte ergeben nach der Formel von oben den erwarteten Wert, der die einzelne Zahl ersetzt, ohne die Ränder zu verschweigen.

5. Größte Lücke benennen

   Welcher fehlende Beleg die Spanne am stärksten verkleinern würde, ist der eigentliche nächste Arbeitsschritt. Nicht die Zahl selbst.

Unsere Erfahrung: Teams, die den Basisaufwand zu genau nehmen, verwechseln ihn mit einer Zusage, obwohl er nur ein Ausgangspunkt für die Rechnung ist. Er darf grob sein. Die Belege dahinter entscheiden über das Ergebnis, nicht die erste Zahl.

07

Welche Belege verkleinern die Spanne am stärksten?

Am stärksten wirken Belege, die eine Frage außerhalb des eigenen Teams klären: getestete Anbindungen an Fremdsysteme, Nutzer, die den Ablauf wirklich bedient haben. Danach folgen ein stabiles Datenmodell und schriftliche Abnahmekriterien. Die Liste unten zeigt, was für Ihr Vorhaben schon steht.

Welcher Beleg am meisten bewirkt, hängt vom Vorhaben ab. Eine Anwendung ohne Fremdsysteme gewinnt mehr durch Nutzertests, eine Anwendung mit fünf Anbindungen mehr durch getestete Schnittstellen. Deshalb nennt der Rechner die größte offene Lücke, statt eine feste Reihenfolge vorzugeben.

08

Wann lässt sich eine feste Zusage verantworten?

Eine feste Zusage lässt sich verantworten, wenn die Spanne klein genug ist, dass ihre obere Grenze für alle Beteiligten tragbar bleibt. McConnell rät, Zusagen erst zu machen, wenn sich der Kegel verengt hat. Praktisch heißt das: Kernablauf bedient, Schnittstellen getestet, Abnahmekriterien schriftlich, verbleibende Annahmen benannt.

Eine frühe Zusage ist verlockend, weil sie Planungssicherheit verspricht. Sie verschiebt die Unsicherheit nur nach hinten: Liegt der tatsächliche Aufwand nahe der oberen Grenze, wird im Vorhaben gekürzt, nachverhandelt, oder die Qualität leidet. McConnell hält fest, dass Organisationen Zusagen vermeiden sollten, bis sich der Kegel verkleinert hat, weil sie vorher nicht haltbar sind (Construx, 2010).

09

Vier Annahmen, die den Praxistest nicht bestehen

10

Wie vergleichen Sie Schätzungen verschiedener Stellen?

Vergleichen Sie zuerst die Grundlagen, erst danach die Zahlen. Auf welchem Stand wurde geschätzt, welche Annahmen sind genannt, was gehört zum Umfang, und welche Lücke soll als Nächstes geklärt werden? Zwei Zahlen auf unterschiedlichem Stand oder mit unterschiedlichem Umfang lassen sich nicht sinnvoll gegeneinanderstellen.

In unseren Projekten hat sich gezeigt: Zwei Zahlen auf unterschiedlichem Stand sind praktisch nicht gegeneinander abzuwägen, so sehr die Beteiligten es sich wünschen. Soll ein bestehender Prototyp weiterentwickelt werden, gehört sein Zustand unbedingt in die Grundlage jeder Schätzung. Woran sich Abkürzungen im Code zeigen, die jede Änderung verteuern, beschreibt Technische Schulden in KI-generiertem Code erkennen, und welche Unterlagen die Übergabe in den Betrieb braucht, steht in Vom Proof of Concept in den Regelbetrieb.

iiterate Technologies GmbH aus Adenau entwickelt Individualsoftware und KI-Anwendungen von der Architektur über die Umsetzung bis zum Betrieb und übergibt mit Quellcode und Dokumentation. Wenn Sie über den Stand Ihres Vorhabens sprechen möchten: Kontakt.