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

821 lines
27 KiB
Markdown
Raw Normal View History

feat(solution-track): added ideas created with chatGPT to structure the solution track's mobbing and developing progress
2025-05-18 14:30:52 +00:00
# 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!
Reference in a new issue Copy permalink