Dojo agile : le challenge de programmation

Dans un billet précédent, j’ai décrit le début de notre dojo agile : vidéos, exercice sur le « task-switching », présentation des règles du randori. La dernière partie avait consisté à présenter un challenge de programmation, qui servira de support à un randori dans un futur dojo. Il n’y a pas eu de programmation proprement dite pour l’instant, mais la discussion qui a eu lieu est un exemple du dialogue entre le product owner et l’équipe ; ce dialogue me paraît un aspect essentiel de Scrum, et c’est pourquoi je le rapporte ici.

Tout d’abord le challenge. En tant que product owner, je voudrais que l’équipe me réalise un simulateur de fourmis. La première histoire d’utilisateur (user story) que j’ai imaginée est … Eh, attendez ! Dans mon rôle de product owner, je devrais me focaliser sur la valeur apportée par ce projet, et donc être capable de l’expliquer.

Valeur du projet

Donc voici quelques éléments justifiant la valeur de ce travail :

• le simulateur de fourmis devrait nous faire progresser sur les tests automatisés. En effet sur une telle application, il va être difficile de faire du test au niveau de l’interface graphique (difficile manuellement/visuellement, ou même avec un outil extérieur, de suivre chaque fourmi et de décider si elle a le comportement désiré). Cela devrait nous obliger à trouver un moyen de faire des tests complètement automatisés, et nous avons besoin de progresser sur ce point. En effet nous avons tendance à facilement laisser de côté les problématiques de test un peu délicates (et à nous reposer sur des tests manuels), mais ce faisant nous augmentons parfois notre dette technique (et il y a des intérêts à payer !).
• le simulateur devrait permettre de garder nos chimistes (non programmeurs) impliqués dans les dojos. En effet réaliser le simulateur va impliquer d’autres travaux que la programmation, par exemple s’assurer de la vraisemblance biologique du travail réalisé, faire des recherches sur les capacités des vraies fourmis, s’assurer que les tests sont pertinents, etc. Garder les chimistes impliqués est vital pour que ces dojos parlent vraiment de « l’art de grandir en équipe », et c’est vital pour que toute l’équipe progresse sur la question des tests.
• le simulateur est un bon exemple de projet que le développeur moyen (comme moi) est fortement tenté de commencer par l’interface graphique. Pourquoi ? Comme ce sujet paraît relativement difficile, travailler sur l’interface graphique est un moyen de se rassurer, de voir rapidemment des choses qui fonctionnent, de trouver des réponses à des questions. Mais c’est préjudiciable à plus long terme : le code de calcul sera très probablement noyé dans l’interface graphique, il sera impossible à tester automatiquement, tous les tests seront faits visuellement et empiriquement, on passera de longues heures en debug, etc. Dans ce randori nous allons essayer de lutter contre cette tentation naturelle. Et justement le TDD permet de voir rapidemment des choses qui fonctionnent ! A nouveau la valeur est de progresser sur les tests, et d’écrire du code plus testable.
• ce projet devrait être amusant ! Et c’est important ! C’est l’une des leçons que j’ai retenues de la formation Scrum dispensée par Pyxis : Scrum devrait permettre de trouver (ou retrouver) du plaisir à pratiquer le métier d’informaticien (bon, ils vont encore plus loin car ils veulent « démontrer que c’est possible de réaliser des projets fournissant des résultats exceptionnels tout en ayant une qualité de vie exceptionnelle et en s’éclatant à fond » – cf leur blogue). En tout cas la valeur pourrait être une augmentation de la productivité grâce à une formation et un projet plaisants.
• enfin, dans le simulateur de fourmis, sous l’apparence d’un jeu se cache une famille d’algorithmes d’optimisation tout à fait intéressante et avec des applications très sérieuses comme le routage sur un réseau (il s’agit des méthodes ACO pour ant colony optimization). Donc ce projet permet à des ingénieurs en calcul scientifique de connaître une nouvelle classe d’algorithmes.

Voila pour la valeur de cette réalisation. Après avoir écrit tout ca je me rends compte que c’est assez ambitieux, et je ne sais pas où cela va nous mener !

Histoire d’utilisateur

Retour à ma première histoire d’utilisateur : « en tant qu’utilisateur, je veux que les fourmis trouvent le plus court chemin entre de la nourriture et la fourmilière ».

En plus, en tant que product owner, j’impose la contrainte suivante : « la modélisation que vous ferez devra avoir une vraisemblance biologique ». Ce qui veut dire que la modélisation devra respecter certaines connaissances sur les fourmis :

• les fourmis ne savent pas qu’elles font partie d’une colonie
• les fourmis sont influencées uniquement par des événements locaux
• les fourmis savent retourner à la fourmilière (elles connaissent la direction générale)
• les fourmis laissent une odeur (phéromone) sur le sol quand elles ont trouvé de la nourriture
• cette odeur s’évapore au fil du temps

