L’approccio event-driven nella modellazione Agile

Lo sviluppo software è un processo di apprendimento. Per capire cosa sviluppare occorre conoscere il dominio che il nostro software dovrà modellare e questa attività è tutt’altro che semplice.

09 feb 2015

Lo sviluppo software è un processo di apprendimento.

 

Per capire cosa sviluppare occorre conoscere il dominio che il nostro software dovrà modellare e questa attività è tutt’altro che semplice. Si perde infatti un sacco di tempo in riunioni per avere più elementi possibili per scrivere l’analisi.

 

Spesso infatti per fare analisi si approccia in maniera “tradizionale”, tipicamente coinvolgendo i cosiddetti esperti di dominio, ovvero le persone individuate dal cliente come quelle che conoscono il processo e possono spiegarlo, in riunioni in cui esporre domande e ricevere risposte. Spesso più che di “persone” si tratta di “persona” al singolare, con tutti i rischi del caso: visione soggettiva e nemmeno esaustiva per mancanza di tempo.

 

Dal canto suo l’analista, disegnando il dominio, rischia di semplificare ulteriormente le esigenze esposte per dare una risposta attraverso gli strumenti che meglio padroneggia e naturalmente il cliente, che non ha il background tecnico sufficiente a valutare correttamente le scelte compiute, non è in grado di fargli notare tutto ciò. Il risultato è così spesso sottostimato sia in termini di struttura che di investimento richiesto. Il sequel è facile da immaginare…

 

Come dare in questi casi una sterzata decisa a questa deriva?

 

Recentemente abbiamo sperimentato una interessante tecnica che si è affacciata nel panorama del Domain Driven Design & CQRS; si tratta dell’Event Storming, ideata dopo anni di sperimentazioni e riflessioni da Alberto Brandolini e presentata per la prima volta all’Italian Agile Day nel novembre 2012, il cui scopo è ottenere in un tempo relativamente breve (poche ore, massimo una giornata intera) una fotografia che costituisca un modello del dominio sotto esame.
Vediamo quali sono le cose importanti da fare:

 

  1. Coinvolgere le persone giuste e chiuderle nella stessa stanza: chi ha le domande e chi ha o dovrebbe avere le risposte. È importante che non sia presente una persona sola, ma più persone (ovviamente se esistono) che siano in grado di illustrare il funzionamento del dominio. L’ideale in ottica DDD è che vi siano persone che permettano di individuare e definire i vari bounded context che costituiscono il dominio.
  2. Gamification: il contesto deve essere stimolante, deve coinvolgere mantenendo un profilo “no stress”, gioco.
  3. Spazio di modellazione illimitato: uscire dal concetto di foglio o lavagna. L’ideale è dare la sensazione che non c’è un limite di spazio ma che esso è potenzialmente infinito (come supporto un bel rotolone di carta da appendere al muro o srotolare a terra è l’ideale.
  4. Uso di nozioni semplici: bando ai tecnicismi. Tutti devono essere in grado di comprendere di cosa si sta parlando e come se ne sta parlando.
  5. Una persona, un pennarello: tutti devono sentirsi coinvolti e liberi di esprimersi.
  6. Rimuovere i potenziali impedimenti: è meglio evitare che le persone possano distrarsi da quello che stanno facendo (banalmente ad esempio impilando le sedie ed evitando che sedendosi possano estraniarsi dal contesto durante l’evento).

 

Preparato il terreno, occorre spiegare alle persone cosa devono fare: consegnati a loro (e a noi) dei post-it di un determinato colore occorre scrivere quelli che ritengono essere gli aspetti chiave del processo che il dominio disegnato deve contemplare (comandi, soggetti, eventi). Lo possono fare liberamente, dove c’è spazio, senza preoccuparsi del fatto che questi eventi debbano avere un ordine.

 

Successivamente occorre consegnare dei post-it di colore differente che possono usare per aggiungere note e pensieri ai post-it attaccati precedentemente da tutti i partecipanti che possono riguardare osservazioni, integrazioni o soluzioni riguardo l’oggetto del post-it considerato.

 

Con ogni probabilità esisteranno dei post-it su cui si saranno accumulate osservazioni, integrazioni o soluzioni che possono anche cozzare fra loro. Occorrerà per questo alle persone di confrontarsi con quanto appeso non in ottica conflittuale (la ragione è mia o tua) ma in maniera collaborativa, cercando di fare sintesi e arrivare ad una dimensione condivisa, perché chi ha una idea diversa su un problema non è un nemico ma un alleato verso lo stesso nemico che è il problema in se.

 

Conclusa questa parte si entra nella fase del “riordinare i pezzi del puzzle”. Occorre dare priorità e capire insieme che posto dare alle cose. Andare in direzioni diverse nell’esplorazione del dominio aiuta ad evitare di trascurare aspetti che anche se a prima vista possono apparire superflui possono successivamente rivelarsi ben più importanti di altri.

 

La nostra esperienza?

 

Sicuramente positiva: chi era presente è riuscito a focalizzare maggiormente dei concetti che non erano passati in maniera chiara non solo tra noi e il cliente ma anche tra gli stakeholder stessi delle rispettive parti.
Ovviamente il risultato finale non può essere considerato esaustivo e certamente occorre altro lavoro di analisi per definire bene il dominio. Una cosa però è certa. In questo modo si inizia a prendere realmente le misure del cliente e della sua realtà in maniera più concreta e con meno pregiudizi che durante un’analisi “classica”, riducendo il rischio di tralasciare aspetti che possono rivelarsi dei veri e propri boomerang.
E’ un dato incontestabile che dando maggiore attenzione al processo decisionale si riducono gli imprevisti. Tutto quanto aiuta a raccogliere informazioni aiuta successivamente a guadagnare tempo e a strutturare con maggiore coscienza quello che serve davvero.

 

Condividere e negoziare è un modo per disegnare una soluzione soprattutto in quei casi in cui è difficile trovare facilmente la chiarezza necessaria per partire col piede giusto.