Gib mir eine Zahl – Schätzungen entlang des Entwicklungsprozesses

Inhaltsverzeichnis

Wer in der Softwareindustrie arbeitet, hat auf die eine oder andere Weise schon Aufwandsschätzungen erlebt oder vielmals sogar erlitten. Entweder auf Managementseite mit Fragen wie "Warum dauert so etwas Einfaches so lange?" Oder: "Wie soll der Umsatz solche Kosten decken?". Oder auf Expertenseite, wo Warnungen über Risiken einfach nicht gehört werden. Diesen Widerspruch wird auch dieser Artikel nicht auflösen. Allerdings gibt er Hinweise, wie Verantwortliche auf beiden Seiten mit ihm besser umgehen können. Schätzmethoden sind Techniken für das Schätzen, nicht für das Messen, und sie sind per se ungenau. Wenn den Verantwortlichen bewusst ist, was diese Ungenauigkeit bedeutet und wie mit ihr umzugehen ist, ist bereits viel gewonnen.

In der Regel ist es keine Option, gar keine Schätzung abzugeben. Planungen sind durchzuführen, Budgets einzuhalten. Diese Dinge müssen Kosten- und Aufwandsschätzungen zur Basis haben. Wie sonst sollen die richtigen Leute in der richtigen Anzahl in ein Projekt kommen? Schätzungen, die alle Möglichkeiten abdecken und alle Risiken umfassen, sind in der Regel viel zu hoch. Kein Wunder, dass das Management im Unternehmen sie zu Recht ablehnt. Was ist somit zu tun?

Die Autorin möchte Schätzverfahren vorstellen, die sich aus ihrer Erfahrung in den jeweiligen Phasen der Softwareentwicklung bewährt haben. Als Beispiel dient ein Softwareprojekt mittlerer bis hoher Komplexität. Die Schätzverfahren lassen sich abhängig vom jeweiligen Projektfortschritt anwenden.

Initialzündung

Erste Ideen entstehen ganz unterschiedlich. Oft tragen Unternehmen sie lange mit sich herum, ehe sie in den Fokus des Managements geraten. Idealerweise werden alle Ideen hinsichtlich ihres Umsatzpotenzials, ihrer strategischen Bedeutung für das Unternehmen und auch hinsichtlich ihrer Kosten bewertet.

Ziel des Artikels ist es nicht, über die Produkt- oder Ideenbewertung zu schreiben – das ist ein Thema für einen weiteren Artikel. Allerdings möchte die Autorin zeigen, wie sich der Aufwand der Softwareentwicklung (und damit der wesentliche Kostenanteil) abschätzen lässt.

Erste Ideen werden nicht umfangreich entwickelt oder gar dokumentiert. Meist existiert ein einseitiges Dokument, das die Vorteile des Projekts für das Unternehmen darlegt und unter Umständen die Konsequenzen bei Nichtdurchführung auflistet. Beides ist den Gesamtprojektkosten gegenüber zu stellen, um die Machbarkeit der Idee bewerten zu können. Die weitere Arbeit an einer solchen Idee kostet ebenfalls Geld, und dies muss sich lohnen, über Umsatz oder auch Einsparungen zum Beispiel von Rechnerkapazitäten.

Aufwandsschätzungen im klassischen Sinne sind zu einem solchen frühen Zeitpunkt nicht möglich. Daher versucht man, die einzelnen Ideen in Größenordnungen wie "XS", "S", "M", "L", "XL" einzusortieren. Die Größenordnungen folgen den Komplexitäten der Projekte oder Ideen. Augenscheinlich schätzt man hier in T-Shirt-Größen.

Da sich die Beteiligten meistens schwertun, absolute Größen zu schätzen, empfiehlt es sich, wie folgt vorzugehen: Die Ideen sind auf Karten gedruckt oder geschrieben und liegen als Stapel auf dem Tisch. Jemand zieht die erste Karte vom Stapel und legt sie unter "M" ab. Die nächste Karte wird gezogen, und die "Mitspieler" diskutieren, ob sie größer, gleich oder kleiner als die gelegte Karte ist.

Die Karte wird dann entsprechend einsortiert. Auf diese Art geht es immer weiter – eine gezogene Karte wird mit schon gelegten Karten verglichen und einsortiert. Kommt eine Karte, die größer als "XL" ist, muss der ganze Stapel nach unten rutschen; die erste Karte wird also zu "S". Sind alle Karten ausgelegt, zieht man ein bereits durchgeführtes Projekt heran, dessen Aufwand bekannt ist und das alle Beteiligten in der Schätzrunde inhaltlich kennen. Es wird als Eichmaß ebenfalls einsortiert. Nach Möglichkeit sollte das Eichmaß nicht zu klein oder zu groß sein, das heißt weder "XS" oder "XL". Alternativ hilft ein zweites durchgeführtes Projekt. Die Eichmaßprojekte sind als Gesamtprojekte, also mit Entwicklung, Qualitätssicherung und Überführung in die Produktion zu verstehen.

Nun kann man im Verhältnis die Projekte beziffern. Da auch für T-Shirt-Größen gilt, je größer, desto ungenauer, setzt man für sie ebenfalls die für agile Projekte vereinfachte Fibonacci-Reihe an: 1, 2, 3, 5, 8.

Das Eichmaß-Projekt ist zum Beispiel ein S-Projekt und produziert den Aufwand von sieben Sprints eines Teams mit fünf Mitgliedern. Das heißt, dass ein XL-Projekt einen Aufwand von 8/2*7 Sprints, also circa 19 Sprints verursachen würde.

In der Regel reicht das Einsortieren in Größenordnungen, um vom Management einen Daumen hoch oder runter zu bekommen. Aufwendigere Risikoabschätzungen oder gar detaillierte Projektpläne sind zu diesem Zeitpunkt weder machbar noch sinnvoll.