Comment nous utilisons EventStorming pour clarifier nos processus

Comme toute autre entreprise, nous avons de nombreux processus chez Easy LMS. Par exemple, la façon dont nous gérons les tickets d'assistance ou développons de nouvelles fonctionnalités. Nous utilisons le Improvement Kata pour optimiser nos processus. L'une des premières étapes consiste à définir la situation actuelle. Cependant, il s'avère que chacun a son propre point de vue sur la situation actuelle. L'EventStorming est une technique que nous utilisons pour définir nos processus sans ambiguïté.

Imaginez que vous êtes un nouvel employé dans une entreprise. Vous êtes jumelé à un membre de l'équipe plus expérimenté et vous passez en revue tous les processus opérationnels, pour la plupart non documentés. Vous créez un modèle mental du processus en posant des questions et en lisant la documentation. Plus vous gagnez en expérience, moins vous devez poser de questions et moins vous devez lire de documentation. La plupart des choses se font (semi-)automatiquement.

Une documentation moins à jour sur un processus entraînera une plus grande variation dans les modèles mentaux que les employés ont de ce processus.

Ensuite, si vous comparez votre façon de gérer le processus avec celle d'un autre membre de l'équipe, vous remarquerez que vous faites certaines choses très différemment. Cela s'explique par le fait que vos modèles mentaux diffèrent.

Lorsque vous optimisez un processus à l'aide du Kata d'amélioration, il peut être difficile de décrire la situation actuelle lorsque les modèles mentaux diffèrent considérablement. Si seulement nous avions un moyen de transformer ces modèles mentaux en documentation.

Comment nous sommes arrivés à EventStorming

Début 2020, j'ai assisté à la conférence Domain-Driven Design Europ pour en savoir plus sur la modélisation de nos logiciels. L'un des ateliers auxquels je voulais participer portait sur l'EventStorming. J'avais déjà lu des articles à ce sujet et je pensais que cela pourrait nous aider à extraire les connaissances spécifiques à un domaine de la tête de nos experts d'une manière qui soit facile à partager avec les développeurs. Cela signifie que nous pourrions créer de meilleurs logiciels. Il s'est avéré qu'EventStorming est très utile pour modéliser des logiciels, mais aussi des processus d'entreprise !

Malheureusement, la pandémie a frappé. Nous avons fermé nos bureaux et commencé à travailler à distance. EventStorming consiste à réunir un groupe d'experts dans une salle pour travailler sur une grande surface commune. Il n'était plus possible d'organiser cela. Heureusement, Alberto Brandolini, le fondateur d'EventStorming, s'en est également rendu compte et a organisé un autre atelier pour résoudre ce problème : Remote EventStorming. J'y ai participé et j'ai ensuite attendu l'occasion d'expérimenter EventStorming.

Modéliser notre processus de développement avec EventStorming

Au cours des derniers mois, nous avons beaucoup modifié notre processus de développement. Parfois, le processus a échoué et il est devenu évident que personne n'avait plus une vue d'ensemble du processus. Le processus candidat parfait pour essayer EventStorming !

Je dis à l'équipe que je veux expérimenter l'EventStorming. Je suis convaincu que nous pourrons ainsi obtenir une bonne vue d'ensemble du processus de développement actuel. J'invite quelques développeurs intéressés des deux équipes et je crée un tableau blanc partagé à distance à l'aide de Miro. Nous suivons les étapes par défaut d'EventStorming :

1. Exploration chaotique : créez des notes autocollantes pour tous les événements auxquels vous pouvez penser et qui se produisent au cours du processus.

2. Forcer la chronologie : ordonnez les événements du début à la fin du processus.

3. Enrichissement des événements : ajoutez des méta-informations à chaque événement. La commande (action) qui déclenche l'événement, les données nécessaires, le système qui agit et la politique qui indique ce qu'il faut faire ensuite.

Exploration chaotique

Au début, c'est un peu gênant. Mais dès que les premières notes adhésives apparaissent, le rythme s'accélère et tout le monde s'y met.

Nous commençons par donner à tous les participants leur propre morceau de tableau blanc et une couleur (mais pas orange, nous y reviendrons plus tard). Ils disposent de 25 minutes pour créer des notes autocollantes sur tous les événements auxquels ils pensent et qui se produisent au cours du processus. Un événement est quelque chose qui s'est produit dans le passé et qui ne peut plus être modifié. C'est pourquoi vous les écrivez au passé. C'est pourquoi vous les écrivez au passé : "Dépôt de code créé" ou "Code déployé dans l'environnement de production".

Je les encourage à "tricher" et à regarder les événements notés par les autres participants, car cela peut ouvrir une toute nouvelle partie du processus à laquelle vous n'aviez pas pensé auparavant. Il est tout à fait possible d'ajouter des événements que d'autres participants ont également notés.

Mise en œuvre du calendrier

Lorsque je constate qu'aucune nouvelle note autocollante n'apparaît sur le tableau, nous passons à l'étape suivante. Je trace une ligne sur le tableau blanc. Je demande ensuite à chacun de prendre la note autocollante de l'événement qui se produit en premier dans le processus de développement et de la placer au-dessus de la ligne de temps. Nous discutons brièvement de l'événement qui est réellement le premier et nous le plaçons au début de la ligne de temps. Pour signifier que nous sommes tous d'accord sur cet événement et sur sa place sur la ligne de temps, nous changeons la couleur de la note en orange (c'est pourquoi il n'y avait pas de note de cette couleur auparavant ?) Nous passons ensuite à l'événement suivant.

Nous discutons plus longuement d'un événement. Pour maintenir le flux, je crée un type spécial de note autocollante appelé hotspot. J'y décris le problème, puis nous passons à autre chose. Nous reviendrons plus tard sur les points chauds. Nous rencontrons un événement créé par plusieurs participants. Nous conservons celui qui décrit le mieux l'événement et nous supprimons les autres. Nous ajoutons également des branches pour les événements conditionnels. Nous les plaçons au-dessus ou au-dessous de la chronologie du processus principal.

Après deux heures et demie, nous nous arrêtons. La chronologie est terminée et tous les points sensibles sont résolus. Tout le monde est ragaillardi et nous planifions immédiatement la prochaine réunion pour rendre le processus plus clair en enrichissant les événements avec des métadonnées.

Enrichir les événements avec des métadonnées

Pour expliquer cette étape, il est préférable de s'appuyer sur une image :

Au début de notre (sous-)processus (grande note noire), nous devons prendre des mesures (note bleue) pour diviser le travail. Pour ce faire, nous avons besoin d'informations (note autocollante verte) sous la forme de l'histoire de l'utilisateur sur laquelle nous allons travailler. Jira est le système (grande note rose) que nous utilisons à cet effet. Lorsque nous avons terminé, nous avons divisé l'histoire de l'utilisateur en sous-tâches. Il s'agit d'un événement (note autocollante orange). La politique de développement (grande note autocollante violette) nous indique alors notre action suivante : mettre une sous-tâche en progression dans Jira.

Nous suivons la chronologie et enrichissons chaque événement. Si nous ne savons pas comment enrichir un événement avec des métadonnées, nous créons un hotspot et passons à autre chose. Plus tard, nous revoyons tous les hotspots. Certains hotspots ne peuvent pas être corrigés. Par exemple, lorsque nous faisons une démonstration de l'histoire parce que cela dépend de la planification des parties prenantes. Ou lorsque nous créons de la documentation pour l'histoire parce que cela ne fait pas encore partie de notre processus. Ce n'est pas grave ; nous ne faisons que décrire la situation actuelle de notre processus. Mais c'est quelque chose que nous pouvons améliorer !

Expérience terminée avec succès

Tout le monde est enthousiaste à propos d'EventStorming et des résultats que nous avons obtenus.

J'étais persuadé que nous pourrions obtenir une bonne vue d'ensemble du processus de développement actuel en réalisant un EventStorm. En fin de compte, nous avons effectivement une image claire de notre processus de développement :

Il est désormais facile d'expliquer aux autres notre processus de développement actuel. Nous savons également qu'il nous manque des éléments essentiels dans notre processus actuel.

J'ai hâte de commencer à modéliser nos autres processus d'entreprise !