Come utilizziamo EventStorming per rendere chiari i nostri processi

Come qualsiasi altra azienda, anche noi di Easy LMS abbiamo molti processi. Ad esempio, il modo in cui gestiamo i ticket di assistenza o sviluppiamo nuove funzionalità. Utilizziamo il metodo Improvement Kata per ottimizzare i nostri processi. Uno dei primi passi è quello di specificare la situazione attuale. Tuttavia, si scopre che ognuno ha una propria visione della situazione attuale. L'EventStorming è una tecnica che utilizziamo per definire i nostri processi in modo univoco.

Immaginate di essere un nuovo dipendente che entra in un'azienda. Siete affiancati da un membro del team con maggiore esperienza e passate in rassegna tutti i processi aziendali, per lo più non documentati. Si crea un modello mentale del processo facendo domande e leggendo la documentazione. Più si acquisisce esperienza, meno domande si devono fare e meno documentazione si deve leggere. La maggior parte delle cose si fanno (semi)automaticamente.

Una documentazione meno aggiornata su un processo porterà a una maggiore variazione dei modelli mentali che i dipendenti hanno di quel processo.

Se poi confrontate il vostro modo di gestire il processo con quello di un altro membro del team, noterete che fate alcune cose in modo molto diverso. Questo accade perché i vostri modelli mentali sono diversi.

Quando si ottimizza un processo utilizzando il Kata del miglioramento, descrivere la situazione attuale può essere difficile quando i modelli mentali differiscono in modo significativo. Se solo avessimo un modo per trasformare questi modelli mentali in documentazione.

Come siamo arrivati a EventStorming

All'inizio del 2020 ho partecipato alla conferenza Domain-Driven Design Europ per saperne di più su come modellare meglio il nostro software. Un workshop a cui volevo partecipare riguardava l'EventStorming. Ne avevo già letto e pensavo che potesse aiutarci a far uscire le conoscenze specifiche del dominio dalla testa dei nostri esperti in un modo facile da condividere con gli sviluppatori. In questo modo avremmo potuto costruire un software migliore. Si è scoperto che EventStorming è molto utile per modellare il software, ma anche per modellare i processi aziendali!

Purtroppo la pandemia ha colpito. Abbiamo chiuso il nostro ufficio e abbiamo iniziato a lavorare in remoto. L'EventStorming si basa sulla presenza di un gruppo di esperti in una stanza che lavorano su un'ampia superficie condivisa. Non era più possibile organizzarlo. Fortunatamente anche Alberto Brandolini, il fondatore di EventStorming, se ne è reso conto e ha organizzato un altro workshop per risolvere questo problema: Remote EventStorming. Mi sono iscritto e poi ho aspettato un'occasione per sperimentare EventStorming.

Modellare il nostro processo di sviluppo con EventStorming

Negli ultimi mesi abbiamo cambiato spesso il nostro processo di sviluppo. A volte il processo falliva ed era evidente che nessuno aveva più una visione d'insieme del processo. Il processo candidato perfetto per provare EventStorming!

Dico al team che voglio sperimentare l'EventStorming. Sono sicuro che in questo modo potremo ottenere una buona panoramica dell'attuale processo di sviluppo. Invito un paio di sviluppatori interessati di entrambi i team e creo una lavagna remota condivisa con Miro. Seguiamo i passaggi predefiniti di EventStorming:

1. Esplorazione caotica: create note adesive per tutti gli eventi che vi vengono in mente e che accadono nel processo.

2. Forzate la cronologia: ordinate gli eventi dall'inizio del processo alla fine.

3. Arricchite gli eventi: aggiungete meta-informazioni a ogni evento. Il comando (azione) che lancia l'evento, i dati necessari, il sistema che agisce e la politica che dice cosa fare in seguito.

Esplorazione caotica

All'inizio la situazione è un po' imbarazzante. Ma non appena compaiono le prime note adesive, il ritmo si alza e tutti sono coinvolti.

