05: Iteration Review - ZHAW-Team-Toxic/PM4-Team-Toxic GitHub Wiki
Retrospektive Iteration 4
1. Kontext
Diese Iteration fiel in die Zeit rund um Ostern sowie die Vorbereitung auf eine Zwischenprüfung. Das Team hat sich entschieden, die Iteration nicht vollständig formal zu starten, um die Arbeitsbelastung zu reduzieren und den Fokus auf Studium und Erholung zu legen.
2. Was wurde erreicht?
-
Einige Issues wurden dennoch weiterbearbeitet und es gab Fortschritte, z. B.:
- [#111 – Pathfinding-System für Gegner].
-
Die Grundstruktur der Iteration war angelegt, aber es gab keine offizielle Sprint-Planung oder explizite Iterationsziele.
-
Ansonsten kannte jedes Teammitglied seine Verantwortlichkeiten und hat an diese weitergearbeitet.
3. Was lief gut?
- Flexible und verständnisvolle Teamkultur: Es war allen klar, dass Studium und Gesundheit Vorrang haben.
- Gute Absprache untereinander: Wer Zeit hatte, hat eigenständig weitergearbeitet, ohne dass Druck aufgebaut wurde.
4. Herausforderungen
- Durch die lockere Organisation gab es weniger sichtbaren Gesamtfortschritt innerhalb des Sprints.
- Einzelne Issues zogen sich länger als ursprünglich geplant.
- Die nächsten Sprints müssen diese Auszeit kompensieren.
5. Lessons Learned
- Solche Phasen sind wichtig und richtig, wenn die äusseren Umstände es erfordern.
- Für die Zukunft wäre es hilfreich, auch "entschleunigte" Iterationen bewusst zu kennzeichnen (z. B. als Wartungs-/Pufferiteration), um die Erwartungshaltung für alle klar zu halten.
- Es wäre sinnvoll solche Iterationen nicht spontan zu planen, sondern vorausschauend mit einzubinden, damit die Arbeit nicht im Nachhinein kompensiert werden muss, sondern auf eine solche Auszeit hingearbeitet werden kann.
6. Actions
Action 1: "Sonder-Iteration" klar markieren
-
Was wir tun: Wenn in einer Iteration absehbar ist, dass wir nur wenig Zeit haben (z. B. wegen Ferien oder Prüfungen), schreiben wir direkt zu Beginn der Iteration einen kurzen Hinweis in die Projektbeschreibung (z. B. "Diese Iteration ist reduziert wegen XYZ").
-
Warum: Damit alle im Team und auch externe Reviewer später nachvollziehen können, warum in dieser Iteration weniger passiert ist.
Action 2: Kleines Ziel trotz ruhiger Phase definieren
-
Was wir tun Auch wenn wir wenig Kapazität haben, legen wir zu Beginn jeder Iteration mindestens ein kleines Ziel fest (z. B. ein einfaches Issue oder eine Wartungsaufgabe), damit das Projekt nicht komplett stillsteht.
-
Warum: So bleibt unser Projekt in Bewegung und wir haben trotzdem einen sichtbaren Fortschritt am Ende der Iteration.
Voraussichtlich wird es nicht wieder zu einer solchen Auszeit kommen. Die nächsten Iterationen sollten geplant werden können.