DevFW-CICD/edp-doc
19
0
Fork 1
Code Issues Pull requests 2 Projects Releases Packages Wiki Activity Actions
edp-doc/docs/technical-documentation/project/team-process/ensemble-pairing-mob/index.md

27 KiB
Raw Blame History

Mobbing / Ensemble programming

Es gibt eine Reihe von Erfahrungen aus Teams, die (Remote-)Mob Programming oder ähnliches wie ensemble programming, pair programming, oder swarming praktizieren – oft mit vergleichbarer Teamzusammensetzung und ähnlichen Dynamiken über die Zeit.

Typischer Verlauf bei Mob Programming (grob in Phasen):

  1. Initiale Euphorie & hoher Output – durch hohe Energie, Fokus und enge Zusammenarbeit (oft durch starke Facilitator oder Leads getrieben).
  2. Erste Ermüdungserscheinungen – durch Daueraufmerksamkeit, Entscheidungsmüdigkeit, reduzierte Eigenverantwortung.
  3. Reflexion und Wunsch nach mehr Balance – Aufkommen von Fragen zur langfristigen Skalierung, individuellen Entwicklung, Ownership, usw.

Annahme

Nach 3 Wochen Mobbing-Initialisierung steen wir jetzt in Phase 3. Das ist gesund und sogar notwendig, damit sich euer Arbeitsmodus weiterentwickeln kann.

🔁 Mögliche Strategien (aus der Praxis)

1. Rotierende Mobs / kleinere Ensembles

Statt alle 10 Personen in einem Mob:

  • Aufteilung in 2–3 kleinere Mobs (z. B. 3–4 Personen), z. B. entlang von Features, Domänen oder Zielen.
  • Wöchentlicher Austausch oder Cross-Sessions zum gegenseitigen Updaten („Mob Review“).
  • Gute Rotation nach 1–2 Wochen, damit kein Wissen isoliert wird (Stichwort: knowledge silos vermeiden).

Beispiel: Ein Team bei Spotify hat ab Woche 4 ihre Mobs in „Feature-Mobs“ aufgeteilt und alle 2 Wochen durchgemischt.

2. Mob/Pair/Alone-Zyklen

Einige Teams fahren gut mit einem wechselnden Modus:

Wochentag Modus
Mo Mob
Di–Mi Pairs / Alone
Do Mob
Fr Review / Pair Debug / Wissenstransfer

Das erlaubt fokussiertes individuelles Arbeiten, aber auch regelmäßige Syncs und gemeinsamen Code-Review mit Mob-Anteil.

3. Wissenstransfer durch „Mob Review“ oder „Mob Replay“

Wenn nicht alle ständig im Mob sind, kann man regelmäßig kurze Sessions einführen, z. B.:

  • 30min-Session: „Was wurde erreicht?“, mit Screensharing & Walkthrough.
  • Jeder darf Fragen stellen, Ideen einwerfen.
  • So bleibt das Wissen verteilt, auch wenn nur 2–3 aktiv gecodet haben.

4. Entlastung der Senior Leads (Coach statt Treiber)

Gerade bei größeren Teams besteht sonst Burnout-Gefahr.

Empfehlung:

  • Fokus auf Coaching: Fragen stellen, Perspektiven eröffnen, Review geben – aber nicht dauerhaft den Driver/Navigator machen.
  • Junioren moderieren lassen, auch wenn’s holprig wird. Wachstum passiert genau da.

5. Explicit Mob Agreements & Retros

Erfolgreiche Mobs leben von klaren Erwartungen & Feedbackschleifen:

  • Wie lange dauert eine Session?
  • Wer ist Driver? Navigator? Observer? Wer wechselt wann?
  • Wie kommunizieren wir Entscheidungen?

→ Regelmäßige Miro-Retros oder kurze „Mob Health Checks“ (z. B. wöchentlich mit einem simplen Niko-Niko oder Stimmungsbarometer) helfen, frühzeitig Überlastung zu erkennen.

