Pair programming : le guide ultime

Qu’est-ce que le pair programming ?

Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.

En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.

Photo de Alvaro Reyes sur Unsplash

Cet article est encore en cours de rédaction. Si tu as des suggestions sur ce qui manque, te semble erroné ou si tu te poses encore des questions après avoir lu l’article, tu peux me contacter ici : https://www.linkedin.com/in/benoitgantaume/

Pourquoi travailler en pair programming ?

Quelle drôle d’idée après tout : mettre deux personnes au travail sur une tâche, alors qu’une seule pourrait suffire.

Pourquoi diable y mettre autant d’énergie ?

Si on reste dans une logique productiviste fordienne, cela ne fait aucun sens.
Mais si on prend conscience qu’on est sur une activité complexe, développer un logiciel, qui nécessite des interactions hautement complexes, des humains qui bossent ensemble, on se rend compte que ce n’est pas si stupide.

Deux paires de bras qui travaillent ensemble vont apporter un gain linéaire : 1 + 1 = 2.
Hors, développer demande d’utiliser principalement son cerveau. Et quand deux cerveaux réfléchissent ensemble, le gain n’est plus linéaire.
Parfois 1 + 1 = 11.
Par moments 1 + 1 = 0.

Donc la première raison de travailler en pair programming est que les solutions apportées vont être beaucoup plus riches et le code de bien meilleure qualité.

La deuxième raison est de faire circuler la connaissance.
N’as-tu jamais été stressé à l’idée de partir, toi ou un collègue en vacances ?
Si tu veux pouvoir partir tranquille, il vaut mieux éviter d’être le seul détenteur d’une connaissance. Ça tombe bien, le pair programming est un formidable circulateur de connaissance.

Enfin, d’un point de vue humain, cela permet d’aller à la rencontre de ses collègues d’une manière plus profonde. Mais ce point peut être à double tranchant. On en parle plus bas.

Comment travailler en pair programming ?

Dans le pair programming des origines, les ordinateurs étaient encombrants, onéreux, et les outils de communication peu répandus. Donc on bossait à deux, l’un à côté de l’autre, sur le même ordinateur. Il n’y avait qu’un clavier/souris et une seule personne touchait le clavier pendant que l’autre réfléchissait avec lui.

Aujourd’hui, les ordinateurs portables sont répandus et les outils de communication beaucoup plus développés grâce aux connexions fibrées.

On peut donc élaborer d’autres manières de binômer.

En mode classique

J’ai beaucoup aimé travailler dans ce mode. A deux, simplement derrière un ordinateur.

Certaines expériences de pair programming ont été des sessions de travail intenses, autant d’un point de vue cognitif qu’émotionnel.

A force de travailler ensemble, les cerveaux s’harmonisent. On finit par connaître tellement bien son partenaire que l’on peut anticiper son prochain mouvement. Une fois, j’avais atteint un tel niveau de complicité avec mon binôme que je pouvais gérer la souris pendant qu’il tapait au clavier, et c’était parfaitement fluide.

Je ne sais pas si tu imagines le niveau de fusion qu’il faut pour y arriver. Si tu veux t’en rendre compte, essaie avec un collègue : tu bosses à la souris et lui au clavier. Tu me diras…

J’avais l’impression de danser avec mon partenaire. Il y avait de l’engagement, de la technique et le plaisir de travailler à deux.

Mais j’avoue que je n’ai plus retrouvé ça depuis.

A deux, à côté, chacun son ordinateur

Aujourd’hui, c’est ma manière préférée de travailler en pair programming : Je retrouve le lien d’intimité avec mon binôme, et chacun a accès à ses ressources.

Un seul garde le contrôle à un moment donné, mais l’autre peut aller fouiller dans le code ou chercher des ressources sur internet pour alimenter la réflexion. Un peu comme un copilote de voiture qui gère la carte. 

Sinon je suis souvent frustré de ne pas comprendre tel ou tel point. Si nos cerveaux ne sont pas parfaitement alignés, j’ai l’impression de tourner au ralenti et ça m’agace.

A deux, à distance

Là, pas le choix : chacun a son ordinateur.

Celui qui pilote partage son écran, l’autre peut suivre.

Pour moi, ça reste un mode dégradé : je préfère la présence physique pour binômer. C’est déjà assez fatigant, inutile d’y ajouter le poids de la visio.

Par contre, si ce n’est pas possible de se retrouver physiquement, ça reste une option viable. Par contre, je fais des pauses plus fréquentes et plus longues pour compenser la fatigue accrue.

A plusieurs

