Wie macht man eine Grobschätzung? Ohne Glaskugel?

System Design: Wirklich?

Wenn man bei dieser Datenlage eine Work Breakdown Structure (WBS, Projektstrukturplan (PSP)) erstellen möchte, dann macht man implizit bereits eine System Design Phase mit vielen Annahmen. Das führt zu einem grossen Aufwand, der in dieser frühen Phase so nicht gerechtfertigt ist und sich vor allem nicht lohnt, da sich mit grösster Wahrscheinlichkeit die Spezifikation nochmals ändert und dadurch die WBS wertlos wird.

Was nun? Die Lösung liegt darin, die vorhandenen Informationen zu nutzen, welche vor allem die Funktion des zu entwickelnden Produkts betreffen.

Functional Breakdown Structure

Statt die Schätzung nach den Arbeitspaketen zu strukturieren, wird sie für die Functional Breakdown Structure (FBS) nach Funktionen und Funktionsgruppen strukturiert.

Aufteilung in Funktionen durch den Projektleiter

Auf der obersten Ebene teilt man das Projekt am besten nach Fachgebieten auf, zum Beispiel Software, Hardware, Mechanik. Dies führt dazu, dass jedes Fach seine Aufwände unabhängig schätzen kann. Innerhalb der Fachgebiete werden die Funktionen falls nötig zu Gruppen zusammengefasst, innerhalb der Gruppen finden sich dann die einzelnen Funktionen. Diese Arbeit kann der Projektleiter oder der entsprechende Fachspezialist sehr gut allein durchführen.

Falls Funktionen mehrere Fachgebiete betreffen, kommen sie mehrmals vor, zum Beispiel eine USB-Schnittstelle in Software (USB-Stack) und Hardware (USB-Elektronik).

Eine zusätzliche Vereinfachung ergibt sich dadurch, dass man die Anzahl der gleichartigen Funktionen angibt, das heisst nicht das Produktmenü, das Reinigungsmenü... , sondern dass man angibt, wie viele Menüs derselben Komplexität vorkommen, zum Beispiel "6 Bedienmenüs".

Da die FBS nicht vom Projektablauf abhängt, ist es schwieriger, eine generische Vorlage zu erzeugen als im Fall der WBS, die einem Projektlebenszyklus folgt.

Ausschnitt aus einer grösseren FBS

Eine kurze Beschreibung der Funktionen ist immer hilfreich, und auch erste Annahmen und über die Schätzung hinaus verbleibende Risiken können schon dokumentiert werden.

Informationssammlung mit allen Beteiligten

Wenn man die FBS so weit erstellt hat, dann macht es Sinn, die Struktur nochmals mit allen Stakeholdern anzuschauen. Häufig gewinnt man dann noch neue Informationen durch Änderungen oder zusätzliche Funktionen, die in der ersten Dokumentation vergessen gingen.

Kategorisierung von Funktionen durch den Projektleiter

Um die Schätzung zu vereinfachen, werden die Funktionen nicht einzeln geschätzt, sondern vom Projektleiter oder Fachspezialisten in zum Beispiel vier Komplexitätskategorien (S, M, L und XL) eingeteilt. Diese grobe Einteilung verringert einerseits den Schätzaufwand, andererseits führt sie dazu, dass keine unnötigen Diskussionen über feine Unterschiede aufkommen, die im groben Endresultat sowieso untergehen.

Schätzung des Aufwandes im Team

Schätzung des Implementationsaufwandes

Nun kann der Aufwand für die Implementation der einzelnen Kategorien in Stunden abgeschätzt werden. Diese Abschätzung wird pro Fachbereich durchgeführt (also mit dem Software-Team, dem Hardware-Team etc.).

Dazu werden aus jeder Kategorie (S, M, L, XL) drei Funktionen ausgewählt, die eine möglichst grosse Diversität repräsentieren (z.B. Menü / Treiber / Regler). Für diese schätzt man den Implementationsaufwand für den Normalfall (d.h. der häufigste Fall) und den schlimmsten Fall als eine Art Mittelwert der drei gewählten Funktionen.

Auch diese Schätzung wird mit Planning Poker durchgeführt.

Beispiel für die Schätzung des Implementationsaufwands für die vier Kategorien

Schätzung der restlichen Arbeitsschritte

Nun kommt der Projektlebenszyklus doch noch ins Spiel. Nachdem oben die Implementation abgeschätzt wurde, fehlen noch wichtige Dinge wie Integration, Test und Debugging, aber auch Projektmanagement. Diese werden als Prozentsatz in Relation zur Implementation angegeben.

Zu schätzende Parameter (kursiv) für einen typischen Projektzyklus für Software

Und auch diese Prozentsätze haben wieder einen Normalwert (den häufigsten Fall) und einen schlimmsten Fall. Diese Schätzung wird am besten mit Planning Poker durchgeführt. Als Referenz kann man historische Werte hinzuziehen.

Ohne etwas Wahrscheinlichkeitsrechnung geht es nicht

Nachdem nun die einzelnen Schätzungen erstellt sind, müssen sie noch summiert werden. Dies funktioniert nicht ohne etwas Wahrscheinlichkeitsrechnung. Für die Wahrscheinlichkeitsverteilung der einzelnen Schätzungen wird eine Lognormalverteilung verwendet.

Als Resultat möchten wir nicht nur den Erwartungswert, das heisst den Wert, den der Aufwand im Mittel annimmt, angeben können, sondern auch den Bereich, in dem sich die Schätzung bewegt. Dieser ist interessant, da er eine Auskunft über die Schätzsicherheit und das Risiko des Projekts beinhaltet.

Wir verwenden das Konfidenzintervall 90% , das heisst der Bereich in dem 90% der geschätzten Werte liegen. Oder anders gesagt: es wurde geschätzt, dass das Projekt mit einer Wahrscheinlichkeit von 5% unterhalb des unteren Werts des Konfidenzintervalls oder mit derselben Wahrscheinlichkeit von 5% oberhalb des oberen Werts des Konfidenzintervalls liegt.

Alle diese Berechnungen basieren auf Wahrscheinlichkeitsverteilungen.

Da auch wir immer besser werden möchten, geben Sie unten bitte Kommentare, Ideen, Vorschläge und Fragen ein. Ich werde sie dann in eine nächste Version einfliessen lassen.

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!