🧭 Vergleichbare Erfahrungsberichte

  1. Llewellyn Falco & Woody Zuill (Mob Programming Erfinder):

    • Empfehlen dauerhaft kleine Mobs mit max. 4–5 Personen.
    • Betonung auf "Mob Programming ist kein Dogma", sondern "Just a tool when it makes sense".

  2. Spotify:

    • Hat Mob Programming erfolgreich in verteilten Teams eingesetzt, aber mit hoher Rotation und wechselnden Modi (Mob/Pair/Individuell).
    • Setzen stark auf „Mob Coaching“ durch Chapter Leads statt dauerhaftes Treiben.

  3. Basecamp / 37Signals:

    • Kein klassisches Mob Programming, aber stark auf kleine Units mit klarem Fokus und regelmäßigen Check-ins.
    • Betonung auf Deep Work und wenig Synchronisation – dafür aber bewusst geplante Sync-Zeiten.

🧠 Empfehlung für euer Team (konkret)

  • 💬 Retrospektive machen: Was läuft gut? Was stresst? Wo braucht ihr Veränderung?
  • 🔀 Aufteilen in 2–3 Mobs mit Rotation (z. B. alle 2 Wochen durchwechseln).
  • 🧭 Klare Erwartungen kommunizieren: Wer darf wann auch allein arbeiten? Wie bleiben wir synchron?
  • 🪴 Rollendefinition anpassen: Weniger Lead-Treiben, mehr Coaching und Selbstorganisation fördern.
  • 📅 Wöchentliche „Show & Tell“ Sessions für Austausch und Teamgefühl.

Wenn du willst, kann ich ein konkretes Vorschlags-Template für eine neue Teamstruktur oder ein leichtgewichtiges Sync-Format liefern.

Konzept: Parallel Hybrid Mobbing

🔁 Kernidee des Konzepts (Hybrid-Modell Mob + individuell)

1. Zwei Gruppen (A/B) arbeiten getrennt, aber:

  • gleicher Wochentakt (Weekly Sync, Review, Retro sind gemeinsam),
  • ähnliche Gesamtverteilung von Mob vs. individueller Arbeit (z. B. 2 halbe Tage Mob, 2 halbe Tage individuell).

2. Asynchrone Reihenfolge:

  • Die Gruppen arbeiten zeitversetzt, um:

    • Ermüdung durch gleichzeitiges Vollzeit-Mobbing zu vermeiden,
    • gegenseitiges Code-Review oder Input zu ermöglichen (z. B. Mob A am Dienstag → Review durch Gruppe B am Mittwoch),
    • Pairings gruppenübergreifend an Donnerstagen zu fördern.

Das ist also bewusst nicht symmetrisch im Tagesplan, aber symmetrisch im Gesamtpensum. Diese Asymmetrie ist ein bewusstes Werkzeug, um mentale Erholung, Rollenrotation und Kontextwechsel zu fördern.

Fazit

Eine dynamische Balance aus Mob-Arbeit und individueller Arbeit, sinnvoll verteilt im Team, um Ermüdung zu vermeiden, Wissen zu teilen, und Feedback-Zyklen zu verbessern.

Wenn ihr aktuell eine Ermüdung durch Mob-only spürt, ist zeitliche Asynchronität zwischen den Gruppen ein Hebel, der oft hilft – muss aber nicht dauerhaft so bleiben. Ich kann euch auch gerne Varianten für 3er-Gruppen, Rollenrotationen oder Mob-Breakout-Strategien skizzieren.

graph TD
    A["Montag: Weekly Sync"] --> B1["Mob Gruppe A: Task 1 starten"]
    A --> B2["Mob Gruppe B: Task 2 starten"]

    B1 --> C1["Dienstag Vormittag: Mob-Session A"]
    B2 --> C2["Dienstag Vormittag: individuelle Arbeit B"]

    C1 --> D1["Dienstag Nachmittag: individuelle Arbeit A"]
    C2 --> D2["Dienstag Nachmittag: Mob-Session B"]

    D1 --> E1["Mittwoch Vormittag: Mob-Session A"]
    D2 --> E2["Mittwoch Vormittag: individuelle Arbeit B"]

    E1 --> F1["Mittwoch Nachmittag: individuelle Arbeit A"]
    E2 --> F2["Mittwoch Nachmittag: Mob-Session B"]

    F1 --> G["Donnerstag: Fokuszeit / freies Pairing"]
    F2 --> G

    G --> H["Freitag: Mob Review"]
    H --> I["Freitag: Team-Retro"]
    I --> A

    subgraph "Rotation (alle 2 Wochen)"
        R1["Mob-Gruppen neu mischen"]
    end

    A --> R1
    R1 --> B1
    R1 --> B2

🧩 Strukturvorschlag: Mob/Individuell Hybrid (2-Wochen-Zyklus)

🧠 Grundprinzipien:

  • Kleine, rotierende Mobs (max. 3–4 Personen)
  • Bewusste Balance: Deep Work + Sync
  • Teamgefühl & Wissensaustausch durch klare Formate
  • Fokus auf Selbstorganisation (weniger getrieben, mehr gestaltet)

📅 Beispiel-Woche (ab Woche 4)

Tag Vormittag Nachmittag
Montag Weekly Sync (30min) Start Mob-Zyklus
Dienstag Mob-Session Gruppe A Individuell (Gruppe B)
Mittwoch Mob-Session Gruppe B Individuell (Gruppe A)
Donnerstag Individuell ggf. Pairing
Freitag Mob Review + Retro (60min) Offene Zeit / Catch-up

🧩 Mob-Gruppen rotieren alle 2 Wochen, sodass jeder mal mit jedem arbeitet und Wissen zirkuliert.

🔁 Formate im Detail

1. 🗓️ Weekly Sync (Mo, 30 Min)

  • Alle zusammen im Call.
  • Ziel: Was wollen wir erreichen? Welche Aufgaben priorisieren wir?
  • Einteilung: Wer ist diese Woche in welcher Mob-Gruppe?
  • Kurzer Check-In zur Stimmung & Energie.

2. 🧑‍🤝‍🧑 Mob-Session (2–3x pro Woche, 90–120min)

  • Feste Slots, jeweils mit 3–4 Leuten.
  • Rollen wechseln regelmäßig: Driver, Navigator, Observer.
  • Fokus: schwierige Tasks, neue Features, pair-learning.
  • Junior als Driver fördern, Seniors eher als Navigators/Coaches.

3. 👤 Individuelles Arbeiten (nachmittags/Do)

  • Fokuszeit für einzelne Tasks, Exploration, Refactoring, Dokumentation etc.
  • Async-Kommunikation per Chat / Issues.
  • Option: freiwilliges Pairing.

4. 📽️ Mob Review + Retro (Fr, 60 Min)

  • Jedes Team zeigt kurz: „Was haben wir gebaut?“ (5–10 Minuten)
  • Fragen, Diskussion, Feedback.
  • Danach kurze Retro: Was lief gut? Was stressig? Was ändern?

5. 🔄 Mob Rotation (alle 2 Wochen)

  • Nach zwei Wochen werden die Mobs neu gemischt.
  • Ziel: Durchmischung, Silos vermeiden, soziales Lernen fördern.

Optional: Ein kleines „Mob Memory“ führen – wer war mit wem schon im Team, welche Themen hat man gemeinsam gebaut?

📌 Rollen & Verantwortungen

Rolle Aufgabe
Mob Facilitator Achtet auf Timebox, Pausen, Rollenwechsel (rollierend pro Session)
Team Coach (Lead) Beobachtet, gibt Feedback, stellt Fragen – aber nicht dauerhaft Navigator
Wissensboten Person aus jedem Mob, die in der Review ihre Gruppe vertritt

🧰 Tools & Hilfsmittel

  • Mob Timer App: z. B. mob.sh oder ein Timer in VS Code.
  • Notion / Miro / GitHub Projects: Für Wissensspeicher und Visualisierung von Aufgaben.
  • Daily Async Updates (optional): 1 Nachricht/Tag im Slack/Teams: "Heute arbeite ich an X, brauche Y."

Möchtest du eine passende Visualisierung (z. B. als Miro-Template oder Mermaid-Diagramm) oder einen Copy-Paste-fertigen Text für euer Confluence oder Onboarding-Dokument?

graph TD
    A["Montag: Weekly Sync"] --> B1["Mob Gruppe A: Task 1 starten"]
    A --> B2["Mob Gruppe B: Task 2 starten"]

    B1 --> C1["Dienstag Vormittag: Mob A"]
    B2 --> C2["Dienstag Vormittag: individuelle Arbeit B"]

    C1 --> O1["Observer B beobachtet Mob A"]
    C2 --> D2["Dienstag Nachmittag: Mob B"]
    D2 --> O2["Observer A beobachtet Mob B"]

    C1 --> D1["Dienstag Nachmittag: individuelle Arbeit A"]

    D1 --> E1["Mittwoch Vormittag: Mob A"]
    D2 --> E2["Mittwoch Vormittag: individuelle Arbeit B"]

    E1 --> O3["Observer B beobachtet Mob A"]
    E2 --> F2["Mittwoch Nachmittag: Mob B"]
    F2 --> O4["Observer A beobachtet Mob B"]

    E1 --> F1["Mittwoch Nachmittag: individuelle Arbeit A"]

    F1 --> G["Donnerstag: Fokuszeit / freies Pairing"]
    F2 --> G

    G --> H["Freitag: Mob Review"]
    H --> I["Freitag: Team-Retro"]
    I --> A

    subgraph "Rotation (alle 2 Wochen)"
        R1["Mob-Gruppen neu mischen"]
    end

    A --> R1
    R1 --> B1
    R1 --> B2

    style O1 fill:#f0f0f0,stroke:#333,stroke-dasharray: 5 5
    style O2 fill:#f0f0f0,stroke:#333,stroke-dasharray: 5 5
    style O3 fill:#f0f0f0,stroke:#333,stroke-dasharray: 5 5
    style O4 fill:#f0f0f0,stroke:#333,stroke-dasharray: 5 5

Erweitertes Konzept

Sehr gerne! Hier kommt eine ausführliche Visualisierung und Beschreibung eines erweiterten Arbeitskonzepts mit mehreren Mobs, inklusive der Rollen Driver / Navigator / Observer, sowie deren zeitlicher Einbettung über mehrere Tage. Dieses Modell ist für ein Team von ca. 10 Personen gedacht, das sich in 2 Gruppen (Mob A / Mob B) aufteilt und Fokus, Wissensaustausch und Nachhaltigkeit ausbalancieren will.

🧱 Strukturprinzipien des Konzepts

  1. Zweiteilung in zwei Mobs (A & B) zur Reduktion von Meeting-Fatigue

  2. Wechsel von synchronem und asynchronem Arbeiten

  3. Explizite Rollenverteilung innerhalb der Mobs:

    • Driver: schreibt Code
    • Navigator: denkt strategisch, gibt Richtung
    • Observer: beobachtet Metaebene

  4. Rollenrotation alle 15–30 Minuten

  5. Feedback- & Sync-Loops:

    • tägliches Micro-Feedback
    • Wochen-Review & Retro

🧭 Zeitlich-strukturelle Darstellung

gantt
    dateFormat  HH:mm
    axisFormat  %H:%M
    title Mob Programming Woche (Gruppen A & B + Rollen)
    
    section Montag
    Weekly Sync         :sync,    09:00, 00:30
    Setup Mob A         :a1,      10:00, 01:30
    Setup Mob B         :b1,      10:00, 01:30
    Individuell A       :a2,      13:00, 02:00
    Individuell B       :b2,      13:00, 02:00

    section Dienstag
    Mob A (D/N/O rollenweise)   :a3, 09:00, 01:30
    Mob B (D/N/O rollenweise)   :b3, 11:00, 01:30
    Fokuszeit (alle)            :f1, 14:00, 02:00

    section Mittwoch
    Mob B (D/N/O rollenweise)   :b4, 09:00, 01:30
    Mob A (D/N/O rollenweise)   :a4, 11:00, 01:30
    Individuell A & B           :ind, 14:00, 02:00

    section Donnerstag
    Observer Sync A/B           :obs, 09:00, 00:45
    Pairing/Fokuszeit           :f2, 10:00, 03:00

    section Freitag
    Mob Review                  :rev, 09:00, 00:45
    Retro (mit Observer-Inputs) :ret, 10:00, 01:00
    Optional: Team-Lunch        :lunch, 12:00, 01:00

🧑‍🤝‍🧑 Rollenverteilung im Mob

Beispiel: Mob A am Dienstag Vormittag (1,5h Session)

Time Slot Driver Navigator Observer
09:00–09:30 Junior A Senior A Junior B (Mob B)
09:30–10:00 Senior A Junior A Junior B (Mob B)
10:00–10:30 Junior B Senior B Junior A (Mob B)

Rollen werden rotierend vergeben. Observer kommen aus der anderen Gruppe, um einen frischen Blick zu erhalten.

🔄 Feedback-Zyklen

Täglich:

  • Nach jeder Mob-Session: 5 Minuten "Observer Insight"

    • Was ist aufgefallen?
    • Gab es Kommunikationspausen, Rollenunklarheiten?
    • Feedback, keine Bewertung

Donnerstag:

  • Observer-Sync (45min): A & B Observer tauschen sich aus
  • Sammlung von Mustern, Problemen, Positivem

Freitag:

  • Mob-Review (Output)

  • Team-Retro (mit strukturiertem Observer-Input)

    • z. B. Karten an der Wand: Codequalität, Kommunikation, Timeboxing, Einbindung, ...

✅ Vorteile

Ziel Wie dieses Modell hilft
Burnout vermeiden Fokuszeit + individuelle Phasen
Wissensaustausch fördern Rollenrotation + regelmäßige Observer
Teamgefühl stärken Gemeinsamer Wochenrhythmus + Retros
Autonomie & Struktur Asynchrone Slots + klar getaktete Mobs

📌 Empfehlungen zur Umsetzung

  • Nutzt Timer-Tools wie Mobster oder VS Code Timer Plugins
  • Führt ein einfaches Mob-Logbuch (z. B. Google Doc oder Notion)
  • Macht Retros auch zur Format-Retro („Wollen wir 2x 45min statt 1x 90min?“)
  • Nutzt eine einfache Visualisierung der Rollen und Rotation (z. B. Whiteboard, digital oder physisch)

Wenn du willst, kann ich dieses Modell auch als Markdown-Template, Confluence-Seite oder als ClickUp/Notion-Board strukturieren – sag einfach Bescheid.

Super! Hier kommt eine vollständige Markdown-Dokumentation, die du als internes Arbeitskonzept in eurem Repo, Wiki oder Knowledge Base verwenden kannst. Außerdem beschreibe ich im Anschluss, wie du dasselbe in Notion oder ClickUp umsetzen könntest, damit du dir ein Bild machen kannst.

✅ Mob-Programming-Arbeitsmodell (2 Mobs, Rollen, Balance)

📌 Übersicht

Wir arbeiten mit zwei Mobs (A & B), einem Wochenrhythmus aus synchroner und individueller Arbeit, sowie mit rollierenden Rollen:

  • Driver: Implementiert den aktuellen Code
  • Navigator: Gibt strategische Richtung
  • Observer: Beobachtet Muster & Metaebene

Rollen rotieren ca. alle 15–30 Minuten. Observer können von außen oder aus dem jeweils anderen Mob kommen.

🧭 Wöchentlicher Ablauf

Tag Vormittag Nachmittag
Montag Weekly Sync, Setup Mobs Individuelle Arbeit
Dienstag Mob A & B (mit Rollen) Fokuszeit (alle)
Mittwoch Mob B & A (umgekehrt) Individuelle Arbeit
Donnerstag Observer Sync (A & B) Pairing / Fokuszeit
Freitag Mob-Review, Retro Team-Lunch (optional)

🧑‍🤝‍🧑 Rollenplan (Beispiel: Mob A Dienstag)

Zeit Driver Navigator Observer (aus Mob B)
09:00–09:30 Junior A Senior A Junior B
09:30–10:00 Senior A Junior A Junior B
10:00–10:30 Junior B Senior B Junior A

🔄 Feedback & Synchronisation

Täglich (Mini-Retro)

  • Direkt nach Mob-Session: 5 Minuten
  • Observer: kurzes strukturiertes Feedback

Donnerstag (Observer Sync)

  • 45 Minuten Austausch der Observer von Mob A & B

  • Sammeln von:

    • Kommunikationsmustern
    • Positivbeispielen
    • möglichen Stolpersteinen

Freitag (Review & Retro)

  • Gemeinsames Anschauen der Arbeitsergebnisse
  • Retro mit Observer-Feedback
  • Optional: Team-Lunch

🔧 Tools & Praktiken

  • Timer: Mobti.me, VS Code Mob-Timer Plugin
  • Logbuch: Google Doc, Notion, Confluence, etc.
  • Kanban/Todo: Notion / ClickUp Board (siehe unten)
  • Visualisierung: Whiteboard / Figma / Miro zur Aufgabenübersicht

📊 Kanban-Struktur für Notion oder ClickUp

Spalten im Board

| Ideen / Backlog | In Mob A | In Mob B | Individuell | Review | Done |

Kartenstruktur (pro Task)

  • Titel: Klarer, handlungsorientierter Titel
  • Beschreibung: Kontext, ggf. Links
  • Rolle (Multiselect): Driver, Navigator, Observer
  • Team (Select): Mob A / Mob B
  • Tag: Montag, Dienstag, …
  • Status (Board-Spalte)
  • Kommentare: für tägliche Mini-Retros

Beispiel-Karte:

**Titel**: „Login-Routing nach erfolgreichem Login optimieren“
**Beschreibung**: 
Aktuell erfolgt Weiterleitung nicht bei JWT-Token Refresh → prüfen & anpassen.
**Rolle**: Navigator, Driver
**Team**: Mob A
**Tag**: Dienstag

📁 Optional: Struktur für Projektordner/Repo

/docs/mob-model/
├── README.md  ← (dieses Dokument)
├── mob-rollen.md
├── retros/
│   ├── 2025-05-16.md
│   ├── 2025-05-09.md
└── logbuch/
    ├── mob-a/
    └── mob-b/

Wenn du willst, kann ich dir gerne ein Notion Template oder ClickUp Export vorbereiten, das du direkt importieren kannst. Möchtest du das? Und welches Tool nutzt ihr aktuell für eure Projektorganisation (z. B. GitHub Projects, Jira, Notion, ClickUp, ...)?

Klasse, danke für den Kontext! Dann bauen wir alles so auf, dass es sich optimal in Forgejo (also Git + Kanban + Tickets/Milestones) integrieren lässt. Ich erkläre dir trotzdem kurz, was Notion und ClickUp sind, damit du es einordnen kannst – und danach bekommst du von mir ein angepasstes Setup, das direkt auf Forgejo zugeschnitten ist.

🧠 Was ist Notion?

Notion ist ein All-in-One-Workspace für Teams, mit dem du:

  • Dokumentation (wie ein Wiki)
  • Projektpläne
  • Kanban-Boards
  • Aufgabenlisten
  • Kalender
  • und sogar einfache Datenbanken

in einer sehr visuell ansprechenden Oberfläche erstellen kannst. Es ist wie eine Mischung aus Google Docs, Trello und Confluence – aber stark modularisiert.

🔗 Beispiel: Du könntest dort euer Mob-Setup als Tabelle pflegen, mit Rollenrotation, Notizen, Aufgaben und Beobachtungen – alles an einem Ort.

⚙️ Was ist ClickUp?

ClickUp ist ein Projektmanagement-Tool wie Jira oder Trello, aber mit sehr vielen Anpassungsmöglichkeiten:

  • Kanban + Gantt + Kalender + Mindmap
  • Aufgaben mit Rollen, Zuständigkeiten, Zeittracking
  • Workspaces und Docs
  • Automation (z. B. „wenn Task erledigt, dann …“)

👉 Es ist ein mächtiges Tool für Teams mit vielen parallelen Aufgaben, braucht aber Einarbeitung.

🧩 Vergleich zu Forgejo

Tool Hauptfunktion Vergleichbar in Forgejo
Notion Dokumentation, Boards, Notizen Wiki + Markdown-Files
ClickUp Aufgaben, Planung, Rollen Kanban + Milestones + Labels
Forgejo Git + Issues + Kanban ✔ Euer Setup passt perfekt

✅ Empfehlung für euer Setup (Forgejo-basiert)

Hier ist, wie ihr das vorgestellte Mob-Konzept mit Forgejo umsetzen könnt:

📁 Git-Struktur im Repo

/docs/mob-programming/
├── README.md                    ← Gesamtkonzept (siehe oben)
├── rollenrotation-2025.md      ← Tabelle mit täglichem Ablauf
├── retros/
│   └── 2025-05-16.md            ← Kurze Lessons Learned je Woche
├── feedback/
│   └── observer-insights.md     ← Zusammenfassung der Beobachtungen

🏷️ Labels für Tickets (Issues)

  • mob:A, mob:B
  • rolle:driver, rolle:navigator, rolle:observer
  • status:ready, status:in mob, status:in review, status:done
  • tag:montag, tag:dienstag, ...

🗂️ Boards

Beispiel: Board „Mob A“

Idee / Backlog Nächste Session In Arbeit Review Done
  • Nutzt hier Tickets mit Rollen- und Zeitangabe in der Beschreibung oder den Labels.

📅 Milestones

  • Woche 20/2025 – Mob Rotation
  • Sprint: UI Login
  • Sprint: Refactor Auth

Wenn du möchtest, kann ich dir:

  • ein README.md Grundgerüst erzeugen (direkt zum Einfügen)
  • eine Beispiel-Ticketstruktur als YAML oder JSON geben (zum Import in Forgejo oder zur Orientierung)
  • ein SVG-Diagramm für Miro/Excalidraw erzeugen (auf Basis eures Wochenplans)

Sag einfach, was du brauchst 😊

Das freut mich sehr – ein leichtgewichtiges, aber wirkungsvolles Logbuch-System ist perfekt, um Wissen zu sichern, Synchronisation zu verbessern und Eigenverantwortung im Team zu stärken – ohne Overhead. Hier kommt eine strukturierte Zusammenfassung, speziell für euer Setup mit Forgejo.

🧭 Ziel des Logbuchs

  • 💡 Wissenssicherung trotz Rotation (Mob ⇄ individuell)
  • 🔄 Synchronisation zwischen Strängen (A/B) und Tagen
  • 👁️ Beobachtungen nutzbar machen, ohne langwierige Meetings
  • ⏱️ Minimaler Aufwand, klar verteilt

🧑‍🤝‍🧑 Rollen & Logbuch-Verantwortung

Rolle Wann wird geloggt? Wo? Inhalt (Beispiele)
🧭 Navigator Während Mob-Sessions (live) Im Issue-Kommentar oder mob-A/2025-05-19.md Kurzes Tagesprotokoll: Was war Ziel? Was wurde gemacht?
👨‍💻 Driver Optional, ergänzend (nur bei Problemen) Im Kommentar oder per Commit-Message Technische Herausforderungen, „Tricks“, Bugs
👀 Observer Nach Session (Dienstag/Mittwoch) Datei feedback/observer-2025-05-21.md Beobachtungen zur Dynamik, Verbesserungsvorschläge
📋 Teamlead Freitags in Retro Datei retros/2025-05-23.md Knappe Lessons Learned, Entscheidungen
🧑‍🔧 Individual Worker Nach Abschluss Task oder Review Direkt im Ticket oder Commit „Ich habe X erledigt, Y gelernt“ oder „⚠️ Achtung bei Z“

🗂️ Struktur im Repo (Markdown-Dateien)

/docs/mob-programming/
├── README.md
├── mob-A/
│   ├── 2025-05-19.md     ← Navigator-Log Montag
│   ├── 2025-05-20.md     ← Navigator-Log Dienstag
│   └── ...
├── mob-B/
│   ├── 2025-05-19.md
│   └── ...
├── feedback/
│   └── observer-2025-05-21.md
├── retros/
│   └── 2025-05-23.md

🧾 Beispiel für ein Navigator-Log (mob-A/2025-05-20.md)

# Mob A – Dienstag, 20.05.2025

**Ziel:** Refactor Auth-Handler & testen edge cases

**Teilnehmer:** Alex (Driver), Robin (Navigator), Kim (Observer)

**Erreicht:**
- Code umgestellt auf `newAuthHandler`
- Edge Case mit expired token abgedeckt
- Test-Fall `auth.spec.ts` ergänzt

**Offen:**
- Token-Refresh behandeln (Ticket #123)
- Review durch Team B vor Merge

**Bemerkung:** Driver hat interessante Lösung für Middleware (siehe Commit f0e1d2)

🧠 Minimal-Checkliste für jeden Tag

Rolle Muss ich heute loggen? Wo?
Navigator ✅ Ja Markdown-Datei im Tagesordner
Observer ✅ Ja (Di/Mi) feedback/observer-*.md
Driver 🟡 Optional Commit-Message oder Kommentar
Teamlead ✅ Freitag retros/*.md
Solo-Worker ✅ Bei Abschluss Kommentar im Ticket oder Commit

💡 Optional: Forgejo Automatisierungsidee

Wenn ihr mit Git-Hooks oder CI rumspielen wollt:

  • Label log:missing auf Tickets, wenn kein Log nach z. B. 24h
  • Release-Milestone „Sprint Logbook 2025-W20“ als Sammelstelle

Wenn du möchtest, kann ich dir ein kleines Bash-Script machen, das eine neue Log-Datei automatisch erstellt (z. B. ./new-log.sh mob-A 2025-05-20) mit vorbefülltem Template. Sag einfach Bescheid.

Perfekt! Hier ist ein kleines Bash-Skript, das dir automatisch ein Tages-Logbuch im gewünschten Format anlegt – inkl. Datum, Mob-Gruppe und Template:

📄 new-log.sh

#!/usr/bin/env bash

# Usage: ./new-log.sh <mob-group> <yyyy-mm-dd>
# Example: ./new-log.sh mob-A 2025-05-20

set -e

MOB_GROUP="$1"
DATE="$2"
BASE_DIR="./docs/mob-programming"
TARGET_DIR="$BASE_DIR/$MOB_GROUP"
FILE="$TARGET_DIR/$DATE.md"

if [[ -z "$MOB_GROUP" || -z "$DATE" ]]; then
  echo "Usage: $0 <mob-group> <yyyy-mm-dd>"
  exit 1
fi

mkdir -p "$TARGET_DIR"

if [[ -f "$FILE" ]]; then
  echo "⚠️  File already exists: $FILE"
  exit 1
fi

cat <<EOF > "$FILE"
# ${MOB_GROUP^} – $(date -d "$DATE" '+%A, %d.%m.%Y')

**Ziel:** _Was war heute das Ziel der Session?_

**Teilnehmer:**
- Driver: _Name_
- Navigator: _Name_
- Observer: _Name_ (optional)

**Erreicht:**
- Punkt 1
- Punkt 2

**Offen:**
- Punkt A
- Punkt B

**Bemerkung:**
- Commit-Referenz oder besondere Erkenntnisse
EOF

echo "✅ Logfile erstellt: $FILE"

✅ Vorteile

  • Immer gleiches Format
  • Kein Nachdenken mehr über Ordnerstruktur
  • Schnell per bash oder make ausführbar

🔧 Optional: ausführbar machen

chmod +x new-log.sh

Und dann z. B.:

./new-log.sh mob-B 2025-05-21

Wenn ihr mögt, können wir auch eine Variante für Observer-Feedback oder die Retro-Logs bauen. Sag einfach Bescheid!