Warum die Aufwandsschätzung für Software nie stimmt, und wie Sie eine bekommen, mit der Sie planen können

Das Gespräch läuft meistens so. Der Geschäftsführer möchte eine Änderung an der Auftragsmaske: ein neues Feld, eine neue Rabattregel, einen kleinen Bericht. Der Entwickler überlegt kurz und sagt: „Etwa zwei Wochen.“ Zwei Monate später ist es immer noch nicht fertig, und der Geschäftsführer fragt sich, ob der Entwickler gelogen hat, faul ist oder seinen Job einfach nicht kann.

Meistens nichts davon. Die Schätzung war für die Arbeit, so wie sie am ersten Tag beschrieben wurde, wahrscheinlich ehrlich. Das Problem: Die Arbeit vom ersten Tag und die Arbeit, die am Ende geliefert wurde, waren nicht dieselbe. Und die zwei Wochen setzten zwei Wochen ungestörte Zeit voraus, die es nie gab.

Dieser Artikel richtet sich an Inhaber, Geschäftsführer und Leiter des operativen Geschäfts, die mit Software planen müssen und immer wieder überrascht werden. Er zeigt, warum Schätzungen danebenliegen, wo die Zeit tatsächlich bleibt und wie Sie eine Aufwandsschätzung bekommen, mit der Sie wirklich planen können.

Schätzungen beginnen breit, und das ist normal

Steve McConnell, Autor des Standardwerks zur Aufwandsschätzung in der Softwareentwicklung, beschreibt den Cone of Uncertainty (Unsicherheitskegel). Ganz am Anfang, wenn eine Aufgabe nur eine Idee ist, kann eine Schätzung um den Faktor vier in beide Richtungen danebenliegen. Aus zwei Wochen können in Wirklichkeit eine halbe Woche werden, oder acht Wochen. Je genauer die Arbeit definiert, entworfen und begonnen wird, desto enger wird die Spanne.

Phase	Realistische Spanne für „zwei Wochen“
Idee, in einem Satz beschrieben	0,5 bis 8 Wochen
Vereinbart, was es können soll	1 bis 4 Wochen
Anforderungen geschrieben und geprüft	1,3 bis 3 Wochen
Entwurf fertig, Arbeit begonnen	1,6 bis 2,5 Wochen

McConnell nennt das den günstigsten Fall. Der Kegel wird nur enger, wenn jemand tatsächlich die Entscheidungen trifft, die die Unsicherheit beseitigen. Die verstreichende Zeit allein ändert daran nichts.

Das ist der erste Grund für die Überraschung: Eine einzelne Zahl, am ersten Tag für eine Anfrage aus einem Satz genannt, ist die unzuverlässigste Schätzung, die es je geben wird. Die meisten „zwei Wochen“ werden genau an diesem Punkt genannt.

Wo die Zeit tatsächlich bleibt

Selbst wenn die Schätzung für das Schreiben des Codes stimmt, ist der Code nur ein Teil der Arbeit. So sieht eine realistische Aufteilung einer „zweiwöchigen“ Änderung in einer gewachsenen Unternehmensanwendung aus:

Arbeit	Meist in der Schätzung enthalten?	Typischer Anteil
Neuen Code schreiben	Ja	40 %
Den bestehenden Code verstehen, den die Änderung berührt	Teilweise	15 %
Tests, und Beheben dessen, was die Tests finden	Oft nicht	15 %
Code-Review und Anpassungen danach	Selten	10 %
Release, Konfiguration, Datenmigration	Selten	10 %
Rückfragen, Klärungen, Warten auf Antworten	Nie	10 %

Die Anteile sind zur Veranschaulichung gedacht, nicht gemessen, aber wer schon einmal Software ausgeliefert hat, erkennt sie wieder. Hat der Entwickler nur die erste Zeile geschätzt, lag die ehrliche Gesamtzahl schon bei vier bis fünf Wochen, bevor irgendetwas schiefging. Bei älteren Systemen wird die zweite Zeile deutlich größer, wie unser Artikel über technische Schulden und langsame Entwicklung zeigt.

Wie aus zwei Wochen zwei Monate werden

Die größte Ursache ist selten die Schätzung selbst. Es ist das, was danach passiert. Ein Beispiel, erfunden, aber typisch:

