Lors de l’atelier N°2, nous avons eu l’occasion de discuter de l’Extreme Programming (XP). Cette méthodologie implique quelques valeurs fondamentales : la communication, la simplicité, le feedback, le courage et le respect.
Cette méthodologie implique également la programmation en binôme.
Et l’on arrive donc à ma question : pensez-vous que la programmation en binôme soit une bonne chose pour le rendement d’une équipe ?
Et vous pouvez étayer vos réponses en précisant des cas concrets.
L’approche XP est une manière d’aller plus rapidement à la solution en s’affranchissant d’une phase formelle de conception.
Dans un environnement vierge ou pour une réalisation ne nécessitant que peu d’intégration à un système d’information existant, cela tient la route (pour peu que le binôme soit d’un bon niveau et homogène).
Mais, je pense que cela ne fait sens qu’avec une méthode agile. C’est à dire une approche où les modules fonctionnels sont réalisés un à un avec, à chaque fois, une version opérationnelle.
l’XP appliquée à une réalisation d’une appli de gestion dont les spécifications et le dossier de conception détaillé sont écrits ne fait pas sens.
l’XP sera une approche qui plaira aux « jeunes » développeurs, souvent pressés de taper la première ligne de code (même parfois sans même savoir ce qu’ils ont à faire 🙂 ) et, je crois, aux équipes géographiquement proches qui se lancent dans la réalisation d’un jeu.
En effet, les JCLN ( 😉 ), je veux dire les jeux en ligne alternatifs, sont souvent développés de manière agile. On commence par le noyau, on lance le jeu que l’on enrichit au fur et à mesure avec, à chaque fois, une mise en production (qui va souvent servir de tests 🙂 ).
Dans ce contexte, et parce qu’il est rare que nous prenions le temps de bien spécifier la fonction attendue, l’XP sera parfaitement adaptée et réduira drastiquement les « bugs » : 4 yeux et 2 cerveaux sont plus efficace que 2 fois 2 yeux et 1 cerveau.
A titre personnel, sans avoir mis en place une méthode agile ni même l’XP, sur certains projets « en retard », je me suis mis en « co-pilote » d’un de mes développeurs qui laissait trainer pas mal d’anomalie.
L’approche est TRES efficace. Mais vraiment TRES TRES efficace. Au bout du « sprint » (là, il s’agissait d’un tout petit module fonctionnel à debugguer et ca n’a pas durer plus de 2 heures), aucune régression, pas de bug tout fonctionnait.
L’appli y a gagné en robustesse et le développeur (si on avait remis ça régulièrement), le « copilote » a permis d’éviter les écueils que le « pilote », le nez dans le guidon, ne voyait pas.
Bref, si vous avez le binôme, qu’il est homogène et que chaque membre est prêt à laisser l’autre s’exprimer (ca, c’est pas toujours évident avec des personnalités qui se croient « fortes » pour ne pas admettre qu’elles sont en réalité abusives, impolies et autoritaires), essayez !