Strategie durch Releases definieren

Nachdem Sie im vierten Blog-Beitrag Ihre Vision definiert und dokumentiert haben, geht es heute darum, den Weg festzulegen, auf dem die Vision erreicht und dabei die Ziele der Stakeholder in konkreten Nutzen umgesetzt werden sollen.

Der Weg wird durch die Anzahl und den Inhalt der Releases markiert, die den Stakeholdern schrittweise zur Verfügung gestellt werden sollen. Mit Release bezeichnen wir dabei ein fertiges, einsetzbares Stück des Systems, das einen Teil der Anforderungen der Stakeholder realisiert. Jedes Release soll den Stakeholdern einen möglichst hohen Geschäftswert bieten. Es wird vollständig getestet und freigegeben, sodass es in den Echtbetrieb gehen kann. Ob ein Release tatsächlich ausgerollt wird, ist eine Entscheidung, die bei den Stakeholdern liegt.

Besonders am Anfang eines längeren Projekts ist es wichtig, möglichst schnell ein Feedback von den Anwendern bzw. vom Markt zu erhalten. Gerade das erste Release sollte so früh wie möglich bereitgestellt werden, um sicherzugehen, dass der eingeschlagene Weg der richtige ist.
Aus diesem Anspruch heraus ist das Konzept des minimal marktfähigen Release (MMR) entstanden. In der Produktentwicklung spricht man auch vom Minimal Viable Product, einem Produkt mit minimalen Anforderungen und Eigenschaften.

Sie können die Planung des ersten minimal marktfähigen Release mit seinem Ziel und den zu realisierenden Features tool-unterstützt durchführen. Wenn Sie Ihr Projekt auf der Basis der Vorlage für ein agiles, skalierbares Projekt angelegt haben, ist dafür Folgendes zu tun:

• Passen Sie Mitarbeitereinsatz, Aufwand, Dauer, Start- und Endtermin für die Release-Aktivität zur Entwicklung des ersten minimal marktfähigen Release an. Das funktioniert genauso, wie es im Tool-Tipp „Projektplan anpassen“ im Abschnitt 11.3 für die Projektaktivität beschrieben wurde.
• Halten Sie das Release-Ziel bei der Release-Aktivität fest. Das Release-Ziel sollte in wenigen Sätzen ausdrücken, an wen sich das Release primär wendet, was der funktionale Schwerpunkt sein wird und welcher Wert für die Stakeholder daraus erwächst. Wohin mit diesem Text?

Release-Ziel festhalten

Wir schlagen vor, das Release-Ziel in der Beschreibung der Release-Aktivität zu hinterlegen.

Und noch ein Tipp: Haben Sie im Meeting zur Abgrenzung des minimal marktfähigen Release an Whiteboards oder Pinnwänden gearbeitet und die Ergebnisse mit Ihrem Smartphone fotografiert? Dann fügen Sie diese Fotos doch in die Beschreibung des Release-Ziels ein. In der Editor-Leiste über dem Beschreibungsfeld finden Sie ein Icon mit einer Sonne. Damit können Sie Bilder in den Text einfügen.

• Wenn Sie Features identifiziert haben, die nicht im ersten minimal marktfähigen Release enthalten sein sollen, aber in jedem Falle in einem darauf-folgenden Release berücksichtigt werden müssen, legen Sie die Aktivitäten für Folge-Releases im Projektplan an.

Release per Muster anlegen

Wie bereits beim Einrichten eines Projekts beschrieben, gehört zu einem Release mehr als nur eine Aktivität im Projektplan. Ein Release umfasst mindestens ein Team mit seinen Sprints, Elementgruppen, jede Menge Auswertungen und Sichten etc. Die Vorlage für ein agiles, skalierbares Projekt, mit der Sie Ihr Projekt angelegt haben, hat dafür gesorgt, dass Ihnen jetzt ein Muster zur Verfügung steht, das Ihnen die Arbeit fast vollständig abnimmt.

Muster werden Ihnen immer kontextorientiert angeboten. Das heißt, es stehen nur die Muster zur Auswahl, die in einem speziellen Kontext sinnvoll sind. Um in Ihrem Projekt ein weiteres Release anzulegen, öffnen Sie den Projektplan als Gantt Chart. Markieren Sie die oberste, also die Projektaktivität und öffnen Sie das zugehörige Kontextmenü. Wenn Sie mit der Maus auf den Befehl Muster anwenden fahren, wird ein Untermenü angezeigt. Es enthält die Menübefehle Release für ein Team anlegen und Release für mehrere Teams anlegen. Das bedeutet: Es existieren im Kontext der Projektaktivität zwei Muster, die die Wirkung haben, ein neues Release zu erzeugen. Da das Projekt mit der Vorlage für ein agiles, skalierbares Projekt angelegt wurde, also offenbar mehrere Teams zum Einsatz kommen sollen, empfiehlt das Tool die Verwendung des Musters Release für mehrere Teams anlegen. Sie erkennen das empfohlene Muster an dem vorangestellten grünen Symbol.

Wenn Sie der Empfehlung folgen und den Kontextmenübefehl Release für mehrere Teams anlegen wählen, wird ein Konfigurationsdialog geöffnet. Bei der Menge an Artefakten, die mit diesem Muster erzeugt wird, sind einige Einstellungen vorzunehmen.

