ESE Fachwissen
Man kann nicht nicht planen
Autor: Markus Unterauer, Software Quality Lab GmbH
Beitrag - Embedded Software Engineering Kongress 2015
Agil wird vielfach als "ohne Planung" oder "einfach drauflos" interpretiert und gelebt. In Wirklichkeit ist das Gegenteil der Fall. In agilen Projekten wird auf mehreren Ebenen vom Produkt über Releases und Iterationen bis zu den durchzuführenden Aufgaben in einer Iteration sehr strukturiert und sorgfältig geplant. Grundlagen sind dabei eine rollierende Planung, welche umso genauer wird, je näher die Umsetzung rückt, und die permanente Anpassung der Pläne mit dem Feedback aus den Iterationen.
Zu Beginn eines Softwareprojektes oder einer Produktentwicklung weiß man noch sehr wenig. Stakeholder und Team haben eine grobe Vorstellung davon, was die Software können muss und wie sie aussehen soll. Erst im Laufe des Projektes lernen alle gemeinsam, was im Detail benötigt wird und wie die besten Lösungen dafür aussehen. Selbst in der Systementwicklung, bei der die Anforderungen an das System, die Hardware, Mechanik und Elektronik schon sehr genau definiert sind, sind die Anforderungen und das genaue Aussehen und Verhalten der Software oft zu Beginn nur vage spezifiziert.
Agile Methoden tragen dieser Tatsache Rechnung und akzeptieren, dass man zu Beginn nicht alles weiß und daher auch nicht alles genauestens planen kann. Eine der wichtigsten Grundlagen agiler Methoden sind daher schnelle Lernzyklen (siehe Abb. 1, PDF). In kurzen Iterationen wird geplant, umgesetzt, getestet und basierend auf dem Feedback der Kunden und Anwender angepasst. Dieses Prinzip wird auch in agiler Planung konsequent weiterverfolgt.
Um keinen Aufwand für die Detailplanung von Funktionen zu verschwenden, die dann anders oder gar nicht umgesetzt werden, werden nur die Dinge, die in den nächsten Iterationen anstehen, genau geplant. Weiter in der Zukunft liegende Funktionen werden lediglich grob abgesteckt (siehe Abb. 2, PDF). Die Planung wird rollierend am Beginn jeder Iteration angepasst, und die nächsten anstehenden Softwareteile werden genauer spezifiziert.
Die 5 Stufen agiler Planung
In agilen Projekten wird auf 5 Stufen geplant (siehe Abb. 3, PDF) [1][2]:
- Product Vision: Im Vision Statement wird das gemeinsame Bild des neuen Produktes beschrieben. Die Vision beschreibt die groben Ziele des Projektes und dient als Orientierung für alle Beteiligten, wo die Reise hingeht. Sie darf durchaus motivierend geschrieben sein, soll sie doch erklären, warum das Produkt notwendig ist, wie es sich von bestehenden Produkten abhebt, was es dem Anwender bringt und wie es die Welt besser macht.
- Product Roadmap: In einer Roadmap wird dargestellt, wann (in welchen Releases) die wesentlichen Kernfunktionen des Produktes fertiggestellt werden. Sie dient als erste Orientierung für das Team und die Stakeholder, wie das Umsetzungsprojekt ablaufen wird. Die Product Roadmap beinhaltet dabei nur sehr grobe Themen und Funktionen und fokussiert auf die Kundensicht.
- Release Planning: In der Release Planung wird das nächste Release genauer geplant. Ein Release dauert in agilen Projekten zwischen 1-6 Monaten. In einem gemeinsamen Workshop aller Projektteams werden die Ziele und umzusetzenden Funktionen festgelegt und eine erste grobe Iterationsplanung durchgeführt. Diese dient als Basis für das laufende Controlling während der Umsetzung.
- Iteration Planning: Eine Iteration dauert in agilen Projekten zwischen 1-4 Wochen. Die Iterationsplanung besteht aus zwei Teilen: Im ersten Teil wird festgelegt, welche Anforderungen das Team in der Iteration fertigstellen kann. Fertig bedeutet dabei, umgesetzt, dokumentiert, getestet und abgenommen. Im zweiten Schritt wird geplant, welche Tätigkeiten (Tasks) durchgeführt werden müssen, um die geplanten Anforderungen fertigzustellen. Das Ergebnis ist ein gefülltes Iterationsbacklog und ein Taskboard mit den zu erledigenden Aufgaben.
- Daily Stand-Up: Täglich trifft sich das Team zu einem kurzen Planungs- und Abstimmungsmeeting. Gemeinsam wird durchgegangen, wer welche Aufgaben fertigstellen wird und welche Hindernisse es dabei gibt.
Artefakte für die Planung
Je nach Planungsebene werden unterschiedliche Artefakte geplant (siehe Abb. 3, PDF) [1]:
Auf der obersten Stufe, der Produktvision, gibt es lediglich ein Vision Statement. Dieses ist meist ein recht kurzes Dokument, in dem auf maximal einer A4-Seite das große Bild gezeichnet wird.
Die Produkt-Roadmap beinhaltet meist nur auf Überschriftenebene die wesentlichen Features des neuen Produktes in einer ungefähren zeitlichen Ordnung. Die Features werden dabei stark aus Markt- bzw. Kundensicht beschrieben. In der agilen Welt werden hier oft auch schon Epics definiert. Das sind ebenfalls größere Funktionsblöcke oder Themen, die aber innerhalb eines Release umgesetzt werden können.
In der Release-Planung werden die Features oder Epics in kleinere Teile, die Stories, heruntergebrochen. Diese beschreiben für den Anwender sinnvolle Funktionen oder Funktionsbausteine, die innerhalb einer Iteration fertiggestellt werden können.
Innerhalb einer Iteration werden die Tätigkeiten, die zur Umsetzung der Stories notwendig sind, geplant. Dafür werden Task-Items angelegt. Diese Arbeitspakete sollten vom Aufwand her nicht größer als ein Personentag sein.
Aufwandsschätzung
Auch in agilen Projekten basiert die Planung auf Schätzungen. Je nach Ebene der Planung kommen dabei unterschiedliche Schätzverfahren zum Einsatz (siehe Abb. 4, PDF). Je genauer die Planelemente spezifiziert sind, desto genauer und feiner auch die Planung.
Für die Roadmap-Planung werden in vielen Projekten die einzelnen Funktionen (Features) und groben Themen (Epics) in T-Shirt-Sizes geschätzt (XS, S, M, L, XL, XXL). Jede Größe entspricht dabei einem Aufwandsbereich, z.B.:
- XS.......... < 5 PT
- S............. 5 – 10 PT
- M............ 10 – 50 PT
- L............. 50 – 100 PT
- XL.......... 100 – 200 PT
- XXL ...... > 200 PT
Die Schätzung erfolgt durch die Umsetzungsteams nach einer kurzen Vorstellung der Funktion bzw. des Themas durch den Produktmanager.
Die Stories für die Release- und Iterationsplanung werden oft in Story Points geschätzt. Dies ist eine fiktive Einheit, die die Komplexität einer Story im Vergleicht zu anderen Stories beschriebt. Eine Story mit doppelt so vielen Story Points ist entsprechend doppelt so komplex. Über die Velocity, das ist die Anzahl der Story Points, die ein Team im Schnitt pro Iteration fertigstellen kann, kann dann eine Kapazitätsplanung durchgeführt werden.
Innerhalb einer Iteration werden die Arbeitspakete (Tasks) zur Umsetzung der Stories in Personentagen oder Personenstunden geschätzt.
Laufendes Controlling und Anpassung
Basierend auf der aktuellen Release und Iterationsplanung wird am Ende jeder Iteration ein Plan-/Ist-Vergleich durchgeführt. Je nach Abweichungen wird dann die aktuelle Planung angepasst. Hierfür werden in vielen agilen Projekten Burnup-Charts verwendet, die eine Prognose des weiteren Projektverlaufs in verschiedenen Szenarien ermöglichen (siehe Abbildung 5, PDF).
Lessons Learned für die agile Planung
Die folgenden Tipps helfen, in Softwareprojekten auf Kurs zu bleiben. Sie gelten für agile Projekte ebenso wie für klassisch plangetriebene:
- Wenn ins Projekt etwas reinkommt, muss etwas anderes raus.
Bei gleichbleibenden Ressourcen ist diese Erkenntnis eigentlich trivial. Wenn sich der Auftraggeber eine neue, zusätzliche Funktion wünscht und gleichzeitig weder die Zahl der Mitarbeiter erhöht noch der Release-Zeitpunkt verschoben werden, so bleibt nur, eine bisher geplante Funktion gleicher Größe zu streichen bzw. Funktionen abzuspecken. Dies muss auf allen Planstufen berücksichtigt werden.
- Schätzungen niemals nach unten handeln.
Die oft zu findende Meinung, dass Softwareentwickler generell mit zu viel Puffer schätzen, bestätigt sich in der Praxis nicht. In der Regel unterschätzen sie den Aufwand. Dabei sind die Folgekosten einer zu niedrigen Schätzung deutlich höher als die Nachteile durch zu hohes Schätzen. Es sollte daher generell niemals die Aufwandsschätzung in Frage gestellt werden, sondern bei zu hohen Werten über eine Reduktion des Umfangs bzw. andere technische Ansätze gesprochen werden.
- Nebentätigkeiten bei der Kapazitätsplanung bedenken.
Neben der eigentlichen Programmierarbeit haben agile Teams noch eine ganze Reihe weiterer Aufgaben zu erfüllen: Unterstützen des Product Owners bei der Spezifikation der Stories, Meetings, Bugfixing usw. All das muss bei der Kapazitätsplanung berücksichtigt werden. Im Schnitt haben agile Teams etwa 34% ihrer Zeit für die tatsächliche Programmierung neuer Funktionen zur Verfügung (siehe Abb. 6, PDF).
Zusammenfassung
Grundlage agiler Planung ist permanentes Lernen und flexibles Eingehen auf Änderungen. In 5 Planstufen werden die Planelemente schrittweise verfeinert. Je näher die Umsetzung rückt, desto genauer wird geplant. Laufende Plan-/Ist-Vergleiche verhindern ein Überrascht-Werden durch Abweichungen am Ende des Projektes.
Literatur und Quellen
[1] Ponomareff, "The 5 Levels of Planning", www.slideshare.com, 01.10.2015
[2] Bergsmann, "Requirements Engineering für die agile Softwareentwicklung", dpunkt.verlag, 2014
[3] Brokenbuild, "Release Burnup Plugin for JIRA" , 01.10.2015
Agil & Scrum - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Agil & Scrum - Fachwissen
Wertvolles Fachwissen zum Thema Agil & Scrum steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.