EventStorming est un atelier Agile de modélisation, qui permet de faire émerger le modèle métier/business d’un projet. Pour cela, cet atelier en groupe doit se dérouler dans une salle, en présence d’un client (product owner). Quelques techniques simples permettent à l’équipe de représenter les flux, les événements et les commandes dans un projet informatique.
Lors de la 1ère conférence NCrafts France le 16 mai dernier, j’ai découvert et testé l’atelier EventStorming. Les idées de cette atelier Agile ont été posées par Alberto Brandolini (@ziobrando). Ce workshop était organisé par 2 personnes du DDD User Group Belge : Jef Claes et Tom Janssen. Dans une salle, avec 25 personnes, nous avons découvert une technique intéressante de modélisation, appelée « EventStorming » (en un seul mot).
D’abord quelques photos, avant de vous en expliquer les principes :
-
- Présentation de l’atelier
-
- Chacun doit avoir un feutre et un bloc jaune
-
- On commence par tous écrire nos idées
-
- On essaye de les classer chronologiquement
-
- Ensuite on refait l’exercice en ne décrivant que des événements
-
- Chaque petit groupe de 5 personnes présente son modele
-
- Enfin on revoit sur un des modèles, on synthétise
-
- Le Product Owner (en bleu de dos) passe à la casserole
-
- Clément explique une idée
-
- Synthèse
Pour vous présenter les idées et les principes d’EventStorming, je me suis permis d’adapter et de traduire en Français l’article d’Alberto. J’y ai ajouté ma propre expérience et ce que nous avons découvert pendant ces 2 heures.
Qu’est-ce qu’un EventStorming ?
L’idée de cet atelier est de permettre d’explorer rapidement, en 2 heures, un domaine métier. C’est très efficace, car de l’aveu de l’ensemble des participants, c’est un excellent outil pour présenter le métier à un nouvel arrivant, ou lors d’une première réunion client. L’outil est aussi très entrainant, les personnes ayant les réponses sont invitées à partager avec ceux qui cherchent à comprendre le métier. Dans l’approche DDD, cet atelier permet aussi d’aller vers une architecture type Event-Sourcing. Par ailleurs, la détermination du Contexte et des Aggregats s’en trouve facilité. L’atelier s’apprécie en ayant aussi je pense une bonne connaissance de la philosophie Domain Driven Design (voir à ce propos mes articles sur DDD de 2010, suite à ma formation avec Eric Evans).
Les principes de l’ateliers sont très simples et s’intègrent dans d’autres pratiques Agiles sans soucis. Pas de modélisation UML derrière son écran, mais plutôt un travail d’équipe, très efficace, qui permet de sortir un modèle complet en s’amusant.
Comment organiser un atelier EventStorming ?
Voici les étapes :
- Inviter les bonnes personnes à la réunion dans une grande salle de réunion. Idéalement 6 à 8 personnes, avec plusieurs clients et donc plusieurs développeurs (mais pas que…). L’idée est de mixer ceux qui ont des questions, et ceux qui ont les réponses, le temps d’un atelier de 2 heures.
- Préparez la salle, recouvrez l’un des murs avec plusieurs feuilles de papier, afin de pouvoir écrire dessus. Préparez aussi un bloc de post-it jaune par participant, ainsi qu’un gros feutre par participant. Chacun prend un post-it en entrant, sauf les clients (ou product owner). Ne tentez pas l’exercice assis, ou sur une table, ou à distance via Skype. Tentez-le physiquement, debout, en ayant collé des feuilles de papier au préalable sur les murs. Prévoyez des post-its qui collent, et de prendre des photos avec vos smartphones. Pas d’ordinateur, et à la limite, chacun met son téléphone portable en mode veille.
- Commencez par demander aux participants de représenter les « Domain Events » du problème à explorer. Tout le monde participe, les clients peuvent répondre aux premières questions. Un Domain Event est un événement passé, avec un sens métier. Par exemple « un speaker a créé une nouvelle proposition de sujet » ou « un membre du CFP a donné une note à un sujet » ou encore « un rappel automatique a été envoyé ce matin ». Placez ensuite ces événements sur une ligne de temps. Ceci vous montrera qu’un événement est peut-être le prédécesseur d’un autre événement. N’utilisez pas de mots techniques comme « un proposal a été sauvé sur la base de données » mais plutôt, uniquement le vocabulaire métier, de vos clients. N’hésitez pas à reprendre les post-its des autres, et à les exprimer à nouveau, jusqu’à ce que l’ensemble des événements soient sur le mur. Cette étape est longue, et il était intéressant pour nous, de ne la faire qu’à 4 ou 5. Afin d’éviter qu’un leader ne prenne trop la parole, chacun est invité à exprimer et poser un post-it, sans que les autres ne portent de jugement, dans un premier temps.
- Explorez ensuite les origines des Domain Events. Certains événements sont les conséquences d’action de vos utilisateurs : ce sont des Commands. Identifiez ces commandes avec un post-it bleu. D’autres actions sont les conséquences de systèmes externes ou du temps qui passe, utilisez alors des post-it rose pour représenter ceux-là. D’autres événements sont liés, dans ce cas regroupez-les ensembles.
- Recherchez ensuite les Aggregates. Un agrégat est une portion de votre système qui reçoit des commandes, et qui décide alors ce qui doit être fait, en émettant de nouveaux Domain Events. Entourez les post-its directement sur la feuille afin de représenter les Aggregats.
- Terminez par rechercher les frontières entre les Aggregats, en explorant aussi sous la forme de sous-domaine, ce qui demandera plus d’attention pour les développeurs.
- Faite une synthèse, prenez des photos, rédigez des tests d’acceptance, bref restez dans l’action 🙂
Pour aller plus loin
Arrivé à ce point, vous devriez déjà avoir un modèle presque complet sur le mur. Pour aller plus loin, voici l’une des techniques que nous avons testé. Prenez un des clients, plus expert sur un sujet, et sur une partie du modèle. Amenez ce client devant le mur. Demandez l’aide d’un autre développeur. Ensuite, pendant 10mn, bombardez de questions le client, et marquez sur les post-its toutes ses réponses. « Est-ce que le speaker peut soumettre un sujet plus tard ? Ah ok, donc il peut sauver le sujet dans un état brouillon. Et s’il oublie de soumettre ? Ok, on va lui envoyer un email… »
Si un conflit ou une discussion s’enlise, essayez de couper l’équipe. Prenez le client et allez soumettre la question à un groupe différent de développeurs. Ceci permettra de faire émerger une solution pilotée par le client. Certaines réponses s’apparentent à des Use-Cases. Pourquoi pas, si cela permet d’identifier les acteurs. Mais la base de l’éxercice est d’abord de représenter des événements.
On parle aussi de la technique User Personas. Il s’agit de décrire un utilisateur, son expertise, ses besoins, ses influences, ses buts, ce qu’il doit faire et ce qu’il ne doit pas faire. Cet exercice venu du monde UX permet aux développeurs de bien comprendre le rôle de chacun. Essayez de jouer cela sur un speaker, un membre du CFP ou un administrateur. Poussez plus loin en décrivant un speaker expérimenté anglophone, un membre du CFP paresseux, un admin étourdi… Cette technique qui date de 93, permet en marketing de décrire la cible visée par une campagne.
La clé de l’atelier : ne pensez pas en Actor, mais simplement en Events. Décrivez les événements qui se produisent sur votre plate-forme.
Conclusion
Le livrable attendu est un modèle complet, représentant sous forme d’Aggregat votre métier. Un Aggregat accepte des commandes (ou non) puis émet des Domain Events.
Pour conclure, je vous encourage à découvrir le blog d’Alberto Brandolini.
