Programmation en paire

Un des points distinctifs de Extreme Programming est la programmation en paire, où deux programmeurs travaillent ensemble à la même station de travail.

Reconnu par ses pairs

La programmation en paire est tranquillement en train de prendre sa place dans l’industrie. C’est une méthode efficace et reconnue d’augmenter la qualité et la vitesse du processus de développement. La technique peut être appliquée à n’importe quelle méthodologie, et plusieurs universités et même IEEE se sont intéressés au sujet et ont conduit des études. Dans l’article « Strengthening the Case for Pair-Programming », les résultats d’études conduites dans 2 universités sont présentés, et démontrent la grande efficacité de la technique avec des étudiants. Le site http://www.pairprogramming.com est entièrement dédié à la programmation en paire.

Le concept

L’idée de base de la programmation en paire est très simple. Tout développeur est familier avec cette scène: un individu est au clavier et tape du code, un autre est assis à côté et pointe les erreurs de syntaxe. Vu de l'extérieur, ça donne l'impression d'être une blague: "combien de programmeurs ça prend pour écrire 10 lignes de code?" C’est d’ailleurs une réaction normale, ça semble être un exemple criant de perte de temps et de mauvaise utilisation des ressources.

Mais quand on porte attention on voit que le travail avance à un rythme régulier et que les erreurs sont attrapées plus rapidement. De plus, la communication ouverte entre les deux programmeurs permet d'échanger des idées et d'identifier des solutions qui n'auraient autrement pas été considérées; il s'agit ni plus ni moins d'une session de brainstorming permanente. Il est reconnu que des programmeurs sont plus efficaces lorsqu’ils communiquent et comparent leurs idées, comparativement à un programmeur travaillant seul.

Générer des idées, isoler un problème, tester une solution, modifier une architecture, toutes ces activités sont hautement complexes et détaillées, et par conséquent susceptibles à l’erreur. Même le plus discipliné et méthodique des programmeurs fera des erreurs, pour une raison ou une autre; certaines de ces erreurs seront reliées à la syntaxe, d’autres à la sémantique, d’autres à l’interaction avec d’autres parties du programme. Une paire de programmeurs a l’avantage de deux paires d’yeux pour voir les erreurs, en plus d’un « cerveau à deux niveaux »: focus sur le code, et focus sur la solution entière. De plus, la possibilité de discussion avec une autre personne permet d’explorer les possibilités ou de voir à l’avance les limitations d’une solution, plutôt que d’en faire la découverte après avoir écrit le code. Ces avantages résultent en un produit de meilleure qualité.

La résistance

Comme c’est le cas pour la majorité des gens, et en particulier pour les gestionnaires, l’idée d’utiliser 2 ressources pour faire le travail qui pourrait être accompli par une seule paraît absurde. Après tout, les programmeurs ont toujours travaillé seul, et ça a fonctionné jusqu'ici, pourquoi changer?

La nature du développement informatique est très propice au travail solitaire, mais le travail solitaire est lui-même très propice à l’erreur. Un programmeur solitaire a tendance à développer des habitudes qui lui permettent d’aller plus rapidement, mais qui sont nuisibles à la qualité et réduisent sa créativité. Une paire de programmeurs travaillant sur le même problème sera beaucoup plus productive, produira un travail de meilleure qualité, et sera beaucoup plus confiante dans le résultat. Les individus gagnent en expérience en étant exposés aux connaissances de l’autre, et l’organisation (employeur, projet, agence) y gagne en réduction des pertes de temps, meilleure qualité du travail, et dissémination des connaissances.

D’un point de vue purement monétaire, le coût de développer une solution en utilisant la programmation en paire est d’environ 20% supérieur au coût de développer la même solution en utilisant un seul programmeur. Cependant, les coûts engendrés par la correction d’erreurs après la mise en production font rapidement changer la balance, et la programmation en paire est en fait un bien meilleur investissement. Il peut être difficile de justifier le coût plus élevé au client, qui demandera inévitablement un programme sans erreur au moindre coût possible, mais un gestionnaire de projet expérimenté arrivera à présenter les avantages et convaincre le client qu'il s'agit en fait d'un investissement dans la qualité plutôt qu'une dépense additionnelle.

Les résultats d’études sont clairs: programmer en paire diminue le nombre d’erreurs
(source: « Strengthening the Case for Pair-Programming »)

Pour un gestionnaire de haut niveau (VP Informatique, VP Systèmes d’information, VP Technologie, CIO, CTO), il y a quelques autres aspects à prendre en compte. Des programmeurs qui travaillent en paire deviennent rapidement plus qualifiés (via le partage de connaissances avec d’autres programmeurs), et sont plus satisfaits par leur travail. Par conséquent, ces programmeurs sont capables de travailler sur des problèmes plus complexes et de produire une plus grande valeur pour la compagnie. Un autre avantage non négligeable est que le taux de rétention de ces employés sera plus élevé.

Faits vécus

J’ai personnellement essayé la programmation en paire, et l’expérience a été entièrement positive. Il s’agissait d’un projet de data warehousing pour lequel un contracteur a été engagé pour aider à produire le résultat plus rapidement. Le contracteur avait peu d’expérience avec le data warehousing, mais était expert en VB et de niveau moyen avec SQL. Ma grande force est le SQL et le design de systèmes de data warehousing; je ne connais rien au VB.

Nous avons commencé la programmation en paire de façon impromptue, puis avons décidé de le faire de façon rigoureuse. La première moitié de la journée était consacrée à de l’administration, documentation et au polissage du code écrit la veille, individuellement; la seconde moitié était passée à travailler sur un problème, identifier des solutions, implanter et tester, en équipe. Les tâches de design, programmation, test et implantation étaient toutes faites en équipe.

Le niveau de productivité atteint sur ce projet ne peut être comparé à aucun autre projet sur lequel j’ai travaillé; les problèmes complexes devenaient simples, les possibilités étaient plus nombreuses, les solutions plus complètes. Il y a toujours quelqu’un avec qui célébrer un succès, affronter un problème difficile, ou éviter de succomber à la tentation de lire son email...

Le prochain article présentera le cycle Développement-test-feedback utilisé par XP.

Eric Lagacé