Lorsque deux personnes se réunissent pour écrire du code sur un même ordinateur, on lui donne le nom de programmation en binôme.
La programmation par paires a été popularisée par le livre de programmation eXtreme de Kent Beck, dans lequel il rapporte la technique pour développer des logiciels par paires, ce qui a suscité l’intérêt des chercheurs pour le sujet. Lan Cao et Peng Xu ont découvert que la programmation en binôme conduit à un niveau plus profond de réflexion et d’engagement dans la tâche à accomplir.
La programmation en binôme comporte également différentes approches. Il existe différents styles de programmation en binôme, tels que le lecteur/navigateur, le ping-pong, le style fort et le développement en binôme.
Tous sont bien décrits par Birgitta Böckeler et Nina Siessegger. Leur article décrit l’approche de la pratique de chaque style.
Ici, nous nous intéresserons particulièrement à seulement deux d’entre eux : le lecteur/navigateur et le ping-pong, car il semble que les deux soient les plus couramment utilisés.
L’objectif est d’avoir un aperçu de ce qu’il faut éviter lorsqu’on développe un logiciel en binôme.
Dans un premier temps, nous introduisons brièvement chaque style de programmation en binôme, puis nous suivons les comportements à éviter.
Pilote/Navigateur
À mon goût, le chauffeur et le navigateur sont les plus populaires parmi les pratiquants. Dans ce style, le conducteur est celui qui écrit le code et réfléchit à la solution en place pour faire des pas concrets pour avancer dans la tâche à accomplir. Le navigateur, quant à lui, surveille le conducteur et donne également un aperçu de la tâche à accomplir.
Mais pas seulement cela, la navigatrice est celle qui pense de manière plus large, et elle est également chargée d’apporter son soutien.
La communication entre le pilote et le navigateur est constante. Ce style est aussi celui qui correspond bien à la technique Pomodoro.
Ping pong
Le ping-pong est le style qui « adopte la méthodologie Test Driven Development » ; la raison derrière cela est la manière dont cette dynamique fonctionne. Supposons que nous ayons une paire qui commencera à travailler ensemble, Sandra et Clara. La session de ping/pong devrait ressembler à ce qui suit :
- Sandra commence à écrire un test d’échec
- Clara fait le test pour réussir
- Maintenant, Clara peut décider si elle veut refactoriser
- Clara écrit maintenant un test d’échec pour Sandra
- La boucle se répète
Il est également possible d’étendre le ping/pong à une approche plus large. On peut commencer une session en écrivant un diagramme de classes, et la personne suivante de la paire implémente le premier ensemble de classes.
Quel que soit le style, la clé du succès de la programmation en binôme est la collaboration.
Comportements à éviter
Malgré sa popularité, la programmation en binôme semble être une méthodologie qui n’est pas largement adoptée par l’industrie. Quand c’est le cas, cela peut varier en fonction de la signification de « paire » et de « programmation » dans un contexte spécifique.
Parfois, la programmation en binôme est utilisée à des moments spécifiques tout au long de la journée des praticiens, comme le rapporte Lauren Peate sur le podcast Software Engineering Unlocked hébergé par Michaela Greiler pour accomplir des tâches spécifiques.
Mais, dans XP, la programmation en binôme est l’approche par défaut pour développer tous les aspects du logiciel.
En raison de la variation et de l’interprétation de ce qu’est la programmation en binôme, les entreprises qui l’adoptent peuvent être confrontées à des conceptions erronées de la manière de la pratiquer. C’est souvent la cause principale d’une mauvaise expérience lors de l’appariement.
- Manque de compétences générales (sociales)
- Manque de connaissances dans la pratique de la programmation en binôme
Dans les sections suivantes, nous passerons en revue certaines conceptions manquées de la pratique. Les éviter pourrait conduire à une meilleure expérience lors du couplage.
Manque de communication
Le pilote et le navigateur sont le style qui oblige la paire à se concentrer sur un seul problème à la fois. Par conséquent, le navigateur est celui qui doit apporter son soutien et remettre en question les décisions du conducteur de garder les deux synchronisés.
Lorsque cela ne se produit pas, la session de collaboration peut souffrir d’un manque d’interaction entre la paire. La première mauvaise conception de l’approche conducteur/navigateur est que le navigateur regarde simplement le conducteur et ne fait rien ; ça devrait être le contraire.
Autant de communication que possible est un signe que la paire progresse. Bien sûr, nous n’avons pas mentionné la variance des connaissances que le lecteur et le navigateur pourraient avoir.
Multitâche
Vérifier le téléphone pour les notifications ou détourner l’attention sur une autre chose qui n’est pas le problème à résoudre est un avertissement que la paire n’est pas synchronisée. L’avènement des sessions de programmation en binôme à distance pourrait même faciliter une telle distraction pendant la session.
Le navigateur doit apporter le plus de soutien possible et encore plus lorsque le conducteur est bloqué pour une raison quelconque. Certaines activités que le navigateur pourrait vouloir effectuer :
- Vérification de la documentation du morceau de code que le pilote est en train d’écrire
- Vérifier si la tâche à accomplir va vers l’objectif final de la tâche (cela devrait empêcher la paire d’aller dans un chemin qui est hors de portée)
- Contrôler le cycle Pomodoro si convenu
D’autre part, le conducteur est également censé écrire le code et pas seulement être la marionnette du navigateur. Lorsque cela se produit, la collaboration dans la session peut en souffrir, entraînant une lourde charge sur le navigateur.