Mécanique d'appariement
Le jumelage consiste à avoir deux programmeurs travaillant sur un seul poste de travail. Un programmeur « conduit », utilise le clavier, tandis que l'autre « navigue », regarde, apprend, demande, parle et fait des suggestions. En théorie, le pilote se concentre sur le code à portée de main : la syntaxe, la sémantique et l'algorithme. Le navigateur se concentre moins là-dessus, et plus sur un niveau d'abstraction plus élevé : le test qu'il essaie de faire passer, la prochaine tâche technique à livrer, le temps écoulé depuis que tous les tests ont été exécutés, le temps écoulé depuis le dernier validation du référentiel et la qualité de la conception globale. La théorie est que l'appariement se traduit par de meilleures conceptions, moins de bogues et une bien meilleure diffusion des connaissances au sein d'une équipe de développement, et donc plus de fonctionnalités par unité de temps, mesurées sur le long terme.
Diffuser les connaissances
Certes, en tant que mécanisme de mentorat, le jumelage est difficile à battre. Si les binômes s'éteignent régulièrement (comme ils le devraient), le binôme diffuse plusieurs types de connaissances au sein de l'équipe avec une grande efficacité : connaissance de la base de code, connaissance de la conception et de l'architecture, connaissance du domaine des fonctionnalités et des problèmes, connaissance du langage, connaissance de la plate-forme de développement, connaissance du framework et de l'outil, refactoriser les connaissances, et tester les connaissances. Il n'y a pas beaucoup de débat sur le fait que l'appariement diffuse mieux ces types de connaissances que les revues de code traditionnelles et les méthodes moins formelles. Alors, quelle pénalité de productivité, le cas échéant, payez-vous pour diffuser si bien les connaissances ?
Appariement et productivité
Les résultats de recherche et les rapports anecdotiques semblent montrer que la productivité à court terme pourrait diminuer légèrement (environ 15 %), mais parce que le code produit est tellement meilleur, la productivité à long terme augmente. Et cela dépend certainement de la façon dont vous mesurez la productivité et sur quelle durée. Dans un contexte agile, la productivité est souvent mesurée en fonction de l'exécution, des fonctionnalités testées réellement livrées par itération et par release. Si une équipe mesure la productivité en lignes de code par semaine, elle peut en effet constater que l'appariement fait chuter celle-ci (et si cela signifie moins de lignes de code par fonctionnalité testée en cours d'exécution, c'est une bonne chose !).
Productivité et rotation du personnel
Les partisans de l'appariement affirment que si vous mesurez la productivité sur une période suffisamment longue pour inclure le personnel embauché et partant, l'appariement commence à montrer encore plus de valeur. Dans de nombreux projets traditionnels, l'expertise a tendance à s'accumuler dans des « îlots de connaissances ». Les programmeurs individuels ont tendance à connaître beaucoup de choses importantes que les autres programmeurs ne connaissent pas non plus. Si l'une de ces îles quitte l'équipe, le projet peut être retardé ou pire. Une partie de la théorie de l'appariement est qu'en diffusant si largement de nombreux types de connaissances au sein d'une équipe, la direction réduit son exposition à cette menace constante de rotation du personnel. En programmation extrême (XP), on parle du numéro du camion : le nombre de membres de l'équipe qui devraient être heurtés par un camion pour tuer le projet. Les projets XP s'efforcent de maintenir le nombre de camions aussi proche que possible de la taille totale de l'équipe. Si quelqu'un part, il y en a généralement plusieurs autres pour prendre sa place. Ce n'est pas qu'il n'y a pas de spécialisation, mais certainement tout le monde en sait plus sur tout ce qui se passe. Si vous mesurez la productivité en termes de fonctionnalités fournies sur plusieurs releases par une telle équipe, il devrait être plus élevé que si l'appariement n'a pas lieu.
Stratégies d'appariement
Dans XP, tout le code de production est écrit par paires. De nombreuses équipes agiles non XP n'utilisent pas du tout l'appariement. Mais il y a beaucoup de terrain d'entente entre aucun appariement et tout le monde appariant tout le temps. Essayez d'utiliser le jumelage lorsque vous encadrez de nouvelles recrues, pour des tâches à très haut risque, au début d'un nouveau projet lorsque la conception est nouvelle, lors de l'adoption d'une nouvelle technologie ou sur une base de rotation mensuelle ou hebdomadaire. Les programmeurs qui préfèrent s'apparier peuvent être autorisés à le faire, tandis que ceux qui ne le font pas ne sont pas autorisés à le faire. La décision d'utiliser des révisions de code au lieu de n'importe quel appariement est populaire, mais nous ne connaissons aucune raison de ne pas au moins expérimenter l'appariement. Il n'y a aucune preuve raisonnable que cela nuit à une équipe ou à un projet, et il y a de plus en plus de preuves qu'il s'agit d'une pratique exemplaire utile.
