# 🗓️ 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 |