Le Pair Programming, étude et chiffres
Introduction
Dans cet article, nous allons nous attarder à expliciter les avantages du développement d’un programme informatique en Pair Programming (PP). Pour cela, nous partirons d’un cas concret et nous donnerons les principaux chiffres entourant l’univers du Pair Programming.
S’adapter à une nouvelle méthode de travail n’est jamais chose aisée. Par ailleurs, certaines personnes ne sont pas aptes pour le travail en binôme pour diverses raisons. Il est essentiel de souligner que le Pair Programming ne fonctionnera que si l’entente entre les deux développeurs est linéaire et basée sur une relation de confiance professionnelle et de partage des tâches ainsi que dans le respect des principes Agiles.
Définition
Une courte définition pour commencer :
le Pair Programming (programmation en binôme) est une méthodologie de travail consistant à faire travailler conjointement deux développeurs sur un seul et même poste. L’un des deux développeurs est appelé driver (conducteur) et est chargé de rédiger le code, tandis que le second est surnommé observer (l’observateur) et à un rôle tout aussi important puisqu’il supervise le travail, détecte les erreurs et donne conseils et solutions alternatives au driver.
Bien évidemment, les développeurs échangent régulièrement leurs postes afin d’accroître le transfert de connaissance et faciliter la communication et la vision globale du programme.
Si bon nombre de PO (product owner) voit dans le Pair Programming un gâchis en termes de ressources humaines, il s’avère bien souvent que le gain final de temps (et donc d’argent) donne lieu à une appréciation toute particulière de cette méthode par les parties prenantes.
Cas concret
Imaginons que le programme final est estimé à 50 000 lignes de codes et que vous coder à un rythme de 50 lignes par heure. Il vous faudra 1000 heures pour terminer le programme. Maintenant, instaurons un minimum de 100 bugs pour 1000 lignes de code (10%). Là où le développeur solitaire peut supprimer 70% des bugs totaux (3500 sur 5000), le binôme atteint lui un taux de 75% de débogages efficace (3750 sur 5000).
Ainsi, l’efficience d’un débug en pair est d’environ 15% supérieure à celle d’un débug en solo. Ce chiffre peut même s’accentuer si une équipe de testeurs QA (Quality Assurance) associée au binôme et que la paire s’occupe elle-même des tests (unitaires, fonctionnels, intégration, graphiques, ergonomiques, de performance ou de sécurité).
Le temps passé à la résolution d’un bug est lui aussi évolutif. On considère qu’il faut en moyenne 40 heures pour résoudre un bug en solo et 60 fois moins de temps pour un binôme sur les mêmes problématiques. En effet, le Pair Programming élimine le fait de devoir faire passer le message aux différents services et se résout de manière interne au binôme. C’est donc un gain de temps pour l’ensemble des équipes qui traite de ce sujet.
L’étude Microsoft
Si l’on s’en tient d’ailleurs à l’étude menée par Microsoft à ce sujet, on constate effectivement un taux de bugs inférieur en Pair Programming tout en gardant les mêmes données temporelles de travail (cf. tableau)

Conclusion
Ce gain de temps impressionnant n’est que le résultat d’un travail plus consciencieux puisque supervisé en temps réel. Les avantages du Pair Programming ne s’arrêtent pas là et peuvent se décliner en six points cruciaux qui vous feront changer d’avis et adopter cette méthodologie.
Des économies garanties
Le temps c’est de l’argent. Le Pair Programming fait gagner du temps. Le Pair Programming fait gagner de l’argent. CQFD.
Si cela peut paraître trop simpliste, voilà pourtant l’un des principaux avantages du Pair Programming. Bien que l’investissement en ressources humaines soit initialement plus conséquent qu’en Solo Programming, le fait d’avoir moins de refactoring à effectuer permet un meilleur respect des deadlines et donc moins de charges variables pour le PO (Product Owner).
Une satisfaction générale
Le fait que plus de bugs soient réparés, que le design et les user-stories client soient respectés, entraîne une satisfaction de toutes les parties prenantes. Tandis que les développeurs s’enorgueillissent d’un travail rapide, efficace et d’un code propre, le Product Owner se voit livrer un programme respectant à la lettre ses recommandations et dans le délai imparti.
Avoir une équipe qui se challenge est gratifiant tant pour les développeurs que pour le chef de projet qui peut ainsi justifier de l’intérêt de son produit par l’investissement de ses consultants.
La qualité du design respectée
Si l’observer est garant de la qualité du design et des user-stories réclamées par le client du fait de son recul sur la programmation en cours, il n’est pas responsable des erreurs commises par son binôme. En effet, pour respecter la qualité du design, l’association des qualités des deux développeurs est essentielle.
Cependant, il est dans certains cas important d’avoir un référent technique (souvent le développeur le plus évolué techniquement) qui pourra venir assister les duos. Rappelons que cela doit en grande partie se déterminer au cas par cas.
Par son œil avisé et surtout sa connaissance de l’écriture du code (rôles interchangeables), il peut quotidiennement vérifier l’avancée du code vis-à-vis du design demandé. Le fait d’être le superviseur d’un code partagé permet d’avoir le recul nécessaire sur la qualité de son travail et la mise en conformité avec les besoins d’un design propre.
Des revues de code continues
Le fait d’effectuer des revues de code et du refactoring continu permet d’adopter – et ce dès le début – des méthodologies permettant d’obtenir un code propre. Cela facilite grandement le travail en équipe et la lecture du code lors de bug. C’est aussi un gain de temps sur l’étendue globale du projet.
Avoir une meilleure visibilité des différentes problématiques qui surviennent durant l’implémentation des fonctionnalités est essentielle. En ce sens, le reviewing et le refactoring sont des atouts essentiels du pair programming. Celui là même qui voit son efficacité accentuée par le fait d’avoir une double vision du même programme.
Un transfert de compétences assuré et une montée en compétence des deux développeurs
Le fait de travailler sur des problématiques différentes permet, tour à tour, à chacun des développeurs de monter en compétences sur des thématiques qu’il ne connaissait ou ne maîtrisait pas auparavant. C’est fortement gratifiant de se sentir meilleur à la fin d’un projet.
La création d’une cohésion d’équipe
Travailler sans discontinuer avec le même binôme favorise la compréhension de l’autre ainsi que de l’environnement de travail de façon rapide. Une fois que le binôme a mis en place sa méthodologie commune de travail, la cohésion d’équipe est assurée, ce qui offre une meilleure atmosphère de travail. Interaction humaines, professionnelles et souvent de véritables amitiés se créent autour d’un travail en pair programming.