Parmi les pratiques d'une des méthodes agiles les plus répandues, eXtreme Programming (XP), la programmation en binôme est sans doute l'une des plus contestée : les managers voient à coup sûr ce qu'ils y perdent (de l'argent), plus difficilement ce qu'ils y gagnent.
Quel est donc le surcoût d'un travail en binôme, et qu'y gagne-t-on ?
Il existe pour y répondre des études quantitatives conduites méthodiquement, avec comparaison de tâches identiques menées soit en paire soit en solo. Je n'étudie ici qu'un petit sous-ensemble de ces articles, dans le but de comparer leurs conclusions avec ma propre expérience de ce mode de travail.
Synthèse à la fin du billet si vous êtes pressé...
Laurie Williams, 2000
La thèse de doctorat de Laurie Williams est inévitablement citée sur ce sujet de la productivité du pair programming. Son "Ph. D", Collaborative Software Process, présente et analyse les mesures de temps et de qualité pour des tâches de développement menées par 38 paires et 38 développeurs solos.
Laurie Williams montre ainsi que, passée une phase d'accommodation au travail en binôme ("team jelling"), le temps total consommé par un binôme n'est que 15% supérieure au temps passé par un développeur solo, au lieu du 100% attendu dans le cas ou une paire se comporte comme "un qui bosse, l'autre qui glande".
Mais en face de ce surcoût de 15%, le gain en qualité rapporté par l'auteur est de 15%. Pour le mesurer Laurie Williams a compté le nombre de tests réussis et constaté une nette différence entre programmes développés en paire et en solo.
Nombre de tests réussis sur quatre programmes développés soit en solo ("individuals"), soit en binôme ("collaborators"). Reproduction de Collaborative Software Process, p. 61. En moyenne, une paire produit deux fois moins de bugs qu'un développeur solo.
C'est un résultat qui a marqué son époque (mais pas en France ?). Il est d'ailleurs cité dans un article de 2001 de The Economist (Agility counts) qui fait le point sur cette méthode de travail :
"Laurie Williams de l'Université de L'Utah à Salt Lake City a montré que les développeurs en binômes sont seulement 15% plus lent que deux développeurs isolés, mais produisent 15% de bugs en moins. Comme les tests et le deboggage coûtent souvent beaucoup plus cher que le développement initial, ces résultats sont impressionnants."
Mais n'en déplaise à The Economist, la formulation choisie par le journaliste est maladroite voire fausse. Il ne s'agit pas de "15% de bugs en moins" (formulation répétée de citations en citations sur le Web, Wikipedia inclus), mais de 15% de tests qui passent en plus. Cette confusion est dommageable parce qu'elle occulte une formulation bien plus frappante : en comparant maintenant le nombre de bugs produits dans les deux modes de travail, il s'avère que les binômes produisent deux fois moins de bugs en moyenne !
Juste en passant, on trouve dans le même article de The Economist cette petite phrase :
"D'une certaine façon, le monde du logiciel est en retard pour adopter l'idée d'une innovation réactive et souple qui repose sur l'équipe."
C'était il y dix ans...
Lui et Chan, 2006
Plus récemment, Lui et Chan ont cherché à comprendre l'effet de l'expérience des développeurs sur la productivité des paires. Leur publication, Pair programming productivity: novice-novice vs. expert-expert, montre que le travail en paire est d'autant plus intéressant en regard de la productivité et de la qualité produite que l'objet du programme est nouveau et représente un défi pour les développeurs :
"Une paire est beaucoup plus efficace que deux individus en termes de temps de livraison et peut concevoir une solution supérieure en termes de qualité et de maintenance quand le problème à résoudre est nouveau et que le design, les algorithmes et le codage demandent plus d'efforts."
Plus loin, le corollaire est encore plus clair :
"L'efficacité de la programmation en binôme chute quand les développeurs ont déjà travaillé sur un problème similaire et n'ont pas encore oublié cette expérience."
Les chiffres : Lui et Chan montrent que plus les tâches sont faciles et routinières aux yeux des développeurs, et plus le coût de la paire tend vers deux fois le coût du développeur solo. Inversement, une tâche nouvelle, c'est-à-dire pour laquelle les développeurs qui s'y collent sont novices, ne coûte en paire que 29% plus cher qu'en solo.
En termes de délais de réalisation, les paires novices sont 1.5 fois plus rapides que les solos novices, alors que la différence de délai entre paires expertes et solo expert est insignifiante.
En somme Lui et Chan ont montré que le binômage n'apporte rien au travail de routine, dépourvu d'imprévu et de création, proche du travail à la chaine, pour lesquels la valeur créée croît linéairement avec l'effort consenti. A l'inverse, les tâches plus innovantes, qui surprennent par des difficultés inattendues, plus proches du bureau d'étude que de l'usine logicielle, bénéficieront des échanges entre binômes, et plus généralement du travail en équipe.
Ceci n'est pas de l'ingéniérie logicielle.
Vanhanen & Lassenius, 2005
Dans leur étude "Effect of pair programming at the development team level: an experiment", Jari Vanhanen et Casper Lassenius montrent, à partir d'un (trop) petit ensemble d'étudiants en informatique travaillant soit en binômes soit en solo sur des tâches de développement identiques, que :
- La productivité des paires est inférieure de 29% à la productivité des solos tant que le système à développer n'est pas maîtrisé. Elle devient supérieure de 5% après cette étape d'apprentissage.
- Une paire produit moins de bugs que des développeurs solos.
- Le pair programming amène à l'équipe un meilleure transfert de connaissance, chaque développeur d'une équipe en mode binôme maîtrisant plus de packages Java que les développeurs des équipes solo.
Erik Arisholm et al., 2007
Le papier de Erik Arisholm et al., Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise, est souvent cité comme argument contre la programmation en paire. De fait les mesures rapportées dans cette étude et les conclusions qui ont découlent ont de quoi secouer les plus convaincus :
Les résultats de cette expérience ne confortent pas les hypothèses suivant lesquelles la programmation en binôme en général réduit le temps requis pour finir correctement les tâches ou augmente la proportion de solutions correctes. Au contraire, finir correctement une tâche requiert 84% de travail en plus.
Dans les faits, Erik et son équipe ont étudié des tâches pour lesquelles le pair programming est coûteux. Il s'agit de tâches de maintenance (et non de développement), menées dans des conditions très différentes de la réalité du développement en paires : les quelques 300 développeurs découvrent en même temps le système à faire évoluer et le travail en binômes.
Mon interprétation :
- "Atterrir" sur un projet existant et y mener une tâche de maintenance (c'est le scénario de l'étude) est très différent du travail d'implémentation d'une nouvelle fonctionnalité sur un projet familier. La différence est qu'il y a une étape préalable de compréhension et d'apprentissage du nouveau système. Avant même de comprendre la tâche de maintenance qui nous est demandée, il nous faut explorer, parcourir les fichiers, comprendre l'organisation, cliquer sur un type et rechercher sa définition... Autant d'actions exploratoires propres à celui qui apprend, difficile à concilier avec une souris pour deux... Erik Arisholm et son équipe ont finalement retrouvé sur ce point de l'apprentissage les conclusions de Vanhanen & Lassenius.
- On n'est pas immédiatement opérationnel en programmation en binôme. Tous les développeurs qui ont l'habitude de travailler seul, ils sont nombreux, ont besoin d'une période d'adaptation allant de deux heures à plusieurs jours avant d'être efficace en paire. Il n'est pas évident, pour un travail qu'on pensait solitaire de devoir soudain se faire comprendre, écouter, débattre et argumenter sur des sujets aussi abstraits que ceux de la programmation. Il y a un temps d'adaptation (le "pair jelling" de la thèse de Laurie William) nécessaire au moins pour converger vers un vocabulaire commun qui n'est pas considéré dans cette étude.
Les conditions très précises de cette publication ont en tout cas permis d'identifier des situations où le pair programming est à déconseiller : pour des tâches de maintenance à mener à bien sur un logiciel inconnu, avec des développeurs habitué au travail en solo, les résultats ne seront pas bons. C'est une étape à dépasser pour récolter les bénéfices du travail en équipe.
Les auteurs montrent par ailleurs que pour des développeurs juniors, le travail en paire booste la qualité de 149% comparé au travail en solo, ce qui n'est pas le cas pour les développeurs confirmés ou seniors.
Tentative de synthèse
Il y aurait beaucoup d'autres études à analyser, mais il se dégage déjà de ces quelques articles des tendances qui me paraissent claires, confortées par ma propre expérience du travail en binôme.
- Le pair programming est très avantageux quand dans le compromis qualité/délais/coût, on recherche d'abord la qualité -- moitié moins de bugs d'après la thèse de Williams.
- La pertinence du pair programming dépend de la complexité ressentie des tâches : développements simples pour des juniors, complexes pour des seniors.
- Les phases exploratoires, pendant lesquelles les ingénieurs découvrent un nouveau système, se prêtent mal au binômage. A moins d'une paire exceptionnellement fusionnelle, les méthodes de chacun pour aborder et comprendre un nouveau système sont rarement compatibles.
A ces points j'ajoute une vertu certaine du pair programming, généralement reconnue par ceux qui l'ont pratiqué (Cf. cette étude): le binômage favorise le partage des connaissances quelles qu'elles soient, depuis les raccourcis clavier jusqu'aux subtilités du programme développé, en passant par les patterns et anti-patterns, astuces diverses et bonnes pratiques professionnelles. En somme, le genre de partage de compétences qui existent dans tous les métiers du monde sauf en ingéniérie logicielle...
Et a contrario, le binômage perd de son intérêt quand :
- Les tâches sont répétitives, évidentes, ou simplement familières aux développeurs.
- Les développeurs sont en phase d'exploration et de compréhension de l'existant.
- Par manque de moyens, quand le financement du 15-30% de jour-homme supplémentaire est tout simplement impossible.
- Quand la qualité du logiciel produit importe peu, par exemple parce qu'il s'agit d'un site Web évènementiel sans évolution attendue, ou parce que les maintenances évolutives et correctives seront facturées au client -- il y a des commerciaux particulièrement habiles.
- Le management est satisfait de l'absence de management technique imposé aux ingénieurs, dont le mode de travail tend vers un equilibre naturel, le Cowboy programming, cararactérisé par une prime a la rétention d'information, une forte compétition interne et un encouragement a l'héroïsme qui donnent de bons resultats à court terme.
