5.4 KiB
SPEC-D — agile_iteration
Steuerungsmethode — Spec-Tiefe D v0.1 (Kompositions-Methode)
Status: vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
Stand: 2026-07-25
Rolle: Kompositions- / Horizont-Methode (technisch AP2.4: method_role=modifier)
Komponiert mit: continuous_product, sequential_dependency, recurring_control
Nicht: eigene Vorhaben-Natur / kein Archetyp
D1 Identität — PO ✓
| Feld | Wert |
|---|---|
method_key |
agile_iteration |
| Fachliche Rolle | Komposition (Kernel §6) mit eigener Plan-/Lifecycle-Logik für den Iterations-Horizont |
| Technische Rolle | modifier (ersetzt Primary nicht; nicht mit program_delivery) |
| Label (DE) | Agile Iteration / Sprint |
| Zweck | Taktet Arbeit in work_cycle (Sprint): Planung, Sprint-Backlog, Ausführung, Abschluss/Carryover. Ändert nicht, ob das Vorhaben Projekt (Ende) oder Product (Dauer) ist. |
Klarstellung PO: „Modifier“ ≠ schwache Logik. Agile hat volle Steuerungslogik für den Sprint — braucht aber eine Primary für Vorhaben-Natur (Closure, Gates-Rolle, Dauerbetrieb vs. Ende).
D2 Geltung
| Feld | Wert |
|---|---|
| Komponiert mit | B2b + continuous_product; A2 + sequential_dependency; A3 + recurring_control |
| Nicht allein | ohne Primary keine Aussage über Vorhaben-Natur |
| Nicht Archetyp | Decision-Lock |
D3 Horizon
| Schicht | Owner |
|---|---|
| Vorhaben- / Plan-Horizont | Primary (Gate, Orientierung, …) |
| Iterations-Horizont (Ist) | diese Methode: aktiver work_cycle |
Beide gleichzeitig gültig; Ist-Default bei aktivem Sprint = Sprint-Backlog.
D4 Leading Work Item
Im Sprint-Slice: Action, gefiltert auf work_cycle_id des aktiven Sprints (Primary-Ready ∩ Sprint).
Mit Primary recurring_control (A3): Sprint taktet Actions (Verbesserung/Sonderarbeit). CadenceInstances bleiben Leading der Primary und liegen nicht als Sprint-Backlog-Todos; Ranking: Cadence overdue/due vor Sprint-Actions (siehe Spec-D recurring_control D6).
D5 Lifecycle — eigener Slice (nicht „Flag“)
| Sprint-Phase | Steuerung |
|---|---|
| Sprint anlegen / geplant | Plan-Container |
| Sprint-Planung | Items aus Eingang/Backlog in Sprint legen (Commit/work_cycle_id) |
| Sprint aktiv | action_selection nur Sprint-Scope; Work-Default Sprint |
| Sprint abschließen | Review/Carryover/Unplan; Status reached/closed |
| Reaktivierung | optional laut bestehendem Flow |
| Kein aktiver Sprint | Komposition wirkungslos → nur Primary (kein leerer Sprint-Sackgasse) |
Primary-Lifecycle (intake … closure des Vorhabens) bleibt; dieser Slice hängt sich in planning / action_selection / waiting / result_intake / adaptation ein.
D6–D8
Next: ready Actions im aktiven Sprint (Primary-Ready-Regeln ∩ work_cycle).
Codes: sprint_ready, sprint_empty, sprint_ending.
Attention: leerer aktiver Sprint; Überhang vor Abschluss.
Events: activate, complete, carryover, reactivate, unplan.
D9 Nested
Kann auf Kind unter B2a liegen, wenn Kind A2/B2b + Agile nutzt. Programm-Meta bleibt program_delivery.
D10–D11
OM: RoadmapItem(work_cycle) + actions.work_cycle_id.
Elements: work_cycle_scope.
composes_with: continuous_product, sequential_dependency, recurring_control.
D10b Backlog-Hierarchie & Jira-Abbildung (Agile-Vollmodell)
Verbindlich: ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md
Diese Methode aktiviert das Scrum/Jira-Vokabular im Eingang — ersetzt nicht die Primary-Methode.
| Jira / Scrum | Kairo (Plan) | Kairo (Ist nach Commit) |
|---|---|---|
| Product Backlog | BacklogItem (Eingang) |
— |
| Epic | BacklogItem item_kind=epic, Container |
Roll-up über Stories/Actions |
| Story | BacklogItem item_kind=story, parent_backlog_id → Epic |
Action delivery |
| Bug | BacklogItem item_kind=bug |
Action bug (+ Feature-Ref) |
| Issue | BacklogItem item_kind=issue |
Action issue (+ Feature-Ref) |
| Sprint | RoadmapItem work_cycle |
Filter: Action.work_cycle_id |
| Sprint Backlog | — | committete Actions im Sprint (keine BacklogItems) |
Regeln:
- Epic ist nicht
RoadmapItem/ Meilenstein. - Epic wird nicht direkt convertiert — nur Stories/Bugs/Issues darunter.
- Stories können mehreren Epics nicht zugeordnet sein (MVP: genau ein
parent_backlog_id; n:m post-MVP). - Ohne aktiven Sprint: Backlog-Hierarchie bleibt Plan; Leading = Primary Continuous/Sequential.
MVP-Ist: story/bug/issue ohne Epic/parent_backlog_id (AP2.2e). Volllogik = ADP Phase P2–P3.
D10c Dual Commit Path (Primary + Agile)
| Pfad | Agile-Profil | Primary Continuous |
|---|---|---|
| A Intake → Commit | Epic/Story → Sprint optional | Idee → Action |
| B Direct AP | erlaubt (Spike, Agent) | Pflicht-Option Plan → Arbeit |
agile_iteration verschärft Sprint-Scope; sie erzwingt nicht Pfad A für jedes AP.
D12
| Punkt | PO ✓ |
|---|---|
| Eigene Steuerungslogik | ja — Planen + Sprint-Lifecycle |
| Primary nötig | ja — Vorhaben-Natur |
| Bezeichnung | fachlich Kompositions-/Horizont-Methode; technisch modifier |
| Ein aktiver Sprint | ja (Decision-Lock) |