Aufgabe 15 - Jahresprojekt Sprint 4 - Review, Bibliotheken und Prozessnachweis

Lernziele

Du bewertest eine Bibliothek mit den fünf Prüffragen aus Kapitel 21 gegen eine Alternative und triffst eine begründete Entscheidung.
Du schließt den letzten Sprint mit Review, Retrospektive und Release ab.
Du dokumentierst die wichtigste Bibliotheksentscheidung deines Projekts in einem Entscheidungsdokument.
Du prüfst den Prozessnachweis deines Teams.

Ausgangslage

Dritte und letzte Woche von Sprint 4, des letzten Sprints. Nächste Woche nimmt die Lehrkraft euer Produkt ab, und ihr präsentiert es (Aufgabe 16). Kapitel 21 fasst zusammen, was das Projekt leisten muss und wie ihr es nachweist: ein komplexes System, dessen wichtigste Flows laufen und End-to-End getestet sind, eigenständig ausgewählte Bibliotheken mit Entscheidungsdokument, bewusst eingesetzte und dokumentierte Muster, eine gelebte Teststrategie, und ein Prozessnachweis, der aus Board- und Git-Historie entsteht und nicht aus einem nachträglichen Bericht.

Bibliotheken habt ihr seit Aufgabe 04 als Kandidaten notiert und teilweise schon eingebunden. Heute holt ihr das Entscheidungsdokument für die wichtigste nach, ehrlich datiert, und lernt dabei das Verfahren, das für jede künftige Bibliothek vor der Verwendung gilt.

Die Kata: Wellenform-Anzeige. Ein Team braucht in der Schnittansicht für Hörspiele der Theatergruppe eine Wellenform-Anzeige. Zur Wahl stehen (alle Angaben erfunden):

	Bibliothek `wavepeek`	Eigenbau mit Canvas
Funktion	zeigt Wellenform, Zoom, Markierungen setzen	Wellenform und Zoom in etwa zwei Einheiten machbar, Markierungen eine weitere
Pflege	letzte Version vor 26 Monaten, 140 offene Fehlermeldungen	eigener Code, eigene Tests
Abhängigkeit	bringt zwei weitere Pakete mit, eigene Datenstruktur für Markierungen	keine
Lizenz	GPL-3.0	eigene
Beherrschbarkeit	eine README-Seite, keine Beispiele für React	Canvas-API aus der 4. Klasse bekannt

Dafür brauchst du:

Kapitel 21 Projekt-Sprints (Was das Projekt leisten muss, Bibliotheken und Schnittstellen auswählen, Organisation der Sprintphase, Der Prozessnachweis, Typische Fallstricke).
Kapitel 18 für das Kapseln hinter einem Adapter, Kapitel 05 bis 07 für Review, Retrospektive und Release.
Euer Design-Review, eure Teststrategie und die Sprint-Protokolle von Sprint 1 bis 3.

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 der Kata (README.md) und den Links auf Sprint-Protokoll, Release, Entscheidungsdokument und docs/prozessnachweis.md im Jahresprojekt-Repository.
Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07).

Wesentlich_überwiegend

Aufgabe

Kata: Beantworte die fünf Prüffragen aus Kapitel 21 für beide Varianten mit je einem Satz und entscheide begründet. Nenne den Preis deiner Wahl und das Risiko, das du damit bewusst eingehst.
Review von Sprint 4: Vorführung Story für Story gegen die Akzeptanzkriterien, Sprint-Protokoll mit abgenommenen und zurückgelegten Stories, Sprint-Ziel erreicht oder nicht (mit Ursache) und Velocity. 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 über das Projekt: Überprüft die Maßnahme aus Sprint 3 und haltet je mindestens drei Punkte fest: „Was lief gut?“, „Was lief nicht gut?“, „Was ändern wir beim nächsten Projekt (Diplomarbeit)?“.

Tipp: Eine Entscheidung, die die Alternative als offensichtlich schlecht darstellt, hat sie nicht geprüft. Bei der Lizenz kommt es darauf an, ob ihr das Produkt weitergebt oder veröffentlicht.

Bewertungskriterien

Vollständig, wenn:

