Mécanismes d'appariement
Le travail en binôme consiste à faire travailler deux programmeurs sur un même poste. L'un « pilote », manipulant le clavier, tandis que l'autre « navigue », observant, apprenant, posant des questions, échangeant et faisant des suggestions. En théorie, le pilote se concentre sur le code en cours d'exécution : la syntaxe, la sémantique et l'algorithme. Le navigateur, quant à lui, se concentre moins sur ces aspects et davantage sur un niveau d'abstraction supérieur : le test à réussir, la tâche technique suivante à réaliser, le temps écoulé depuis la dernière exécution des tests, le temps écoulé depuis la dernière modification du dépôt et la qualité de la conception globale. L'idée est que le travail en binôme permet d'obtenir de meilleures conceptions, moins de bogues et une meilleure diffusion des connaissances au sein de l'équipe de développement, et donc une productivité accrue par unité de temps, sur le long terme.
Diffuser les connaissances
En tant que mécanisme de mentorat, le pair programming est sans conteste difficile à surpasser. Si les binômes alternent régulièrement (comme il se doit), le pair programming permet de diffuser efficacement différents types de connaissances au sein de l'équipe : connaissances du code source, de la conception et de l'architecture, du domaine fonctionnel et des problèmes, des langages de programmation, des plateformes de développement, des frameworks et des outils. connaissances en refactoringet en matière de tests de connaissances. Il est généralement admis que le pair programming diffuse mieux ce type de connaissances que les revues de code traditionnelles et les méthodes moins formelles. Alors, quel est le coût en termes de productivité, s'il y en a un, de cette diffusion si efficace des connaissances ?
Appariement et productivité
Les résultats de recherches et les témoignages semblent indiquer qu'une légère baisse de productivité à court terme (environ 15 %) peut survenir, mais que la qualité nettement supérieure du code produit entraîne une hausse de la productivité à long terme. Bien entendu, cela dépend de la méthode de mesure de la productivité et de la période considérée. Dans un contexte agile, la productivité est souvent mesurée en nombre de fonctionnalités opérationnelles et testées, effectivement livrées par itération et par version. Si une équipe mesure sa productivité en lignes de code par semaine, elle constatera peut-être que le travail en binôme entraîne une baisse de ce chiffre (et si cela signifie moins de lignes de code par fonctionnalité opérationnelle et testée, c'est un avantage !).
Productivité et roulement du personnel
Les partisans du travail en binôme affirment que si l'on mesure la productivité sur une période suffisamment longue pour prendre en compte les embauches et les départs, le travail en binôme révèle encore plus de valeur. Dans de nombreux projets classiques, l'expertise a tendance à s'accumuler en « îlots de connaissances ». Chaque programmeur possède généralement de nombreuses connaissances importantes que les autres ne maîtrisent pas aussi bien. Si l'un de ces îlots quitte l'équipe, le projet risque d'être fortement retardé, voire pire. L'un des principes du travail en binôme est qu'en répartissant largement les connaissances au sein d'une équipe, la direction réduit son exposition à la menace constante du roulement du personnel. En programmation extrême (XP), on parle du « nombre de camions » : le nombre de membres de l'équipe qui devraient être percutés par un camion pour que le projet soit stoppé. Les projets XP s'efforcent de maintenir ce nombre aussi proche que possible de la taille totale de l'équipe. Si quelqu'un part, plusieurs autres sont généralement prêts à le remplacer. Il ne s'agit pas d'une absence totale de spécialisation, mais chacun possède assurément une vision d'ensemble plus complète. Si l'on mesure la productivité en termes de fonctionnalités livrées sur plusieurs versions par une telle équipe, elle devrait être supérieure à celle obtenue en l'absence de travail en binôme.
Stratégies d'appariement
Dans la méthode XP rigoureuse, tout le code de production est écrit en binôme. De nombreuses équipes agiles non-XP n'ont pas recours au travail en binôme. Cependant, il existe de nombreuses solutions intermédiaires entre l'absence totale de travail en binôme et le travail en binôme systématique. Le travail en binôme peut être utile pour l'accompagnement des nouvelles recrues, les tâches à très haut risque, le lancement d'un nouveau projet lorsque la conception est inédite, l'adoption d'une nouvelle technologie, ou encore selon un système de rotation mensuelle ou hebdomadaire. Les développeurs qui préfèrent travailler en binôme peuvent être autorisés à le faire, tandis que ceux qui préfèrent ne pas l'être peuvent l'éviter. Le choix d'utiliser des revues de code plutôt que le travail en binôme est répandu, mais nous ne voyons aucune raison de ne pas au moins expérimenter cette méthode. Rien ne prouve que le travail en binôme soit préjudiciable à une équipe ou à un projet, et de plus en plus d'éléments indiquent qu'il s'agit d'une bonne pratique.