1. Woche 1Die Arbeit beginnt wie vereinbart
2. Woche 2„Kann es auch Retouren abbilden?“
3. Woche 3Dringender Fehler im Livebetrieb, drei Tage weg
4. Woche 4Ein anderes Projekt hat plötzlich höchste Priorität
5. Woche 6Zurück an der Aufgabe, die Hälfte muss neu erarbeitet werden
6. Woche 7Nach einer Demo ändert sich die Rabattregel
7. Woche 9Endlich geliefert

Niemand hat etwas dramatisch falsch gemacht. Jede einzelne Bitte war vernünftig. Zusammen haben sie aus einer Arbeit von zwei Wochen eine von neun gemacht. Was jede davon wirklich gekostet hat:

Was gewünscht wurde	Wie es klingt	Was es wirklich kostet
„Kann es auch Retouren abbilden?“	Ein Fall mehr	Neue Regeln, neue Tests, oft ein Umbau dessen, was schon gebaut war
Ein dringender Fehler im Livebetrieb	Drei Tage	Drei Tage, plus die Zeit, um wieder in die Arbeit hineinzufinden
„Legen Sie das auf Eis, das andere Projekt ist dringender“	Eine Pause	Später alles neu erarbeiten, und das Risiko, dass sich der Code darunter verändert hat
Eine Änderung nach einer Demo	Eine kleine Korrektur	Einen Teil des Fertigen zurückbauen und neu machen
„Nur eine kurze Frage“, mehrmals am Tag	Nichts	Unterbrochene Konzentration, jedes Mal

Die Wechsel zwischen Aufgaben verdienen eine Zahl. Der Softwareautor Gerald Weinberg hat dafür eine Faustregel aufgestellt: Jedes zusätzliche Projekt, an dem eine Person parallel arbeitet, kostet rund 20 % ihrer Zeit allein durch das Umschalten. Ein Entwickler, der zwischen zwei Projekten aufgeteilt ist, gibt nicht jedem die Hälfte seiner Woche, sondern eher 40 %, und die übrigen 20 % gehen dazwischen verloren.

Warum Druck nicht hilft

Wenn Termine platzen, ist Druck die naheliegende Reaktion: ein fester Termin, ein tägliches Statusmeeting, der Hinweis, dass der Kunde wartet. Meistens macht das die Lage schlimmer.

• Unter Druck werden Schätzungen kürzer, nicht besser. Man nennt die Zahl, die das Meeting beendet, nicht die Zahl, an die man glaubt.
• Tests und Review fallen als Erstes weg. Der Termin wird gehalten, die Fehler kommen eine Woche später, und ihre Behebung kostet mehr als die gesparte Zeit.
• Statusmeetings sind ebenfalls Unterbrechungen. Eine tägliche Abfrage zu einer verspäteten Aufgabe nimmt der Aufgabe Zeit weg.
• Gute Entwickler merken das. Ständiger Termindruck zusätzlich zu ständig wechselnden Prioritäten ist einer der Gründe, warum erfahrene Entwickler kündigen.

Wie Sie eine Schätzung bekommen, mit der Sie planen können

Präzise machen können Sie eine Aufwandsschätzung für Software nicht. Nützlich schon.

1. Fragen Sie nach einer Spanne, nicht nach einer Zahl. „Zwischen zwei und vier Wochen“ enthält mehr Information als „drei Wochen“. Ist die Spanne sehr breit, ist auch das eine nützliche Information: Die Arbeit ist noch nicht verstanden.
2. Fragen Sie, was es länger machen würde. „Was könnte daraus sechs Wochen machen?“ Die Antwort zeigt Ihnen die Risiken, und oft eine Entscheidung, die Sie jetzt treffen können, um eines davon auszuräumen.
3. Teilen Sie die Arbeit auf. Ein großes Paket, als Ganzes geschätzt, ist geraten. Dieselbe Arbeit, aufgeteilt in Stücke von wenigen Tagen, die jeweils einzeln geliefert und gezeigt werden, ist ein Plan. Ein klares Lastenheft für die Software hilft dabei sehr.
4. Lassen Sie die Schätzung alles enthalten. Fragen Sie ausdrücklich: Sind Tests, Review, Release und Datenmigration enthalten? Wenn nicht, rechnen Sie sie dazu.
5. Lassen Sie neu schätzen, wenn sich etwas ändert. Eine neue Anforderung ist eine neue Schätzung, keine Fußnote zur alten.

Was Sie als Geschäftsführer tun können

Der größte Teil der verlorenen Zeit im Beispiel oben lag nicht in der Hand des Entwicklers. Das hier liegt in Ihrer:

• Ein Kanal für neue Anfragen. Ideen, Fehler und Änderungen landen an einer Stelle, nicht direkt beim Entwickler, der gerade am nächsten sitzt.
• Prioritäten, die mindestens zwei Wochen halten. Ändern Sie sie, wenn es sein muss, aber nicht alle paar Tage. Ein Plan, der zwei Wochen hält, ist mehr wert als ein perfekter, der zwei Tage hält.
• Neue Ideen kommen in die nächste Runde. „Kann es auch Retouren abbilden?“ ist eine gute Frage, und die Antwort lautet: ja, im nächsten Arbeitspaket, mit eigener Schätzung.
• Schützen Sie konzentrierte Arbeitszeit. Weniger Meetings, weniger kurze Fragen, und eine Person, die dringende Fehler im Livebetrieb übernimmt, damit nicht alle unterbrochen werden.
• Achten Sie auf den Trend, nicht auf einen einzelnen Ausreißer. Liegt ein Team regelmäßig 50 % darüber, planen Sie mit dem 1,5-Fachen seiner Schätzungen und arbeiten Sie an den Ursachen. Das ist ehrlicher, als so zu tun, als würde es beim nächsten Mal anders.

Geht die Arbeit an einen externen Partner, gilt dieselbe Logik für den Vertrag. Unser Artikel Festpreis oder Aufwand erklärt, warum ein Festpreis diese Unsicherheit nicht beseitigt, sondern sie nur in den Preis verschiebt.

Fragen, die wir oft hören

Warum kann ein Entwickler nicht einfach einen exakten Termin nennen?

Weil am Anfang niemand genau weiß, was die Arbeit umfassen wird, auch nicht die Person, die sie in Auftrag gibt. Details zeigen sich erst während der Arbeit. Ein exakter Termin am Anfang ist ein Versprechen, keine Schätzung, und Versprechen unter Unsicherheit werden gern gebrochen.

Sollten wir auf jede Schätzung einen Puffer aufschlagen?

Ein versteckter Puffer, von dem alle wissen, wird meistens trotzdem aufgebraucht. Besser ist es, nach einer Spanne zu fragen, für wirklich wichtige Dinge mit der oberen Hälfte zu planen und die Gründe für die Spanne sichtbar zu halten.

Unser Team ist immer zu spät. Ist es einfach langsam?

Möglich, aber prüfen Sie zuerst die anderen Ursachen: wie oft sich Prioritäten ändern, an wie vielen Projekten jede Person arbeitet, wie viele Unterbrechungen es gibt und wie alt und verworren der Code ist. Nach unserer Erfahrung erklären diese Punkte den größten Teil der Verzögerung.

Helfen Schätzmethoden wie Story Points?

Sie können einem Team helfen, einheitlich zu schätzen und die eigenen Muster zu erkennen. Sie helfen nicht, wenn sich die Arbeit unter der Schätzung ständig verändert. Bringen Sie zuerst den Arbeitsfluss in Ordnung, dann die Methode.

Wie wir arbeiten

ProCoding ist ein .NET-Studio in Split, Kroatien. Wir entwickeln und betreuen Unternehmensanwendungen, und ein großer Teil davon, das gut zu machen, ist die Planung der Arbeit: kleine Pakete, die sich alle ein bis zwei Wochen zeigen lassen, Schätzungen als Spannen mit benannten Risiken, und Änderungen, die in die nächste Runde gehen, statt die laufende zu stören. In Ihrem eigenen Projekt, mit Ihrem Team oder mit einem .NET-Freelancer in Ihrem Team. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• The Cone of Uncertainty, Steve McConnell, Construx
• The Multi-Tasking Myth, Jeff Atwood, über Gerald Weinbergs Faustregel zum Wechsel zwischen Projekten