57 lines
2.7 KiB
Markdown
57 lines
2.7 KiB
Markdown
 
|
# Refinement und Retro — die Termine des Frameworks
|
|||
|
|
|
|||
|
|
Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur
|
|||
|
|
Ablage. Festgelegt in [ADR-0005](../decisions/0005-pm-framework-kanban.md); hier
|
|||
|
|
steht, wie sie ablaufen.
|
|||
|
|
|
|||
|
|
## Refinement (≈ wöchentlich, 30–45 min)
|
|||
|
|
|
|||
|
|
Der eine Termin, der das System am Leben hält. Immer dieselbe Reihenfolge:
|
|||
|
|
|
|||
|
|
1. **Board von rechts nach links lesen** — zuerst `status:doing`: Läuft es noch,
|
|||
|
|
oder ist es in Wahrheit blockiert? Dann `status:wartet`: Wartet es noch auf das,
|
|||
|
|
was im Issue steht? Erst zuletzt `status:next`.
|
|||
|
|
2. **WIP-Limit prüfen** — höchstens zwei Issues in `doing`. Ist es voll, wird nichts
|
|||
|
|
Neues gezogen; stattdessen wird gefragt, was das Laufende blockiert.
|
|||
|
|
3. **Nachziehen** — freie Plätze aus `next` füllen, `next` aus dem Backlog auffüllen.
|
|||
|
|
Auswahlkriterium ist nicht Priorität allein, sondern **was still kaputtgeht**
|
|||
|
|
(Fristen, abgeschaltete Schutzmechanismen) vor **was nervt** vor **was Spaß macht**.
|
|||
|
|
4. **Entscheidungsvorlagen** — offene Fragen, die eine Entscheidung von sorb brauchen,
|
|||
|
|
werden als Optionen mit Empfehlung vorgelegt, nicht als offene Fragen geparkt.
|
|||
|
|
Dauerhafte Ausnahmen von Regeln werden hier zu ADRs.
|
|||
|
|
5. **Datumspflicht prüfen** — jedes zeitkritische Issue trägt ein Datum, kein „bald".
|
|||
|
|
|
|||
|
|
## Retro light (≈ monatlich, 20–30 min)
|
|||
|
|
|
|||
|
|
Drei Fragen, mehr nicht:
|
|||
|
|
|
|||
|
|
- Welche **Verfahren** haben diesen Monat getragen, welche haben gestört?
|
|||
|
|
- Welche **ADRs** sind durch die Realität überholt (→ neues ADR, altes auf
|
|||
|
|
„abgelöst durch")?
|
|||
|
|
- **Fasert etwas aus?** Gibt es wieder Arbeit, die nur in Chatverläufen lebt?
|
|||
|
|
|
|||
|
|
Grundlage sind die AARs des Monats — sie sind die Retro-Vorbereitung, nicht ihr
|
|||
|
|
Ersatz.
|
|||
|
|
|
|||
|
|
## AAR (anlassbezogen)
|
|||
|
|
|
|||
|
|
Nach jedem Deploy mit Übergabe und nach jedem Incident, Vorlage in
|
|||
|
|
[aar-vorlage.md](aar-vorlage.md). Ein AAR ist keine Chronik, sondern ein
|
|||
|
|
Wissensspeicher: Was war das Ergebnis, welche Befunde, was hat die Eingrenzung
|
|||
|
|
ermöglicht, welche Lehren, was bleibt offen. **Offene Punkte aus einem AAR werden
|
|||
|
|
im selben Zug zu Issues** — sonst versacken sie in der Prosa (real passiert am
|
|||
|
|
2026-08-01, nachgezogen als #14–#16).
|
|||
|
|
|
|||
|
|
## Zusammenspiel mit den Sessions
|
|||
|
|
|
|||
|
|
Mehrere Claude-Sessions arbeiten parallel (Mac-Session, Host-Sessions auf CFGMON
|
|||
|
|
und Overmind). Für sie gilt:
|
|||
|
|
|
|||
|
|
- Die **kanonischen Arbeitskonventionen** stehen in [`CLAUDE.md`](../CLAUDE.md) und
|
|||
|
|
sind über den Gitea-Mirror von überall lesbar.
|
|||
|
|
- Arbeit zwischen Sessions läuft über das
|
|||
|
|
[Deploy-Übergabe-Verfahren](deploy-uebergabe.md) — Auftrag, Meldung, Protokoll
|
|||
|
|
im Issue, nicht im Chat.
|
|||
|
|
- Was eine Session lernt, gehört ins Repo (AAR/ADR/Doku), nicht nur in ihr
|
|||
|
|
Gedächtnis — Sessions gehen verloren, Repos nicht.
|