21. Projekt-Sprints

Nach diesem Kapitel kannst du:

• ein komplexes Anwendungssystem über mehrere Sprints im Team eigenverantwortlich entwickeln und dabei Vorgehensmodell, Entwurfsmuster und Teststrategie nachweisbar einsetzen.
• Bibliotheken und Schnittstellen anhand von Prüffragen evaluieren, auswählen und die Wahl dokumentieren.
• die vier Zeremonien eines Sprints mit ihrer Leitfrage erklären und begründen, warum im Review nur zählt, was sich vorführen lässt.
• einen laufenden Prozessnachweis aus Board- und Git-Historie führen und begründen, warum er belastbarer ist als ein nachträglicher Bericht.
• typische Projektfallstricke früh erkennen und ihnen mit Prozessmaßnahmen begegnen.

Das Jahresprojekt ist das Herzstück des Jahres: Seit Sprint 0 (Aufgabe 03) entsteht ein komplexes Anwendungssystem, nicht als Übung, sondern als echtes Produkt. In vier Sprints zu je drei Wochen habt ihr jede Woche die Theorie eines Kapitels in euer Projekt eingebaut: Modellierung, SOLID, Muster und Teststrategie. Dieses Kapitel steht am Ende des letzten Sprints und fasst den Rahmen zusammen: was das Projekt leisten muss, wie ihr Bibliotheken auswählt und begründet, wie die Sprints organisiert sind und wie der Prozessnachweis entsteht. Die konkreten Aufträge stehen in Aufgabe 15 (Abschluss von Sprint 4) und Aufgabe 16 (Abnahme und Präsentation).

Stell dir eine Theaterproduktion vor. Wochenlang wurde Szene für Szene geprobt, jede Woche kam etwas dazu: Text, Licht, Kostüme, Musik. Bei der Generalprobe läuft zum ersten Mal das ganze Stück am Stück, unter echten Bedingungen. Die Regie spielt nicht mit, sie sitzt im Zuschauerraum, schaut zu und gibt danach Rückmeldung. Genau das ist der Abschluss des Projekts: Die Sprints 1 bis 3 mit den Kapiteln 08 bis 20 waren die Proben im Stück, der letzte Sprint mit Abnahme ist die Generalprobe, und die Lehrkraft sitzt als Stakeholder im Publikum.

flowchart LR
  accTitle: Einzelproben führen zur Generalprobe, die Regie sitzt im Publikum
  E["Proben im Stück<br/>Sprint 1 bis 3, Kapitel 08 bis 20"] --> G["Generalprobe<br/>Sprint 4 und Abnahme"]
  G --> P["Premiere<br/>Fachgespräch, echtes Entwicklungsteam"]
  R["Regie im Publikum<br/>Lehrkraft als Stakeholder"] -.->|Rückmeldung im Review| G

Begriffe vorab

• Sprint-Ziel: ein Satz, der beschreibt, in welchem Zustand das Produkt am Ende des Sprints sein soll; am Sprintende lautet die Antwort “erreicht” oder “nicht erreicht”.
• Abnahme: die Prüfung des Produkts durch den Stakeholder gegen die Akzeptanzkriterien der Stories; im Projekt geschieht sie im Review.
• Entscheidungsdokument: ein kurzer Text, der eine technische Entscheidung mit Kontext, Alternativen, Kriterien und Ergebnis festhält, etwa im Format Architecture Decision Record (ADR).
• Kapseln: eine fremde Bibliothek nur hinter einem eigenen Interface verwenden, sodass der übrige Code sie nicht direkt kennt.
• Prozessnachweis: die Belege dafür, wie das Team gearbeitet hat - Board-Historie, Git-Historie, Sprint-Protokolle, Retrospektiven.

Was das Projekt leisten muss

Das Projekt ist bewusst anspruchsvoll und in vier Punkten festgelegt:

1. Ein komplexes Anwendungssystem im Fachgebiet Medientechnik. Kein Spielprogramm, sondern ein System mit mehreren zusammenhängenden Funktionen, echter Datenhaltung und mehreren Nutzern oder Rollen.

2. Eigenständige Auswahl von Schnittstellen und Bibliotheken. Anders als in den Vorjahren wird nicht vorgegeben, welche Werkzeuge zu verwenden sind. Das Team recherchiert, evaluiert und begründet seine Wahl selbst - das ist eine ausdrückliche Kompetenz des Lehrplans.

3. Bewusst eingesetzte Entwurfsmuster. Mindestens ein Muster wird gezielt verwendet und dokumentiert: welches Problem, warum dieses Muster, welche Alternative (Kapitel 11 bis 18).

4. Eine gelebte Teststrategie. Die dokumentierte Strategie aus Kapitel 20 wird umgesetzt und in der Pipeline automatisch ausgeführt.

Jede der vier Anforderungen braucht einen Beleg, den die Lehrkraft prüfen kann, ohne dem Team aufs Wort zu glauben:

flowchart LR
  accTitle: Jede der vier Anforderungen hat einen prüfbaren Beleg
  A1["komplexes System"] --> B1["die wichtigsten Flows laufen<br/>und sind E2E-getestet"]
  A2["eigenständige Auswahl"] --> B2["Entscheidungsdokument<br/>mit Alternativen"]
  A3["bewusste Muster"] --> B3["im Code markiert,<br/>mit UML begründet"]
  A4["gelebte Teststrategie"] --> B4["Pipeline auf main grün"]

Genauer erklärt: Was heißt “komplex”? Die Prüffrage lautet: Gibt es Schreiboperationen mit Regeln und Zustandsübergängen, nicht nur Anzeige? Eine Galerie, die Bilder aus einem Ordner anzeigt, hat viele Seiten, aber keine einzige Regel. Ein Geräteverleih, bei dem eine Reservierung eine Doppelbuchung ablehnen muss und ein Schadensvermerk das Gerät sperrt, ist kleiner im Umfang, aber komplex im Sinne der Anforderung. Mit der Teststrategie verhält es sich ähnlich: Ein Dokument, das Tests plant, die nie laufen, ist keine gelebte Strategie, eine Pipeline, die bei jedem Merge Request grün oder rot wird, schon.

Der Unterschied zu allem Vorherigen liegt in der Eigenständigkeit: Nicht die Aufgabenstellung führt durch das Projekt, sondern das Team führt sich selbst - mit dem Vorgehen als Werkzeug.

Bibliotheken und Schnittstellen auswählen

Die selbstständige Auswahl fremder Bausteine ist eine eigene Fähigkeit. Sie folgt denselben Prüffragen, die schon beim Umgang mit Paketen galten, ergänzt um die fachliche Passung:

Frage	Worauf es ankommt
Löst es unser Problem?	genau dieses, nicht ein ähnliches
Wird es gepflegt?	letzte Veröffentlichung, offene Fehler, Aktivität
Wie groß ist die Abhängigkeit?	was es alles mitbringt, wie schwer ein späterer Ausstieg wäre
Passt die Lizenz?	bei Weitergabe oder Veröffentlichung rechtlich relevant, nicht nur akademisch
Können wir es beherrschen?	Dokumentation, Beispiele, Lernaufwand im Zeitrahmen

Wichtig ist die dokumentierte Entscheidung: Warum diese Bibliothek und nicht die Alternative? Genau diese Begründung wird im Fachgespräch gefragt, und “die war halt oben bei der Suche” ist keine. Eine brauchbare Dokumentation braucht dafür keine eigene Seite - ein kurzer Abschnitt im README oder ein Kommentar beim Eintrag in der package.json genügt, solange er die Frage “warum diese und nicht jene?” tatsächlich beantwortet und nicht nur den Namen der Bibliothek wiederholt.

Genauer erklärt: Das Entscheidungsdokument entsteht vor der Verwendung der Bibliothek. Wird es erst geschrieben, wenn die Bibliothek schon überall eingebaut ist, kennt es keine ernsthafte Alternative mehr, sondern rechtfertigt nur noch, was ohnehin passiert ist. Das merkt man ihm an: Die Alternative wird mit einem Halbsatz abgetan, und das Datum liegt nach den ersten Commits, die die Bibliothek verwenden.

Die Abhängigkeit, die man nicht mehr los wird

Eine Bibliothek tief ins System zu verweben ist schnell gemacht und schwer rückgängig. Die Architektur der Vorjahre hilft: Wird eine fremde Bibliothek hinter einem eigenen Interface (einem Adapter, Kapitel 18) gekapselt, bleibt sie austauschbar. Wird sie überallhin importiert, ist ein späterer Wechsel ein Umbau. Kapseln, was man nicht selbst kontrolliert.

flowchart LR
  accTitle: Der eigene Code kennt nur das eigene Interface, nur der Adapter kennt die fremde Bibliothek
  C["eigener Code<br/>Services, Komponenten"] --> I["eigenes Interface"]
  I --> A["Adapter"]
  A --> L["fremde Bibliothek"]
  L2["andere Bibliothek"] -.->|Wechsel: nur ein neuer Adapter| A

Genauer erklärt: Die Folge zeigt sich, wenn eine späte Anforderung den Wechsel erzwingt, etwa weil die Bibliothek nicht mehr gepflegt wird. Ist sie gekapselt, entsteht ein neuer Adapter, und git diff --stat zeigt eine Handvoll Dateien. Ist sie in jeder Komponente direkt importiert, zeigt derselbe Befehl einen Flächenbrand über das halbe Projekt. Die Zahl der berührten Dateien ist damit selbst ein Befund über die Architektur.

Weiterlesen

• Architecture Decision Records - ein knappes Format, um Entscheidungen wie die Wahl einer Bibliothek mit Kontext, Alternativen und Folgen festzuhalten.

Kurz nachgedacht

Dein Team braucht einen PDF-Export. Eine Person hat eine Bibliothek gewählt, “weil sie bei der Suche ganz oben war”, und sie in jeder Komponente direkt importiert, die etwas exportiert. Welche Prüffragen sind unbeantwortet, und was passiert, wenn die Bibliothek in drei Wochen ersetzt werden muss?

Auflösung

Keine der fünf Prüffragen ist beantwortet: weder ob die Bibliothek genau dieses Problem löst, noch ob sie gepflegt wird, wie groß die Abhängigkeit ist, ob die Lizenz passt und ob das Team sie beherrscht. Es fehlt also das Entscheidungsdokument mit einer Alternative. Weil die Bibliothek nicht gekapselt ist, muss bei einem Wechsel jede Komponente angefasst werden, die sie importiert. Mit einem eigenen Interface und einem Adapter wäre es nur ein neuer Adapter.

Organisation der Sprintphase

Das Projekt läuft in Sprints mit festen Zeremonien im Stundenplan. Der Zuschnitt dieses Jahres: vier Sprints zu je drei Wochen, danach eine Woche Abnahme und Präsentation.

flowchart LR
  accTitle: Nach Sprint 0 folgen vier Sprints zu je drei Wochen, dann Abnahme und Präsentation
  S0[Sprint 0<br/>Aufgabe 03] --> S1[Sprint 1<br/>Aufgabe 04 bis 06]
  S1 --> S2[Sprint 2<br/>Aufgabe 07 bis 09]
  S2 --> S3[Sprint 3<br/>Aufgabe 10 bis 12]
  S3 --> S4[Sprint 4<br/>Aufgabe 13 bis 15]
  S4 --> A[Abschluss:<br/>Abnahme und Präsentation, Aufgabe 16]

• Sprints: drei Wochen, also drei Einheiten; Ferien und Schularbeitswochen können einen Sprint verschieben. Die Termine, vor allem die Reviews, legt das Team beim Projektstart mit der Lehrkraft fest und legt sie als Milestones an. Lang genug, dass Stories tatsächlich fertig werden, kurz genug für regelmäßige Rückmeldung.
• Feste Zeremonien: Planning in der ersten Einheit, ein Board-Check zu Beginn jeder Einheit statt eines täglichen Daily, Review und Retrospektive in der letzten Einheit des Sprints. Sie stehen im Kalender, nicht im Belieben.
• Rollen: Product Owner ist eine Person aus dem Team, die Prozessrolle wechselt jeden Sprint. Die Lehrkraft ist Stakeholder: Sie bringt Anforderungen ein, nimmt im Review ab und stellt die Fragen, die später auch die Prüfungskommission stellt.
• Arbeitsfluss: WIP-Limit auf „In Arbeit“, Arbeit wird geholt statt zugeteilt, Review vor neuer Arbeit. Die vollständige Arbeitsweise steht in Kapitel 06, Abschnitt „Scrum light + Kanban“.