Iniziamo dando a tutti i partecipanti il proprio pezzo di lavagna e un colore (ma non arancione, come vedremo più avanti). Hanno 25 minuti per creare note adesive per tutti gli eventi che riescono a pensare e che accadono durante il processo. Un evento è qualcosa che è accaduto nel passato e non può più essere cambiato. Per questo motivo si scrive al passato. Ad esempio: "Creazione del repository del codice" o "Distribuzione del codice nell'ambiente di produzione".

Li incoraggio a "barare" e a guardare gli eventi scritti dagli altri partecipanti, perché possono aprire una nuova parte del processo a cui non si era pensato prima. Va benissimo aggiungere eventi che anche gli altri partecipanti hanno.

Applicazione della tempistica

Dopo aver notato che non compaiono nuove note adesive sulla lavagna, passiamo alla fase successiva. Traccio una linea sulla lavagna. Poi chiedo a tutti di scegliere il proprio foglietto adesivo dell'evento che si verifica per primo nel processo di sviluppo e di spostarlo sopra la linea del tempo. Discutiamo brevemente su quale evento sia davvero il primo e lo collochiamo all'inizio della linea del tempo. Per indicare che siamo tutti d'accordo su questo evento e sul suo posto nella timeline, cambiamo il colore della nota adesiva in arancione (ecco perché prima non c'erano note adesive di questo colore). Poi passiamo all'evento successivo.

Si tratta di una discussione più estesa su un evento. Per mantenere il flusso, creo un tipo speciale di nota adesiva chiamata punto caldo. Su di esso descrivo il problema e poi andiamo avanti. Torneremo sui punti caldi più avanti. Ci imbattiamo in un evento creato da più partecipanti. Manteniamo quello che descrive meglio l'evento e rimuoviamo gli altri. Aggiungiamo anche dei rami per gli eventi condizionali. Li posizioniamo sopra o sotto la linea temporale del processo primario.

Dopo due ore e mezza, ci fermiamo. La timeline è terminata e tutti i punti critici sono stati risolti. Tutti sono entusiasti e pianifichiamo immediatamente la prossima riunione per rendere più chiaro il processo arricchendo gli eventi con i metadati.

Arricchire gli eventi con i metadati

Per spiegare meglio questo passaggio è sufficiente un'immagine:

All'inizio del nostro (sotto)processo (nota adesiva nera grande), dobbiamo agire (nota adesiva blu) per dividere il lavoro. Per farlo, abbiamo bisogno di informazioni (nota adesiva verde) sotto forma di storia utente su cui lavoreremo. Jira è il sistema (nota adesiva rosa grande) che utilizziamo per questo. Una volta terminato, abbiamo suddiviso la user story in cosiddette sottoattività. Questo è un evento (nota adesiva arancione). La politica di sviluppo (grande nota adesiva viola) ci indica la nostra azione successiva: mettere una sottoattività in stato di avanzamento in Jira.

Seguiamo la timeline e arricchiamo ogni evento. Se non siamo sicuri di come arricchire un evento con i metadati, creiamo un hotspot e andiamo avanti. In seguito, rivediamo tutti gli hotspot. Alcuni hotspot non possono essere risolti. Ad esempio, quando facciamo una demo della storia, perché dipende dalla pianificazione degli stakeholder. Oppure quando creiamo la documentazione della storia perché non fa ancora parte del nostro processo. Va bene così; stiamo solo descrivendo la situazione attuale del nostro processo. Ma è qualcosa che possiamo migliorare!

Esperimento completato con successo

Tutti sono entusiasti di EventStorming e dei risultati che abbiamo ottenuto.

Ero sicuro che avremmo potuto ottenere una buona panoramica dell'attuale processo di sviluppo facendo un EventStorm. Alla fine, abbiamo effettivamente un quadro chiaro del nostro processo di sviluppo:

Ora è facile spiegare agli altri qual è il nostro attuale processo di sviluppo. Sappiamo anche che ci mancano alcune parti essenziali del nostro processo attuale.

Non vedo l'ora di iniziare a modellare gli altri processi aziendali!