Aufgabe 06 - Jahresprojekt Sprint 1 - Review, Stories und Modell

Lernziele

• Du ordnest die Teile einer User Story den Elementen von Use-Case-, Klassen- und Sequenzdiagramm zu.
• Du schließt einen Sprint mit Review, Retrospektive und Release ab und leitest eine überprüfbare Maßnahme ab.
• Du schneidest einen Anwendungsfall in Stories, beginnend mit einem dünnen, durchgängigen Standardablauf.
• Du prüfst die drei Diagramme deines Projekts entlang der vier Prüfbeziehungen und legst fest, wann Diagramme aktualisiert werden.

Ausgangslage

Dritte und letzte Woche von Sprint 1. Heute zeigt ihr der Lehrkraft (Stakeholder), was fertig ist, und schaut als Team zurück. Danach schließt ihr die Modellierung des ersten Sprints ab: Kapitel 10 verbindet die Stories im Backlog mit den drei Diagrammen aus Aufgabe 04 und 05, und die drei Blickwinkel prüfen einander. Was dabei an Lücken auftaucht, wandert als Story ins Backlog von Sprint 2.

Die Kata: Fundbüro der Schule. Gegeben ist diese Story:

Als Schülerin oder Schüler möchte ich einen gefundenen Gegenstand mit Foto und Fundort melden, damit die Besitzerin oder der Besitzer ihn im Fundbüro wiederfindet.

• Gegeben ein angemeldeter Schüler, wenn er Beschreibung, Fundort und Foto angibt, dann erscheint der Gegenstand in der Liste „Gefunden“ mit Datum.
• Gegeben ein angemeldeter Schüler, wenn das Foto größer als 5 MB ist, dann wird die Meldung abgelehnt und ein Hinweis angezeigt.
• Gegeben ein Gegenstand, der seit 60 Tagen gemeldet ist, wenn die Hausverwaltung die Liste öffnet, dann ist er als „zur Abholung freigegeben“ markiert.

Dafür brauchst du:

• Kapitel 10 UML III – Von User Stories zu Diagrammen (Story und Anwendungsfall, Zuordnung Story zu Modell, Anwendungsfall in Stories schneiden, Modellierung just in time, die vier Prüfbeziehungen, häufige Fehler, Zustandsdiagramm).
• Kapitel 05 bis 07 für Review, Retrospektive und Release (Release-Merge-Request, Tag, Milestone schließen).
• Deine Diagramme aus Aufgabe 04 und 05.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

• Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
• Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
• Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
• Abgegeben wird dein Projektordner mit einer README.md: darin die Kata und die Links auf Issues, Merge Requests, Release und Dateien dieser Woche im Jahresprojekt-Repository. Review- und Retro-Ergebnis stehen im Repository des Teams (zum Beispiel docs/sprints/sprint-1.md).
• Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07).

Wesentlich_überwiegend

Aufgabe

• Kata: Ordne die Teile der Fundbüro-Story in einer Tabelle mit den Spalten Teil der Story und Element im Modell zu: Rolle, Funktion, Nutzen, mindestens drei Nomen, mindestens zwei Verben, das Akzeptanzkriterium im Normalfall und die beiden anderen Kriterien. Halte fest, welches Kriterium ein eigenes Diagramm nahelegt und welches.
• Review von Sprint 1: Führt der Lehrkraft die lauffähige Software vor, Story für Story gegen die Akzeptanzkriterien. Haltet im Sprint-Protokoll fest: abgenommene Stories, nicht abgenommene Stories (zurück ins Product Backlog), Sprint-Ziel „erreicht“ oder „nicht erreicht“ mit Ursache, Velocity als Summe der abgenommenen Story Points. Die Lehrkraft geht während der Praxiszeit von Team zu Team (etwa zehn Minuten je Team); bis sie bei euch ist, arbeitet ihr an der Kata und am Projektteil weiter.
• Retrospektive (nur das Team): je mindestens zwei Punkte zu „Was lief gut?“ und „Was lief schlecht?“ und eine Maßnahme mit verantwortlicher Person, die im nächsten Sprint überprüfbar ist.

Tipp: Eine zu 90 % fertige Story zählt null Punkte. Im Review zählt nur, was sich vorführen lässt. „Wir kommunizieren besser“ ist keine Maßnahme, „Jeder Merge Request bekommt innerhalb einer Einheit ein Review, geprüft beim Board-Check“ schon.

Bewertungskriterien

Vollständig, wenn:

• die Tabelle alle Teile der Story einem passenden Modellelement zuordnet und die Ausnahmen als Alternativablauf bzw. alt-Zweig oder Zustand erkannt sind,
• das Sprint-Protokoll abgenommene und zurückgelegte Stories, die Bewertung des Sprint-Ziels mit Ursache und die Velocity enthält,
• die Retrospektive eine konkrete, überprüfbare Maßnahme mit verantwortlicher Person hat.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Release: Schließt Sprint 1 nach Kapitel 07 ab: Release-Merge-Request von dev nach main, Tag (zum Beispiel v0.1.0), GitLab-Release mit kurzen Notes und geschlossener Milestone Sprint 1.
• Schneidet einen noch offenen Anwendungsfall in mindestens drei Stories (Standardablauf als dünner Durchstich zuerst, danach Alternativabläufe) und legt sie mit Akzeptanzkriterien als Issues im Product Backlog an.

Tipp: Der dünne Durchstich zuerst: Der Standardablauf läuft einmal ganz durch, die Alternativabläufe kommen als eigene Stories danach.

Bewertungskriterien

Vollständig, wenn:

• Release-Merge-Request, Tag, Release und geschlossener Milestone existieren,
• mindestens drei Stories aus einem Anwendungsfall geschnitten sind, die erste ein durchgängiger Durchstich ist und alle Akzeptanzkriterien haben.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Prüft eure drei Diagramme entlang der vier Prüfbeziehungen aus Kapitel 10 (Use Case gegen Klassendiagramm, Use Case gegen Sequenzdiagramm, Sequenzdiagramm gegen Klassendiagramm, Klassendiagramm gegen Sequenzdiagramm). Dokumentiert in docs/uml/ pro Prüfbeziehung mindestens einen Befund mit Korrektur oder begründet, warum es keinen gibt. Korrigiert dabei die häufigen Fehler (doppelte Information, Anwendungsfall als Funktionsliste).
• Zeichne für das Objekt eures Projekts mit dem reichsten Lebenslauf (zum Beispiel eine Buchung, ein Upload, eine Einreichung) ein Zustandsdiagramm mit Start- und Endzustand und leite daraus mindestens zwei Stories ab, die im Backlog noch fehlen.
• Wähle drei Klassen oder Operationen aus eurem Klassendiagramm und entscheide jeweils, ob daraus eine Story oder ein Task an einer bestehenden Story wird. Begründe mit dem Kriterium Valuable aus INVEST.

Tipp: Frag bei jedem Übergang: Wer löst ihn aus, und was sieht diese Person danach? Wer hätte etwas davon, wenn die Klasse fertig wäre?

Bewertungskriterien

Vollständig, wenn:

• zu jeder der vier Prüfbeziehungen ein Befund mit Korrektur oder eine begründete Fehlanzeige dokumentiert ist und die korrigierten Diagramme keine doppelte Information enthalten,
• das Zustandsdiagramm Start- und Endzustand und fachlich begründete Übergänge hat und die zwei neuen Stories aus einem Zustand oder Übergang folgen,
• die drei Entscheidungen Story oder Task mit Valuable begründet sind.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Wende Modellierung just in time auf die Kandidaten für Sprint 2 an: Entscheide für jede Story, ob ein Diagramm eine offene Entscheidung klärt, welches, und ob es Skizze bleibt oder in die Dokumentation kommt.
• Schlage dem Team eine Zeile für die Definition of Done vor, die festlegt, wann Diagramme aktualisiert werden müssen, und bringt sie (nach Team-Entscheidung) in die Definition of Done ein.
• Beurteile in drei Sätzen, an welcher Stelle eures Projekts ein Diagramm Zeit kosten würde, ohne eine Entscheidung zu klären, und was ihr dort stattdessen tut.

Tipp: Die Prüffrage lautet: Welche Frage beantwortet dieses Diagramm, die sonst offen bliebe? Fällt dir keine ein, brauchst du das Diagramm nicht.

Bewertungskriterien

Vollständig, wenn:

• zu jeder Kandidaten-Story eine begründete Entscheidung über Diagramm, Diagrammart und Skizze oder Dokumentation steht,
• die Zeile für die Definition of Done prüfbar formuliert ist und ihr Status (übernommen oder abgelehnt mit Grund) festgehalten ist,
• das Urteil eine konkrete Stelle im eigenen Projekt und eine Alternative zum Diagramm nennt.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 10 min Kata, 25 min Review und Retrospektive, 30 min Release und Stories schneiden)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules