Qu’est-ce donc ?

Vous connaissez déjà le Pair-Programming, je vais faire appel à vos souvenirs… Attention

Boum !    

Nous revoilà sur les bancs de l’école pour un court moment, et c’est maintenant l’heure du TP en binôme. Le pair-programming consiste, comme son nom l’indique, à programmer à deux (ou plus !) sur un même environnement de travail.

Pourquoi faire du pair-programming ?

Des écueils avec le Pair Programming ?

Les habitudes !

Parfois le confort de coder seul sans la pression du carton jaune est difficile à abandonner. Il peut être compliqué de sortir de ses habitudes et d’accepter de travailler en binôme alors que nous avons eu l’habitude d’être seul en tête à tête avec notre IDE. De plus, commenter le code d’une autre personne, surtout sans en avoir l’habitude, peut être une tâche ardue. Il faut savoir être assez exigeant avec le code tout en sachant ne pas être trop cassant dans ses propos. 

Cette expérience de partage doit être souhaitée par les participants afin que personne ne se sente frustré, voire violé dans ses habitudes de travail.

La gestion du temps et la capacité de concentration est une autre partie du quotidien à revoir pour faire du Pair-programming. En effet, le Pair-Programming favorise la concentration et permet de discuter, réfléchir et argumenter davantage ensemble. Mais comme  Robert C. Martins l’évoque dans son livre The Clean Coder (livre à lire !), nous n’avons pas une réserve illimitée de concentration. Nous devons faire des pauses afin de pouvoir recharger nos batteries. Il faut donc accepter de faire des pauses plus régulièrement et accepter d’être fatigué plus rapidement. 

La relation actif/passif

Même si certaines personnes préfèrent rester passives, dans le cas du Pair Programming cela ne marche pas. En effet, le but n’étant pas de suivre un cours mais bien de partager, il ne faut pas qu’une personne soit plus active qu’une autre. 

C’est un problème récurrent dans les cas de binôme avec une personne au caractère fort et/ou avec une connaissance technique supérieure. Cette dernière prendra naturellement le leadership du duo.

L’un des intérêts du Pair-programming est précisément la transmission de connaissances dans l’équipe

Le coût !

Le coût est le premier frein remonté par les personnes étrangères au Pair-Programming. Mais ce coût révèle généralement une mauvaise application de cette pratique. En effet, les tâches “no brain”, très simples peuvent causer un surcoût si réalisées en binôme (même si cela peut encore être débattu). Mais une étude montre que le Pair-Programming coûte à terme moins cher avec un gain de temps de 15% de par les avantages vu plus haut.

Comment le mettre en place

Il n’y a pas de solutions miracles qui marcheraient pour tout le monde, chacun est différent et aura plus ou moins d’accroche avec cette pratique. 

Le conseil le plus important pour moi est d’y aller progressivement. 

On ne peut pas décider du jour au lendemain de se dire : “Allez faisons du full Pair Programing maintenant”. Cela ne marchera pas. 

Privilégions plutôt l’approche itérative, sur ce sprint faisons donc une story en Pair Programming pour essayer. Si cela marche bien nous en ferons deux ou trois au prochain.

Évangéliser le pair-programming : 

Malgré ce que j’ai dit précédemment, il ne faut pas hésiter si vous en ressentez le besoin, ou que vous pensez que cela peut être judicieux, de proposer à quelqu’un de travailler en binôme (je dis bien “proposer”). Cela peut permettre d’instaurer une bonne habitude qui restera dans le temps.

Partager le temps devant le clavier :

Pour que le Pair Programming soit efficace et bénéfique pour tout le monde il faut partager l’activité équitablement afin que personne n’ait le rôle de “passif”. Quelques exemples : 

• Dans le cas d’un développement TDD, une personne écrit un test, l’autre implémente la solution tant que la première personne n’est pas satisfaite. Puis à son tour, elle écrit son test pour que l’autre fasse de même (Méthode Ping-Pong)
• Mettre en place un timer permettant de définir des sessions devant le clavier (15 min par exemple, cela peut permettre de mixer avec la méthode de gestion de temps “Pomodoro”)

Le Mob Programming :

Comme l’expression le dit : “Plus on est de fous, plus on rit”. Il ne faut pas se limiter à travailler en binôme. Il ne faut pas hésiter à faire du “Mob-Programming” pour des tâches complexes ou qui ont un retour sur expérience important. Il est plus pertinent d’apprendre tous ensemble plutôt qu’une ou deux personnes capitalisent seules sur le sujet  et “perdent” du temps à expliquer par la suite, avec le risque que certains points aient été négligés par manque de points de vue. Mais étant plus “coûteuse” en termes d’organisation, cette pratique doit rester exceptionnelle !

Changez de partenaire :

Les habitudes se prennent vite, et surtout les mauvaises. A ne travailler qu’avec les mêmes personnes, nous prenons des habitudes qui peuvent ne pas être bonnes. En effet, pour un binôme un certain point sera évidemment fait de telle manière alors qu’une tierce personne aurait fait comprendre qu’il y avait mieux à faire. De plus, cela limite le partage de connaissance alors qu’il s’agit là d’un des points les plus importants du pair-programming.

Donc contrairement au couple : Allez voir ailleurs !

Ce que je retiens du Pair Programming

Malheureusement pour moi, je n’ai découvert le Pair-Programming que récemment car les équipes dans lesquelles il m’a été donné de travailler, pourtant composées de développeurs très compétents, fonctionnaient sur un mode très traditionnel qu’elles ne souhaitaient pas forcément modifier.

Cela reflète une situation assez globale, étant qu’aujourd’hui le pair programming est une pratique encore trop peu utilisée malgré tous les avantages non négligeables qu’elle peut apporter sur un projet.

Qu’il s’agisse de l’intégration de nouveaux arrivants, de l’uniformisation des pratiques, du partage de connaissances ou de la résolution de problèmes complexes, cette pratique est un réel vecteur d’amélioration des projets sur les plans technique, méthodologique et qualitatif.

Comme un bon repas ou une bonne bouteille, la programmation est encore meilleure quand elle est partagée avec les autres.

Silvio VASCONCELOS