Die Sache ist einfacher, als es auf den ersten Blick aussieht. In der linken Spalte, die mit Namen der neuen Elemente überschrieben ist, sehen Sie das, was angelegt wird – allerdings auf Ordner-Niveau und nicht bis ins letzte Detail. Die Wörter in den geschweiften Klammern sind Platzhalter. Sie müssen sie durch konkrete Namen ersetzen: Also statt {Release} zum Beispiel Release 2.

Damit Sie das nicht mehrfach machen müssen, gibt es den Fußbereich des Dialogs, der mit Namensersetzungen überschrieben ist. Hier geben Sie die Ersetzungen für die Platzhalter ein – also den Namen für das neue Release, die Bezeichnung für den ersten Sprint im neuen Release und den Namen des ersten Teams, das am Release mitarbeiten soll. Das Muster erzeugt eine Ordnerhierarchie für Release-, Team- und Sprint-Artefakte. Außerdem entstehen Aktivitäten mit Kontrollflüssen und Themeneinträge in der Themenleiste. Die Namen für den Ende-Meilenstein des Release, den Release-Ordner, die Release-Aktivität und die Einträge in den Themengruppen werden aus dem eingegebenen Release-Namen automatisch gebildet. Sie können diese Namen in der linken Spalte des Konfigurationsdialogs überschreiben.

Werfen Sie jetzt bitte einen Blick auf die rechte Spalte. Hier wählen Sie die bestehenden Elemente aus, mit denen die neuen Elemente, die das Muster erzeugt, „irgendwie“ in Beziehung stehen.

In der ersten Zeile der rechten Spalte müssen Sie für den Ende-Meilenstein eine übergeordnete Aktivität vom Stereotyp «WorkPackage» festlegen. Wir empfehlen Ihnen, die oberste Projektaktivität auszuwählen.

In der zweiten Zeile ist der übergeordnete Ordner in der Produktesicht für die Planungs- und Steuerungsartefakte des Release festzulegen. Empfehlung: Wählen Sie den Ordner Planung und Steuerung.

In der dritten Zeile definieren Sie unter den vorhandenen Projektgruppen diejenige, die als Team am Release mitarbeiten soll. Oder in der Sprache des Projektmanagements: Sie legen die Projektgruppe fest, die als Ressource der Release-Aktivität zugewiesen werden soll.

In der vierten Zeile wählen Sie die Vater-Aktivität für die neue Release-Aktivität aus. Wir empfeh-len Ihnen hier wieder, die oberste Projektaktivität zu nehmen.
In der fünften Zeile bestimmen Sie die Vorgängeraktivität im Projektplan. Sinnvollerweise ist das der Ende-Meilenstein vom Vorgänger-Release.

Die letzten beiden Angaben betreffen die Themengruppen in der Themenleiste. Hier müssen Sie keine Einstellungen tätigen.

Wenn Sie den Dialog mit OK abschließen, können Sie im Projektplan, der Produktesicht und der Themenleiste – denn auch sie wird für das neue Release erweitert – die Wirkung live miterleben:

Das Muster erzeugt sowohl eine Ordner- als auch eine Aktivitäten-Hierarchie. Beide Hierarchien sind nach Teams und innerhalb eines Teams nach Sprints gegliedert. Die vom Muster angelegte Ordnerhierarchie enthält die Ordner {Release} Backlog, Baseline und Auswertungen. Innerhalb der Ordnerhierarchie des Teams wird ein Ordner für die Artefakte des ersten Sprints angelegt. Die erzeugten Artefakte umfassen {Team} Backlog, Baseline und Auswertungen. Die von Muster angelegte Aktivitäten-Hierarchie enthält eine Release-Aktivität, einen Ende-Meilenstein mit Kontrollfluss sowie einen Kontrollfluss zu dem Ende-Meilenstein des Vorgänger-Release. Die Release-Aktivität ist in eine Team-Aktivität verfeinert, die ihrerseits eine Sprint-Aktivität enthält. Der Ende-Meilenstein vom Stereotyp «Gate» wird in der Roadmap der Organisation angezeigt, die eine Übersicht der Meilensteine sämtlicher Projekte der Organisation abbildet. Der erzeugten Team-Aktivität ist die im Konfigurationsdialog ausgewählte Projektgruppe als Ressource zugeordnet. Der Release- und Team-Aktivität sind Backlog-Ordner zugewiesen, die die eingeplanten Anforderungen oder Anwendungsfälle aufnehmen. Damit wird es möglich, die Aufwände für ein Release bzw. für eine Team-Aktivität zu summieren und mit den Planaufwänden zu vergleichen.

Zum Anlegen eines Release mit einem Team sowie weiterer Sprints und neuer Teams gibt es separate Muster.

 

Jetzt müssen Sie dem minimal marktfähigen Release Features, User Cases und Use Case Slices zuordnen. Wie das geht erfahren Sie im nächsten Blog-Beitrag. Wenn Sie bereits Fragen zum Anlegen eines Releases haben, dann melden Sie sich bitte bei uns. Wie immer stehen wir unter service@microtool.de bzw. 030/467086-20 sehr gerne zur Verfügung.

 

Hinweis:

Alles Wichtige zu objectiF RPM auf einen Blick haben wir für Sie im objectiF RPM Whitepaper zusammengestellt.