6 min lecture • Guide 835 of 877
Pratiques de Mob Programming
Un clavier, toute l'équipe. GitScrum aide à coordonner les sessions de mob et suivre leur impact sur la qualité et les capacités de l'équipe.
Bases du Mob Programming
Comment Ça Marche
MOB PROGRAMMING EXPLIQUÉ:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LA CONFIGURATION: │
│ ───────────────── │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ │ │
│ │ GRAND ÉCRAN │ │
│ │ │ │
│ └───────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌────┐ ┌────┴────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑💻 │ │ 🧑 │ │
│ │ │ │ DRIVER │ │ │ │
│ └────┘ └─────────┘ └────┘ │
│ Navigateur Tape Navigateur │
│ seulement │
│ ┌────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑 │ │
│ │ │ │ │ │
│ └────┘ └────┘ │
│ Navigateur Navigateur │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÔLES: │
│ ────── │
│ DRIVER: Tape le code, ne décide pas quoi taper │
│ NAVIGATEURS: Dirigent le driver, discutent des solutions │
│ │
│ "Pour qu'une idée entre dans l'ordinateur, elle doit │
│ passer par les mains de quelqu'un d'autre." │
└─────────────────────────────────────────────────────────────┘
Structure de Session
Déroulement d'une Session
DÉROULEMENT SESSION MOB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STRUCTURE SESSION (2 heures): │
│ ───────────────────────────── │
│ │
│ 0:00 - 0:05 SETUP │
│ • Définir objectif de session │
│ • S'assurer que tous voient l'écran │
│ • Premier driver au clavier │
│ │
│ 0:05 - 0:50 TRAVAIL MOB (Bloc 1) │
│ • Rotation driver toutes 10-15 min │
│ • 3-4 rotations │
│ • Navigateurs guident le travail │
│ │
│ 0:50 - 1:00 PAUSE │
│ • Se lever, s'étirer, bio pause │
│ • Sync rapide sur progression │
│ │
│ 1:00 - 1:50 TRAVAIL MOB (Bloc 2) │
│ • Continuer les rotations │
│ • 3-4 rotations supplémentaires │
│ │
│ 1:50 - 2:00 CLÔTURE │
│ • Qu'avons-nous accompli ? │
│ • Qu'est-ce qui reste ? │
│ • Comment la session s'est-elle passée ? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIMER: │
│ ────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🕐 Rotation driver: 12:00 ││
│ │ ││
│ │ Driver actuel: Alex ││
│ │ Prochain: Jordan ││
│ │ ││
│ │ [Timer visible pour tous] ││
│ │ [Rotation stricte, pas d'exception] ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Quand Utiliser le Mob
Meilleurs Cas d'Usage
QUAND LE MOB PROGRAMMING EXCELLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ CAS À HAUTE VALEUR: │
│ ────────────────────── │
│ │
│ PROBLÈMES COMPLEXES: │
│ "C'est trop difficile pour une seule personne" │
│ → Perspectives multiples trouvent meilleures solutions │
│ │
│ TRANSFERT DE CONNAISSANCES: │
│ "Seul Sam sait comment ça marche" │
│ → Tout le monde apprend en faisant ensemble │
│ │
│ ONBOARDING: │
│ "Nouveau membre qui rejoint l'équipe" │
│ → Apprendre codebase, pratiques, relations │
│ │
│ CODE CRITIQUE: │
│ "Ça ne peut absolument pas avoir de bugs" │
│ → Plusieurs reviewers en temps réel │
│ │
│ DÉCISIONS DE DESIGN: │
│ "On doit se mettre d'accord sur l'architecture" │
│ → Construire le consensus en construisant │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ MOINS EFFICACE POUR: │
│ ────────────────────── │
│ │
│ TRAVAIL ROUTINIER: │
│ Tâches simples, bien comprises │
│ → Le travail solo est plus efficace │
│ │
│ TÂCHES PARALLÈLES: │
│ Travail indépendant sans chevauchement │
│ → Séparez et mobbez seulement sur l'intégration │
│ │
│ RECHERCHE APPROFONDIE: │
│ Phase d'exploration initiale │
│ → Recherche individuelle, mob sur synthèse │
│ │
│ ÉQUILIBRE: Pas tout, pas rien │
│ Mobbez stratégiquement, solo quand approprié │
└─────────────────────────────────────────────────────────────┘
Rôles Driver/Navigateur
RÔLES DRIVER ET NAVIGATEUR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LE DRIVER: │
│ ────────── │
│ RESPONSABILITÉS: │
│ • Tape ce que les navigateurs dirigent │
│ • Pose des questions de clarification │
│ • Reste focalisé sur la tâche actuelle │
│ │
│ À NE PAS FAIRE: │
│ • Prendre des décisions sur quoi taper │
│ • Avancer sans direction │
│ • Dominer la conversation │
│ │
│ LES NAVIGATEURS: │
│ ──────────────── │
│ RESPONSABILITÉS: │
│ • Réfléchir au problème │
│ • Discuter de l'approche │
│ • Diriger le driver clairement │
│ • Poser des questions, suggérer des alternatives │
│ │
│ NIVEAUX D'ABSTRACTION: │
│ ├── Haut: "On doit gérer le cas d'erreur" │
│ ├── Moyen: "Ajoute un try-catch autour de ça" │
│ └── Bas: "Tape 'try {' puis retour à la ligne" │
│ │
│ Adaptez selon expérience du driver │
└─────────────────────────────────────────────────────────────┘
Métriques et Suivi
┌────────────────────────────────────────────────────────────────┐
│ MOB PROGRAMMING - Suivi Impact │
├────────────────────────────────────────────────────────────────┤
│ │
│ SESSIONS CE MOIS: │
│ ├── Total sessions: 8 │
│ ├── Heures totales: 18h │
│ └── Participants moyens: 4.2 │
│ │
│ RÉSULTATS: │
│ ├── Bugs trouvés post-mob: 2 (vs 8 solo) ✅ │
│ ├── Revues code nécessaires: 0 ✅ │
│ ├── Connaissances partagées: 12 topics ✅ │
│ └── Satisfaction équipe: 4.3/5 ✅ │
│ │
│ TÂCHES TRAITÉES EN MOB: │
│ ├── Architecture payment v2 ✅ Terminé │
│ ├── Onboarding nouvel employé ✅ Terminé │
│ ├── Bug critique auth ✅ Résolu │
│ └── Établir patterns API 🔄 En cours │
│ │
└────────────────────────────────────────────────────────────────┘
Intégration GitScrum
GitScrum supporte le mob programming avec:
- Tâches mob: Type de tâche spécifique
- Suivi participants: Qui a participé
- Durée sessions: Temps investi
- Résultats: Documentation décisions
- Métriques: Impact sur qualité