Aufwandsschätzung in Softwareprojekten auf Basis der Dokumentation

Eine Aufgabe des Projektmanagements, die sicher jeden schon einmal zur Verzweiflung gebracht haben wird, ist eine möglichst passgenaue Aufwandsschätzung für Software abzugeben.

Ich möchte hier einen neuen Ansatz vorstellen. Er ist nicht nur wesentlich einfacher und kommt schneller zum Ziel, sondern – und das ich für mich wichtiger – er liefert mir recht brauchbare Zahlen.

Klassische Verfahren

Ist eine Aufwandsschätzung zu optimistisch angesetzt, wird der zugesagte Termin nicht eingehalten werden können. Ist sie jedoch zu pessimistisch angesetzt, droht das Projekt noch vor dem Start aufgrund des Budgets abgesetzt zu werden. Eine möglichst realistische Schätzung zu finden ist daher wichtig.

Dieses Problem ist nicht neu. Dennoch ist es schwer gute Schätzungen zu bekommen. Dies ist nicht verwunderlich, da die Entwicklung von Software ein Lernprozess ist. (Siehe dazu meinen anderen Artikel.) Dennoch ist es unabdingbar eine „Hausnummer“ nennen zu können. Das scheinbar unlösbare Problem muss irgendwie gelöst werden – zur Not wird geraten.

Es gibt zahlreiche Methoden, von denen in der Praxis lediglich das „Function-Point-Verfahren“ und „COCOMO“ häufiger angewendet werden. Meist jedoch versucht jedes Team selbst irgendwie einfach eine Stundenzahl zu „raten“ und unterschätzt damit den Umfang bei weitem. Dies kompensieren erfahrene Manager (je nach Team) mit einem Faktor zwischen 2 und 3.

Aufwandsschätzungen sind aufwendig

Das Problem mit fast allen Schätzverfahren ist, dass alle Funktionen und Features einzeln geschätzt werden müssen oder in Punkte umgerechnet werden müssen. Dies braucht Anfangs oft länger als einen Tag und ist eine unliebsame Aufgabe, da die Ergebnisse meist schon nach 2 Wochen wieder veraltet sind. Die anfänglich grobe Dokumentation weicht zwischenzeitlich einer wesentlich detailierten Version (vielleicht gar einem Pflichtenheft), welche viele Aspekte enthält, die alle in der Schätzung nicht berücksichtigt wurden. Dies erfordert ein erneutes Schätzen.

Ein mühsames Unterfangen.

Schätzung basierend auf einem Pflichtenheft

Vor ungefähr zehn Jahren habe ich versucht eine Metrik zu finden, anhand derer ich gute Aufwandsschätzungen erstellen könnte. Ich habe vieles ausprobiert. Inspiriert vom Function-Point-Verfahren, dass ich damals bereits für recht willkürlich und subjektiv hielt, probierte ich diverse andere Rechnungen. (Diese waren oft nicht minder willkürlich und subjektiv.)

Als Grundlage nahm ich alles Mögliche, was sich zählen ließ. Features, Objekte, Screens und andere zählbare Werte. Ich versuchte damals auch die Seitenzahlen der Pflichtenhefte heranzuziehen. Ein Wert, der mir damals noch nicht als geeignet erschien.

„Zu viel, dass kann nicht sein!“

Nach anfänglichen Auswertungen vergangener Projekte stellte sich der Zusammenhang zwischen Pflichtenheft-Seiten (A4 Format) und dem Aufwand nahezu linear dar. Doch schon beim nächsten Projekt schien dies nicht aufzugehen. Der geschätzte Aufwand war viel zu hoch bemessen. Meine Schätzung der Einzelpositionen fiel um den Faktor 3 kleiner aus. Die bloße Seitenanzahl erschien mir dann doch zu grob und willkürlich und dem Kunden nicht zumutbar. Ich verwarf die Rechnung und tat das Verfahren zunächst als ungeeignet ab.

„Vielleicht geht es ja doch?“

Zwei oder drei Jahre später stand ich wieder vor einem größeren Projekt, das Monate verschlingen sollte. Ich schaute zurück auf meine vergangenen Projekte und war unzufrieden, da mehrere deutlich aufwendiger ausgefallen waren, als ich geschätzt hatte. (Ein Symptom, dass überall in der IT vorherrschte.) Ich hatte zu dem Zeitpunkt oft nicht alles bis ins Detail ausgearbeitet, so dass die Aufgaben stets zu sehr vereinfacht geschätzt wurden und dann doch umfangreicher ausfielen.