Jede Zeremonie beantwortet genau eine Leitfrage. Wer die Frage kennt, erkennt auch, wann eine Zeremonie ihr Ziel verfehlt:

Zeremonie	Wann	Leitfrage
Planning	erste Einheit des Sprints	Was nehmen wir uns vor, und wie viel schaffen wir?
Board-Check (statt Daily)	zu Beginn jeder Einheit	Wo stehen wir, was blockiert?
Review	letzte Einheit, mit der Lehrkraft	Was ist fertig und funktioniert für den Stakeholder?
Retrospektive	direkt nach dem Review, nur das Team	Wie haben wir gearbeitet, und was verbessern wir?

Genauer erklärt: Im Review gilt “Was nicht demonstrierbar ist, ist nicht fertig”. Der Grund: Eine Story, die “fast fertig” oder “nur noch nicht gemergt” ist, liefert dem Stakeholder keinen Nutzen und lässt sich nicht gegen ihre Akzeptanzkriterien abnehmen. Würde sie trotzdem gezählt, wüsste niemand mehr, wo das Produkt tatsächlich steht. Review und Retrospektive verwechselt man leicht, sie schauen aber in verschiedene Richtungen: Das Review prüft das Produkt, die Retrospektive den Prozess. Eine Retro ohne konkrete Maßnahme, die im nächsten Sprint überprüft wird, ist deshalb nur ein Gespräch.

Auch das Sprint-Ziel braucht eine Form, die sich am Ende prüfen lässt. Ein brauchbares Sprint-Ziel beschreibt einen Zustand des Produkts, keine Liste von Tätigkeiten. “Stories 12, 13 und 15 erledigen” lässt sich zwar abhaken, sagt aber nicht, was das Produkt danach kann. “Eine Person kann ein Gerät reservieren, und eine Doppelbuchung wird abgelehnt” lässt sich im Review mit ja oder nein beantworten.

Den Start von Sprint 1 habt ihr in Aufgabe 04 nach diesen vier Schritten gemacht; jeder weitere Sprint beginnt sinngemäß gleich:

1. Zeremonien in den Kalender eintragen und prüfen, ob Board und Repository aus Sprint 0 (Aufgabe 03) bereit sind.
2. Produktidee und Backlog aus Sprint 0 aufgreifen und die drei wichtigsten Flows festlegen; erste Kandidaten für Bibliotheken und Schnittstellen notieren.
3. Die Nachweisstruktur im Repository anlegen: Ablage für Muster-Begründungen, Teststrategie und Sprint-Protokolle.
4. Das Sprint-Ziel als einen Satz formulieren und das Planning-Protokoll von Sprint 1 festhalten.

Weiterlesen

• Scrum Guide - die Originalbeschreibung von Sprint, Planning, Daily, Review und Retrospektive, aus der die Schulvariante dieses Kapitels abgeleitet ist.

Kurz nachgedacht

Zwei Teams formulieren ihr Sprint-Ziel. Team A: “Wir arbeiten an Login, Upload und Galerie.” Team B: “Eine angemeldete Person kann ein Video hochladen und sieht es danach in ihrer Liste.” Welches Ziel lässt sich im Review prüfen? Und in welcher Zeremonie fällt auf, dass Team A sein Ziel nicht erreicht hat?

Auflösung

Nur das Ziel von Team B beschreibt einen Zustand des Produkts, der sich im Review mit ja oder nein beantworten lässt. “Wir arbeiten an …” ist eine Liste von Tätigkeiten und ist auch dann “erfüllt”, wenn nichts fertig wird. Gerade deshalb fällt bei Team A im Review nichts auf, obwohl das Review die Zeremonie wäre, die das zeigen soll. Die Ursache, warum es so gekommen ist, bespricht das Team danach in der Retrospektive.

