Aufgabe 02 - Nutzergeschichten und Akzeptanzkriterien

Aufgabe 02 - Nutzergeschichten und Akzeptanzkriterien

Worum geht es?

Sie übersetzen Ihr Thema in Anforderungen, die sich prüfen lassen (siehe Kapitel Jahresprojekt: Thema und Team). Der Unterschied, um den es geht, ist der zwischen „Kalenderfunktion” und einem Satz, bei dem eine zweite Person ohne Rückfrage entscheiden kann, ob er erfüllt ist. Aus diesen Kriterien werden später Ihre Tests, Sie erledigen hier also einen Teil der Testarbeit des Jahres im Voraus.

Was Sie dafür brauchen

• Kapitel Jahresprojekt: Thema und Team, Abschnitt Anforderungen aufschreiben.
• Die Projektskizze aus Aufgabe 01.
• Das Board Ihres Projekts in GitLab, GitHub oder einem gleichwertigen Werkzeug.

Welche Kompetenzen Sie erwerben und zeigen

• Sie formulieren Anforderungen als Nutzergeschichten mit prüfbaren Akzeptanzkriterien.
• Sie priorisieren nach Muss, Soll und Kann und halten das Muss-Set klein genug, um es zu erfüllen.
• Sie stellen Entitäten und Beziehungen Ihres Themas als Skizze dar und gleichen sie gegen die Geschichten ab.

Pädagogische Einordnung

• Reproduktion: das Format der Nutzergeschichte anwenden und Kriterien aufschreiben (Teil A).
• Reorganisation und Transfer: untaugliche Kriterien erkennen und in prüfbare überführen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: das eigene Muss-Set begründen und Sonderfälle ergänzen (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Das Format sitzt

1. Schreiben Sie drei Nutzergeschichten Ihres Projekts im Format Als <Rolle> möchte ich <Ziel>, damit <Nutzen>. Verwenden Sie in jeder Geschichte eine andere Rolle aus Ihrer Projektskizze.

2. Prüfen Sie den Nutzenteil jeder Geschichte an dieser Frage: Steht dort etwas anderes als eine Umformulierung des Ziels? „damit ich buchen kann” hinter dem Ziel „buchen zu können” besteht die Prüfung nicht. Schreiben Sie jede Geschichte um, die durchfällt.

3. Vor Ihnen liegen sechs Kriterien. Entscheiden Sie zu jedem, ob eine zweite Person allein danach beurteilen kann, ob es erfüllt ist, und begründen Sie Ihre Entscheidung in einem Satz.

   • Der Kalender ist übersichtlich.
   • Die Liste zeigt die nächsten 14 Tage.
   • Die Anwendung ist schnell.
   • Ohne Anmeldung ist die Liste lesbar, eine Buchung nicht möglich.
   • Fehlerhafte Eingaben werden sinnvoll behandelt.
   • Belegte Zeitfenster sind als belegt erkennbar, ohne fremde Namen zu zeigen.

4. Drei der sechs Kriterien fallen durch. Schreiben Sie diese drei so um, dass sie die Prüfung bestehen. Aus „Die Anwendung ist schnell” wird dabei kein „Die Anwendung ist sehr schnell”, sondern eine Angabe mit Zahl und Messpunkt.

Teil B - Das Backlog

1. Schreiben Sie zwölf bis zwanzig Nutzergeschichten für Ihr Projekt. Jede bekommt mindestens drei Akzeptanzkriterien, die die Prüfung aus Teil A bestehen.

2. Notieren Sie hinter jeder Geschichte, welchen der sechs Abdeckungsbereiche aus dem Kapitel sie bedient. Prüfen Sie am Ende, ob jeder Bereich mindestens einmal vorkommt, und ergänzen Sie fehlende Geschichten.

3. Vergeben Sie an jede Geschichte eine der Prioritäten Muss, Soll oder Kann. Ins Muss-Set kommen fünf bis acht Geschichten, nicht mehr.

4. Begründen Sie Ihr Muss-Set in vier bis fünf Sätzen. Der Maßstab dafür steht im Kapitel: Ohne welche dieser Geschichten wäre das Projekt kein Projekt mehr?

5. Suchen Sie unter Ihren Muss-Geschichten die heraus, an denen eine fachliche Regel hängt, also eine Überschneidung, eine Frist, ein Kontingent oder eine Voraussetzung. Schreiben Sie die Regel als eigenes Kriterium auf und ergänzen Sie, was das System tut, wenn jemand sie verletzt.

6. Ergänzen Sie bei mindestens drei Geschichten ein Kriterium zur Berechtigung. Es nennt die Rolle, die es darf, und die Antwort des Systems an alle anderen.

7. Legen Sie die Muss-Geschichten als Issues auf Ihrem Board an. Die Akzeptanzkriterien stehen im Text des Issues, nicht in einer separaten Datei.

Teil C - Domänenskizze und Sonderfälle

1. Zeichnen Sie die Domänenskizze Ihres Themas mit allen Entitäten und ihren Beziehungen. Sie passt auf eine Seite und beantwortet zwei Fragen: Welche Dinge gibt es, und wie hängen sie zusammen?

2. Machen Sie zwei Gegenproben und notieren Sie jede Abweichung. Erstens: Kommt jede Entität der Skizze in mindestens einer Geschichte vor? Zweitens: Lässt sich jede Geschichte auf der Skizze wiederfinden? Eine Entität ohne Geschichte ist entweder überflüssig oder Sie haben eine Anforderung vergessen. Lösen Sie jede Abweichung auf und schreiben Sie dazu, wie.

3. Nehmen Sie drei Muss-Geschichten und suchen Sie zu jeder einen Sonderfall, den Ihre Kriterien noch nicht abdecken. Vier Sonderfälle kommen fast immer in Frage: die leere Liste, zwei Personen greifen gleichzeitig zu, ein Bezugsdatensatz wurde gelöscht, eine Frist ist abgelaufen. Ergänzen Sie zu jeder der drei Geschichten das fehlende Kriterium.

4. Nehmen Sie eine Ihrer Muss-Geschichten, die Ihnen zu groß erscheint, und schneiden Sie sie auf. Es entstehen zwei Geschichten: eine kleinere, die für sich genommen schon einen Nutzen liefert und im Muss-Set bleibt, und ein Rest, der auf Soll wandert. Begründen Sie in zwei Sätzen, warum der Schnitt genau dort liegt.

Wissenscheck

1. Wozu dient der Nutzenteil einer Nutzergeschichte, und was verrät es, wenn er sich nicht ausformulieren lässt?
2. Wie lautet die Prüfung für ein Akzeptanzkriterium?
3. Warum ist ein Muss-Set aus dreißig Geschichten keines?
4. Warum gehört zu einem Kriterium über eine fachliche Regel immer auch das Verhalten im Verletzungsfall?
5. Warum bezeichnet das Kapitel die Akzeptanzkriterien als Vorlage für Ihre Tests?
6. Was beantwortet die Domänenskizze, und was gehört ausdrücklich nicht hinein?
7. Warum stehen die Akzeptanzkriterien im Text des Issues und nicht nur in einem eigenen Dokument?

Abgabe

Eine Datei docs/anforderungen.md mit allen Geschichten, Kriterien und Prioritäten. Die Domänenskizze liegt in docs/architektur.md. Die Muss-Geschichten stehen als Issues auf dem Board. Die Ergebnisse aus Teil A und die aufgelösten Abweichungen aus Teil C stehen in protokoll.md.