Brain-Sys ed il suo evento di Event Storming dell’8 Novembre scorso

Di cosa si tratta?
Venerdì 8 Novembre scorso ho vissuto un evento aziendale, interno alla società in cui lavoro, Brain-Sys, davvero molto, molto interessante. Qualche premessa prima di cominciare. Brain-Sys è una società magari-piccola-nei-numeri, ma eccezionale per altri motivi: innanzitutto crede nel telelavoro, perchè permette a ciascun dipendente di lavorare da casa propria. Per questo motivo, fisicamente ci vediamo poco, anche perchè siamo distribuiti geograficamente in posti differenti: chi in zona Lodi come me, chi in zona Pavia come i capi e chi in Valtellina. Abbiamo clienti altrettanto distribuiti geograficamente, con i quali riusciamo a lavorare perfettamente con tutta una serie di strumenti, dal meno tecnologico (telefono) al più tecnologico (Office 365, Lync, Skype, etc.). Personalmente è tre anni che lavoro in questo modo: i clienti che seguo sono piuttosto soddisfatti, io altrettanto, e credo che tutta Brain-Sys tragga vantaggio da tutto questo. Ed io pure.

Tutto questo per dire che l’evento dell’8 Novembre è stata anche un’occasione per ritrovarci tutti quanti, per conoscerci ancora meglio e per conoscere qualche nuovo componente che da poco si è aggiunto alla famiglia Brain-Sys.

Ma è stata anche un’importante occasione per lavorare, chiaramente, e per mettere in pratica una tecnica (metodologia?) di cui avevamo letto io e Gabriele nelle settimane/giorni scorsi. Questa tecnica viene denominata “Event Storming”, ed abbiamo preso spunto dalle sessioni e dai post di un certo Alberto Brandolini, alias @ziobrando su Twitter).

In pratica, ci siamo ritrovati tutti in una location molto raffinata (per la cronaca: Cascina Scova, a Pavia, un hotel 4 stelle con annesso centro benessere) e….Fermi!!! Tutti chi??? Per assurdo che sia, una delle cose che mi ha più colpito è proprio questo “tutti”. Normalmente, infatti, quando si tratta di sviluppare un software, succede più o meno la seguente cosa: un gruppo di persone si riunisce e decide vita, morte e miracoli di questo software. Normalmente, questo “gruppo di persone” include il cliente, un’analista ed un gruppo di commerciali. Rarissima volte il developer viene coinvolto in questa fase: a lui arriva una mazzetta di fogli, o al massimo una mail, con il contenuto riassunto di quella riunione.

Quando si applica Event Storming, invece, quello che accade è che viene organizzata una riunione a cui partecipano tutti quanti gli attori (numericamente, ci si aggira – dice @ziobrando – intorno alle 6-8 persone: l’importante è che siano diversi “punti di vista” attorno allo stesso problema): il cliente (che espone ciò di cui ha bisogno), il developer, un moderatore, l’esperto di dominio, magari un commerciale e così via. Questo è un vantaggio impressionante, di cui secondo me ci si rende conto solo a fine giornata: tutto il team coinvolto ha ragionato sullo stesso problema, ed una volta “educato” anche con la stessa terminologia (ubiquitous language), e ciascuno ha imparato dagli altri qualcosa. Un vero e proprio brainstorming, insomma, una tempesta di cervelli che alla fine i suoi frutti li dà eccome.

Facciamo un passo indietro.
Event Storming è un workshop con una struttura ben precisa.

Ci si ritrova in un certo numero di persone, ci vuole un bel rotolo di carta da appendere alla parete, ci vogliono post-it di diverso colore, penne, matite, scotch, etc. etc. Il cliente espone inizialmente il problema che ha, e che teoricamente il nostro software dovrebbe risolvere. Perchè si chiama Event Storming? E’ semplice: perchè la prima cosa che il team deve fare è pensare agli eventi che accadono all’interno del sistema. Nella vita reale, ciascuno di noi “fa qualcosa” in reazione “a questa cosa che è accaduta”. La stessa cosa deve accadere nel software. Gli eventi devono essere espressi con il “participio passato”, perchè un evento è avvenuto, punto e stop. Un evento non si può annullare, viene persistito, da questo non si scappa. Gli eventi vengono rappresentati da post-it di un colore ben preciso, che vanno attaccati al rotolo di carta sulla parete. E vi posso assicurare che, in base alla composizione del team che avete riunito, i risultati possono essere buoni o cattivi: noi ci siamo trovati alla grande. Nel nostro gruppo c’erano developer junior e senior, c’erano almeno due persone che con la programmazione non c’entravano nulla, eppure hanno partecipato ugualmente con produttività, per esempio. Una volta definiti gli eventi, siamo passati ai comandi, che possono scatenarsi da: un evento utente (click di un bottone, per esempio), dal semplice trascorrere del tempo (se entro le ore XX non è accaduto questo, avviene questo evento), oppure come semplice conseguenza di un altro evento. Ed ovviamente anche i comandi sono stati rappresentati sul foglio di carta con altri post-it, di un colore diverso. Poi gli aggregati, i domini, i bounded context, tutti concetti derivanti da Domain Driven Design (per gli amici DDD). I primi (aggregati) rappresentati ancora da post-it, gli altri da linee di separazione sulla carta, con diversi stili.

