Backlog
Der priorisierte Backlog kann hier gefunden werden: GitLab.com | Backlog Der Backlog ist “Top-Down”, somit sind die obersten Userstories die am meisten priorisierten.
Zielsetzung
Folgende Ziele sollen im Rahmen dieses Projekts erfüllt werden:
| Nr. | Ziel | Messkriterium | Prio |
|---|---|---|---|
| Z1 | Die Basis-Infrastruktur ist vollständig in Terraform beschrieben und wird über die GitLab-Pipeline ausgerollt. | terraform apply auf leerem Account läuft fehlerfrei durch, terraform plan danach zeigt keine Änderungen. | Muss |
| Z2 | Ein neuer MR erhält automatisch eine eigene Umgebung. | Umgebung innert 5 Minuten erreichbar, URL als Environment im MR sichtbar. | Muss |
| Z3 | Ein neuer Commit aktualisiert die bestehende Umgebung. | Nach drei Commits genau eine Instanz pro MR, die neuste Version ist ausgeliefert. | Muss |
| Z4 | Merge oder Schliessen baut die Umgebung ab. | Nach Merge und nach Schliessen ist jeweils keine Instanz mit dem MR-Tag mehr vorhanden. | Muss |
| Z5 | Die Verarbeitung ist robust bei Nebenläufigkeit und Fehlern. | Testfälle bestanden: doppelte Nachricht, zwei gleichzeitige Pipelines für denselben MR, MR geschlossen während die Bereitstellung läuft. Fehlerhafte Aufträge landen in der Dead-Letter-Queue. | Muss |
| Z6 | Vergessene Umgebungen werden automatisch entfernt. | auto_stop_in gesetzt, Aufräum-Lambda entfernt Instanzen nach max. 24 h. | Kann |
| Z7 | Die Kosten sind transparent. | Kostenabschätzung pro Umgebung und Monat, AWS-Budget-Alarm aktiv. | Kann |
Mindestumfang: Ein vollständiger Durchlauf mit der Demo-Anwendung: MR eröffnen, Umgebung entsteht und die URL ist im MR sichtbar, ein neuer Commit aktualisiert sie, Merge oder Schliessen baut sie ab.
Story Points
Zur Schätzung des Aufwands wird die relative Schätzung mittels Story Points (Fibonacci-Folge) gewählt. Dies ermöglicht es, Komplexität, Unwägbarkeiten und den reinen Arbeitsaufwand entkoppelt von Zeitdruck zu bewerten. Eine Story mit 5 Punkten wird dabei als etwa doppelt so aufwendig/komplex wie eine Story mit 2 oder 3 Punkten eingestuft. Als Beispiel:
| Story Points | Komplexität | Beschreibung | Beispiel im Projekt |
|---|---|---|---|
| 1 | Trivial | Minimale Änderung, kein Risiko, sofort umsetzbar. | Tippfehler in der README korrigieren oder Label anpassen. |
| 2 | Einfach | Standardaufgabe ohne nennenswerte logische Hürden. | Berechtigungen im Schulaccount mit der AWS CLI prüfen. |
| 3 | Moderat | Erfordert Recherche oder einfache Logik/Verknüpfungen. | URL der Umgebung über die GitLab-API im Environment eintragen. |
| 5 | Komplex | Mehrere Abhängigkeiten, Fehlerbehandlung nötig, API-Interaktion. | Bestehende Instanz über SSM Run Command aktualisieren. |
| 8 | Gross | Hohe Unsicherheit, umfasst mehrere Systembereiche. | Erstmaliger Deploy-Ablauf (Pipeline -> SQS -> Lambda -> EC2). |
| 13 | Epic | Zu umfangreich für eine einzelne User Story. | “Den gesamten Lebenszyklus inkl. aller Testfälle entwickeln” -> Muss gesplittet werden! |
Priorisierung mit MoSCoW
Die Userstories sowie Tasks werden anhand von MoSCoW (Must have, Should have, Could have, Won’t have) priorisiert. Dies sorgt dafür, dass die Priorisierung auf den wirklich wichtigen Aufgaben liegt und nicht für “nice-to-have”-Dinge zu viel Zeit verbraucht wird. Must entspricht dabei dem Mindestumfang (Z1 bis Z5), die Kann-Ziele (Z6, Z7) sind Could.
Releases
Es wird gleich viele Releases wie auch Sprints geben. Somit: Pro Sprint ein Release. Dies sieht ungefähr wie folgt aus:
| Sprint | Release | genauere Bezeichnung | Nutzen |
|---|---|---|---|
| 1 | MVP | Minimal Viable Product | Die Basis-Infrastruktur steht in Terraform und ein Auftrag aus der Pipeline erreicht die Lambda (Durchstich). |
| 2 | MMP | Minimum Marketable Product | Der Mindestumfang läuft: Ein MR erhält eine Umgebung, ein Commit aktualisiert sie, Merge oder Schliessen baut sie ab. |
| 3 | MLP | Minimal Loveable Product | Die Lösung ist robust bei Nebenläufigkeit und Fehlern, räumt selbst auf und die Kosten sind transparent. |
Risikomanagement
| Risiko | W | S | Risikowert (W x S) | Mitigationsstrategie (Vermeidung/Lösung) |
|---|---|---|---|---|
| Einschränkungen des Schul-AWS-Accounts (IAM-Rollen, SQS FIFO, SSM) | 3 | 4 | 12 | Prüfung in Woche 1 vor jeder Umsetzung. Fallback: vorhandene Rollen nutzen oder privater Account im Free Tier. |
| Aufwand unterschätzt (50 h neben Arbeit und Schule) | 3 | 4 | 12 | Mindestumfang klar abgegrenzt, Kann-Ziele erst nach lauffähigem Mindestumfang. Zeiterfassung pro Sprint. |
| Doppelanlage bei gleichzeitigen Aufträgen | 3 | 3 | 9 | FIFO-Message-Group pro MR, Deduplizierung, EC2-ClientToken, eigener Testfall. |
| MR geschlossen während Bereitstellung, Instanz bleibt liegen | 3 | 3 | 9 | FIFO-Reihenfolge, Destroy terminiert auch startende Instanzen, eigener Testfall. |
| Kosten durch vergessene Instanzen | 3 | 3 | 9 | Kleine Instanztypen, Abbau über on_stop, Aufräum-Lambda und Budget-Alarm als Kann-Ziele. |
| Sicherheitslücken (offene Ports, Zugangsdaten im Repo) | 2 | 4 | 8 | Security Groups nur HTTP/HTTPS, kein SSH, Secrets nur in geschützten Variablen bzw. Parameter Store. |
| Datenverlust (Lokal) | 2 | 4 | 8 | Tägliche Commits und Pushes in das GitLab-Repository (Versionierung als Backup). |
| Ausfall der Hardware (Laptop) | 1 | 5 | 5 | Regelmässige Sicherung der wichtigsten Konfigurationen; Nutzung von Cloud-IDE-Alternativen im Notfall. |
Legende
W: Wahrscheinlichkeit (1 = unwahrscheinlich, 5 = sehr wahrscheinlich) S: Schadensausmass (1 = vernachlässigbar, 5 = kritisch für den Projektabschluss)
Risikowert: Priorisierung der Massnahmen (Hoch > 12, Mittel 6-12, Niedrig < 6)
Die Risiken werden bei jedem Sprint-Abschluss überprüft.
Kommunikation
Die Kommunikation mit den Stakeholdern findet grundsätzlich nur über MS Teams statt. Das Gitlab-Repo ist öffentlich einsehbar und kann unter diesem Link gefunden werden: Gitlab.com Die aus dem Gitlab-Repo automatisch generierte Website kann hier eingesehen werden: docs.sa2.ronova.to
Stakeholder-Analyse
| Name | Rolle | Einstellung | Einfluss | Interesse |
|---|---|---|---|---|
| Ramon Schmocker | Projektleiter / Developer | Hoch | Kritisch | Projekt so professionell, effizient und zielstrebig wie möglich abschliessen. |
| Corrado ??? | Fachexperte Projektmanagement | Mittel | Unterstützend | Hilfestellung für Projektmanagement-Anliegen / Challenges. |
| Armin Dörzbach | Fachexperte IaC & FAAS | Mittel | Unterstützend | Hilfestellung für technische Anliegen / Challenges. |
| Thanam Pangri | Lehrgangsleiter / Verantwortlich bei Eskalationen | Niedrig | Neutral | Professionelle Semesterarbeit, die bezeugt dass ich befähigt bin. |
Ramon Schmocker:
Kategorie: Schlüsselfigur
Strategie: Wichtig: Regeln: Kommunikation über Teams-Kanal. Projekt so ausführlich wie möglich dokumentieren und planen. Dies ist entscheidend für den Erfolg.
Corrado ???:
Kategorie: Fachexperte
Strategie: Starke Einbindung im Projektmanagement, bei Challenges nach Rat fragen. Bei Entscheidungsunsicherheit die Stakeholder miteinbeziehen.
Armin Dörzbach:
Kategorie: Fachexperte
Strategie: Sicherstellen, dass das Produkt fachgerecht programmiert ist und dass ich jede Zeile Code erklären kann. Den Architekturentscheid (ADR) frühzeitig besprechen.
Thanam Pangri:
Kategorie: Lehrgangsleiter
Strategie: Regelmässige Updates über Teams-Kanal bereitstellen. Bei Eskalationen in Absprache bleiben.