Ci eravamo aggiornati lasciando in sospeso la discussione sul risultato del primo Sprint. 

Ebbene vediamo com’è andata.

Il team ha lavorato molto bene, sviluppando una prima timida sinergia che, anche in relazione alla composizione dello stesso (che vi ricordo era fatta di Persone afferenti a 4 player diversi), di per sé è già un buon risultato che merita dei kudo.

Se veniamo invece alle Technical Story (TS), la situazione si è rilevata un po’ più difficile da comprendere: infatti, se è vero che la maggior parte delle TS sono state completate, è anche vero che è risultato abbastanza difficile rappresentare il valore reale di quanto realizzato. Questo perché le Storie sono subito apparse come “isolate” e, rappresentando tasselli di un flow di esecuzione automatizzato, non è stato possibile valutare nessuna esse in senso atomico e da un punto di vista esplicitamente funzionale.

[Terza Considerazione] Abbiamo quindi appreso una nuova lezione: la review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner (come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato.

Quello invece che è risultato interessante è stata la visualizzazione del data-set ottenuto dall’esecuzione del primo flow parziale realizzato. In pratica si è costruita una semplice vista che, evidenziando di volta in volta il passaggio completato, metteva a confronto lo stato in ingresso con quello in uscita, consentendo al PO di valutare la correttezza del risultato e ponendo le basi per una successiva validazione automatizzata (un RPA dell’RPA J).

A questo punto si è tenuta la prima retrospettiva (classico Strafish) e la problematica primaria affrontata è stata quella di capire come rappresentare in modo più efficace la visione d’insieme e le diverse specializzazioni verticali. In pratica, come riuscire a sfruttare un tool tipo User Story mapping, che però risultava poco efficace rispetto alle più volte sottolineate caratteristiche delle Tecnical Story. La soluzione individuata è stata quella di ricorre ad una rappresentazione grafica del processo, attraverso uno dei più classici strumenti che si conosca: un flow chart.

Questo strumento è stato introdotto nel planning dello Sprint 2, consentendo al team di discutere visivamente del processo e andare a esplicitare i 5 elementi di riferimento di ogni Technical Story: Sottosistemi coinvolti, Dati in ingresso attesi (tipologia e set campione per il test), Dati in uscita attesi (tipologia e set campione per il test), Gate di ingresso e Gate di uscita.

 [Quarta Considerazione] Alcuni strumenti comunemente utilizzati per il mapping delle Storie, vanno opportunamente rivisti, considerando gli aspetti tecnici delle storie. In particolare, l’uso del Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati.

L’FCM ha permesso al nostro speciale PO, Process Owner, di descrivere il sotto-flow atteso per lo sprint, in funzione dei dati di input di start e quelli di output in end. A questo punto il team si è rituffato nello sviluppo!

Nel prossimo post, che chiuderà la serie, vedremo come sono andati gli sprint successivi e faremo una serie di considerazioni finali.

Stay tuned J