Review des dritten Sprints

Technisches

Der dritte Sprint war technisch der kleinste, aber dafür einer mit ein paar feinen Tücken. Die visuelle Fortschrittsanzeige (US.9) klingt zuerst nach einer Kosmetik-Aufgabe, kollidiert aber direkt mit dem set -euo pipefail aus Sprint 1: Ein Spinner braucht einen Hintergrundprozess, und dessen Exit-Code sauber einzusammeln, ohne dass set -e das Skript vorzeitig abbricht, war der eigentliche Knackpunkt. Gelöst habe ich das mit der Hilfsfunktion run_with_spinner, die den Befehl im Hintergrund startet, den Spinner anzeigt und den Exit-Code über wait gezielt einfängt. So bleibt die bestehende Fehlerbehandlung – inklusive der DryRunOperation-Logik aus Sprint 2 – unverändert erhalten.

Ein zweiter Punkt war die Robustheit ausserhalb einer echten Konsole. Ein Spinner, der mit \r dieselbe Zeile überschreibt, sieht in einer Pipeline oder in CI-Logs unschön aus. Über die Prüfung [[ -t 1 ]] zeigt das Skript daher nur in einer interaktiven Konsole die Animation und fällt sonst auf reine Statusmeldungen zurück.

Die Betriebsdokumentation (US.11) war weniger ein Code- als ein Strukturthema. Hier hat sich das von Anfang an gewählte Include-Konzept ausgezahlt: Der Inhalt liegt einmal zentral als Include und wird sowohl in die Dokumentations-Website als auch in die Stand-Alone-Datei userdocumentation.md eingebunden. Dadurch musste ich nichts doppelt pflegen.

Projektmanagement

Hier ist die Linie aus den ersten beiden Sprints klar aufgegangen. Das konsequente Scope-Management hat sich bewährt: Da die funktionalen Requirements bereits mit dem MMP abgedeckt waren, blieb für Sprint 3 ein überschaubarer, klar abgegrenzter Rest. Das Schätzen fiel mir spürbar leichter als noch in Sprint 1, und der Sprint liess sich ohne Überraschungen abschliessen.

Bewusst Stellung beziehen musste ich beim Feedback aus der Nachbesprechung von Sprint 2, dass für Sprint 2 “zu viel” eingeplant gewesen sei. In einem Ein-Mann-Projekt war das machbar, in einem echten Team-Setting wäre die Last aber unrealistisch gewesen. Diese Erkenntnis nehme ich als wichtigste Lehre für kommende Semesterarbeiten mit.

Reminder

Dies ist erneut ein Reminder an mich selbst für die Zukunft:

- Auch "kosmetische" Features (wie ein Spinner) können mit globalen Shell-Optionen kollidieren – früh mitdenken.
- Nicht-interaktive Umgebungen (CI/Pipe) von Anfang an als Sonderfall berücksichtigen.
- Realistische Sprint-Last auch für ein hypothetisches Team prüfen, nicht nur für mich allein.

TL;DR:

Sprint 3 hat den MMP zum MLP veredelt: Das Tool fühlt sich dank Spinner und Statusmeldungen runder an, und mit der Betriebsdokumentation ist die Übergabe an den Betrieb sauber vorbereitet. Damit sind alle für die Releases MVP, MMP und MLP vorgesehenen User Stories abgeschlossen, und das Produkt ist fertig. Ich bin mit dem Gesamtergebnis zufrieden.

TL;DR: Nachbesprechung

Mit dem MLP-Release ist der geplante Funktions- und Dokumentationsumfang des Projekts vollständig erreicht. Die in der letzten Nachbesprechung angemerkten Punkte (Dokumentation der verworfenen User Story, realistischere Sprint-Last) wurden aufgenommen. Für den Abschluss verbleibt einzig die finale Durchsicht und Abgabe der Semesterarbeit.