So betreiben Sie eine sinnvolle Aufwandsschätzung auch bei wenig Informationen

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.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Solcept AG

Ist Aufwandsschätzung wirklich so wichtig? Und was soll geschätzt werden? Diese Fragen hängen bei Software Engineering Management sehr stark davon ab, wen Sie in Ihrer Organisation fragen. Für uns als Ingenieurbüro ist es allerdings überlebenswichtig genau zu schätzen, da bereits Fehlschätzungen von ein paar 10 % existenzbedrohend werden können.

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 einigermassen 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“.

Bildergalerie

Aufwandsschätzung: Die richtige 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 ü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) wie in Bild 3 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 muss geschätzt werden?

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ätze ich den Aufwand richtig ein?

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össtmö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 ausserhalb 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 bei der Aufwandsschätzung sonst noch beachten?

• Keine zu großen Aufgaben schätzen: typisch sollten die auf einmal geschätzten Aufgaben nicht grösser 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ößen 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 folgendermassen 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äss 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?

Dazu erstellt der Projektleiter eine FBS-Tabelle und beschreibt die Funktionen und sortiert sie nach Komplexität in S..XL ein.

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.

Aufwandstreiber und Kostenbewertung im zeitgemäßen Software Engineering

Tipps und Tricks für zeitgemäßes Projektmanagement

Der 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.

Referenzen und Literaturangaben

[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)

(ID:45625516)