Construire Ensemble — Chapitre #2 : EventStorming
Découvrir le domaine métier en développant une connaissance partagée du projet
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 1er chapitre : Chapitre #1: Impact Mapping
Junior entra le premier dans la salle pour assister à ce deuxième atelier. Aucune chaise, juste une petite table. Croyant s’être trompé, il rebroussa chemin.
— C’est bien la bonne salle, dit Paul-Olivier qui venait de le rejoindre. Attendons que tout le monde arrive, tu comprendras mieux.
Senior arriva ensuite, suivi de près par Bizz qui ferma la porte derrière lui et pris la parole:
— Bienvenue à tous. Comme je le mentionnais dans le précédent atelier, nous allons développer un projet qui servira de fil rouge à nos différents articles. Je suis l’expert business ici, dans le cerveau, c’est-à-dire que je suis expert en mémoire. Nous allons donc créer une petite application de mémorisation par répétitions espacée. C’est une méthode qui permet d’apprendre plus de choses en les révisant juste avant de les oublier.
— Je ne vois pas bien en quoi ça consiste…, fit Junior, dubitatif.
— C’est tout l’intérêt de cet atelier ! s’exclama PO. Nous sommes réunis dans cette salle pour explorer notre coeur de métier, développer une compréhension partagée du projet dans sa globalité. Mais je t’en prie Bizz, explique nous ce qu’est un système de mémorisation par répétitions espacées.
— C’est très simple. C’est un système mis au point par Leitner dans les années 1970. Concrètement cela consiste en une boîte, séparée en plusieurs compartiments. Dans ces compartiments se trouvent des cartes de révision, avec à leur recto une question et à leur verso la réponse. Toutes les cartes commencent dans la première partition. Lorsque l’on révise une carte, et que l’on en donne la bonne réponse, celle-ci est placée dans la partition suivante. Si la réponse donnée est mauvaise, la carte retourne dans la première partition. On révise les cartes dans la première partition tous les jours, celle de la deuxième partition tous les deux jours, celle de la troisième partition tous les trois jours, etc. On révise ainsi les cartes que l’on connait moins bien plus souvent que celles que l’on mémorise mieux, sans toutefois ne jamais les réviser. C’est le principe de l’apprentissage par répétition espacée, on révise au moment où l’on allait oublier la réponse.
— Dis le si on t’embête PO, s’exclama Senior.
Pendant que Bizz expliquait le fonctionnement du système Leitner, PO s’était dirigé vers un mur pour y déposer un post-it:
— Je sais ce qu’est un système de Leitner, se défendit PO, j’en profite simplement pour commencer notre atelier ! Je viens de poser le premier post-it pour servir d’exemple. Comme vous pouvez le constater, j’ai formulé ces mots à la forme passive, c’est un évènement. L’atelier que nous faisons aujourd’hui est nommé EventStorming, nous allons tenter de découvrir les évènements pouvant survenir pendant l’utilisation de notre application. Ici j’indique donc qu’une flashcard a été ajoutée.
— Une flashcard ? demanda Junior
— C’est le nom que l’on donne à ce type de cartes servant de support de révision, répondit Bizz.
— Jamais entendu ce terme de ma vie, dit Senior.
— Seulement un post-it et nous avançons déjà, se réjouit PO. L’un des objectifs principaux de l’EventStorming est de créer un langage commun, que tous les membres de l’équipe peuvent comprendre. Lorsque tout le monde parle de la même chose pour les mêmes concepts, les quiproquos deviennent plus rare.
— Et tu l’ajoutes dans quoi cette flashcard ? dit Junior. Tu n’as pas oublié des choses avant ? La fameuse boîte dont parlait Bizz tout à l’heure doit avoir été créée avant non ?
— Exactement, répondit PO. J’ai volontairement mis un évènement ne marquant pas le début du workflow. Le but étant que nous complétions ensemble ce qu’il se passe avant, et ce qu’il se passe après. Tu peux donc ajouter l’évènement de création de la boîte sur le mur, avant celui de l’ajout de la flashcard. Nous cherchons pour l’instant à représenter la progression linéaire dans le temps de notre workflow.
Junior s’exécuta:
— Si j’ai bien compris, dit Senior, l’utilisateur est invité chaque jour à démarrer une nouvelle session de révision. On peut donc aussi ajouter cet évènement :
— Lorsque la session de révision commence, un deck spécial est créé en fonction du calendrier de révision, dit Bizz. Ainsi si c’est le premier jour de révision on prendra les cartes dans la partition 1, si c’est le deuxième jour de révision on prendra dans la partition 1 et 2, le troisième dans la partition 1 et 3, etc.
— Pour savoir à quel jour de révision nous sommes, il va falloir aussi déterminer le premier jour, celui qui va servir de date de départ pour la boîte de révision, fit remarquer PO. Devons-nous considérer la date de création de la boîte comme premier jour, ou plutôt utiliser le jour de la première session de révision démarrée par l’utilisateur ? Mettons ces évènements et ces interrogations sur le mur :
« Comme vous pouvez le remarquer :
- les post-its orange représentent les évènements
- les post-its rose foncée permettent de mettre en évidence les interrogations
- les post-it violets indiquent les règles métiers
Lorsque deux évènements peuvent survenir au même moment, on les place l’un en dessous de l’autre.
— La prochaine étape est donc de réviser une flashcard, dit Senior, l’utilisateur va devoir la piocher dans la pile créée pour cette session. Je pense que tout le monde sera d’accord pour dire que c’est la première carte dans la pile qui est piochée :
— Une fois que l’utilisateur a pioché la flashcard à réviser, dit Junior, il doit pouvoir demander à voir la réponse associée, pour ensuite dire s’il avait la bonne ou la mauvaise réponse. Je vois donc 3 nouveaux évènements :
— Les deux derniers évènements sont pertinents, fit remarquer PO. En revanche, l’évènement concernant le fait que la réponse est montrée à l’utilisateur n’est pas vraiment un évènement intéressant pour notre modèle. Il ne représente pas un changement d’état du système. C’est plutôt une information dont a besoin l’utilisateur pour faire son choix de réponse. Je vais ajouter un post-it vert au dessous pour le moment, c’est une notion que nous aborderons un peu plus tard :
— La prochaine étape me paraît être l’incrémentation du score si l’utilisateur a donné une bonne réponse, dit Bizz. Puis le fait que la flashcard est déplacée dans la partition suivante si la réponse est bonne, ou dans la première partition si la réponse est fausse :
— Les deux évènements de déplacement de la flashcard me paraissent redondant, dit Senior. On pourrait n’utiliser qu’un seul post-it. Dans le code, la partition sera probablement représentée par une variable dans l’évènement.
— C’est une bonne remarque, fit PO. Mais ne réfléchissons pas tout de suite en termes de code, il vaut mieux pouvoir représenter les différents évènements explicitement dans un premier temps. Quand bien même à terme il ne pourra en effet s’agir que d’un seul et même évènement.
— Que se passe-t-il si l’on donne la bonne réponse à une flashcard qui est déjà dans la dernière partition ? demanda Junior.
— Elle se trouve archivée, répondit Bizz, c’est que cette flashcard est maintenant mémorisée à long-terme dans le cerveau.
— Ok, donc il nous faut un nouvel évènement, ajouta Junior. Je vais le placer sur le mur :
— Lorsque la dernière flashcard de la session en cours a été révisée, la session se termine, dit Bizz en ajoutant deux post-its sur le mur :
— Nous voilà avec une première version du workflow ! dit PO. Nous avons sous les yeux l’ensemble des changements d’état de notre application. La prochaine étape est de comprendre ce qui déclenche ces changements d’état, bien souvent c’est tout simplement le résultat d’une action de l’utilisateur. Par ailleurs, l’utilisateur a besoin d’information sur lesquelles se baser pour effectuer ces actions. Nous allons voir comment nous pouvons représenter ça. Je vous propose de faire une petite pause, et de continuer avec cette étape juste après !
Lire le Chapitre #3 : EventStorming, toujours plus de post-its
