Nous animons des EventsStorming chez nos clients depuis quelques temps déjà et, à DDD Europe 2020, nous (Anthony et Colin) avons pu participer à un atelier de 2h avec Alberto Brandolini (créateur de l'atelier).
Le but était de modéliser un Domain que nous avons tous découvert pendant la session : un expert du domain était présent et il a présenté pour la première fois à tout le monde (Alberto compris) le métier qui devait être modélisé.
Comment nous animions cet atelier avant de le faire avec Alberto
Pour cet atelier nous avons habituellement ces pré-requis :
- Un sujet à traiter, cela peut être un système complet ou un point particulier ;
- Au moins 2h de réelle disponibilité pour tous les participants ;
- Un facilitateur qui assurera le bon déroulement de l’atelier et la participation bienveillante de tout le monde ;
- Une petite dizaine de participants travaillant sur le domain avec des experts du domain et des développeurs. Cet atelier fonctionne éminemment mieux si tous les participants sont dans la même pièce ;
- Un mur virtuellement infini ;
- Une salle dont on enlève les chaises : les participants doivent rester debout ;
- Un rouleau de papier et du scotch pour recouvrir et protéger votre mur ;
- Des posts-its de différentes couleurs, à minima : orange, bleu, jaune, rose fluo et rose clair (selon le déroulement et le but recherché vous pouvez avoir besoin d’autres couleurs) ;
- Des stylos / feutres fins pour tous les participants.
Une fois ces éléments rassemblés, le mur protégé et le tuto sur le décollage de post-its fait, on distribue des posts-its oranges à tous les participants. Sur ces posts-its on va chercher à identifier les événements, ils sont :
- Au passé : ce sont des choses qui se sont passées ;
- Simple : pas de description complexe ;
- Partagés : tous les participants doivent être d’accord sur les termes ;
- Compréhensible par tous : pas de termes techniques ici, on note les événements métier.
À ce moment les experts du Domain vont commencer à nous raconter l'histoire du traitement que l'on cherche à modéliser. Tout le monde peut couper à tout moment pour demander ou apporter des précisions mais surtout pour noter les événements qui sont en train d’être mis en lumière.
Pendant 20 minutes chacun va donc proposer et noter des événements que l’on va placer au mur sur des post-its orange dans l’ordre chronologique (de gauche à droite).
Les photos sont tirées d’une vidéo live que nous avons faite d’un EventStorming. Cela explique la piètre qualité et les mauvais cadrages (pour trouver les rares moments où personne n’est devant les post-its)...
Une fois ces 20 minutes passées prenez 5 minutes de pause pour expliquer l’utilité des post-its roses : noter les questions en suspens. L’idée n’est pas de chercher une réponse si on ne peut l’avoir tout de suite (manque d’information, manque de connaissance, …) mais simplement de noter que ce point est en suspens.
Dans certains cas vous aurez eu besoin de présenter les post-its roses avant cette pause. Ne laissez pas les gens chercher des solutions s'il est évident qu’elles ne peuvent pas apparaître en session !
Profitez aussi de ces 5 minutes pour prendre un peu de recul, recentrer tout le monde et fusionner les doublons si de petits groupes se sont naturellement formés.
Reprenez ensuite pour une nouvelle session de 20 minutes à trouver des événements (et des questions).
À ce stade deux options :
- Il est évident qu’il vous manque des événements : vous pouvez repartir pour une session de découverte d'événements ;
- Les événements semblent être clairement trouvés : vous pouvez alors présenter trois nouvelles couleurs de post-it :
- Bleu : Ce sont les commandes, des actions qui permettent le déclenchement d’un événement. Ce sont des verbes à l’infinitif ;
- Jaune (pouvant être coupés en deux) : Ce sont les acteurs qui déclenchent les commandes ;
- Rose clair : Ce sont les systèmes externes qui déclenchent les événements (messages, temps, …) ;
Les déclencheurs doivent être positionnés à gauche des événements qu’ils déclenchent (si un événement en déclenche un autre on garde donc l’affichage temporel). Les acteurs sont ajoutés en bas à gauche des commandes :
Il est fréquent de vouloir mettre des commandes à la place des événements dans les premières boucles. La grande idée de cet atelier est justement de commencer par ce qui se passe réellement sur le système : il faut être très vigilant et ne pas faire apparaître les commandes trop tôt.
Si vous avez vos événements vous pouvez alors partir pour 20 minutes de découverte de déclencheurs de vos événements.
Selon le but recherché par cet atelier vous pouvez vous arrêter là, vous avez déjà :
- Une bien meilleure compréhension du métier pour toutes les personnes présentes ;
- Un Ubiquitous Language ;
- Un processus modélisé (et dont la timeline est clairement représentée) ;
- Une vision des principales actions et événements qui doivent être codés.
Vous pouvez cependant faire le choix d’aller plus loin dans cet atelier pour faire apparaître les Aggregates sur des posts-its jaunes. Pour cette étape vous allez devoir détruire la notion de temps pour regrouper vos déclencheurs et événements devant être manipulés ensemble.
Le but ici est de rechercher des transactions métier : ensembles d’éléments qui, pour le métier, ont une cohérence uniquement s'ils sont manipulés ensemble. Ces regroupements doivent être les plus petits possible (pour permettre une vérification des règles métier).
Lorsque ce point est compris vous pouvez rechercher ces Aggregates pendant une petite dizaine de minutes (cette étape est plus rapide que les précédentes).
L’étape suivante est l’identification des Bounded Contexts : on va regrouper les Aggregates dans les plus petits ensembles possibles répondant à un métier donné. Pour cette étape on va déplacer de nouveaux les post-its pour pouvoir dessiner les Bounded Contexts au feutre sur le papier.
On va différencier deux types de Bounded Contexts :
- On va tracer en pointillé ceux qui sont essentiels mais qui ne font pas directement la valeur ou la plus value de notre solution ;
- On va tracer en trait plein celui qui, d’un commun accord, est le coeur de notre domain.
Tous les participants ont maintenant une bonne vision d’ensemble de beaucoup d’éléments de design que nous avons déjà évoqués (et même de certains qui n’ont pas encore été présentés).
Cet atelier peut être utilisé pour modéliser tout un système ou un sous ensemble de celui-ci, c’est à vous de voir. Dans tous les cas ne faites pas de session de plus de 2h, préférez plusieurs ateliers de 2h si le sujet est trop volumineux pour être traité en une fois.
Comme pour tous les ateliers prenez le temps de prendre un retour d’expérience de tous les participants.
Ce qui change dans la manière de faire d'Alberto
Lors de l’atelier que nous avons pu suivre avec Alberto, un expert métier (Brian) nous a présenté son besoin et pour nous montrer comment le modéliser, seul Alberto faisait l'analyse sous la forme d’un EventStorming.
La première chose qui frappe est l'animation de l'atelier : Alberto impose un rythme très soutenu, il est très dynamique et on sent clairement que c'est volontaire !
Avant de commencer l'atelier il nous explique la règle principale : au vu du nombre de personnes dans l'audience nous n'avons pas le droit d'intervenir oralement. Si nous avons une idée ou quelque chose qui ne nous convient pas nous devons prendre un post-it rose et simplement le placer sur le mur.
Le métier se situe dans le domaine bancaire et la première idée est de trouver le scénario le plus simple pour arriver au but de l’application à modéliser.
Pour trouver ce scénario minimal, Alberto a identifié plusieurs cas possibles :
- Un échange entre particuliers ;
- Un échange avec un vendeur ;
- Des échanges differents selons les règles en vigueur dans d’autres pays.
Dans notre cas, l’idée est de représenter l’échange entre particuliers, c’est-à-dire tout ce qu’il se passe entre l’activation d’un compte et une somme monétaire reçue par une seconde personne.
Pour se faire, il a positionné le premier événement avec un post-it orange à gauche du support papier sur le mur pour indiquer le compte du particulier activé.
Immédiatement après, il s'est concentré sur le dernier événement pour représenter le but à atteindre, c’est-à-dire le paiement reçu par l’autre particulier. Il a pris du temps pour identifier ce point : savoir quelles sont les bornes de l'atelier est vraiment un point essentiel au bon déroulement.
Alberto prend sur lui l’ensemble des post-its dont il a besoin, il n’hésite pas à mettre des questions à l’aide des roses lorsqu’il veut indiquer un élément à creuser plus tard. En fait dès que quelque chose sort du scénario nominal qu'il à choisi d'étudier pour rendre un premier service il note un post-it rose (il y en a rapidement beaucoup).
Très vite, il sort les petits post-its jaune, ceux qui représentent les acteurs, non seulement pour les représenter mais aussi pour indiquer la satisfaction à l’aide d’un :) ainsi que la valeur business à l’aide d’un $.
Cette représentation que nous ne faisions pas dans notre atelier permet d’indiquer là où la solution a de la valeur pour l’entreprise et de la distinguer de celle qui a de la valeur pour l’utilisateur.
Contrairement à un atelier de découverte, Alberto positionne directement les vues via ses post-its verts, les commandes via les post-its bleus et les agrégats via les post-its larges jaunes sans représenter l'exhaustivité des autres événements avant.
Pour revenir sur la notion des vues, elles représentent les données visibles par un utilisateur mais aussi les données qui permettent de prendre des décisions en amont d’une commande ou d’une policy (notion que nous allons aborder plus tard). Elles constituent ainsi ce qu’il appelle le Read model.
En discutant avec Alberto suite à l’atelier, nous pensons qu’il est plus pertinent de partir sur une approche plus classique, c’est-à-dire représenter d’abord les événements, plutôt que de tout représenter au fil de l’eau parce que ça nécessite d’avoir déjà pratiqué de nombreux EventStorming. Lui-même conseille, lors d’une découverte du métier, de ne pas aller trop loin pour représenter le métier.
En parallèle, durant l’atelier, il n’hésite pas à nous rappeler le but de l’atelier et suite à des remarques dans l'assistance, il introduit trois rôles :
- The driller (celui qui va creuser le sujet) :
- Les + : Il va aider à représenter l’exhaustivité du modèle ;
- Les - : Il n’a pas de vision permettant d’aller vite à un résultat (qui est le but de l'atelier). Ce rôle peut ouvrir beaucoup d’embranchements n’apportant pas forcément beaucoup de valeur.
- The pragmatic :
- Les + : Il tranche rapidement et s'assure que l'atelier va vers sa cible ;
- Les - : Il peut oublier de prendre en compte des détails importants pour le métier.
- The empathic :
- Les + : Il comprend les besoins des utilisateurs finaux et peut apporter des simplifications nécessaires notamment dans les vues (ou faire ajouter des vues). Il peut aussi insister sur un cas qui doit être creusé et non pas noter comme un point en suspens ;
- Les - : Il peut ne pas avoir assez de recul pour être capable de s’arrêter sur un détail.
Pour Alberto, pour un EventStroming réussi, ces trois rôles doivent s'équilibrer : The pragmatic doit éviter que the driller consume tout le temps de l'atelier à creuser des détails de détails. The empathic doit quand à lui s'assurer que les besoins des utilisateurs sont au centre de l'analyse (et qu'on ne se concentre pas uniquement sur des problématiques techniques comme peut avoir tendance à le faire the pragmatic).
Suite à cet aparté, Alberto reprend et introduit la notion de Policy (sur des post-it lilas), qui permet de représenter des décisions et ainsi mettre en lumière des règles métier.
Depuis son introduction à EventStorming, Alberto indique que cette notion apparaît lorsqu’une réaction commence par le mot "lorsque" ou "à chaque fois". Il donne ainsi deux exemples avec "whenever the exposure passes the given threshold, we need to notify the risk manager" et "whenever a user logs in from an new device, we send him an SMS warning".
En l’interrogeant à ce sujet pour savoir pourquoi Alberto introduit cette notion dans ses ateliers, il nous a expliqué que c’est suite à un retour de Greg Young qui lui a demandé explicitement de parler de cette notion qu’il n’introduisait pas ou rarement dans ses ateliers jusqu’à présent.
L’avantage de cette notion permet selon lui de détailler ce qui est changeant dans le métier de ce qui ne change pas ou peu. Avec le recul, il remarquait que les agrégats n’étaient pas assez complets et ne parlaient pas assez aux experts métiers alors que les policies semblent avoir plus de sens pour eux.
C’est sans doute l’outil des EventStorming que nous connaissions le moins ! Cet ajout change grandement la forme du l'atelier.
Avec ces notions voici l'ordre suivi pendant l'atelier :
Après une grosse demi-heure de modélisation il s'est passé un événement important : nous avons atteint un point ou un changement de context semblait évident. Alberto a alors marqué clairement ce changement avec de l'adhésif jaune. Même si nous ne modélisons pas directement la solution dans cet atelier il est très possible que ces deux parties finissent par être dans des Bounded Contexts différents.
Après un peu plus d’une heure, Alberto a su représenter le domaine métier décrit par Brian dans une vision très simple.
Souvent il y a de la frustration avec les produits minimum viables (MVP) lorsqu’on travaille avec un client puisque, pour le réaliser, il faut parfois passer plusieurs mois. Faire cet atelier en se concentrant sur un cas d'utilisation aboutissant au rendu d'un premier service permet d'avoir une première version fonctionnelle en production.
Pendant le temps restant, Alberto a modélisé des scénarios laissés en suspens sur des post-it roses en cherchant toujours à avoir un utilisateur satisfait.
Pour terminer voici une partie de notre Domain final (avec Alberto répondant un point soulevé par l’audience qu’il pourra par la suite représenter sur le mur) :
Ce qu'on va changer dans nos futurs EventStorming
Comme nous l'avons déjà dit nous allons probablement garder l'ordre que l'on utilise actuellement qui est plus simple pour des analystes qui ne sont pas Alberto.
Nous allons cependant nous essayer aux Policies et aux Read Models mais nous allons surtout changer le rythme "imposé" par le facilitateur tout en se concentrant beaucoup plus sur un seul cas d'utilisation (avec beaucoup plus de post-its roses).
Même si nous ne savons pas encore de quelle manière, il est certain que ces deux heures avec le créateur de l'atelier vont changer notre manière de l'utiliser. Peut-être écrirons-nous un article dans quelque temps expliquant tout ça.
