Autor: Markus Unterauer, Software Quality Lab GmbH<\/p>\n
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 \u00fcber Releases und Iterationen bis zu den durchzuf\u00fchrenden Aufgaben in einer Iteration sehr strukturiert und sorgf\u00e4ltig geplant. Grundlagen sind dabei eine rollierende Planung, welche umso genauer wird, je n\u00e4her die Umsetzung r\u00fcckt, und die permanente Anpassung der Pl\u00e4ne mit dem Feedback aus den Iterationen.<\/strong><\/p>\n Zu Beginn eines Softwareprojektes oder einer Produktentwicklung wei\u00df man noch sehr wenig. Stakeholder und Team haben eine grobe Vorstellung davon, was die Software k\u00f6nnen muss und wie sie aussehen soll. Erst im Laufe des Projektes lernen alle gemeinsam, was im Detail ben\u00f6tigt wird und wie die besten L\u00f6sungen daf\u00fcr 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.<\/p>\n Agile Methoden tragen dieser Tatsache Rechnung und akzeptieren, dass man zu Beginn nicht alles wei\u00df und daher auch nicht alles genauestens planen kann. Eine der wichtigsten Grundlagen agiler Methoden sind daher schnelle Lernzyklen (siehe Abb. 1,\u00a0PDF<\/a>). 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.<\/p>\n Um keinen Aufwand f\u00fcr die Detailplanung von Funktionen zu verschwenden, die dann anders oder gar nicht umgesetzt werden, werden nur die Dinge, die in den n\u00e4chsten Iterationen anstehen, genau geplant. Weiter in der Zukunft liegende Funktionen werden lediglich grob abgesteckt (siehe Abb. 2,\u00a0PDF<\/a>). Die Planung wird rollierend am Beginn jeder Iteration angepasst, und die n\u00e4chsten anstehenden Softwareteile werden genauer spezifiziert.<\/p>\n In agilen Projekten wird auf 5 Stufen geplant (siehe Abb. 3,\u00a0PDF<\/a>) [1][2]:<\/p>\n Je nach Planungsebene werden unterschiedliche Artefakte geplant (siehe Abb. 3,\u00a0PDF<\/a>) [1]:<\/p>\n 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\u00dfe Bild gezeichnet wird.<\/p>\n Die Produkt-Roadmap beinhaltet meist nur auf \u00dcberschriftenebene die wesentlichen Features des neuen Produktes in einer ungef\u00e4hren 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\u00f6\u00dfere Funktionsbl\u00f6cke oder Themen, die aber innerhalb eines Release umgesetzt werden k\u00f6nnen.<\/p>\n In der Release-Planung werden die Features oder Epics in kleinere Teile, die Stories, heruntergebrochen. Diese beschreiben f\u00fcr den Anwender sinnvolle Funktionen oder Funktionsbausteine, die innerhalb einer Iteration fertiggestellt werden k\u00f6nnen.<\/p>\n Innerhalb einer Iteration werden die T\u00e4tigkeiten, die zur Umsetzung der Stories notwendig sind, geplant. Daf\u00fcr werden Task-Items angelegt. Diese Arbeitspakete sollten vom Aufwand her nicht gr\u00f6\u00dfer als ein Personentag sein.<\/p>\n Auch in agilen Projekten basiert die Planung auf Sch\u00e4tzungen. Je nach Ebene der Planung kommen dabei unterschiedliche Sch\u00e4tzverfahren zum Einsatz (siehe Abb. 4,\u00a0PDF<\/a>). Je genauer die Planelemente spezifiziert sind, desto genauer und feiner auch die Planung.<\/p>\n F\u00fcr die Roadmap-Planung werden in vielen Projekten die einzelnen Funktionen (Features) und groben Themen (Epics) in T-Shirt-Sizes gesch\u00e4tzt (XS, S, M, L, XL, XXL). Jede Gr\u00f6\u00dfe entspricht dabei einem Aufwandsbereich, z.B.:<\/p>\n Die Sch\u00e4tzung erfolgt durch die Umsetzungsteams nach einer kurzen Vorstellung der Funktion bzw. des Themas durch den Produktmanager.<\/p>\n Die Stories f\u00fcr die Release- und Iterationsplanung werden oft in Story Points gesch\u00e4tzt. Dies ist eine fiktive Einheit, die die Komplexit\u00e4t einer Story im Vergleicht zu anderen Stories beschriebt. Eine Story mit doppelt so vielen Story Points ist entsprechend doppelt so komplex. \u00dcber die Velocity, das ist die Anzahl der Story Points, die ein Team im Schnitt pro Iteration fertigstellen kann, kann dann eine Kapazit\u00e4tsplanung durchgef\u00fchrt werden.<\/p>\n Innerhalb einer Iteration werden die Arbeitspakete (Tasks) zur Umsetzung der Stories in Personentagen oder Personenstunden gesch\u00e4tzt.<\/p>\n Basierend auf der aktuellen Release und Iterationsplanung wird am Ende jeder Iteration ein Plan-\/Ist-Vergleich durchgef\u00fchrt. Je nach Abweichungen wird dann die aktuelle Planung angepasst. Hierf\u00fcr werden in vielen agilen Projekten Burnup-Charts verwendet, die eine Prognose des weiteren Projektverlaufs in verschiedenen Szenarien erm\u00f6glichen (siehe Abbildung 5,\u00a0PDF<\/a>).<\/p>\n Die folgenden Tipps helfen, in Softwareprojekten auf Kurs zu bleiben. Sie gelten f\u00fcr agile Projekte ebenso wie f\u00fcr klassisch plangetriebene:<\/p>\n Grundlage agiler Planung ist permanentes Lernen und flexibles Eingehen auf \u00c4nderungen. In 5 Planstufen werden die Planelemente schrittweise verfeinert. Je n\u00e4her die Umsetzung r\u00fcckt, desto genauer wird geplant. Laufende Plan-\/Ist-Vergleiche verhindern ein \u00dcberrascht-Werden durch Abweichungen am Ende des Projektes.<\/p>\n [1] Ponomareff, „The 5 Levels of Planning“,\u00a0www.slideshare.com<\/a>, 01.10.2015<\/p>\n [2] Bergsmann, „Requirements Engineering f\u00fcr die agile Softwareentwicklung“, dpunkt.verlag, 2014<\/p>\n [3] Brokenbuild, „Release Burnup Plugin for JIRA<\/a>“ , 01.10.2015<\/p>\n Beitrag als PDF downloaden<\/a> Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Agil & Scrum steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nDie 5 Stufen agiler Planung<\/h2>\n
\n
Artefakte f\u00fcr die Planung<\/h2>\n
Aufwandssch\u00e4tzung<\/h2>\n
\n
Laufendes Controlling und Anpassung<\/h2>\n
Lessons Learned f\u00fcr die agile Planung<\/h2>\n
\n
\nBei gleichbleibenden Ressourcen ist diese Erkenntnis eigentlich trivial. Wenn sich der Auftraggeber eine neue, zus\u00e4tzliche Funktion w\u00fcnscht und gleichzeitig weder die Zahl der Mitarbeiter erh\u00f6ht noch der Release-Zeitpunkt verschoben werden, so bleibt nur, eine bisher geplante Funktion gleicher Gr\u00f6\u00dfe zu streichen bzw. Funktionen abzuspecken. Dies muss auf allen Planstufen ber\u00fccksichtigt werden.<\/li>\n<\/ol>\n\n
\nDie oft zu findende Meinung, dass Softwareentwickler generell mit zu viel Puffer sch\u00e4tzen, best\u00e4tigt sich in der Praxis nicht. In der Regel untersch\u00e4tzen sie den Aufwand. Dabei sind die Folgekosten einer zu niedrigen Sch\u00e4tzung deutlich h\u00f6her als die Nachteile durch zu hohes Sch\u00e4tzen. Es sollte daher generell niemals die Aufwandssch\u00e4tzung in Frage gestellt werden, sondern bei zu hohen Werten \u00fcber eine Reduktion des Umfangs bzw. andere technische Ans\u00e4tze gesprochen werden.<\/li>\n<\/ol>\n\n
\n<\/strong>Neben der eigentlichen Programmierarbeit haben agile Teams noch eine ganze Reihe weiterer Aufgaben zu erf\u00fcllen: Unterst\u00fctzen des Product Owners bei der Spezifikation der Stories, Meetings, Bugfixing usw. All das muss bei der Kapazit\u00e4tsplanung ber\u00fccksichtigt werden. Im Schnitt haben agile Teams etwa 34% ihrer Zeit f\u00fcr die tats\u00e4chliche Programmierung neuer Funktionen zur Verf\u00fcgung (siehe Abb. 6,\u00a0PDF<\/a>).<\/li>\n<\/ol>\nZusammenfassung<\/h2>\n
Literatur und Quellen<\/h2>\n
\n<\/strong><\/p>\n
\nAgil & Scrum – unsere Trainings & Coachings<\/h2>\n
\nAgil & Scrum – Fachwissen<\/h2>\n