Coding Dojo

'Coach agile' voici le titre professionnel que je me suis donné. Je ferais mieux de le changer en 'Explorateur agile'. En effet je découvre chaque semaine un nouvel aspect, une nouvelle méthode, un atelier, un modèle de pensé lié de près ou de loin à ce que l'on appelle l'Agilité, ou tout au moins à la conception que j'en ai et la façon dont je pratique. Le Coding Dojo est la dernière de ces découvertes. Ces deux dernières semaines, j'ai pu assisté à l'un en C# organisé pour la communauté ATLNet Rennes et à un second en Ruby organisé cet fois-ci par RennesOnRails.

J'avais lu des articles, j'en avais entendu parlé, maintenant je sais comment cela fonctionne et dans quelle situation je peux l'utiliser.

Le premier était animé par Laurent Morisseau et Guillaume Collic. Le sujet était de réaliser un convertisseur de nombres arabes en nombres romains. Après une présentation du principe et de la philosophie, Laurent commence à coder accompagné des commentaires de Guillaume. Selon les principes de développements dirigés par les tests, de faire au plus simple et d'émergence de la conception par incrément, le programme prend progressivement et naturellement forme.
A cette occasion, je rencontre une femme qui est venue par curiosité. Elle ne travaille pas du tout dans le domaine informatique mais dans les relations humaines ce qui de mon point de vu est de moins en moins dissocié.

Le second coding dojo, celui de cette semaine, est présenté par Karine Sabatier et animé par Emmanuel Gaillot, l'une des personnes à l'origine de ces pratiques.

Quelques règles que Emmanuel nous a données avant de commencer

PAS DE DESIGN SANS CODE
ET PAS DE CODE SANS TEST.

1. Ecrire un test qui ne fonctionne pas.

2. Faire passer le test de la manière la plus simple qui soit.

3. Nettoyer le code (lisibilité, duplication, algo et structure).

4. Et on recommence en écrivant un nouveau test.

On s'arrête quand?
Quand on en n'a plus envie de continuer.

La fourmi de longton, voilà le sujet. Une petite foumi se balade dans un monde qu'elle découvre au fur et à mesure qu'elle se déplace.

Finalement, c'est ça. Je me sens un peu comme cette fourmi; je me promène dans le monde 'agile' et à chaque fois que je bouge, je le découvre.

Si vous réalisez ce programme, vous pourrez constater que le mouvement chaotique de la fourmi au début finit par se déplacer dans un mouvement ordonné. Pour ceux qui ne programment pas, voici ce que ça donne avec trois fourmis.

Ce genre d'exercice, me semble utile dans les cas suivants :

• partager des pratiques de codage
• sensibiliser et expliquer le TDD
• montrer par l'exemple les valeurs XP
  comme la simplicité, le courage, respect...
• prouver que l'on s'autorise à se tromper
• que l'on code tous de la même façon :
  en tapant sur le clavier

A la prochaine