Warum es schwer ist, den Aufwand zu schätzen
Sicher, die einzelnen Bestandteile der zu entwickelnden Hardware sind ungefähr klar, von Spannungsversorgung bis Datenspeicherung. Auch der übliche Aufwand um die einzelnen Bestandteile zu entwickeln, lässt sich aus Erfahrungswerten ableiten.
Ein großes Problem aber bleibt: fast alle Entwicklungsprojekte fallen leider in die Kategorie “Problem bekannt, Lösung unbekannt” und lassen sich deshalb nur schwer planen und schätzen.
© Alphaboard
Problem bekannt, Lösung bekannt
Schauen wir uns ein Beispiel an, damit wir diese Situation komplett verstehen. Wir bei alpha-board sind ein kleiner Berliner Dienstleister für Elektronik-Design und Fertigungsservice. Wir beschäftigen derzeit, alle Studenten, Teilzeit-Arbeitskräften und Azubis eingerechnet, knapp 30 Mitarbeiter.
Nehmen wir an, für eine Weihnachtsfeier sollen wir für alle Mitarbeiter eine Kürbissuppe kochen. Problem bekannt, Lösung bekannt: es geht um eine reine Implementierung eines bekannten Rezepts:
- wir suchen uns ein Rezept für Kürbissuppe aus
- rechnen die Zutaten für 30 Leute hoch
- schreiben einen Einkaufszettel
- gehen einkaufen
- schälen und hacken den Kürbis und die Möhren
- anbraten lassen, mit Brühe versetzen etc.
Jeder einzelne Schritt lässt sich planen und wenn Sie wollen, kann ich Ihnen genau sagen, was ich gegen 11:45 Uhr tue, wenn um 12:30 Uhr das Essen für alle warm auf dem Tisch landen soll. Projekte dieser Art (Problem bekannt, Lösung bekannt) lassen sich sehr genau schätzen.
Verändern wir die Aufgabenstellung ein wenig: Wir wollen für die Weihnachtsfeier für alle unsere Mitarbeiter deren jeweiliges Lieblingsessen kochen. Tja, nun wird’s kompliziert. Welche Zutaten brauche ich? Was soll ich einkaufen? Wann fange ich womit an? Was ist, wenn sich Mitarbeiter zwischendrin überlegen, dass ihr Lieblingsessen ein ganz anderes ist?
Dies ist exakt die Situation, in der das Problem bekannt ist (Lieblingsessen für 30 PCB-Designer und Hardware-Entwickler kochen), die Lösung aber völlig unbekannt (was essen diese PCB-Design-Heinis eigentlich am liebsten?).
Anzugeben, was wir einkaufen müssen, und wann wir mit dem Kochen anfangen müssen, damit das Gemampfe rechtzeitig um 12:30 Uhr beginnt, fällt auf einmal sehr, sehr schwer.
Keinen Bock auf Staffellauf, wir spielen lieber Rugby
Genau von dieser Art sind auch die meisten Hardware-Entwicklungsprojekte, die wir übernehmen: Problem bekannt, Lösung leider unbekannt. Das üblicherweise verwendete Projektmanagement, Wasserfall- oder Gantt- oder Balkenplan-Projektmanagement genannt, versagt hier, weswegen wir auch auf PM-Tools wie MS Project verzichten und unsere Projekte im Team lieber mit Asana.com verwalten.
Wir sind dabei, unser Projektmanagement auf AGILE/SCRUM umzustellen. Das wurde für unsere Situation extra entwickelt und stammt aus der Software-Entwicklung. SCRUM (engl. Gedränge, bekannt aus Rugby) hilft, sich der unbekannten, perfekten Lösung iterativ schnell zu nähern (die Vorzüge von SCRUM wurden bereits 1986 von Hirotaka Takeuchi und Ikujiro Nunaka in ihrem Artikel für den Harvard Business Review “The New Product Development Game” beschrieben).
Und bei SCRUM gibt es auch eine Methode, den Aufwand zu schätzen, der genau für unsere Situation hilft. Wir zeigen Ihnen, wie das geht.
Wir spielen Poker!
Bei SCRUM schätzen Sie eigentlich auch nicht den Aufwand für Arbeitspakete im herkömmlichen Sinne. Dort unterteilen Sie den gesamten Aufwand für Ihr Projekt nicht nach Arbeitsschritten oder Meilensteinen, sondern nach User Stories – kleinen Geschichten, die eine Funktionalität aus Sicht eines Stakeholders beschreiben, damit das Entwicklungsteam besser versteht, was der Sinn dieser Aufgabe ist. Fürs Schätzen ist es aber eigentlich egal, ob Sie Ihr Projekt wie herkömmlich in Arbeitsschritte und Meilensteine unterteilen, oder in User Stories.
Egal, wie Sie Ihr Projekt unterteilen, den Aufwand schätzen Sie mit Planning Poker. Dafür verwenden Sie spezielle Planning Poker-Karten mit Zahlen drauf, die ganz ungefähr der Fibonacci-Reihe entsprechen (Leonardi Fibonacci entwickelte die Folge der Fibonacci-Zahlen im Jahre 1202, um eine Kaninchenpopulation zu beschreiben – jede Fibonacci-Zahl ist die Summe der zwei vorhergehenden und nach einer Weile ist das Verhältnis zweier aufeinanderfolgender Fibonacci-Zahlen ungefähr 1,618… und entspricht dem Goldenen Schnitt).
Wir haben für Sie (und für uns) ein Set von Planning Poker-Karten entwickelt, das Sie gerne downloaden und in Ihrem Projekt verwenden können. Die einzelnen Karten haben die Werte 1, 2, 3, 5, 8, 13, 20, 40, 100.
Planning Poker – Der Ablauf
Planning Poker spielen Sie im Team. Unsere Teams bestehen aus bis zu sechs Leuten. Mindestzahl für eine Planning Poker-Session ist aber drei Mitspieler. Sollten Sie ein Projekt schätzen wollen, dass letzten Endes nur ein Team-Mitglied bearbeiten wird, sollten Sie trotzdem mindestens drei erfahrene Leute zum Planning Poker bitten, die das Projekt übernehmen KÖNNTEN.
Die Vorbereitung für Planning Poker läuft wie folgt ab:
- ijedes Teammitglied bekommt einen Satz Karten
- das Team schaut sich alle Projektabschnitte (bei SCRUM: User Stories) an und entscheidet sich für die leichteste, einfachste davon
- idafür müssen sich alle einig sein
Diese Aufgabe ist nun die Vergleichsaufgabe mit einem Aufwand von 1 Storypunkt. Wir benutzen diese Aufgabe, um alle anderen Aufgaben damit in Relation zu setzen. Die leichteste Aufgabe ist die “1”. Sie werden später sehen, ob das 1 Mannstunde oder 1 Mannwoche ist – aber alle anderen Aufgaben stehen mit dieser in Relation!
Nun beginnt der eigentliche Planning Poker:
- der Projektleiter (bei SCRUM: SCRUM Master) stellt den Projektabschnitt (bei SCRUM: die Userstory) vor
- das Schätzer-Team bespricht den Abschnitt / die Story
- jedes Teammitglied entscheidet für sich, wie viel Aufwand in dem Abschnitt / der Story steckt
- alle zeigen gleichzeitig ihre ausgewählte Karte
Wenn alle Teammitglieder die gleiche Karte zeigen, wird die Schätzung erfasst und es geht mit der nächsten Story weiter. Bei großen Unterschieden der gezeigten Werte müssen die Teilnehmer mit den jeweils niedrigstem und höchstem Wert ihre Schätzung begründen.
In diesem Gespräch, das nicht länger als 2-3 Minuten dauern soll, findet fürs gesamte Team ein Lernprozess statt. Nach diesen Erläuterungen wiederholt das Team die Schätzung, bis sich alle auf einen Wert geeinigt haben. Bei jeder Schätzung darf jedes Teammitglied die Karte legen, die ihm in dieser Situation am sinnvollsten erscheint (und nicht notwendigerweise immer dieselbe).
Am Ende haben Sie für jeden Arbeitsschritt (bei SCRUM: für jede User Story) einen vom Team gemeinsam geschätzten und somit teamweit getragenen Aufwandswert, in Relation zum einfachsten Arbeitsschritt. Wenn Sie diesen zeitlich bestimmen können (zum Beispiel, indem Sie ihn sofort erledigen lassen und die Zeit stoppen), kennen Sie auch den Aufwand für alle anderen Aufgaben – und somit in der Summe auch fürs Gesamtprojekt.
Wir bei alpha-board haben mit Planning Poker sehr gute Erfahrungen gemacht. Das Team hat sehr gut verstanden, was alles beim kommenden Projekt auf sie wartet. Wir hören oft Aussagen wie “So gut habe ich die einzelnen Aufgaben vorher nie verstanden”.
