Construire Ensemble — Chapitre #3 : EventStorming, toujours plus de post-its
Relier les évènements aux utilisateurs, aux actions qui peuvent les déclencher, et aux read models nécessaires à la prise de décision
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 2ème chapitre : Chapitre #2 —EventStorming
La pause terminée, Junior, Senior, Bizz et PO se positionnèrent devant le mur, prêts pour la prochaine étape de l’EventStorming. PO pris la parole :
— Juste avant la pause nous avons réussi à modéliser sur le mur tout le processus de révision d’une flashcard, de son ajout dans une boîte, jusqu’à la réponse donnée par l’utilisateur. Je vous invite à vous rafraîchir la mémoire en regardant à nouveau sur le mur où nous en étions :
— Il y a ce fameux post-it vert dont on ne sait toujours pas vraiment ce qu’il représente, dit Junior.
— En effet, repris PO, et nous n’allons pas tout de suite en parler, car je vais introduire encore un nouveau type de post-it : le post-it bleu ! Les évènements que nous avons placés sur le mur ensemble, représentés par les post-it orange, n’apparaissent pas comme par magie. Ils peuvent être la résultante d’une action utilisateur, ils peuvent venir d’un système extérieur, ou encore le résultat du temps qui passe, ou bien être simplement la conséquence d’un autre évènement.
— C’est le cas de l’évènement “session ended”, fit remarquer Sénior. C’est le résultat de l’évènement “flashcard archived” si cette flashcard était la dernière du deck de révision.
— Tout à fait, répondit PO, essayons maintenant de trouver la cause des autres évènements. Par exemple, le premier évènement “box created” est le résultat d’une action utilisateur de création de boîte. On représente ces actions, ou “commande”, par un post-it bleu, formulé à la forme active :
« J’ai ajouté un petit post-it avec un bonhomme dessus pour indiquer que cette action provient de l’utilisateur. »
— Cela m’a l’air plutôt simple, dit Bizz, je vais compléter avec 2 autres actions utilisateur :
— Quel est l’intérêt de faire ça si ce n’est que pour formuler à la forme active ce que l’on a déjà formulé à la forme passive via les évènements ? demanda Junior.
— Ces actions utilisateurs, à l’image des évènements, ne viennent pas de nulle part, répondit PO. Pour qu’un utilisateur prenne une décision, qui va se traduire par une action de sa part, il a besoin de données sur lesquelles se baser. Par exemple, l’utilisateur peut décider de créer une nouvelle boîte car aucune de celles déjà créées ne lui convient. La liste des boîtes disponibles fait donc office de “données” dont l’utilisateur a besoin pour prendre sa décision. Et c’est ce que l’on appelle un read model. Représenter les actions, ou commandes, permet de mettre en évidence ces read models.
— Et ce sont les fameux post-its verts !
— Perspicace ! fit PO.
Junior se dirigea vers le mur et y plaça donc quelques post-its verts :
— La liste des boîtes fait donc office de read model, comme tu l’as indiqué PO, dit Junior. Sur le même principe j’ai ajouté la liste des flashcards pour une boîte donnée qui va permettre à l’utilisateur de voir si la flashcard qu’il compte ajouter existe déjà ou non. Enfin, comme certaines boîtes peuvent contenir beaucoup de flashcards, j’imagine qu’il serait intéressant pour l’utilisateur d’avoir un aperçu du nombre de flashcards à réviser pour la session qu’il souhaite démarrer.
— Je pense que l’on peut maintenant supprimer l’évènement “answer shown” qui n’en était pas vraiment hein, dit Sénior. Cela ne représente pas un changement de l’état de notre application, ce n’est qu’une donnée que peut visionner l’utilisateur. En revanche, une fois la réponse affichée, il doit pouvoir indiquer s’il avait la réponse correcte ou non. Voici ce que je propose :
— Je ne suis pas d’accord, dit Bizz en pointant les deux post-it verts. Quel est l’intérêt si l’utilisateur voit à la fois la question et la réponse de la flashcard qu’il révise ?
— Il ne verra pas les deux à la fois, répondit Sénior. Probablement qu’un bouton, ou quelque chose du genre dans l’interface lui proposera de regarder la réponse associée à la flashcard. PO a bien insisté pour dire que les évènements correspondent à des changements d’état de notre système. Le fait d’afficher la réponse ne modifie pas l’état, c’est vraiment la responsabilité de l’interface.
Bizz acquiesça d’un léger mouvement de la tête :
— Ok je vois, mais je préférerais qu’on ajoute une note quelque part pour le mentionné, pour que ce soit clair pour tout le monde :
— Très bonne initiative Bizz, fit PO. N’oubliez pas que l’objectif principal de l’EventStorming est de créer une connaissance partagée du projet, de mettre en évidence les points d’interrogation, et d’y apporter des précisions. Ajouter des petites notes à droite à gauche comme cela est donc tout à fait pertinent. Voici où nous sommes donc arrivés :
« Maintenant que nous avons une vision d’ensemble claire du projet, nous allons pouvoir passer à l’étape suivante : l’Example Mapping. »
