820 lines
27 KiB
Markdown
820 lines
27 KiB
Markdown
|
||
# 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](https://spotify.design/article/2022-04-20_mob-programming-the-spotify-way) 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.
|
||
|
||
|
||
```mermaid
|
||
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](https://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?
|
||
|
||
```mermaid
|
||
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
|
||
|
||
```mermaid
|
||
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](https://mobti.me/) 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](https://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
|
||
|
||
```text
|
||
/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
|
||
|
||
```text
|
||
/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)
|
||
|
||
```plaintext
|
||
/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`)
|
||
|
||
```markdown
|
||
# 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`
|
||
|
||
```bash
|
||
#!/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
|
||
|
||
```bash
|
||
chmod +x new-log.sh
|
||
```
|
||
|
||
Und dann z. B.:
|
||
|
||
```bash
|
||
./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!
|