Ich bekam aber ein immer besseres Gespür für „versteckten Aufwand“. Zu vage Stellen versuchte ich immer etwas höher im Aufwand anzusetzen. Aber so richtig gut waren die Schätzungen trotzdem nicht.

Im Nachhinein betrachtet, war mein als „zu hoch“ geschätzter Aufwand des alten Projektes doch wesentlich näher an der Realität, als der damals anhand von Einzelpositionen geschätzte Aufwand. Ich schöpfte ich wieder Vertrauen in diese grobe Approximation und vereinbarte im anstehenden Projekt einen Festpreis.

Das Projekt brauchte mehr als doppelt so lange. Ich war enttäuscht. Eine realistische Schätzung schien einfach unmöglich.

„Endkunden sind anders!“

Wieder ein paar Jahre später hatte ich rückblickend verstanden, wieso dieses eine Projekt so viel länger brauchte. Im Gegensatz zu den meist eher einfachen Webanwendungen oder Businessanwendungen waren die Projekte für Endkunden immer aufwendiger ausgefallen. Die Ansprüche an die Bedienung und die Behandlung von Fehlverhalten waren im Endkundenbereich wesentlich höher angesiedelt.

Im Gegensatz dazu sind die Admin-Tools meist viel schneller fertig geworden. Dort war es nicht so wichtig diverse Situationen zu behandeln. Es gab meist nur einen richtigen Weg die Anwendung zu benutzen und ansonsten musste man mit Fehlermeldungen leben. (Verschiedene Lösungswege, Bequemlichkeit oder ansprechende Aufbereitung waren selten ein Thema und blieben aus.)

Die Formel

Nach langem hin und her und diversen Erfahrungen komme ich zur Erkenntnis, dass die doch recht einfache Annäherungsformel im Vergleich zu anderen Methoden durchweg passable Ergebnisse liefert.

Drei Faktoren spielen dabei eine Rolle:

• die Reife des Dokumentes
• die Anzahl der A4-Seiten
• die Zielgruppe der Anwendung

Die Kurzfassung: Aufwand in Stunden = Anzahl der Seiten x 10

Zu beachten sind natürlich noch der Reifegrad des Dokumentes und die Zielgruppe.

Reifegrad des Dokumentes

Ist das Dokument recht grob, so dass nur die Erfinder/Ideengeber und involvierte es verstehen, dann muss die Seitenanzahl mit „5“ multipliziert werden, um ein detailiertes Dokument zu werden.

Ein detailiertes Dokument ist zwar schon ganz gut und sogar für nicht involvierte (außenstehende) Entwickler verständlich und umsetzbar, aber es ist noch kein richtiges wasserfestes Pflichtenheft. Meist kommen Konzepte nicht über dieses Stadium hinweg. Denn die nächste Stufe ist nur nötig, wenn Aufträge nach außen gegeben werden und sich alle beteiligten Schützen wollen. Dies ist z.B. innerhalb von Unternehmen selten der Fall. Um zu einem richtigen Pflichtenheft zu gelagen, wird die Seitenanzahl abermals um den Faktor „5“ anwachsen.

Ein Pflichtenheft, das alle Ansichten definiert, alle Features spezifiziert, alle Daten identifiziert, jeden Knopf (bzw. die Funktion dahinter) beschreibt und genau abgrenzt, was gemacht werden soll und was nicht. Die Anzahl dieser Seiten ist für die o.g. Formel relevant.

Daraus ergeben sich die Multiplikatoren

• x1 für klar abgegrenzte und durch-spezifizierte Pflichtenhefte
• x5 für detaillierte Dokumente, die außenstehende Entwickler umsetzen könnten
• x25 für Dokumente, welche die Idee erklären, jedoch so noch nicht 1:1 umsetzbar wären

Die Zielgruppe

Sind Administratoren oder Entwickler die Zielgruppe, so kann man den Aufwand ohne weiteres halbieren. Die Zielgruppe muss nicht unbedingt so versiert sein. Jedoch wäre die Bequemlichkeit der Anwendung eben so holprig. Dies ist der minimale Aufwand um alle Funktionen korrekt umzusetzen.

