Eine Wahrsagerin hält die Hände um eine Kristallkugel

Wie macht man eine Grobschätzung? Ohne Glaskugel?

Lesezeit 5 min

Dies ist der anspruchsvollere Fall als die Projektschätzung. Wie kann man eine Schätzung machen, wenn die Anforderungen und auch die Architektur eines Produkts noch nicht klar sind? Wie soll man eine Aufwandsschätzung machen, wenn nur gerade mal eine erste Idee auf einem A4-Blatt skizziert ist?

Wie kann man aus der vorhandenen Information das Maximum herausholen? Das Maximum heisst hier: In welchem Bereich liegt der zu erwartende Aufwand?

Kaffeesatzlesen für Kaffeemaschinensteuerung

Ein solches Beispiel war bei uns die Entwicklung einer Steuerung für eine Kaffeemaschine in der Anfangsphase. Das Projekt umfasste am Ende mehrere Personenjahre Arbeit. Die erste Schätzung basierte auf den damals vorhandenen Informationen: einem Lastenheft von zwölf Seiten inklusive Deckblatt und Inhaltsverzeichnis und einem groben Menübaum für die Bedienung…

Wie kann für ein Projekt in dieser frühen Phase eine Schätzung erzeugt werden, die nicht nur reines Kaffeesatzlesen ist?

Was erwartet Sie?

Und auf separaten Seiten:

Wir arbeiten schon seit vielen Jahren mit dieser Schätzmethode und haben dazu ein Software-Werkzeug erstellt, welches wir bei genügend Interesse als Freeware anbieten, bitte kommentieren Sie unten, wenn Sie Interesse haben.

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.

Funktionsgruppe Funktionsuntergruppe Funktion Anzahl Komplexität Beschreibung Annahmen Verbleibende Risiken
Schnittstellen Host LAN 1 L an SCADA   LAN-Treiber muss selbst portiert werden
    seriell 2 S für Legacy-Anlagen    
  User LCD-Grafikanzeige 1 XL Dot-Matrix max. VGA-Auflösung  
    10er-Tastatur 1 S      
  Protokolle MODBUS 1 M      
    Propritäres Host-Protokoll 1 XL      

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.

Kategorie Implementation Normalfall/ Ph Implementation Worst Case/ Ph
S 2 20
M 8 40
L 20 80
XL 40 200

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.

Modul Phase Projektlebenszyklus Beschreibung Anzahl Iterationen Aufwand relativ zur Implementation Normalfall Aufwand relativ zur Implementation Worst Case
Software Implementation Design, Entwicklung & Test auf Unit Level 1 1.0 1.0
  Modul Integration & Test Erste Integration und Tests, inkl. Debugging 1 0.4 1.0
  Modul Regressionstest Regressionstests & Debugging für iterative Releases 3 0.2 0.3
  Modul Design Architektur & Design des Moduls 1 0.2 0.4

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

Stichworte/ Tags

Kommentare

Keine Kommentare

Was ist Ihre Meinung?

* Diese Felder sind erforderlich

Teilen auf

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren