137 lines
4.3 KiB
Markdown
137 lines
4.3 KiB
Markdown
---
|
||
description: Grobplanung eines Projekts oder Problems – analysiert Anforderungen, klärt Unklarheiten, identifiziert Technologiebedarf und zerlegt das Projekt in thematisch abgegrenzte, einzeln testbare Blocks. Erstellt [T]-Tickets für Tech Decisions und [P]-Tickets für jeden Block. Wird vom nextstep-Router für [B]-Tickets aufgerufen.
|
||
agent: agent
|
||
model: Claude Opus 4.6 (copilot)
|
||
tools: [read, edit, search, execute, agent, web, todo, browser, vscode]
|
||
---
|
||
|
||
# Workflow: Grobplanung [B]
|
||
|
||
Dieser Workflow wird aufgerufen, wenn der nextstep-Router ein `[B]`-Ticket identifiziert hat.
|
||
Die Eingabe enthält: **Issue-Nummer**, **Titel** und **Issue-Body**.
|
||
|
||
**Ziel:** Ein grob beschriebenes Projekt oder Problem in thematisch abgegrenzte, unabhängig testbare Blocks zerlegen. Für jeden Block entsteht ein `[P]`-Ticket. Tech Decisions werden als `[T]`-Tickets vorangestellt.
|
||
|
||
---
|
||
|
||
## Aufgabenplanung
|
||
|
||
Erstelle zu Beginn eine TODO-Liste (`manage_todo_list`):
|
||
|
||
1. Issue lesen & Projekttyp bestimmen
|
||
2. Anforderungen/System analysieren
|
||
3. Unklarheiten klären (User-Interaktion)
|
||
4. Technologiebedarf identifizieren
|
||
5. Blocks & Abhängigkeitsgraph definieren
|
||
6. Tickets erstellen ([T] zuerst, dann [P])
|
||
7. [B]-Issue schließen
|
||
|
||
---
|
||
|
||
## Phase 1 – Issue lesen & Projekttyp bestimmen
|
||
|
||
1. Lies den vollständigen **Issue-Body** des [B]-Tickets.
|
||
2. Bestimme den **Projekttyp**:
|
||
|
||
| Typ | Kennzeichen |
|
||
|---|---|
|
||
| **Neuentwicklung** | Neues System von Grund auf |
|
||
| **Feature-Erweiterung** | Bestehendes System um größeren Bereich erweitern |
|
||
| **Architektur-Refactoring** | Größere Strukturumbauten am bestehenden System |
|
||
|
||
3. Notiere: Zielplattform, grober Scope, vorhandener Code.
|
||
|
||
---
|
||
|
||
## Phase 2 – Anforderungen/System analysieren
|
||
|
||
1. Lies relevante **Architekturdokumente** (falls vorhanden).
|
||
2. Analysiere den Ist-Zustand (vorhandener Code, Schnittstellen, Datenmodelle).
|
||
3. Identifiziere Abhängigkeiten zu bestehenden Modulen.
|
||
|
||
Erstelle intern eine **Subsystem-Liste** mit:
|
||
- Name und Kurzbeschreibung
|
||
- Geschätzte Komplexität: S / M / L / XL
|
||
- Externe Abhängigkeiten / unbekannte Technologien
|
||
- Abhängigkeiten zu anderen Subsystemen
|
||
|
||
---
|
||
|
||
## Phase 3 – Unklarheiten klären
|
||
|
||
Prüfe für jede Kategorie, ob Klarheit besteht:
|
||
|
||
1. **Scope-Abgrenzung:** Was ist enthalten / nicht enthalten?
|
||
2. **Zielplattform und -Technologie:** Vollständig definiert?
|
||
3. **Externe Systeme:** APIs, Server, Datenbanken?
|
||
4. **Datenmodell:** Kern-Entitäten und Beziehungen klar?
|
||
5. **Offline-Verhalten:** Muss das System offline funktionieren?
|
||
6. **Testing-Anforderungen:** Welcher Testgrad?
|
||
7. **Prioritäten:** Was ist MVP?
|
||
|
||
**Falls Unklarheiten:** Nummerierte Rückfragen mit Optionen → **auf Antwort warten**.
|
||
|
||
---
|
||
|
||
## Phase 4 – Technologiebedarf identifizieren
|
||
|
||
Identifiziere alle offenen **Technologieentscheidungen**:
|
||
|
||
- Persistenzlösungen
|
||
- Externe Server oder Backend-Systeme
|
||
- Neue Frameworks oder SDKs
|
||
- Sync-/Auth-Protokolle
|
||
|
||
Für jede offene Entscheidung notiere: Was, Warum, welche Blocks davon abhängen.
|
||
|
||
---
|
||
|
||
## Phase 5 – Blocks & Abhängigkeitsgraph definieren
|
||
|
||
### Was ist ein Block?
|
||
|
||
Ein **Block** ist eine thematisch abgegrenzte Implementierungseinheit:
|
||
- Eigenständig testbar
|
||
- Klare fachliche Grenze
|
||
- Größenordnung: 1–4 Wochen
|
||
|
||
### Pflicht-Blöcke bei Neuentwicklungen
|
||
|
||
1. **Projektgerüst & Basisinfrastruktur** – lauffähiges Skeleton (App-Struktur, Navigation, DI, Logging)
|
||
2. **Querschnittsfunktionen** – Persistenz, Datenmodell, ggf. Auth, Netzwerkschicht
|
||
|
||
### Block-Tabelle
|
||
|
||
| Nr | Block-Name | Kurzbeschreibung | Abhängig von | Kompl. | Testbarkeit |
|
||
|---|---|---|---|---|---|
|
||
| B1 | Projektgerüst | App-Skeleton, Navigation, CI | – | M | Build + Smoke |
|
||
| B2 | Datenschicht | Room DB, Repository, Export/Import | B1 | M | Unit |
|
||
| … | … | … | … | … | … |
|
||
|
||
**Präsentiere die Block-Tabelle und warte auf Bestätigung** des Users.
|
||
|
||
---
|
||
|
||
## Phase 6 – Tickets erstellen
|
||
|
||
### [T]-Tickets für Tech Decisions (höchste Priorität)
|
||
|
||
Pro offene Tech Decision ein Ticket. Label: `tech-decision`.
|
||
|
||
### [P]-Tickets für jeden Block
|
||
|
||
Pro Block ein Ticket mit:
|
||
- Ziel (ein Satz)
|
||
- Scope (enthalten / ausgeschlossen)
|
||
- Abhängigkeiten (`Depends on: #N`)
|
||
- Akzeptanzkriterien
|
||
- Testing-Strategie
|
||
|
||
Label: `planning`
|
||
|
||
---
|
||
|
||
## Phase 7 – [B]-Issue schließen
|
||
|
||
1. Kommentar mit Übersicht aller erstellten Tickets.
|
||
2. Issue schließen.
|