Um ein bekanntes Konzept im Projektmanagement zu paraphrasieren, könnte man sagen: „Planung ist unverzichtbar, aber Pläne sind nutzlos. Daher inspizieren und anpassen.“
Traditionelle Pläne werden von Daten bestimmt – höchstwahrscheinlich mit einem Enddatum als primärem treibenden Faktor. Im traditionellen Projektmanagement sammeln Sie die Anforderungen Ihrer Stakeholder, bauen den Umfang des Projekts auf und zerlegen das Projekt in überschaubare Arbeitsschritte. Dadurch wird wiederum ein Projektstrukturplan (PSP) erstellt. Als nächstes wird die unterste Ebene der PSP, d. H. Arbeitspakete, weiter in Aktivitäten zerlegt. Die Aktivitäten werden dann mit Abhängigkeiten verknüpft, und Ressourcen werden geschätzt und auf Aktivitäten angewendet, um einen End-to-End-Zeitplan für das Projekt zu erstellen. Dieser Zeitplan wird dann mit Hilfe eines Zeitplanmanagementplans überwacht und gesteuert, der in der Regel ein Nebenplan des konsolidierten Projektmanagementplans ist.
Aber wie oft ist es passiert, dass das, was Sie geplant haben und was tatsächlich vor Ort passiert ist, übereinstimmt? Sie kennen die Antwort bereits! Das Eröffnungszitat bedeutet, dass Planung unerlässlich ist, aber zu erwarten, dass wir dem Plan genau folgen können, ist keine kluge Sache. Wenn die Anforderungen stark schwanken und die Technologie oder Plattform unsicher ist, gehen PMs normalerweise mit adaptiven (oder agilen) Lebenszyklen um.
Tatsächlich lautet der vierte Wert im Agilen Manifest: „Auf Veränderungen zu reagieren bedeutet, einem Plan zu folgen.“ Agil ist veränderungsgetrieben, und höchstwahrscheinlich werden diese Veränderungen von den Kunden vorangetrieben. Dies führt zu einem Konzept namens Agile Release Planning.
Die Release-Planung unterscheidet sich von der herkömmlichen Planung, bei der der vollständige Plan im Voraus betrachtet, detailliert ausgearbeitet und nur mit formellen Änderungsanforderungen geändert werden kann. Ein Release-Plan kann viele Male basierend auf dem Feedback aus früheren Iterationen aktualisiert werden.
Da adaptive Lebenszyklen inkrementeller Natur sind, können Organisationen am Ende jeder Iteration freigeben. Sie können auch nach einigen Iterationen oder sogar kontinuierlich freigeben. Dies erfordert eine längerfristige Planung, kann jedoch durch die Verwendung der Release-Planungstechnik, die in der 6. Ausgabe des PMBOK-Handbuchs neu eingeführt wurde, effektiv erleichtert werden.
Für angehende Project Management Professionals (PMPs) und Certified Associates im Projektmanagement (CAPM) ist Agile Release Planning ein Schlüsselkonzept. Der PMBOK Guide 6th Edition hat Agile Überlegungen für jeden Wissensbereich eingeführt. Dies ist auch nützlich für angehende Agile Certified Practitioners (ACPs).
Wenn wir näher darauf eingehen, wollen wir zunächst sehen, wie die Release-Pläne auf hohem Niveau entwickelt werden.
Von der Vision über die Roadmap bis hin zu Release-Plänen
In agilen Projekten beginnt die Arbeit mit einer Produktvision. Die Vision wird dann in eine Produkt-Roadmap umgesetzt. Die Roadmap enthält die Funktionen, die über einen bestimmten Zeitraum entwickelt werden sollen. Sie können auch sagen, dass eine Roadmap den Umfang des Produkts darstellt, das in verschiedenen Versionen geliefert wird. Dies führt zu den Release-Plänen und ist in der folgenden Abbildung dargestellt.
Roadmap und Product Backlog
Eine Komponente in der obigen Reihenfolge ist die Produkt-Roadmap, und um die Produkt-Roadmap zu verstehen, müssen wir zuerst das Produkt-Backlog verstehen. Bei agilen Ansätzen sind alle Anforderungen – sowohl Projektanforderungen als auch Produktanforderungen – Teil des Product Backlogs (PB). Jedes Element im Product Backlog wird als Product Backlog Item (oder PBI) bezeichnet. Abgesehen von Funktionen (Anforderungen) kann ein Product Backlog-Element eine Änderungsanforderung, ein Defekt, ein Fehler, ein Problem oder sogar eine bestimmte technische Arbeit sein.
Wie wir wissen, entwickeln sich die Anforderungen in agilen Projekten kontinuierlich weiter und es bestehen erhebliche Unsicherheiten/Risiken. Daher priorisieren wir normalerweise die PBIs. Die priorisierten PBIs werden von der Spitze des Backlogs übernommen und an die Kunden geliefert. Elemente mit hoher Priorität bleiben oben im Backlog und sind feinkörnig, während Elemente mit niedriger Priorität unten im Backlog und grobkörnig sind. Die Priorisierung der Elemente im PB bestimmt den Detaillierungsgrad für dieses Element im Product Backlog. Dies ist in der folgenden Abbildung dargestellt.
Wenn Sie agile Tools wie Microsoft Project verwenden, können Sie das Product Backlog schnell entwickeln. Ein Beispiel für ein Product Backlog, das mit MS Project erstellt wurde, ist unten dargestellt.
Hier haben wir ein Product Backlog, das die Product Backlog-Elemente (PBIs) von „Neuen Benutzer erstellen“, „Beim Online-Handelssystem anmelden“, „Aktie übertragen“ usw. anzeigt. Wenn Sie ein anderes Backlog-Element hinzufügen möchten, müssen Sie nur auf das Symbol „+“ im Befehlsfeld „Neue Aufgabe“ klicken.
Die Elemente der obersten Ebene im Product Backlog können in User Stories geschrieben werden, die in Story Points geschätzt werden – einem relativen Maß ohne Einheit.
Wenn Sie nun zur Produkt-Roadmap kommen, können Sie einfach sagen, dass es sich um ein Product Backlog mit einer Zeitleiste handelt. Eine Roadmap zeigt die geplante Zukunft des Projekts (d. H. geplante und / oder vorgeschlagene Produktveröffentlichungen) oder Release-Themen und listet übergeordnete Funktionen des Produkts auf. Die Roadmap sagt, welche Features oder Epen (ein Epos, einfach gesagt, ist eine große User Story) in jeder Version geliefert werden.
Release-Plan
Die Produkt-Roadmap bestimmt die Release-Pläne. Ein Release-Plan gibt den Release-Zeitplan an – jede Version dauert in der Regel drei bis sechs Monate. Ein Release enthält viele Iterationen – von Iteration 0 (Iteration Null) bis Iteration N. Iteration 0 kann für Projektgenehmigungen, das Einrichten der Umgebung für das Projekt, erste Übersicht und Designdiskussionen usw. verwendet werden. Einige agile Praktiker verwenden Iteration – H (Hardening Iteration), die die letzte Iteration am Ende des Releases ist, um sich auf die Auslieferung vorzubereiten. Diese Iteration kann endgültige Arbeitselemente wie Schulungs- und Marketingmaterialien, endgültige Versionshinweise, Installationsanleitungen, System- / Benutzerhandbücher usw. enthalten. Dies ist unten dargestellt.
Wie gezeigt, hat der Release-Plan Iterationen – von „Iteration – 0“ bis „Iteration – N“. Sie können entscheiden, ob Sie nach einigen Iterationen ein Release und / oder ein endgültiges Release nach der letzten Iteration haben möchten.
Der Release-Plan enthält eine Roadmap, wie das Team die Projektvision im Rahmen der Projektziele und -einschränkungen erreichen will. Es hilft dem Product Owner und dem gesamten Team zu entscheiden, wie viel entwickelt werden muss und wie lange es dauern wird, bis sie ein freigabefähiges Produkt haben. Es vermittelt Erwartungen darüber, was wahrscheinlich in welchem Zeitrahmen entwickelt wird. Der Release-Plan kann auch als Wegweiser dienen, auf dem das Team voranschreiten kann. Der Release-Plan kann am Ende einer Iteration aktualisiert werden und spiegelt die aktuellen Erwartungen wider, die berücksichtigt werden, damit sie in nachfolgenden Iterationen erfüllt werden können.
Release-Planung mit Product Backlog
Um die Release-Planung besser zu verstehen, können Sie die Release-Pläne mit Hilfe von Product Backlog visualisieren.
Wir wissen bereits, dass die Artikel im Product Backlog basierend auf ihrer Priorität eingestuft oder bestellt werden. Die Elemente der obersten Ebene, die feinkörnig sind, werden in der nächsten Iteration (unter der unmittelbaren nächsten Version) zum Verzehr bereit sein. Das priorisierte Backlog mit Features und anderen Elementen wird auf der linken Seite der folgenden Abbildung angezeigt.
 |
 |