Der Prozessnachweis

Für die Beurteilung zählt neben dem Produkt der nachweisbare Prozess - und der entsteht nur, wenn er laufend mitläuft, nicht nachträglich erfunden wird:

Nachweis	Entsteht aus
Was wurde wann gemacht?	Board-Historie (Issues wandern, wenn die Arbeit wandert)
Wer hat was beigetragen?	Git-Historie, Merge Requests, Reviews
Welche Entscheidungen fielen warum?	kurze Sprint-Protokolle und die Muster-/Bibliotheksbegründungen
Was wurde aus Fehlern gelernt?	Retrospektiven mit je einer konkreten Maßnahme

Der Aufwand dafür ist gering, wenn Board und Git wie in den Kapiteln 06 und 07 verbunden sind: Dann ist der Nachweis ein Nebenprodukt der Arbeit. Wird er getrennt geführt, wird er zur lästigen Nacharbeit und ist am Ende lückenhaft.

flowchart LR
  accTitle: Aus Issue, Branch und Merge Request entstehen Board- und Git-Historie als Nebenprodukt
  I["Issue #42<br/>auf dem Board"] --> B["Branch"]
  B --> M["Merge Request<br/>Closes #42, Review"]
  M --> D["Issue geschlossen:<br/>Board-Historie"]
  M --> G["Commits und Reviews:<br/>Git-Historie"]

Genauer erklärt: Warum ist die Historie ein besseres Beweismittel als der Abschlussbericht? Der Bericht entsteht am Ende und erzählt, wie es gewesen sein soll. Board- und Git-Historie entstehen dagegen während der Arbeit, mit Zeitpunkt und Person, und lassen sich im Nachhinein nicht glaubwürdig herstellen. Wer alle Sprint-Protokolle in einem Commit kurz vor der Abgabe nachreicht oder alle Issues an einem Abend schließt, macht genau das sichtbar, was er verbergen wollte.

Typische Fallstricke

Alles am Schluss. Wer die ersten Sprints als Vorbereitung behandelt und “richtig” erst später anfangen will, hat am Ende keine Sprints, sondern einen verkappten Wasserfall unter Zeitdruck.

Eine Person baut das Meiste. Sichtbar in der Git-Historie, hörbar in der Präsentation. Gegenmittel: Aufgaben im Planning bewusst verteilen und Zuständigkeiten zwischendurch tauschen, damit jede Person jede Schicht kennt.

Das Board als Show. Karten, die nur zum Review stimmen, sind wertlos. Das Board ist Arbeitsmittel, kein Bühnenbild.

Der Muster-Zwang. Ein erzwungenes Muster ist schlechter als keines (Patternitis, Kapitel 18). Setz eines dort ein, wo es ein echtes Problem löst - und dokumentiere ebenso, wo ihr bewusst darauf verzichtet habt.

Weiterlesen

• GitLab: Issues - wie Stories als Issues mit Labels, Milestones und Verknüpfungen geführt werden, woraus der Prozessnachweis entsteht.

Kurz nachgedacht

Beim Durchsehen eines Repositorys fällt auf: Alle vier Sprint-Protokolle kamen in einem einzigen Commit am Tag vor der Abgabe, und fast alle Commits stammen von einer Person aus zwei Nächten. Welche Fallstricke erkennst du, und welche Maßnahme aus diesem Kapitel hätte sie verhindert?

Auflösung

Zu sehen sind “Alles am Schluss” (die Arbeit ballt sich am Ende, die Protokolle sind nachträglich geschrieben) und “Eine Person baut das Meiste”. Verhindert hätten das feste Zeremonien im Kalender, nach denen das Protokoll jeweils sofort entsteht, ein Board, das mit Git verbunden ist, sodass der Nachweis nebenbei mitläuft, und eine bewusste Verteilung der Aufgaben im Planning mit Rollentausch.

Der eigentliche Zweck

