Construire Ensemble — Chapitre #4 : Example Mapping
Définir les règles métiers et leur critères d’acceptations à travers des exemples de cas génériques et de cas particuliers
Construire Ensemble est une série d’articles relatant l’histoire d’une start-up fictive vivant dans mon cerveau. Nous suivons donc Bizz, le responsable business ; Paul Olivier (PO), le product owner ; Junior, le développeur junior ; Senior, le développeur senior. Chaque article évoque un point méthodologique précis de la réalisation d’un produit en accord avec des besoins business bien définis.
Si vous avez manqué le 3ème chapitre : Chapitre #3 —EventStorming, toujours plus de post-its
— Bienvenue à tous dans ce nouvel atelier, salua PO. Aujourd’hui nous allons faire ensemble un Example Mapping. Mais avant ça, laissez-moi vous rappeler notre démarche jusqu’à présent.
« Bizz nous a fait part d’un nouveau projet. Pour tenter d’en définir une version minimale répondant aux besoins business, nous avons créé une impact map, que vous pouvez voir s’afficher maintenant à l’écran pour raviver vos souvenirs :
« Nous nous sommes ensuite concentrés sur les différents livrables mentionnés dans l’impact map. Particulièrement sur la création d’un produit factice pour illustrer les différents concepts à mettre en place. Pour rappel, nous avons opté pour une petite application d’aide à la mémorisation longue durée via des flashcards à réviser de façon espacée. Pour que tout les membres de l’équipe comprennent bien cet univers, et utilisent les mêmes termes, nous avons défini un langage commun, et mis en évidence le processus complet de révision à travers un atelier d’EventStorming dont voici le résultat final :
« J’ai le plaisir de vous annoncez que, sans le savoir, vous venez de découvrir l’essence même du BDD »
— Le BDD ? Comme Behavior Driven Development ? demanda Junior. Je croyais que c’était un outil pour tester notre application en effectuant des tests automatisés sur notre UI. Quel rapport avec ce que nous avons fait jusqu’à présent ?
— C’est effectivement une confusion fréquente, répondit PO. Mais le BDD est une méthodologie de travail plutôt qu’un simple outil technique. C’est un ensemble d’outils méthodologiques, et techniques, permettant à une équipe de se concentrer sur le développement d’un produit en accord avec les spécifications fonctionnelles. Les ateliers que nous avons fait jusqu’à présent, qui visaient donc à créer une connaissance partagée du projet, font partie intégrante de la démarche BDD. Nous nous sommes concentrés sur la partie “produit”, mais la partie “technique” du développement concret du produit sera bientôt abordée. Mais pour l’heure, il nous manque encore des éléments importants qui nous empêchent de commencer à écrire du code.
— Les spécifications, fit Senior. Sans spécification on ne peut pas travailler convenablement. D’expérience, je remarque que la majeure partie des problèmes rencontrés sur un projet trouvent leur source dans des quiproquos sur l’interprétation des spécifications.
« Lorsque l’on travaille en silo, les objectifs business dictés par les responsables business au product owner, puis rédigés sous forme de spécifications par le product owner à destination des développeurs, génère autant d’étapes intermédiaires de compréhension des besoins réels que cela produit invariablement des incompréhensions. Un véritable jeu de téléphone arabe.
« Le corollaire de ce constat est le manque de critères d’acceptation pour une spécification donnée qui rend difficile de savoir quand un besoin fonctionnel est réellement assouvi. Les retours qui s’en suivent ralentissent tout le cycle de développement, qui aurait gagné en premier lieu à définir clairement ces critères d’acceptations. »
— C’est très juste, fit Bizz. C’est exactement la raison pour laquelle nous procédons à ces ateliers, et je pense que l’atelier d’aujourd’hui est totalement approprié.
— Alors commençons ! s’exclama PO. Cet atelier permet de remédier aux problèmes que tu viens de soulever Senior. L’objectif de l’example mapping est de trouver des exemples précis pour chaque fonctionnalité de notre application, afin de mettre en évidence les règles métiers. Chaque exemple sert donc comme critère d’acceptation pour une règle donnée, pour une fonctionnalité donnée.
— Je ne suis pas sûr de bien comprendre l’intérêt, fit timidement Junior.
PO, ayant anticipé une certaine incrédulité, afficha sur l’écran un exemple :
— Comme vous pouvez le voir, repris PO, on commence par définir une fonctionnalité sous la forme classique : “En tant que <rôle>, je veux <faire quelque chose>, afin de <objectif>”. C’est le post-it jaune ici.
« Les post-its bleus sont des règles métiers propre à la fonctionnalité. Pour chaque post-it bleu, il s’agit ensuite de trouver des exemples concrets qui serviront comme autant de critères d’acceptation.
« La première étape consiste donc à déterminer nos fonctionnalités. On peut utiliser l’EventStorming pour ce faire. En l’occurence, même si ce n’est pas toujours le cas, il peut être utile de partir des post-its bleus : les actions / commandes. Dans notre cas, nous pourrions partir sur 4 fonctionnalités :
- créer une boîte
- ajouter une flashcard dans une boîte
- démarrer une session de révision
- notifier si l’on a correctement répondu »
— Existe-t-il un cas où l’on voudrait créer une boîte sans tout de suite y ajouter une première flashcard ? demanda Bizz
— C’est une question pertinente, dit Senior. Je suis d’avis de réduire à trois fonctionnalités. La création de la boîte peut se faire au même moment que l’ajout de la flashcard.
— Comment dissocier les deux cas du coup ? s’interrogea Junior.
— Par des exemples, justement ! répondit PO. L’example mapping permet de mettre en avant les cas génériques mais aussi, et surtout, les cas particuliers. Je vous propose donc de commencer par cette fonctionnalité, celle de l’ajout d’une flashcard dans une boîte :
« La prochaine étape est de définir les règles métiers propres à cette fonctionnalité, par exemple, le fait que la flashcard est ajoutée dans la première partition de la boîte. On mentionne cette règle avec un post-it bleu :
Junior se leva pour ajouter un autre post-it:
— On ne doit pas non plus être en capacité d’ajouter une flashcard dont la question est déjà présente dans la boîte !
— Très bien, repris PO. Nous allons maintenant pouvoir passer aux exemples. Il est important pour cet exercice que tout le monde soit présent. Certains exemples de cas particuliers sont plus facilement soulignés par les développeurs, qui ont un esprit habitué à trouver les cas limites. D’autres vont appuyer un comportement de plus haut niveau de l’application, les responsables business et responsables produit peuvent être plus prompts à trouver ce genre d’exemples.
« Un bon exemple est limpide pour tout le monde, et son résultat est clairement identifié. Je vais mettre le premier exemple qui correspond au point soulevé par Senior tout à l’heure sur la création de boîte à l’ajout d’une flashcard :
— D’accord j’ai compris, fit Junior. En revanche, si la boîte existe déjà, on peut dire que la flashcard est alors ajoutée en dernière position dans la partition. Cela convient à tout le monde ? Parfait, je l’ajoute :
— Occupons-nous maintenant de la deuxième fonctionnalité, proposa Bizz. Je dirais simplement que si le joueur essaye d’ajouter une flashcard dont la question existe déjà parmi toutes les flashcards de la boîte, alors une erreur doit apparaître, d’une façon ou d’une autre :
— Passons maintenant à la fonctionnalité suivante, dit PO :
« Nous allons devoir discuter des différentes règles métiers applicables à la création d’un deck de session. Est-ce que vous vous souvenez de la façon dont sont sélectionnées les flashcards pour une session donnée ?
Junior pris la parole :
— Les flashcards de la partition 1 tous les jours, celles de la partition 2 tous les deux jours, celles de la partition 3 tous les trois jours, etc., jusqu’à la 5ème partition. C’est bien ça ?
— Tout à fait ! Indiquons-le sur le mur comme première règle :
— Que se passe-t-il si le joueur manque une session ? demanda Senior
— Dans ce cas, le deck de session contient les flashcards des jours précédents en plus de celles du jour en cours, précisa Bizz. Je vais ajouter cette règle :
— D’un point de vue technique, j’imagine que la première carte que l’on va réviser dans le deck sera la première de la pile, ajouta Senior. Ajoutons cette règle aussi :
PO résuma alors:
— Comme vous pouvez le voir, chacune de ces règles a été soulevée par quelqu’un de différent. Bizz a apporté les précisions plus “business” quant au fonctionnement du produit. Senior a pensé à des besoin “techniques”. C’est tout l’intérêt de faire l’example mapping avec les principaux membres de l’équipe. Trouvons maintenant les exemples pour ces règles…
— Très bien, dit PO. Regardons les exemples que nous avons trouvés :
« Comme on peut le remarquer, le deuxième exemple de la première fonctionnalité et l’exemple de la deuxième fonctionnalité sont pratiquement similaires. Ils diffèrent seulement dans le cas particulier qui nous intéresse.
« Vous remarquez aussi, dans le dernier exemple, que l’on parle de flashcard “A”, “B”, “C”. Le fait qu’une flashcard soit composée d’une question et d’une réponse n’est par pertinent ici, cela ne ferait que compliquer l’exemple. Vous pouvez tout à fait omettre volontairement des détails dans la définition des exemples s’ils ne sont pas pertinents pour la règle concernée.
« Définissons maintenant les exemples pour la dernière fonctionnalité : la notification d’une bonne ou d’une mauvaise réponse…
Senior contempla le mur, et pensa tout haut :
— Nous allons pouvoir nous servir de tout ces exemples pour développer le produit en ayant une approche pilotée par les tests. Je vais maintenant prendre le relais avec Junior. Nous sommes correctement armés pour répondre aux besoins fonctionnels du produit. Prochaine étape : transformer ces post-its en tests d’acceptation automatisés.
A suivre…
