Qu’est-ce que le pair programming ?

C’est une pratique dite ‘agile’, issue des bonnes pratiques XP (eXtreme Programming), qui remonte aux années 90. Elle procède du même principe que celui du pilote et co-pilote, en effet le développeur ‘pilote’ code pendant que le développeur ‘co-pilote’ effectue la revue de code en direct, commente et suggère des améliorations ou des approches différentes lorsque la situation d’y prête. Les rôles s’inversent régulièrement selon un planning prévu à l’avance. L’idée est bien de réfléchir à deux pour trouver plus vite la meilleure solution.

Pourquoi le mettre en place ?

Que faut-il en attendre,  quels sont les bénéfices ?

Créativité et émulation

Travailler en binôme favorise l’émulation et donc la créativité. L’échange fait émerger de nouvelles idées. Alors qu’un développeur seul pourrait être tenté de se contenter du minimum, lorsque l’on travaille en binôme, il faut être capable de justifier le bien-fondé de sa solution et de peser le pour et le contre avec l’éventuelle proposition de son co-équipier, ça laisse difficilement la place à la médiocrité.

Une meilleure qualité de code sans incidence sur les délais

Le fait de devoir défendre ses idées, de discuter des meilleures façons de résoudre les éventuels problèmes et ne pas se contenter du minimum a forcément une incidence bénéfique sur la qualité du code : plus propre, plus facile à lire avec moins de code inutile.

Mon expérience du pair programming est super positive. On a commencé à l’implémenter progressivement pour limiter l’impact dans la productivité. A la fin du 1^er sprint, on a pu constater qu’on avait effectué le même nombre des tâches que dans le sprint précèdent (donc pas d’impact sur la productivité) mais surtout avec une bien meilleure qualité du code livré. Aujourd’hui on a moins de retours de l’équipe de test, nos applications sont beaucoup plus performantes, et le partage de connaissances entre les membres de l’équipe est continu dans la mesure où on est tous liés de façon directe au développement du code

comme le souligne Ignacio Rognoni, Consultant SoftFluent

Moins de maintenance

Un code épuré : le code source généré lors du pair programming est souvent plus court et donc plus efficace. Il contient moins d’erreurs, moins de code mort et est globalement mieux structuré, soit des économies potentielles de maintenance.

Une collaboration saine et efficace

Au-delà des gains inhérents à la revue de code en continu, développer à deux peut en effet s’avérer bien plus bénéfique que seul dans son coin, et ce pour différentes raisons :

Partage des connaissances et des meilleures pratiques. Quel que soit leur niveau, chacun peut apporter à l’autre. Un senior apporte son expérience terrain, ses pratiques, un Junior, le dernier tooltip à la mode… Un méthodique structure davantage avec un cadre, des processus, de la rigueur, alors qu’un créatif foisonne d’idées ….

Le renforcement de l’esprit d’équipe et des liens, une meilleure cohésion entre développeurs et une coordination d’ensemble plus simple.

Alors que l’on pourrait penser que le pair programming augmente les temps de livraison de 100%, il n’en est rien, deux têtes sont plus efficaces plus rapidement et auront moins tendance à se disperser ou se déconcentrer

selon Sabrina Pereira, Team Leader

Des intégrations facilitées

Le transfert de connaissances est plus fluide en pair programming et peut faire l’économie de l’auto-formation. C’est encore plus vrai pour l’intégration d’un nouveau collaborateur.

Même avec la meilleure volonté du monde, un débutant non cadré à qui l’on met la pression a peu de chance de livrer un code conçu dans les règles de l’art quand bien même il a toutes les règles de bonnes pratiques en main. Le tutorat, la revue de code ou l’accompagnement par des personnes expérimentées permettent de démarrer dans de bonnes conditions et d’être opérationnel plus rapidement

Programmer à deux en vue d’une embauche peut également être un très bon moyen pour évaluer la qualité d’un candidat ou d’une candidate, et se faire une idée de sa future intégration avec l’équipe de développement en place mais aussi en période d’essai, pour être sûr de ne pas se tromper sur le candidat, nous l’avons d’ailleurs expérimenté auprès de nos clients

comme l’explique Sabrina Pereira – Team Leader

Pas de phénomène de ‘starisation’

Un seul développeur star certes brillant qui est le seul à maitriser le sujet et qui se rend indispensable est dangereux. S’il quitte le projet, il emmène avec lui toute la connaissance. Le partage continu de connaissances est source d’enrichissements mutuels. Il n’est d’ailleurs par rare que le spécialiste en question ait une vision erronée sur un sujet qu’il est censé maitriser et qu’un regard neuf, un échange productif permettent d’améliorer l’application.

Nous avons un peu tendance à penser que nos idées sont les meilleures, le pair programming nous montre parfois qu’il peut y avoir d’autres solutions, voire des solutions meilleures

avoue Ignacio Navarro – Consultant chez SoftFluent

Comment le mettre en place ?

Le pair programming est relativement facile à implémenter, et surtout, il peut l’être à la carte sans forcément remettre en cause les habitudes.  En fonctionnement agile, vous pouvez le mettre en place le temps d’une itération et comparer avec le mode de fonctionnement en solo, pour convaincre et embarquer les développeurs sur cette pratique.

Mettre toutes les chances de votre côté

Il est conseillé de commencer sur des tâches complexes et plutôt longues, plutôt que sur des développements simples et rapides. Les avantages du pair programming n’en seront que plus visibles.

Choisissez des développeurs volontaires et motivés pour que toute l’énergie du binôme soit consacrée à l’accomplissement de la mission

Proposez-leur de changer de rôle fréquemment pour prendre conscience des autres aspects et ne pas s’enfoncer dans un rôle unique et ne pas hésiter à communiquer sur les ressentis de chacun.

Avec les bons outils

Vous trouverez ci-dessous une liste d’outils de développeurs destinés à celles et ceux qui travaillent dans une équipe dispatchée ou qui sont régulièrement amenés à collaborer sur des bouts de code :

• Visual Studio Live Share : la solution Microsoft pour le développement collaboratif
• Teletype for Atom : gratuit et open source.
• RemoteCollab : un plugin SublimeText pour travailler à plusieurs sur le même projet en temps réel.
• CodeSandbox : pour collaborer sur vos différents sandboxs.
• Codeanywhere : permet de « coder partout », ou en tous cas depuis n’importe quel appareil.
• CodePen : propose un environnement sur lequel plusieurs développeurs peuvent travailler simultanément moyennant abonnement

Evidemment, comme toute nouvelle pratique, elle nécessite un temps d’adaptation mais rares sont les développeurs qui n’y prennent pas goût après avoir démarrer.

Différents styles de pair programming

Classique

Collaboration de 2 personnes sur un même poste de travail avec chacun un rôle bien précis, l’un code et l’autre effectue la revue de code en simultané. Il est recommandé d’alterner les rôles et surtout

Ping pong

Cette forme de pair programming est mise en œuvre dans un contexte de développement piloté par les tests (TDD). L’un écrit le test, et l’autre écrit le code qui validera le test. C’est une méthode ludique qui permet aux développeurs de se lancer des défis mutuellement.

Strong style pairing

Dans cette méthode, le ‘conducteur’ doit systématique demander l’avis au ‘navigateur’ avant de faire quoi que ce soit de sorte que les 2 développeurs soient complétement impliqués dans le processus de développement. Les échanges de place s’effectuent dès que l’un des 2 a une idée : c’est à l’autre de la traduire en code.

Llewellyn Falco, coach Agile spécialiste du code legacy et du TDD, justifie cette approche ainsi :

Pour qu’une idée aille de votre tête à l’ordinateur, il faut qu’elle passe par les mains de quelqu’un d’autre

Les règles d’or du Pair Programming

Il faut dans la mesure du possible :

• Des ressources et la volonté de collaborer de manière constructive
• Privilégier les projets d’envergure pour lesquels le pair programming prend tout son sens
• Eclater régulièrement les binômes pour sensibiliser un maximum de développeurs. Non seulement c’est l’opportunité de former plus de développeurs aux projets et aux bonnes pratiques mais cela évite que le projet ne dépende que de quelques personnes spécificiques
• Ne pas hésiter pas à former des binômes moins ‘équilibrés’ en termes d’expérience : un développeur expérimenté a beaucoup à transmettre et un développeur junior peut aussi apporter un œil neuf
• Associer deux collègues de différents secteurs : cela peut s’avérer bénéfique suivant les projets, pour la complémentarité des compétences.

Qu’en est-il du …

Remote pair programming

Si la plupart des sessions de programmation en binôme se font derrière un seul et même écran, il est tout à fait possible de faire du pair programming à distance et même souhaitable vu la crise que nous traversons. Les outils informatiques favorisant la collaboration sont aujourd’hui très nombreux, Slack, Zoom, Teams…. Le partage d’écran permet au ‘pilote’ de modifier le code pendant que le ‘co-pilote’ fait la revue et les commentaires

Extreme programming

La méthodologie eXtreme Programming ou XP est une méthode de gestion de projet qui applique à l’extrême les principes du développement agile, c’est-à-dire se concentrer sur les besoins du client, mettre en place un développement itératif et l’intégration continue. L’équipe projet et ses relations avec le client sont au cœur de XP

La méthode eXtreme Programming s’appuie sur :

• une forte réactivité au changement des besoins du client
• un travail d’équipe
• la qualité du travail fourni
• la qualité des tests effectués au plus tôt.

XP repose sur cinq valeurs fondamentales

• Communication : il est essentiel que chaque membre de l’équipe communique quotidiennement avec ses collègues ainsi qu’avec le client. C’est un moyen incontournable pour résoudre les problèmes.
• Simplicité : la façon la plus simple d’arriver au résultat est privilégiée. L’équipe projet fait ce qui est nécessaire et demandé, rien de plus. Une application simple sera plus facile à faire évoluer ensuite.
• Feedback : le retour d’information entre l’équipe projet et le client est essentiel. Chaque étape du projet est envoyée aussi rapidement et souvent que possible au client afin qu’il teste, donne son avis et valide l’étape. Chaque demande de modification est prise en compte immédiatement.
• Respect : le respect de chaque membre de l’équipe et de son travail sont primordiaux. Le management, l’équipe projet et le client se respectent mutuellement.
• Courage : Il faut du courage pour effectuer certains changements comme essayer une nouvelle technique, recommencer une itération non validée ou revoir l’organisation du projet. Le courage permet de sortir d’une situation inadaptée.

Peer reviewing

La “revue par pair” consiste à faire la revue de code par d’autres personnes de l’équipe pour bénéficier d’un œil neuf. Le développeur dispose d’une version locale du code source, il peut suivre l’historique des modifications, détecter et corriger d’éventuelles anomalies, mais aussi apprendre de nouveaux concepts et se perfectionner. Il peut revenir à une version antérieure en cas d’erreur ou de perte d’une partie du code source. En outre, dès lors que plusieurs personnes travaillent sur le même code source, la gestion de projet est optimisée.