Le Pair Programming, popularisé par Kent Beck grâce à l’Extreme Programming (XP), prend une place de plus en plus importante dans les organisations IT. Cette méthodologie trouve cependant un écho défavorable auprès de certaines personnes, principalement car ses avantages sont mal perçus ou bien incompris. Nous allons tenter dans cet article de comprendre l’intérêt et les avantages du Pair et Mob Programming pour une équipe et plus globalement pour un projet.

Pair Programming ?

Le concept consiste à programmer à 2 personnes (Pair) ou à plusieurs (Mob), généralement avec toute l’équipe. Des rôles sont définis pour savoir qui tient le clavier et qui observe/dirige le développement (Driver/Navigator), et des rotations sont mises en place pour inverser les rôles. Nous n’allons pas ici détailler les différentes formes de Pair Programming (Ping-Pong, Strong-Style), vous trouverez notamment plus d’informations sur ce lien, avec des préconisations sur la mise en œuvre. 

Rentrons maintenant dans le vif du sujet : que peut nous apporter la pratique du Pair et Mob Programming ?

 

5 avantages à retenir

 

Un impact positif sur le code produit

Développer à 2, c’est bénéficier d’un exercice où 2 cerveaux vont collaborer efficacement pour challenger leur point de vue, partager leurs questionnements, et imaginer la solution la plus adéquate à un contexte donné. C’est aussi réduire les temps de blocage sur une problématique et prévenir les risques liés aux “Sunk Costs” : en développant seul, lorsqu’on rencontre des difficultés sur un problème depuis plusieurs heures, comme on a déjà investi beaucoup de temps, on a envie de continuer jusqu’à trouver une solution (et donc on aggrave la situation).

Travailler à plusieurs sur une tâche va optimiser les chances d’arriver à un résultat plus abouti en termes de design et de code produit, qui nécessitera probablement peu de rework plus tard. L’exercice engendre par nature une revue de code en temps réel, puisqu’une seule personne tient le clavier. Il diminue aussi les risques d’over-engineering, tous les participants à la session étant les garants d’un code minimal et compréhensible à la fin de la tâche.

 

Moins de bugs introduits

Même si c’est difficile à généraliser, plusieurs études ont depuis le début des années 2000 mis en lumière l’impact bénéfique du Pair Programming sur le nombre de bugs. Les pairs ont tendance à écrire du code qui contient moins de bugs que les personnes seules. Aucun chiffre universel ne peut être établi évidemment, mais en a-t-on vraiment besoin pour se convaincre ?  

Puisque le résultat produit est plus abouti à 2, qu’une revue de code a été faite en temps réel, on peut ainsi présumer que la qualité globale du travail réalisé est supérieure à un travail réalisé seul. Ce sont tous ces mécanismes qui permettent de prévenir le risque de bugs introduits dans notre code.

 

Un partage de connaissance

Nous avions déjà parlé de ce point lors d’un précédent article sur la revue de code. Le Pair/Mob Programming est un exercice de communication entre développeurs d’une même équipe. Cette communication inclut de la transmission sur des savoir-faire techniques mais aussi sur la manière dont certaines parties de code sont structurées et conçues.  

Participer à une session de Pair Programming sur du code sur lequel on n’est pas familier est un très bon moyen d’augmenter la propriété collective du code, évitant d’avoir des silos de connaissances au sein d’une équipe. La personne qui relit le code en temps réel peut proposer des alternatives sur la façon d’écrire le code, et on devine facilement le processus d’apprentissage qui peut avoir lieu ici.

 

Une meilleure cohésion d’équipe

On ne le dira jamais assez, le développement logiciel est un travail d’équipe. Pratiquer le Pair/Mob Programming est vertueux pour la dynamique collective et pour consolider les liens entre chaque personne. Les sessions de Pair Programming ont un impact positif sur le moral des équipes. Le fait de communiquer et de partager de la connaissance consolide le bien-être de tout le monde ! C’est également un retour que nous avons fréquemment avec les Ateliers Craft de Promyze.

Trouver ensemble des solutions à des problèmes et parvenir à un résultat de meilleure qualité plus rapidement génèrent une forme de satisfaction. Cela renforce la conviction d’un accomplissement collectif dans le travail réalisé, et que nous ne sommes pas des personnes isolées qui doivent résoudre des problèmes chacun dans leur coin.

 

Un meilleur “focus”

Cela peut paraître secondaire de mentionner ce point, mais plusieurs études ont également mis en évidence que développer à plusieurs présente l’avantage d’augmenter la concentration des participants et diminuer les risques de distraction. L’idée est simple : seul, on peut avoir tendance à plus facilement se laisser perturber par une notification, un mail, à switcher d’onglets, bref à quitter son IDE pour d’autres sujets. A plusieurs, il semble y avoir un effet où les gens, désireux de ne pas perturber la session de Pair/Mob Programming, vont moins se laisser distraire et rester plus concentrés sur la tâche en cours. Cela atténue finalement l’effet de “Context Switching”, qui pour le coup peut faire perdre du temps. 