C’est ce qu’on appelle le mob-programming. Je le vois comme une extension du pair programming, sauf qu’au lieu de le faire à deux, on le fait à plusieurs.

C’est un mode de travail que j’ai peu pratiqué personnellement en tant que dev. Par contre, je l’ai utilisé en coaching avec des équipes. J’ai remarqué des capacités très disparates des équipes à utiliser ce mode de travail qui semble prometteur.

Suite à cet article, j’ai pas mal échangé avec Hadrien qui a pas mal bossé en mob. Et on s’est dit que ça serait cool de créer une super ressource sur la question : on te dit tout dans cet article sur le mob-programming.

Qui pilote en pair programming ?

L’image avec le rallye de voiture est celle qui me parle le plus : on a un pilote qui tient le volant. Il est concentré sur la route et assure que la voiture aille là où il faut. 

Le copilote suit la carte et anticipe puis annonce les difficultés.

Bon, c’est comme ça que je vois les choses. Je suis convaincu que je rate plein de nuances.

Je garde de cette image qu’il y en a un qui est collé à au code : le pilote. Le copilote, quant à lui, est là pour prendre du recul et réfléchir avec le pilote.

Le pilote a le nez collé à la route, le copilote prend de la hauteur de vue.

C’est la combinaison de ses deux points de vue qui permet d’aller vers l’objectif.

Par contre, la différence, c’est que le pilote reste toujours pilote. Le copilote toujours copilote. On n’a jamais vu une voiture de rally s’arrêter pour que les deux compères échangent leur place.

Dans le pair programming, si.

Il existe différentes manières de gérer cette alternance. Le mode le plus classique est de se donner une boite de temps, par exemple 15 mins, et d’échanger les rôles quand le temps est terminé.

On peut aussi échanger selon que l’on écrive le code de production ou le code de test : le testeur écrit un test. Le codeur le fait passer et repasser la main au testeur.

Je suppose qu’on peut imaginer d’autres déclencheurs de cette alternance. Mais le plus important, c’est qu’il y a ait cette alternance.

Il faut vraiment échanger régulièrement les rôles de pilote et copilote. Sinon une certaine facilité s’installe et la pratique perd de ses bénéfices.
A mes yeux, 30 mins semblent être un maximum.

Comme toujours, il y a des exceptions que j’évoque plus bas.

Mentorer en pair-programming

Le pair programming est une excellente manière de mentorer quelqu’un. Mais à vrai dire, ce n’est pas vraiment ce que j’appelle binômer si une seule personne reste active. Même s’il y a un écart de niveau important, il est essentiel pour la pratique que les rôles de pilote et copilote alternent. Sinon ce n’est plus du binomage, juste du mentorat.

Quand ne pas alterner les rôles ?

Je viens de passer plusieurs paragraphes à te conseiller de faire tourner les rôles et que même si les rôles ne tournent pas, c’est pas vraiment du pair-programming.

Il y a pourtant une situation que j’ai vécue et qui a mieux fonctionné à mon sens en ne changeant pas les rôles.

On avait une feature à développer. J’avais une très bonne connaissance du métier et mon binôme était bien meilleur que moi sur la stack.

Il est resté pilote et moi co-pilote. Je le guidais dans ce qu’il fallait faire. J’anticipais les points de blocage en lisant le code par endroits alors qu’il codait un algorithme un peu pointu.
N’ayant pas de velléité à monter en compétence sur la stack, cela a très bien fonctionné.

J’imagine que cela peut ressembler à ça quand on binôme avec un profil non développeur, comme un UX designer, un testeur ou un métier.

Je n’ai jamais testé de mixer les métiers en pair-programming, mais pourtant je pense que c’est une voie très intéressante à creuser pour faciliter la porosité des idées entre les différents rôles.

Si tu as du retour sur ça, je prends aussi.

Les difficultés à travailler en pair programming

L’ego

Le premier ennemi à mon sens est l’ego. 

Quand tu bosses en pair, tu te mets un peu à nu. Tu invites l’autre dans ton environnement de travail.

Certaines questions sont assez symptomatiques des premières sessions de binomage, comme : 

“Tiens tu utilises quel mapping clavier ?

Bepo, tiens je ne connaissais pas”

Pour peu que le binôme soit sous un autre OS ou un autre IDE, il faudra dévoiler son quotidien et surtout ses lacunes.

“Ah ! Tiens, tu n’utilises pas les raccourcis clavier toi ?”

Et voilà une petite aiguille plantée dans l’ego de son binôme.
Attention donc à y aller tout en douceur.

Quand il faudra trouver des solutions techniques à un problème, il est très possible que chacun des deux binômes ait sa propre idée. Parfois, une solution est objectivement meilleure que l’autre. Si les deux sont capables de le reconnaître, alors c’est bon.

Parfois les deux solutions seront équivalentes. Laquelle choisir à ce moment ?

Si l’ego s’en mêle, le binôme passera plus de temps à discuter de qui a raison qu’avancer.
Attention donc à débarrasser la relation de l’ego qui pourrait étouffer la pratique.

L’intimité

On a déjà parlé, juste avant, de l’intimité de partager son environnement de travail.

Mais quand on travaille de pair à côté l’un de l’autre, on partage aussi son intimité physique : on entre dans une sphère particulière qui est celle de la proximité physique, à moins d’un mètre. C’est une zone dans laquelle seules les personnes de confiance peuvent entrer. 

Dans cette zone, les odeurs corporelles, agréables ou non, sont perceptibles. On peut facilement toucher son binôme sans forcément le vouloir.

Cette proximité physique n’est pas forcément facile à tenir sur la durée. Car oui, on a probablement tous fait l’expérience d’un collègue qui vient s’asseoir à côté de nous pour travailler sur un sujet.

Mais l’avez-vous fait pendant 6h d’une journée, plusieurs jours de suite ?

Ca fatigue

C’est peut-être le point le plus difficile car cela persiste. On peut travailler sur son ego et apprendre à découvrir son binôme avec sincérité. Par contre cela reste un exercice fatigant, même avec l’expérience. La seule différence est qu’on en prend l’habitude.

Ce qu’il faut comprendre, c’est que dans le travail en pair-programming, chacun est concentré en permanence. Quand je bosse seul, il m’arrive d’avoir des coups de mou, et d’aller butiner sur internet ou aller consulter mes emails pour faire quelque chose moins engageant intellectuellement.

Alors qu’en binôme, on est toujours sur la brèche : le regard de l’autre nous pousse à rester concentré et actif.

J’ai d’ailleurs fait un podcast avec … sur ce point très précis. Si ça te dit de l’écouter, je te mets l’épisode ici :

Pour moi ce n’est pas parce que c’est difficile qu’il faut renoncer. Au contraire, c’est bien le job d’un pro de faire ce qui est difficile à faire.

Par contre si tu démarres le pair programming et que tu n’en n’as pas encore l’habitude, je te conseille d’y aller doucement. Commence une heure par jour, puis deux, puis trois…

Augmente progressivement jusqu’à trouver un bon équilibre entre la fatigue générée et l’efficacité du travail.

Personnellement, je ne binôme pas plus de 5 à 6h par jour au maximum. C’est trop fatigant et la qualité du travail finit par s’en ressentir. Sans compter qu’il faut laisser un peu de temps pour les tâches personnelles comme répondre aux emails ou faire des pauses pour recharger les batteries.

Combien ça coûte de travailler en pair-programming ?

Ou sa variante : est-ce que ça coûte deux fois plus cher de faire la même chose ?

Spoiler : non.

Travailler en binôme ne coûte pas plus cher, c’est probablement l’inverse à mon sens : travailler en binôme fait gagner de l’argent à l’entreprise.
Par contre ça prend plus de temps homme alors que c’est plus rapide.

Quoi ? Ça prend plus de temps, mais ne coûte pas plus cher  et c’est plus rapide ?En fait, tout dépend de la variable que l’on mesure.

Si on considère le temps d’exécution, on va clairement plus vite à deux. Malgré mon expérience, c’est difficile à quantifier car ce n’est pas linéaire : quand deux cerveaux se mettent à réfléchir ensemble à un problème, démarre un phénomène d’entraînement qui fait aboutir beaucoup plus vite à une solution.

Si on considère le temps pris, on bosse certes plus vite, mais on est deux. Sur la base de mon expérience, j’ai un ratio pas du tout scientifique ni objectif de x1,5.
Pour moi, la même tâche faite en binôme coûte 1,5 fois le prix de la tâche faite par une seule personne.

Si on s’arrêtait là, on pourrait penser que le pair programming est une tâche qui coûte cher.

Mais en vérité, sur la durée, l’entreprise reste gagnante : les revues de code se font en direct, la qualité de code augmente drastiquement et la connaissance circule beaucoup mieux dans les équipes.

Tout ça fait que l’équipe est plus véloce et plus résiliente. 

Le “surcoût” est en fait un investissement dans des choses moins visibles et pourtant essentielles sur le long terme.

Pair programming et software craftsmanship

Le pair programming est une pratique totalement intégrée dans le software craftsmanship.

Si tu veux en savoir plus sur ce mouvement, viens consulter l’article dédié au software craftsmanship.