6 min lecture • Guide 795 of 877
Sessions de Mob Programming
Le mob programming rassemble toute l'équipe sur les problèmes complexes. GitScrum aide à coordonner les sessions de mob et suivre leurs résultats.
Bases du Mob Programming
Qu'est-ce que le Mobbing
CONCEPT MOB PROGRAMMING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DÉVELOPPEMENT TRADITIONNEL: │
│ ─────────────────────────── │
│ 4 développeurs → 4 tâches différentes → merge → review │
│ → conflits → bugs → retravail │
│ │
│ MOB PROGRAMMING: │
│ ──────────────── │
│ 4 développeurs → 1 tâche ensemble → bien fait du 1er coup │
│ → pas de review nécessaire → pas de silos de connaissance │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LE MOB: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 👤 👤 👤 👤 ← Navigateurs (réfléchissent, guident)││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────┐ ││
│ │ │ ⌨️ │ ← Driver (tape seulement) ││
│ │ └───────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────────────────────────────────────┐ ││
│ │ │ GRAND ÉCRAN │ ││
│ │ │ (tout le monde voit) │ ││
│ │ └───────────────────────────────────────┘ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DRIVER: Tape ce que les navigateurs disent │
│ NAVIGATEURS: Réfléchissent, discutent, dirigent le driver │
│ ROTATION: Le driver change toutes les 5-10 minutes │
└─────────────────────────────────────────────────────────────┘
Quand Faire du Mob
BONNES UTILISATIONS POUR LE MOBBING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IDÉAL POUR: │
│ ────────── │
│ │
│ DÉCISIONS DE DESIGN COMPLEXES: │
│ "Comment devrait-on architecturer cette feature ?" │
│ L'équipe atteint un consensus en codant │
│ │
│ BUGS DIFFICILES: │
│ "Personne ne peut résoudre ça seul" │
│ Perspectives multiples aident │
│ │
│ ÉTABLIR DES PATTERNS: │
│ "Comment fait-on X dans tout le codebase ?" │
│ Tout le monde apprend le pattern ensemble │
│ │
│ ONBOARDING: │
│ "Nouveau qui doit apprendre notre codebase" │
│ Il observe et participe │
│ │
│ CODE À FORT ENJEU: │
│ "C'est critique et risqué" │
│ Propriété et revue collectives │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PAS BON POUR: │
│ ───────────── │
│ ❌ Tâches simples et routinières │
│ ❌ Recherche indépendante │
│ ❌ Quand l'équipe est trop grande (max 5-6) │
│ ❌ Toute la journée chaque jour (épuisant) │
│ ❌ Quand des boucles de feedback rapides existent déjà │
└─────────────────────────────────────────────────────────────┘
Déroulement d'une Session
Structure de Session
STRUCTURE SESSION MOB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVANT (5-10 min): │
│ ───────────────── │
│ • Énoncé clair du problème │
│ • Contexte pertinent partagé │
│ • Environnement prêt │
│ • Grand écran / projecteur / écran partagé │
│ │
│ PENDANT: │
│ ──────── │
│ • Rotation driver toutes les 5-10 minutes │
│ • Navigateurs discutent de l'approche │
│ • Driver tape ce que le mob décide │
│ • Pauses toutes les 50-60 minutes │
│ │
│ APRÈS (5-10 min): │
│ ──────────────── │
│ • Rétrospective rapide │
│ • Documenter décisions prises │
│ • Identifier travail de suivi │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TÂCHE SESSION MOB: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MOB-001: Designer flux traitement paiement ││
│ │ ││
│ │ PARTICIPANTS: @alex, @jordan, @pat, @sam, @taylor ││
│ │ DURÉE: 3 heures (avec pauses) ││
│ │ ││
│ │ PROBLÈME: ││
│ │ Designer et implémenter le nouveau flux de traitement ││
│ │ paiement avec multiples fournisseurs et logique retry.││
│ │ ││
│ │ OBJECTIF: ││
│ │ Implémentation fonctionnelle + consensus équipe ││
│ │ ││
│ │ PLANNING: ││
│ │ 9:00 - Revue contexte et problème ││
│ │ 9:15 - Discussion design (tableau blanc) ││
│ │ 9:45 - Commencer à coder ensemble ││
│ │ 10:45 - Pause (10 min) ││
│ │ 10:55 - Continuer codage ││
│ │ 11:45 - Clôture, documenter décisions ││
│ │ ││
│ │ ROTATION DRIVER: Toutes les 10 minutes ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Rotation des Drivers
MÉCANIQUE DE ROTATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMER: │
│ ────── │
│ Timer visible réglé sur 5-10 minutes │
│ Quand le timer sonne, rotation driver │
│ Pas d'exception (garde tout le monde engagé) │
│ │
│ ORDRE DE ROTATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 10:00 10:10 10:20 10:30 10:40 ││
│ │ ───── ───── ───── ───── ───── ││
│ │ @alex → @jordan → @pat → @sam → @taylor → ││
│ │ ││
│ │ 10:50 11:00 11:10 ... ││
│ │ ───── ───── ───── ││
│ │ @alex → @jordan → @pat → ... ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CONSEIL: Rotation courte garde tout le monde attentif │
└─────────────────────────────────────────────────────────────┘
Conseils pour Sessions Réussies
FACTEURS DE SUCCÈS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ À FAIRE: │
│ ├── Définir un objectif clair avant de commencer │
│ ├── S'assurer que tous peuvent voir confortablement │
│ ├── Respecter strictement les rotations │
│ ├── Prendre des pauses régulières │
│ ├── Documenter les décisions prises │
│ └── Faire une mini-rétro à la fin │
│ │
│ ❌ À ÉVITER: │
│ ├── Laisser une personne dominer │
│ ├── Sauter les rotations │
│ ├── Sessions trop longues sans pause │
│ ├── Problème mal défini au départ │
│ └── Trop de participants (idéal: 3-5) │
│ │
└─────────────────────────────────────────────────────────────┘
Intégration GitScrum
GitScrum supporte les sessions de mob avec:
- Tâches mob: Type de tâche dédié
- Participants: Suivi de qui a participé
- Durée: Tracking temps investi
- Résultats: Documentation des décisions
- Commentaires: Discussion post-session