Die meisten Software-Projekte im IT-Bereich laufen inkrementell und iterativ ab, um die Kontrollspanne klein zu halten und so die Risiken einer Fehlentwicklung und die Komplexität zu reduzieren (siehe z.B. »Lean und Kanban in der IT«).
Iterativ bedeutet in diesem Zusammenhang, dass ein Zeitabschnitt innerhalb eines Entwicklungsprozesses sich in ähnlicher Weise immer wieder wiederholt.
Inkrementell bedeutet in diesem Zusammenhang, dass der Geschäftswert bzw. die Innovation schrittweise erhöht und ein Big-Bang-Release vermieden wird.
Der gesamte Entwicklungsprozess wird hier in viele kleine Iterationen unterteilt, die nicht nur seriell, sondern auch parallel in verschiedenen Teams (siehe Abbildung »Iteration und Timebox«) ausgeführt werden können.
Vorteile iterativer und inkrementeller Vorgehen sind[1]:
- Time to Market: Funktionalität wird den Endanwendern schneller zur Verfügung gestellt.
- Break-Even & Cash-Flow: Software wird schneller an den Kunden ausgeliefert und die Kunden bezahlen früher für die Software.
- Risikominimierung.
- Höhere Profitabilität, ROI
- Bessere Vorhersage der Kundenbedürfnisse
- Deliver Fast: Projektdauer und Release-Zyklen reduzieren um Wertschöpfung zu erhöhen
Gängige, in der Softwareentwicklung übliche Vorgehensweisen welche Iterationen einsetzen sind beispielsweise von IBM das Vorgehensmodell RUP (Rational Unified Process) oder von Microsoft das MSF (Microsoft Solution Framework) und das agile Framework Scrum.
Eine Timebox ist eine spezielle Form der Iteration, deren höchste Priorität die absolute Termintreue ist. Eine Timebox startet und endet zu den geplanten Anfangs- und Endterminen und wird unter keinen Umständen verschoben oder verlängert, auch wenn die Ergebnisse nicht mehr im Zeitplan liegen sollten. In Kapitel »Timebox« und »Meilenstein« wird der Unterschied zum Meilenstein noch einmal detaillierter dargestellt.
Timebox
Die Timebox definiert einen fixen Zeitrahmen, an dessen Ende eine vorher definierte Menge an Ergebnissen vollständig, nachprüfbar und formal dokumentiert vorliegen soll. Liegen die Ergebnisse zu dem geplanten Ende nicht vor, werden die nicht vorliegenden Ergebnisse fallen gelassen oder in eine andere Timebox verschoben. Zum geplanten Ende werden die tatsächlich erreichten Ergebnisse ermittelt. Beim Timeboxing hat der Endtermin eine höhere Priorität als das gelieferte Ergebnis der Iteration. In der Praxis bedeutet dies, dass an dem vereinbarten Termin nur die Ergebnisse geliefert werden die fertig sind[2].
Meilenstein
Der Meilenstein definiert einen Termin, an dem eine vorher definierte Menge an Ergebnissen vollständig, nachprüfbar und formal dokumentiert vorliegen muss. Liegen die Ergebnisse zu dem geplanten Meilenstein nicht vor, wird der Meilenstein verschoben.
Timebox und das Pareto-Prinzip
Das Pareto-Prinzip[3] wurde aus der Pareto-Verteilung[4] abgeleitet und stammt von dem ital. Ökonom Vilfredo Pareto der festgestellt hat, dass 20 Prozent der Bevölkerung 80 Prozent des Volksvermögens besaßen. Dieses Prinzip lässt sich in vielen unterschiedlichen Bereichen empirisch beobachten und kann auch auf unsere Zeitnutzung angewandt werden. In 20% unserer Zeit erreichen wir 80% der Erfolge[5]. Der Einsatz der Timebox hat u.a. das Ziel, das Pareto-Prinzip wirksam umzusetzen und so das Verhältnis von Zeit und Leistung zu verbessern. Hierzu müssen Prioritäten bzgl. Umsetzungsgeschwindigkeit (Aufwand) und Geschäftswert (siehe »Product- und Sprint-Backlog«) festgelegt werden was die Reihenfolge der Abarbeitung der einzelnen Ergebnisse beeinflusst.
Timebox und das Parkinsonsche Gesetz
Wer kennt diese Situation nicht, wenn man eine Aktivität so lange aufschiebt, bis man ein schlechtes Gefühl hat und nun zur Tat schreiten muss (Prüfung, Steuererklärung, Präsentation für das Management, usw.). Danach ist man sehr oft verwundert, was man in dieser kurzen Zeit so alles erreicht hat. Kommt in dieser Situation noch das Pareto-Prinzip hinzu ist diese Art, Aktivitäten abzuarbeiten die effizienteste (siehe »Einstellung«).
Cyril Northcote Parkinson (1909-1993) war ein britischer Historiker und Soziologe und verfasste in seiner Laufbahn einige (humorvolle) Lehrsätze, wobei der bekannteste der Parkinson‘schen Gesetze lautet: »Work expands so as to fill the time available for its completion[6]«, was so viel bedeutet wie »Die Arbeit nimmt solange zu, bis das verfügbare Volumen ausgeschöpft ist«. Diesem Gesetz entsprechend wird bei Schätzungen nicht der notwendige Aufwand zur Umsetzung des Projektes geschätzt, sondern der maximal mögliche Aufwand[7] (siehe »Planning Poker«).
Entwicklungsgeschwindigkeit, Velocity
Wie in Kapitel »Lean und Kanban in der IT« bereits aufgeführt, versucht man im agilen Projektmanagement die parallelen Arbeiten, die sog. WiP’s und die Engpässe weitestgehend zu reduzieren um sukzessive einen gleichmäßigen Fluss in der Softwareproduktion zu erzielen. Die Entwicklungsgeschwindigkeit ist ein Maß, um den Fluss zu messen und beinhaltet die Summe aller Aufwände, die am Ende einer Timebox angefallen sind (siehe »Burndown«). In der Metrik werden teilweise fertiggestellte oder defekte Ergebnisse nicht der Summe zugeordnet, nur fertige Ergebnisse (siehe »Timebox«) werden in die Berechnung der Entwicklungsgeschwindigkeit aufgenommen[8].
Die Abbildung »Entwicklungsgeschwindigkeit« zeigt in den ersten drei Timeboxen einen typischen und positiven Verlauf in der Anfangsphase. Die nachfolgenden Timeboxes können zum Beispiel durch Fehlzeiten, Hindernisse, Urlaub[10], etc. beeinflusst werden. Je mehr Iterationen man durchläuft, desto genauer werden diese Vorhersagen.
Mit dem Wissen der Entwicklungsgeschwindigkeit und der historischen Hindernissen kann man nun gezielt in den Retrospektiven (siehe »Retrospektive«) Optimierungen angehen und Lösungen für die Erhöhung der Entwicklungsgeschwindigkeit finden.
[1] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S.32f.
[2] Oesterreich, Bernd, Weiss, Christian: APM – Agiles Projektmanagement, Erfolgreiches Timeboxing für IT-Projekte; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S.191
[3] Hens, Thorsten, Pamini, Paolo: Grundzüge der analytischen Mikroökonomie; 1. Auflage; Springer-Verlag; Berlin Heidelberg; 2008; S.5ff.
[4] Cottin, Claudia, Döhler, Sebastian: Risikoanalyse – Modellierung, Beurteilung und Management von Risiken mit Praxisbeispielen; 1. Auflage; GWV Fachverlage GmbH; Wiesbaden; 2009; S.40ff.
[5] Lorenz, Michael, Rohrschneider, Uta: Praxishandbuch Mitarbeiterführung; 2. Auflage; Haufe-Lexware GmbH & Co. KG; Freiburg; 2010; S. 99.
[6] Mohrmann, Martin: Bauvorhaben mit Hilfe von Lean Projektmanagement neu denken, bei Unternehmen in der technischen Gebäudeausrüstung; 4. Auflage; Books on Demand GmbH; Norderstedt; 2011; S.55f.
[7] Demleitner, Klaus: Projekt-Controlling, Die kaufmännische Sicht der Projekte, 2. Auflage; expert Verlag, Renningen; 2009; S.134.
[8] Wirdemann, Ralph: Scrum mit User Stories; 1. Auflage; Carl Hanser Verlag München Wien; 2009; S.15ff
[9] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S.72.
[10] Diese werden in den Engpässen zusammengefasst.
No Comments