🗓️ 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 |
Stefan Mogeritsch
7e16b3f318