Im dritten Teil der Blog-Serie über einen agilen Proof of Concept möchte ich eine Frage beantworten, die sich jedes agile Projekt immer wieder stellt: Wie schneidet man die Backlog Items / User Stories, so dass sie innerhalb eines Sprint realisiert werden können?
User-Story-Chirurgie
Neben der schieren Größe gibt es noch andere Gründe, um eine User Story in kleinere Geschichten zu zerschneiden. So hatten wir in unserem Proof of Concept mehrfach die Situation, dass Teilaspekte der User Story mit den Bordmitteln des untersuchten Portalsystems erfüllt werden konnten, während andere Aspekte einen größeren Anpassungsaufwand bedeutet hätten. Oft beschreiben die Product Owner und Anwender in den User Stories ihre Maximalforderung – nicht selten in dem Wissen, dass sie ohnehin nur einen Teil ihrer Anforderungen realisiert bekommen, und deshalb lieber mehr fordern als unbedingt nötig. Die Kunst besteht nun darin, gemeinsam mit dem Product Owner eine fachlich und technisch sinnvolle Zergliederung dieser User Stories zu finden. In unserem Fall machten wir aus einer User Story zwei neue: Eine, die den mit Portal-Bordmitteln realisierbaren Funktionsumfang beschrieb, und eine zweite, die alle darüber hinaus gehenden Anforderungen beinhaltete. Die erste User Story setzten wir im Rahmen des Proof of Concept um, während wir die „Extended Version“ in der Regel nur mit einer Größenschätzung versahen (Variante 2 unserer Definition of Done). In mehreren Fällen waren die Produktverantwortlichen mit der Bordmittel-Variante so zufrieden, dass sie auf die „Extended Version“ verzichteten. Diesen Effekt, dass das Aufteilen der User Stories in einer schlankeren und in der Folge besser und günstiger wartbaren Lösung resultierte, haben wir auch in anderen agilen Projekten beobachten können.
Unserer Aufteilung der User Stories in Basisfunktionen (die mit Bordmitteln oder wenig Aufwand realisiert werden können) und erweiterten Funktionen haben Koen van Exem und Walter Hesius in einem Vortrag auf den XP Days Benelux 2007 den Namen „Dimensional Planning“ gegeben.
Dimensional Planning
Aus dem klassischen Projektmanagement kennt man drei Einflussfaktoren, die auf ein Projekt einwirken und in einer gegenseitigen Abhängigkeit stehen:
- Zeit: Ist oft das knappste Gut. Kaum ein Projekt, das ohne einen (angeblich unter keinen Umständen verschiebbaren) Zieltermin auskommt.
- Menschen und Ressourcen: „Je mehr Entwickler, desto schneller das Projekt.“ Dass diese einfache Formel nur bedingt gilt, lässt sich beispielsweise aus dem Brookschen Gesetz ableiten. Demnach steigt der Kommunikationsaufwand mit zunehmender Anzahl an Personen quadratisch an. Deshalb sind die meisten Teams in agilen Projekten recht klein (2-9 Personen). Temporär hinzugezogene Experten müssen zur rechten Zeit verfügbar sein, um den Projektverlauf nicht zu entschleunigen. Auch haben knappe, inadäquate oder zu spät verfügbare Ressourcen (z.B. Projekträume, technische Infrastruktur) haben einen negativen Einfluss auf ein Projekt.
- Projektumfang: Sind die beiden erstgenannten Faktoren fest vorgegeben, so bleibt als Steuergröße der Projektumfang. Werden weniger Anforderungen realisiert als ursprünglich vorgesehen, so stellt sich die Frage, welche Anforderungen weggelassen werden sollen/dürfen. In agilen Projekten ist diese Frage vergleichsweise einfach durch einen Blick auf das Product Backlog zu beantworten: Das Backlog wird von unten gekappt, weil die Backlog Items nach absteigender Priorität sortiert sind.
Anstatt jedoch ganze Anforderungen von der Projektbildfläche verschwinden zu lassen, bringen van Exem und Hesius eine vierte Steuergröße ins Spiel: Die Tiefe (depth) eines Backlog Items. Als Metapher verwenden sie den Straßenbau. Um von A nach B zu gelangen, kann man eine Straße bauen. Man erreicht das Ziel unabhängig davon, wie diese Straße ausgestaltet ist – allerdings unterschiedlich schnell und komfortabel:
- Ein Feldweg (dirt road) steht für den manuellen Workaround, mit dem man eine Anforderung schnell und pragmatisch umsetzen kann; die Bedienung der Funktion ist jedoch oft manuell und aufwendig.
- Die Kopfsteinpflasterstraße (cobblestone road) bezeichnet eine minimalistische Lösung, die zwar handwerklich sauber umgesetzt ist, bei deren Anwendung es jedoch – bildlich gesprochen – immer noch ganz schön ruckelt.
- Eine vernünftige Implementierung wird durch die asphaltierte Straße (asphalted road) symbolisiert. Hier hat der Anwender das Gefühl, dass seine Anforderung angemessen realisiert worden ist.
- Die Autobahn (highway) stellt schließlich die Goldrandlösung dar, die gekennzeichnet ist durch ein hohes Maß an Komfort und schnelle Bedienbarkeit. Technisch ist dies in fast allen Fällen die aufwendigste Lösung.
Wie sich dieses Modell in der Praxis anwenden lässt, soll ein kleines Beispiel zeigen. Für das Online-Reservierungssystem einer Hotelkette muss ein Hotel-Finder implementiert werden, bei dem der Benutzer durch Auswahl eines Landes und einer Stadt alle dortigen Hotels angezeigt bekommt. Die fachliche Anforderung „Pflege der entsprechenden Geoinformationen“ wurde in einer User Story beschrieben, für die im Projekt nacheinander vier verschieden „tiefe“ Implementierungen realisiert werden:
- Feldweg: Die Daten werden manuell in einer XML-Datei mit Hilfe eines einfachen Texteditors gepflegt.
- Kopfsteinpflasterstraße: Zur XML-Struktur wurde ein XML-Schema definiert. Die Daten werden manuell in einem XML-Editor gepflegt, der mit Hilfe des XML-Schemas eine syntaktische Validierung der XML-Daten durchführen kann.
- Asphaltierte Straße: Die Geoinformationen werden in einer Excel-Tabelle gepflegt, aus der automatisch die XML-Datei generiert werden kann. Bei der Generierung werden die Rohdaten aus Excel automatisch validiert.
- Autobahn: Die Geoinformationen werden in einer Webapplikation mit Google-Maps-Integration interaktiv erfasst.
Vier Lösungen – ein Ziel. Beginnt man mit der Feldweg-Implementierung, so gibt man den Anwendern die Möglichkeit, erste Erfahrungen mit dieser Funktion zu sammeln. Das kann Auswirkungen auf die Definition der weiteren Ausbaustufen haben – oder auch dazu führen, dass es keine weiteren Ausbaustufen gibt, weil die Anwender mit der Lösung in ihrer existierenden Form zufrieden sind. Dieses „Dimensional Planning“ genannte Strukturierungskonzept fügt sich bestens in das iterative Verfeinerungskonzept der Backlog Items ein. Innerhalb einer Iteration kann es dazu genutzt werden, um zunächst alle User Stories in einer einfachen Implementierung (Feldweg oder Kopfsteinpflaster) umzusetzen. Danach (aber immer noch in der selben Iteration) wird gemeinsam mit dem Product Owner und den Anwendern entschieden, welche User Stories zur asphaltierten Straße ausgebaut werden sollen.
Man kann die Dimension auch in die Definition der Backlog Items aufnehmen. Aus einer User Story werden damit bis zu vier Backlog Items – je eine pro Ausbaustufe. Der Product Owner kann diese dann auf verschiedene Iterationen verteilen (oder aber einzelne Ausbaustufen streichen). Die Tiefe gibt allerdings eine Abhängigkeit der Backlog Items vor – man wird wohl kaum mit einer Autobahn beginnen und diese später zum Feldweg zurückbauen.
Damit endet diese Blog-Serie über einen Proof of Concept mit Scrum. Sie haben gesehen, dass Scrum (stellvertretend für alle agilen Vorgehensweisen) nicht nur in der (Software-)Produktentwicklung eine gute Figur macht. Im besten „Inspect and Adapt“-Sinne haben wir das Rahmenwerk Scrum an die besonderen Bedingungen eines Proof of Concept angepasst und konnten erfolgreich in der geplanten Zeit unter Beweis stellen, dass das untersuchte Portalsystem unsere Anforderungen erfüllt. Dass die Anforderungen (sprich: das Product Backlog) während des Proof of Concept verändert werden konnten und durften, ist vor allem jenen Beobachtern und Projektbeteiligten positiv aufgefallen, die bisher noch keine Erfahrung mit agilen Projekten sammeln konnten.
Die anderen Artikel dieser Serie: