Aufgabe 03 - Jahresprojekt Sprint 0

Lernziele

• Du schneidest eine Produktidee mit Medientechnik-Bezug auf einen vorführbaren Kern zu.
• Du setzt Backlog, Board mit WIP-Limit und eine Definition of Done als Team auf.
• Du richtest ein lauffähiges Projektgerüst mit grüner CI ein und begründest die technische Basis.
• Du planst den ersten Sprint als tragendes Skelett und bewertest die Risiken deines Projekts.

Ausgangslage

Der Start des Jahresprojekts. Du schneidest mit deinem Team eine tragfähige Produktidee im Fachgebiet zu, ihr baut Backlog, Board und technisches Gerüst auf und vereinbart die Arbeitsweise des Teams - alles, was ein erster echter Sprint braucht, bevor er beginnen kann. Der Maßstab: Am Ende muss die erste Story starten können, ohne dass noch etwas zu klären ist (siehe Kapitel 4 bis 7, Agiles Arbeiten I–IV, und Kapitel 21, Projekt-Sprints).

Was du dafür brauchst:

• Kapitel 4 bis 7 (Agiles Arbeiten I–IV) und Kapitel 21 (Projekt-Sprints).
• Das Story-Handwerk aus Aufgabe 02; die Schichtenstruktur aus der 4. Klasse.
• Teams zu zwei bis vier Personen; das Schul-GitLab (Repository, Board, CI).

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 je nach erreichter Stufe: Pitch-Dokument, Definition of Done, Board-Link, Repository-Link (CI grün auf dem Gerüst), Architektur-Skizze, Risikoregister und der Sprint-1-Plan mit tragendem Skelett. Texte und Links stehen im README.md des Projekt-Repositorys.

Wesentlich_überwiegend

Aufgabe

• Entwickle mit deinem Team eine Produktidee mit Medientechnik-Bezug (Beispiele: Podcast-Verwaltung mit Kapitelmarken, Foto-Wettbewerbsplattform mit Jury-Voting, Video-Feedbacktool für Präsentationstrainings). Der Pitch umfasst eine Seite: Zielgruppe, Kernnutzen, drei wichtigste Funktionen, bewusst weggelassene Funktionen.
• Pitcht vor der Lehrkraft (Stakeholder): fünf Minuten. Erst mit Freigabe geht es weiter.
• Lege ein initiales Backlog an: mindestens 10 Stories mit Akzeptanzkriterien (Handwerk aus Aufgabe 02), geordnet; die obersten fünf fein, der Rest darf grob sein. Erkläre in ein bis zwei Sätzen, woran man erkennt, dass euer Backlog geordnet und nicht bloß gesammelt ist.
• Beschließt als Team eine Definition of Done. Minimum: Review durch eine zweite Person, Tests grün, per Merge Request auf dev gemergt. Ergänze zwei eigene Punkte. Begründe in ein bis zwei Sätzen, warum die Definition of Done einmal vereinbart und nicht pro Story neu diskutiert wird.

Tipp: Bewusst weggelassene Funktionen sind die MoSCoW-Kategorie Won’t have (this time) aus Kapitel 4. Jeder Punkt der Definition of Done muss überprüfbar sein - „der Code ist sauber“ ist es nicht.

Bewertungskriterien

Vollständig, wenn:

• der Pitch auf einer Seite Zielgruppe, Kernnutzen, drei Funktionen und die bewusst weggelassenen Funktionen nennt und von der Lehrkraft freigegeben ist (Auflagen sind im Pitch-Dokument nachgetragen),
• das Backlog mindestens 10 Stories mit Akzeptanzkriterien enthält, eine echte Rangfolge hat und oben fein, unten grob ist,
• die Definition of Done das Minimum und zwei eigene, überprüfbare Punkte enthält und für alle sichtbar abgelegt ist,
• beide Erklärungen fachlich stimmen.

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

• Richte die GitLab-Boards nach Kapitel 6 (Abschnitt „Issue Boards über mehrere Sprints“) ein: Milestones für die ersten Sprints, ein Board „Planung“ und ein Board „Sprint“ mit WIP-Limit; Stories als Issues, mit dem Repository verknüpft (Issue-Nummer im Branch-Namen, z. B. feature/42-add-chapter-mark).
• Richte das Repository nach dem Git-Workflow light aus Kapitel 7 ein: dev als Default-Branch, main und dev geschützt, kein Squash-Merge.
• Lege im Repository ein Next.js-Grundgerüst in Schichtenstruktur an (deine bewährte Struktur aus der 4. Klasse) und eine CI, die bei jedem Push Tests und Linter laufen lässt.
• Prüfe am Ende den einfachen Maßstab dafür, dass Sprint 0 abgeschlossen ist, und halte im README.md in einem Satz fest, ob ihr ihn erreicht habt.

Tipp: Ihr dürft parallel arbeiten: Eine Person setzt das Repository-Gerüst auf, während die anderen das Board befüllen. Eine grüne Pipeline sagt nur etwas aus, wenn mindestens ein echter Test auf dem Gerüst läuft.

Bewertungskriterien

Vollständig, wenn:

• Milestones und beide Boards existieren, das WIP-Limit gesetzt ist und die Stories als Issues mit Akzeptanzkriterien angelegt sind,
• Branch-Namen die Issue-Nummer tragen, dev Default-Branch ist, main und dev geschützt sind und Squash-Merge abgeschaltet ist,
• das Gerüst startet, die Schichten eine saubere Abhängigkeitsrichtung haben und die Pipeline mit Tests und Linter grün ist,
• der Maßstab für das Ende von Sprint 0 korrekt benannt und geprüft 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):

• Zeichne eine Architektur-Skizze (eine Seite): Schichten, geplante externe Bibliotheken und Schnittstellen mit je einem Satz Begründung. Die eigenständige Auswahl ist Lehrplan-Kompetenz und wird bei der Abnahme abgefragt.
• Lege ein kurzes Risikoregister an: die drei größten Projektrisiken (fachlich, technisch, organisatorisch), je mit Eintrittswirkung und einer vorbeugenden Maßnahme. Ein Risiko muss eine noch unerprobte Bibliothek oder Schnittstelle betreffen - und die vorbeugende Maßnahme dazu ist ein früher Wegwerf-Prototyp in Sprint 1.
• Begründe in zwei bis drei Sätzen, warum eine unerprobte Bibliothek früh statt spät angebunden werden sollte.

Tipp: Für die Auswahl von Bibliotheken helfen die Prüffragen aus Kapitel 21 (Abschnitt „Bibliotheken und Schnittstellen auswählen“). Eine Maßnahme wie „wir passen auf“ ist keine Maßnahme.

Bewertungskriterien

Vollständig, wenn:

• die Skizze Schichten, Bibliotheken und Schnittstellen mit Abhängigkeitsrichtung zeigt und jeder Baustein einen Satz Begründung hat,
• das Risikoregister drei Risiken verschiedener Art enthält, je mit Wirkung und überprüfbarer Maßnahme,
• das Bibliotheksrisiko einen Wegwerf-Prototyp in Sprint 1 als Maßnahme hat und die frühe Anbindung nachvollziehbar begründet ist.

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

• Plane Sprint 1 konkret: ein Sprint-Ziel in einem Satz und die Auswahl der Stories, die ein tragendes Skelett (walking skeleton) ergeben - die dünnste durchgängige Funktion, die einmal quer durch alle Schichten läuft (Oberfläche → Service → Datenzugriff und zurück). Begründe, warum ein durchgehender dünner Schnitt einem fertig gebauten Einzelbaustein als erstes Sprint-Ergebnis vorzuziehen ist.
• Prüfe dein Team gegen die Rollen aus Scrum light + Kanban (Kapitel 6): Wer ist Product Owner, wer übernimmt im ersten Sprint die Prozessrolle, welche Sprinttermine (meist zwei bis drei Wochen pro Sprint) vereinbart ihr mit der Lehrkraft, und wie stellt ihr sicher, dass am Ende jede Person jede Schicht kennt?

Tipp: Die Velocity eures Teams ist vor Sprint 1 noch unbekannt. Plant den ersten Sprint deshalb bewusst klein und denkt an den Prototyp aus dem Risikoregister.

Bewertungskriterien

Vollständig, wenn:

• das Sprint-Ziel ein Satz ist, die Auswahl nachweislich quer durch alle Schichten läuft und der Umfang zur unbekannten Velocity passt,
• die Begründung für den dünnen durchgängigen Schnitt mindestens zwei Argumente nennt,
• Product Owner, Prozessrolle und Sprinttermine festgelegt sind und für „jede Person kennt jede Schicht“ ein überprüfbarer Mechanismus statt einer Absichtserklärung steht.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules