L02 Meilensteine

Änderungen

• 2026-10-20 Initiale Version

• 2026-11-03 Ergänzungen Projektdatenverwaltung

• 2026-11-04 Pair Programming: jede:r nimmt teil; Code Reviews: alle reviewen

Übersicht

Jeder Meilenstein ist ein Teil eures Entwicklungsprozesses, den ihr bis zum jeweiligen Zeitpunkt (siehe Termine) erreicht haben solltet.

• Es gibt keine ausführliche Abgabe.

• Tragt im Online-Tool ein, wann ihr den Meilenstein erreicht habt, und beschreibt kurz (wenige Sätze), wie ihr ihn umgesetzt habt.

• Eure Teambegleitung (TB) prüft, ob der Meilenstein tatsächlich erreicht ist. Stellt sicher, dass sie Zugriff auf die nötigen Repositories, Dokumente und Tools hat.

• Wird ein Meilenstein verpasst, begründet das in der Projektdokumentation, sonst gibt es dort Punktabzug. Als Begründung zählen in der Regel nur externe Gründe, etwa Verzögerungen durch die AGs.

Die Meilensteine sind Mindestanforderungen. Wie ihr sie konkret umsetzt, entscheidet ihr im Team, passend zu eurem Projekt (siehe D02 Projektmanagement).

Projektdatenverwaltung

Alle Projektdaten liegen zentral, versioniert und für alle auffindbar ab (siehe Datenverwaltung).

• Es gibt einen gemeinsamen Kommunikationskanal und gemeinsamen Kalender.

• Ein Git-Repository auf einer Forge (z.B. GitLab, GitHub) ist eingerichtet.

  • Es gibt einen Ort in dem Anforderungen verwaltet werden (oft die Forge).

• Es gibt einen festen Ort (oder Orte) für Dokumente, Protokolle, und Timetracking.

• Alle Teammitglieder und die TB haben Zugriff, der AG wo sinnvoll.

• Protokolle der bisherigen Meetings (insbesondere des ersten AG-Treffens) sind dort abgelegt.

Kurzbeschreibung im Tool: Welche Tools nutzt ihr wofür, und wo findet die TB was?

Lauffähiger Code

Eine erste lauffähige Version eurer Software existiert. Sie kann extrem minimal sein, muss aber in der Zielumgebung bzw. mit dem Zielframework laufen.

• Beispiele: eine Website im Zielframework, die „Hallo Welt“ anzeigt; eine selbst kompilierte Version der existierenden Software mit kleiner Änderung; eine Abfrage der Remote-API, die ein paar Statistiken ausgibt.

• Der Code liegt im Repository.

• Es ist dokumentiert (z.B. in einer README), wie man die Software baut und startet, sodass jedes Teammitglied das kann.

Kurzbeschreibung im Tool: Was läuft, und wo ist beschrieben, wie man es baut und startet?

Pair Programming

Ihr habt Pair oder Group Programming ausprobiert und festgelegt, wie ihr es im Projekt einsetzt (siehe Pair & Group Programming).

• Jede:r hat an mindestens einer Session mit Pair oder Group Programming teilgenommen.

• Ihr habt danach bewertet, ob es sich gelohnt hat.

Kurzbeschreibung im Tool: Woran habt ihr gemeinsam gearbeitet, in welcher Form, und wie setzt ihr es künftig ein?

Code Review Checkliste

Code Reviews sind fester Bestandteil eures Prozesses (siehe Code Reviews).

• Es gibt eine schriftliche Checkliste mit euren Prüfkriterien.

• Es ist festgelegt, wann Reviews stattfinden (z.B. vor jedem Merge in den Main-Branch).

• Alle Teammitglieder reviewen abwechselnd (keine feste Reviewer-Rolle).

• Erste Reviews wurden nachvollziehbar durchgeführt, z.B. als Merge Requests mit Kommentaren.

Kurzbeschreibung im Tool: Wo liegt die Checkliste, wann reviewt ihr, und wo sieht die TB Beispiele?

Automatisierte Tests (oder Testcheckliste)

Eure Software wird systematisch getestet (siehe Tests).

• Es gibt automatisierte Tests, die zur aktuellen Software passen und erfolgreich laufen, idealerweise per Continuous Integration.

• Wo automatisierte Tests nicht sinnvoll möglich sind (z.B. UI), gibt es stattdessen eine Testcheckliste für manuelle Tests, die regelmäßig abgearbeitet wird (z.B. vor jedem AG-Treffen) und deren Durchführung protokolliert ist.

• Es ist festgelegt, wann getestet wird und wer testet.

Kurzbeschreibung im Tool: Was wird wie getestet, und wo sieht die TB Tests bzw. Testprotokolle?

Vollständiger Arbeitsablauf

Euer gesamter Prozess läuft wie vorgesehen über komplette Iterationen (siehe Rahmen: Iterationen):

• Regelmäßige AG-Treffen mit Live-Demo, Abnahme und Priorisierung, jeweils protokolliert.

• Anforderungen werden erfasst, geschätzt und pro Iteration eingeplant (siehe D03 Anforderungen).

• Code Reviews, Tests und Pair Programming sind fester Teil der Umsetzung (siehe D04 Qualitätssicherung).

• Zeiterfassung läuft und wird regelmäßig ausgewertet; ein aktueller Burndown-Chart existiert (siehe Zeiterfassung).

• Ihr reflektiert regelmäßig euren Prozess und passt ihn an.

• Euer Prozess ist schriftlich festgehalten.

• Ihr habt mit dem AG besprochen wie ihr das Projekt zu einem erfolgreichen Ende führt.

Kurzbeschreibung im Tool: Wie sieht eine typische Iteration bei euch aus, und wo ist euer Prozess beschrieben? Ist der Projektabschluss gefährdet?