Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
205 lines (146 sloc) 8.38 KB

User Stories

Was ist IEEE 830?

Software Requirements Specification


Was zeichnet geschriebene Anforderungen aus?

  • Die Anforderungen sind gut durchdacht, überprüft und bearbeitet werden - Es ist ein Prozess mit Benutzerfeedback
  • Permanente änderungen müssen gemacht werden können - Muss gepflegt werden -> Versionen der schriftlichen Anforderungen erstellen
  • Die Anforderungen sind einfach geteilt mit Gruppen und Leuten -> Tools wie Wiki sind perfekt dafür.
  • Die Anforderungen benötigen nicht so viel Zeit, produziert zu werden –> UI-Zeichnungen etc. sind nicht immer gut.
  • Die Anforderungen sind möglicherweise weniger wichtig oder überholt mit der Zeit -> Müssen gepflegt werden. Mehrere Versionen der geschriebenen Anforderungen erstellen
  • Die Anforderungen können einfach missverstanden werden -> Wenn sie nicht korrekt geschrieben wurden.

Was zeichnet mündlich kommunizierte Anforderungen aus?

  • sofortiges Feedback und Klärung von Problemen möglich
  • informationsaustausch
  • einfacher zu erklären und zu verstehen
  • einfacher an neue Informationen anzupassen, die zu der Zeit bekannt waren.
  • kann Ideen über Probleme und Möglichkeiten lösen
  • Aber: Wenn nichts aufgeschrieben wird geht vieles schnell wieder vergessen

Welche Prinzipien für den agilen Anforderungsprozess kennen Sie?

  • Aktive Beteiligung der Benutzer ist unabdingbar
  • Bewegliche Teams müssen befugt sein, Entscheidungen zu treffen
  • Anforderungen entstehen und entwickeln sich, wenn Software entwickelt wird.
  • Agile Anforderungen werden in kleinen, mundgerechten Stücken entwickelt
  • Genug ist genug - 80/20-Regel anwenden
  • Kooperation, Zusammenarbeit und Kommunikation zwischen allen Teammitglieder ist unerlässlich

Was ist eine User Story?

  • Eine kurze, schriftliche Beschreibung einer Funktionalität, die für einen Benutzer (oder Kunden) der Software von Nutzen ist.
  • «User Stories» beschreiben, was Nutzer wollen.
  • Balance zwischen Business Seite und Entwickler Seite ist sehr wichtig, sonst ist das Projekt gefährdet.

Was sind Akzeptanzkriterien, Akzeptanzbedingungen?

  • Akzeptanzkriterien werden vom Product Owner definiert und sagen, ab wann eine User Story als erledigt/erfüllt angeschaut wird
  • Akzeptanzbedingungen führen zu Akzeptanztests

Was ist Acceptance Testing?

Akzeptanz-Tests

  • Sie stellen sicher, dass die Stories erstellt worden sind, welche die Erwartungen des Kunden erfüllen
  • Werden auf der Rückseite der Story Card geschrieben
  • Sollten automatisiert werden

Welche Probleme sollen durch die User Stories gelöst werden?

  • Softwareanforderungen sind ein Kommunikationsproblem
  • Man versucht, die Stärken von mündlicher und schriftlicher Kommunikation zu verbinden.
  • Diejenigen, die die Software wollen, müssen mit denen kommunizieren, die sie erstellen werden

Wie lautet der Prozess zum sammeln von User Stories?

User Story Mapping (glaube ich)


Aus welchen Teilen besteht die User Story Card?

  • Karte: Schriftliche Beschreibung der User-Story zu Planungszwecken und zur Erinnerung
  • Konversation: Ein Abschnitt zum Erfassen weiterer Informationen zur User Story und Einzelheiten zu Konversationen
  • Bestätigung: Ein Abschnitt, in dem angegeben wird, welche Tests durchgeführt werden, um zu bestätigen, dass die User Story vollständig ist und wie erwartet funktioniert

User Story Card{ width=550px }


Wie ist eine User Story formuliert?

  • Als [ROLLE] möchte ich [ZIEL] damit [NUTZEN]
  • Bsp: Als Kunde (Rolle) möchte ich einen Beleg (Ziel) um zu Beweisen (Nutzen), dass ich die Parkgebühr entrichtet habe.

Welche Detailierungsgrade von Stories gibt es?

  • Theme (Eine Sammlung von verwandten Stories)
  • Epic (eine Grosse Story)
  • Story (User Stories)

Wie kann man User Stories bewerten?

  • Mit Story Points (Wie gross ist der Aufwand für User-Stories –> Wird geschätzt zwischen 1, 2, 3, 5 und 8 beispielsweise)
  • Risiko
  • Priorisierung

Was sind Themes?

