EventStorming

Introduit en 2013 par Alberto Brandolini et hérité du DDD (Domain-Driven Design), l’EventStorming est un atelier de conception logicielle collaborative qui a pour objectifs de casser les silos entre les différents départements d’une organisation, d’aider les acteurs à converger vers une compréhension commune des processus métier, et d’exposer les éventuels incohérences en vue d’identifier des pistes d’amélioration.

L’exercice de description visuelle des processus métier, basé sur la recherche du consensus entre les participants, contribue à nourrir le processus de prise de décision. En permettant d’appréhender tous les éléments d’un système, l’EventStorming aide les acteurs à prendre des décisions, éventuellement structurantes, de façon informée.

L’EventStorming commence généralement par une description orientée par événements métier du domaine concerné, la modélisation des éventuelles interactions que celui-ci entretient avec des systèmes externes, puis l’identification de points de friction et de risques. Ensuite, il s’agit de déterminer plus précisément les actions métier (ou les commandes) qui peuvent déclencher ces événements et les acteurs concernés par la décision associée (personas).

Puis, il s’agit de décrire les policies, qui décrivent la logique métier, à savoir les blocs de traitement déclenchés par une commande et produisant des événements, ainsi que la logique de cause à effet entre les événements mêmes. L’autre objectif important est la découverte et l’apprentissage des concepts ou des objets du domaine et d’une langue commune partagée avec les experts du domaine.

Et enfin, pour concevoir le design de l’interface, l’atelier peut aller jusqu’à l’ébauche des vues (read models) nécessaires pour informer la prise de décision de l’acteur concerné, les vues pouvant être des écrans, ou simplement des documents ou des rapports.

Plusieurs formats d’EventStorming existent en fonction de la finalité recherchée :

• Le Big Picture EventStorming est idéal pour lancer un projet ;
• Le Design Level EventStorming va jusqu’au détail de l’implémentation ;
• Le Value-Driven EventStorming est une façon de cartographier la chaîne de valeur, en utilisant le storytelling d’événements comme base de la réflexion ;
• L’UX-Driven EventStorming se concentre sur le trajet utilisateur avec pour objectif d’offrir une expérience optimale ;
• L’EventStorming comme format de rétrospective utilise la suite des événements comme support de recherche d’opportunités ;
• L’EventStorming comme outil d’apprentissage aide les nouveaux arrivants à comprendre plus finement le système sur lequel ils vont travailler.

Le composition du groupe de participants dépend de la finalité de l’atelier. Par exemple, un Big Picture EventStorming implique généralement un expert du domaine, un représentant de l’équipe de développement et, éventuellement, un architecte, alors que un Design Level EventStorming ne fait pas nécessairement appel à un expert du domaine.

L’EventStorming repose sur un code couleur précis. La représentation du système pouvant rapidement devenir relativement complexe et étendue, il est fortement recommandé de respecter ce code pour veiller à ce que l’artefact reste intelligible :

• Les stickies oranges représentent les événements liés au domaine. Ces événements représentent un changement d’état survenu sur un objet du domaine. Ils doivent être nommés en utilisant le nom d’un objet métier suivi d’un verbe au participe passé.
• Des stickies rectangulaires (ou carrés) jaunes clairs peuvent être utilisés pour identifier les concepts ou objets du domaine ; cela peut aider à mieux visualiser le processus.
• Pour identifier les problèmes et les opportunités le long de la suite d’événements, deux couleurs sont utilisées :
  • Des stickies verts foncés pour indiquer d’éventuelles opportunités ;
  • Des stickies violets foncés pour les éventuels points de friction ou risques identifiés. Les problèmes les plus sensibles, qui doivent être traités en priorité, sont distingués en tournant le sticky à 90°, ce qui forme un losange.
• Les stickies rectangulaires (ou carrés) roses représentent les systèmes externes concernés dans le déclenchement de certains événements.
• Les stickies bleus décrivent les commandes ou simplement les actions par les utilisateurs sur le système. Elles sont généralement accompagnés d’un stickie jaune foncé qui précise le persona concerné par la commande.
• Les stickies verts clairs représentent les vues qui doivent être apportées à l’utilisateur pour l’aider à prendre la décision liée à la commande. Des ébauches de wireframing peuvent y être associées. Une vue peut également être un document ou un rapport produit par le système, plus généralement une présentation de l’état du modèle métier à l’utilisateur ou au système consommateur.
• Les stickies rectangulaires (ou carrés) lilas sont utilisés pour décrire les éventuelles règles (policy) à l’origine de l’occurrence d’un événement ou causées par la consommation d’un événement.

L’artefact attendu est un mur physique ou digital sur lequel sont posés les stickies, organisés par groupes représentant différents enchaînements ou processus.

Étape 1: La première étape de l’atelier consiste à identifier et ordonnancer les différents événements qui composent le système (sticky orange), puis à les trier par ordre chronologique.

Étape 2: Ensuite, il s’agit d’identifier les éventuels problèmes (sticky violet) et opportunités (sticky vert) qui peuvent se présenter à chaque étape du processus. Cette étape est importante, car elle va déterminer sur quelles parties du système vous allez vous concentrer par la suite.

Étape 3: Vous pouvez désormais décrire plus en détail le système en identifiant les personas (sticky jaune), les commandes (sticky bleu) et les systèmes externes (sticky rectangulaire rose).

Étape 4: Il s’agit ensuite de décrire les règles (sticky rectangulaire lilas) qui peuvent conditionner l’occurrence de certains évènements et les informations (sticky vert) qui doivent être apportées aux utilisateurs pour les aider à décider.

Étape 5: Pour faciliter la compréhension du processus, vous pouvez agréger plusieurs événements autour d’un concept du domaine ou concept métier (sticky rectangulaire jaune clair).

Olivier von Dach, expert en Software Craftmanship, possède une grande expérience dans l’animation d’ateliers d’EventStorming. Il partage ici quelques recommandations pour vous aider à mener cet atelier de façon la plus fructueuse possible :

• A distance, utiliser un mur digital pour la coordination d’un EventStorming. Il est préférable de partir d’un template qui contient une légende explicative des différents types de stickies ;
• Accorder une certaine tolérance initiale dans la formulation des événements et des commandes, ce afin d’éviter que les participants soient intimidés lorsqu’ils déposent des stickies ;
• Après la dépose de certains stickies, questionner les participants pour comprendre leurs intentions et éventuellement opérer des corrections.
• Conserver un nommage court des stickies : la typologie explicite de ces derniers, leur disposition, et leur séquencement devant apporter des information sémantiques complémentaires ;
• Organiser le temps de travail par session ayant généralement une durée d’une heure, avec un round initial de découverte, puis ensuite des sessions de travail ;
• Au cours d’une session, toutes les vingt minutes, demander la narration d’un processus métier par un participant.

L’EventStorming est une bonne option pour démarrer un projet. Ensuite, vous pouvez enchainer avec des sessions plus tactiques, par exemple, des sessions d’Example Mapping pour effectuer de la spécification par l’exemple et, notamment, préciser les règles hébergées par les policies.