Introduzione ad Agile

Quando ci siamo incontrati per un aperitivo/agile-coffee in agosto, stimolati da alcune persone che partecipavano per la prima volta alle nostre iniziative, abbiamo cercato – anche un po’ giocando – un modo condiviso per definire cosa sia Agile. Esperimento riuscito solo in parte, però ci ha suggerito di continuare a lavorarci sopra, ed è quello che abbiamo fatto preparando e realizzando il meetup di settembre, dedicato proprio a descrivere e a vivere con il nostro tipico atteggiamento pratico cosa significhi lavorare in modo Agile.

Il meetup è stato gentilmente ospitato nello spazioso auditorium di TAG – Fondazione Agnelli in via Giacosa e ha visto la partecipazione di circa 25 persone, quasi tutte alla loro prima esperienza con noi e con alle spalle un primo approccio alle pratiche agili.

Alma Maria del Campo Vara ha preparato un ricco ed equilibrato menu suddiviso tra un’introduzione storica-teorica e un momento di laboratorio in cui il gioco e la pratica hanno portato alla luce le differenze tra un approccio classico o “waterfall” e un approccio iterativo. C’erano carta, pennarelli, colla, forbici, gli immancabili post-it… buona parte dell’equipaggiamento che ci si aspetterebbe in occasioni del genere. Ma c’era soprattutto una grande curiosità da parte di tutte le persone presenti, con un piccolo aiuto da parte dei partecipanti già “navigati” del meetup, che si sono prestati a impersonare ruoli di supporto ai 4 gruppi di lavoro: una volta stakeholder, pochi minuti dopo facilitatori di mini-retrospettive.
In questa pagina potete vedere alcune foto scattate durante il meetup, a testimonianza del clima attento e collaborativo che si respirava nell’auditorium del TAG.

Tornando indietro al momento in cui abbiamo avuto l’idea di questo incontro, un’ipotesi che abbiamo condiviso è di rendere questo tipo di iniziative episodi ricorrenti nella vita del nostro meetup, utili per facilitare l’ingresso nel mondo agile di chi lo conosce da poco o per niente, ma anche un’occasione per chi ha più esperienza per fermarsi un momento a riflettere e saper trovare sempre migliori parole per descrivere cosa sia Agile.

Ecco le slide usate per la presentazione. 

Non abbiamo ancora deciso quale cadenza avranno in futuro gli incontri introduttivi come questo, ma continuate a seguirci sulla piattaforma meetup per ricevere notizie sulle nostre prossime iniziative. 

Marcello Testi

More Posts

L'articolo Introduzione ad Agile – estate 2019 proviene da Agile Community Torino.

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.

Risorse

• https://www.eventstorming.com/resources/
• http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html
• https://www.slideshare.net/ziobrando/50000-orange-stickies-later
• https://martinfowler.com/tags/domain%20driven%20design.html

Marcello Testi

More Posts

L'articolo Introduzione a EventStorming proviene da Agile Community Torino.