Mike Cohn: Agile Estimating and Planning

You are currently viewing Mike Cohn: Agile Estimating and Planning

Mike Cohn
Vorwörter: Robert C. Martin, Jim Highsmith, Gabrielle Benefield
Agile Estimating and Planning

12. Druck (Mai 2012)
2006, XXX, 330 Seiten, Broschur
Prentice Hall Professional Technical Reference
ISBN: 0-13-147941-5



Mike Cohns zweites Buch zum Thema Agilität behandelt die Themen Schätzung und Planung in einem agilen Umfeld. Wer schon eine gewisse Erfahrung mit agilen Methodologien hat, dürfte jedoch vermutlich Agile Estimating and Planning nicht mehr so viel abgewinnen können.


Inhalt und Struktur

Teil 1: The Problem and the Goal

Planung ist eine schwierige Angelegenheit und Schätzungen sind oft mit viel Unsicherheit verbunden. Schätzungen werden umso sicherer, je näher ein Projekt seiner Fertigstellung naht, wie es der auf Seite 4 vorgestellte Cone of Uncertainty illustriert. Das Konzept des „Cone of Uncertainty“ wurde von Barry Boehm für den Softwarebereich verwendet, ist allerdings schon älter (der Name wurde von Steve McConnel geprägt). Die größte Unsicherheit entsteht jedoch dadurch, dass man oft nicht weiß, ob man überhaupt dabei ist, das richtige Produkt zu entwickeln (S. 6). Entsprechend geht es bei der Planung darum Unsicherheiten und Risiken zu minimieren – der Akt der Planung ist dabei wichtiger als der Plan selbst (S. 10) – der Plan selbst wird ja ständig angepasst.

Im zweiten Kapitel identifiziert Cohn diverse Probleme einer „traditionellen“ (also nicht-agilen) Planung:

  • Aufgaben – im Gegensatz zu Features – werden geplant;
  • Die Kosten des Multitaskings werden nicht berücksichtigt;
  • Es geschieht keine „richtige“ – also wert-basierte – Priorisierung;
  • Fälschlicherweise wird davon ausgegangen, dass durch den Plan schon die Unsicherheit eliminiert wurde;
  • Es wird nicht zwischen Schätzung und Zusage unterschieden.

Agile Prozesse (Cohn meint damit wohl in erster Linie Scrum, da gewöhnlich von einem „Product Owner“, der die Priorisierung durchführt, die Rede ist) könnten die vorher präsentierten Probleme lösen. Dies geschieht

  • durch eine Priorisierung der Aufgaben (unter Verwendung von User Stories),
  • durch eine dreistufige Planung:
    1. Plan bis zur Freigabe (für den Fall, dass eine Iteration nicht genügend Mehrwert für einen Kunden bietet, wird der Begriff „Release“ eingeführt, der die Ergebnisse mehrerer Iterationen bündelt),
    2. Planung der Iteration und
    3. die tägliche Planung
  • und durch den „Inspect-and-Adapt“-Zyklus, der durch die Iterationen vorgegeben ist.

Teil 2: Estimating Size

Nachdem das Problem erläutert wurde und die Vorteile einer agilen Vorgehensweise beschrieben wurden, widmet sich Cohn Möglichkeiten um die Arbeitspakete (Stories, Epics und Themes) zu schätzen. Der Autor stellt zwei Möglichkeiten dafür vor: „Story Points“ und „Ideale Tage“. Beide haben jeweils ihre Vor- und Nachteile, wobei Cohn ganz klar die Story Points den Idealen Tagen vorzieht (S. 73).

Schätzmethoden wie Expertenmeinung, Analogie oder Disaggregation stellt der Autor im sechsten Kapitel vor. Cohn empfiehlt das sogenannte Planning Poker als gute Möglichkeit Schätzungen im Team durchzuführen.

Teil 3: Planning for Value

„Planning for Value“ bedeutet, den höchstmöglichen Wert in der vorhandenen Zeit zu liefern. Daraus folgt: die Priorisierung der Aufgaben ist wichtig. Cohn stellt vier Kriterien dafür vor (behandelt im Kapitel 9), anhand derer die Priorisierung durchgeführt werden kann (vgl. S. 80ff – Reihenfolge, wie im Buch):

  • Der finanzielle Wert eines fertiggestellten Features
  • Die Kosten des Features (Implementierung und Wartung)
  • Durch die Implementierung des Features gewonnenes Wissen
  • Risiken, die durch die Implementierung eines Features eventuell eliminiert werden.

Selbstverständlich sind durch die Implementierung von Features erwartete Gewinne oder eliminierte Kosten ebenfalls ein wichtiger Aspekt, diesem widmet sich das zehnte Kapitel.

Im elften Kapitel geht Cohn auf Möglichkeiten die Erwünschtheit („desirability“) von Features zu ermitteln, d.h. wie wichtig ist den Nutzern ein gewisses Feature, kann es z.B. ignoriert werden, ohne dass der Wert des Produktes als Ganzes leidet, ist es eher ein „must-have“ oder vielleicht gar etwas Unerwartetes, das zwar nicht notwendig ist, aber den Wert des Produktes steigert. Als Tools zur Bewertung der Erwünschtheit, stellt Cohn zwei Verfahren vor:

  • Noriaki Kanos sog. Kano-Modell, das Features in Basismerkmale, Leistungsmerkmale, Begeisterungsmerkmale, unerhebliche Merkmale und Rückweisungsmerkmale unterteilt und
  • Karl Wiegers‘ „Relative Weighting“-Methode, die einerseits den Wert des Vorhandenseins eines Features und die Nachteile des Fehlens desselben betrachtet (vgl. S. 117ff).

