Au cours de deux semaines de coaching autour du Domain-Driven Design et de l’eXtreme Programming, j’ai été amené à jouer un atelier assez enrichissant. L’objectif était de démontrer à la fois l’extraction de la connaissance de l’expert métier, et la manière de démarrer le développement en se concentrant uniquement sur ce langage commun.
Pour l’occasion, le PMO du projet a endossé le rôle d’expert métier. Son but : tenter de nous décrire son besoin en tant qu’organisateur de courses d’orientation pluridisciplinaires. Il faut avouer, c’était une chance qu’il connaisse si bien ce secteur sans aucun rapport avec notre travail au quotidien. De plus, nous n’avions rien préparé à l’avance, ce qui a donné un exercice « sans filet ». Il ne s’agissait donc pas d’une démonstration académique, mais bien d’une réalité tangible.
De mon côté, je devais, avec l’aide du reste de l’équipe, tenter de trouver son problème, négocier les bases d’un langage commun, puis développer la première histoire.
Nous avions un peu moins de deux heures pour mener à bien cet exercice.
Pour une équipe assez habituée à la communication avec le métier à travers des spécifications ou des écrans, je pense que le premier impact de cet atelier à été la découverte de cette discussion/négociation avec l’expert pour extraire un langage commun, jamais teinté de technique, d’Excel ou de solutions. Le langage extrait n’exprimait que des concepts riches de sens dans ce contexte : points de sécurité, équipe de sécurité, étapes, participants, performances, course, etc.
A la fin de cette discussion, nous avions un lexique, une mindmap capturant notre modèle naissant, et notre première histoire utilisateur. Nous avons pu aborder en plus quelques grands classiques des soucis de communication :
- des solutions étaient exprimées plutôt que des problèmes,
- beaucoup de synonymes, il a donc fallu décider lesquels choisir et s’y tenir,
- trop de détails : ils sont très utiles pour comprendre l’ensemble, mais il faut savoir abstraire et décider ce qui est pertinent ou pas dans le modèle en cours de construction.
Le deuxième point très marquant pour l’équipe a été, d’après les retours, l’absence totale de délai entre le moment ou nous avions notre première histoire utilisateur, agrémentée de son test d’acceptation, et le moment où nous avons commencé à développer. Effectivement, l’avantage de ne faire dépendre le cœur de l’application d’aucune considération technique, est que le démarrage du développement est aussi simple que le lancement de son IDE favori et l’écriture du premier test, exactement comme dans les coding dojos que j’animais le matin. Tous les katas que nous avions faits n’ont donc plus été vus comme des exercices d’esprit sans relation avec notre travail au quotidien, mais véritablement comme un entraînement en conditions réelles. Encore une fois, vu que nous n’avions rien préparé avec l’expert, cette demi-heure était du temps réel : voilà tout le temps qu’il faut pour démarrer un projet !
Enfin, pendant ce petit développement, nous avons dû régulièrement réinterroger notre expert sur des ambiguïtés que nous avions laissées passer, prouvant par là même qu’un souci dans le code représente un souci dans le métier, pas un souci technique.
Cet exercice a récolté les meilleurs ROTI de tout ce que j’ai pu faire en deux semaines, mais je ne le jouerai pourtant pas en premier si je devais être amené à refaire une mission équivalente. J’ai eu le sentiment que l’effet « révélation » de l’exercice n’a pu exister que grâce aux 4 mois de développement précédant mon arrivée, et aux deux semaines de coding dojo/formation/pair programming qui venaient de s’écouler. Apparemment, l’équipe continue l’exercice dans les désormais traditionnels dojos du matin, et j’ai bien peur qu’elle préfère bientôt développer sur l’exercice plutôt que sur le « vrai » projet :) Après tout, c’est exactement ce qui s’est passé pour nous sur Tiron.
J’espère aussi pouvoir compter à nouveau sur l’aide d’un expert jouant aussi bien le jeu la prochaine fois.
Crédit photos: Time / Alan Cleaver via Flickr CC License By