agile spezifikation

1

Agile Spezifikation Johannes Stiehler

© duckman76 - fotolia.com

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

Vielen Dank für Ihre Aufmerksamkeit johannes.stiehler@ideenpla.net

26