Ma valise de programmeur
Accueil du site > Essais > Binômer ? on est pas là pour s’amuser !

Binômer ? on est pas là pour s’amuser !

dimanche 10 septembre 2006, par Etienne Charignon

De plus en plus d’entreprises éditrices de logiciels organisent leurs équipes de travail en binôme, c’est à dire que les développeurs écrivent des programmes informatiques en se mettant à deux par clavier. Qu’est-ce qui a pu motiver ces entreprises à changer ? Cette pratique est-elle le fait d’illuminés rêvant d’un monde meilleur où la moitié des employés se tournerait les pouces ?

Ce qui est étonnant, c’est que le binômage existe depuis plus de 20 ans, mais l’engouement pour ce mode de fonctionnement semble récent. Si on recherche des informations à propos du binômage dans la littérature d’il y a quelques années, certaines études [1]avaient montré que la productivité d’un binôme était de 1,8 par rapport à celle de deux personnes travaillant indépendamment (productivité de 2). En effet, la première constatation est qu’un binôme ne travaille pas deux fois moins vite que deux personnes séparées. Et pourtant ce résultat ne permet pas de justifier que des entreprises décident de choisir ce mode d’organisation.

Ce qu’on constate à travers des expériences plus récentes, c’est que la pratique du binômage associée à d’autres pratiques, telle que la planification itérative ou le développement piloté par les tests, permet de faire passer la productivité de 1,8 à 4. C’est à dire que deux personnes ensemble parviennent à travailler deux fois plus vite que si elles étaient séparées.

Un avantage du binômage est la relation à la peur et à l’apprentissage. Bien souvent, un développeur seul, surtout s’il est jeune (ce qui est souvent le cas) n’osera pas avouer qu’il ne connaît pas la solution à son problème. Il préférera chercher seul et passera beaucoup plus de temps dessus. S’il avait travaillé en binôme, il aurait simplement appris ces choses sans avoir à les demander, simplement en regardant un collègue travailler. Sans parler d’incompétence, ce phénomène se vérifie en particulier lors de l’arrivée d’une nouvelle personne sur un projet.

Imaginez que le développement logiciel ressemble à un voyage. Un voyage dans un monde hostile. Imaginons par exemple que nous ayons à parcourir une certaine distance dans un mètre de neige. Est-ce que nous voyagerions plus vite en marchant tous de front, ou à la queue-leu-leu ? La pratique commune qui consiste à faire travailler les membres d’une équipe individuellement n’est pas naturelle et très inefficace. Et qu’on ne me dise pas qu’il est possible de travailler en équipe tout en étant individuellement concentré sur des taches distinctes. On ne peut pas d’un coté dire "travaillez ensemble" et de l’autre donner des taches disjointes à chacun. C’est le meilleur moyen d’empêcher l’équipe de se former. Je le sais pour le vivre chaque jour en ce moment. Quand on est concentré sur un problème donné de conception, il est vraiment très difficile de se concentrer sur le problème de son voisin. Il faut pour cela se déconnecter complètement de ce que l’on est en train de faire. Pour reprendre ma métaphore, on ne peut pas dire d’un côté "allez tous dans la même direction" et de l’autre donner des directions différentes à chacun.

Enfin, le binômage apporte l’homogénéité d’une solution informatique, il facilite l’application des standards de codage et facilite encore, cette fois de manière indirecte, l’arrivée d’une nouvelle personne. Cela facilite aussi la maintenance. Comme on le voit, le binômage vient renforcer les avantages d’autres pratiques fondamentales du développement logiciel. Ce sont tous ces petits renforcements accumulés qui permettent de dire que le binômage permet de travailler plus vite.

P.-S.

Au sujet de la mécompréhention du binômage, voir aussi cet article : PairProgrammingMisconceptions

Notes

[1] Malheureusement, je n’arrive pas a retrouver la référence à ces études et même, comme l’explique Martin Fowler, il n’est pas possible de mesurer la productivité ! CannotMeasureProductivity Quoi qu’il en soit, les chiffres de 1,8, 2 ou 4 permettent de bien expliquer les idées de cette article et me semble correspondre à ce que je connais

SPIP | squelette | | Plan du site | Suivre la vie du site RSS 2.0