Vous voulez clarifier une user story avant le développement ?
Vous reprenez une story présente dans la backlog depuis un moment ?
Besoin de cas de tests d'acceptation concrets et précis ?
Example Mapping est un exercice simple qui s’y prête bien. Cet atelier permet d’instaurer une discussion courte et productive entre le PO, le(s) développeurs et le testeur sur la user story.
Comment cela fonctionne-t-il ?
Cet atelier doit être fait sur une courte durée (environ 30 min) pour une story. L’exercice demande de la concentration. J’ai remarqué qu’au delà de 25 min, les membres se fatiguent et trouvent l’exercice long pour analyser une simple story.
Il est préférable de faire cet exercice avec nos “3 amigos” :
- Product Owner: présente le besoin et les règles associées
- Développeur: sera guidé sur son choix technique et les tests à écrire par les examples
- Testeur: (Quality Assurance) propose des examples qui respectent les règles métiers.
Cela ne signifie pas que nous avons que 3 rôles dans la réunion. Mais nous devons avoir les trois profils présentés. Par exemple, on peut avoir un PO, 2 développeurs ( un back, un front) et un testeur.
Pour le matériel, il faut des post-it de différentes couleurs (jaune, bleu, vert et rose), un tableau physique ou virtuel (ex: Miro, Klaxoon). La raison première de l’utilisation des post-it est de nous permettre de les manipuler/déplacer plus facilement durant la discussion. Ensuite, le fait d’avoir des couleurs différentes permet de distinguer les 4 notions : Story, Rules, Example et Question.
Au début de la discussion, on indique le titre de la story sur laquelle les membres de l’équipe présents vont travailler. Ensuite, les critères d’acceptation (Rules) sont exposés tout au long de la discussion. Chaque critères d’acceptation aura zéro ou plusieurs Examples. Pour définir un example, on se laisse guider par le comportement que va avoir l’utilisateur sur notre logiciel. Nous retrouvons 2 pratiques du BDD (Behaviour Driven Design):
- Discovery : discuter de la User Story à travers des exemples
- Formulation : documenter les exemples.
Puis, si le public présent ne peut pas répondre à certaines questions, on les note sur un post-it pour y répondre à posteriori.
Exemple de résultat de l’atelier:
La durée et la fréquence
Lorsque l’atelier est nouveau pour l’équipe, cela peut prendre beaucoup de temps au début. Je vous conseille pour les premiers ateliers de préparer l’Example mapping avec les critères d’acceptation déjà connus. Du coup, vous allez vraiment vous concentrer sur les examples et peut-être découvrir de nouveaux critères d’acceptation. Vous vous rapprocherez donc de la durée préconisée de 25 min.
Si au bout des 25 min, vous n’avez toujours pas fini (c’est-à-dire que la story n’a pas été validée “ready” par tous les membres) cela signifie peut être que la story est trop grosse.
Ensuite, il est conseillé d’en faire une à deux fois par semaine pour que l’équipe s’imprègne et comprenne l’intérêt de l’exercice. Et dans le temps, vous pourrez le pratiquer sur les stories ayant beaucoup de zones d’ombre.
Que vous apporte ce type d’atelier?
Il va vous permettre de vous concentrer sur des comportements concrets de votre story et identifier les comportements qui n’ont pas leurs places dans votre story mais dans une autre. Cela évite donc d’avoir de grosses stories et de découvrir des surprises en fin de développement. Si vous avez beaucoup de questions, cela donne aussi un indice sur la complexité de la story.
L’atelier permet aussi de faciliter le dialogue entre les différents membres s’il est compliqué voire inexistant. Cela évite que chaque membre reste dans le flou tout le long du développement.
Utiliser cet atelier pour valider une US peut devenir une règle de la Definition of Ready (DOR).
A quel moment faut-il faire un Example Mapping?
Je vous conseille de le faire avant le développement de la story. Grâce à cet exercice, nous mettons en avant les exemples qui vont permettre de piloter le développement. Le développeur écrit les tests en s’aidant des exemples et ensuite le code adéquat pour rendre les tests passants. Il fait donc du TDD. Par ce type de pratique, vous convergez vers un code de meilleur qualité.
Cet atelier est nécessaire tout le temps.
En mode remote ?
En ce temps de confinement, cet atelier s’y prête bien car on garde le dialogue et une trace écrite en cas de doute.
Il vous faut juste un outil qui vous propose de retranscrire les post-it en carré de couleur.
Par exemple, vous avez l’outil Miro qui propose un tableau blanc et des post-it de couleur virtuellement. Il s’y prête bien et est facile à utiliser.
En outre, il faut garder en tête que l’objectif de la discussion est de résoudre le fond de la story et de découvrir les choses que vous ne connaissez pas. Ajoutez de la complexité à l’exercice quand tous les membres seront à l’aise et matures sur l’atelier. Par complexité, j’entends par exemple l’écriture des examples au format Gherkin.
Ensuite, on pourra faire émerger des pratiques comme l'automatisation de ces tests. Et dans ce cadre, on se posera des questions sur les outils à utiliser. Un article va suivre sur cette troisième pratique du BDD.
Pratiquer l’Example Mapping signifie favoriser la communication et déterminer les scénarios les plus importants pour vous.
