pourquoi développer en pair programming ?

1+1=3 : focus sur le pair programming !

L’arrivée de l’eXtreme Programming dans le monde du développement logiciel a permis de favoriser la diffusion de « bonnes » pratiques de développement avec pour clef de voûte le TDD (TestDrivenDevelopment) et le pair programming.

 

Mais c’est quoi le pair programming ?

C’est du développement en binôme sur un seul poste de travail : une souris, un écran et un clavier pour deux. Les développeurs qui travaillent de cette manière occupent des rôles tournants : il y a un driver et un navigateur. Le driver contrôle le clavier, il est chargé d’écrire les lignes de code. Pour sa part, le navigateur à un rôle d’observateur, de guide et de ressources pour celui qui développe. Les rôles changent après un temps défini à l’avance. Pour simplifier, on peut comparer aux sports automobiles où il y a un pilote et un copilote. Le pilote a le contrôle du véhicule là où le copilote l’aide à surmonter les difficultés en cours de course.

Un principe de fonctionnement simple en apparence, mais loin d’être évident dans la pratique pour les pair programmers !

 

Les rôles en pair programming

On l'a vu, cette pratique de développement logiciel implique une programmation en binôme. Au sein de ce dernier, il est important de préciser que peu importe le rôle que l’on occupe, des règles s’imposent. Les deux développeurs doivent être actifs en permanence et investis dans leur rôle. Par exemple, il ne faut pas hésiter à intervenir si votre binôme est trop calme ! Il faut aussi s’astreindre à une certaine discipline pour lâcher ou reprendre le clavier quand le temps est écoulé. Si les rôles définis sont respectés, les transitions sont très fluides et ne nécessitent presque pas d’explications de l’un à l’autre. Et le plus important, qui peut paraître évident sur le papier, mais qui ne l’est pas toujours dans le feu de l’action : communiquer et célébrer les réussites ! C'est une des clés de succès de la technique du pair programming.

 

Focus sur le rôle du driver

En pair programming, le driver est celui qui contrôle le clavier. Son rôle consiste à créer le code en fonction des instructions que lui donne le navigateur. Il se doit donc d’être très attentif ! Surtout, en tant que driver, il ne faut pas hésiter à questionner les instructions pour être sûr que les deux développeurs comprennent la même chose. Et en cas de désaccord avec les guidelines du navigateur, il faut être capable de proposer d’autres solutions. Il faut également qu’il y ait un niveau de confiance mutuel important entre les deux membres du binôme, autrement le pair programming court à l’échec. En tant que driver, il est aussi important d’écrire du code aussi propre que possible (le navigateur y veille) et se focaliser sur la tâche en cours plutôt que sur la vision plus large du projet : une chose à la fois ! Et dernier point, mais pas des moindres : lâcher le clavier quand le temps défini est écoulé !

pair programming blague

Focus sur le rôle du navigator

Le « copilote » dicte au driver le code qui doit être rédigé, de la manière la plus claire possible. Il doit aussi être en mesure d’expliquer les raisons qui ont fait qu’il choisit telle ou telle solution par rapport à un problème donné. Pour aider le driver, il doit aussi être attentif aux erreurs de frappe et de syntaxe qui peuvent arriver pendant l’écriture du code. Il est chargé de faire une revue du code en permanence. Sur tous les points qui touchent au design et au refactoring, il est d’usage d’attendre que la tâche initiale soit accomplie avant de s’attaquer à ces sujets.

À lire aussi : Focus sur le mouvement DevOps

D’autres manières de pratiquer le pair programming

Ping pong pair programming

La manière la plus courante de développer en binôme est celle que nous venons de développer, mais ce n’est pas la seule ! Il existe également le pair programming en « Ping-pong ».

Cette méthode est un très bon choix pour faire du développement piloté par les tests (du Test Driven Development). Le nom ping-pong n’est pas le fruit du hasard, puisqu’il s’agit bien de faire des aller-retour entre les deux membres du binôme :

  1. Martin écrit un nouveau test et vérifie qu’il ne passe pas.
  2. Martine implémente le code voulu pour passer le test.
  3. Martine écrit un nouveau test et vérifie qu’il ne passe pas.
  4. Martin implémente le code voulu pour passer le test.