In MS Project müssen Sie einfach Backlog-Elemente auswählen, ziehen und ablegen und sie nach Bedarf anordnen, um sie zu priorisieren. Dies ist auf der rechten Seite der obigen Abbildung dargestellt. In Anbetracht des vorherigen Beispiels, das das Product Backlog in MS Project zeigt, haben wir dieses relative Ranking: Zuerst „Melden Sie sich beim Online-Handelssystem an“, dann „Erstellen Sie einen neuen Benutzer“, dann „Kaufen Sie eine Aktie“ usw.
Wie oben gezeigt, habe ich das Feature-Element „Beim Online-Handelssystem anmelden“ ausgewählt und gezogen und es vor dem Feature-Element „Neuen Benutzer erstellen“ abgelegt.“ Das ausgewählte Element war beim Ziehen und Ablegen leicht ausgegraut.
Über das Backlog können Sie entscheiden, welche der Backlog-Elemente in den nächsten Releases ausgeliefert werden sollen. Unten sehen wir, dass die Elemente in der nächsten Version (dh Version 1) größtenteils priorisiert sind. Die Elemente für Release 2 können ebenfalls priorisiert werden, aber wir sehen, dass Elemente für Release 3 nicht priorisiert werden, da es sich um Elemente mit niedriger Priorität handelt.
Sie können diese Release-Planung auch mit MS Project visualisieren. Schauen Sie sich die Abbildung unten an. Es gibt PBIs, die in verschiedenen Versionen eingenommen werden. Denken Sie daran, ein Release enthält Iterationen? In unserem Fall haben wir für die erste Version drei Iterationen, und es wird erwartet, dass alle Elemente in diesen Iterationen geliefert werden. Eine Iteration wird im Scrum-Framework als Sprint bezeichnet, einem beliebten Framework, das von agilen PMs verwendet wird. Für die nächsten beiden Releases (d. H. Release 2 und Release 3) haben wir die PBIs, aber wir haben uns noch nicht für die Iterationen (oder Sprints) entschieden.
Iterationsplanung
Wenn Sie gefolgt sind, besteht der Release-Plan aus Iteration 0 bis Iteration N und wir können entscheiden, am Ende aller paar Iterationen oder jeder Iteration zu veröffentlichen. Aber was passiert innerhalb einer Iteration? Einfach gesagt, der Umfang für eine Reihe von Features innerhalb der Iteration wird zu Beginn der Iteration bestätigt und am Ende der Iteration geliefert.
Die Features, die bestätigt und für die Iteration verwendet werden, werden nach Aufgaben (oder Aktivitäten) aufgeschlüsselt und von den Teammitgliedern in Stunden geschätzt. Die Abfolge der Schritte von der Produkt-Roadmap über den Release-Plan bis zum Iterationsplan ist in der folgenden Abbildung dargestellt.
Zusammenfassend die obige Abbildung, werden dies die wichtigsten Punkte sein:
- Die Vision des Produkts treibt die Produkt-Roadmap voran
- Die Produkt-Roadmap treibt die Release-Pläne voran
- Ein Release-Plan enthält Iterationen
- Funktionen, die in Story Points geschätzt werden, werden in einer Iteration entwickelt
- Funktionen werden in Aufgaben unterteilt, die in Stunden geschätzt werden
Mit MS Project 2016 können Sie schnell einen Release-Plan erstellen. In Anbetracht unseres vorherigen Backlog-Beispiels haben wir drei Iterationen / Sprints für die erste Version (dh Sprint 1, Sprint 2 und Sprint 3). Jeder Sprint verfügt über eine Reihe von Funktionen, die bereitgestellt werden müssen. Dies wird unten in der Ansicht „Sprint Planning Board“ angezeigt.
Sie können auch einen Drilldown durchführen, um zu sehen, was auf Iterations- / Sprintebene passiert, und um herauszufinden, an welchen PBIs gearbeitet wird. MS Project zeigt dies in der Ansicht „Aktuelles Sprintboard“ an. Siehe Abbildung unten.
Für Sprint 1 müssen drei Elemente geliefert werden: „Melden Sie sich beim Online-Handelssystem an“, „Erstellen Sie einen neuen Benutzer“ und „Kaufen Sie eine Aktie.“ Diese durchlaufen drei Workflow-Zustände „Next Up“, „In Bearbeitung“ und „Done“.“ Natürlich können Sie diese Workflow-Zustände nach Bedarf hinzufügen, entfernen oder anpassen.
Release-Plan vs. Iterationsplan
Wenn Sie die Prüfung ablegen, müssen Sie auch die Unterschiede zwischen Release-Plan und Iterationsplan kennen. Sie sind in der folgenden Tabelle vermerkt. In der Regel sind die Iterationen für zwei bis vier Wochen timeboxed. In einigen Fällen, wie z. B. XP (ein weiteres agiles Framework), können Iterationen jedoch eine Woche dauern.
Project Management Body of Knowledge (PMBOK) Guide, 6. Auflage, von Project Management Institute (PMI)
Ich möchte ein PMP sein: Der einfache und einfache Weg, ein PMP zu sein, 2. Auflage, von Satya Narayan Dash
Ich möchte ein ACP sein: Der einfache und einfache Weg, ein ACP zu sein, von Satya Narayan Dash
Microsoft Project 2016 Live Lessons, von Satya Narayan Dash
Agile Practice Guide, von Project Management Institute VPI)