Introduzione a EventStorming

Il 20 maggio molti di noi si sono ritrovati a Toolbox Torino per un evento organizzato da Torino Coding Society (che ringraziamo), in cui Jacopo Romei (una nostra vecchia conoscenza…) ha presentato, nel modo meno “frontale” possibile, EventStorming, un formato di workshop. In questa pagina cerchiamo di raccontarvi cosa abbiamo imparato quella sera.

Nato come strumento di analisi per la realizzazione di software, EventStorming può essere usato più in generale per analizzare i processi di business, identificare punti critici, opportunità di miglioramento. In particolare, permette di mettere in relazione tra loro ambiti di business diversi che altrimenti non si parlerebbero e creerebbero un fattore di rischio per il progetto software o per l’intero business.

In quali contesti si usa EventStorming

Dal punto di vista dello sviluppo software, EventStorming nasce come strumento di facilitazione per affrontare lo sviluppo di un’applicazione usando i principi del Domain-Driven Design, il cui obiettivo è identificare e analizzare il dominio del problema da risolvere prima di fare considerazioni implementative.
Per fare questo, è necessario mettere insieme e fare interagire le competenze di stakeholder con diversi background e una delle caratteristiche più importanti di EventStorming è quella di permettere questa interazione, senza richiedere competenze specifiche sul formato ai partecipanti (solo il facilitatore deve conoscerne le “regole”).
Il prodotto di questa progettazione è un “modello”, che costituisce la base (spesso espressa come codice o altri artefatti software – classi, interfacce, se si lavora con OOP) per lo sviluppo dell’applicazione.

Ma l’ambito di applicazione di EventStorming non si limita allo sviluppo di software, si presta anche all’utilizzo per altri scopi, come: analizzare il flusso di business di un’organizzazione per identificare gli impedimenti e capire come produrre valore rilevante; esplorare il mercato in cui si colloca una nuova impresa e pianificarne la crescita/evoluzione; progettare nuovi servizi in modo collaborativo.

Come si fa

Un workshop realizzato in EventStorming inizia creando uno ampio spazio di lavoro costituito da una lunga striscia di carta, a cui verranno attaccati (e spostati) dei post-it. La superficie deve essere abbondante, non basta un singolo foglio perché, andando ad analizzare processi complessi e facendo partecipare quanti più stakeholder possibile, deve essere possibile, almeno inizialmente, mappare un gran numero di event.

Gli event sono infatti il punto di partenza del workshop: una volta definito l’ambito dell’analisi e quindi quale dominio si vuole descrivere e definire, i partecipanti devono pensare e trascrivere su post-it dello stesso colore (arancione) dei singoli event rilevanti, che si posizionano in un’ideale linea temporale e/o logica.
Dopo questa prima fase, inevitabilmente “storming”, il facilitatore può affidare al gruppo o eseguire di persona un walkthrough della narrativa che gli event compongono sulla superficie di modellazione; in questo momento si verifica che gli event siano effettivamente in ordine, si fa “clustering”, ed è auspicabile che emergano degli event “pivot”, cioè dei momenti chiave nella linea temporale, che possono marcare anche confini tra parti più o meno discrete del flusso del processo. Gli event pivot sono marcati usando un pezzo di nastro adesivo verticale che parte appunto dall’event (o da un cluster).

Inoltre, durante il walkthrough, i partecipanti al workshop possono discutere di tutto quello che riguarda gli event presenti sulla superficie: la loro posizione nella timeline, la loro rilevanza, ecc. Questo aiuta a far emergere conoscenze implicite che, se non condivise – soprattutto tra stakeholder con background diversi, possono portare a incomprensioni e quindi a problemi implementativi.
Il riepilogo della narrativa del processo è qualcosa che va eseguito diverse volte durante il workshop, per stimolare commenti e validare collettivamente l’analisi svolta. Le linee narrative possono diventare più d’una mentre la discussione tra i partecipanti si sviluppa.
Il facilitatore non dovrebbe necessariamente guidare verso un completamento del modello: l’obiettivo della completezza potrebbe non aver valore per tutti i partecipanti e in alcuni casi spaventarli o frustrarli quando non fosse raggiunto. L’obiettivo vero è quello di imparare più cose possibili nel minor tempo possibile.

Altri elementi del modello

Sulla superficie del modello trovano posto diversi event e altri elementi

Nell’incontro in cui abbiamo provato EventStorming insieme a Jacopo, abbiamo utilizzato uno dei diversi formati in cui si può articolare il workshop, detto “Big Picture”. In questo formato, l’obiettivo è descrivere un’intera linea di business per averne una visione d’insieme, con l’obiettivo primario di superare le suddivisioni organizzative in “silos”. Questo formato si concentra sull’identificare gli event del dominio e nel sistemarli sulla timeline, tracciando event pivot e discutendo criticità e contesti, risolvendo eventuali ambiguità nel linguaggio usato per descrivere le parti del processo.
Se si opera in un ambito più strettamente di sviluppo software, conviene passare a un modello più articolato, che per ogni event cerca di descrivere i command che lo provocano (azioni degli utenti, interazioni con altri sistemi, il tempo che passa…) e gli aggregate (concetto familiare a chi già pratica DDD).

Mappando un dominio complesso come può essere un’intera linea di business rappresentata in un workshop “Big Picture”, si arriverà a identificare dei bounded context, modelli coerenti al loro interno – anche nell’uso del linguaggio e dei termini, con aree di confine e talvolta di sovrapposizione con altri modelli “confinanti”, con cui si creano aree di conflitto (linguistico/semantico, di competenze, di responsabilità…).

Quando si trova un’area di conflitto o di incertezza, questa deve essere annotata nel modello con un post-it di colore diverso (fucsia). Questo è uno dei motivi per cui bisogna usare una sola grande superficie per il modello: inizialmente, gli esperti provenienti dai loro “silos” creeranno sequenze di event relative o rilevanti per il loro bounded context, ma presto emergeranno i confini tra questi context e le relazioni tra essi obbligheranno ad avviare conversazioni fruttuose.
Nel proseguimento del workshop e della discussione, emergeranno le strutture che costituiscono il modello, gli utenti, i sistemi ed emergerà il consenso su quali siano i problemi principali da risolvere.

In quali contesti si usa EventStorming

Come si fa

Altri elementi del modello

Risorse

Marcello Testi