In der Praxis ist häufig am Arbeitsumfang und Zeitrahmen eines Projekts nicht zu rütteln. Den Entwicklern bleibt daher weniger Zeit, als sie eigentlich benötigen, um alle Aufgaben vollständig und in angemessener Qualität durchzuführen. Darauf reagieren Entwickler, indem sie entweder mehr oder nachlässiger arbeiten – oder beides zugleich. Zunächst verkürzen sie die Kaffeepausen und schränken die Zeit für Mahlzeiten ein, Meetings verschieben sie oder streichen sie zusammen; wenn das nicht ausreicht, machen sie Überstunden; wenn das ebenfalls nicht genügt, dann arbeiten sie vielleicht noch am Wochenende. Aber dadurch lässt sich die Arbeitsleistung nur um 30 bis 40% erhöhen, denn irgendwann sind die Kompensationsmöglichkeiten erschöpft.
Mehrarbeit ist eine Möglichkeit, kurzfristige Termine einzuhalten, etwa die Präsentation in der nächsten Woche, aber keine Lösung langfristiger Probleme. Wochen- oder monatelange Mehrarbeit verschafft nur vordergründig Luft; langfristig führt der Verzicht auf Privatleben und die dauerhafte Überbelastung zu Unzufriedenheit, Erschöpfung und Burnout-Gefühlen, die den kurzfristigen Zeitgewinn langfristig wieder zunichte machen: Die Arbeitsleistung sinkt unterm Strich unter 100%.
Übrigens ist auch der Verzicht auf Qualität eine Sackgasse. Entwickler sind zu vielen Kompromissen bereit, aber wer ständig nach dem Motto »Es ist das gut genug, was Auftraggeber und Anwender gerade eben noch schlucken« arbeiten muss, der wird irgendwann feststellen, dass er seine eigenen Qualitätsansprüche verraten hat. Vor allem für die Leistungsträger ist das häufig Grund, sich nach einem anderen Arbeitgeber umzusehen.
Wenn der Verlauf eines Projekts nicht dessen Planung entspricht, liegt das häufig daran, dass die Realität sich einer genauen Schätzung entzieht. Dieser Artikel zeigt, wie Sie dennoch zu guten Schätzungen gelangen, und betrachtet sowohl klassische Schätzverfahren als auch moderne Verfahren in agilen Projekten.
Aufwandschätzung für Entwickler
Im Alltag spricht man von einer Schätzung, wenn eine intuitive Zahlenangabe oder Bewertung einer messbaren oder zählbaren Größe auf raschem Wege nach dem Augenschein, mit Intuition oder mittels Erfahrung bestimmt wird.
Beispiele für Alltagsschätzungen sind:
- Ich schätze, da fehlen noch drei Teelöffel Zucker.
- Wir müssen noch etwa 10 km fahren.
- Es sind schätzungsweise 150 Personen anwesend.
- Der Film müsste in einer Viertelstunde zu Ende sein.
Aus Sicht des Projektmanagements sind dies keine zulässigen Schätzungen.
Eine Schätzung ist stets ein Näherungswert, der mit einer bestimmten Wahrscheinlichkeit in einem bestimmten Bereich liegt.
Zulässige Schätzungen sind:
- Mit einer Wahrscheinlichkeit von über 70 % bleiben wir unter 3 Tagen.
- Wir brauchen bestenfalls 2 Tage, schlimmstenfalls 4 Tage.
- Mit einer Wahrscheinlichkeit von 80 % brauchen wir 5 plusminus einen halben Tag.
Die Herausforderungen, mit denen ein Schätzer zu tun hat, ähneln jenen, denen sich ein Pokerspieler stellen muss: Basierend auf unvollständigen Informationen, Annahmen und Wahrscheinlichkeiten müssen Entscheidungen getroffen werden, bei denen viel Geld auf dem Spiel stehen kann.
Der Cone of Uncertainty (siehe Abb. 1) beschreibt den Verlauf von Unsicherheiten in einem Projekt: Eine Schätzung, die zu Beginn eines Projekts vorgenommen wird, also noch vor der Anforderungsphase, ist im Durchschnitt mit einer Unsicherheit von Faktor 4 belastet. So kann die tatsächlich benötigte Zeit eines Projekts vier Mal so lang oder auch nur ein Viertel so lang sein wie zu diesem Zeitpunkt geschätzt. Die Unsicherheit nimmt im Projektverlauf zwar stetig ab, aber bis zum Ende des Projekts bleibt eine gewisse Unsicherheit bestehen.
Abb. 1: Cone of Uncertainty
Es bietet sich der Vergleich zum Verlauf einer Pokerhand an, bei der die Informationsmenge mit dem Aufdecken der Gemeinschaftskarten sowie dem Spielverhalten der Mitspieler zunimmt, aber erst beim Showdown Gewissheit vorherrscht; wobei der Spieler bereits zu Beginn Einschätzungen treffen muss, die er im Verlauf der Hand ständig überdenkt und neu bewertet.
Ähnlich wie Pokerspieler, die ihre eigenen Chancen, eine Hand zu gewinnen, zu hoch einschätzen oder deren Hoffnung größer ist als die objektive Wahrscheinlichkeit, scheitern viele Schätzer an ihrem eigenen Optimismus. Die Praxis zeigt nämlich: Die meisten Entwickler schätzen den zu erwartenden Aufwand um bis zu 30 % zu optimistisch ein. Was dann dabei heraus kommt, liegt auf der Hand: Der Kunde freut sich über das günstige Angebot und der Entwickler hat es mit einem unrealistischen Projektplan zu tun.
Eine dritte Parallele lässt sich ziehen: Pokerspieler können versteckte »Monsterhände« so schnell übersehen wie Schätzer verstecke Aufwände. Beim Pokern sind dies unauffällige Drillinge oder Straßen in der Hand des Gegners, die die eigene Hand beim Showdown alt aussehen lassen; bei der Aufwandschätzung Aktivitäten wie Dokumentation oder Meetings. Denken Sie daran: Gespräche und Abstimmungen mit dem Kunden oder dem Team untereinander kosten ebenfalls Zeit. Ein zweistündiges Meeting mit vier Personen entspricht einem Personentag! Über die gesamte Projektlaufzeit betrachtet kann da einiges an versteckten Aufwänden zusammenkommen.
Das Gesetz der großen Zahlen
Das Gesetz der großen Zahlen ist ein mathematischer Satz aus der Stochastik und besagt, dass sich die relative Häufigkeit eines Zufallsergebnisses der Wahrscheinlichkeit dieses Zufallsergebnisses annähert, wenn das zu Grunde liegende Zufallsexperiment immer wieder durchgeführt wird.
Bei einem Münzwurf beträgt die Wahrscheinlichkeit für Kopf 50 %. Dies bedeutet jedoch nicht, dass bei zehn Würfen fünf Mal Kopf fallen muss, sondern lediglich, dass die Wahrscheinlichkeit dafür recht hoch ist. Tatsächlich könnte auch acht Mal Zahl und nur zwei Mal Kopf fallen. Das Gesetz besagt lediglich, dass sich die Quote für Kopf bei hinreichend vielen Würfen 50 % annähert.
Es ist gewagt zu behaupten, dass Einzelschätzungen Zufallsergebnisse sind. Andererseits haben wir bereits gesehen, dass Sie mit sehr hoher Wahrscheinlichkeit komplett daneben liegen, wenn Sie einen Aufwand aus dem Bauch heraus schätzen, und auch dann, wenn Sie gewissenhaft schätzen, kann der tatsächliche Aufwand deutlich höher oder niedriger liegen.
Aus diesem Grund sollten Sie eine Aufgabe in Unteraufgaben unterteilen. Das setzt voraus, dass Sie sich bereits Gedanken zur Problemlösung machen, also Informationen sammeln, die Ihre Schätzung verbessert. Wichtiger dabei ist jedoch, dass die Fehler in einer Summe von Einzelschätzungen einander häufig ausgleichen. Abb. 2 zeigt die Unterteilung einer Aufgabe in neun Teilaufgaben, die separat geschätzt wurden. Die Schätzungen liegen in den meisten Fällen daneben, teilweise bis zu 80%. Einige Aufwände wurden überschätzt, andere unterschätzt, sodass die Gesamtschätzung nur um 15% abweicht. Das ist eine akzeptable Abweichung.
Abb. 2: Die Fehler in einer Summe von Einzelschätzungen gleichen einander häufig aus
Dreipunktschätzung
Alltagsschätzungen sind in der Regel Einpunktschätzungen, bei denen sich der Schätzer auf einen aus seiner Sicht wahrscheinlichen Wert festlegt. Leider neigen wir dabei unbewusst dazu, den bestmöglichen Fall zu nennen.
Besser ist daher die Dreipunktmethode, auch PERT-Schätzung genannt.
Die PERT-Schätzung ist ein einfaches und schnelles Verfahren, um an verlässliche Schätzwerte zu erlangen. Dabei ermittelt der Schätzer nicht nur einen Wert, sondern drei Werte:
- Beim optimistischen Wert (dmin) geht der Schätzer davon aus, dass alles wie am Schnürchen funktioniert und keinerlei Probleme und Verzögerungen eintreten.
- Beim normalen Wert (dnorm) wird der Normalfall geschätzt, wenn die üblichen Verzögerungen und nur kleine Probleme auftreten, die Arbeit aber mit gewohntem Tempo voran geht.
- Beim pessimistischen Wert (dmax) nimmt der Schätzer an, dass alle denkbaren Verzögerungen eintreten, ein Problem dem nächsten folgt und nichts auf Anhieb funktioniert.
Die anzusetzende mittlere Dauer dmittel wird Erwartungswert genannt und nach folgender Wahrscheinlichkeitsverteilung errechnet, der die Beta-Verteilung zugrunde liegt:
Der Erwartungswert ist so definiert, dass mit einer Wahrscheinlichkeit von 50 % der zu erwartende Aufwand unterhalb und mit ebenfalls 50 % Wahrscheinlichkeit oberhalb des Erwartungswerts liegt.
Schätzschema
Das Schätzschema kombiniert das Gesetz der großen Zahlen und die Dreipunktschätzung miteinander. Dabei handelt es sich um eine Tabelle, in der Schätzer die zu schätzenden Aufgaben – sorgfältig in möglichst viele Teilaufgaben unterteilt – und ihre Schätzwerte eintragen.
Mit Tabellenkalkulationsprogrammen wie Microsoft Excel oder OpenOffice.org Calc können Sie die PERT-Spalte über o.g. Formel befüllen lassen. Sinnvoll ist es darüber hinaus, automatisch Summen über die einzelnen Spalten zu bilden, um eine Gesamtschätzung zu erhalten.
Abb. 3 zeigt ein Schätzschema für die Aufgabe: Schreibe einen Artikel über Aufwandschätzung für die PHPUser, mindestens 4 Seiten. Es ist gut zu erkennen, dass die Aufgabe in drei Teilaufgaben unterteilt wurde, die jeweils aus weiteren Unteraufgaben bestehen, die einzeln geschätzt wurden. Das Schreiben des Artikels verursacht – wie zu erwarten war – die meisten Aufwände, aber auch für die Vorbereitung und Recherche muss viel Zeit eingeplant werden. Der Gesamtaufwand liegt mit hoher Wahrscheinlichkeit zwischen 15 und 47,5 Stunden mit dem Erwartungswert 28,75 Stunden.
Abb. 3: Schätzschema für die Aufgabe: Schreibe einen Artikel für die PHPUser
Das vorgestellte Schätzschema ist ein Werkzeug für Entwickler und soll Ihnen dabei helfen, zu besseren Aufwandschätzungen zu gelangen. Projektmanager arbeiten zumeist mit umfangreicheren Schätzschemata, die zudem die Standardabweichung berechnen, d.h. die Abweichung der Schätzungen von ihrem Erwartungswert oder mit anderen Worten: die Unsicherheit der Schätzungen. Die Schätzung aus Abb. 3 ist eine verhältnismäßig unsichere Schätzung, da die Summe aus dmax drei Mal so hoch ist wie die Summe aus dmin. Zudem enthalten professionelle Schemata zusätzliche Puffer und Wahrscheinlichkeiten, um auf Basis der Schätzungen einen realistischen Projektplan erstellen zu können. Unter Berücksichtigung der Standardabweichung würden Projektmanager bis zu 50 Stunden für die Erstellung des Artikels einplanen – abhängig von den Formeln, die zur Berechnung der Puffer angewendet werden. Die Zusammenhänge an dieser Stelle zu erklären, würde zu weit führen, aber Sie können mit Näherungen arbeiten.
Die ungefähre Standardabweichung wird nach folgender Formel berechnet.
Um die Wahrscheinlichkeit zu erhöhen, dass die tatsächlichen Aufwände geringer sind als Sie geschätzt haben, beziehen Sie die Standardabweichung in Ihr Schätzergebnis mit ein. Der zu erwartende Aufwand unterschreitet mit einer Wahrscheinlichkeit von 84 % den Wert, den Sie erhalten, wenn Sie den Erwartungswert zu der Standardabweichung addieren, und sogar 98 %, wenn Sie die Standardabweichung zwei Mal addieren.
Im oberen Beispiel beträgt die Standardabweichung näherungsweise 5,42 Stunden. Mit einer Wahrscheinlichkeit von 50 % ist der zu erwartende Aufwand kleiner als 28,75 Stunden, mit einer Wahrscheinlichkeit von 84 % kleiner als 34,17 Stunden und mit einer Wahrscheinlichkeit von 98 % kleiner als 39,58 Stunden.
Aufwandschätzung in agilen Projekten
Klassische Projektvorgehensmodelle mit schwergewichtigen, formalen Prozessen gehören heute weitgehend der Vergangenheit an. Viele Projektmanager setzen heute auf agile Verfahren. Die Motivation agiler Methoden wird bereits durch die Namenswahl verdeutlicht: Agil bedeutet flink oder beweglich und bezieht sich darauf, schnell auf geänderte Rahmenbedingungen zu reagieren. Agile Vorgehensmodelle lösen sich vom klassischen Wasserfall-Modell mit dessen einzelnen Phasen und Variationen und setzen stattdessen auf eine enge Zusammenarbeit mit dem Auftraggeber, wenig bürokratischen Aufwand und Teamarbeit.
Das derzeit populärste agile Vorgehensmodell ist Scrum. Der Begriff beschreibt ursprünglich einen Spielzug im Rugby: das Gedränge der Spieler beim Einwurf des Spielballs während des Spiels – sinnbildlich für die Nähe und »Reibereien« zwischen Kunden und Projektteam.
Scrum ist ein Gesamtsystem aus Meetings, Artefakten, Rollen und Werten, das aufbauend auf den Rahmengrundsätzen der agilen Softwareentwicklung ein Prozessmodell für die Abwicklung von Projekten darstellt. Dabei setzt Scrum sehr stark auf die Selbstorganisation und Verantwortung des Teams. Ein Projektmanager im klassischen Sinne mit umfangreicher Autorität existiert nicht. Vielmehr gibt es neben dem Team und dem Kunden (repräsentiert durch die Rolle des Product Owners) den so genannten Scrum Master, dessen Aufgabe es ist, die Werte und Regeln von Scrum während des Projekts zu wahren und Hindernisse zu beseitigen.
Auch in Scrum befasst sich das Entwicklerteam zu Beginn des Projekts damit, die Aufgaben zu sammeln. Sie werden durch den Product Owner priorisiert und anschließend im so genannten Product Backlog eingetragen, einer Sammlung aller Aufgaben, die laufend während des gesamten Projekts aktualisiert wird. Wenn alle Aufgaben bekannt und in das Product Backlog aufgenommen sind, dann beginnt die erste Schätzklausur.
Schätzklausuren
Schätzklausuren finden in Scrum regelmäßig während des gesamten Projektverlaufs statt. Die erste Schätzklausur dient dazu, die Gesamtaufwände des Projekts grob abzuschätzen. Der Ablauf ist dabei wie folgt: Der Product Owner erklärt alle Anforderungen, bis das Team sie vollständig verstanden hat. Anschließend schätzt das Team die Aufwände. Der Scrum-Master moderiert die Klausur und stellt sicher, dass sie regelkonform abläuft und pünktlich endet. Sind alle Einträge abgeschätzt oder ist die Zeit abgelaufen, so endet die Klausur.
Schätzklausuren sollten höchstens zwei Stunden dauern, da nach dieser Zeit die Konzentration des Teams nachlässt und die Schätzgüte spürbar abnimmt.
Alle Teammitglieder müssen sich darüber verständigen, wie viel Aufwand mit der Umsetzung verbunden ist. Dazu muss das Team alle wesentlichen Arbeitsschritte berücksichtigen, also Design, Programmierung, Integration, Test und Dokumentation. Dahinter steht nichts anderes als die bereits bekannte Aufteilung von Aufgaben in überschaubare Teilaufgaben und somit das Gesetz der großen Zahlen. Als Schätzverfahren kann die Dreipunktschätzung dienen, allerdings ist ein anderes Verfahren geeigneter, um rasch einvernehmliche Teamschätzwerte zu erhalten: Das Team spielt Planungspoker; ein Schätzverfahren, das mit dem klassischen Pokerspiel mit Ausnahme der Tatsache, dass Karten zum Einsatz kommen, nicht viel zu tun hat.
Planungspoker
Zunächst erhält jedes Teammitglied einen Stapel Karten. Jede Karte hat auf ihrer Vorderseite eine Zahl aus einer ausgewählten Punktereihe. Die Punktewertefolge ist in Scrum nicht vorgeschrieben, gut eignen sich allerdings Zahlenreihen, die eine adäquate Auswahl an Aufwandsgrößen bieten, die sich deutlich genug voneinander unterscheiden. Eine geeignete Wertefolge ist die Fibonacci-Folge, bei der sich die jeweils folgende Zahl durch Addition der beiden vorherigen Zahlen ergibt, wobei jedem Punkt folgende Bedeutung zugeordnet wird:
| Punktewert | Bedeutung |
|---|---|
| 0 | Kein Aufwand |
| 1 | Sehr kleiner Aufwand |
| 2 | Kleiner Aufwand |
| 3 | Mittlerer Aufwand |
| 5 | Großer Aufwand |
| 8 | Sehr großer Aufwand |
| 13 | Riesiger Aufwand |
Die Punktewerte stehen zueinander in Beziehung, d.h. ein kleiner Aufwand ist doppelt so groß wie ein sehr kleiner Aufwand; ein sehr großer Aufwand so groß wie ein mittlerer und großer Aufwand zusammen.
Sobald der Product Owner die Aufgabe vorgestellt und das Team etwaige Unklarheiten beseitigt hat, wählt jedes Teammitglied die Karten aus, die aus seiner Sicht den Aufwand der Aufgabe repräsentiert und legt die Karte verdeckt auf den Tisch. Sobald alle Karten auf dem Tisch liegen, drehen alle Teammitglieder gleichzeitig ihre Karte um.
In den meisten Fällen haben verschiedenen Teammitglieder unterschiedliche Zahlen aufgedeckt, vor allem in den ersten Schätzklausuren oder bei unklaren Aufgabenstellungen. Wenn also kein Konsens vorliegt, so erklären die beiden Teammitglieder, deren Schätzwerte sich am meisten unterscheiden, wie sie zu ihrem Wert gekommen sind.
Das ist übrigens nichts Ungewöhnliches, ganz im Gegenteil: Unterschiedliche Experten kommen häufig zu verschiedenen Ergebnissen. Der CSS-Purist schätzt den Aufbau des grundlegenden Spaltenlayouts auf 8, weil er ein eigenes auf das Projekt angepasste Layout-Modul schreiben möchte; der CSS-Pragmatiker setzt auf ein Framework wie YAML, kann also schon auf vorgefertigte Bausteine zurück greifen und schätzt den Aufwand daher nur auf 3. Das ist normal und gewünscht. Die restlichen Teammitglieder verfolgen die Diskussion und können ihre Entscheidung überdenken. Anschließend geht das Planungspokerspiel in die nächste Runde: Erneut wählen alle Mitglieder eine Karte, legen sie auf den Tisch und drehen sie gleichzeitig um. Das Ganze geht so lange, bis alle Schätzungen übereinstimmen, d.h. jedes Teammitglied die gleiche Karte aufgedeckt hat.
Es ist hilfreich, neue Anforderungen mit bereits existierenden Schätzungen zu vergleichen, um einen Maßstab zu erhalten und dadurch sicherzustellen, dass die Schätzwerte zueinander relativ korrekt sind. Dabei ist es sinnvoll, gleich große Anforderungen während des Abschätzens zu gruppieren und regelmäßig zu überprüfen, ob die Gruppen in sich konsistent sind.
Bereits nach wenigen Planungspokerspielen sind Teams aufeinander abgestimmt und verstehen unter verschiedenen Aufwänden dasselbe; innerhalb von zwei Minuten oder weniger kommt das Team zu einem einstimmigen Ergebnis.
Ermittlung der Entwicklungsgeschwindigkeit
In Scrum werden Projekte in Iterationen von zwei bis vier Wochen durchgeführt, die Sprints genannt werden. Zu Beginn jedes Sprints findet ein Sprintplanungsmeeting statt, in dem das Team Aufgaben aus dem (priorisierten) Product Backlog für den Sprint auswählt und in das Sprint Backlog überführt, die Aufgabenliste für den folgenden Sprint. Die Aufwandschätzungen für diese Aufgaben werden noch einmal überprüft und gegebenenfalls korrigiert.
Wenn die Aufgaben nach der Dreipunktschätzung geschätzt wurden, kann das Team ermitteln, wie viele Stunden ihm im Laufe des Sprints real zur Verfügung stehen und entsprechend viele Aufgaben in den Sprint aufnehmen. Wurde hingegen Planungspoker gespielt, muss anders vorgegangen und die Entwicklungsgeschwindigkeit (engl. velocity) des Teams ermittelt werden.
Die Entwicklungsgeschwindigkeit ist die Summe aller Aufwände der am Ende eines Sprints vom Product Owner abgenommenen Arbeitsergebnisse.
Je mehr Sprints das Team hinter sich gebracht hat, desto genauere Aussagen zur Entwicklungsgeschwindigkeit sind möglich. Angenommen, das Team verpflichtet sich im ersten Sprint, Aufgaben im »Wert« von 25 Punkten zu erledigen, schafft aber nur 16. Im nächsten Sprint nimmt sich das Team Aufgaben für 20 Punkte vor und schafft tatsächlich 22. Diese sind Basis für den dritten Sprint, in dem die 22 Punkte erreicht werden, ebenso im vierten Sprint. Nun kann diese Entwicklungsgeschwindigkeit im Projektplan angenommen werden.
Das ist übrigens nicht ungewöhnlich, dass Teams im ersten Sprint nur etwa 60% ihrer tatsächlichen Leistungsfähigkeit erreichen. Zumeist dauert es drei bis vier Sprints, bis das Team sich eingespielt hat und im Projekt »angekommen« ist.
Fazit
Schätzen ist eine verantwortungsvolle und anspruchsvolle Aufgabe. Wenn sich der Schätzer verschätzt, kann das verheerende Folgen nach sich ziehen. Es ist daher unbedingt erforderlich, die Aufwandschätzung so realistisch wie möglich zu halten. Dazu ist es notwendig, das zu erreichende Ziel und die Voraussetzungen klar zu definieren, von denen der Schätzer ausgehen kann. Je klarer die Voraussetzungen sind und je genauer die Anforderungen, desto besser kann eine Schätzung sein.
Eine Schätzung ist sehr gut, wenn der tatsächliche Wert vom Nominalwert nicht mehr als 10 % abweicht. Ein Schätzverfahren ist gut, wenn die Abweichungen in 75 % der Fälle unter 25 % liegen.
Jede Aufwandschätzung ist nur ein grober Anhaltspunkt. Auch wenn der Schätzer in dem, was er schätzen muss, sehr erfahren ist und zum Zeitpunkt der Schätzung ausreichend viele Informationen zur Verfügung stehen, müssen Schätzungen zur Erstellung eines Projektplans und somit auch der Projektplan selbst regelmäßig aktualisiert werden. Agile Projektvorgehensmodelle wie Scrum sind dafür ausgelegt, dynamisch auf sich ändernde Projektanforderungen zu reagieren.
Gegen die von Dir angesprochene Schätzungenauigkeit gibt es weitere Methoden, diese zu minimieren. Als Stichworte dazu: Monte-Carlo, Bottom-Up, Top-Down, Ballpark-Estimation, Function-Point Methode etc. Im täglichen Projekteinsatz mit meinem Team wende ich einige dieser Methoden zur Absicherung von Aufwandsschätzungen häufig an.
Gegen versteckte Kosten und Aufwände helfen generelle Aufschläge für QS, PM oder Bugfixing (abhängig von der Zahl der zu erwartenden Defects).
Pingback: Bithalter 035′10 | Webzeugkoffer Webdesign