Aufgabe 12 - Jahresprojekt Die Sprints

Aufgabe 12 - Jahresprojekt: Die Sprints

Worum geht es?

Die längste Projektphase des Jahres: konzentrierte Sprint-Arbeit an Ihrem komplexen Anwendungssystem, mit allem, was der Lehrplan des V. Jahrgangs verlangt - eigenständige Auswahl von Schnittstellen und Bibliotheken, bewusst eingesetzte Entwurfsmuster, eine gelebte Teststrategie und ein nachweisbarer Prozess. Ab hier ist alles Methodische kein Stoff mehr, sondern Arbeitsweise (siehe Kapitel Projekt-Sprints und alle vorherigen).

Was Sie dafür brauchen

• Kapitel Projekt-Sprints und die gesamte Methodik des Jahres.
• Ihr Setup aus Sprint 0 (Aufgabe 03) und Ihre Teststrategie (Aufgabe 11).
• Team, Board und Repository; die Lehrkraft als Product Owner.

Welche Kompetenzen Sie erwerben und zeigen

• Sie entwickeln ein komplexes Anwendungssystem im Fachgebiet in aufeinanderfolgenden Sprints.
• Sie wählen Bibliotheken und Schnittstellen eigenständig aus und begründen die Entscheidung.
• Sie setzen Muster und Teststrategie bewusst ein und weisen den Prozess laufend nach.

Pädagogische Einordnung

• Reproduktion: den Sprint-Rhythmus mit seinen Zeremonien leben (Teil A).
• Reorganisation und Transfer: ein vollständiges Produkt unter allen Lehrplan-Anforderungen bauen (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: eine späte Änderung absorbieren, Entscheidungen verteidigen und Kosten/Nutzen ehrlich abwägen (Teil D).

Rahmen

• Dauer: mehrere Wochen je nach Jahresverlauf, organisiert als Sprints zu je rund einer Woche (Planning Montag, Review und Retro Freitag; Details laut Stundenplan).
• Rolle der Lehrkraft: Product Owner im Review, Coach dazwischen, aber keine Debugger-Hotline.

Arbeitsaufträge

Die Übung erstreckt sich über die gesamte Projektphase. Teil D ist der Expertenteil.

Teil A - Der Sprint-Rhythmus

Für jeden Sprint verbindlich:

1. Sprint-Ziel als ein Satz; am Ende: erreicht oder nicht erreicht, mit Ursache statt Ausrede.
2. Feste Zeremonien im Kalender: Planning, kurzes Daily je Einheit, Review, Retrospektive.
3. Review mit lauffähiger Demo - was nicht demonstrierbar ist, ist nicht fertig. Retro mit mindestens einer konkreten Verbesserung, die im nächsten Sprint überprüft wird.

Teil B - Das Produkt (Pflichtanforderungen)

1. Komplexes Anwendungssystem im Fachgebiet Medientechnik, benutzbar über die drei wichtigsten Flows hinweg (E2E-getestet, siehe Aufgabe 11).
2. Eigenständige Auswahl von Schnittstellen und Bibliotheken: mindestens eine externe Bibliothek und eine Schnittstelle (fremde API oder eigene für Dritte), deren Auswahl in einem kurzen Entscheidungsdokument begründet ist (Alternativen, Kriterien, Entscheidung; je fünf Sätze genügen).
3. Mindestens zwei bewusst eingesetzte Entwurfsmuster, im Code markiert und im Abschlussbericht mit UML dokumentiert, inklusive der Begründung, warum hier kein einfacherer Weg besser war (Patternitis-Schutz).
4. Gelebte Teststrategie: CI durchgängig grün auf main, Bugfixes mit vorangestelltem Test.
5. Vorgehensmodell nachweisbar: Board-Historie, Sprint-Protokolle, Retro-Ergebnisse und deren Umsetzung im Folgesprint.

Teil C - Der Abschluss

1. Abnahme: Durchlauf aller Flows durch den Product Owner anhand der Akzeptanzkriterien.
2. Abschlussbericht (maximal 10 Seiten): Architektur mit Diagramm, Muster-Dokumentation, Bibliotheks-Entscheidungen, Teststrategie-Bilanz (geplant vs. gelebt), Sprint-Bilanz.
3. Präsentation (15 Minuten): Live-Demo, eine Architektur-Entscheidung verteidigen, die ehrlichste Lektion des Projekts.

Teil D - Expertenteil: Die Änderung, die Verteidigung, die Abwägung

1. Späte Änderung absorbieren: Der Product Owner bringt in einem der letzten Sprints eine neue Anforderung ein (etwa ein Wechsel der Datenquelle oder eine zusätzliche Rolle). Setzen Sie sie um und protokollieren Sie, welche und wie viele Dateien Sie anfassen mussten. Wenige, klar abgegrenzte Änderungen sind der Beweis, dass die Architektur des Jahres trägt; ein Flächenbrand ist selbst ein Befund.
2. Entscheidung verteidigen: Wählen Sie die umstrittenste technische Entscheidung des Projekts und verteidigen Sie sie gegen die stärkste Alternative - so, wie es die Prüfungskommission später auch tut. Ein Absatz, der die Alternative ehrlich benennt.
3. Ehrliche Abwägung: Beurteilen Sie in vier bis sechs Sätzen, wo die Methodik des Jahres (Schichten, Muster, Tests, Prozess) den Aufwand zurückgezahlt hat und wo sie für die Projektgröße Overkill war. Eine ehrliche Grenze zu ziehen zeigt mehr Verständnis als pauschales Lob.

Beurteilung

Produkt und Komplexität (30 %), Architektur/Muster/Codequalität (25 %), Teststrategie und CI (15 %), Prozess-Nachweis über die Sprints (15 %), Bericht und Präsentation (15 %). Die Git- und Board-Historie zählt als primäres Beweismittel, denn nachträglich lässt sich ein Prozess nicht fälschen.

Wissenscheck

1. Warum gilt “Was nicht demonstrierbar ist, ist nicht fertig” im Review?
2. Woran erkennt der Product Owner beim Abnahme-Durchlauf, dass ein Flow erfüllt ist?
3. Warum ist eine wenige Dateien umfassende Umsetzung einer späten Änderung ein Qualitätsnachweis der Architektur?
4. Warum ist die Board- und Git-Historie ein besseres Beweismittel als der Abschlussbericht?
5. Nennen Sie eine Situation, in der die Muster- oder Schichtenstruktur für ein Schulprojekt ehrlich betrachtet Overkill ist.

Abgabe

Git-Repository mit gelebter Historie, das Bibliotheks-Entscheidungsdokument, die Muster-Dokumentation, die Teststrategie-Bilanz, das Protokoll der späten Änderung, der Abschlussbericht und die Präsentation.