agile spezifikation
TRANSCRIPT
Traditionell Agil
Produktmanager, Projektmanager, Marketing Product Owner
Durch Prozess, Organisation vom Entwicklungsteam getrennt Mitglied des Scrum Teams
Marktforschung, Business-Analyse etc. vor der Produktentwicklung
Möglichst minimale Vision und schnelle Produktinkrements
„Eingefrorene“ Anforderungen Anforderungen entwickeln sich stetig weiter
Spätes Kundenfeedback Frühes und häufiges Feedback durch kleine Releases
Produktmanagement traditionell und agil2
Ziel agiler Produktdefinition
…ist es, im Gespräch mit dem gesamten Team
die minimalste Lösung („Output“) zu finden, die zum erwünschten Ergebnis („Outcome“) führt.
3
Warum User Stories?
• Platzhalter für Kommunikation
• Kein „Detail-Inventar“
• Produktfortschritt wird messbar
„Shared understanding beats shared documents.“
4
Produktvision
• Wer benutzt das Produkt?
• Welcher Bedarf wird gedeckt? Welcher Wert geschaffen?
• Was sind die kritischen Features? Wie wird das Produkt grob aussehen?
5
Was ist eine User Story?
Spezifikation nach IEEE 830
1. Das Produkt soll einen benzinbetriebenen Motor haben.
2. Das Produkt soll vier Räder haben.
2.1.Das Produkt soll auf jedem Rad einen Reifen haben.
3. Das Produkt soll ein Lenkrad haben.
4. Das Produkt soll eine Karosserie aus Stahl haben.
6
Was ist eine User Story?
User Story
Als Gärtner möchte ich einfach und schnell große Rasenflächen schneiden, um mehr Zeit für anspruchsvolle Arbeiten zu haben.
Template
7
Nutzerrollen
Sammeln (jede Rolle repräsentiert einen Nutzer)
Hierarchisch Ordnen
Verfeinern:
• Wie oft wird die Software benutzt?
• Welche Erfahrung hat der Nutzer mit Computern?
• Wofür verwendet der Nutzer die Software?
• …
8
Funktionen
Was wird benötigt?
• Featurebeschreibung aus Sicht der Nutzerrolle
• ohne Implementierungsdetails
• ohne Nebenszenarien
• in allgemeinverständlicher Sprache
9
Nutzerziele
Warum wird das benötigt?
• Fokus auf den Nutzer des Produkts
• Begründung aus dem Geschäftswert
10
Akzeptanztests
Was muss erfüllt werden, damit die Story fertig ist?
• für alle Beteiligten verständlich
• von außen verifizierbar
• detailliert genug, um einen Test zu erstellen
11
Funktionale Akzeptanztests
Ein Nutzer kann eine einfach Suche ausführen, die nach einem Wort oder Wortverbindungen sowohl in den Feldern Autor als auch Titel sucht, damit er möglichst schnell zum gesuchten Artikel kommt.
• Nach einem Wort suchen, das Teil eines Titels sein soll, aber nicht der Autor sein kann
• Nach einem Wort suchen, das wahrscheinlich der Autor, aber eher nicht der Titel sein kann
• Nach einem Wort suchen, das wahrscheinlich keines von beiden ist
12
Nicht-funktionale Akzeptanztests
Performanz-Constraint
Die allgemeine Suche muss in weniger als einer Sekunde antworten.
Akzeptanzkriterien
• 10.000 Transaktionen
• jede Transaktion überträgt 100 KB an Daten
• 99% schließen unter 1 Sek ab
13
INVEST Stories
Independent – keine Abhängigkeiten
Negotiable – jederzeit änderbar, bis zur Planung
Valuable – nützlich für den Endverbraucher
Estimatable – für Entwicklung abschätzbar
Small – in einem Zyklus umsetzbar
Testable – von außen testbar
14
Stilistische Kriterien
• aus Sicht eines einzelnen Nutzers schreiben
• im Aktiv schreiben
• wenn möglich, Kunden schreiben lassen
• nicht nummerieren
15
Aufteilen von Stories16
Als Enterprise-Nutzer möchte ich
eine Email verfassen
Als Enterprise-Nutzer möchte ich
einen Betreff eingeben
Als Enterprise-Nutzer möchte ich einen oder mehrere Empfänger angeben
Als Enterprise-Nutzer möchte ich
die Wichtigkeit setzen können
Als Enterprise-Nutzer möchte ich einen oder mehrere
Empfänger aus meinen Kontakten
wählen
Als Enterprise-Nutzer möchte ich einen Empfänger
eingeben
Mögliche Aufteilungen
• Datengrenzen – Arten von Daten, die die Story unterstützt
• Unterstütze Operationen – Arten von Operationen, die vorgenommen werden können
• Übergreifende Aspekte auslagern – Logging, Fehlerbehandlung, Sicherheit, Styling
• Performanz-Constraints auslagern – „Make it work, then make it faster“
17
In Iterationen aufteilen, nicht in Inkremente18
Abhängigkeiten zwischen Stories
• Zusammenfassen
• Gemeinsame Abhängigkeit in separate Story herausziehen
• Abhängigkeit durch Mehraufwand auflösen
19
Abhängigkeiten zwischen Teams
• Keine Komponententeams, sondern Feature-Teams
• Gemeinsame Bearbeitung in einem Sprint
• Last Resort: Pipelining
20
Wie kommen Details in die Story?
• Gespräch (und dessen Dokumentation)
• Aufteilung in kleinere Stories
• Akzeptanztests
• zusätzliche Artefakte (Design-Skizzen, UI-Richtlinie, Interaktionsdiagramm)
21
Der Weg durchs Backlog22
„Tiefes“ Backlog
Detailed Appropriately
Estimated
Emergent
Prioritized
23
Weiterführende Ansätze zur Strukturierung
• Gojko Adzic: Impact Mapping (Kurz-Einführung: https://prezi.com/fa4fpvhpkkcb/)
• Jeff Patton: User Story Mapping
24
Literatur / Quellen
Roman Pichler: Agiles Produktmanagement mit Scrum
Gojko Adzic: Impact Mapping
Mike Cohn: User Stories
Mike Cohn: Agile Estimation and Planning
Jeff Patton: User Story Mapping
Eric Ries: Lean Startup
25