Et ainsi de suite ! L’avantage par rapport au système driver – navigator « classique » est que les transitions sont plus aisées puisque délimitées par des tâches fixes. Il faut cependant avoir à l’esprit que le temps passé sur une tâche peut varier. Ce ne doit pas être un motif de frustration, à la longue le temps s’équilibre entre les membres du binôme. Ensuite, dans les bonnes pratiques à observer, il faut s’astreindre à écrire le test de fail le plus court possible. De même pour le code qui fera passer le test.

 

Strong style pair programming

La méthode qui est peut-être la moins intuitive, mais sûrement la plus challengeante ! Llewellyn Falco la définit de la manière suivante : “In order for an idea to go from your head into the computer, it must go trough someone else’s hands”. Avec cette méthode, c’est le navigateur qui prend les décisions. Quand le driver veut apporter une idée, il doit passer le clavier au navigateur et lui expliquer son idée pour que le navigateur soit en mesure de la transcrire en code. Le principal avantage de cette approche est que le niveau d’engagement de l’observateur est fort. Cela permet également de développer une capacité de collaboration importante.

 

Pourquoi payer deux personnes pour faire le job d’une personne ?

Il est vrai que le postulat de base est contre-intuitif : on met deux personnes (deux « ressources ») sur la même tâche au lieu d’une. Mais le coût ne double pas, loin de là ! Une étude sur les coûts et avantages du Pair Programming a été conduite par une chercheuse de l’université de l’Utah. Les conclusions permettent de souligner la pertinence de cette pratique : développer en pair programming prend en moyenne 15% de temps en plus, mais le code produit contient 15% de défauts en moins ! Sans compter les avantages non mesurables tels que la capacité à collaborer, la cohésion d’équipe …

À lire aussi : Software Craftsmanship, on parle de quoi ?

Quelques retours d’expériences sur le pair programming

Nous sommes allés à la rencontre de développeurs pour qu’ils nous partagent leur expérience en pair programming et les bénéfices ou freins qu’ils ont pu observer par rapport à cette pratique. Point important à préciser : en tant qu’outil issu de l’agilité, la pratique ne peut marcher que si elle s’inscrit dans une démarche agile globale. Il faut a minima que des pratiques comme l’automatisation des tests soient mises en place. Autrement, faire du pair programming pour faire du pair programming ne vous mènera nulle part.

De nombreux développeurs que nous avons interrogés recourent au pair programming de manière ponctuelle (quelques heures par semaine ou en fonction des problèmes rencontrés). Par exemple, cela peut être à la demande de membres de l’équipe qui rencontrent un blocage ou font face à des difficultés sans trop savoir comment les résoudre. Dans ce cas-là, la pratique peut permettre de consolider le code et de surmonter les difficultés rencontrées plus rapidement en apportant un autre regard. Autre point positif noté par les personnes que nous avons rencontré : le pair programming permet de renforcer la capacité qu’ont les membres de l’équipe à collaborer et cela renforce les liens, la cohésion interne.

Ce ne sont pas les seuls avantages qu’amène cette pratique. Le fait de travailler en binôme permet d’apprendre de l’autre et de ses manières de travailler, de développer : les développeurs qui codent ensemble se forment mutuellement ! Cela permet une montée en compétences partagées par les membres du binôme. De plus, le pair programming permet de « transversaliser » la maîtrise du code : cela peut permettre de réduire le risque auquel on fait face quand l’on récupère un code écrit par une personne qui a quitté l’entreprise par exemple.

Autre point relevé par certains, le pair programming est un excellent moyen d’onboarder de nouveaux membres au sein d’une équipe ! Cela leur permet de se familiariser avec les manières de faire de l’entreprise, de les challenger, mais aussi et surtout de créer des liens avec leurs nouveaux collègues.

 

Pair programming : top départ ?

De notre point de vue, la pratique présente des avantages tangibles. En pair programming, bien qu’il y ait un poste de travail pour deux, on peut aller plus vite et plus loin que seul dans son coin. Le plus pertinent étant de recourir à cette pratique selon votre bon sens et selon ce que vous souhaitez que cela apporte à votre organisation.