User stories schreiben

651 Aufrufe

Veröffentlicht am

Anforderungen werden in der Agilen Entwicklung von Software in Form von User Stories festgehalten.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
651
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

User stories schreiben

  1. 1. User Stories schreiben
  2. 2. Was ist eine User-Story? Eine User-Story repräsentiert eine Anforderung. Sie ist in der Sprache des Kunden geschrieben. Gehört zur Agilen Entwicklung
  3. 3. Inhalt einer User-Story ● Eine Beschreibung der Anforderung in der Sprache des Kunden. ● Abnahmekriterien, welche erfüllt sein müssen, damit die Story als ausgeliefert gilt. ● Ein Konversationsverlauf, welcher die Details für die Implementierung klärt.
  4. 4. Beschreibungstext Als <Benutzerrolle> möchte ich <Funktionalität>, damit ich <Ziel>.
  5. 5. Beschreibungstext (Beispiel) Als Student möchte ich mich einloggen können, damit ich meine Noten anschauen kann.
  6. 6. Anforderung an die User-Story INVEST ● Independent (Unabhängig) ● Negotiable (Verhandelbar) ● Valuable to users or customers (Mehrwert) ● Estimatable (Schätzbar) ● Small (klein) ● Testable (Testbar)
  7. 7. Priorisierung ● Stories werden nach Mehrwert und Risiko priorisiert. ● Die Priorisierung bestimmt der Kunde (oder der Product-Owner).
  8. 8. Benutzerrollen The Simpsons ©20th Century Fox
  9. 9. Benutzerrollen identifizieren In einem Workshop: 1. Benutzertypen, die mit dem System interagieren, sammeln. 2. Gesammelte Typen gruppieren. 3. Aus den Gruppen die Rollen definieren.
  10. 10. Akzeptanzkriterien ● Dokumentieren Details einer Anforderung. ● Eine Story ist erst vollständig, wenn sie alle Akzeptanzkriterien erfüllt. ● Akzeptanzkriterien werden vor der Implementation geschrieben. ● Sollten vom Kunden (oder Product-Owner) geschrieben werden.
  11. 11. Stories sind verhandelbar ● Die genauen Details werden erst vor der Implementierung definiert. ● Dialog mit dem Kunden ist wichtig. ● Entscheidungen/Fragen sollen in der Story dokumentiert werden. ● Entscheidungen als Testfälle notieren.
  12. 12. Abhängige Stories Zum Beispiel: ● Ein Benutzer kann sich über Facebook einloggen. ● Ein Benutzer kann sich über Google einloggen. ● Ein Benutzer kann sich über Twitter einloggen.
  13. 13. Abhängige Stories ● Abhängige Stories in eine grössere, aber unabhängige Story zusammenfassen. ● Die grössere Story anders aufteilen.
  14. 14. Nichtfunktionale Anforderungen z.B. Maximale Antwortzeit Können als User-Story formuliert werden. Wichtiger ist aber eine verständliche Beschreibung.
  15. 15. Stories schätzen Stories sollten im Team geschätzt werden. Zeit für die Tests, Gespräche, Recherchen usw. müssen miteinberechnet werden. Stories werden in Storypunkten geschätzt.
  16. 16. Spike-Stories ● Nützlich bei Stories, bei denen der Aufwand nicht abschätzbar ist. ● Das Ziel der Spike-Story ist eine genauere Aufwandschätzung für eine andere Story.
  17. 17. Grosse Stories Stories, welche zu gross sind, werden im Sprint-Planning-Meting aufgeteilt. Die Stories werden zu einem Epic gruppiert.
  18. 18. Das Buch dazu Mike Cohn User Stories Applied Addison-Wesley Professional

×