verfahren: Refinement/Retro-Termine ausgearbeitet, Struktur-Workshop vorbereitet (#17)
- verfahren/refinement.md: Ablauf und Timeboxes fuer Refinement (woechentlich), Retro light (monatlich), AAR-Anlass; Zusammenspiel der parallelen Sessions - roadmap.md + README: Kadenz-Abschnitt verweist darauf, Workshop-Einstieg verlinkt Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
This commit is contained in:
co-authored by
Claude Fable 5
parent
1b8ef35e9b
commit
cd7b2d0b75
@@ -34,7 +34,7 @@ dieser Ausnahme sind Folgearbeit.
|
||||
| `vision/` | Eine Vision je Linie: Community (axion1337.chat), Tool (ThreadNet), Plattform (Homelab) |
|
||||
| `roadmap.md` | Linien, Meilenstein-Kandidaten, Kadenz — GitLab-Milestones halten den Stand |
|
||||
| `decisions/` | ADRs — Pflicht bei Architekturentscheidungen **und dauerhaften Ausnahmen** |
|
||||
| `verfahren/` | Wie wir arbeiten: [Deploy-Übergabe/DoD](verfahren/deploy-uebergabe.md), [AARs](verfahren/aar/), Werkzeuge |
|
||||
| `verfahren/` | Wie wir arbeiten: [Deploy-Übergabe/DoD](verfahren/deploy-uebergabe.md), [Refinement & Retro](verfahren/refinement.md), [AARs](verfahren/aar/), Werkzeuge |
|
||||
| `hosts/`, `shared/` | **Bestand + Historie** je Host/Thema — offene Punkte sind Issues |
|
||||
|
||||
## Das Backlog: Issues + Board
|
||||
|
||||
+12
-4
@@ -50,7 +50,15 @@
|
||||
|
||||
## Kadenz
|
||||
|
||||
- **Refinement** (gemeinsame Session, ~wöchentlich): Board pflegen,
|
||||
`status:next` füllen, Entscheidungsvorlagen durchgehen.
|
||||
- **AAR** nach jedem Deploy mit Übergabe und nach Incidents (bestehendes Verfahren).
|
||||
- **Retro light** (~monatlich): Verfahren/ADRs prüfen — fasert etwas aus?
|
||||
Ablauf und Timeboxes: [verfahren/refinement.md](verfahren/refinement.md).
|
||||
|
||||
- **Refinement** (gemeinsame Session, ~wöchentlich, 30–45 min): Board von rechts
|
||||
nach links, WIP-Limit prüfen, nachziehen, Entscheidungsvorlagen.
|
||||
- **AAR** nach jedem Deploy mit Übergabe und nach Incidents — offene Punkte daraus
|
||||
werden im selben Zug zu Issues.
|
||||
- **Retro light** (~monatlich, 20–30 min): Verfahren/ADRs prüfen — fasert etwas aus?
|
||||
|
||||
**Der Einstieg steht aus:** [Struktur-Workshop (#17)](https://git.lab/axion1337.chat/management/-/issues/17)
|
||||
— Visionen schärfen, Milestones anlegen (M1–M4 vorgeschlagen), Board erstsichten,
|
||||
Kadenz und Arbeitsteilung festlegen. Vorbereitung ist erledigt, der Termin besteht
|
||||
aus Entscheiden.
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user