Review des zweiten Sprints

Technisches

Der zweite Sprint war technisch deutlich angenehmer als der erste, da die Grundstruktur bereits stand und ich primär erweitern statt neu aufbauen konnte. Das konsequente Festhalten am “funktionalen Monolithen” hat sich hier ausgezahlt: Jede neue User Story liess sich als zusätzliche Funktion ergänzen, ohne den bestehenden Ablauf umzuwerfen.

Ein paar Stolpersteine gab es trotzdem. Der Dry-Run-Modus (US.5) war überraschend tückisch: aws ec2 run-instances --dry-run gibt bei Erfolg absichtlich einen Fehlercode mit der Meldung DryRunOperation zurück. Zusammen mit set -euo pipefail hat das zuerst dazu geführt, dass das Skript bei einem eigentlich erfolgreichen Dry-Run abgebrochen ist. Die Lösung war, den Aufruf in ein if ! ...-Konstrukt zu kapseln und gezielt auf den DryRunOperation-String zu prüfen.

Ebenfalls musste ich für die Output-Zusammenfassung (US.6) berücksichtigen, dass die öffentliche IP-Adresse direkt nach dem Start noch nicht verfügbar ist. Ein kurzes Polling über describe-instances löst das pragmatisch, ohne das Skript unnötig komplex zu machen.

Bei US.10 habe ich bewusst eine pragmatische Interpretation gewählt: Statt sämtliche Ressourcen zur Laufzeit über Tags aufzulösen, mappt das Skript die Human-Readable Umgebungsauswahl auf die in den Standards hinterlegten Werte und taggt die Instanzen beim Deployment mit Name und Environment. Das deckt den Nutzen für den 2nd Level Support vollständig ab und bleibt im Rahmen der Semesterarbeit wartbar.

Projektmanagement

Hier habe ich im Vergleich zum ersten Sprint klar dazugelernt. Die User Stories aus dem Nachbesprechungs-Feedback liessen sich sauber in den Sprint-Backlog überführen, und das Planen fiel mir spürbar leichter. Die fünf Stories bildeten thematisch eine logische Einheit (“Robustheit & Usability”), was die Priorisierung und die Reihenfolge der Umsetzung vereinfacht hat.

Was weiterhin Luft nach oben hat, ist das saubere Schätzen der Aufwände. Einzelne Stories (z. B. US.5 mit dem Dry-Run) haben mehr Zeit gekostet als gedacht, andere (US.8) gingen schneller als erwartet.

Verworfene User Story: US.4

Ursprünglich war für Sprint 2 die User Story US.4 “Abfrage von SSH-Keys & Security Groups” eingeplant. Diese wurde im Verlauf des Sprints bewusst verworfen, da sich die Anforderungen der Stakeholder geändert haben:

• Die Security Groups werden seit US.8/US.10 nicht mehr separat abgefragt, sondern automatisch pro Umgebung (Prod/Int/Dev) aus den /.admin/Standards_AbyssInc.md aufgelöst. Eine zusätzliche, manuelle Abfrage wäre damit redundant und würde der Zielsetzung “Human-Readable, keine ID-Kenntnis nötig” sogar widersprechen.
• Die SSH-Keys sind fest im userdata.yml.template (Cloud-Init) hinterlegt und werden so bei jedem Deployment einheitlich ausgerollt. Eine Laufzeit-Abfrage einzelner Keys hätte die homogene Systemlandschaft aufgeweicht. Die produktiv sauberere Lösung (Auslagerung in AWS Secrets Manager / Parameter Store) wurde bereits im Review von Sprint 1 als ausserhalb des Rahmens dieser Semesterarbeit eingestuft.

Die Story wurde damit nicht “vergessen”, sondern als nicht mehr werthaltig (effektiv “Won’t Do”) eingestuft. Auf Wunsch der Stakeholder aus der Nachbesprechung wird diese Entscheidung hier explizit dokumentiert.

Reminder

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

- Bei AWS-CLI-Befehlen immer das Exit-Code-Verhalten prüfen (gerade in Kombination mit `set -e`).
- Defaults und fixe Werte konsequent zentral halten (Standards-File), statt sie im Code zu verstreuen.
- Eventualitäten wie "Wert noch nicht verfügbar" von Anfang an mitdenken.

TL;DR:

Sprint 2 hat den MVP zu einem runden, benutzerfreundlichen MMP gemacht. Die im ersten Sprint identifizierten Requirements der Zielgruppen wurden nachgezogen, der Code ist robuster und für nicht-technische User deutlich zugänglicher. Ich bin mit dem Ergebnis dieses Sprints zufrieden.

TL;DR: Nachbesprechung

Die Requirements der Zielgruppen werden im MMP-Release nun korrekt abgedeckt. Für Sprint 3 verbleibt das Polishing (MLP) sowie die abschliessende Dokumentation und Erfolgsmessung.