stefan
7e16b3f318
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>
22 KiB
22 KiB
🗓️ 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 |