alle fünf Prüffragen für beide Varianten beantwortet sind und die Entscheidung den Preis der eigenen Wahl und ein bewusstes Risiko nennt,
das Sprint-Protokoll abgenommene und zurückgelegte Stories, die Bewertung des Sprint-Ziels mit Ursache und die Velocity enthält,
die Retrospektive die alte Maßnahme überprüft und je drei konkrete Punkte in allen drei Gruppen enthält.

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 von Sprint 4 nach Kapitel 07 (Version für die Abnahme, zum Beispiel v1.0.0).
Entscheidungsdokument: Schreibt für die wichtigste Bibliothek oder Schnittstelle eures Projekts ein Entscheidungsdokument in docs/adr/ mit Kontext, Alternativen (mindestens eine ernsthafte, Eigenbau zählt), den fünf Prüffragen je Alternative, Ergebnis und Datum. War die Bibliothek schon vorher im Einsatz, vermerkt das ehrlich mit dem Datum des ersten Commits, der sie verwendet. Nennt das eigene Interface, hinter dem sie gekapselt ist, oder begründet, warum sie es nicht ist.
Prozessnachweis: Legt docs/prozessnachweis.md an. Beantwortet für jede der vier Fragen aus Kapitel 21 (Was wurde wann gemacht? Wer hat was beigetragen? Welche Entscheidungen fielen warum? Was wurde aus Fehlern gelernt?) mit Links ins Repository, wo der Nachweis liegt. Prüft die Kette Issue → Branch → Merge Request mit Closes #… an drei Stories und notiert jede Lücke.

Tipp: Was nicht protokolliert ist, existiert für den Nachweis nicht. Eine Lücke, die ihr selbst findet und benennt, wiegt weniger als eine, die die Lehrkraft findet.

Bewertungskriterien

Vollständig, wenn:

Release-Merge-Request, Tag, Release und geschlossener Milestone Sprint 4 existieren,
das Entscheidungsdokument Kontext, eine ernsthafte Alternative, alle fünf Prüffragen, Ergebnis und ein ehrliches Datum enthält und die Kapselung benennt,
docs/prozessnachweis.md alle vier Fragen mit Links beantwortet und die Prüfung der Kette an drei Stories dokumentiert ist.

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):

Späte Änderung: Die Lehrkraft bringt als Stakeholder eine neue Anforderung ein (etwa eine zusätzliche Rolle oder ein Wechsel der Datenquelle). Euer Product Owner reiht sie ins Backlog. Setzt sie um und protokolliert mit git diff --stat gegen den Stand davor, welche und wie viele Dateien ihr anfassen musstet.
Begründet in drei Sätzen, warum eine Umsetzung in wenigen Dateien ein Qualitätsnachweis eurer Architektur ist, oder diagnostiziert, warum die Änderung Kreise gezogen hat. Bezieht euch auf die Abschnitte im Design-Review.

Tipp: Ein Flächenbrand im Diff ist selbst ein Befund. Er braucht eine Diagnose, keine Ausrede.

Bewertungskriterien

Vollständig, wenn:

die späte Änderung umgesetzt und die Liste der berührten Dateien protokolliert ist,
die Begründung oder Diagnose sich auf konkrete Stellen im Design-Review stützt.

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):

Prüft euer Projekt gegen die vier typischen Fallstricke aus Kapitel 21 (Alles am Schluss, Eine Person baut das Meiste, Das Board als Show, Der Muster-Zwang). Belegt für jeden mit der Historie, ob er euch getroffen hat (zum Beispiel Verteilung der Commits und /spend-Einträge über die Wochen und Personen), und nennt eine Maßnahme für die Diplomarbeit.
Prüft die vier Anforderungen aus „Was das Projekt leisten muss“ mit ihrem jeweiligen Nachweis und markiert, was bis zur Abnahme noch fehlt.

Tipp: Die Historie lügt nicht. Ein Diagramm der Commits pro Woche zeigt „Alles am Schluss“ auf einen Blick.

Bewertungskriterien

Vollständig, wenn:

jeder der vier Fallstricke mit Belegen aus der Historie beurteilt ist und eine konkrete Maßnahme hat,
alle vier Anforderungen mit Nachweis oder offenem Punkt dokumentiert sind.

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, Entscheidungsdokument und Prozessnachweis)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules