Pair et Mob programming¶

Travailler ensemble en temps réel — en presentiel et en remote — pour résoudre des problèmes complexes et transferer la connaissance.

Pair programming¶

Le pair programming consiste à travailler a deux sur le même poste (ou le même écran) en alternant des rôles définis.

Les rôles : driver et navigator¶

graph LR
    D["Driver\n(clavier)"] -->|"ecrit le code"| C["Code"]
    N["Navigator\n(vue d'ensemble)"] -->|"guide, questionne, anticipe"| D
    C -->|"rotation toutes les 10-25 min"| N

La rotation régulière (10 a 25 minutes) evite la fatigue cognitive et assure que les deux personnes restent actives.

Quand pratiquer le pair programming¶

Le pair programming a un coût horaire double — il faut qu'il soit justifie.

Bon usage :

• Problèmes complexes ou mal définis (explorer ensemble plutôt que seul dans l'impasse)
• Onboarding d'un nouveau membre sur une partie critique du codebase
• Transfert de connaissance avant un départ ou une rotation d'équipe
• Debuggage difficile ("rubber duck" avec les droits de réponse)
• Premier jet d'une API ou d'une architecture importante

Usage deconseille :

• Tâches repetitives et bien définies que chacun maîtrise
• Tâches necessitant une longue phase de recherche solitaire
• Quand un des deux participants n'est pas disponible mentalement

Pair programming en remote¶

Le remote change la logique mais pas les principes.

Outils recommandes¶

Mob programming¶

Le mob programming etend le pair à toute l'équipe : une seule machine, toute l'équipe sur le même problème.

Format standard¶

• 1 driver : au clavier, exécuté les instructions
• 1 navigator actif : donne les instructions au driver
• N observers : suivent, prennent des notes, se preparent a naviguer
• Rotation : toutes les 5 a 15 minutes, chrono strict

sequenceDiagram
    participant A as Alice (driver)
    participant B as Bob (navigator)
    participant C as Carol (observer)
    participant D as David (observer)

    B->>A: "Cree une fonction validate_email"
    A->>A: ecrit le code
    Note over A,D: Rotation (timer)
    A->>B: devient navigator
    B->>C: devient driver
    C->>C: ecrit le code
    B->>C: "Ajoute un test pour l'email vide"

Quand utiliser le mob programming¶

• Démarrage d'un projet : aligner l'équipe sur les choix fondateurs
• Rétrospective technique sur un bug critique
• Formation sur un nouveau framework ou pattern
• Décisions d'architecture qui concernent toute l'équipe
• Deblocage d'un problème sur lequel un dev est coince depuis longtemps

Comparaison solo / pair / mob¶

Bonnes pratiques communes¶

Avant la session :

• Definissez l'objectif : qu'est-ce qu'on veut avoir fait à la fin ?
• Configurez l'environnement : IDE, raccourcis, polices lisibles pour tous
• Decidez de la durée et du rythme de rotation

Pendant la session :

• Le driver ne prend pas d'initiative non demandee par le navigator
• Les desaccords se résolvent par un vote rapide ou une experimentation, pas un debat
• Respectez les rotations même si "c'est juste deux lignes"

Après la session :

• Commitez et documentez les décisions prises
• Notez ce qui reste a faire si la session s'arrêté avant la fin
• Courte rétrospective : qu'est-ce qui a bien marche ? qu'est-ce qu'on change ?

Points clés¶

• Driver et navigator ont des responsabilités distinctes — la rotation est obligatoire
• Le pair en remote nécessité des outils adaptés et des pauses fréquentes
• Le mob est coûteux en temps mais extremement efficace pour l'alignement et le partage
• Choisissez le mode en fonction du problème, pas par habitude
• Commencez par de courtes sessions pour adopter progressivement la pratique

Précédent : Code review | Suite : Conventions d'équipe