Thore CimbalandClaude Fable 5
ae62727a50
Vier Entscheidungen aus dem Struktur-Workshop. Kadenz: Refinement sonntagabends, woechentlich. Sonntag, weil die GitLab-Backups dort ohnehin laufen und die Woche an der Stelle eine Kante hat. Die Retro light bekommt bewusst KEINEN eigenen Termin, sondern haengt am ersten Refinement des Monats - ein monatlicher Extra-Termin im Solo-Betrieb ist ein Termin, der ausfaellt. Board-Pflege bei Abwesenheit: Eine Session darf abbilden, aber nicht zusagen. Erlaubt sind status:wartet, Schliessen, Fristen nachtragen, Issues anlegen; nicht erlaubt sind status:doing und status:next. Die Trennlinie ist nicht Vorsicht, sondern Bedeutung - doing und next sagen, was als Naechstes wirklich passiert, und das entscheidet sorb. Jede Aenderung wird im Issue begruendet. ADR-0008 zu #14: Agenten-Sessions auf CFGMON laufen root-aequivalent ueber die docker-Gruppe, und das bleibt so - ausdruecklich. Damit gilt 'sudo mit Passwort' auf diesem Host nicht als Kontrollmechanismus. Option B haette das Auditproblem geloest, indem sie den Arbeitsweg entfernt (sudo braucht ein TTY, das eine Session nicht hat); Option C bleibt Ziel, lohnt aber erst bei einem zweiten Menschen - ihr Nutzen ist Zuordnung, und im Ein-Personen-Betrieb gibt es niemanden, gegen den sie schuetzen wuerde. Als ADR und nicht als Absatz in hosts/cfgmon.md, weil eine Ausnahme nur zu dokumentieren statt sie zu entscheiden genau der Fehler ist, den die ADR-Pflicht adressiert. Die im Issue geforderte Vorklaerung - welche Konten sonst in der docker-Gruppe sind, gilt dasselbe auf MATRIX - ist ausdruecklich als offen vermerkt statt stillschweigend uebergangen. Definition of Done: Baustein 4 der Textbausteine IST die kurze DoD fuer Aenderungen ohne Deploy, statt eines eigenen Dokuments. Ein drittes Dokument waere die dritte Fassung derselben Regeln und damit die dritte, die driftet. 62 relative Links geprueft, keiner tot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
92 lines
4.2 KiB
Markdown
92 lines
4.2 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.
|
||
|
||
## Termine (festgelegt im Struktur-Workshop, 2026-08-06)
|
||
|
||
| Termin | Wann |
|
||
|---|---|
|
||
| **Refinement** | **sonntagabends**, wöchentlich, 30–45 min |
|
||
| **Retro light** | im **ersten Refinement des Monats**, +20–30 min |
|
||
|
||
Sonntag, weil die GitLab-Backups dort ohnehin laufen (00:00) — die Woche hat an
|
||
dieser Stelle eine Kante, und die Abendblöcke, in denen real gearbeitet wird,
|
||
liegen meist am Wochenende.
|
||
|
||
Die Retro bekommt **keinen eigenen Termin**: Ein monatlicher Extra-Termin im
|
||
Solo-Betrieb ist ein Termin, der ausfällt. Sie hängt sich an das erste Refinement
|
||
des Monats an — dann ist die Vorbereitung (die AARs des Monats) ohnehin offen.
|
||
|
||
## 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).
|
||
|
||
## Board-Pflege, wenn sorb länger nicht dazukommt
|
||
|
||
Festgelegt 2026-08-06. Eine Session darf das Board **abbilden**, aber nichts
|
||
**zusagen**:
|
||
|
||
| erlaubt | nicht erlaubt |
|
||
|---|---|
|
||
| `status:wartet` setzen (mit benanntem Grund) | nach `status:doing` ziehen |
|
||
| Erledigtes schließen, mit Begründung im Issue | `status:next` vergeben |
|
||
| Fristen ins `due_date`-Feld nachtragen | Prioritäten umsortieren |
|
||
| Befunde als neues Issue anlegen | Milestones neu zuordnen |
|
||
|
||
Die Trennlinie ist nicht Vorsicht, sondern Bedeutung: `doing` und `next` sind die
|
||
**Zusage-Spalten** — sie sagen, was als Nächstes wirklich passiert. Das entscheidet
|
||
sorb. Alles links davon bildet nur ab, was ohnehin schon der Fall ist.
|
||
|
||
**Jede Änderung wird im Issue begründet**, nicht still vorgenommen. Ein Board, dem
|
||
man nicht ansieht, wer warum etwas verschoben hat, ist beim nächsten Refinement
|
||
wertlos.
|
||
|
||
## 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.
|