Dieses Projekt ist die Generalprobe für professionelles Arbeiten: dieselbe Arbeitsweise, dieselben Nachweise, dieselbe Art von Präsentation und Fachgespräch, wie sie später zählen - im Fachgespräch der abschließenden Prüfung ebenso wie in jedem echten Entwicklungsteam. Wer hier den Prozess sauber lebt, hat die Methode geübt, bevor sie zum ersten Mal bewertet wird. Wie bei jeder Generalprobe dürfen dabei Fehler passieren; wichtig ist, dass sie auffallen, solange noch Zeit ist, sie zu beheben. Das ist der Zweck dieser Projektphase: nicht ein weiteres Produkt, sondern die eingeübte Fähigkeit, ein Projekt eigenständig und nachweisbar zu führen.

Zusatzmaterialien

• Scrum Guide - als laufende Referenz während der Sprints, nicht nur einmalig gelesen; die Abschnitte zu Sprint Review und Sprint Retrospective helfen, die beiden Zeremonien sauber auseinanderzuhalten.
• Architecture Decision Records - Vorlagen und Beispiele für Entscheidungsdokumente; lohnt sich, bevor ihr die erste Bibliothek auswählt.
• GitLab-Dokumentation: CI/CD und Issues - die technische Grundlage für Pipeline und Prozessnachweis (Issues, Branches, Merge Requests).
• Die eigenen Kapitel 01 bis 20 (01_vorgehensmodelle_phasen.mdx bis 20_teststrategien_2.mdx) als gebündelte Werkzeug-Referenz - Vorgehensmodell, User Stories, Entwurfsmuster und Teststrategie kommen hier alle gleichzeitig zum Einsatz.

Zum Anhören

Du kannst dir diesen Text mit der Vorlesefunktion deines Browsers oder Betriebssystems kostenlos anhören, etwa mit “Laut vorlesen” in Microsoft Edge. Das eignet sich gut zum Wiederholen vor dem Projektstart.

Lernergebnisse: Was du nach diesem Kapitel können solltest

• Anwenden: ein komplexes Anwendungssystem über mehrere Sprints im Team eigenverantwortlich entwickeln und dabei Vorgehensmodell, Entwurfsmuster und Teststrategie nachweisbar einsetzen.
• Beurteilen: Bibliotheken und Schnittstellen anhand von Prüffragen evaluieren, auswählen und die Wahl dokumentieren.
• Erklären: die vier Zeremonien eines Sprints mit ihrer Leitfrage erklären und begründen, warum im Review nur zählt, was sich vorführen lässt.
• Anwenden: einen laufenden Prozessnachweis aus Board- und Git-Historie führen und begründen, warum er belastbarer ist als ein nachträglicher Bericht.
• Beurteilen: typische Projektfallstricke früh erkennen und ihnen mit Prozessmaßnahmen begegnen.

Passende Übungen

Die Übungen stehen im Stufenformat: Wesentlich_überwiegend und Wesentlich_vollständig sind in etwa 70 Minuten zu schaffen, PlusPlus und MandalorianPlus sind optionale Erweiterungen im Projekt.

• Aufgabe 15 - Jahresprojekt Sprint 4 - Review, Bibliotheken und Prozessnachweis: Eine Bibliothek mit den fünf Prüffragen gegen eine Alternative bewerten, Review und Retrospektive über das Projekt (Wesentlich_überwiegend); Release, Entscheidungsdokument für die wichtigste Bibliothek, Prozessnachweis mit Prüfung der Kette Issue, Branch und Merge Request (Wesentlich_vollständig). PlusPlus: späte Änderung absorbieren; MandalorianPlus: Fallstricke und Anforderungen mit der Historie prüfen.
• Aufgabe 16 - Jahresprojekt - Abnahme und Präsentation (Woche nach diesem Kapitel, ohne Theorieblock): Abnahme der drei wichtigsten Flows gegen die Akzeptanzkriterien (Wesentlich_überwiegend), Präsentation mit Live-Demo, Architekturentscheidung und ehrlichster Lektion (Wesentlich_vollständig). PlusPlus: Abschlussbericht; MandalorianPlus: Entscheidung verteidigen und ehrliche Abwägung.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules