Pair Programming : comment tirer profit de la collaboration à son maximum?

Par Christian Belisle

La programmation en paire, communément appelée « Pair Programming », est une technique de développement logiciel Agile qui a été popularisée dans les années 90 par la méthodologie « Extreme Programming ». Une de ses règles est que chaque unité de travail réalisée doit passer entre les mains d’au moins deux membres de l’équipe.

Par réflexe, nous pourrions penser que le processus de revue de code est la solution idéale pour assurer le respect de cette règle, mais c’est une pratique qui comporte son lot de risques car certains membres de l’équipe peuvent exprimer leurs opinions avec vigueur. Les gens qui ont l’habitude de travailler seuls peuvent alors être insultés ou déstabilisés, tout ça bien involontairement. Nous nous retrouvons alors avec des collègues qui ont peur de prendre des décisions au risque de les voir être détruites.

Parfois, la mise en contexte peut aussi être complexe et ardue, ou même il n’y a simplement pas de consensus clair et défini sur la méthode qui sera utilisée pour arriver à nos fins. Il faut que nous nous parlions! C’est le signe qu’une séance de programmation en paire serait nécessaire.

Avant de commencer

Il est important de bien cibler les items de travail au préalable pour ne pas perdre notre temps à effectuer ensemble des tâches répétitives. Lors de la planification en équipe, nous pouvons déjà nous demander si les items ont :

  • Un haut niveau d’incertitude à propos duquel nous pouvons échanger.
  • Besoin d’un design, comme des maquettes ou la création d’un pilier de l’application.
  • Quelqu’un dans l’équipe qui a un intérêt pour le sujet et souhaite en apprendre plus, ou le démontrer.

Parfois, cela peut aussi être une mauvaise idée de démarrer une séance de programmation en paire, principalement si l’intérêt n’y est pas. Il faut que la discussion reste positive et que la communication puisse être ouverte. Si un ou l’autre se sent forcé, il ne faut pas hésiter à reporter à un autre moment.

Il faut également bien définir l’ampleur de la tâche avant de commencer afin d’avoir un objectif réalisable en 1,5 à 2 heures. Si la séance est trop longue, nous perdrons notre concentration et aurons le sentiment qu’elle est inutile.

Différentes techniques de programmation en paire

Pour bien comprendre le déroulement de chacune des techniques, il est important de discerner les deux rôles lors d’une séance de programmation en paire. La personne qui a le contrôle du clavier est le conducteur et l’équipier qui suit la réalisation est le navigateur. Remarquez bien avec le vocabulaire utilisé qu’un navigateur n’est pas un spectateur, mais bien la personne qui aidera le conducteur à naviguer à travers les étapes!

  • Chacun notre machine

Le conducteur utilise son ordinateur pour accomplir le travail dans le code de l’application, alors que le navigateur peut avoir la liberté d’utiliser le sien pour faire des recherches qui aideront à l’orientation, ou pour produire des maquettes qui permettront de choisir la meilleure solution.

Il faut faire attention à la perte de concentration si un des deux en profite par exemple pour aller sur les réseaux sociaux quelques minutes.

  • Une machine, deux claviers, deux souris

Avec un petit investissement, un poste de programmation en paire peut améliorer la concentration tout en accélérant la transition de la prise en charge du clavier. Habituellement, ce type d’aménagement doit être cloisonné pour éviter que les discussions viennent déranger le reste de l’environnement, qui a peut-être besoin de silence pour se concentrer.

  • Ping-Pong Pairing

En pratiquant le développement orienté par les tests, le navigateur peut s’occuper d’écrire les tests pour qu’ensuite le conducteur puisse développer la fonctionnalité qui viendra rendre ce test vert (il s’exécute avec succès).

Les tests unitaires peuvent être utilisés par le navigateur pour communiquer sa vision du code, alors que des tests « end to end », ou tests d’interface utilisateur, peuvent déjà mettre en place un processus d’assurance qualité automatisé tout en donnant la possibilité de prendre des captures d’écran.

  • L’analyste

Le navigateur occupe le rôle de l’analyste. Il n’a pas accès au clavier et utilise papier et crayon pour réfléchir en détail sur le développement en cours. Il suit le code que le conducteur est en train de créer et n’hésite pas à suggérer des améliorations et à passer en revue ce qui a été fait jusqu’à présent. Cette technique est particulièrement intéressante lorsqu’il y a une portion du travail qui touche le design (logiciel, architectural ou d’interfaces utilisateur).

Les pièges

  • Sortez de votre zone de confort

Évitez de vous éloigner des tâches qui vous intéressent le moins. En étant tous polyvalents autant que possible, nous pouvons profiter des séances de programmation en paire pour nous mettre au défi, nous poser les bonnes questions et trouver la meilleure façon d’attaquer ce que nous avons à réaliser.

En gardant cette règle d’or en tête, la programmation en paire aide à éviter la procrastination en nous permettant nous amuser même si la tâche à réaliser n’est pas toujours intéressante.

  • Ne pas vous surmener

Gardez la durée de la séance limitée entre 90 minutes et deux heures pour ensuite retourner au travail individuel. Lorsque vous êtes fatigués, il est temps d’arrêter. C’est souvent sous la fatigue et le stress que la communication se fait moins bien. L’impact sur la qualité est direct; de plus en plus de problèmes surviennent dans le code et des querelles risquent d’éclater.

Des petites pauses ici et là peuvent aussi nous permettre de clarifier nos esprits avant de continuer. Cet aspect ne doit pas être pris à la légère; c’est souvent en attendant près de la machine à café que les discussions sont les plus intéressantes.

  • Avancez à petits pas

Qu’on se le dise et redise, pour avancer, nous avons besoin de petits objectifs; ou même des micro-objectifs! Chacun doit soutenir son coéquipier et collaborer avec lui en tout temps. Si vous restez bloqués, vous pouvez facilement changer de cap et avancer sur une fonctionnalité plus définie pour ensuite revenir sur celle qui a été mise de côté.

Vous ne savez pas quoi faire lorsque vous êtes navigateur?

Concentrez-vous sur la revue du code. Votre attention devrait être totale de sorte que rien ne vous échappe. Pensez à des bogues possibles, des problèmes à plus grande échelle, ou à des manières d’améliorer et de simplifier le design de l’application. Si vous ne comprenez pas le travail que le conducteur réalise présentement, c’est votre rôle de faire en sorte que vous puissiez en savoir assez pour être en mesure de faire la revue.

Prenez garde de ne pas perdre de vue le micro-objectif fixé! N’hésitez pas à prendre des notes et attendez la fin pour soulever des erreurs ou des idées d’amélioration.

Et surtout, ne provoquez pas de distraction pour le conducteur…

  • Prenez un moment pour célébrer lorsque vous complétez quelque chose

N’hésitez pas à faire un « high five » ou à prendre cinq minutes de pause. Vous avez travaillé fort et vous le méritez. En vous assurant de garder cet esprit collaboratif, vous joindrez vos énergies et atteindrez des résultats exceptionnels. Si vous perdez cet élan, vous aurez vite l’impression de travailler en parallèle et allez probablement préférer retourner chacun de votre côté pour avancer plus vite.

La collaboration vaut la peine d’être encouragée

Travailler en équipe avec quelqu’un nous permet de faire face aux différents problèmes rencontrés avec positivisme. Outre la qualité qui est évidemment impactée par la revue en continu, les avantages sont nombreux :

  • Il est difficile de procrastiner, nous attaquons ce qu’il y a à faire ensemble, que ce soit intéressant ou non.
  • Les bonnes pratiques sont partagées, le navigateur peut se permettre de faire des recherches pendant que le conducteur code.
  • La montée en connaissances est plus rapide car les nouveaux employés collaborent avec les anciens.
  • Permet l’identification rapide du profil d’un candidat en programmant en paire durant l’interview.
  • On remarque une augmentation de la satisfaction des employés, causée par le fait que chacun peut dire son mot, même les collaborateurs à distance.

Malgré tout, certaines personnes trouvent que ce n’est pas une utilisation optimale de leur temps. C’est pourquoi les séances de programmation en paire doivent survenir seulement quand nous en ressentons le besoin et non lorsqu’elles sont planifiées. Habituellement, l’équipe complète finit un jour ou l’autre par participer à des séances même si ce n’est pas requis.

Il n’y a rien de mieux qu’un vendredi après-midi avec une ambiance un peu festive pour encourager les gens à collaborer sur tout et sur rien. Certains en profiteront pour passer un moment en idéation, d’autres peuvent apporter de nouvelles idées de produits.

À long terme, vous aurez une productivité améliorée, un positivisme face aux défis à surmonter et un produit d’une qualité irréprochable.

Autres articles qui pourraient vous intéresser

Qu’en est-il du développement de logiciels personnalisés à l’ère de l’informatique en nuage?

Fort à parier que vous ayez déjà adressé le cloud computing dans vos opérations quotidiennes. Savez-vous toutefois comment l’utilisation de ces services en ligne interagit avec le développement logiciel sur mesure? Approfondissons différents aspects de ce type de développement dans le contexte nuagique, ce qu’il permet, ses avantages, les défis à retenir et comment l’intégration...
comment les microservices aident à l'agilité

Microservice et Agiilité: les changements requis à l’ère numérique

L’ère numérique dans laquelle nous vivons présentement nécessite que nous apportions plusieurs changements dans nos manières de faire. Les entreprises qui perçoivent encore le développement logiciel comme un fardeau coûteux et non comme une force de frappe feront bientôt face à de nombreux défis importants. Pour surfer sur la vague technologique, les entreprises doivent pouvoir...
Custom Software Development | Done Technologies

Technique spike : tout ce qu’il y a à savoir

Initialement introduite par l’Extreme Programming, il existe une technique qui consiste à ajouter un élément au carnet de produit (product backlog) qu’on peut qualifier de « Spike ». Il s’agit d’un item pour lequel l’équipe s’entend sur une limite de temps à investir. Le but est d’acquérir des connaissances qui sont nécessaires pour réduire le risque, pour...