Wie erstellt man eine User Story Map?
Die Methode des User Story Mappings soll den am Prozess der Softwareerstellung beteiligten Personen helfen, für den Anwender hilfreiche Software zu erstellen und dabei den Überblick über das große Ganze zu behalten. Wie wird nun ein solches User Story Mapping durchgeführt?
Von der Theorie zur Praxis
Im ersten Teil dieser kleinen Artikelreihe habe ich beschrieben, wie die vorgestellte Methode dabei unterstützen möchte, nützliche Software zu erstellen. In diesem Artikel zeige ich, wie das Mapping praktisch durchgeführt wird. Dabei gehe ich auf die Erstellung der zweidimensionalen Landkarte ein und erläutere, wie Versionen damit geplant werden können.
Wie entsteht eine Landkarte von User Storys?
Beim User Story Mapping geht es darum, einander Geschichten aus Nutzersicht zu erzählen und diese in einem Erzählfluss auf Karten sinnvoll anzuordnen. Hierbei kommt es darauf an, wirklich von Angesicht zu Angesicht miteinander zu sprechen – schließlich geht es hier immer um eine »Story«. Das eigentliche Format einer Story ist hierbei zweitrangig. Es sollten jene Personen das User Story Mapping durchführen, die später auch an die Umsetzung beteiligt sind.
Damit die Beteiligten das große Ganze im Blick haben, konzentrieren sie sich bei der Erzählung zunächst darauf, die Geschichte in der Breite zu erzählen und erst später in die Tiefe der Details einzusteigen. Es geht im ersten Schritt darum, die ganze Geschichte zu erzählen und sich nicht in Details zu verlieren.
Im Laufe dieser ersten Erzählung ordnen die Teilnehmer die Karten ganz natürlich an: Die Erzählung beginnt links und sie schreitet nach rechts fort, bis sie abgeschlossen ist. Diese Darstellung erinnert an das wandelnde Skelett von Alistair Cockburn. Hier sehen die Teilnehmer nun das Rückgrat dieses Skeletts.
Alle Teilnehmer haben nun durch diesen ersten Schritt ein Verständnis davon, wie die Software von Anfang bis Ende benutzt wird und wie sie dem Anwender hilft. Jetzt wird die Erzählung mit detaillierteren User Storys ausgeschmückt, die unter das Rückgrat gehängt werden. Hier wird nun der Erzählfluss verlassen und die Teilnehmer ergänzen die Landkarte der User Storys an passender Stelle. So wächst die Landkarte der User Storys nach unten und alle Anwesenden können sehen, wie sehr sie in die Tiefe gehen.
Während der vielen Unterhaltungen, die nun stattfinden, fällt den Teilnehmern vielleicht auf, das bestimmte Storys in irgendeiner Form zusammengehören. Diese thematisch zusammengehörende Storys werden zu Aktivitäten zusammengefasst. Die Aktivitäten werden auf Karten über dem Rückgrat dargestellt. Sie gliedern die Erzählung in größere Abschnitte.
Die so entstandene Landkarte kann nun verwendet werden, um Versionen zu planen.
Auf zur Versionsplanung!
Ähnlich einem eindimensionalen Backlog können sich die Teilnehmer nun darüber unterhalten, welche Storys aus ihrer Sicht wichtig sind, um dem Nutzer beim Lösen seiner Probleme zu helfen. Diese Karten werden dann unter den jeweiligen Aktivitäten höher gehängt – Wichtiges hängt oben, weniger Wichtiges unten. Und Unwichtiges wird hoffentlich entfernt und gar nicht erst für die Umsetzung vorgesehen.
Um nun Versionen zu planen, ziehen die Teilnehmer horizontale Linien durch die Landkarte und teilen sie so in Versionsbänder auf.
Damit dabei jeweils eine Version entsteht, die für den Anwender sinnvoll ist, ordnen die Teilnehmer die Karten in den Versionsbändern über den gesamten Erzählfluss sinnvoll an. Hierbei wird es mit Sicherheit angeregte Diskussionen darüber geben, welche Storys sinnvollerweise gemeinsam in einer Version umgesetzt werden, da sie einzeln nicht für den Anwender hilfreich sind.
Mit der Zeit entsteht so eine Landkarte von User Storys, die von Versionsbändern durchzogen ist, und sinnvoll geschnittene Versionen darstellt. Die Versionen ergeben aus Anwendersicht Sinn und die an der Umsetzung Beteiligten verstehen (zumindest jetzt) den Zusammenhang der einzelnen User Storys. Wenn diesen an der Umsetzung beteiligten Personen später etwas unklar ist, können sie stets auf diese Landkarte von User Storys zurückgreifen.
Zusammenfassung
Im ersten Teil der Artikelreihe haben wir die Methode »User Story Mapping« kennengelernt. Dieser Artikel erläutert, wie ein solches Mapping praktisch von beteiligten Personen durchgeführt wird. Dabei bin ich auch darauf eingegangen, wie mit dieser Methode sinnvoll Versionen geschnitten werden können. Im nächsten Teil dieser kleinen Serie werde ich »best practices« zum User Story Mapping beschreiben.
User Story Mapping Teil 1
In der agilen Software-Entwicklung wird oft die formale Korrektheit von User Storys über ihren eigentlichen Zweck gestellt: Die Beteiligten erzählen einander Geschichten aus Anwendersicht. Während der Umsetzung der Software verlieren Beteiligte zudem oft den Blick »auf’s große Ganze«. Die Methode »User Story Mapping« möchte helfen, diese Probleme zu beheben und durch die enstehende Software das Leben der Anwender verbessern.
Problem 1: Nicht erzählte formal korrekte User Storys
User Storys sind in der agilen Entwicklung ein beliebtes Mittel, um aus Nutzersicht gewünschte Funktionalitäten umzusetzender Softwaredarzustellen.
Oftmals konzentrieren sich die Verfasser dieser User Storys auf die formale Korrektheit: Das Wer-Was-Warum wird mit der Formel »Als Rolle möchte ich eine Funktion ausführen, um damit folgenden Mehrwert zu schaffen« beschrieben.
Dabei sehen die Beteiligten die User Storys oft als Ergebnis (und damit Ende) der Konversation, das auf virtuelle oder echte Karten gebannt wird.
Die User Storys sollten aber vielmehr der Beginn laufender Unterhaltungen der an der Umsetzung beteiligten Personen sein.
Problem 2: Das Backlog als eindimensionale Sicht
Zur Planung der Umsetzung setzt der Product Owner in der Regel ein priorisiertes Backlog ein. Es ist eindimensional und gibt die Reihenfolge der Umsetzung vor. Diese Priorisierung von Storys reißt diese inhaltlich zusammen gehörenden Funktionalitäten zeitlich auseinander.
Die Beteiligten betrachten User Storys damit aus ihrem Kontext herausgelöst. Als Folge vermissen sie den Blick »auf’s große Ganze« und verlieren die Bedürfnisse des Benutzers aus den Augen.
Das User Story Mapping ist ein Werkzeug, um diese Probleme zu lösen und damit Software zu entwickeln, die die Probleme der Anwender löst.
Lösung: Die zweidimensionale Landkarte
Der Name des User Story Mappings deutet an, dass Storys auf einer Karte angeordnet werden. Diese Karte hat anders als das Backlog nicht nur eine Tiefe, sondern auch eine Breite.
Fachexperten, Entwickler und andere interessierte Parteien ermitteln die benötigte Funktionalität durch Erzählungen, wie Anwender handeln. Aus Sicht des Benutzers wird ein Ablauf erzählt.
Hierbei konzentrieren sie sich zunächst auf die Breite, um die Geschichte vom Anfang bis zum Ende zu erzählen. Der Erzählfluss wird dabei auf nebeneinander angeordneten Karten dargestellt. In anschließenden Diskussionen wird die Erzählung in die Tiefe ergänzt.
Die entstehenden Karten sind nur der Ausgangspunkt von Unterhaltungen: Sie werden laufend in die Hand genommen, ergänzt und bewegt.
Die dargestellte Erzählung ist ein beispielhafter Ablauf, der nur /eine/ mögliche Benutzung der Software darstellt. Die so entstandene Landkarte dient den Beteiligten als Hilfestellung und Orientierung während der Entwicklung.
Und wie erstellen wir nun eine solche Landkarte?
In diesem Artikel habe ich einen kurzen Überblick darüber gegeben, was das User Story Mapping ist und wofür es eingesetzt werden kann.
Im nächsten Teil einer kleinen Artikelreihe zeige ich, wie eine solche User Story Map aufgebaut werden kann und wie man damit Releases plant.
Weiterlesen
Permalink: /2021-01-28-user-story-mapping-teil1
Frohes Neues Jahr 2021
Das in vielerlei Hinsicht ungewöhnliche Jahr 2020 ist vorbei. Wir wünschen allen treuen und neuen Leser*innen unseres Blogs ein frohes neues Jahr. Wir hoffen, dass Sie gut durch das vergangene Jahr gekommen sind und dass 2021 besser wird.
Trotz der vielen Einschränkungen waren wir nicht untätig. Erstmal ein paar Daten:
- Wir haben 33 Releases von unseren CPAN-Modulen gemacht, darunter auch neue Module wie CPANfile::Parse::PPI und Markdown::Table
- Wir haben 40 Blogposts geschrieben
- 29 hier bei perl-academy.de
- 11 bei feature-addons.de
- Einen Artikel für die iX haben wir beigesteuert
- Wir haben sechs Schulungen (vier längerfristige Schulungen, zwei Sonderschulungen für den Deutschen Perl-/Raku-Workshop) konzipiert
- Wir waren beim Deutschen Perl-/Raku-Workshop 2020 in Erlangen
- Die ersten Addons wurden von der ((OTRS)) Community Edition auf OTOBO portiert
- Für einige freie Addons für die ((OTRS)) Community Edition gab es neue Versionen
- etliche Perl-Projekte wurden erfolgreich abgearbeitet
- und vieles mehr.
Wir möchten uns bei all unseren Kunden und Freunden bedanken. Nur mit Ihnen/Euch konnte das Jahr so erfolgreich abgeschlossen werden. Wir haben viele Ideen bekommen, die wir größtenteils umsetzen konnten.
Wir hoffen, dass der Deutsche Perl-/Raku-Workshop 2021 in Leipzig auch offline stattfinden kann. Dann werden auch wir unsere Schulungen wie geplant abhalten können. Auf dem Workshop werden wir wahrscheinlich ein paar Vorträge halten. Sobald die Organisatoren das Programm veröffentlichen werden wir uns auf diesem Kanal melden.
Auch für die geplanten anderen Schulungen planen wir zweigleisig – sowohl als Präsenzveranstaltung als auch in einer Online-Variante.
Wir wünschen Ihnen ein erfolgreiches Jahr 2021 und freuen uns auf ein spannendes Jahr.
Permalink: /2021-01-01-frohes-neues-jahr
Teaser: Gitlab und Perl
Perl-Schulungen 2021
Nachdem wir uns das Jahr 2020 Zeit genommen haben, um die Perl-Academy etwas umzubauen (mit neuem Design, der Einführung dieses Blogs, mit Gregor als zusätzlicher Trainer, ...), wollen wir heute unseren Plan für 2021 vorstellen.
Wir werden wenige feste Termine für offene Schulungen haben. Wir wollen mehr Firmenschulungen anbieten und offene Schulungen zusätzlich planen, wenn sich Interessenten melden.
Unsere Schulungsthemen werden wir am Lebenszyklus einer Anwendung ausrichten. Auch in agilen Umgebungen hat man immer wieder den Lebenszyklus in klein. Momentan haben wir vier Themen geplant:
Einsteigen werden wir mit User Story Mapping
. Kein originäres Perl-Thema, aber eine ganz praktische Vorgehensweise, um eine Anwendung aus Sicht des Benutzers zu planen.
Die mit User Story Mapping
geplante Software werden wir mit Mojolicious umsetzen. Dabei werden wir mit einer kleinen Version anfangen um die Grundlagen von Mojolicious kennenzulernen. Anschließend werden wir die Anwendung wachsen lassen, um die weitergehenden Fähigkeiten von Mojolicious nutzen zu können.
Natürlich muss man nicht erst die User-Story-Mapping Schulung besucht haben, um an der Mojolicious-Schulung teilzunehmen.
Das Thema Sicherheit in Perl-Anwendungen
spielt natürlich auch bei Mojolicious-Anwendungen ein Thema. Wir haben eine eigene Schulung daraus gemacht, um dem Ganzen genügend Raum zu geben und uns nicht auf Mojolicious zu beschränken.
Als viertes Thema bieten wir Gitlab und Perl
an. Die Versionsverwaltung begleitet die Anwendung ein Leben lang. Wir zeigen, was man abseits der reinen Versionsverwaltung mit Gitlab machen kann – von Continuous Integration
bis zum Ausliefern der Anwendung.
Interesse an einer der Schulungen? Dann melden Sie sich bei uns!
Permalink: /2020-12-07-schulungen-2021
Perl-Schulungen vor dem Deutschen Perl-/Raku-Workshop 2021 in Leipzig
Auch während der aktuell hohen Infektionszahlen in der Corona-Pandemie schauen wir nach vorne. Nach aktuellem Stand findet der Deutsche Perl-/Raku-Workshop 2021 Ende März in Leipzig statt (sollte die Corona-Situation das nicht hergeben, wird da mit Sicherheit reagiert).
Wir wollen den Workshop zum Anlass nehmen, am Tag vorher (23. März 2021) zwei Halbtagesschulungen anzubieten:
- Gitlab und Perl
- REST-APIs mit Mojolicious umsetzen
Den Tag beginnen wird Gregor mit Gitlab und Perl
. In dem Kurs, der von 08:00 Uhr bis 12:00 Uhr stattfinden wird, geht es um die Entwicklung von Perl-Distributionen mit Hilfe der Plattform Gitlab. Gregor wird anhand einer CPAN-Distribution kurz die hierfür relevanten integrierten Komponenten der Plattform vorstellen und insbesondere auf die continuous integration eingehen. Ein Schwerpunkt liegt hier auf der schnellen Rückmeldung an Entwickler nach einem Commit.
Am Nachmittag (13:30 Uhr bis 17:30 Uhr) geht es dann um REST-APIs mit Mojolicious. Ich werde hierbei kurz auf REST an sich eingehen, bevor eine Schnittstelle definiert und dann als Mojolicious-Anwendung mit Leben gefüllt wird. Dabei werden dann auch Themen wie Sicherheit etc. angesprochen. Zum Abschluss wird die Schnittstelle noch getestet.
Als Veranstaltungsort ist das Hotel Michaelis geplant und die Teilnehmerzahl ist auf 10 Personen pro Schulung beschränkt.
Wer Interesse an einer der Schulungen hat, kann sich gerne bei uns melden. Die Teilnahme an einer Schulung kostet 200,00 € netto (238,00 € inkl. MwSt), ein Kombiticket für beide Schulungen kostet 350,00 € netto (416,50 € inkl. MwSt).
Wir werden natürlich die Entwicklungen bzgl. Corona weiter im Auge behalten. Sollte eine Präsenzveranstaltung nicht möglich sein, werden wir die Schulungen als Online-Veranstaltung anbieten.
Permalink: /2020-11-10-gpw-schulungen