[3/4] - Comment bien démarrer un projet : exposer les règles métiers grâce à l'Example Mapping
Temps de lecture estimé : 5 min
Cet article fait partie d’un groupe d’articles visant à bien préparer le backlog du premier sprint d'un projet avant de commencer à développer. C’est le troisième article de la série, si vous avez manqué le deuxième, le voici : Comment bien démarrer un projet : organiser les besoins grâce au Story Mapping
Bonne lecture !
La semaine dernière, nous avons vu comment le Story Mapping pouvait nous aider à formuler les besoins grâce à un support de discussion : la User Story.
Maintenant que nous avons quelques User Stories, nous pouvons procéder au recueil plus fin des règles métiers qui les sous-tendent.
Pour ce faire, l’atelier d’Example Mapping est tout indiqué ! Il va nous aider à définir les règles métiers des User Stories et dans un second temps il nous permettra de découper plus finement ces US !
Qu’est-ce que l’Example Mapping ?
Attention, énorme spoiler : il va s’agir de collecter des exemples ! Et des exemples concrets.
Eh oui, c’est dingue je sais, vous ne vous y attendiez absolument pas ;)
Mais dis-moi Jamy, c’est quoi un “exemple concret” ?
Haha ! Glad you fuc*ing ask !
(ouais je suis en roues libres niveau référence pop culture)
Un exemple concret, c’est un exemple qui :
expose un contexte bien défini
illustre un comportement précis, avec des données réalistes
met en évidence des règles métiers
Lors d’un atelier d’Example Mapping, on part donc d’une User Story, qui je vous le rappelle est un support de discussion. Eh bien, c’est le moment où l’on en discute !
On écrit généralement la User Story sur un post-it jaune, les exemples sont écrits sur des post-it verts, les règles métiers illustrées s’écrivent sur des post-it bleus et les éventuelles questions soulevées sur des post-it rouges.
Comme un exemple vaut mieux qu’un long discours, c’est parti pour un exemple d’Example Mapping ! Let the Exampleception begin !
Session d’Example Mapping pour une User Story de CraftOverflow
Partons de cette US :
Le premier exemple que j’aimerais illustrer est le plus simple qui me vienne à l’esprit : up-voter une réponse ayant déjà reçu des votes
Pour formuler cet exemple, on commence par les éléments de contexte. Si Dev veut exprimer son feedback, ça ne sort pas de nulle part.
Voici donc le contexte :
Dev est connecté
Dev consulte la question “Quelle différentre entre TDD et Test First ?”
Les réponses suivantes sont données :
"Test First se positionne dans l'espace de solution alors que TDD est dans l'espace du problème pour tendre vers une solution" - 5 votes
"Le TDD c'est la seule vraie méthode Test First originale" - 3 votes
Dans mon exemple, je définis donc la notion de connexion, bien que l’on en est encore jamais vraiment parlé.
Je définis aussi une “vraie” question, crédible. Je n’écris pas “Dev consulte la question A”, l’important est d’avoir des exemples concrets, avec des données réalistes.
Pareil pour les réponses, je mets des réponses crédibles, et j’indique le nombre de votes actuel.
Maintenant on peut s’intéresser à l’action concrète :
Dev est d’accord avec la réponse : "Test First se positionne dans l'espace de solution alors que TDD est dans l'espace du problème pour tendre vers une solution”
Dev fait un up-vote
L’action concrète définie, il ne reste qu’à illustrer le résultat attendu :
La réponse a maintenant 6 votes positifs
La structure d’un exemple est donc :
Given un certain contexte
When une certaine action
Then un résultat attendu
Et évidemment ce n’est pas un hasard ;) Nos exemples serviront de tests d’acceptation !
On donne un titre à l’exemple, et on le positionne sous l’US, sur un post-it vert :
Notre exemple posé, il convient maintenant dans extraire la règle métier qu’il illustre ! Dans notre cas, c’est une règle simple, mais qu’il faut tout de même définir explicitement : up-voter une réponse augmente son nombre de votes de 1
On ajoute alors cette règle sur un post-it bleu, entre l’US et l’exemple :
Ce genre d’atelier est censé se faire en équipe, pour que chacun puisse apporter son avis et proposer des exemples parfois alambiqués, mais nécessaire ! Et notamment nous, les devs, on a l’habitude des cas un peu vicieux, c’est pourquoi notre présence à ce genre d’atelier est primordiale !
Un ou plusieurs exemples pour une seule règle métier, mais pas l’inverse
Si plusieurs règles métiers doivent être mises en évidence, il est plus judicieux de créer des exemples séparés pour que chaque lot d’exemples ne corresponde qu’à une seule règle métier.
Dans l’exemple ci-dessus on peut voir apparaitre implicitement une autre règle métier : les réponses sont triées par votes, du plus grand nombre de votes positifs au plus petit.
Il serait tentant d’ajouter un ticket bleu à côté de celui-déjà présent pour rédiger cette règle.
Mais à la place, il vaut mieux créer un exemple qui va l’illustrer de manière plus explicite :
Prenons un dernier exemple pour mettre en évidence le dernier type de ticket : les tickets rouges : ceux des questions.
Si vous connaissez bien StackOverflow, vous savez certainement qu’il existe un système de réputation qui fait que down-voter une réponse a un “coût”. Cela nous coûte un point de réputation, et ce, pour éviter d’avoir des down-votes agressifs et injustifiés.
Nous avons à aucun moment parlé de système de réputation dans notre version “mini” de StackOverflow.
Toutefois, cela souligne des interrogations pertinentes, et en ce sens elles peuvent être notées sur ce fameux post-it rouge :
Je ne vais pas détailler ici tous les différents exemples de toutes les UC de CraftOverflow, je pense que vous avez saisi le principe !
À retenir :
L’atelier d’Example Mapping permet de poursuivre concrètement la discussion sur les User Stories.
L’atelier doit être court ! Environ 30 minutes pour une User Story.
Cet atelier se fait en présence de quasiment toute l’équipe : les développeurs, les product-owners, les responsables business éventuels, et idéalement les clients finaux si possible.
L’objectif est d’établir une liste d’exemples concrets d’utilisation pour illustrer chaque User Story et ainsi mettre en évidence les règles métiers, et d’éventuels questionnements.
Un exemple s’écrit sous la forme :
Given un certain contexte
When une certaine action
Then un résultat attendu
Lorsqu’une User Story apparaît de toute évidence trop grosses, car il existe beaucoup d’exemple et de cas particulier possible, c’est probablement l’indication qu’il faut découper la User Story.
Nous verrons donc la semaine prochaine quels moyens sont à notre disposition pour découper au maximum les User Stories pour en générer de simples “tâches” ayant toutes la même complexité, rendant de fait les estimations inutiles :)
Happy Coding !