Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Dieser Blogbeitrag ist die Abschlussarbeit der Teilnehmer des Seminars Agiles Software-Projektmanagement vom 11. - 15.03.2013.

Der War Room ist ein Raum im Rahmen eines Projekts, in dem sich Teammitglieder jederzeit treffen können. Alle Informationen, die für das Projekt relevant sind, sind im War Room ständig präsent. Bei größeren Projekten unterscheidet man zwei verschiedene Arten von War Rooms.

Der Projektleitungs War Room bildet den Rahmen für das Gesamt-Projekt und bietet vor allem Informationen für den Gesamt- und die Teilprojektleiter. Der Feature-Team War Room bildet den Rahmen für die einzelnen Feature-Teams eines größeren Projektes. Im Folgenden werden für beide War Room Typen Informationen und Tools vorgestellt, die jeweils verfügbar sein sollten.

 

Projektleitungs War Room

Produkt Vision

 

Abbildung 1: Produkt Vision

 

Abbildung 2: Produkt Vision - Kundensicht

Die Produkt Vision ist sozusagen das Big Picture des zu entwickelnden Produkts. Es ist wichtig, dass alle Teammitglieder jederzeit wissen, wohin die Reise gehen soll – was soll entwickelt werden? Was sind die Ziele für den Kunden? Die Produkt Vision sollte in einfacher Form (z.B. mit prägnanten Schlagworten)  und leicht verständlich jederzeit präsent sein. Idealerweise wird die Produkt Vision durch eine graphische Darstellung unterstützt.

Produkt Backlog

Abbildung 3: Produkt Backlog

Das Produkt Backlog gibt eine vollständige Übersicht über die noch zu erledigenden Arbeiten im Projekt. Die einzelnen Arbeitsschritte werden ausgedrückt in Form von Use Cases oder User Stories, die die benötigten Funktionalitäten aus Sicht der User beschreiben. Dabei besteht ein Use Case (UC) mehreren User Stories (US). Diese Verfeinerung wird im Laufe des Projekts nach Bedarf durchgeführt, so dass die in naher Zukunft umzusetzenden Aufgaben die feinste Granularität aufweisen. Die User Stories ersetzen dabei den Use Cases im Backlog.

Das Produkt Backlog enthält für jeden UC/US den jeweiligen Namen, eine erklärende Beschreibung, sowie ein Akzeptanzkriterium, das definiert wann die Aufgabe als erfüllt gilt.

Eine weitere Spalte im Backlog ist ein erster Schätzwert für den Aufwand des entsprechenden UC/US. Hierbei wird eine relative Skala verwendet („Story Points“) die den Aufwand im Verhältnis zu den anderen UC/US beschreibt.

Bereits erledigte UC/US werden aus dem Backlog entfernt, so dass immer eine Übersicht über den aktuellen Projektstand sichtbar ist und auch eine Schätzung der verbleibenden Zeit ermöglicht.

Release Plan

Abbildung 4: Release Plan

Im Release Plan wird die inhaltliche Aufteilung der einzelnen Anforderungen auf die verschiedenen Releases und Iterationen dargestellt. Eine Möglichkeit hierzu ist die Story-Map. In dieser graphischen Darstellungsform werden die verschiedenen Use Cases den einzelnen Releases zugeordnet. Dabei kann ein Release aus mehreren Iterationen bestehen.

Burn up Chart

Abbildung 5: Release Burn up Chart

Das Release Burnup Chart gibt einen Überblick über den Gesamtprojektfortschritt. Dargestellt werden die bearbeiteten Story Points zu jedem Release in Relation zum Gesamtaufwand.

Feature Team War Room

Abbildung 6: Feature Team War Room

Definition of Done

Die Definition of Done ist eine Checkliste von Aktivitäten und Prüfungen, auf deren Basis identifiziert werden kann, ob Iterationen, Use Cases, User Stories, Tasks (Entwicklungstasks, Testtasks, DokuTasks etc.) abgeschlossen sind. Sie wird verwendet, um die um die Qualität von Ergebnissen unterschiedlicher Art während der Iterationen zu prüfen und für alle transparent zu definieren, wann konkret ein Task, ein Artefakt oder die Iteration bzw. auch ein Release abgeschlossen ist.

Abbildung 7: Definition of Done

Alles, was nicht allen relevanten Prüfkriterien der Definition of Done entspricht, gilt als nicht fertig. Teilweise fertige Artefakte gelten weiter als „in Bearbeitung“.

Die Definition of Done wird zu Projektbeginn von den Projektbeteiligten festgelegt und während des Projektablaufs auf Basis von Erfahrungen / Ideen weiterentwickelt.

Aus den Kriterien der Definition of Done ergeben sich automatisch Tasks für das Task Board. Die Definition of Done unterstützt also beim Verfeinern von UseCases und User Stories in konkrete Tasks und hilft, den Aufwand bis zur Fertigstellung besser zu einzuschätzen.

Burndown Chart (Iteration)

Burndown-Charts dienen der Visualisierung bereits geleisteter und noch verbleibender Arbeit einer Iteration.

Ein Burndown-Chart erfasst auf der x-Achse den Zeitverlauf (in Tagen) und auf der y-Achse die Anzahl der nicht erledigten Tasks, so dass die Kurve sich entlang der Zeit nach unten entwickelt.

Abbildung 8: Burndown Chart (Iteration)

Abbildung 9: Burnup Chart (Iteration)

Das Chart wird vor allem in agilen Projekten eingesetzt, ist aber grundsätzlich auch in anderen Vorgehensweisen verwendbar.

Das Chart soll dazu dienen, die Erreichung des Iterations-Ziels besser abschätzen zu können. Es sagt jedoch nur etwas über die Abarbeitung der einzelnen Aufgaben aus. Die im Product Backlog festgehaltenen User Stories bleiben hier unberücksichtigt.

Vorteil dieser Darstellung: Beim Burndown-Chart wird eine Scopeerweiterung durch einen Anstieg des tatsächlichen Restaufwands offenbar.

Task Board

Auf einem Task Board werden die Tasks aufgelistet, die notwendig sind um User Stories innerhalb einer Iteration zu erledigen.
Die Tasks werden entsprechend der Priorität der User Stories absteigend am Task Board sortiert.
Die Tasks werden anhand der Abarbeitung geteilt. Die minimale Aufteilung ist „ToDo“, "In Bearbeitung" und "Fertig".

Denkbar wäre eine Zerlegung von "In Bearbeitung" in "Entwicklung" und "Test".

Das Task Board wird zu den Daily Standings aktualisiert.

Abbildung 10: Task Board

Impressum / Mitwirkende

• Volker Ikenmeyer
• Andreas Kiefer
• Diana Schmeiser
• Ilja Brest
• Jens Bohl
• Rabih Hamadeh
• Johannes Hohenbichler
• MW
• Patrick Pospiech
• Dorothea Uchtmann
• Andriy Panchenko
• Thorsten Roessel