8. Projekt-Sprints

Projekt-Sprints

Dies ist das Herzstück des Jahres: der längste zusammenhängende Abschnitt, in dem ein komplexes Anwendungssystem entsteht - nicht als Übung, sondern als echtes Produkt, entwickelt mit dem Vorgehen, den Mustern und der Teststrategie der vorangegangenen Kapitel. Wie viele Wochen zur Verfügung stehen, hängt vom Jahresverlauf ab; der Rahmen bleibt derselbe, unabhängig von der genauen Länge. Ab hier ist alles Methodische kein Stoff mehr, sondern Arbeitsweise. Dieses Kapitel beschreibt den Rahmen; die konkreten Aufträge stehen in Aufgabe 12.

Was das Projekt leisten muss

Das Projekt ist bewusst anspruchsvoll und in vier Punkten festgelegt:

Ein komplexes Anwendungssystem im Fachgebiet Medientechnik. Kein Spielprogramm, sondern ein System mit mehreren zusammenhängenden Funktionen, echter Datenhaltung und mehreren Nutzern oder Rollen.
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.
Bewusst eingesetzte Entwurfsmuster. Mindestens ein Muster wird gezielt verwendet und dokumentiert: welches Problem, warum dieses Muster, welche Alternative.
Eine gelebte Teststrategie. Die dokumentierte Strategie aus Kapitel 7 wird umgesetzt und in der Pipeline automatisch ausgeführt.

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.

Organisation der Sprintphase

Das Projekt läuft in Sprints mit festen Zeremonien im Stundenplan. Ein bewährter Zuschnitt (die Zahl der Sprints richtet sich nach der verfügbaren Zeit):

flowchart LR
  S0[Sprint 0<br/>bereits erledigt] --> S1[Sprint 1]
  S1 --> S2[Sprint 2]
  S2 --> Sn[weitere Sprints<br/>je nach Zeit]
  Sn --> A[Abschluss:<br/>Abnahme und Praesentation]

Sprint-Länge: rund eine Woche, an den Stundenplan angepasst. Kurze Sprints geben häufiger Rückmeldung - richtig im Lernkontext.
Feste Zeremonien: Planning zu Beginn, ein kurzes Daily je Einheit, Review und Retrospektive am Sprintende. Sie stehen im Kalender, nicht im Belieben.
Rolle der Lehrkraft: Product Owner beziehungsweise Stakeholder - sie priorisiert aus fachlicher Sicht, nimmt im Review ab und stellt die Fragen, die später auch die Prüfungskommission stellt.

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 Kapitel 2 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.

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. 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.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Nach Abschluss dieses Kapitels sollten Schülerinnen und Schüler in der Lage sein:

Anwenden: ein komplexes Anwendungssystem über mehrere Sprints eigenverantwortlich im Team entwickeln.
Beurteilen: Bibliotheken und Schnittstellen anhand fachlicher und wirtschaftlicher Kriterien evaluieren, auswählen und die Wahl dokumentieren.
Anwenden: Vorgehensmodell, Entwurfsmuster und Teststrategie im eigenen Projekt nachweisbar einsetzen.
Anwenden: einen laufenden Prozessnachweis aus Board- und Git-Historie führen.
Beurteilen: typische Projektfallstricke früh erkennen und ihnen mit Prozessmaßnahmen begegnen.

Passende Übungen

Aufgabe 12 - Jahresprojekt: Die Sprints