User Story Mapping

Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung

Jeff Patton

Diese Publikation zitieren

Jeff Patton, User Story Mapping (2015), O'Reilly Verlag, Heidelberg, ISBN: 9783958750685

4198
Accesses
41
Quotes

Beschreibung / Abstract

"User Story Mapping" ist in den USA längst ein Bestseller. Die von Jeff Patton entwickelte Methode knüpft an bewährte Ansätze aus der Agilen Entwicklung an und erweitert sie. Die Idee: Die Produktentwicklung wird detailliert am Arbeitsfluss der Nutzer ausgerichtet und in Story Maps kontinuierlich dokumentiert und illustriert. Dadurch entsteht im gesamten Team - bei Entwicklern, Designern und beim Auftraggeber - ein deutlich verbessertes gemeinsames Verständnis vom Gesamtprozess und vom zu entwickelnden Produkt. Gleichzeitig wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder gar ein Gesamtprodukt zu entwickeln, das dem Nutzer nicht hilft.

Inhaltsverzeichnis

  • BEGINN
  • Inhalt
  • Widmung
  • Vorwort
  • Vorwort von Martin Fowler
  • Vorwort von Alan Cooper
  • Vorwort von Marty Cagan
  • Über dieses Buch
  • Wieso ich?
  • Wenn du Schwierigkeiten mit Stories hast, ist dieses Buch für genau Dich
  • Wer sollte dieses Buch lesen?
  • Ein paar Konventionen in diesem Buch
  • Wie dieses Buch aufgebaut ist
  • Hier geht†™s los
  • Stille Post
  • Gemeinsames Verständnis ist erschreckend einfach zu erreichen
  • Vergesst perfekte Dokumentation
  • Gute Dokumente sind wie Urlaubsfotos
  • Dokumentiert, um euch zu erinnern
  • Über das Richtige reden
  • Jetzt und später
  • Es geht nicht um Software
  • Okay, es geht nicht nur um Menschen
  • Produziert weniger
  • A wie Anforderungskatalog
  • Das ist alles
  • Kapitel 1 – Das große Ganze
  • Das Wort mit »A«
  • Stories erzählen, nicht Geschichten schreiben
  • Die ganze Geschichte erzählen
  • Gary und die Tragödie des flachen Backlogs
  • Talk and Doc
  • Umreißt eure Idee
  • Beschreibt eure Kunden und User
  • Erzähl die Stories deiner User
  • Details und Möglichkeiten erforschen
  • Kapitel 2 – Planen, (um) weniger zu produzieren
  • Mapping hilft großen Gruppen, gemeinsames Verständnis herzustellen.
  • Mapping hilft euch, die Löcher in eurer Geschichte zu entdecken
  • Es ist immer zu viel (zu tun)
  • Definiert das Minimum für ein Minimum Viable Product Release
  • Definiert eine Release Roadmap
  • Priorisiert Outcomes, nicht Features
  • Es ist Magie – wirklich.
  • Die Sache mit dem MVP
  • Das neue MVP ist gar kein Produkt!
  • Kapitel 3 – Planen, (um) schneller zu lernen
  • Diskutiert die Chancen
  • Validiert das Problem
  • Benutzt Prototypen, um etwas zu lernen
  • Was User Wollen
  • Lernt aus euren Builds
  • Iteriert bis zum MVP
  • Wie man es falsch macht
  • Validiertes Lernen
  • Minimiert eure Experimente. Wirklich.
  • Zusammenfassung
  • Kapitel 4 – Planen, (um) rechtzeitig fertig zu werden
  • Redet mit dem Team
  • Die Kunst des gekonnten Schätzens
  • Plant, Stück für Stück zu produzieren
  • Macht nicht aus jedem Slice ein Release
  • Das andere Geheminis gekonnter Schätzungen
  • Managt euer Budget
  • Iterativ UND inkrementell
  • Strategien: Eröffnungs-, Mittel- und Endspiel
  • Markiert eure Entwicklungsstrategie in einer Map.
  • Es geht um das Risiko.
  • Wie geht es weiter?
  • Kapitel 5 – Ihr wisst schon, wie es geht
  • 1. Schreibt eure Story auf – einen Schritt nach dem anderen
  • 2. Organisiert eure Story
  • 3. Entdeckt alternative Stories
  • 4. Komprimiert die Map und erzeugt einen Backbone
  • 5. Gruppiert Tasks, die euch helfen, einen bestimmten Outcome zu erzielen
  • Fertig! Ihr habt alle wichtigen Konzepte gelernt!
  • Do Try This at Home (oder bei der Arbeit)
  • Die Map dreht sich ums Jetzt, nicht ums Später
  • Probiert es wirklich aus
  • Mit Software ist es schwieriger
  • Die Map ist nur der Anfang
  • Kapitel 6 – Die wahre Geschichte der Stories
  • Kents verstörend einfache Idee
  • Einfach ist nicht leicht
  • Ron Jeffries und die 3 Cs
  • Worte und Bilder
  • Das war†™s schon.
  • Kapitel 7 – Bessere Stories erzählen
  • Connextras Tolles Template
  • Template-Zombies und der Schneepflug
  • Checkliste: Worüber ihr euch wirklich unterhalten solltet
  • Macht Urlaubsfotos
  • Das ist eine Menge Zeug
  • Kapitel 8 – Nicht alles steht auf der Karte
  • Unterschiedliche Leute, unterschiedliche Konversationen
  • Wir brauchen eine größere Karteikarte
  • Strahler und Kühltruhen
  • Dafür ist das Werkzeug nicht gedacht
  • Kapitel 9 – Die Karteikarte ist nur der Anfang
  • Habt eine klare Vorstellung davon, was ihr konstruiert
  • Entwickelt eine mündliche Tradition des Geschichtenerzählens
  • Inspiziert das Ergebnis eurer Arbeit
  • Es geht nicht um Euch
  • Entwickelt, um zu lernen.
  • Es ist nicht immer Software
  • Plant, zu lernen, und lernt, zu planen
  • Kapitel 10 – Wir backen uns eine Story
  • Ein Rezept kreieren
  • Den großen Kuchen aufteilen
  • Kapitel 11 – Steine brechen
  • Auf die Größe kommt es immer an
  • Stories sind wie Steine
  • &klein;Epen sind große Steine, die manchmal benutzt werden, um Menschen damit zu schlagen
  • Themen organisieren Story-Gruppen
  • Vergesst diese Begriffe und konzentriert euch darauf, Stories zu erzählen
  • Beginnt mit Chancen (Opportunities)
  • Entdeckt eine Minimum Viable Solution
  • Vertieft euch in die Details jeder einzelnen Story im Delivery-Prozess
  • Redet weiter, während ihr produziert
  • Evaluiert jedes Stück
  • Evaluiert mit Usern und Kunden
  • Evaluiert mit Business-Stakeholdern
  • Evaluiert auch nach dem Release weiter
  • Kapitel 12 – Steinebrecher
  • Wertvoll – benutzbar – realisierbar
  • Ein Discovery-Team benötigt für den Erfolg viele andere Personen
  • Die drei Amigos
  • Produkt-Owner als Produzenten
  • Es ist kompliziert
  • Kapitel 13 – Beginnt mit Chancen
  • Führt Konversationen über Chancen
  • Tiefer graben, wegwerfen oder darüber nachdenken
  • Chance sollte kein Euphemismus sein
  • Story Mapping und Chancen (Opportunities)
  • Seid wählerisch
  • Kapitel 14 – Mit Discovery gemeinsames Verständnis aufbauen
  • Bei Discovery geht es nicht um das Schreiben von Software
  • Vier essenzielle Schritte der Discovery
  • Discovery-Aktivitäten, Diskussionen und Artefakte
  • Discovery dient der Herstellung von gemeinsamem Verständnis.
  • Kapitel 15 – User-Discovery für validiertes Lernen
  • Wir liegen meistens falsch
  • Die schlechte alte Zeit
  • Einfühlen, Fokussieren, Ideen Sammeln, Prototypen Bauen, Testen
  • Wie man etwas Gutes versaut
  • Kurze Zyklen validierten Lernens
  • Wie Lean Startup Thinking das Produktdesign verändert
  • Stories und Story Maps?
  • Kapitel 16 – Verfeinern, Definieren, Produzieren
  • Karteikarten, Konversationen, mehr Karten, noch mehr Konversationen ...
  • Schneiden und Polieren
  • Der Story-Workshop
  • Sprint- oder Iterationsplanung?
  • Menschenmengen kollaborieren nicht
  • Aufteilen und Ausdünnen
  • Benutzt eure Story Map während der Delivery
  • Benutzt eine Map, um Fortschritte zu visualisieren
  • Benutzt einfache Story Maps in Story-Workshops
  • Kapitel 17 – Stories sind genau genommen wie Asteroiden
  • Zerbrochene Steine wieder zusammenfügen
  • Übertreibt es nicht mit dem Mapping
  • Zerbrecht euch nicht den Kopf über Kleinkram
  • Kapitel 18 – Lernt aus jedem Build
  • Review im Team
  • Review mit anderen aus eurem Unternehmen
  • Genug
  • Lernt von Usern
  • Lernt aus euren Releases
  • Outcomes nach Zeitplan
  • Benutzt eine Map, um zu evaluieren, ob ihr bereit für den Release seid
  • Das Ende. Oder?
  • Danksagung
  • Literatur
  • Index
  • Über den Autor
  • Kolophon

Ähnliche Titel

    Mehr von diesem Autor