Et si l’Example Mapping se rapprochait du mouvement d’une bille
Vous allez découvrir que l’on peut faire l’analogie de l’Example Mapping et le Behavior Driven Development (ou BDD) avec des lois de la Physique (la loi du mouvement). Vous avez séché des cours de Physique pendant le lycée ? Ce n’est pas grave ! On vous explique tout cela !
L’Example Mapping, c’est quoi ?
Cet outil est très utilisé lors du 3 Amigos, atelier qui regroupe le Product Owner, le développeur et le testeurs qui vont développer et tester la Userstory prioritaire.
L’Example Mapping a différents avantages pour :
Aider à la compréhension du besoin pour ceux qui vont développer et tester,
Aider au découpage des Usertories,
Mettre en évidence des sujets que nous aurions pu oublier dans notre backlog lors de la maturation du sujet,
Préparer des Behavior-driven development (BDD).
L’expérience montre qu’avec un Example Mapping, il reste très peu de zones d’ombres sur une User Story avant de la développer.
Pour cette technique, nous avons besoin de :
Une Userstory (Post’it© jaune)
Ses différentes règles décrites (Post’it© bleu),
D’exemples (Post’it© vert) pour illustrer chaque règle, qui seront écrit par les 3 amigos … D’où son nom “Example Mapping”.
De questions (Post’it© rose) qui seraient en suspens.
Et les BDD dans tout cela ?
Les BDD vont nous aider à écrire chaque exemple, en utilisant la structure suivante :
Given — Etant donné que …
When — Quand …
Then — Alors …
Mais nous en reparlerons plus précisément par la suite.
Pour aller plus loin : Les 6 principes d’écriture d’une Userstory | by Silvere Duval | Just-Tech-IT | Medium
Comme le mouvement d’une bille
Maintenant, venons à la physique en comparant le mouvement d’une bille au BDD, en considérant que notre bille est notre “système” ou “objet”.
Le “Given” = l’état au repos de notre bille
La bille (notre système) est tout d’abord au repos. Pour représenter cet état dans notre Userstory, il suffira de décrire le contexte initial dans lequel elle est.
Prenons l’exemple d’une Userstory décrivant “un versement bancaire”, nous serions alors dans le cas suivant :
La bille au repos de notre Userstory :
“Nous avons un compte A qui sera considéré comme le compte débiteur et le compte B sera le compte créditeur.”
Attention, comme pour toute démarche scientifique, il est nécessaire d’être rigoureux, avec des données précises, pour être capable de reproduire l’expérience. Aussi, nous décrirons plus précisément notre “Given” dans notre exemple. Ce qui donnera :
“Nous avons un compte A qui sera considéré comme le compte débiteur avec un montant de 1.000 euros et le compte B sera le compte créditeur avec un montant de 500 euros.”
Le contexte a bien été posé.
Le “When” = ce qui va provoquer le mouvement de la bille
Une intervention extérieure (le doigt d’une main) va créer de l’énergie qui provoquera le changement d’état de la bille. Il en sera de même pour notre Userstory. Ce qui donnerait :
Pour notre exemple, le doigt de notre Userstory :
L’utilisateur souhaite faire le versement de 500 euros du compte A vers B.
Le “Then” = le mouvement de la bille
Il s’agit du résultat de la poussée du doigt sur la bille : la bille est en train de rouler de façon rectiligne ! Ce qui donnerait :
Pour notre exemple, la trajectoire rectiligne de notre Userstory :
Le compte A contiendra (1000–500)=500 euros et le compte B contiendra (500+500)=1000 euros
Mais attention au mouvement non attendu de la bille
Comme vous le savez, tout n’est pas parfait. Il est possible de mal taper la bille et de réaliser que sa trajectoire n’est plus rectiligne, comme attendu, mais qu’elle devienne curviligne !
Pour la Userstory, c’est la même chose. En creusant, pendant le 3 Amigos, l’un des membres peut se poser des questions sur des cas au limite ou des cas non passants. Ce qui donnerait :
Pour notre exemple, la trajectoire curviligne de notre Userstory :
Given : Nous avons au départ un compte A (débiteur) avec 499 euros et le compte B (créditeur) avec 500 euros.
When : L’utilisateur souhaite faire le versement de 500 euros du compte A vers B.
Then : Le versement sera impossible car le montant du compte débiteur (499) < montant à débiter (500).
Il s’agira alors d’une nouvelle règle à ajouter dans cette Userstory ou dans une nouvelle, en fonction de la décision des membres du 3 Amigos.
N’oublions pas les cas de Résilience, lorsque votre Système Applicatif ne répond plus, en définissant le résultat attendu (message d’erreur, etc.).
Et si vous avez mis trop de force ?
Vous perdez votre bille ! Pour votre Userstory, cela veut dire que votre exemple est surement trop complexe et pourrait être découpé … Peut-être même que votre règle devrait être découpée en plusieurs règles simples !
Un exemple complexe dans notre Userstory qui - finalement - pourrait être découpé :
Given : Nous avons au départ un compte A (débiteur) avec 0 euros, le compte B (créditeur) avec 500 euros et avec un seuil de versement de 400 euros.
When : L’utilisateur souhaite faire le versement de 500 euros du compte A vers B.
Then : Le versement sera impossible car (1) le montant du compte débiteur < montant à débiter et (2) le seuil de versement est dépassé.
En conclusion
En l’expérimentant, vous verrez que les BDD permettent de bien structurer et de clarifier vos exemples. N’hésitez pas à les tester avec votre équipe !
J’espère que cet article a éclairci la notion de BDD avec l’aide de cette bille !
Sources de cet article
Les 6 principes d’écriture d’une Userstory | by Silvere Duval | Just-Tech-IT | Medium
