In einem Entwicklungsprojekt kürzlich in Aschaffenburg:
Für die Planung der Teamstärke, die zur Entwicklung eines neuen Release bis zu einem mit dem Kunden verbindlich vereinbarten Termin notwendig ist, wird eine Aufwandsschätzung benötigt. Ein Kollege entscheidet sich für eine Expertenschätzung.
Er bricht die vorhandene Feinspezifikation herunter auf viele einzelne Aufgaben und bewertet sie auf Basis seiner umfangreichen Erfahrung mit der Entwicklung dieses Systems. Für die Schätzung benötigt er einen Arbeitstag. Das Ergebnis, das mir zunächst nicht bekannt ist, beträgt 153 Personentage.Ich beginne etwa zeitgleich mit einer indirekten Aufwandsschätzung. Auch meine wichtigste Schätzgrundlage ist die Feinspezifikation. Ich zähle, wie viele Dialogelemente zur Eingabe bzw. nur zur Anzeige, wie viele Attribute in der Datenbank benötigt werden und welche Anzahl an Datenelementen in Berichten ausgegeben werden soll. Aufgrund der Struktur unserer Feinspezifikation kann das Zählen weitgehend von Excel-Formeln übernommen werden. Ich übertrage die Ergebnisse der Zählung in eine Vorlage, wo sie je nach Typ (GUI Ein-/Ausgabe, GUI nur Ausgabe, Datenbank schreibend usw.) gewichtet werden. Das Ergebnis teile ich durch einen Messwert für die Produktivität, den ich nach Fertigstellung des vorhergehenden Release gemessen habe. Mein Ergebnis: 153 Personentage. Der dafür benötigte Aufwand: eine Stunde.
Messen statt schätzen
Im Grunde genommen hat das Abzählen von Datenelementen in einer Spezifikation nichts mehr mit “Schätzen” zu tun. Auch bei der Messung der Produktivität nach Abschluss eines Entwicklungsprozesses handelt es sich um reines Zählen, das zu einem großen Anteil automatisiert werden kann. Dadurch erforderte auch die Messung der Entwicklungsproduktivität in dem oben geschilderten Projekt weniger als eine Stunde menschlicher Arbeitszeit.
Die Genauigkeit der Aufwandsschätzung ist stark von der Qualität der Feinspezifikation abhängig. Eine detaillierte und vom Auftraggeber intensiv geprüfte Feinspezifikation ist jedoch ohnehin notwendig, wenn ein Entwicklungsprozess innerhalb der in einem Werkvertrag verbindlich vereinbarten Rahmenbedingungen planbar und steuerbar sein soll. Mit einer etwas geringeren Genauigkeit ist eine Aufwandschätzung jedoch auch vor der Erstellung einer Spezifikation möglich, beispielsweise auf Basis eines Lastenhefts vor der Angebotsabgabe.
Der Schlüssel sind Methoden zur Messung des funktionalen Umfangs
Indirekte Aufwandsschätzungen basieren im ersten Schritt auf einer Bestimmung der “Größe” der zu entwickelnden Anforderungen. Anschließend wird dieser Wert mit einem Erfahrungswert in Beziehung gesetzt, welche “Größe” durch das Team mit einem bestimmten Aufwand entwickelt werden kann. Nach diesem Prinzip funktioniert die Story-Point-Methode, die besonders in der agilen Softwareentwicklung eingesetzt wird. Genauer sind Methoden zur Messung des funktionalen Umfangs. Der Klassiker ist die Function-Point-Analyse. Auch die COSMIC-Methode ist weit verbreitet. PASS setzt die Data-Interaction-Point-Methode ein, die völlig frei von manuellen Bewertungen ist und daher leicht automatisiert werden kann. Mehr über diese Methoden, Beispiele zur Anwendung und Vergleiche sind in den beiden empfohlenen Büchern zu finden:
- “Aufwandsschätzungen in der agilen Softwareentwicklung” (zum Shop)
- “Produktivitätssteigerung in der Softwareentwicklung, Band 1: Produktivitäts- und Leistungsmessung – Messbarkeit und Messmethoden” (zum Shop)
Welche Methoden setzen Sie zur Aufwandsschätzung ein und welche Erfahrungen haben Sie damit gemacht?
Bildquelle: Shutterstock