«Themes» sind Gruppen von User Stories. Man packt einfach alle Stories zur monatlichen Berichterstattung zusammen und nennt das Ganze dann “Theme” (Thema). Es kann hilfreich sein, einen Überbegriff für gewisse Stories zu haben. In meinem Vergleich mit den Filmen wären das beispielsweise alle James Bond Filme, die ich nebeneinander in mein Regal gestellt habe – sie bilden zusammen ein Theme bzw. eine Gruppe.


Was sind Epics?

Der Begriff «Epic» steht einfach für eine große User Story. Es gibt keine exakte Grenze, wann User Stories zu Epics werden. Sie sind einfach nur “große User Stories” und das Prinzip kann gut mit Filmen verglichen werden. Wenn ich sage, dass ein bestimmter Film ein Actionfilm ist, sagt das etwas über den Film aus. Mit großer Wahrscheinlichkeit gibt es Verfolgungsjagden, Schießereien usw. Und das weiß man, obwohl es keine feste Definition davon gibt, dass in einem Actionfilm beispielsweise mindestens drei Verfolgungsjagden, 45 Schüsse etc. vorkommen müssen.


Was sind User Stories?

  • «User Stories» beschreiben, was Nutzer wollen. Sie sind zwar mehr als nur ein paar Wörter auf einer Karteikarte, für unsere Zwecke reicht aber es aus, wenn wir sie uns als einen einfachen Text vorstellen, wie z. B. “Den monatlichen Verkaufsbericht mit Seitenzahlen versehen” oder “Die Berechnung der Steuerbeträge in Rechnungen ändern”.
  • Vielen Teams gefällt die folgende Art und Weise, ihre User Stories zu schreiben:
    Als [Nutzer] [will/kann/muss ich], damit [Grund].”
    Sie müssen jedoch nicht so geschrieben werden, denn auch andere Formate haben ihre Vorteile.

Welche zusätzlichen Informationen können User Stories enthalten?

  • Business rules
  • Data dictionary
  • Beispiel von Input und erwarteter Output

Was ist User Role Modeling?

Das Beschreiben von unterschiedlichen User-Typen.
Am besten Rollen beschrieben und von konkreten Rollen sprechen anstatt von "User". Zb. Nicht "..als User möchte ich..." sondern "..als Vielflieger möchte ich..."


Was sind User Proxies?

Vermutlich das selbe wie User Roles. Prototypen-User die Stellvertretend für eine gewisse Art von Mensch stehen (Nerd, Banker, Lehrer).


Welche Merkmale können User Roles aufweisen?

  • Warum benötigt der User die Software
  • Wie benutzt der User die Software
  • Background vom User
  • Wie technikafin ist der User

Wie können User Roles gefunden werden?

  1. Brainstorming
  2. Organiseren und ordnen der Rollen
  3. Doppelte Rollen zusammenlegen
  4. Rolen verfeinern

Welche Techniken zum Erfassen der User Stories kennen Sie?

  • Questionnaires
  • Interviews
  • Workshops

Was ist die Rolle des PO (Project Owner)/PM (Project Manager)/Customer beim Erstellen der User Stories?

  • Kunden und Anwender bleiben während der gesamten Projektdauer involviert
  • Das Kundenteam schreibt die User Stories, nicht die Entwickler
  • Geschichten werden in der Geschäftssprache geschrieben
  • Der Kunde ist am besten in der Lage, das Produkt zu beschreiben

Wie können nicht-funktionale Anforderungen formuliert werden?

  • Als User Stories
  • Diese Anforderungen beeinflussen das Design und Testsen vieler anderer Geschichten
  • Kann in die «Definition of Done» (später bei SCRUM) aufgenommen werden

Was sind Knowledge Acquisition Stories?

  • Das Team hat nicht genug Wissen, um die Geschichte einzuschätzen
  • User Story zum «Wissen kaufen»
  • Timeboxed (Zeitlimitiert)
  • Als Entwickler möchte ich zwei Alternativen für die neue Filter-Engine prototypisieren, damit ich weiß, welche langfristig eine bessere Wahl ist. (ist umstritten, weil kein direkter Vorteil für den Kunden)

Was verstehen Sie unter INVEST im Zusammenhang mit User Stories?

Gute User Strories weisen 6 Eigenschaften auf:

  • Independent (möglichst keine Abhängigkeiten zwischen User Stories)
  • Negotiable (Verhandelbar, keine Verträge)
  • Valuable to users or customers (und nicht für Entwickler)
  • Estimatable (schätzbar)
  • Small (oder skalierbar)
  • Testable

Was sind Stories NICHT?

  • Schriftliche Verträge
  • Anforderungen, die die Software erfüllen muss
  • Dürfen nicht alle Details enthalten
  • Zu viele Details lassen vermuten, dass alle Fragen bereits geklärt sind und keine weitere Diskussion mehr geführt werden muss
  • Dürfen nicht Unflexibel sein
  • Flexibilität ist notwendig, damit wir den Grad der Umsetzung angleichen können
You can’t perform that action at this time.