Cette liste n’est pas exhaustive, la recherche d’informations complémentaires de ce type fait partie du projet. A ce stade l’idée derrière cette contrainte de vraisemblance biologique est d’interdire des algorithmes centralisés qui piloteraient l’ensemble des fourmis, ainsi que des algorithmes de recherche de chemin optimal etc. Le comportement global désiré devra émerger de comportements individuels.

A ce stade j’avais l’impression d’avoir fait un bon travail de product owner : définition d’une histoire d’utilisateur, identification de contraintes (l’expérience montre que les product owners ont beaucoup de mal à le faire), un critère d’acceptance (le plus court chemin). Vous allez voir que c’est loin d’être suffisant pour que l’équipe et moi ayons une compréhension commune : les membres de l’équipe ont posé beaucoup de questions que je n’avais pas anticipées, et n’ont pas manqué de me faire préciser le critère d’acceptance, comme le dialogue ci-dessous l’illustre.

Le dialogue

Equipe : est-ce que les fourmis volent ? nagent ?
PO : ni l’un ni l’autre. L’eau est un obstacle.

Equipe : pour nous aider à comprendre l’histoire, quel est l’état initial ?
PO : un monde informatique avec un point « fourmilière » et un point « nourriture ». Ce monde est un espace limité (fini). C’est un monde plat (pas en 3D). On peut convenir que c’est un rectangle. Les bords du rectangle sont des obstacles pour les fourmis.

Equipe : initialement, est-ce que les fourmis sortent de la fourmilière ou sont disposées aléatoirement dans le monde ?
PO : cela m’est égal, vous pouvez faire ce qui vous arrange. Equipe : on fera probablement sortir les fourmis de la fourmilière.

Equipe : initialement, y a-t-il des obstacles ?
PO : en principe oui, mais si vous voulez on peut commencer par une histoire utilisateur sans obstacles du tout. C’est probablement pertinent.

Equipe : maintenant on comprend l’état initial, mais quand le jeu finit-il ?
PO : c’est le point difficile. Quel est le critère d’acceptance de l’histoire, finalement ? Quand le chemin le plus court a été identifié clairement (pour un observateur extérieur). Je propose le critère « une majorité des fourmis ayant trouvé de la nourriture prennent le plus court chemin ».

Equipe : est-ce qu’on ajoute des fourmis en cours de route ?
PO : non. De même les fourmis sont immortelles, et on n’en retire aucune.

Equipe : combien il y a de fourmis ?
PO : Je n’ai pas décidé. Je voudrais que ce soit un paramètre.

Equipe : est-ce qu’on peut ajouter des obstacles en cours de route ?
PO : non, les obstacles sont fixés au départ. Peut-être que plus tard je voudrai ajouter des obstacles, mais ce sera une autre histoire.

Equipe : est-ce qu’une fourmi est un obstacle pour une autre fourmi ?
PO : non.

Equipe : dans quelles directions peut aller une fourmi ?
PO : dans 8 directions (donc diagonales autorisées).

Equipe : est-ce la nourriture diminue ?
PO : non, la quantité de nourriture est illimitée.

Equipe : est-ce que les fourmis détectent la nourriture à distance ?
PO : non, il faut qu’elles tombent dessus pour la détecter.

Equipe : est-ce que les fourmis font des aller-retours ? Est-ce qu’elles suivent la piste odorante en repartant de la fourmilière
PO : oui dans les deux cas.

Equipe : quelle est la vitesse moyenne d’une fourmi ? Quel est le temps d’évaporation des phéromones ?
PO : je ne sais pas. Peut-être à déterminer par l’équipe. Peut-être que ce doit être un paramètre. Une constante me paraît aussi acceptable.

Equipe : est-ce que les fourmis suivent obligatoirement une piste odorante ? Ou bien il y a un ratio de fourmis aventurières qui ne suivent pas la piste ?
PO : probablement pas toutes. Donc un ratio me paraît intéressant. Par contre il n’est pas nécessaire de rendre ce ratio variable au cours du temps. De même il ne paraît pas nécessaire de décider à la « naissance » d’une fourmi si elle est aventurière ou non. C’est un critère statistisque.

Equipe : est-ce que la fourmi dépose de la phéromone uniquement au retour (ie avec de la nourriture)
PO : il me semble que oui.

Equipe : est-ce que les phéromones se cumulent ?
PO : oui.

Equipe : est-ce que les fourmis savent dans quel sens va la piste odorante ?
PO : probablement oui. Mais il faudrait confirmer (rechercher sur internet).

Equipe : qu’est-ce qui fait que les fourmis prennent le plus court chemin ?
PO : je pense que la notion d’évaporation des phéromones est essentielle – c’est l’évaporation au fil du temps qui pénalise les longs chemins.

Equipe : donc les fourmis se déplacent aléatoirement en l’absence de phéromone ?
PO : en effet. Et quand il y a une odeur, cela influence leur déplacement.

Voilà nous en sommes restés là, les trois heures consacrées à ce dojo étant écoulées. Suite dans un prochain billet. En attendant je dois affiner mon backlog, en particulier travailler mes critères d’acceptance ! J’espère aussi que la lecture du livre Ant Colony Optimization va m’éclairer…