„Wie lange bist du noch unterwegs?“ – „Kann ich nicht genau sagen, bin gerade auf der A6, Höhe Mannheim. Ich schätze aber, dass ich in einer Stunde, gegebenenfalls auch 45 Minuten, da bin.“ Eine eigentlich triviale Frage, mit einer meist schwierigen Antwort: Die für eine Strecke benötigte Zeit ist nicht einfach mit Multiplikation von Entfernung und Geschwindigkeit zu ermitteln. Während wir antworten, gehen wir in Gedanken die geplante Route durch, ermitteln aus unserer Erfahrung Stauschwerpunkte und bekannte Baustellen, die von Wochentag und Uhrzeit abhängige Verkehrslage, und geben anschließend eine möglichst zuverlässige Schätzung ab. Um unsere Unsicherheit zum Ausdruck zu bringen, beschränken wir uns häufig nicht auf eine Zahl, sondern geben ein Intervall an, von dem wir annehmen, dass es unsere Ankunftszeit mit hoher Wahrscheinlichkeit beinhaltet. Niemand würde von uns eine Aussage wie „1 Stunde und 17 Minuten“ erwarten oder überrascht sein, wenn sich nach einem Unfall auf unserer Strecke die Ankunft dann noch stärker als erwartet verzögert. Wie sieht das aber bei der Schätzung im Rahmen eines Softwareprojekts aus? Wie präzise können unsere Vorhersagen sein und wie kommen wir zu verlässlichen Einschätzungen?
Schätzmethoden im Überblick
In der Fachliteratur findet sich eine ganze Reihe von Methoden zur Aufwandschätzungen in Softwareprojekten. Grob lassen sich diese in expertenbasierte und datengetriebene Verfahren einteilen. Bei expertenbasierten Verfahren stehen die Fachexperten, meist Entwickler oder Projektmanager, und die effektive Erschließung ihres Erfahrungsschatzes im Zentrum der Methode. Datengetriebe Methoden hingegen nutzen durch Beobachtung und Messung gesammelte Daten aus vergangen Projekten um Rückschlüsse auf den Aufwand des aktuell geplanten Projekts zu ziehen. Beides bringt ganz eigene Probleme mit sich…
Expertenbasierte Schätzverfahren
Sie sind in der Praxis sehr beliebt und daher stark verbreitet. Dies begründet sich vor allem in der niedrigen Hürde für ihre Anwendung. Meist sind sie einfach verständlich, benötigen keine speziellen Vorbereitungen oder Werkzeuge, und vor allem keine vorgehaltene Datenbasis.
Bekannte Ansätze zur Unterstützung der expertenbasierten Aufwandsschätzung sind unter anderem die Delphi-Methode, die aus dem PERT Verfahren bekannte Drei-Punkt-Schätzung, aber auch der in der agilen Entwicklung verbreitete Planungspoker [1].
Wo liegen die Schwächen expertenbasierter Schätzungen? Häufig sind Projekte zum Zeitpunkt der Schätzung noch nicht ausreichend detailliert und durchdrungen, um als Schätzender eine valide Schätzung abgeben zu können. Zudem hat nicht jeder Entwickler oder Projektmanager die notwendige Erfahrung und Expertise, um eine zuverlässige Schätzung abgeben zu können (und der Fachexperte, der es könnte, ist gerade mal wieder völlig Land unter und daher nicht verfügbar). Darüber hinaus sind insbesondere interaktive expertenbasierte Schätzungen in ihrer Durchführung und Koordination verhältnismäßig aufwändig. Der größte Nachteil ist jedoch, dass Menschen zu systematischen Schätzfehlern neigen, die sich selbst, wenn man sich dieser bewusst ist, nicht vollständig ausschalten lassen [2]. Das ist beispielsweise auch ein Grund warum der Aufwand für Softwareprojekt häufiger unter- als überschätzt wird [3].
Datengetrieben Schätzverfahren
Datengeriebene Schätzverfahren basieren auf der systematischen Erhebung und Auswertung von bereits kalkulierten und abgewickelten Projekten. Die Schätzung beruht dabei häufig auf mathematischen Modellen, die mittels statistischer oder maschineller Lernverfahren aus den Daten abgeleitet werden. Im Vergleich zu ihrer Vorherrschaft in der Fachliteratur und Forschung, genießen sie in der Praxis wenig Beachtung und eine verhältnismäßig geringe Verbreitung.
Der Vorteil datengetriebener Verfahren ist, dass sie meist unabhängig von der Verfügbarkeit eines geeigneten Fachexperten eingesetzt werden können und im Unterschied zu menschlichen Schätzern objektive und wiederholbare Schätzergebnisse liefern.
Die wohl bekannten Verfahren sind COCOMO bzw. COCOMO II [4]. Daneben existieren aber zumindest in der Forschung unzählige weitere Verfahren. Auch Anbieter kommerzieller Kostenschätzwerkzeuge setzten normalerweise auf datengetriebene Modelle, die auf einer proprietären Schätzdatenbanken mit abgeschossenen Projekten unterschiedlicher Unternehmen basieren. Eine öffentliche aber im Allgemeinen kostenpflichtige Datenbank mit solchen Projektdaten stellt die ISBSG bereit.
Die Grenzen datengetriebener Schätzungen
Ein Grund für die geringe Verbreitung datengetriebener Schätzverfahren in der Praxis ist die für eine valide Schätzung notwendige historische Datenbasis. Insbesondere komplexere Verfahren sind auf eine große Menge qualitativ hochwertig und konsistent erfasster Projekte möglichst aus der eigenen Vergangenheit angewiesen.
Ein weiterer Grund mag die Komplexität der vorgeschlagenen Schätzverfahren sein, die sich hierdurch für den Schätzenden teilweise eher als eine Art Black Box darstellen. Da der Schätzende gewöhnlich selbst für die Güte der Schätzung einstehen muss, erscheint die eigene Erfahrung dann häufig attraktiver als sich in die Hände eines intransparenten Modells zu begeben.
In der Praxis besteht die größte Schwierigkeit jedoch darin, überhaupt den Umfang der geplanten Umsetzung zu ermitteln, also festzulegen, wie viele Eingabemasken, Klassen oder Codezeilen für die Umsetzung benötigt werden. Eine solche Quantifizierung des Mengengerüsts, welche Grundlage der meisten datengetriebenen Schätzungen ist, lässt sich nur hinreichend genau vornehmen, wenn das geplante Vorhaben detailliert durchdrungen wurde und die Anforderungen präzise sind. Häufig stellt sich die Quantifizierung des Mengengerüsts als vergleichbar schwierig wie die Bestimmung des Aufwandes selbst dar. Die Anzahl der zur Umsetzung benötigten Codezeilen ist beispielsweise erst sehr spät im Projekt wirklich bestimmbar und muss folglich in der Planung selbst erst einmal geschätzt werden. Funktionspunkte (engl. Function Points) lassen sich bei ausreichender Dokumentation zwar schon in frühen Projektphasen bestimmen, ihre Auszählung ist aber arbeitsintensiv und insbesondere bei Zählenden mit wenig Erfahrung auch anfällig für Fehler.
Hybrides Schätzverfahren
Das Ziel hybrider Schätzverfahren ist es, die Vorteile expertenbasierter Ansätze mit den Vorteilen datengetriebener Ansätze in einer hybriden Methodik zu vereinen [5]. Hierzu werden Informationen aus beiden Quellen geschickt kombiniert. Insbesondere lässt sich hiermit häufig der Umfang notwendiger Daten aus vergangenen Projekten deutlich reduzieren.
Ein gutes Beispiel für eine in der Praxis genutzte und wissenschaftlich bestens dokumentierte hybride Schätzmethode ist CoBRA®. Sie nutzt im Unternehmen vorhandenes Expertenwissen um den Einfluss von Kostentreibern vorab in einem Schätzmodell zu dokumentieren, so dass Schätzungen später auch bei einer geringen Datenbasis valide Ergebnisse liefern können [6].
Einen anderen Weg geht die ebenfalls hybride Abakus-Methode, die abgestimmt auf die Rahmenbedaingungen kleiner und mittelständiger Betriebe im Softwarebereich in den letzten beiden Jahren entwickelt und erprobt wurde. Ihr Fokus liegt auf der gezielten Unterstützung des schätzenden Experten, der werkzeuggestützt durch den Schätzprozess geleitet wird und hierbei jeweils die für die Schätzung relevanten Daten und Unsicherheitsinformationen bereitgestellt bekommt. Details hierzu finden sich in der aktuellen Ausgabe des Entwicklermagazins [7].
Die Abakus-Methode beruht auf einer Reihe grundlegender Prinzipien, von deren Anwendung auch ihre Schätzungen profitieren können [8]:
- Dokumentieren Sie die bei Ihren Projekten gemachte Erfahrungen, insbesondere den tatsächlich benötigten Umsetzungsaufwand für einzelne Features. Nur so lässt sich eine verlässliche Basis für zukünftige Schätzungen schaffen.
- Auch wenn die Anforderungen an ein Projekt zum Zeitpunkt der Schätzung noch nicht vollständig ausgearbeitet sind, identifizieren und zerlegen Sie das Projekt zumindest hinsichtlich der einzelnen bereitzustellenden Features. Jedes Projekt ist neu, Features, die bei der Entwicklung im eigenen Tätigkeitsumfeld häufig eine Rolle spielen, sind meist deutlich stabiler und damit besser abzuschätzen.
- Schätzen Sie den Aufwand für die Umsetzung eines Features möglichst unter Einbeziehung der tatsächlich beobachteten Aufwände bei der Umsetzung des Features in früheren Projekten. Auch erfahrene Schätzer neigen nachweißlich zu systematischen Fehlern in ihren Schätzungen, diese lassen sich am besten eingrenzen indem tatsächlich beobachtete Aufwandszahlen die Ausgangsbasis Ihrer Schätzung bilden.
- Berücksichtigen Sie Gemeinsamkeiten und Unterschiede zwischen dem aktuellen und den früheren Projekten, um Abweichungen nach oben oder unten in der Schätzung zu belegen. Gemachte Annahmen werden damit explizit und die Schätzung nachvollziehbarer.
- Bestimmen Sie nicht nur einen wahrscheinlichsten, sondern auch einen realistischen minimalen und maximalen Schätzwert, berücksichtigen Sie dabei insbesondere die tatsächliche Spannweite der beobachteten Aufwände bei der Umsetzung des Features in früheren Projekten.
[1] Mike Cohn: Agile Estimating and Planning. Prentice Hall, 2005, ISBN 0-13-147941-5
[2] Daniel Kahneman: Schnelles Denken, langsames Denken. Siedler 2012, ISBN 3-88680-886-6.
[3] Jørgensen, Magne; Grimstad, Stein: „Software Development Effort Estimation – Demystifying and Improving Expert Estimation“, in: Tveito, Aslak; Bruaset, Are Magnus; Lysne, Olav (Hrsg.): „Simula Research Laboratory by Thinking Constantly about it“, S. 381–403, Springer, 2010
[4] Boehm, Barry W.: „Software Engineering Economics“, Prentice-Hall,1981
[5] A Trendowicz and R. Jeffery, Software Project Effort Estimation. Foundations and Best Practice Guidelines for Success. Springer Verlag, 2014
[6] A Trendowicz, Software Cost Estimation, Benchmarking, and Risk Assessment: The Software Decision-Makers‘ Guide to Predictable Software Development, Springer Science & Business Media, 2013
[7] Kalenborn, A., Kläs, M., Schmitt, H., „Kalkulation mit der Abakus-Methode – Erfahrungsbasierte Aufwandsschätzung,“ Entwickler Magazin 2.18, S&S Median, 2018.
[8] Kalenborn, A., Kläs, M., Schmitt, H., „Erfahrungsbasierte Aufwandsschätzung – Softwareprojekte zuverlässig und erfolgreich kalkulieren,“ Entwickler Magazin 4.17, S&S Median, 2017.