Nachdem im ersten Teil dieser Blog-Serie die Definition of Done im Mittelpunkt gestanden hatte, möchte ich heute eine Eigenkreation des Proof-of-Concept-Projektteams vorstellen: Der Topic Tank. In dieses virtuelle Gefäß werden alle User Stories einer bestimmten Kategorie „eingekippt“.
Sechs solcher Topic Tanks haben wir für die Untersuchung des Portalsystems definiert:
- Content-Management-System
- Applikationsintegration
- Design
- Benutzerberechtigung und Content-Publikation
- Content-Migration
- Portaladministration und -betrieb
Durch die Verteilung der User Stories auf diese Topic Tanks bekommen wir ein Gefühl dafür, wie stark die einzelnen Themen durch User Stories repräsentiert sind. Außerdem können wir zu Beginn (oder am Ende) eines jeden Sprint sehen, ob wir die sechs Themenbereiche gleichmäßig berücksichtigt haben. Damit unterscheidet sich unser Vorgehen vom „klassisch agilen“ Softwareprojekt, in dem einzelne Funktionen komplett über alle technischen Schichten umgesetzt werden. Wie auch schon bei der Beschreibung der Definition of Done erwähnt, geht unser Blick mehr in die Breite (Abdeckungsgrad) als in die Tiefe (Fertigungsqualität). Schließlich wollen wir am Ende des Proof of Concept eine Bewertung des untersuchten Portalsystems hinsichtlich aller wichtigen (d.h. hoch priorisierten) Anforderungen abgeben können. Nehmen wir beispielsweise das Thema „Design“: Anstatt alle Inhaltselemente des Design Guide pixelgenau umzusetzen, beschränken wir uns darauf, den Seitenrahmen mit den Bordmitteln des Portalsystems zu visualisieren und ausgewählte Seitenlayouts umzusetzen. Wenn wir das erreicht haben, dann ist die Umsetzung der anderen Seitenlayouts sowie der Feinschliff am HTML-Gerüst und den CSS-Definitionen vor allem Fleißarbeit – und deshalb keine Aufgabe für einen Proof of Concept.
In den Sprint Reviews haben wir festgestellt, dass die Topic Tanks dem Auftraggeber, aber auch den Vertretern der Fachbereiche einen schnellen Überblick über den Projektstatus bieten, weil sie sowohl die zentralen Themen des Proof of Concept als auch den Abdeckungsgrad dieser Themen anschaulich darstellen. Eine kleine Schwäche hat dieses Konzept allerdings: Da das Product Backlog lebt, kann sich der Füllgrad eines Topic Tank negativ entwickeln – nämlich dann, wenn diesem Tank neue, noch nicht erledigte User Stories zugerechnet werden. Deshalb betrachten wir nicht nur den aktuellen Füllstand, sondern vergleichen diesen mit dem Füllstand aus dem vergangenen Sprint. Eine andere Visualisierungsvariante haben wir im letzten Sprint verwendet. Es galt darzustellen, dass wir eine User Story aus einem Topic Tank zugunsten einer neuen User Story aus einem anderen Topic Tank nicht realisiert haben. Die Lösung: Ein Topic Tank hat einen Füllstand von 110%, und der andere ist nur zu 90% gefüllt. In Summe haben wir unser Ziel erreicht.
Die anderen Artikel dieser Serie: