Einem Release Features, Use Cases und Use Case Slices zuordnen

Nachdem Sie im fünften Teil der Blogserie das erste marktfähige Release angelegt haben, erfahren Sie heute, wie Sie Ihre Features, Use Case und Use Case Slices diesem Release zuordnen. Wenn Sie nach dem Einrichten des Projekts bereits ein zweites Release per Muster angelegt haben, müssen Sie zuerst die Backlog-Sicht mit wenigen Klicks anpassen, in der Sie Features, Epics oder User Stories auf die Release-Backlogs verteilen. 

Einem Release Features zuordnen

Markieren Sie in der Themengruppe Planung und Steuerung die Sicht Anforderungen Domäne / Releases und öffnen Sie das zugehörige Kontextmenü. Darin klicken Sie auf Bearbeiten. Es geht der Dialog Sicht bearbeiten auf.

Gehen Sie in diesem Dialog auf die Registerkarte Kontext-Element. In der Spalte Ziel-Backlogs steht zunächst nur der Eintrag Release 1 Backlog. Das bedeutet: Mit diese Sicht können Sie bisher nur dem Release 1 Features, Epics und User Stories zuordnen. Damit in dieser Sicht auch das Backlog für das neu angelegte zweite Release erscheint, klicken Sie auf das Plus-Zeichen rechts über der Spalte. Es wird ein Auswahldialog geöffnet. Darin finden Sie unter Planung und Steuerung einen Ordner für das zweite Release. Wählen Sie ihn aus. Er wird die Features, Epics und User Stories aus dem Domänen-Backlog aufnehmen, die im zweiten Release bearbeitet werden sollen. Er stellt also das Release-Backlog für das zweite Release dar.

Bearbeiten Sie die Sicht, um Release 2 einzublenden

Vielleicht fragen Sie sich, wo das Release-Backlog für das zweite Release herkommt. Es wurde durch das Muster angelegt, mit dem neue Releases erzeugt werden und das seinerseits aus der Vorlage für ein agiles, skalierbares Projekt stammt.

Jetzt steht dem Planen der ersten Releases nichts mehr im Weg.

Öffnen Sie die gerade neu konfigurierte Sicht Anforderungen Domäne / Releases. Sie ist zweigeteilt (vgl. nachfolgende Abbildung): Links sehen Sie die Anforderungen der Domäne, rechts die Release-Backlogs. Unter den Anforderungen der Domäne gibt es in unserem Beispiel ein Epic 1. Es ist markiert. Sie sehen, dass es eine Verfeinerung von Feature ist. Sie erkennen außerdem, dass daraus ein QualityRequirement abgeleitet wurde. Diese Darstellung kennen Sie bereits vom Domänen-Backlog. Epic 1 erscheint auch rechts im Backlog von Release 1. Wie ist es dort hingekommen? Gibt es das Epic doppelt?

Sicht für Domäne- und Release-Backlog

Die Antworten lauten: „Per Drag & Drop“ und „Nein“. Um eine Anforderung aus der Domäne in ein Release-Backlog zu übernehmen, ziehen Sie sie einfach von links nach rechts in das Backlog. Bei dieser Aktion werden Sie gefragt, ob Sie die Anforderung aus dem Ordner der Anforderungen der Domäne in den Ordner, der das Release-Backlog darstellt, Verschieben oder im Release-Backlog eine Referenz erstellen wollen. In der obigen Abbildung wurde eine Referenz erstellt – erkennbar am leicht veränderten Icon. Wenn Sie sich für Verschieben entscheiden, verschwindet die Anforderung aus dem Domänen-Backlog.

Immer aber gilt: Eine bewertete Anforderung, die Sie in ein Release-Backlog übernehmen – egal, ob als Referenz oder im Original –, geht in den Zustand übernommen über.

Sie haben sich vertan und müssen eine Anforderung wieder aus dem Release-Backlog herausnehmen? Wenn Sie mit Referenzen arbeiten, einfach mit dem gleichnamigen Kontextmenübefehl die Referenz löschen (aber Achtung, nicht die Anforderung löschen!). Wenn Sie eine Anforderung versehentlich in das Backlog verschoben haben, einfach wieder zurückverschieben. In beiden Fällen geht die Anforderung von übernommen wieder in den Zustand bewertet über.

In welches Release ist eine Anforderung eigentlich eingeplant? Je weiter das Projekt voranschreitet, umso häufiger stellt sich diese Frage. Markieren Sie einfach die Anforderung links im Bereich der Domäne. Die Referenz rechts im Release-Backlog wird grau hinterlegt. Zusätzlich wird der Rahmen des Release-Backlogs farbig hervorgehoben. Am hervorgehobenen Rahmen erkennen Sie das Release-Backlog, das die Anforderung enthält, auch dann, wenn das Backlog zugeklappt ist.

Übrigens: Das Tool hilft Ihnen festzustellen, ob die gewünschten Features vom Aufwand her tatsächlich in das Release „hineinpassen“. Oben rechts finden Sie in jedem Release-Backlog zwei Zahlen. Im obigen Beispiel lauten sie 65 / 250. Die erste ist die Summer der geplanten Aufwände aller Anforderungen, die sich bereits im Release-Backlog befinden. Die zweite zeigt den Gesamtaufwand an, der für das Release geplant ist. Im obigen Beispiel ist aufwandsmäßig also noch jede Menge „Luft“. Das funktioniert natürlich nur, wenn Sie für die Anforderungen der Domäne einen Planaufwand geschätzt und im Anforderungsformular eingegeben haben.

Einem Release Use Cases und Use Case Slices zuordnen

Für die Arbeit mit Use Cases steht Ihnen zum einen eine spezielle Sicht auf das Domänen-Backlog zur Verfügung. Sie finden sie unter dem Namen Anwendungsfälle Domäne Backlog in der Themengruppe Anforderungen. Zum anderen gibt es in der Themengruppe Planung und Steuerung eine spezielle Planungssicht Anwendungsfälle Domäne / Release-Backlogs.

Use Cases und Use Case Slices einem Release zuordnen

Die Bedienung funktioniert genauso wie die der bereits beschriebenen Sicht Anforderungen Domäne / Releases.

Sie haben Ihre Features, Use Cases und Use Case Slices Releases zugeordnet. Was ist aber, wenn der Unternehmensbereich der zu entwickelnden Lösung sehr groß ist? Wie Sie Ihre Features, Use Cases und Use Case Slices in solchen Fällen am besten planen, erfahren Sie im nächsten Blog-Beitrag. Wenn Sie bereits Fragen 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.