docs: Methodische Flexibilität als verbindliche Leitplanke verankern
PO-Leitplanken und ADP AP1.4 stellen klar, dass RoadmapItem und Plan-UI methodenneutral bleiben. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
parent
687aad6cbd
commit
a5d9eeb338
|
|
@ -159,6 +159,19 @@ Steering Snapshot: `upcoming_milestones` liest aus `roadmap_items` statt `milest
|
|||
- [ ] item_type initial: milestone, review_gate, maturity_stage
|
||||
- [ ] milestones-Tabelle darf deprecated werden
|
||||
- [ ] AP1.4 nach AP1.2c
|
||||
- [ ] **Methodenneutralität:** Schema/UI nicht nur für sequenzielle Software-Gates
|
||||
|
||||
---
|
||||
|
||||
## Methodische Neutralität (AP1.4)
|
||||
|
||||
AP1.4 liefert das **generische Plan-Gerüst**. Konkrete Methoden (z. B. `product_milestone_driven`, Reifegrad-Parallelpfade, Content-Kapitel) **registrieren sich** über:
|
||||
|
||||
- `item_type` + `sequencing_mode` auf RoadmapItem
|
||||
- `method_key` auf `steering_context` (bereits vorhanden)
|
||||
- später: Method-spezifische Verify-Policies, Structure Builder, Next-Action-Strategien
|
||||
|
||||
**Nicht:** fest codierte „Meilenstein = lineare Software-Roadmap“-UI oder Dependency-Modell nur für WBS.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -298,4 +298,18 @@ UI-Unterseiten und Agent-API müssen **fachlich äquivalent** bleiben.
|
|||
|
||||
---
|
||||
|
||||
## 15. Methodische Flexibilität (verbindlich)
|
||||
|
||||
Kairo unterstützt **unterschiedliche Entwicklungs- und Steuerungsmethoden** — auf Portfolio-, Initiativ-, Plan- und Ausführungsebene.
|
||||
|
||||
- **Kernmodell generisch:** RoadmapItem-Typen, Lifecycle, Actions — nicht „nur Software-PM“
|
||||
- **Methoden in Registry:** `steering_context.method_key` + Strategy/Hook-Pakete — keine Sonder-Tabellen pro Methode
|
||||
- **Plan flexibel:** `sequencing_mode` sequenziell | parallel | optional; `item_type` (milestone, maturity_stage, chapter, …)
|
||||
- **Verify flexibel:** Gate-`reached` über Evidence/Review/Decision — Policies methodenabhängig konfigurierbar (später)
|
||||
- **UI methodenbewusst, nicht methodenfix:** Plan-Tab rendert RoadmapItems; Labels/Filter aus Method-Profil, nicht hardcodiert
|
||||
|
||||
Siehe Vision v0.2 §9.1.
|
||||
|
||||
---
|
||||
|
||||
*v0.1 bleibt als historische Referenz erhalten.*
|
||||
|
|
|
|||
|
|
@ -359,6 +359,41 @@ Prompt/KI/MCP bleiben **eingefroren**, bis Plan/Ist und Gates tragfähig modelli
|
|||
|
||||
---
|
||||
|
||||
## 9.1 Methodische Flexibilität auf allen Ebenen (verbindlich)
|
||||
|
||||
Kairo ist **kein** einzelnes PM- oder Software-Framework. Auf **allen Ebenen** können unterschiedliche **Entwicklungs- und Steuerungsmethoden** gelten — parallel im Portfolio, unterschiedlich pro Vorhaben, später auch pro Project/Stream.
|
||||
|
||||
**Prinzip:** Das **Kernmodell bleibt generisch**; konkrete Methoden stecken in der **Method Registry** (`backend/steering/methods/`), nicht in hardcodierten UI-Flows oder Tabellen pro Methode.
|
||||
|
||||
| Ebene | Was variiert methodisch | Mechanismus (Ziel) |
|
||||
|-------|-------------------------|---------------------|
|
||||
| **Portfolio** | Priorisierung, Attention | Strategien in `steering/` (AP1.8) |
|
||||
| **Initiative / Programm** | Lifecycle, Signals, Next Action | `steering_context.method_key` |
|
||||
| **Plan** | Gate-Typen, Abfolge, DoD | `RoadmapItem.item_type`, `sequencing_mode`, Method-Hooks |
|
||||
| **Ist / Ausführung** | Hierarchie (WBS vs. flach), Commit-Regeln | Method-Profil + Structure Builder (später) |
|
||||
| **Verify / Review** | Was zählt als „erreicht“ | Evidence/Review-Policies pro Methode |
|
||||
| **Agenten / Vibe-Coder** | Empfohlene nächste Schritte | Operational API + gleiche Steering-Strategien |
|
||||
|
||||
**Beispiele gleichzeitig im Tenant:**
|
||||
|
||||
- Vorhaben A: `product_milestone_driven` — sequenzielle Gates, Meilenstein-Horizont
|
||||
- Vorhaben B: Reifegrad-Modell — **parallele** `maturity_stage`-RoadmapItems
|
||||
- Vorhaben C: Content/Buch — Kapitel-Gates, andere DoD-Kriterien
|
||||
- Vorhaben D: `generic_operating` — leichte Struktur, wenig Plan-Zwang
|
||||
|
||||
**Was Implementierung nicht tun darf:**
|
||||
|
||||
- Ein einziges Gate-Modell (nur sequenzielle Software-Meilensteine)
|
||||
- UI, die nur eine Methoden-Metapher zeigt
|
||||
- Abhängigkeiten nur als Gantt-Denke
|
||||
- Next Action fest auf Priorität+Fälligkeit — ohne methoden-/kontextabhängige Strategie
|
||||
|
||||
**AP1.4-Konsequenz:** RoadmapItem-Schema und Plan-UI **methodenneutral** bauen; `product_milestone_driven` ist **eine** registrierte Methode, nicht das Produkt.
|
||||
|
||||
**Später:** Method Packages (Structure Builder, Hook-Sets, Next-Action-Strategien) erweiterbar — ohne OM-Tabellen pro Methode (Target State §7–8, §14).
|
||||
|
||||
---
|
||||
|
||||
## 10. Ehrlicher Implementierungsstand (Kurz)
|
||||
|
||||
| Visionselement | Stand |
|
||||
|
|
@ -410,9 +445,25 @@ Kein weiteres Layout-Patching auf der Omnibus-Seite, bevor:
|
|||
| **AP1.5** | Hierarchie: Project, Task unter Action |
|
||||
| **AP1.6** | Plan/Ist-Views, Journey |
|
||||
|
||||
*Später:* Method Packages (Structure Builder, Hook-Sets, Next-Action-Strategien) erweiterbar — ohne OM-Tabellen pro Methode (Target State §7–8, §14).
|
||||
|
||||
## 13. Product Owner Leitplanken
|
||||
|
||||
Entscheidungen an diesem Dokument prüfen:
|
||||
|
||||
1. Beantwortet die Änderung die **Leitfrage** auf der richtigen **Ebene** (Ausführung vs. Plan)?
|
||||
2. Trennt sie **Plan** und **Ist**?
|
||||
3. Ist ein Meilenstein **prüfbar** — oder nur ein Statusfeld?
|
||||
4. Passiert Bearbeitung in **Modal/Detail** — oder wächst wieder eine CRUD-Wand?
|
||||
5. Wird die **Reise** nachvollziehbar — oder nur der aktuelle Zustand?
|
||||
6. Verhindert sie Scope-Creep in Richtung To-do-Tool?
|
||||
7. Wird die Änderung **nur für eine Methode** hardcodiert — oder über Registry/Profil erweiterbar?
|
||||
8. Unterstützt das Schema **sequenziell und parallel** (Gates vs. Reifegrade)?
|
||||
9. Bleibt **Plan/Ist** getrennt, unabhängig von der gewählten Methode?
|
||||
|
||||
---
|
||||
|
||||
## 12. Verbindliche Dokumenten-Hierarchie (neu)
|
||||
## 14. Verbindliche Dokumenten-Hierarchie (neu)
|
||||
|
||||
Bei Konflikten ab 2026-07-05:
|
||||
|
||||
|
|
@ -427,17 +478,4 @@ Bei Konflikten ab 2026-07-05:
|
|||
|
||||
---
|
||||
|
||||
## 13. Product Owner Leitplanken
|
||||
|
||||
Entscheidungen an diesem Dokument prüfen:
|
||||
|
||||
1. Beantwortet die Änderung die **Leitfrage** auf der richtigen **Ebene** (Ausführung vs. Plan)?
|
||||
2. Trennt sie **Plan** und **Ist**?
|
||||
3. Ist ein Meilenstein **prüfbar** — oder nur ein Statusfeld?
|
||||
4. Passiert Bearbeitung in **Modal/Detail** — oder wächst wieder eine CRUD-Wand?
|
||||
5. Wird die **Reise** nachvollziehbar — oder nur der aktuelle Zustand?
|
||||
6. Verhindert sie Scope-Creep in Richtung To-do-Tool?
|
||||
|
||||
---
|
||||
|
||||
*Verwandt: `DOCUMENTATION_REVISION_PROGRAM_v0.2.md`, `Kairo_Canonical_Operating_Model_v0.2.md`, `Kairo_Implementation_Truth_Table_v0.1.md`*
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user