J’ai présenté certains éléments dans mon précédent article, ici je ferais une liste plus complète afin d’avoir une vision globale et rapide de ce qu’on peut utiliser. On pourra ensuite voir les interactions entre les éléments. Individuellement, chaque ingrédient apporte un type d’information, mais ensemble, ils forment un tout et agissent sur les autres.

Les différents éléments

Domain Event / Événement

Avec les événements, on construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action.

Les événements forment la base de l’Event Storming, tout tourne autour des événements. C’est compréhensible par le métier, par tout le monde. On peut raconter une histoire avec. On aura forcément les événements dans cet atelier, et on commence d’ailleurs par cette étape.

Actor / Acteur

Les acteurs interagissent avec le système, ils déclenchent des commandes. Ils initient une action qui va produire un événement. Ce peut être un utilisateur ou une partie d’un logiciel, un système. On essaie d’être assez précis avec la dénomination de l’acteur, de représenter ce qu’il est vraiment, son nom, son rôle. « Le client », « Le livreur », « Le système Y ». On utilise très souvent les acteurs car on veut visualiser qui fait quoi.

External System / Système Externe

Ce sont les dépendances. On veut visualiser ce qui est à l’extérieur de notre système, ce qu’on ne gère pas. On veut aussi voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint, les goulots d’étranglement. « Le fournisseur », « Service Z ». Tout comme les acteurs, on veut voir qui fait quoi, et cette fois-ci, on a une information supplémentaire - c’est quelque chose d’extérieur.

Command / Commande

La commande est le déclencheur d’un événement, souvent une conséquence d’une action utilisateur, une prise de décision d’un acteur ou d’un système externe. On parle de l’action réalisée qui sera le déclencheur d’un ou plusieurs événements avec un verbe à l’infinitif. « Ajouter au panier ». Il n’y a pas forcément une commande sur chaque événement.

Avec les commandes, on commence à être plus précis sur le processus et on se projette également un peu dans le code.

Policy / Règle

Une Policy permet de rendre explicite une règle métier. C’est la glu qui lie un événement et une commande. Avec une Policy, on représente des commandes qui sont exécutées suite à un événement et selon une condition précise. En général, on décrit une Policy avec Lorsque ... alors ... : « Lorsque le paiement dépasse 500 €, alors il faut envoyer un SMS à l’utilisateur ».

Les Policies peuvent être présentent dans un système, qui gère cette règle lorsque l’événement correspondant se produit. Ce peut également être un humain qui agit lorsqu’un événement se passe. Par exemple, « Lorsqu’une fraude est détectée, alors il faut appeler le client ». C’est un processus humain. Dans ce cas-là, on peut ajouter un post-it acteur sur la Policy pour représenter la personne.

Read Model / Données

Il y a une nuance importante dans le nom anglais, Read Model. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement.

Aggregate / Agrégat

Les agrégats vont apporter une vision bien plus micro et être très proche du code. Pour paraphraser Martin Fowler, un agrégat est un regroupement d’objets du domaine qui peuvent être manipulés comme un seul objet. C’est un pattern qui vient du Domain-Driven Design.

Ce regroupement a du sens pour le métier. On préfèrera manipuler l’agrégat plutôt que chaque objets individuellement - ces objets sont cohérents s’ils sont manipulés ensemble. Dans l’exemple du e-commerce, on peut imaginer un agrégat « Panier » qui contiendrait plusieurs objets « Article » et un objet « Promotion ».

L’intérêt en faisant émerger les agrégats avant de se plonger dans le code va être de visualiser où ils se retrouvent, s’il n’y a pas trop d’événements ou commandes autour d’un même agrégat.

Hot Spot / Point d’attention

Tout au long de l’atelier, on peut marquer les désaccords, les questions, les risques, etc. Ça fait partie du modèle. On peut marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On veut également les visualiser pour mettre en lumière les zones d’ombres, les questions, les problèmes. On agira peut-être là-dessus suite à l’atelier.

Déclencheur temporel

Le temps est parfois aussi un déclencheur d’action. Par exemple, une sauvegarde qui doit être réalisée toutes les heures. On marquera alors simplement « Toutes les heures » sur le post-it. Ce sera le déclencheur d’une commande ou d’un événement visant à créer une sauvegarde.

Bounded Context / Contexte borné

Une fois la modélisation du système bien avancé, dessiner les Bounded Context va permettre de définir les contours des domaines et sous-domaines métiers. En les identifiant, en les explicitant, on veut faire émerger des périmètres métier cohérent, des services, des ensembles de fonctionnalités, des contextes à l’intérieur desquels les objets, les mots, le vocabulaire auront un sens important. On peut aussi visualiser comment ils interagissent entre eux.

Dans une plateforme d’e-commerce, on pourrait imaginer plusieurs contextes : le service client, le service achats, le service livraison. Le terme « client » n’a peut-être pas la même signification au sein des trois services. Peut-être même que le terme est différent, le service livraison pourrait parler de « destinataire ».

Les interactions entre les éléments

Individuellement, tous ces éléments sont simples et apportent un niveau de compréhension différent. L’acteur informe sur qui prends la décision, l’événement indique ce qu’il s’est passé.

Ensemble, ils forment un tout. Ils se complètent, et certains ont une interaction directe entre eux. Quand un acteur agit, il déclenche une commande. Quand une commande est exécutée dans un système, un événement se produit.

Je trouve intéressant de voir comment chaque élément se comporte avec les autres et ce schéma (venant d’Alberto Brandolini, le créateur), le représente bien. C’est intéressant pour la compréhension de l’Event Storming, pour modéliser, et aussi pour concevoir plus tard le logiciel.

Une commande est exécutée. « Ajouter l’article au panier ». Une décision a été prise, il y a une action, quelque chose doit se passer. Cette commande se produit dans un système. Ce peut être le nôtre, auquel cas elle agira sur un agrégat. « On ajoute un Article au Panier, on applique éventuellement une Promotion, on recalcule un prix total ». Ou ce peut être dans un système externe.

Par l’action de cette commande, le système en question génère un événement. « Article ajouté ». Cette fois-ci, ça a eu lieu, l’histoire a évolué. Il s’est passé quelque chose dans le système.

Avec cet événement, un état a changé. On peut projeter de nouvelles données « il y a 5 articles dans le panier, le nouveau prix total est de 343 euros » et les afficher dans une nouvelle interface graphique.

L’événement peut déclencher une règle, une Policy. Le système réagit à cet événement si une condition particulière est rencontrée. « Lorsque le panier contient 5 articles, alors une réduction de 20% est appliquée sur l’article le moins cher ». Une commande est alors exécutée. « Appliquer la promotion ».

Qui d’autre peut être à l’origine d’une commande ? Un acteur. « Le client » a lancé la commande « Ajouter l’article au panier ». C’est lui qui a pris la décision, qui a agi.

Une commande est donc exécutée par un acteur ou par une règle provenant d’un système. Qui produira un événement. Et ainsi de suite. La boucle est bouclée.

C’est un atelier qui peut s’utiliser dans n’importe quel domaine et pas seulement dans le monde du logiciel (même si son créateur, Alberto Brandolini, est un développeur). On pourrait modéliser le fonctionnement d’une équipe de RHs tout comme le parcours d’achat d’une application.

Les événements forment la colonne vertébrale de L’Event Storming. On parle de ce qu’il se passe dans le processus, dans le système, sur une ligne de temps. On peut le raconter, c’est une histoire. Le storytelling est un aspect très puissant de cet atelier.

C’est en plus modulable : on peut ajouter différentes étapes qui feront naître de nouvelles conversations selon le besoin. On pourrait par exemple introduire les acteurs qui agissent sur le système ou les dépendances externes. On peut s’adapter en fonction du niveau d’abstraction que l’on souhaite avoir, d’une vision très macro à une vision très micro sur un bout de logiciel.

Pour autant, l’Event Storming reste simple, ce qui le rend d’autant plus efficace - on va en retirer quelque chose à la fin. Le cadre est léger. C’est très libre, voire parfois chaotique. Et c’est très bien. Ça donne de l’espace aux participants pour faire émerger une compréhension commune.

Quand déclencher un Event Storming ?

Dès lors qu’il y a de l’incompréhension ou un besoin de s’accorder. La force de l’Event Storming est de rassembler de nombreuses personnes et de tout mettre à plat sur un mur. On va rendre l’implicite explicite et harmoniser les modèles mentaux de chacun.

Quelques autres signaux intéressants pour déclencher : on a trop de bugs, on a des zones de floues, on veut s’aligner avec un existant, on veut cartographier de la connaissance.

Plus axé conception logiciel, l’Event Storming aura également son utilité associé au Domain-Driven Design lorsque l’on souhaite découvrir des Bounded Contexts ou des agrégats, ou associé à de l’Event Sourcing pour identifier les événements.

Une animation d’Event Storming

Il y a plusieurs recettes pour animer un Event Storming. Alberto compare l’atelier à une pizza. Il y a une base avec de la tomate et de la mozza (notre ligne de temps avec nos événements). Et ensuite, on y ajoute différents ingrédients au choix (des acteurs, des commandes, des données, des règles, …), sauf quelques exceptions (ni ananas, ni table de base de données :p). Je parle de tous ces éléments et leurs interactions dans cet article.

Selon le besoin, on va donc ajouter des étapes supplémentaires. En général, on veut au moins voir qui fait quoi. On veut identifier les acteurs et les systèmes externes qui nous ajoutent des contraintes, ainsi que les problèmes.

Pour cette introduction, on composera avec les événements ainsi que les commandes, acteurs, données et dépendances. C’est une bonne entrée en la matière que j’ai vu avec Marion Lecerf et Pablo Pernot lors d’un atelier pendant la conférence School of PO ; on obtient rapidement une cartographie intéressante du système.

Libre à vous d’adapter comme vous le souhaitez. On peut ajouter ou supprimer des étapes, en rassembler certaines en une seule étape, être plus macro ou plus micro. C’est très modulable. J’y reviendrais dans un second temps.

Préparation

En amont de l’atelier, on prendra soin d’inviter toutes les personnes qui ont un lien avec ce que l’on veut faire. Si on prend l’exemple d’un logiciel, on pourrait y inviter des développeurs, des POs, des experts du métier, des collaborateurs d’une équipe externe, etc. Toute personne qui peut contribuer est la bienvenue - on veut voir l’image dans son ensemble, on veut éclaircir des zones d’ombre, il faut qu’il y ait tous les acteurs.

Second point, la salle et le matériel. Il faut réserver un grand espace, avec de grands murs. On éloignera le mobilier qui peut gêner, et on mettra à disposition une infinité de stylos et de post-its avec les bonnes couleurs. Prévoir plusieurs mètres de papier craft idéalement pour permettre d’écrire et dessiner directement dessus. Possiblement du scotch ou des ficelles. Ça fonctionne aussi à distance sur un outil comme Miro.

Les événements

Sur une ligne de temps que l’on aura tracé, les participants vont s’atteler à positionner ensemble tous les événements qui composent le processus. On construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. On peut commencer par délimiter le début et la fin en plaçant le premier événement et le dernier événement du processus pour borner.

On utilise des post-its oranges. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action. Les événements doivent être parlant pour les experts métiers et ça tombe bien, ils sont censés être dans la pièce avec nous.

Si on a du conditionnel, on peut faire deux branches. Et si on a trop de branches, on se dit qu’il faut les mettre de côté et faire un atelier dédié afin de se concentrer sur notre branche principale. On veut se concentrer sur notre cas nominal.

On veillera à exprimer tout ce qui vient via des post-its. On veut voir émerger l’ensemble du modèle. On discutera après. Ça peut sembler chaotique mais c’est ce que l’on veut. Lors de l’atelier avec Pablo, il indiquait qu’il poussait au chaos : si ce n’est pas assez bordélique, c’est peut-être qu’il n’y a pas les bonnes personnes ou qu’il y a trop de limites.

On peut marquer les désaccords, les questions, les risques, ça fait partie du modèle. On utilise des post-its roses foncés / rouges pour ces points d’attention (les Hot Spots). Alberto n’hésite pas à marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On peut les positionner en hauteur pour surplomber, ou directement à l’endroit où ça fait sens, au choix.

Cette première étape peut prendre du temps, c’est normal. Les événements forment le cœur du processus. Lorsqu’on arrive à la fin, on demande à une personne de raconter l’histoire qui est modélisée. Le storytelling fait son apparition, les gens aiment écouter des histoires. On en profite pour peaufiner et clarifier le modèle si besoin. Peut-être qu’il manque une précision à un moment. Peut-être qu’il reste une zone de flou.

Les commandes

Dans notre seconde étape, on va positionner les commandes. C’est ce qui déclenche un événement, souvent une conséquence d’une action utilisateur, une prise de décision, ou d’un système externe.

On utilise des post-its bleus. La commande est décrite avec un verbe à l’infinitif. « Ajouter au panier ». Elle est placée devant l’événement sur la ligne de temps.

