Gérer les hommes
CHAPITRE 6
193
À un extrême, les processus lourds figent très tôt une conception détaillée au travers d'une
documentation riche, segmentent les activités de développement et multiplient les métriques pour assurer le suivi des plans. De grosses dépenses sont consenties sur des phases
très spécifiques : la conception en début de projet, puis l'intégration et les tests en fin de
projet. Ce dernier centre de coût se révèle régulièrement et de loin le plus gour mand, en
révélant très tardivement certains choix de conception.
De l'autre côté, les méthodes agiles font le pari d'une approche incrémentale, transversale
avec des itérations courtes ; les activités de test, conception et développement sont mélangées et nourries des points de vue de tous les intervenants du projet. Plus nous déplaçons le
curseur dans cette direction, plus les coûts sont étalés sur toute la durée du projet. Contrairement aux idées reçues, ils ne sont pas plus importants, car la phase finale de test avant livraison est réduite à son minimum et ne révèle plus de surprise.
En fin de spectre, la pratique du binômage représente l'extension de cette même logique, car
la complémentarité des points de vue s'exerce en temps réel pour tous les choix d'implémentation. Le copilote assume un double rôle de garde-fou et de stratège : son détachement
du clavier lui permet de considérer la cohérence d'ensemble de ce qui se construit en listant
tout détail qui germerait dans sa tête sans interrompre le contexte du pilote. C'est le garant
de la qualité de réalisation de la tâche. À ce stade, les coûts associés à un changement de
direction technique sont faibles par comparaison avec ceux qui se produisent plus tardivement et hors contexte. Enfin, cette pratique limite efficacement les coûts relatifs au turnover
en garantissant que toute partie du code est au moins connue par deux personnes.
L'enveloppe budgétaire en mois/homme paraît a priori plus élevée aux yeux des clients et
sponsors. Pourtant, ce calcul doit tenir compte des activités de maintenance et de correction
de défauts, qui occupent encore trop souvent la moitié des effectifs d'une équipe chargée d'un
logiciel ! Ces fonctions pénibles et ingrates précipitent le départ des bons programmeurs en les
démotivant. Le retour sur investissement réalisé dans le binômage est très difficile à mesurer.
Dans les projets complexes et/ou à forte technicité, l'expérience prouve que cette pratique
réduit très fortement les risques de défauts, et donc les coûts directs et indirects qui y sont
associés.
3) La réponse de l’expert Laurent Bossavit, président de l'association Agile France.
Le pair-programming consiste à s'organiser en binômes de programmeurs : deux programmeurs partagent un clavier, un écran, et collaborent à une même tâche. On peut en effet se
dire que deux programmeurs, chacun sur leur poste, vont avoir une production double de celle
d'un binôme... à condition de considérer que le travail d'un programmeur, c'est de la dactylographie !
En réalité, la frappe au clavier ne constitue que la partie triviale du travail d'un programmeur.
Ce qui compte, c'est le temps qu'il met à analyser le problème posé, à imaginer une, de préférence plusieurs, solutions, à soumettre ces solutions à une analyse critique, à implémenter une
solution et à la tester. Toutes ces tâches peuvent être plus efficaces « à quatre mains ».
Notamment, si le binômage permet d'éviter des défauts (bogues) au moment de la programmation, le temps gagné se récupère au décuple ou au centuple : on sait en effet depuis longtemps qu'une erreur qui prend 10 minutes à détecter et réparer pendant l'implémentation peut
gaspiller des heures voire des jours si on attend la phase de recette ou la mise en production.
GestProjInform Livre Page 193 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 6
193
À un extrême, les processus lourds figent très tôt une conception détaillée au travers d'une
documentation riche, segmentent les activités de développement et multiplient les métriques pour assurer le suivi des plans. De grosses dépenses sont consenties sur des phases
très spécifiques : la conception en début de projet, puis l'intégration et les tests en fin de
projet. Ce dernier centre de coût se révèle régulièrement et de loin le plus gour mand, en
révélant très tardivement certains choix de conception.
De l'autre côté, les méthodes agiles font le pari d'une approche incrémentale, transversale
avec des itérations courtes ; les activités de test, conception et développement sont mélangées et nourries des points de vue de tous les intervenants du projet. Plus nous déplaçons le
curseur dans cette direction, plus les coûts sont étalés sur toute la durée du projet. Contrairement aux idées reçues, ils ne sont pas plus importants, car la phase finale de test avant livraison est réduite à son minimum et ne révèle plus de surprise.
En fin de spectre, la pratique du binômage représente l'extension de cette même logique, car
la complémentarité des points de vue s'exerce en temps réel pour tous les choix d'implémentation. Le copilote assume un double rôle de garde-fou et de stratège : son détachement
du clavier lui permet de considérer la cohérence d'ensemble de ce qui se construit en listant
tout détail qui germerait dans sa tête sans interrompre le contexte du pilote. C'est le garant
de la qualité de réalisation de la tâche. À ce stade, les coûts associés à un changement de
direction technique sont faibles par comparaison avec ceux qui se produisent plus tardivement et hors contexte. Enfin, cette pratique limite efficacement les coûts relatifs au turnover
en garantissant que toute partie du code est au moins connue par deux personnes.
L'enveloppe budgétaire en mois/homme paraît a priori plus élevée aux yeux des clients et
sponsors. Pourtant, ce calcul doit tenir compte des activités de maintenance et de correction
de défauts, qui occupent encore trop souvent la moitié des effectifs d'une équipe chargée d'un
logiciel ! Ces fonctions pénibles et ingrates précipitent le départ des bons programmeurs en les
démotivant. Le retour sur investissement réalisé dans le binômage est très difficile à mesurer.
Dans les projets complexes et/ou à forte technicité, l'expérience prouve que cette pratique
réduit très fortement les risques de défauts, et donc les coûts directs et indirects qui y sont
associés.
3) La réponse de l’expert Laurent Bossavit, président de l'association Agile France.
Le pair-programming consiste à s'organiser en binômes de programmeurs : deux programmeurs partagent un clavier, un écran, et collaborent à une même tâche. On peut en effet se
dire que deux programmeurs, chacun sur leur poste, vont avoir une production double de celle
d'un binôme... à condition de considérer que le travail d'un programmeur, c'est de la dactylographie !
En réalité, la frappe au clavier ne constitue que la partie triviale du travail d'un programmeur.
Ce qui compte, c'est le temps qu'il met à analyser le problème posé, à imaginer une, de préférence plusieurs, solutions, à soumettre ces solutions à une analyse critique, à implémenter une
solution et à la tester. Toutes ces tâches peuvent être plus efficaces « à quatre mains ».
Notamment, si le binômage permet d'éviter des défauts (bogues) au moment de la programmation, le temps gagné se récupère au décuple ou au centuple : on sait en effet depuis longtemps qu'une erreur qui prend 10 minutes à détecter et réparer pendant l'implémentation peut
gaspiller des heures voire des jours si on attend la phase de recette ou la mise en production.
GestProjInform Livre Page 193 Vendredi, 3. avril 2009 12:07 12