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:
-
Ziel 1: Reduktion der Bereitstellungszeit pro EC2-Instanz von aktuell ca. 20 Minuten auf unter 5 Minuten
-
Ziel 2: Sicherstellung einer konsistenten und nachvollziehbaren Konfiguration von EC2-Instanzen
-
Ziel 3: Reduktion des Support- und Troubleshooting-Aufwands um mindestens 20%
-
Ziel 4: Verbesserung der Wartbarkeit und Nachvollziehbarkeit der bereitgestellten Infrastruktur
-
Ziel 5: Ermöglichung der Durchführung standardisierter Deployments durch weniger erfahrene Mitarbeitende
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. | Abfrage von User-Inputs (z.B. Region oder Instance-Type) via read. |
| 3 | Moderat | Erfordert Recherche oder einfache Logik/Verknüpfungen. | Implementierung der Logik zum Ersetzen von Platzhaltern im YAML-Template. |
| 5 | Komplex | Mehrere Abhängigkeiten, Fehlerbehandlung nötig, API-Interaktion. | Einbindung der AWS CLI Befehle inklusive Validierung der Rückgabewerte. |
| 8 | Gross | Hohe Unsicherheit, umfasst mehrere Systembereiche. | Erstmaliges Setup des Deployment-Flows (Verbindung Shell -> Template -> AWS). |
| 13 | Epic | Zu umfangreich für eine einzelne User Story. | “Das gesamte Skript inkl. aller Features 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.
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 | Das Skript läuft einmalig von oben nach unten durch und deployt irgendwas. |
| 2 | MMP | Minimum Marketable Product | Das Skript ist “robust”. Es prüft Eingaben und ist sicher genug für Kollegen. |
| 3 | MLP | Minimal Loveable Product | Das Skript fühlt sich wie ein professionelles Tool an (Farben, Menüs, Geschwindigkeit). |
Risikomanagement
| Risiko | W | S | Risikowert (W x S) | Mitigationsstrategie (Vermeidung/Lösung) |
|---|---|---|---|---|
| Zeitverzug durch Komplexität | 4 | 4 | 16 | Fokus auf das MVP; MLP-Features konsequent streichen, falls die Zeit knapp wird (Scope-Management). |
| AWS Account/Quota Probleme | 2 | 5 | 10 | Frühzeitiger Test der Credentials und Berechtigungen; Nutzung des AWS Free Tier Budgets überwachen. |
| Technischer ““Blocker”” (Syntax) | 3 | 3 | 9 | Zeitnahe Recherche in Dokumentationen; Fallback auf einfachere Shell-Logik statt komplexer Tools. |
| 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)
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.abyss.li
Stakeholder-Analyse
| Name | Rolle | Einstellung | Einfluss | Interesse |
|---|---|---|---|---|
| Ramon Schmocker | Projektleiter / Developer | Hoch | Kritisch | Projekt so professionell, effizient und zielstrebig wie möglich abschliessen. |
| Michel Rodriguez | Fachexperte Projektmanagement | Mittel | Unterstützend | Hilfestellung für Projektmanagement-Anliegen / Challenges. |
| Armin Dörzbach | Fachexperte Infrastruktur | 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.
Michel Rodriguez:
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.
Thanam Pangri:
Kategorie: Lehrgangsleiter
Strategie: Regelmässige Updates über Teams-Kanal bereitstellen. Bei Eskalationen in Absprache bleiben.