User Story Mapping

Jeff Patton, Peter Economy
User Story Mapping
Discover the Whole Story, Build the Right Product

O'Reilly, 2014
XLIV + 276 Seiten, US-$ 34,99
ISBN 978-1-491-90490-9

Kent Beck führte als Erster zusammen mit XP die sogenannten User Stories ein. Formulierungen etwa in der Form "Als <Rolle> möchte ich <Feature> um <Ziel> zu erreichen". Kurz und prägnant – mit dem Ziel, schwergewichtige Anforderungsdokumente zu ersetzen. Denn letztere, und diese Auffassung bestätigt Jeff Patton, seien nicht nur schwer zu aktualisieren, sondern trotz vermeintlich klarer Formulierung immer noch interpretierbar, was zu unterschiedlichem Verständnis führe.

User Stories sind Geschichten. Und diese müssen in erster Linie erzählt und diskutiert werden. Das führt dann zu einem gemeinsamen Verständnis. Erst in zweiter Linie werden sie notiert. Zur Erinnerung: nicht zur Kommunikation von Anforderungen. Wer einfach nur User Stories aufschreibe und meine, damit können dann Entwickler loslegen, der macht nach Ansicht des Autors denselben Fehler wie traditionelle Verfahren. Das und andere Prinzipien erläutert Patton in einem Abschnitt "Read this first". Auf eine Einleitung, beginnend mit der arabischen Ziffer 1 verzichtet er, da seiner Meinung nach die meisten Leser eine Einleitung überlesen. Doch sein Lies-mich-erst-Teil befindet sich noch weiter vorn, im römisch nummerierten Teil, der insgesamt 44 Seiten umfasst – und dieser Teil fällt nach Meinung des Rezensenten eher dem Überlesen zum Opfer. Also aufgepasst. Der Teil ist wichtig!

Doch was ist User Story Mapping, und wozu ist es gut? Nun, der Autor berichtet von Entwicklern, die mit User Stories arbeiten: Viele kleine Geschichten, die jede für sich recht einfach umgesetzt werden kann – bis eine große Flickschusterei entsteht. Denn oftmals vermissen Entwickler das große Ganze, den Zusammenhang der Stories. Und hier setzt das Story Mapping ein. Die einzelnen Geschichten werden auf Haftetiketten oder Karteikärtchen notiert und dann zu einer großen (Übersichts-)Karte zusammengesetzt, wahlweise am Boden oder einer großen Wandfläche. Durch Umsortieren und Gruppieren von Stories wird die gesamte Geschichte in logischer Reihenfolge erzählt, werden Zusammenhänge, chronologische Abfolgen und mehr sichtbar.

Das Prinzip der Maps ist recht einfach und intuitiv. Dennoch, der Teufel liegt sprichwörtlich im Detail, und so benötigt auch die Kartografie von User Stories ein gewisses Maß an Erfahrung. Große, unhandliche Stories müssen zu gegebener Zeit in kleine, handlichere Brocken aufgeteilt werden. Zu viele kleine Stories sind andererseits auch zu größeren Geschichten zusammenzusetzen. Jeff Patton erläutert ausführlich, wann was Sinn macht, und bringt im hinteren Teil des Buchs als Vergleich das alte Asteroids-Spiel in Erinnerung: Große Asteroiden gleiten langsam durch die Gegend. Von seinem Raumschiff aus schießt der Spieler sie in kleinere Brocken, die dann schneller in verschiedene Richtungen fliegen, und nochmals in kleinere, schnellere. Erst diese lassen sich dann komplett aus dem Weg räumen. Zu viele schnelle, kleine Asteroiden führen zum Crash des Raumschiffs.

Und so ist es mit der Software: Große Probleme sind in eine Vielzahl einfacherer Probleme zu zerlegen, die sich dann einfacher lösen lassen. Aber nicht zu viele auf einmal, denn wer vor lauter Bäumen auf einmal den Wald nicht mehr sieht, steht eher auf verlorenem Posten. Der Vergleich mit dem alten Spiel ist sehr treffend gewählt, aber nicht der einzige. Das Buch enthält viele comic-artige Zeichnungen, farbige Fotos von der Arbeit an Story Maps mit einkopierten Erläuterungen, Berichten aus der Praxis und mehr. So lockert der Autor nicht nur sein Buch auf, sondern bietet dem Leser recht einprägsame Hilfestellungen. Dabei beschränkt sich das Buch nicht nur auf die Technik des Story Mapping, sondern bietet viele weitere Anregungen und Hintergründe für den Softwareentwicklungsprozess, angefangen von der Ideenfindung über die Umsetzung bis zum Einsatz.

Obwohl das Buch keine Zeile Code enthält, richtet es sich an Softwareentwickler, aber auch an Produktmanager (in Scrum Product Owner geannnt), Tester, Anwender und andere am Entwicklungsprozess beteiligte Personen. Jeff Patton verändert die Welt.

Michael Müller
ist als Bereichsleiter Softwareentwicklung der InEK GmbH verantwortlich für Projekte im Web-, Java- und .NET-Umfeld. Daneben betätigt er sich als freier Autor und verfasst Fachartikel zu diversen Entwicklungsthemen sowie Buchrezensionen. (ane)