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.

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.

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.

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.

S’appuyant sur plusieurs années d’expérience et ayant rassemblé les retours d’expérience d’une cinquantaine de projets, Gojko Adzic a synthétisé quelques conseils dans le livre de référence Specification by Example :

• Les exemples doivent être précis. Pour éviter toute ambiguïté, il est important de bien définir le contexte d’un exemple et de clairement décrire comment le système est censé fonctionner. L’exemple doit être aisément vérifiable.
• Les exemples doivent être réalistes. Pour ce faire, il est conseillé d’utiliser des données réelles (quand cela est possible) et de s’appuyer sur des exemples réels d’utilisateurs ou de clients. Évitez d’utiliser des utilisateurs ou des clients abstraits (tel que “Client A”) et essayez de trouver un utilisateur ou un client qui possède les caractéristiques que vous souhaitez illustrer.
• Les exemples doivent être faciles à comprendre. Veillez à ne pas explorer toutes les combinaisons possibles, par exemple, en construisant un tableau qui aurait des dizaines de lignes et de colonnes. Vous devez plutôt vous concentrer sur les cas classiques et les cas limites. Le but de l’Example Mapping reste d’aider l’équipe à identifier les lacunes fonctionnelles ou les incohérences des spécifications.
• Les objectifs de performance doivent être établis précisément. Les caractéristiques telles que la performance ou le temps de réponse sont des besoins non-fonctionnels. C’est pourquoi beaucoup d’équipes peinent à les définir avec des données discrètes, laissant ainsi un doute quant à l’interprétation, ce qui peut entraîner de la sous- ou de la sur-qualité. Vous devez fournir aux développeurs des objectifs de performance précis à atteindre.