Aufwandsschätzung in der Softwareentwicklung ist ein Dauerbrenner und heiß diskutiertes Thema. Es gibt unterschiedliche Schätzverfahren von der Delphi-Methode bis hin zu Function Points. Was die unterschiedlichen Methoden verbindet ist die Erkenntnis, dass sie alle Vor- und Nachteile haben und dass es immer eine Schätzung bleibt, bei der die Wahrscheinlichkeit, nah am tatsächlichen Aufwand zu liegen, abhängig von den zu Grunde liegenden Informationen steigt oder sinkt.
Wenn man also davon ausgeht, dass jede Schätzung durch die Menge der zur Verfügung stehenden Informationen näher oder weniger nah am tatsächlichen Aufwand liegt, halte ich die Diskussion über die Schätz-Methode für die Kür und die Gestaltung der Kür ist eine Frage von “Geschmack” und “Glauben”. Schätzabweichungen wird es immer geben, weil man trotz großer Anstrengungen nicht alle Informationen zum richtigen Zeitpunkt haben kann, um Aufwände mit Sicherheit benennen zu können. Was aber kann man tun, wenn nicht die Wahl der Schätzmethode die Genauigkeit der Vorhersage maßgeblich beeinflusst?
Ich halte es für interessanter darüber nachzudenken, wie man mit der Unsicherheit von Schätzungen an sich gut umgehen kann und welche Rahmenbedingungen man neben dem reinen Umsetzungsaufwand bei einer Schätzung noch berücksichtigen sollte, um eine möglichst gute Vorhersage treffen zu können. Die erste Frage sollte sein: Wofür brauche ich die Schätzung eigentlich? Schätze ich für eine Releaseplanung, für eine konkrete Umsetzung oder für ein Angebot. Davon hängt meistens der Umfang der zu Grunde liegenden Informationen ab und auch die Art und Intensität der Schätzung. Schätze ich mit einzelnen Experten oder mit Gruppen oder mit einem ganzen Team? Je näher ich der konkreten Umsetzung einzelner Aufgaben komme, um so mehr Informationen brauche und habe ich und um so wahrscheinlicher ist eine geringe Abweichung der tatsächlichen Aufwände von der Schätzung. Nach Beantwortung der ersten Frage müssen aus meiner Sicht bei einer Schätzung neben den konkreten fachlichen Anforderungen und technischen Rahmenbedingungen auch die folgenden drei Punkte besonders beachtet werden.
- Größe der einzelnen Aufgaben – Je kleiner einzelne Aufgabenpakete sind, um so einfacher lassen sich die Anforderungen verstehen und die technischen Rahmenbedingungen überblicken. Dadurch reduziert sich das Risiko unvorhergesehener Störungen. Außerdem lassen sich kleine Aufgaben schneller erledigen. Das verringert das Risiko von Veränderungen der Rahmenbedingungen während der Umsetzung.
- Betrachtung historischer Werte – Besser als die reine Annahme von Aufwand für zukünftige Aufgaben ist die Betrachtung historischer Werte ähnlicher Aufgaben und die Betrachtung der historisch gemessenen durchschnittlichen Entwicklungsgeschwindigkeit. Warum Aufwände raten, wenn ich sie von bereits gemachten Erfahrungen ableiten kann?
- Unsicherheit in der Schätzung – Einzelne Aufgaben sind unterschiedlich komplex und unterschiedlich gut verstanden. Schätzungen für einzelne Aufgaben können also sicherer oder unsicherer sein. Diese Unsicherheit sollte in die Schätzung mit einfließen.
Ist man so zu einer Schätzung bekommen, hat man einen recht guten Eindruck davon, welcher Aufwand wahrscheinlich entstehen wird. Welchen Einfluss das wiederum auf das konkrete Angebot hat, hängt von vielen weiteren Faktoren und Business-Entscheidungen ab.
Excel-Unterstützung
Christian Fischer hat sich vor einiger Zeit intensiver mit dem Thema Agiles Puffermanagement beschäftigt und ich durfte dabei mit ihm zusammen arbeiten. Das Ergebnis vieler teilweise gemeinsamer Überlegungen war ein Excel-Sheet, das ich noch heute gerne einsetze, das bei einer Aufwandsschätzung unterstützt und dabei die obigen Punkte berücksichtigt.