Kapitel 11 behandelt Gründe und Möglichkeiten, um Stories aufzuteilen.

Teil 4: Scheduling

Der vierte Teil des Buches geht auf die konkrete Planung von Releases und Iterationen ein. Es geht um die Wahl der zu implementierenden User Stories, über Prioritäten, Velocity (deren Schätzung wird das gesamte sechzehnte Kapitel gewidmet), der Wahl der geeigneten Iterationslänge (Kapitel 15) und Einigem mehr.

Cohn stellt im siebzehnten Kapitel fest, dass in manchen Situationen die Unsicherheit und die Risken durch das Vorsehen von Zeitpuffern minimiert werden können. Er unterscheidet Puffer auf Feature- und auf Zeitplanebene.

Im letzten Kapitel des vierten Teils geht der Autor auf einen sehr wichtigen Aspekt ein: das Planen mehrerer Teams. Unter anderem stellt Cohn fest, dass eine vorausschauendere Planung (vgl. S. 206ff) in diesem Fall hilfreich sein kann.

Teil 5: Tracking and Communicating

Im fünften Teil hält Cohn fest, dass die Pläne (auf Iterations- und Releaseebene) und die Velocity ständig überwacht werden müssen. Burndown Charts sind dabei ein wichtiges Instrument, um sowohl den Fortschritt zu kontrollieren als auch diesen zu kommunizieren.

Teile 6 und 7

Der sechste sehr kurze Teil, betitelt Why Agile Planning Works ist eine Zusammenfassung der vorherigen Kapiteln, während der siebte und letzte Teil (betitelt A Case Study) anhand eines umfangreichen – über 50 Seiten – fiktiven Beispiels agile Planung und Schätzung demonstriert.

Diskussion

Anforderungserhebung und Planung sind zwei eng verbundene Aufgaben, somit verwundert es wenig, dass zwischen Cohns Bücher User Stories Applied (erschienen 2004) und Agile Estimating and Planning (erschienen 2005, Copyright-Jahr 2006) eine gewisse Überschneidung existiert. So behandelt Cohn im zweiten Teil von User Stories Applied (betitelt Estimating and Planning) schon Themen wie:

  • Ermittlung und Verwendung der Velocity,
  • Planung einer Iteration und einer Freigabe (Release),
  • Burndown Charts und
  • das Schätzen mittels Story Points.

Selbstverständlich enthält Agile Estimating and Planning auch die eine oder andere Information über User Stories.

Da die zwei Themen so stark miteinander verbunden sind, stellt sich die Frage, ob ein einziges Buch, welches sowohl Planung als auch Schätzverfahren und Anforderungserhebung (mittels User Stories) behandelt, nicht besser wäre als zwei Bücher, die sich thematisch überschneiden und Redundanzen beinhalten. Selbstverständlich lautet die Antwort: ja. Einschränkend möchte ich aber hinzufügen: aus heutiger Sicht. Vielleicht war es 2004 noch nicht klar, dass Bedarf nach einer umfangreicheren Behandlung des Themas Planung und Schätzung bestand – Kent Becks und Martin Fowlers Planning Extreme Programming war ja auch schon seit 2000 auf dem Markt. Vielleicht hätte die Fertigstellung eines umfassenderen Werks zu viel Zeit in Anspruch genommen und das Thema wurde (im agilen Sinne) aufgeteilt. Letztendlich sind diese Überlegungen jedoch unerheblich, der interessierte Leser sei jedoch ob dieser Redundanzen gewarnt.

Mike Cohns Schreibstil empfinde ich generell als angenehm, Agile Estimating and Planning ist da keine Ausnahme. Der Text enthält viele Beispiele und ist sehr leicht lesbar – allerdings: zu leicht lesbar. Jedes Kapitel (bis auf das Letzte) wird am Ende desselben kurz zusammengefasst. In den meisten Fällen hatte ich das Gefühl, dass ich nichts verpasst hätte, wenn ich lediglich diese Zusammenfassungen durchgelesen hätte.

Das letzte Kapitel, ein fiktives Projekt, welches das vorher Beschriebene veranschaulichen soll, ist auch wenig hilfreich und viel zu umfangreich (über 50 Seiten). Vielleicht kann ich mich zu schlecht in die damalige Zeit versetzen – es sind immerhin über 15 Jahre seit der Veröffentlichung vergangen und damals war Agilität noch gewissermaßen neu – das Buch scheint mir jedoch ein eher unerfahrenes Publikum anzusprechen.

Wer schon eine gewisse Erfahrung mit agiler Softwareentwicklung hat, dürfte vermutlich Agile Estimating and Planning nicht mehr so viel abgewinnen können.


Zum Autor

Informationen über Mike Cohn finden Sie auf der separaten Buchautorenseite.


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Nachdem er sein Bachelorstudium im Fach Psychologie abschloss, orientierte er sich neu und studierte Software Engineering an der Hochschule Heilbronn, ebenfalls mit einem Bachelor abgeschlossen. Anschließend war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Aktuell ist er mit dem Masterstudium der Praktischen Informatik und der Rezensionsplattform für IT-Fachbücher nososo.de beschäftigt.

Schreibe einen Kommentar