Chiaramente, Event Storming non serve e probabilmente non è utile per tutti i progetti. Dà il meglio su progetti complessi, perchè è molto utile per:

1. uniformare il linguaggio (ubiquitous language): alla fine della giornata, tutti noi (il cliente, i developer, il grafico, l’esperto di dominio, chiunque) eravamo allineati sulla terminologia da utilizzare (vocabolario), evitando ambiguità, fraintendimenti, conflitti vari. Fidatevi, per una volta: vi posso assicurare che una semplice parola, a cui voi attribuite un significato chiaro e limpido, per altri può significare una cosa completamente diversa. E’ importante uniformarsi, creare un ubiquitous language che sarà utilizzato nel codice, nella documentazione, sulla UI, in qualsiasi riunione con il cliente
2. team building: la giornata personalmente mi è piaciuta molto, perchè tutti noi abbiamo collaborato strettamente, di persona, per cui alla fine tutto ciò aumenta il feeling con gli altri componenti dell’azienda. Abbiamo scherzato, e lavorato, ci siamo presi in giro ed abbiamo discusso, abbiamo avuto idee che non avremmo mai pensato di avere all’inizio della giornata. Sì: come succede spesso in Brain-Sys abbiamo lavorato divertendoci.
3. chiarezza del progetto: forse, inerente il punto (1). Al di là del linguaggio, tutti noi abbiamo le idee chiare su ciò che dovrà fare il progetto, dalla A alla Z. Sappiamo i confini entro i quali si estende il dominio, abbiamo per certi versi separato le responsabilità, identificato ciascun bounded context

Da quella giornata, siamo tutti tornati a casa molto, molto soddisfatti. Prima di lasciare la location (davvero spettacolare!), abbiamo ovviamente ripulito tutto quanto, ed abbiamo scattato foto al rotolo di carta prima di staccarlo, per avere anche in futuro la nostra modellazione a portata di mano, come documentazione. Pian piano, il progetto sta prendendo vita anche dal punto di vista del codice.

Qualche ringraziamento!!
Beh, l’elenco può essere lungo.

1. Innanzitutto, ai capi: Gabriele Gaggi ed Alessandra Maggi, perchè oltre ad essere i capi, sono amici e persone sempre disponibili, non solo rendendomi partecipe della vita dell’azienda, con i giusti limiti, ma anche dal punto di vista personale
2. A Nazareno Manco, che si è mosso dall’est dell’Italia, per raggiungerci, portando con sè la sua famiglia, la sua simpatia, e la sua competenza durante l’Event Storming. Persona bravissima, in gamba, e competente. Ed anche un amico, soprattutto per il supporto morale di questa estate, che non dimenticherò mai, probabilmente. Ok, scusate l’OT
3. Ad Andrea Barbaini, anche lui si è imbarcato in un lungo viaggio da Roma per essere dei nostri. Non è da tutti!!!
4. Posso ringraziare ancora qualcuno? Ok, grazie. Aggiungo allora l’intero staff di Managed Designs, Andrea Saltarello e Mauro Servienti in primis, che nel corso del tempo mi hanno fatto entrare in testa i concetti di CQRS, Event Sourcing, e soprattutto DDD, metodologie e tecniche che non riguardano solo il mero sviluppo del codice, ma aiutano a pensare meglio, da molto prima di cominciare a scrivere il codice, al progetto software in cui ci si sta imbarcando
5. All’intera famiglia Brain-Sys, cioè a tutti noi, perchè siamo (anche) bravi. E come dicevo alla nostra Chiara durante l’evento “Certo che noi della Brain-Sys siamo proprio belli!”!!!!

Send to Kindle