Example Mapping

Qu’est-ce que l’Example Mapping ?

L’Example Mapping est une méthode qui utilise des exemples concrets pour illustrer et mieux définir les critères d’acceptation d’une user story. L’objectif de l’atelier est d’encourager l’échange, autour d’un même référentiel, entre les business owners et l’équipe de développement.

S’accorder sur des exemples énoncés dans le langage métier participe à construire une compréhension commune des spécifications. Les développeurs ont l’opportunité de mettre en exergue les cas limites et de directement les clarifier avec les business owners. La responsabilité d’établir les spécifications adéquates est ainsi partagée entre les business owners et les membres de l’équipe de développement.

Dans les pratiques Agiles, l’Exemple Mapping est généralement attaché au TDD (Test-driven Development) ou au BDD (Behavior-driven Development). Les tests peuvent être directement déduits des exemples. A des fins de traçabilité, ces derniers constituent une documentation vivante et dynamique du projet.

Qui est concerné par un atelier d’Example Mapping ?

Bien que des grands ateliers impliquant à la fois l’équipe de développement, les représentants du métier et les experts métier soient un moyen efficace de diffuser la connaissance au sein des équipes, ils sont difficiles à organiser et très coûteux en temps et en argent. Pour une équipe mature, ce type d’ateliers est probablement excessif.

C’est pourquoi les équipes Agiles préfèrent généralement organiser de petits ateliers, qui n’impliquent qu’un business analyst ou un product owner, un développeur et un testeur. Cette configuration est la plupart du temps suffisante pour confronter les différentes perspectives. Cet atelier se nomme les Trois Amigos.

Comment mener un atelier d’Example Mapping ?

L’Example Mapping a recours à quatre catégories d’éléments :

• La user story est écrite un post-it (ou une carte) jaune. Il s’agit du point de départ de l’atelier.
• Des post-it bleus sont utilisés pour écrire les règles liées à la user story, généralement les critères d’acceptation et les éventuelles contraintes.
• Les exemples sont écrits sur des post-it verts. Ils servent à illustrer les règles.
• Les éventuelles questions sont indiquées sur des post-it rouges. Tant que ces questions n’ont pas trouvé de réponses, elles ne doivent pas être considérées comme étant prêtes à être implémentées.

Si, à la fin de l’atelier, vous avez trop de règles, cela peut signifier que la user story analysée devrait être scindée en deux parties ou plus. Si vous avez trop d’exemples sous une règle, cela peut signifier que la règle devrait être divisée en plusieurs parties. L’Exemple Mapping est une bonne façon de s’assurer que les user stories sont toujours de la bonne taille.

Comment rédiger des exemples dans l’optique d’écrire de bons tests ?

Pour écrire de bons tests, il vous faut, tout d’abord, les spécifier correctement. C’est pourquoi la rédaction des exemples doit dresser le contexte, ne concerner qu’une seule action, et définir précisément les conditions de sortie. Pour ce faire, vous pouvez utiliser la méthode Given-When-Then tirée du BDD :

• Etant donnée une précondition (Given a precondition) ;
• Quand une action a lieu (When an action happens) ;
• Ensuite, les conditions suivantes doivent être satisfaites (Then the following post-conditions should be satisfied).

Illustrons cette méthode avec un exemple :

• Etant donnée le fait qu’un utilisateur a dépassé la limite des 500 objets ;
• Et que plus de 24 heures se sont écoulées depuis ;
• Quand un utilisateur se connecte à l’application ;
• L’utilisateur ne peut plus éditer un document.