Les commandes peuvent être utiles pour faire émerger du bordel, surtout sur un système existant, pour aligner les connaissances. On peut trouver que la commande et l’événement sont redondants. Avec la commande, on parle de l’action réalisée par un acteur, qui sera le déclencheur d’un ou plusieurs événements. Il n’y a pas forcément une commande sur chaque événement. Avec les commandes, on se projette également un peu dans le code.

Les acteurs

Troisième étape, on positionne les acteurs. Ce sont eux qui déclenchent les commandes. Ce peut être un utilisateur ou une partie d’un logiciel. On utilise des post-its jaunes et on y marque le nom de l’acteur. « Le client », « Le livreur », « Le système Y ». L’acteur est placé sur la commande, légèrement sur la gauche.

Les données

On arrive à la quatrième étape où l’on positionne les données. En anglais Read Model. Il y a une nuance importante ici. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On utilise des post-its verts. On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement. Le post-it est placé avant l’acteur.

Ne pas hésiter à se faire une session de storytelling pour s’assurer que tout va bien, et qu’on est aligné. On peut faire des sous-groupes. Est-ce qu’on est tous d’accord ? Est-ce clair pour tout le monde ? On peut commencer à préciser. Précis mais pas exhaustif, sinon on n’en fini pas. On met davantage au propre.

Les systèmes externes

Pour notre cinquième étape, on positionnera les systèmes externes. Ce sont les dépendances. On veut voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint. On utilise des post-its rose clair. « Le fournisseur », « Service Z ».

On peut à nouveau reprendre le storytelling et raconter les événements afin de s’assurer que tout est représenté comme dans la vraie vie.

Quelques détails et astuces

Ici comme ailleurs, vous verrez qu’on associe une couleur à chaque élément de l’Event Storming. Respecter ce code couleur a son importance. On veut faciliter la lecture et la compréhension lors de l’atelier, et on veut s’y retrouver facilement si ce n’est pas notre premier Event Storming (on s’enlève la charge mentale de devoir réapprendre un autre code couleur). En voici un rappel :

• Acteur en jaune,
• Agrégat en jaune clair,
• Commande en bleu,
• Données en vert,
• Événement en orange,
• Point d’attention en rose foncé / rouge,
• Règle métier en violet,
• Système externe en rose clair.

On pourrait dire la même chose de la mise en page. Si tout le monde adopte une façon unique de présenter les post-its, on améliore la lisibilité. Une bonne pratique est d’afficher le modèle des différents post-its sur le mur.

Veillez à bien espacer les post-its entre eux pour faciliter l’ajout de nouveaux post-its au fil des étapes. D’ailleurs, un classique quand on joue avec des post-its, écrivez en majuscules, en gros, et soyez concis.

Dernière précision. On peut toujours mettre un événement, un acteur ou tout autre type de post-it même si on est passé à l’étape suivante. C’est toujours le bon moment d’ajouter de l’information.

Avec quoi on repart ?

On obtient de la visibilité. L’ensemble du processus, du système est rendu visible. Il n’y a plus de zones d’ombre - ou s’il y en a, elles sont explicitement révélées. Les problèmes et les questions sont identifiés. On va pouvoir avancer sur ces sujets.

On obtient de la compréhension. On peut avoir des prises de conscience comme “je ne pensais pas que je te créais des problèmes là-bas en faisant ça” ou “je ne savais pas que tu faisais ceci”. Les participants comprennent ce qu’il se passe chez eux et chez les autres, on casse les silos. On va améliorer la collaboration.

On obtient de l’alignement. On s’est mis d’accord tous ensemble sur le modèle, sur les problèmes. Continuons d’avancer ensemble.

La suite est très modulable, tout comme l’est l’atelier. On peut imaginer un tas de choses pour travailler sur le processus :

• Voter pour le problème principal, qui pourrait devenir la priorité numéro une.
• Mettre en lumière les zones à améliorer, et travailler dessus avec le temps.
• Identifier où il peut manquer des compétences.
• Regarder le niveau de qualité dans les zones les plus importantes pour le métier.
• Travailler sur les dépendances et goulots d’étranglement.
• Simplifier le processus.
• Etc.

Pour aller plus loin, Les éléments d’un Event Storming et leurs interactions.

Merci Marion Lecerf et Pablo Pernot pour les divers échanges, et Yannick Grenzinger qui avait initié mon équipe l’année dernière :)