Kollaborativ, visuell, verständlich!
Die Anforderungen an eine Software werden durch den Einsatz immer neuerer Technologien, Endgeräte und Einsatzgebiet komplexer und unübersichtlicher. In der Anforderungsaufnahme wird versucht diese mehrdimensionalen Aspekte „eindimensional“ in einem Textdokument festzuhalten und mit den Interessenvertretern zu validieren. Dies führt in vielen Fällen zu Missverständnissen und und endet im Nachgang in einer Flut von „Request for Changes“. Doch wie kann diese Herausforderung einfach und erfolgreich gemeistert werden? Die Visualisierungstechnik einer Story Map widerspiegelt die Sprache des Benutzer und führt ihn entlang seiner Anforderungen. Im Zentrum steht das gemeinsame Verständnis zwischen dem Kunden und dem Softwarelieferanten was gebaut werden soll und warum. Die Story Map entsteht kollaborativ mit allen Interessenvertreter und fokussiert auf die Benutzer und deren Bedürfnisse.
6. - > +
„There‘s always more to build than we have
time or resources to build – always!“
Jeff Patton
7. ... und warum ist das wichtig für mich?
https://www.flickr.com/photos/wadem/2808468566
8. Das richtige Produkt zu bauen heisst ...
https://pixabay.com/de/lego-spielzeug-junge-bauen-286232/
... Features zu realisieren, die
wirklich Business Value liefern.
... eine gemeinsame Sprache/
Verständnis von Benutzer, Fach
und IT herzustellen.
Wer hat Kinder?
Unser Wissen und Erfahrungen wurde von noch nicht allzu langer Zeit nur via Geschichten weiter verbreitet.
Heute machen wir das leider viel zu oft über 1-Weg Kommunikation (Word Doku, Emails, ...)
Hase und Ente Spiel
# Theorie zu Impact Mapping
# Beispiele aus der Praxis
# Selber ein Bespiel erarbeiten
Gemeinsames Verständnis via Dokumente sind kein gemeinsames Verständnis.
Wir müssen aufhören perfekte Dokumente zu schreiben
By Jeff Patton, named in January 2005 “It’s all in how you slice it”
Geschichte
"We spend lots of time working with our customers. We work hard to understand their goals,
their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build
Tree:
Trunk: Goals / Desired benefits
Big Branches: Users
Small Branches + Twigs: Capabilities (Resourcen, Fähigkeiten) they need
Leaves: User stories Small enough to place into iterations
Then we we pull all the leaves off the tree…
… load them into a leaf bag (flat).
Finally, we cut the tree.
"That's what a flat backlog is to me. A bag of context-free mulch.“
Backlog is ok:
Priorized: From highest to lowest Business Value
The drawbacks
How to explain others what the system does?
What about the Big Picture
Consider: The development
Excellent Link: Patterns, Cheat Sheet und Map to cut Stories