Stefan Mogeritsch
7e16b3f318
Some checks failed
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
- Added `SPRINT_EXECUTION_ORDER.md` to define the cross-role sprint step sequence. - Created individual roadmaps for Architect, Backend, Frontend, DevOps, Rulebook, QA, UI/UX, and Curator. - Captured developer responsibilities, dependencies, and timelines for Sprints A–C. - Aligned sprint planning documentation with session log agreements. - Provided structured documentation in `docs/04_Agents/Roadmaps/`. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
215 lines
22 KiB
Markdown
215 lines
22 KiB
Markdown
# 🗓️ Sprint Execution Order — Entwickler-übergreifende Reihenfolge
|
||
|
||
> **Stand:** 2. April 2026
|
||
> **Autor:** 🏗️ Lead Architect
|
||
> **Zweck:** Verbindliche, entwickler-übergreifende Ausführungsreihenfolge aller Sprint-Schritte.
|
||
> Dieses Dokument ist die **Single Source of Truth** für „Wer macht was, in welcher Reihenfolge".
|
||
|
||
---
|
||
|
||
## 📐 Legende
|
||
|
||
| Symbol | Bedeutung |
|
||
|--------|----------------------------------------------------------------|
|
||
| 🔴 | Blocker — muss abgeschlossen sein bevor Folgeschritte beginnen |
|
||
| 🟡 | Kann parallel gestartet werden, sobald Voraussetzung erfüllt |
|
||
| 🟢 | Kann sofort und unabhängig gestartet werden |
|
||
| ⏳ | Wartet auf eine andere Aufgabe |
|
||
| ✅ | Abgeschlossen |
|
||
| ⏸️ | Zurückgestellt — separate Besprechung |
|
||
| `→` | „ermöglicht" / „blockiert" |
|
||
|
||
---
|
||
|
||
## 🔴 PHASE 1 — Fundament legen (Woche 1, Sprint A)
|
||
|
||
> **Ziel:** Alle Grundlagen schaffen, auf denen alle anderen aufbauen.
|
||
> Diese Phase darf nicht übersprungen werden — sie blockiert fast alles andere.
|
||
|
||
### Schritt 1 — Startet sofort, gleichzeitig (Tag 1)
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|---------------|--------------------------------------------------------------------------------------------|-------------------------------------------------|
|
||
| 🔴 | 🏗️ Architect | **A-1** ADR-0021 schreiben: Tenant-Resolution-Strategie | → Freischalten von Schritt 2 (Backend A-1) |
|
||
| 🔴 | 🏗️ Architect | **A-2** Domänen-Modell formal präzisieren (`Veranstaltung → Turnier → Bewerb → Abteilung`) | → Freischalten von Backend A-2 und Frontend A-2 |
|
||
| 🔴 | 📜 Rulebook | **A-1** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenz, Alter) | → Freischalten von Backend A-3, Frontend B-3 |
|
||
| 🔴 | 📜 Rulebook | **A-2** Abteilungs-Zwangsteilungsregeln vollständig spezifizieren (CSN-C-NEU) | → Freischalten von Backend A-3, Frontend A-2 |
|
||
| 🟢 | 🧐 QA | **A-1** Test-Strategie für Desktop-App definieren (Testpyramide, Tooling, Konventionen) | → Grundlage für alle QA-Schritte |
|
||
| 🟢 | 🐧 DevOps | **A-1** Docker-Compose-Setup auf aktuellen Stand bringen | → Stabile lokale Dev-Umgebung für alle |
|
||
| 🟢 | 🧹 Curator | **A-5** Session-Log für heutige Besprechung erstellen | → Nachvollziehbarkeit der Beschlüsse |
|
||
|
||
---
|
||
|
||
### Schritt 2 — Startet sobald Schritt 1 (Architect A-1 + A-2) abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
|
||
| 🔴 | 👷 Backend | **A-1** Tenant-Isolation im Datenzugriffs-Layer implementieren (basiert auf ADR-0021) | → Sichere Tenant-Grenze; Grundlage für alle weiteren Backend-Schritte |
|
||
| 🔴 | 👷 Backend | **A-2** Datenbankschema umsetzen: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` | → Freischalten von Backend B-1, B-2 |
|
||
| 🟡 | 🎨 Frontend | **A-1** ViewModel-Architektur definieren + `VeranstalterViewModel` als Referenz-Implementierung umsetzen (MVVM/UDF) | → Muster für alle anderen ViewModels |
|
||
| 🟡 | 🧹 Curator | **A-1** `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect) | → Gemeinsames Vokabular für alle Teams |
|
||
| 🟡 | 🧹 Curator | **A-2** Event-First-Workflow dokumentieren | → Onboarding neuer Entwickler |
|
||
|
||
---
|
||
|
||
### Schritt 3 — Startet sobald Schritt 2 (Backend A-2 + Rulebook A-1/A-2) abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|---------------------------------------------------------------------------------------------------|--------------------------------------------|
|
||
| 🔴 | 👷 Backend | **A-3** Turnierkategorie-Limits validieren (`Turnier.validate()`, `Bewerb.validate()`) | → ÖTO-konforme Dateneingabe gesichert |
|
||
| 🟡 | 🎨 Frontend | **A-2** Abteilungs-Logik im Bewerb-Dialog (CSN-C-NEU Pflicht-Teilung als Vorschlag + Validierung) | → Korrekte Abteilungsanlage durch Benutzer |
|
||
| 🟡 | 🧹 Curator | **A-3** Navigation-V2 dokumentieren (Screen-Baum, Back-Stack) | → |
|
||
| 🟡 | 🧹 Curator | **A-4** Tenant-Konzept dokumentieren (nach ADR-0021) | → |
|
||
|
||
---
|
||
|
||
## 🟠 PHASE 2 — Verbinden & Implementieren (Woche 2, Sprint B)
|
||
|
||
> **Ziel:** Frontend und Backend verbinden. Validierungslogik aktiv. Kassa-Service lauffähig.
|
||
> **Voraussetzung:** Phase 1 vollständig abgeschlossen.
|
||
|
||
### Schritt 4 — Startet parallel, sobald Phase 1 abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
|
||
| 🔴 | 👷 Backend | **B-1** CRUD-Endpunkte für alle Stammdaten-Entitäten (`veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `reiter`, `pferde`, `vereine`, `funktionaere`) | → Freischalten von Frontend B-2 |
|
||
| 🟡 | 🎨 Frontend | **B-1** ViewModels für alle V2-Screens umsetzen (`TurnierViewModel`, `BewerbViewModel`, `PferdProfilViewModel`, etc.) | → Echte Datenbindung in allen Screens |
|
||
| 🟡 | 🖌️ UI/UX | **B-1** Wireframes: Edit-Formulare (AlertDialog vs. dedizierter Screen / Sliding-Panel) | → Grundlage für Frontend-Umsetzung der Formulare |
|
||
| 🟡 | 🖌️ UI/UX | **B-2** Wireframes: Bewerb + Abteilung anlegen (Abteilungs-Auswahl inkl. Pflicht-Felder) | → |
|
||
| 🟡 | 🖌️ UI/UX | **B-3** Wireframes: Kassa-Screen (Gesamt-Saldo + Zahlvorgang + Rechnungsvorschau) | → |
|
||
| 🟡 | 🐧 DevOps | **B-1** CI/CD Pipeline für Compose Desktop Tests headless konfigurieren | → Automatisierte Qualitätssicherung |
|
||
| 🟡 | 🐧 DevOps | **B-2** Gradle-Build-Optimierungen (Cache, parallele Builds, Wrapper-Update) | → Schnellere Build-Zeiten für alle |
|
||
|
||
---
|
||
|
||
### Schritt 5 — Startet sobald Backend B-1 (CRUD-Endpunkte) abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------|
|
||
| 🔴 | 🎨 Frontend | **B-2** Ktor-Clients + Repositories für Backend-Anbindung; `StoreV2` schrittweise ersetzen | → Echte Daten statt Mock; Freischalten von Frontend B-3, B-4 |
|
||
| 🟡 | 🧹 Curator | **B-1** Roadmaps-Verzeichnis pflegen (abgeschlossene Tasks markieren) | → Transparenz über Fortschritt |
|
||
| 🟡 | 🧹 Curator | **B-2** `docs/05_Backend/` aktualisieren (neues DB-Schema, API-Endpunkte-Übersicht) | → |
|
||
|
||
---
|
||
|
||
### Schritt 6 — Startet sobald Schritt 5 (Frontend B-2) abgeschlossen ist UND Rulebook A-1 vorliegt
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------|
|
||
| 🔴 | 👷 Backend | **B-3** ÖTO-Validierung serverseitig absichern (OEPS, FEI-ID, Lizenz, Altersklassen, Abteilungs-Zwangsteilung) | → Daten-Integrität auf Server-Ebene gesichert |
|
||
| 🟡 | 🎨 Frontend | **B-3** Validierungs-Live-Feedback in Edit-Dialogen (OEPS, FEI-ID, Lizenz × Klasse, Altersklasse) | → Benutzer sieht Fehler sofort |
|
||
| 🟡 | 📜 Rulebook | **B-1** Validierungs-Implementierung Frontend begleiten + prüfen | → Qualitätssicherung der Regelwerks-Compliance |
|
||
| 🟡 | 📜 Rulebook | **B-2** Validierungs-Implementierung Backend begleiten + prüfen | → |
|
||
| 🟡 | 🧐 QA | **B-1** Test-Suite: V2-Navigation und Back-Stack | → |
|
||
| 🟡 | 🧐 QA | **B-2** Test-Suite: Onboarding-Wizard Edge-Cases | → |
|
||
| 🟡 | 🧐 QA | **B-3** Test-Suite: Abteilungs-Logik (CSN-C-NEU Pflicht-Teilungen) | → |
|
||
|
||
---
|
||
|
||
### Schritt 7 — Startet sobald Backend B-1 + B-3 abgeschlossen sind
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
|
||
| 🔴 | 👷 Backend | **B-2** Kassa-Service implementieren (`TeilnehmerKonto`, `Zahlvorgang`, Rechnungs-Generierung je Turnier) | → Freischalten von Frontend B-4 |
|
||
| 🟡 | 👷 Backend | **B-4** Nennungs-Service (Grundstruktur: Eingang, Status-Workflow, Postfach-Endpunkt) | → Freischalten von Frontend-Nennungs-Postfach (Sprint C) |
|
||
| 🟡 | 🧐 QA | **B-4** Test-Suite: ViewModel-Verhalten (State-Initialisierung, Intent → Transition, Error-State) | → |
|
||
| 🟡 | 📜 Rulebook | **B-3** Bewerbs-Typen und Bewertungslogik dokumentieren (Stilspringen, Dressurreiter, Reihungsregeln) | → |
|
||
|
||
---
|
||
|
||
### Schritt 8 — Startet sobald Backend B-2 (Kassa-Service) + UI/UX Wireframes abgeschlossen sind
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
|
||
| 🟡 | 🎨 Frontend | **B-4** Kassa-Screen: Gesamt-Saldo-Ansicht, Zahlvorgang, Rechnungsvorschau je Turnier | → Vollständige Kassa-Funktion für Meldestelle |
|
||
| 🟡 | 🧹 Curator | **B-3** `docs/06_Frontend/` aktualisieren (ViewModel-Architektur-Muster, Verweis auf `VeranstalterViewModel`) | → |
|
||
|
||
---
|
||
|
||
## 🟡 PHASE 3 — Ausliefern & Aufräumen (Woche 3–4, Sprint C)
|
||
|
||
> **Ziel:** Stabilisieren, testen, ausliefern, dokumentieren.
|
||
> **Voraussetzung:** Phase 2 vollständig abgeschlossen.
|
||
|
||
### Schritt 9 — Startet parallel sobald Phase 2 abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|----------------------------------------------------------------------------------------------------------|--------------------------------------------|
|
||
| 🟡 | 🎨 Frontend | **C-1** `StoreV2` vollständig ablösen und entfernen / als `@Deprecated` markieren | → Saubere Architektur, kein Tech-Debt mehr |
|
||
| 🟡 | 👷 Backend | **C-1** Testdaten-Seeder implementieren (Neumarkt-Szenario: 2 Turniere, Bewerbe, Abteilungen, Nennungen) | → Reproduzierbare Testbasis für QA |
|
||
| 🟡 | 🧐 QA | **C-1** Test-Suite: Mandanten-Isolation (Veranstaltung A kann keine Daten von B lesen/schreiben) | → |
|
||
| 🟡 | 🧐 QA | **C-2** Test-Suite: Kassa und Zahlvorgang (1 Zahlung → 2 korrekte Rechnungen) | → |
|
||
| 🟡 | 📜 Rulebook | **C-1** `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Testfälle an QA übergeben | → |
|
||
| 🟡 | 🐧 DevOps | **C-1** Desktop-App Packaging (`.msi`, `.deb`, `.dmg`) | → Auslieferbare Desktop-App |
|
||
| 🟡 | 🖌️ UI/UX | **C-1** Wireframes aus Sprint B implementieren (Edit-Formulare + Sliding-Panel) | → |
|
||
| 🟡 | 🖌️ UI/UX | **C-2** Empty States für alle Listenansichten designen und umsetzen | → |
|
||
| 🟡 | 🧹 Curator | **C-1** `README.md` aktualisieren (Desktop-App Fokus, Schnellstart, V1-Referenzen entfernen) | → |
|
||
| 🟡 | 🧹 Curator | **C-2** Setup-Guide aktualisieren (`docs/02_Guides/`) | → |
|
||
|
||
---
|
||
|
||
### Schritt 10 — Startet sobald Schritt 9 abgeschlossen ist
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|-------------|---------------------------------------------------------------------------------------------------------|-----------------------|
|
||
| 🟡 | 🧐 QA | **C-3** Test-Suite: ÖTO-Validierung (alle OEPS/FEI-ID/Lizenz-Kombinationen) | → |
|
||
| 🟡 | 👷 Backend | **C-2** Statistik-Endpunkte (`GET /turniere/{id}/statistiken`, `GET /veranstaltungen/{id}/statistiken`) | → |
|
||
| 🟡 | 📜 Rulebook | **C-2** Funktionärs-Qualifikationen auf Enum umstellen | → |
|
||
| 🟡 | 🐧 DevOps | **C-2** Semantic Versioning einführen + Release-Tagging in CI/CD | → |
|
||
| 🟡 | 🧹 Curator | **C-3** Unterordner-Struktur in `docs/` einführen (nach Abstimmung mit Architect) | → |
|
||
| 🟡 | 🧹 Curator | **C-4** V1-Code-Bereinigung koordinieren (gemeinsam mit Frontend + Backend) | → |
|
||
|
||
---
|
||
|
||
### Schritt 11 — Abschluss Sprint C (nach Schritt 10)
|
||
|
||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||
|-----------|---------------|--------------------------------------------------------------------------------------------------------|-------------------------------------|
|
||
| 🟡 | 🏗️ Architect | **C-1** Synchronisations-Protokoll-Konzeption starten (Offline-First Desktop ↔ Backend) | → Grundlage für LAN-Sync (Sprint D) |
|
||
| 🟡 | 🏗️ Architect | **C-2** `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine) | → Aktueller Überblick für alle |
|
||
| 🟡 | 🐧 DevOps | **C-3** Produktions-Deployment vorbereiten | → |
|
||
| 🟡 | 🧹 Curator | **C-5** Reports-Verzeichnis pflegen (Kurzberichte Sprint A, B, C einsammeln + archivieren) | → |
|
||
|
||
---
|
||
|
||
## ⏸️ Zurückgestellte Themen (eigene Besprechungen)
|
||
|
||
| Thema | Status | Notiz |
|
||
|----------------------------------------------------------|-------------------------|------------------------------------------------------------------|
|
||
| USB-Stick Fallback (Export/Import bei LAN-Ausfall) | ⏸️ Separate Besprechung | Konzept liegt vor (JSON + Versionierung + Checksum) |
|
||
| Web-App Präsentation (Veranstaltung → Turnier → Inhalte) | ⏸️ Separate Besprechung | Hierarchie noch nicht final besprochen |
|
||
| Nenn-System (Web-Formular, dynamisch aus Turnier-Daten) | ⏸️ Separate Besprechung | Konzept liegt vor, Priorisierung nach Desktop-App-Fertigstellung |
|
||
| Live-Ergebnisse Web-App (SSE/WebSocket) | ⏸️ Separate Besprechung | Konzept liegt vor, nach Nenn-System |
|
||
|
||
---
|
||
|
||
## 🔗 Kritischer Pfad (Blocker-Kette)
|
||
|
||
Das ist die längste abhängige Kette — Verzögerung hier verzögert alles:
|
||
|
||
```
|
||
🏗️ ADR-0021
|
||
└─→ 👷 Tenant-Isolation (Backend A-1)
|
||
└─→ 👷 DB-Schema (Backend A-2)
|
||
└─→ 👷 CRUD-Endpunkte (Backend B-1)
|
||
└─→ 🎨 Ktor-Repositories (Frontend B-2)
|
||
└─→ 🎨 Live-Validierung (Frontend B-3)
|
||
└─→ 🎨 Kassa-Screen (Frontend B-4)
|
||
└─→ 🧐 Kassa-Tests (QA C-2)
|
||
|
||
📜 Validierungs-Spezifikation (Rulebook A-1)
|
||
└─→ 👷 ÖTO-Validierung Backend (Backend B-3)
|
||
└─→ 🎨 Live-Validierung Frontend (Frontend B-3)
|
||
└─→ 🧐 Validierungs-Tests (QA C-3)
|
||
```
|
||
|
||
---
|
||
|
||
## 📊 Gesamtübersicht: Wer ist wann aktiv?
|
||
|
||
| Phase / Woche | 🏗️ Architect | 👷 Backend | 🎨 Frontend | 📜 Rulebook | 🐧 DevOps | 🧐 QA | 🖌️ UI/UX | 🧹 Curator |
|
||
|--------------------------|------------------------------|---------------------------------------|----------------------------------------------------------|--------------------------------------|-----------------------|------------------------------------|-----------------------------------|-------------------------------------|
|
||
| **Woche 1 (Sprint A)** | ADR-0021, Domänen-Modell | ⏳ (wartet auf ADR) | ViewModel-Referenz | Validierungsregeln, Abteilungsregeln | Docker-Setup | Test-Strategie | (Start Wireframes) | Session-Log, Ubiquitous_Language |
|
||
| **Woche 2 (Sprint B)** | LAN-Sync ADR | CRUD-APIs, Kassa-Service, Validierung | ViewModels, Repositories, Live-Validierung, Kassa-Screen | Implementierung begleiten | CI/CD, Gradle | Navigation-Tests, Abteilungs-Tests | Wireframes | Docs aktualisieren |
|
||
| **Woche 3–4 (Sprint C)** | Sync-Konzept, Roadmap-Update | Seeder, Statistiken | StoreV2-Ablösung | AltersklasseRechner, Enums | Packaging, Versioning | Isolation-Tests, Kassa-Tests | Empty States, Wireframes umsetzen | README, Setup-Guide, V1-Bereinigung |
|