Cela soulève également l’importance de mettre des limites de temps dans les sessions, pour justement permettre à chaque personne d’avoir du temps pour soi et décompresser !

Et la productivité dans tout ça ? 

On touche là un sujet sensible lorsque l’on parle avec des personnes plutôt réticentes à mettre en œuvre du Pair/Mob Programming. Elles vont avoir l’impression que le projet va coûter plus cher car on va mettre plus de temps à livrer des fonctionnalités. 

Dans le développement logiciel, la productivité est un concept délicat. Peut-on la mesurer en fonction du temps pour compléter une tâche ? Pas seulement. Car au final, notre objectif n’est-il pas de produire du code qui marche d’un point de vue fonctionnel, mais aussi qui soit durable et surtout testé ? Auquel cas, est-ce que la productivité ne reviendrait pas à mesurer le temps pour finir la tâche, le temps qu’il faudra plus tard à une autre personne pour comprendre et retravailler le code, le temps qu’il faudra pour corriger les éventuels bugs survenus dans le code, etc… ? 

Certaines études ont démontré que des pairs mettaient plus de temps à finir une tâche que des personnes seules, mais cet overhead était néanmoins assez faible (15 % en moyenne selon les études). Encore une fois, cette donnée est court-termiste et difficilement généralisable, car comme nous l’avons dit, il faut prendre en compte le contenu du travail produit (architecture, design, …), pas seulement le temps. 

Ce ne serait pas plus simple si on parallélisait les tâches ? 

Et bien nous aurions tendance à vous répondre “oui” si le développement logiciel était une activité consistant à réaliser un ensemble de tâches dont l’exécution est précisément connue et détaillée à l’avance. Ce n’est pas bien entendu pas le cas, et comme tout métier d’ingénierie, les solutions à un problème donné sont diverses et s’affinent au fur et à mesure que l’on avance dans le code.

Comme l’a très bien expliqué Woody Zuill, “It’s in the doing of the work that we discover the work we must do”. On pourrait même parler du #NoEstimate, mais ce serait dévier un peu du sujet qui nous intéresse. Le développement est fait d’imprévus et de problèmes à surmonter, donc aucune recette connue à l’avance.

Faut-il toujours faire du Pair programming ? 

Il s’avère que certaines tâches triviales, comme des correctifs de bugs mineurs dont la résolution est connue, ne présentent pas forcément une grande valeur ajoutée à être exécutées à plusieurs. Certaines études ont également mis en lumière que même si la dimension sociale est appréciée par les équipes, certaines personnes apprécient aussi de pouvoir développer seule de temps en temps. C’est notamment le cas de profils “Junior”, pour qui arriver à compléter une feature par eux-mêmes leur permet d’engranger de la confiance et de l’assurance. 

Un bon moyen de savoir si la session a toujours de l’intérêt est de voir si les participants sont toujours concentrés et attentifs aux échanges. Nous avons le droit, au bout de quelques heures, de ne plus se sentir productif et de laisser les autres poursuivre la session.

Quelques points de vigilance..

Le Pair Programming, comme beaucoup de méthodologies dans notre domaine, n’est pas une “silver bullet”. Ce n’est pas parce qu’on le fait que tout va s’améliorer. Comme d’autres méthodologies (Revue de code ou TDD par exemple), si on n’applique pas les bonnes recettes, peu de chances d’obtenir des gains. 

Il est important au préalable d’expliquer la démarche et les objectifs recherchés. Il faut aussi prendre en compte les personnalités de chaque personne, notamment quand on fait du Mob Programming. Certaines personnes peuvent trouver cela intimidant de coder devant le reste de l’équipe. D’autres ont peur d’être jugées si elles souhaitent quitter une session de Mob. Certains profils plus expérimentés peuvent également se lasser de passer tout leur temps à accompagner des plus juniors, et auront besoin dans la semaine d’avoir du temps pour eux pour travailler sur d’autres sujets. C’est un équilibre à trouver.

En conclusion !

L’objectif n’est pas de passer de 0 à 100 % de pair programming en quelques semaines dans l’équipe, mais de positionner le bon curseur pour son équipe. Pour cela, il est primordial de partager les objectifs et les attendus de cette démarche et de recueillir en continu le feedback de l’équipe sur son ressenti. C’est encore le principal moyen d’identifier les ajustements à apporter pour tirer parti des sessions de Pair Programming.

Pour aller plus loin, nous vous invitons à regarder ce webinar que nous avons consacré au sujet début 2021.