ESE Fachwissen
Aufwandsschätzung: Handwerk oder Magie?
Autor: Andreas Stucki, Solcept AG
Beitrag - Embedded Software Engineering Kongress 2017
Aufwandsschätzung ist immer dann einfach, wenn man etwas schon mal getan hat. Was aber wenn alles neu ist? Was, wenn die Information über das Projekt nur dürftig ist? Der Beitrag zeigt verschiedene Schätzmethoden auf, bekannte und weniger bekannte, zusammen mit weichen Faktoren, die man beachten sollte. Dann wird gezeigt, wie man die Methoden für zwei Fälle kombinieren kann; zuerst für neue, aber einigermaßen klar definierte Projekte, dann auch für Projekte, die eher noch Ideen sind.
Ist Schätzung so wichtig?
Diese Frage hängt sehr stark davon ab, wen Sie in Ihrer Organisation fragen. Für uns als Ingenieurbüro ist es überlebenswichtig genau zu schätzen, da bereits Fehlschätzungen von ein paar 10 Prozent existenzbedrohend werden können.
Was soll geschätzt werden?
Der folgende Beitrag zeigt auf, wie man für zwei Fälle einen Entwicklungsaufwand schätzen kann. Der erste Fall ist eine Entwicklung, bei der die Spezifikation und vor allem die Schritte zum Produkt einigermaßen bekannt sind. Im anderen Fall kommt der Produktmanager mit einer Produktidee auf einer A4-Seite und will wissen, was die Entwicklung nun kostet − "bis Ende Woche bitte".
Vorbereitung
Vor allem, wenn wenig vorhanden ist, sollte man auf alle vorhandene Information zugreifen können. Daher lohnt es sich, z.B. mit dem Autor der Spezifikation ein Gespräch zu führen, damit klarer wird, was zwischen den Zeilen steht. Diese Information kann man nun in eine WBS (Work Breakdown Structure, auch PSP: Projektstrukturplan) gemäß Bild 2 (s. PDF) überführen, d.h. eine hierarchische Aufteilung des Projektes in immer feinere Arbeitspakete, am besten als Tabelle. Es macht Sinn, diese Pakete hierarchisch zu gliedern, am besten entlang eines Projektlebenszyklus. D.h. entlang der Schritte, "wie wir hier solche Dinge entwickeln".
Was machen wir aber bei der Idee auf einer A4-Seite? Eine WBS würde erfordern, dass wir eine Architektur des Produkts erstellen. Hier kann man eine FBS (Functional Breakdown Structure) gemäß Bild 3 (s. PDF) erzeugen, welche alle Funktionen beinhaltet, am besten hierarchisch geordnet. Vor allem sollte man die Funktionen für verschiedene Entwicklergruppen, z.B. Soft- und Hardware trennen. So kann jede Gruppe ihren eigenen Teil schätzen.
Diese Liste sollte man dann mit allen Beteiligten nochmals durchgehen. So kann man Dinge einfangen, von denen "doch klar ist, dass sie dazugehören". Und übrigens: wenn man die WBS immer ähnlich macht, entsteht mit der Zeit eine Vorlage, die dafür sorgt, dass keine Schritte vergessen werden.
Was schätzen?
Am Ende läuft es immer auf das Geld hinaus, der Stundensatz ist gegeben, man wird also nicht darum herumkommen, den Aufwand in Stunden zu schätzen. Vor allem bei einer FBS, wo vieles noch unklar ist, kann man sich das Leben mit Kategorien vereinfachen, d.h. man sortiert die Funktionen grob nach Komplexität in z.B. S, M, L, XL und schätzt dann nur den Aufwand für jede Kategorie.
Wie schätzen?
Die einfachste Methode ist der heroische Ansatz: man gibt die Liste dem Guru, der "soll nun mal sagen, was der Aufwand ist".
Weil das häufig nicht funktioniert, hat die Rand Corporation Wideband Delphi [RC] erfunden, wiedererweckt als Planning Poker [JG]. Dabei gibt jeder Experte zu jedem Arbeitspaket seine Schätzung ab, aber er erfährt erst von der Schätzung aller anderen, nachdem er selbst geschätzt hat (Details zum Vorgehen: [PP]). Der Konsens aus der iterativen Anwendung dieses Prozesses ist meist sehr gut, da niemand dem Leithammel einfach folgen kann.
Parameter-basierte Schätzung erlaubt einfache, aber genaue Schätzung. Man weiss z.B. wie viel Zeit man pro wöchentlicher Projektsitzung verbraucht, diese multipliziert mit der Anzahl der Anwesenden und der Anzahl Wochen gibt eine gute Aufwandsschätzung.
Auch historische Daten liefern gute Anhaltspunkte. Wir wissen zum Beispiel, dass ein Projekt ziemlich genau 10-mal mehr Aufwand macht als die sauber abgeschlossene Systemdesign Phase. Wenn also diese Phase 400 h braucht, braucht das Gesamtprojekt wohl ca. 4000 h. Man beachte hier, dass der Zusammenhang nicht-linear sein kann, z.B. für ein großes Projekt der Aufwand nur mit 8 multipliziert werden muss.
Und man muss die historischen Daten zuerst mal haben. Das heißt, dass ein Projekt-Controlling stattfinden muss, welches diese Parameter erfasst.
Wie geht man mit Unschärfe um?
Jede Schätzung ist mit Unschärfe behaftet, und es ist hilfreich, diese zu kennen.
In [RS] S. 112 findet man dazu eine 3-Punkt Schätzung. Es werden zuerst der wahrscheinlichste Aufwand N, der kleinstmögliche K und der größtmögliche G geschätzt. Der resultierende zu erwartende Schätzwert S (basierend auf der Beta-Verteilung) ist dann: S:= (K + 4N + G)/ 6. An derselben Stelle findet man auch eine getunte Formel, welche ein Gewicht von N zu G verschiebt, um die "Neigung der Schätzer zum Optimismus" auszugleichen: S:= (K + 3N + 2G)/ 6.
In [WR] S. 146 wird daraus eine einfachere Formel, indem die kleinstmögliche Schätzung gerade ganz weggelassen wird, d.h. es wird eine 2-Punkt Schätzung gemacht: S:= (0K + 4N + 2G)/ 6 = (2N + G)/ 3. Damit ist der Aufwand für eine Schätzung gespart und der Ausgleich für den Optimismus gerade eingebaut. Die Formel hat auch eine einfache Begründung in der Normalverteilung: Wenn man annimmt, dass G bei 3 Standardabweichungen liegt, dann liegt S bei 1 Standardabweichung. D.h. in 84% der Fälle liegt der Aufwand unter S.
Für eine statistisch sauberere 2-Punkt-Schätzung kann die Log-Normal Verteilung herangezogen werden. Diese hat den Vorteil, dass sie von 0 (Aufwände unter 0 sind unrealistisch) bis unendlich definiert ist und sich auch aus den zwei Parametern N und G bestimmen lässt. Ihr Nachteil ist, dass es einige Numerik braucht, um die Verteilung z.B. zu summieren.
Was ist mit den Risiken?
"If a project has no risks, don't do it" [dML].
Welche Risiken sind nun in der Schätzung enthalten? Welche nicht? Dies wird vom Schätzteam in der Diskussion (z.B. während des Planning Poker) entschieden. Und zwar in der Form von Annahmen und verbleibenden Risiken außerhalb der Schätzunschärfe. Es empfiehlt sich daher, zu jedem Punkt der WBS/ FBS beide in der Diskussion zu dokumentieren, damit sie nicht verloren gehen.
Beide kann man dann für die Risikofeststellung des Projektes verwenden, denn Risiken sind ja Annahmen, die nicht eintreffen. Wenn man diese Risiken mit Schaden und Eintretenswahrscheinlichkeit beziffert erhält man die Risikosumme, welche ein wichtiger Bestandteil der Abschätzung ist.
Was muss man sonst noch beachten?
Keine zu großen Aufgaben schätzen: typisch sollten die auf einmal geschätzten Aufgaben nicht größer als 40, maximal 80 Stunden sein.
Die Schätzung budgetieren: überlegen, wieviel Zeit man für die gesamte Schätzung aufwenden will. Dann kann man die Zeit für jede Schätzung z.B. mit einem Timer begrenzen.
Aufwand (Stunden) ist nicht gleich Dauer (Stunden): je nach Organisation und Erfahrung arbeiten Entwickler maximal 70..80% für das Projekt, dies also einplanen.
Und übrigens: Man kann die Methoden grundsätzlich auch verwenden, um andere Grössen zu schätzen, zum Beispiel Kosten oder Speicherbedarf.
Wie schätzt man auf Basis einer Spezifikation?
Falls wir eine genügend detaillierte Spezifikation haben, gehen wir folgendermaßen vor: Zuerst erstellt der Projektleiter basierend auf einer Vorlage eine WBS-Tabelle mit einer Beschreibung der einzelnen Arbeitspakete.
Dann führt das Team unter der Leitung des Projektleiters Planning Poker durch. Das Team schätzt zuerst den wahrscheinlichsten, normalen Fall und dann den Spread, d.h. die Differenz zum größtmöglichen Aufwand ("Worst Case"). Die Diskussion (Beschreibung, Annahmen und verbleibende Risiken) werden vom Projektleiter während der Diskussion dokumentiert.
Der geschätzte Aufwand berechnet sich für jede Aufgabe der WBS gemäß S := (2N + G)/ 3. Zur Gesamtsumme werden für eine realistische Schätzung die gewichteten Risiken dazu gezählt. Unter [Sc1] finden Sie eine Vorlage für ein Spreadsheet für diese Schätzung. Wir haben uns ein Tool geschrieben (von dem die Bilder stammen), welches es erlaubt, auch parametrische Schätzungen aufgrund historischer Daten einfach einzubeziehen.
Und bei einer Projektidee?
Und die Schätzung einer Projektidee? Dazu erstellt der Projektleiter eine FBS-Tabelle und beschreibt die Funktionen und sortiert sie nach Komplexität in S..XL ein. Siehe Bild 3 im PDF.
Das Team wählt zufällig drei Funktionen von jeder Komplexität (S..XL). Es schätzt für diese nun N und G mit Planning Poker wie oben. Dann schätzt das Team basierend auf historischen Daten die Parameter wie z.B. den Anteil von Test und Debugging an der Entwicklung. Daraus lässt sich numerisch oder mit Monte-Carlo Simulation die Verteilung für das gesamte Projekt berechnen. Unser Tool kann auch das, unter [Sc2] finden Sie unser Tool für die Abschätzung von Steuerungsprojekten. Auch zu diesem Resultat macht es Sinn, die Summe der Risikoabschätzung dazu zu zählen.
Für den Schätzer hat die Methode den Vorteil, dass er einen Bereich aus der Verteilung angeben kann, z.B. das 90% Konfidenzintervall. Damit gibt er seinem "Kunden" in die Hand, wie viel Risiko er nehmen will. Sobald das Projekt klarer wird, kann man statt der FBS eine WBS erstellen und zumindest die nächste Phase genauer abschätzen.
Referenzen
[RC]: Wikipedia: "Delphi Method", 2017, https://en.wikipedia.org/wiki/Delphi_method (download: 2017-09)
[JG]: J. W. Grenning: "Planning Poker", 2002, https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf (download: 2017-09)
[PP]: Solcept: "Planning Poker Anleitung", 2017, https://www.solcept.ch/de/pp (download: 2017-09)
[RS]: R. D. Stutzke: "Estimating Software Intensive Systems", 2005
[WR]: W. Reiter: "Die nackte Wahrheit über Projektmanagement", 2003
[dML]: T. DeMarco, T. Lister: "Waltzing with Bears", 2003
[Sc1]: Solcept: "ESE Kongress Referenzen", 2107, https://www.solcept.ch/de/blog/ese-kongress-2017/ (download: 2107-12)
[Sc2]: Solcept: "OnlineEstimation", 2017, https://www.solcept.ch/de/aufwandsschaetzung/ (download: 2107-12)
Autor
Andreas Stucki, Dipl. El.-Ing. ETHZ, Geschäftsleiter von Solcept AG hat eine 20jährige Erfahrung in der Projektleitung von embedded Soft- und Hardware-Projekten im industriellen und kommerziellen Umfeld.
Kontakt
Internet: www.solcept.ch
E-Mail: a.stucki@solcept.ch
Software Engineering Management - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Software Engineering Management /Prozess-, Projekt- und Produktmanagement.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Software Engineering Management - Fachwissen
Wertvolles Fachwissen zum Thema Software Engineering Management /Prozess-, Projekt- und Produktmanagement steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.