
Il est en ce moment un nom qui provoque des frissons d'indignation chez les
DSI et les managers. Une pratique qui, même dans certaines organisations ayant
adopté intégration continue et TDD au sein de leurs équipes de développement,
reste un tabou autour duquel gravitent beaucoup d'idées reçues. Cette pratique
mal-aimée, du moins en France, c'est le Pair Programming.
Qui n'a jamais entendu la réflexion suivante : "La programmation en
binôme, c'est payer deux développeurs pour faire le travail d'un seul. Ma
direction n'acceptera jamais ça." Il y a peu j'ai même entendu de la part d'une
société qui pratique pourtant d'autres techniques d'ingénierie agiles au
quotidien : "Nous ne sommes que quatre développeurs, vous comprenez qu'on
ne peut pas se permettre ce genre de façon de travailler !"
Pourtant, les études montrant l'efficacité du Pair Programming ne manquent
pas. Le chiffre habituellement donné est celui d'un développement 15% plus lent
qu'avec deux développeurs séparés mais qui produit 15% de bugs en moins. Quand
on sait que le temps de debug et de test est souvent bien plus long que le
temps de développement initial, un tel gain de qualité n'est pas négligeable.
Des études plus récentes vont plus loin, affirmant que pour des
logiciels complexes, le Pair Programming apporte en moyenne un gain de qualité
de 48% sans qu'il y ait de différence significative au niveau des délais.
Au-delà des chiffres, il y a le constat d'amélioration omniprésent lorsqu'on
pratique le Pair Programming sur une période de temps significative. Pour
l'avoir expérimenté entre autres en tant que membre d'une équipe à la fois
nombreuse (10 à 15 développeurs) et hétérogène en termes de maturité sur le
projet et d'expertise technique, les effets constatés sont assez
spectaculaires :
- Diffusion rapide de la connaissance du domaine à tous les membres de
l'équipe
- Montée en compétence technique favorisée par le binomage expert-novice (le
novice ne se contentant pas d'écouter, il agit aussi, lorsqu'il a le
clavier)
- Choix de conception et d'implémentation de meilleure qualité, fruits de la
réflexion conjointe et de la confrontation d'idées des deux coéquipiers
- Moins de perte de temps et de déconcentration, le copilote servant de
barrière de sécurité pour rester dans les rails de l'objectif fixé
- Emulation au sein de chaque binôme et de l'équipe entière
Bien sûr, il ne s'agit pas de partir la fleur au fusil pour une colocation à
durée indéterminée avec le collègue avec qui on se marrera le mieux. Il y a une
rigueur à adopter et certaines règles de conduite nous y aident. Par exemple,
le fait de timeboxer systématiquement les scéances de pairing, et de changer de
coéquipier régulièrement (toutes les semaines, tous les jours, toutes les
demi-journées, à l'équipe de trouver son rythme).
Je ne suis pas non plus partisan du 100% Pair Programming. Il y a certaines
tâches de codage, parmi celles les plus répétitives et nécessitant le moins de
réflexion et d'arbitrages, qu'un développeur peut, avec autant de qualité et
plus d'efficacité, assurer seul.
En revanche, le binomage me parait être d'un bénéfice tellement évident pour
certaines autres activités que je ne vois pas bien comment s'en passer. Par
exemple, lorsqu'il s'agit d'intégrer un nouveau membre dans l'équipe ou pour le
transfert de compétences entre un développeur partant et son remplaçant.
Enfin, un des avantages du Pair Programming qu'on ne cite jamais, mais qui
serait pourtant de nature à rassurer les responsables, est le gain de rigueur
et de focalisation dans le travail accompli. Un développeur qui paire sera
moins tenté d'aller consulter son facebook ou lire ses mails perso toutes les
cinq minutes. D'une part par respect pour son coéquipier, parce qu'il n'a peut
être pas envie d'étaler sa vie privée, et d'autre part parce que programmer en
binôme, c'est fixer mutuellement un cap et s'y tenir. C'est toujours beaucoup
plus engageant de se promettre conjointement avec un autre développeur
d'arriver au bout de cette fonctionnalité avant la pause déjeuner, que de se le
promettre juste à soi-même.
Dans ces conditions, on peut se demander pourquoi tant de structures, même
celles qui se revendiquent agiles, n'adoptent pas le Pair Programming. Sans
doute est-ce une aberration dans un système encore dirigé par la sacro-sainte
mesure de la performance individuelle par rapport au temps de travail. Sans
doute aussi les décideurs voient-ils inconsciemment dans des coéquipiers des
gamins qui se font plaisir plutôt que des travailleurs.
Au moins pourraient-ils, comme le préconise Martin Fowler, se donner la peine de l'essayer :
My view is that you should try it and the team should reflect on whether
they feel they are more effective with pairing that without. As with any new
practice make sure you allow enough time so you have a good chance of crossing
the ImprovementRavine.