Blog de Bruno Orsier

Un article de Bruno Orsier    Commentaires fermés

L’excellente ambiance de la conférence à Grenoble m’a motivé pour m’inscrire à celle de Valence à la dernière minute. J’ai accompagné Homo Agilis (Emmanuel Etasse) qui a déjà fait un excellent compte-rendu, donc j’apporte quelques compléments à ce qu’Emmanuel a déjà écrit.

J’ai assisté au début de l’atelier Agile Dojo : L’art de grandir en équipe, présenté par Ramiro Sarmiento. Cela fait plusieurs fois que j’entends parler de ces dojos, donc j’étais très curieux d’en voir un en pratique (avec l’idée d’en animer un moi-même plus tard). Ramiro nous a expliqué que les dojos se pratiquaient sous deux formes :

1. le kata. C’est une séance préparée, durant laquelle quelqu’un programme en public – l’idée étant de montrer le geste parfait (terme évidemment emprunté aux arts martiaux)
2. le randori. C’est une séance moins préparée, durant laquelle le public participe. Un binôme programme sur un PC relié à un projecteur, et un membre du public remplace un membre du binôme toutes les cinq minutes. C’est donc très rythmé et intensif.

J’ai noté quelques autres points de l’introduction de Ramiro :

• l’idée générale est de pouvoir (enfin !) programmer sans contrainte de type délai à respecter, et donc de pouvoir trouver la meilleure manière. Au minimum, le but est d’aimer ce qu’on a écrit !
• on essaie de respecter le principe KISS  – pour lui Keep It Simple but not Stupid – je connaissais plutôt Keep It Simple, Stupid  mais bon chacun a l’air d’avoir sa propre formule, et wikipedia mentionne aussi « Keep It Sweet & Simple » et« Keep It Short & Simple ».
• on peut passer par des phases appelées « spike », durant lesquelles on explore un sujet (par exemple pour trouver comment quelque chose fonctionne exactement – idéalement par des tests).
• en principe on ne passe pas trop de temps à faire de la conception, on laisse parler le code et les tests.
• durant ces séances, on explore aussi des voies d’amélioration comme la réduction de l’utilisation de la souris (et je suis bien d’accord car je vois de temps en temps des collègues perdre plusieurs minutes à faire des opérations qui pourraient se faire en secondes – le point ennuyeux n’étant pas la perte de temps mais plutôt la perte du fil de pensée).

Suite à cette introduction, nous démarrons sur l’exercice proposé (réaliser un jeu de démineur). Le démarrage est évidemment un peu poussif, d’autant plus que certains (comme moi) ne connaissent pas le langage utilisé (Java).

A la pause je dois malheureusement m’éclipser car je souhaitais écouter la présentation de Alexandre Boutin – c’est l’inconvénient de ces conférences où il y a plusieurs sessions intéressantes en parallèle, et des choix difficiles à faire. Je n’ai pas donc pu voir le randori dans son aspect le plus intensif, mais cette introduction m’a conforté dans l’envie d’en organiser un moi-même. Il y a un ensemble de règles à respecter, voir par exemple ce site qui me permettra de préparer la future séance.

Alexandre Boutin nous a ensuite fait une excellente présentation (comme d’habitude je dirais, ayant déjà vu sa présentation sur le Lean Software Development), donc je n’ai pas trop regretté le randori. Voir le billet d’Emmanuel pour plus de détails sur cette présentation.

La pause est l’occasion d’être présenté par Emmanuel à Laurent Bossavit, avec lequel j’avais été en contact par mail (il avait eu l’amabilité de relire mon tutoriel sur le TDD). Laurent nous indique que son sujet de prédilection depuis plusieurs années est la rétrospective. Ca tombe bien, c’est l’un des sujets qui nous semble délicat dans notre implémentation Scrum/XP (voir mon précédent billet). Laurent nous explique une des leçons qu’il a tirées : les actions de la rétrospective ne doivent concerner que les participants à la réunion de rétrospective. Conséquence : il faut parfois inviter des personnes en plus des membres de l’équipe : décideurs, managers etc. A méditer, car nos rétrospectives sont en général limitées aux seuls membres d’équipe.

J’ai alors assisté ensuite la présentation « le refactoring » de Régis Medina, et j’ai été très impressionné – en effet je suis familier depuis un moment avec le refactoring, mais je le pratique essentiellement à la main. Régis a fait une démonstration spectaculaire de remaniement de code Java grâce à IntelliJ IDEA. Il a aussi indiqué qu’il était un extrémiste du principe DRY – Don’t Repeat Yourself – ca tombe bien, moi aussi (voir mon article qui essaie de promouvoir ce principe) mais j’ai trouvé mon maître. Enfin Régis a expliqué l’une des conséquences du refactoring constant (et impitoyable) sur un gros projet sur lequel il a travaillé : un concept de plate-forme réutilisable (non prévu au départ) à fini par émerger. Bref, après cette belle présentation, le retour à la réalité – Delphi 7 et son manque d’outils de refactoring – est bien difficile ces derniers jours.

Pour terminer j’ai assisté à la présentation de Géry Derbier sur la méthode Crystal, présentation qui a été beaucoup appréciée par Emmanuel et d’autres participants. Mais j’ai eu un peu de mal à voir les aspects concrets de cette méthode, et j’ai parfois perdu le fil de la présentation. Crystal semble voir les choses de beaucoup plus haut que Scrum (Emmanuel en parle d’ailleurs comme d’une « méta-méthode »). Je suspecte que la grande réussite de Scrum vient de sa capacité à être rapidement comprise, et de sa mise en oeuvre assez directe. Crystal paraît moins « prescriptive ». En fin de séance, Emmanuel et moi avons interrogé Géry sur le rôle du manager dans un contexte agile (c’est aussi un de nos points sensibles, voir précédent billet). Géry nous a répondu que son rôle de manager, c’était de produire des équipes – et donc de travailler sur le recrutement, la formation, la communication. Encore un point à méditer, je ne pense pas que nous ayons atteint ce degré de maturité (comme je l’ai indiqué lors de ma présentation à Grenoble, pour nous le rôle de manager se superpose à celui de « pompier », expert technique etc.).

Et enfin, cette visite à Valence a été l’occasion de revoir ces dynamiques valentinois agiles que sont Emmanuel Chenu, Nicolas Blanpain, Emmanuel Herve (pour ceux que je connais). Bravo à tous ceux qui organisé et animé cette conférence.