Agile Spezifikation
•
2 gefällt mir•1,550 views
Wie kommunizieren Product Owner effektiv Anforderungen an ihr Team? Wie bildet man ein gemeinsames Produktverständnis? Wie bringt man notwendige Details unter?
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (18)
Ähnlich wie Agile Spezifikation
Ähnlich wie Agile Spezifikation (20)
Agile Spezifikation
- 1. 1 Agile Spezifikation Johannes Stiehler © duckman76 - fotolia.com
- 2. 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 agil 2
- 3. 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
- 4. Warum User Stories? • Platzhalter für Kommunikation • Kein „Detail-Inventar“ • Produktfortschritt wird messbar „Shared understanding beats shared documents.“ 4
- 5. Produktvision • Wer benutzt das Produkt? • Welcher Bedarf wird gedeckt? Welcher Wert geschaffen? • Was sind die kritischen Features? Wie wird das Produkt grob aussehen? 5
- 6. 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
- 7. 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
- 8. 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
- 9. Funktionen Was wird benötigt? • Featurebeschreibung aus Sicht der Nutzerrolle • ohne Implementierungsdetails • ohne Nebenszenarien • in allgemeinverständlicher Sprache 9
- 10. Nutzerziele Warum wird das benötigt? • Fokus auf den Nutzer des Produkts • Begründung aus dem Geschäftswert 10
- 11. 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
- 12. 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
- 13. 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
- 14. 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
- 15. Stilistische Kriterien • aus Sicht eines einzelnen Nutzers schreiben • im Aktiv schreiben • wenn möglich, Kunden schreiben lassen • nicht nummerieren 15
- 16. Aufteilen von Stories 16 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
- 17. 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
- 18. In Iterationen aufteilen, nicht in Inkremente 18
- 19. Abhängigkeiten zwischen Stories • Zusammenfassen • Gemeinsame Abhängigkeit in separate Story herausziehen • Abhängigkeit durch Mehraufwand auflösen 19
- 20. Abhängigkeiten zwischen Teams • Keine Komponententeams, sondern Feature-Teams • Gemeinsame Bearbeitung in einem Sprint • Last Resort: Pipelining 20
- 21. 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
- 22. Der Weg durchs Backlog 22
- 24. Weiterführende Ansätze zur Strukturierung • Gojko Adzic: Impact Mapping (Kurz-Einführung: https://prezi.com/fa4fpvhpkkcb/) • Jeff Patton: User Story Mapping 24
- 25. 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
- 26. Vielen Dank für Ihre Aufmerksamkeit johannes.stiehler@ideenpla.net 26