Sind hingegen Endkunden die Zielgruppe, so muss mindestens mit dem Faktor „2“ multipliziert werden. Je höher die Anzahl der Kunden ist, umso größer wird dieser Faktor ausfallen. Grob geschätzt würde ich sagen, dass der Faktor 2 bis zu 500 Benutzer gut trifft. Bei mehr als 2000 Benutzern wäre es ratsamer den Faktor „3“ zu nehmen. Größere Projekte bedürfen jedoch ohnehin eines Wartungskonzeptes. Die Benutzer formen heutzutage eine Anwendung und verändern ihre Bedürfnisse im Laufe der Zeit. (Heutzutage ändern sich die Bedürfnisse der Anwender innerhalb von 2 Jahren deutlich.) Für Projekte dieser Größenordnung habe ich noch nicht genügend Erfahrungswerte um eine Aussage machen zu können.

Voodoo?

Ich muss zugeben, dass klingt alles auf den ersten Blick ziemlich willkürlich. Und es hat auch 10 Jahre gedauert, bis ich mich selbst überzeugt habe. Im Grunde basiert das ganze Verfahren auf der Annahme: je mehr ich erklären muss, umso komplexer oder umfangreicher ist die zu stemmende Aufgabe. Dies ist bereits im Function-Point-Verfahren ebenso manifestiert. Dort wird der Umfang mit der Komplexität multipliziert. D.h. der Aufwand steigt entweder durch die Masse an Funktionen/Features oder durch ihre Komplexität.

Ein Pflichtenheft (das Vertragssicher sein soll) muss ziemlich viel abgrenzen und klarstellen. Dies braucht Papier – viel Papier. Vieles ist so explizit festgehalten, dass die Aufgaben recht klar sind. Was auf einer Seite beschrieben ist, lässt sich dann gut an 1-2 Tagen umsetzen.

Das Problem der Praxis ist, dass je nach Umfang des Projektes eine frühe Schätzung niemals ein vollständiges Pflichtenheft haben wird. Es liegen immer nur frühe Konzepte vor, die mehr oder weniger detailliert ausgearbeitet sind. Daher ist es wichtig, diesen Reifegrad in die Berechnung einfließen zu lassen.

Lange Vorlaufphasen

Trotzdem all der Papier-Orientierung bleibt zu sagen: Egal wie viel Papier bisher erzeugt wurde. Es zähl das Dokument, welches einem ganzheitlichen Pflichtenheft am nahesten kommt. (Gerade in größeren Unternehmen wird gerne mal ein Jahr besprochen und protokolliert. Das meiste davon taugt nicht als Pflichtenheft.)

Falls vor einer Aufwandschätzung bereits über drei Monate Verhandelt und Dokumentiert wurde, sollte man sich folgende Untergrenze setzen: pro Besprechungs-Monat (also pro 2 langen Meetings) werden ca. 2-3 Seiten einer detailierten Dokumentation entstehen. Das bedeutet also grob 100 bis 150 Stunden Aufwand.

Fazit

Wieso soll man sich mit dem Function-Point-Verfahren abplagen, wenn die Ergebnisse nicht wirklich besser ausfallen? Im Gegenteil – beim Function-Point-Verfahren ist man gerade in frühen Planungsphasen verleitet das Problem zu simplifizieren und unterschätzt den Aufwand systematisch. Dem wird nicht ausreichend entgegengewirkt.

Die Schätzung anhand des Pflichtenheftes hingegen orientiert sich sowohl an der Reife der Planung, als auch am Umfang und der Komplexität. Je detailierter die Planung ist, umso genauer ist die Aussage. Dabei müssen nicht einmal zusätzliche Dokumente oder Tabellen erstellt werden. Denn alles was man heranzieht ist ohnehin bereits vorhanden – oder auch eben nicht.

Stellen sie das Verfahren einfach mal auf die Probe: nehmen Sie ihr letztes abgeschlossenes Projekt, die Dokumentation und den Aufwand und rechnen Sie nach. Kommt es in etwa hin? Lassen Sie es mich wissen. Falls nicht, dann möchte ich erst recht gerne mehr erfahren!