- Agilität (94)
- Allgemein (10)
- Ankündigungen (29)
- Buchtipp (13)
- Crystal (7)
- Konferenzen (23)
- Kunden (5)
- Lean Software Development (1)
- Management (36)
- Planung (20)
- Politik (14)
- Praktiken (7)
- Refactoring (11)
- Scrum (15)
- Software Design (10)
- Surftipp (28)
- Testgetriebene Entwicklung (8)
- Werkzeuge (7)
- Zitate (8)
- 21.1.2010: it-agile und Coldewey Consulting gehen zusammen
- 11.12.2009: Aufspalten einer User Story
- 6.11.2009: Vortrag auf der W-Jax zu langfristiger agiler Planung
- 2.10.2009: Alistair Cockburns Keynote "I come to bury Agile, not to praise it" als Video
- 22.9.2009: Apple und die Macht einer Vision
- 21.9.2009: Pair Programming in der New York Times
- 10.9.2009: Neue XING-Gruppe zu Lean Software Development
- 9.9.2009: CSM+Crystal Kurse mit Alistair Cockburn
- 7.8.2009: Alistair Cockburn gibt CSM-Kurs in Deutschland im November
- 21.7.2009: Folien der Karlsruher Entwicklertage online
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Juni 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- September 2008
- Juli 2008
- Juni 2008
- Mai 2008
- April 2008
- März 2008
- Februar 2008
- Januar 2008
- Dezember 2007
- November 2007
Bestandteile eines Projektplans - wirklich nötig?
Stefan Hagen hat in seinem “Projektmanagement Blog” eine Folie bereitgestellt mit den “Bestandteilen eines Projektplans“. Die Folie enthält unter anderem 18 Teilpläne, einschließlich “Arbeitspaketdefinitionen” und “Terminplan (GANTT)”.
Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:
- Das Team auf die wichtigen Aufgaben fokussieren
- Zusammenarbeit koordinieren
- Vorhersagen über Fertigstellungstermine ermöglichen
- Transparenz über den Projektstatus schaffen
Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Das Team erstellt gemeinsam mit den Auftraggebern eine priorisierte Liste der zu erstellenden Features und schätzt sie gemeinsam. Schon durch die gemeinsame Erstellung des Plans werden Ziel eins und zwei erreicht.
Die Liste wird prominent aufgehängt, in der Regel in Form von Karteikarten auf einer Pinwand. Sind Entwickler frei, “holen” sie sich die nächstwichtige Aufgabe von der Wand und hängen sie in die Liste der Aufgaben in Bearbeitung. Sobald das Feature mit allen Tests implementiert ist (das heißt alle neuen automatischen Tests und alle alten Tests laufen auf dem Integrationsserver fehlerfrei duch), hängen sie die Karte auf “fertig”. Diese klare Definition, wann eine Aufgabe fertig ist, trägt erheblich zur Transparenz bei.
Für die Vorhersagen gibt es Schätzverfahren, die anhand der vorigen Iterationen kalibriert und nachkalibriert werden.
Natürlich wird diese Planung für jede Iteration wiederholt. Ich persönlich arbeite dabei oft mit drei Ebenen unterschiedlicher Granularität: Wochenplanung, Monatsplanung und Releaseplanung (siehe auch den Eintrag “Langfristige Produktplanung und Agilität“).
Bei allen Teams, in denen ich diese Verfahren eingeführt habe, war die deutliche Verbesserung von Transparenz und Zusagetreue einer der schnellsten Effekte. Dass das, was man anhand der Transparenz nun sehen konnte, nicht immer erfreut hat, ist ein anderes Thema.
Keines der Teams hat eines der 18 Planungsdokumente erstellt oder gepflegt, alle haben wirtschaftlich erfolgreiche Projekte oder Produkte entwickelt. Ich stimme daher Herrn Hagen zu, dass “eine systematische, pragmatische und dynamische Projektplanung von größter Bedeutung für den späteren Erfolg” ist, ich bin aber überzeugt, dass der agile Planungsansatz diese Anforderungen weit effizienter erfüllt, als eine Sammlung von 18 Planungsdokumenten - zumal das für deren Pflege notwendige Projektmanagementbüro in der Regel größer ist, als das Entwicklungsteam in agilen Vorhaben.