Die Feature Progression Map: Reporting-Vorlage in agilen Projekten

Gute Kommunikation ist alles – das gilt im Besonderen für große Softwareprojekte. Während die agilen Methoden sehr viel für die Kommunikation innerhalb des Teams tun, sind Stakeholder, die nicht Teil des Teams sind, meistens außen vor. Sie haben häufig keine Zeit, um an Reviews teilzunehmen oder sich mit den User-Stories zu beschäftigen.

Fehlende Transparenz stellt oft Projektfortschritt in Frage

Schnell kommt die Frage auf: „Was machen die da eigentlich?“. Und wenn das nicht strukturiert beantwortet wird, dann beginnen die Spekulationen und der Weg für Fehlinformationen ist geebnet. Schnell wird das Projekt von außen in Frage gestellt, obwohl schon wertvolle Teilergebnisse erreicht wurden. Hier ist vor allem Transparenz gefragt.

Im traditionellen Wasserfall-Ansatz wurde in der Regel nach Phasen reportet, die eine bestimmte Menge von Erzeugnissen (Artefakten) enthalten, beispielsweise ein Architekturentwurf, ein Datenbankmodell oder einfach Sourcecode. So kann man vom Fortschritt der einzelnen Phasen den Fortschritt des gesamten Projektes ablesen. Die Phasen waren jedem bekannt und so war auch das Vertrauen da: wenn die Meilensteine erfolgreich waren, war auch das Projekt erfolgreich.

Warum also dieses Konzept nicht auch für agile Projekte anwenden? Im traditionellen Wasserfall Ansatz laufen die Phasen über das gesamte Projekt

Jede dieser Phasen enthält sogenannte Artefakte bzw. Dokumente, die für das Endprodukt notwendig sind, damit es stabil und robust betrieben und weiterentwickelt werden kann.

Agil bedeutet, früh ein nutzbares Produkt zu haben

Beim agilen Ansatz wird das Gesamtprojekt nicht in Phasen, sondern in Sprints unterteilt, in denen Funktionen des Produktes – sogenannte Features – in Form von Epics oder User Stories umgesetzt werden. Ziel ist es, möglichst früh ein nutzbares Produkt zu haben. Es ist dabei explizit gefordert, das Produkt auf wenige Features zu reduzieren, die den höchsten Nutzen bringen (Minimum Viable Product).

Damit ein Feature produktiv einsetzbar ist, sind die gleichen Artefakte bzw. Dokumente notwendig wie beim Wasserfall Ansatz, nur eben begrenzt auf den Funktionsumfang des Features. Dadurch entstehen im agilen Projekt sehr viele Zustände, denn theoretisch kann sich jedes Feature in einer unterschiedlichen Phase befinden. Auf Außenstehende wirkt das oft sehr unübersichtlich und chaotisch und das macht misstrauisch.

Eine Feature Progression Map – Reporting-Vorlage –  schafft die nötige Transparenz

Ein gutes Mittel, um diesem Zustand entgegenzuwirken ist, Transparenz für alle Beteiligten zu schaffen, z.B. in dem dieser Zustand auf einer Karte (engl. Map) dargestellt wird.

Dabei werden die Phasen und Artefakte in der X-Achse und die Features bzw. Funktionen auf der Y-Achse aufgetragen. Am besten realisiert man das in einer Excel-Datei, da hier ausreichend Platz in beide Dimensionen vorhanden ist. Zudem lassen sich noch zusätzliche Informationen je Feature ergänzen.

Um möglichst viel Transparenz zu geben, trägt man nun in den Kreuzungspunkt des Features und des Artefaktes eine Zahl zwischen 0 und 10 ein. Diese Zahl steht für den Reifegrad (bspw. von 0 – 100 Prozent) des Artefakts in Bezug auf das Feature. Da es oftmals Diskussionen darüber gibt, was ein Artefakt alles enthalten muss, damit es einen bestimmten Reifegrad hat, sollten pro Artefakt sogenannte Definitions of Done (DoD) formuliert werden, die erklären, was beispielsweise ein Reifegrad von 50 Prozent bedeutet.

Färbt man nun diese Zellen entsprechend ein (z.B. 0 = rot, 10 = grün), so ergibt sich eine grafische Vorstellung davon, wie fortgeschritten das Projekt in Summe ist.Bei den Artefakten kann nach den Phasen Design, Implementierung und Betrieb unterschieden werden.

Beispiele für Artefakte:

• Designartefakte: Anforderungsliste, Usecase, Funktionsmodell, Datenmodell, Prozessmodell, Testfälle, …
• Implementierungsartefakte: Sourcecode, automatisiertes Tests, Build-Skripte, …
• Betriebsartefakte: Installationsskripte, Umgebungskonfigurationen, Monitoringkonzept, Handbuch, Benutzerdokumentation, …

Für uns bedeutet Wasserfall und agil kein Widerspruch. Im Gegenteil: Wasserfall-Methoden können sehr gut helfen, auch in agilen Projekten mehr Transparenz zu schaffen. Denn Transparenz schafft Vertrauen und damit den nötigen Freiraum, sich vollständig inhaltlich auf das Projekt zu konzentrieren.

In unseren Projekten haben wir damit zahlreiche positive Erfahrungen gemacht.