Coma Informatique

Le développement en binôme est LA pratique la plus contestée de l’eXtreme Programming. A tel point que j’ai rencontré des partisans de XP qui n’avaient même pas essayé de la mettre en oeuvre.

Le contexte

Alors comment mettre en oeuvre cette pratique dans le contexte difficile d’une dotcom en 2002 ? Un certain nombre d’éléments étaient cependant favorable.

Tout d’abord il existait déjà un esprit d’équipe, sans doute liée à une certaine homogénéité en terme d’age et d’ancienneté. Cet esprit d’équipe s’exerçait plutôt dans des activités extra-professionnelle (repas, loisirs), alors que la culture d’entreprise centré sur la performance personnelle n’encourageait pas vraiment le travail en équipe.

C’est pourquoi le développement en binôme n’est pas facile à mettre en oeuvre. Parce qu’il est contraire aux pratiques habituelles dans l’entreprise. Ce n’est pas propre à l’entreprise, d’ailleurs. On a tellement l’habitude d’être évalué selon ses performances individuelles, durant sa scolarité et sa vie professionnelle, que la notion de performance collective est assez peu connue, à moins d’avoir joué de la musique dans un orchestre ou pratiqué un sport collectif.

La méthode

Le secret pour réussir tient essentiellement au coaching. Un changement de mentalité passera par de la pédagogie, et bien sur la pédagogie c’est d’abord répéter souvent les principes.

Il faut d’abord convaincre de l’intérêt de cette pratique. Au départ cela semble hasardeux. On a l’impression qu’un seul travaille (et il faut éviter que ce soit le “meilleur” du binôme qui soit systematiquement au clavier) et que l’autre s’ennuie. Et franchement au début ce n’est pas faux.

Alors il faut forcer les binômes à changer souvent. C’est à dire après chaque tache. Et verifier que ce n’est pas toujours le même équipier en face du clavier. Avec une bonne organisation des postes de travail c’est déjà plus facile de voir comment les gens travaillent et d’intervenir gentillement en cas de besoin.

Synchronisation

Evidement le problème qui peut arriver lorsqu’on veut souvent changer la composition des binômes c’est la synchronisation. Pour éviter cela il faut essayer de découper chaque scénario utilisateur en tâches techniques réalisable en quelques jours au plus (l’idéal étant une journée).

Lorsqu’un binôme a terminé sa tache et qu’aucun autre équipier n’est disponible pour former un autre binôme, chaque équipier peut effectuer un travail individuel en attendant de former un autre binôme. Car il ne faut pas oublier que seuls le développement de code utilisé en production doit se faire en binôme. Les autres taches comme la rédaction de document, le prototypage, l’exploration technique se font individuellement. Sans compter tous les taches par nature personnelles (lecture d’email, surf, etc). Éventuellement le binôme peut aussi commencer une autre tâche.

Les résultats

Petit à petit l’équipe voit les résultats arriver :

• Revue de code : La pratique du binômage revient à effectuer constamment une revue de code. Cela évite les erreurs de conceptions, favorise les solutions élégantes et simples, facilite la correction d’erreur.
• Transfert de compétences : Comme la composition des binômes varie souvent, les compétences techniques sont très vite partagés. Dans le cas qui nous intéresse, la maîtrise de la plateforme .Net au sein de l’équipe s’est faite sans organiser une formation générale de l’équipe, mais simplement grâce à la formation en amont du projet de 2 personnes sur 8.
• Partage de l’information : C’est un point crucial pour l’adoption de la méthode par les membres de l’équipe. En effet très rapidement on constate qu’il n’y a plus de chasse gardé dans le code. Cela évite le phénomène fréquent de surcharge du responsable d’un module critique. Le stress est moindre puisque personne n’est vraiment indispensable (bien que globalement l’équipe le soit).

Rien n’est acquis

Malgré l’unanimité qui se fait dans l’équipe à propos des avantages de la méthode, on constante quand même une tendance naturelle à l’abandon du binômage et un retour à un travail individuel. C’est là qu’interviendra à nouveau le coach. Et aussi la mise en place d’un système incitatif dans la politique de rémunération. Mais c’est une autre histoire

A suivre…

Cet article a été publié par Alexis KARTMANN le Dimanche 8 mai 2005 à 16:54 et est classé dans Tags:extreme programming, programmation
.
Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.