InfOsaurus

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Pair Programming

Fil des billets - Fil des commentaires

dimanche 1 avril 2012

Code Retreat Montpellier

Le 24 Mars dernier se déroulait le premier Code Retreat à Montpellier, animé par Antoine Vernois et organisé par Julien Lafont, Vivian Pennel et Sylvain Fraïssé. L'événement avait lieu dans les locaux de l'école Epitech. Je ne vais pas rappeler les règles d'un code retreat en détail, mais il s'agit d'une rencontre où on développe en pair programming sur un problème donné - en général le Conway's Game of Life, sous forme d'itérations de 45 minutes en changeant de binôme à chaque fois. Voici mon petit retour (tardif) sur la journée.

Ce que j'ai aimé :

  • La bonne humeur générale propice aux échanges, avec des développeurs venus d'un peu partout (Montpellier mais aussi Marseille, Toulouse, etc).
  • La variété des langages présents, de Java à Python en passant par Scala, Ruby et plein d'autres.
  • Le cadre d'Epitech sympa, dans une bâtisse ancienne montpelliéraine rénovée.
  • L'efficacité d'Antoine qui avait visiblement reçu 5/5 l'unique conseil avisé de Corey Haines :)

Ce que j'ai appris :

  • Le pouvoir des contraintes. Se mettre des restrictions très pénibles (pas de if, de boucles, pas de getters/setters...) force en fait à réfléchir autrement et paradoxalement on en tire plein d'enseignements à mettre en application plus tard.
  • Un Code Retreat, ça passe très vite, aussi bien la journée que les itérations elles-mêmes. Au bout des 45 minutes, on est systématiquement frustré d'être si loin de voir notre monde en vie, surtout quand de précieuses minutes ont été passées en contingences matérielles annexes. Mais c'est le jeu, ma pauvre Lucette :)
  • Ruby, ça a l'air de roxxer. Il faut que je m'y penche de plus près.
  • Décidément, j'ai du mal à convaincre mes petits camarades que C#, c'est bien. Pourtant, C#, c'est bien ;)

Si c'était à refaire :

  • Eviter de se pointer avec un langage ou un environnement qu'on maîtrise mal. Je pense qu'il est crucial qu'un des deux membres du binôme connaisse très bien la techno utilisée pour pouvoir se concentrer uniquement sur les tests et l'émergence du design. J'ai le sentiment d'avoir passé trop de temps à cerner des détails de langages, c'est intéressant mais pas forcément dans les clous de la journée.
  • Peut-être expliquer un peu mieux au début de la journée ce qu'est TDD, ou demander aux gens de se renseigner dessus avant. J'ai l'impression qu'il y avait un taux assez haut de "totale découverte TDD" dans la salle ce qui est bien sûr enrichissant au niveau du partage, mais a peut-être généré une certaine perplexité.

Dans la catégorie "j'ai testé pour vous" :

  • Casser la cafetière du code retreat dès le matin (encore désolé Julien)... j'ai un peu fait mon boulet sur ce coup-là.
  • Le Conway's Game of Life en Python avec un binôme qui n'avait fait que du C et pas familier du développement objet. Tout ça sans if et sans boucle sinon c'est pas drôle... Ou comment expliquer le polymorphisme à quelqu'un en 5 minutes :)
  • Le ping-pong programming à 3 sans avoir le droit de se parler et avec un test runner JUnit qui crashe de temps en temps. Un grand moment... d'incompréhension, mais très instructif sur notre dépendance à la communication !


Debriefing entre deux sessions

En tout cas, très bonne expérience que ce premier code retreat, encore merci aux organisateurs et aux participants ! A quand la prochaine ? ;)

samedi 19 septembre 2009

Le mouton noir des pratiques d'ingéniérie

Un mouton noir parmi les brebis vertueuses

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.