In questi casi, l’approccio migliore è allineare come queste definizioni devono essere create, nel caso in cui debbano essere create, con gli stakeholder che hanno maggiore influenza e impatto sul progetto. Lascio qui un altro articolo che ho scritto su questo tema chiamato “Come usare la Stakeholder Matrix per aumentare la tua influenza e migliorare la comunicazione del progetto.”

Se sei già un leader con sufficiente influenza e autonomia, condividerò prima i concetti del SAFe e poi spiegherò come li uso nella pratica. Questo è anche il tipo di problema che Saint Jude aiuta i leader a osservare con maggiore chiarezza: task che entrano nella board senza sufficiente chiarezza, stime che non corrispondono alla realtà e rischi creati da una cattiva definizione delle attività.

Definizione di ready e definizione di done nel SAFe

Shift learning left

Lo sviluppo di prodotti include molti scenari sconosciuti che il team scoprirà man mano che il progetto avanza, e lo stesso vale per le singole task. Più tardi questi scenari vengono scoperti, più difficile e costoso diventa correggerli, con impatti su scope, qualità, schedule e costi. Per questo motivo, avere un processo per verificare e validare possibili scenari in anticipo diventa essenziale per il buon andamento di un progetto.

Pair programming e peer review

Questa è una pratica preziosa e molto conosciuta, ma ancora poco utilizzata in modo consistente dai team di tecnologia. Due professionisti lavorano insieme sulla stessa task: uno si concentra sulla costruzione della soluzione, mentre l’altro agisce come navigatore, offrendo feedback e suggerendo miglioramenti in tempo reale. L’idea è portare più di una prospettiva su come la task dovrebbe essere costruita, aumentando non solo la conoscenza del prodotto, ma anche la comprensione del team su come il prodotto funziona internamente.

Collective ownership e competenze T-shaped

Qui, il SAFe ci dice che ogni persona all’interno del team dovrebbe avere le competenze e l’autorità sufficienti per modificare una consegna, indipendentemente dal momento del processo in cui essa si trova. Nessun professionista è proprietario della consegna o del prodotto. Un altro punto importante di questo concetto è avere professionisti che, pur essendo specialisti in un tipo di lavoro, comprendano anche il progetto nel suo insieme.

Standard degli artefatti e definizione di done

Le consegne spesso dipendono da processi manuali per spostare le task tra professionisti dello stesso team, il che può generare ritardi. All’interno di questi processi di costruzione del prodotto, c’è anche perdita di tempo nell’ispezionare le task o nel cercare componenti già esistenti che potrebbero essere riutilizzati per accelerare la consegna o migliorare la performance. Automatizzare questi processi aiuta a ridurre tempi e costi, aumentare la produttività e migliorare gli standard di consegna.

Automazione del workflow

I workflow spesso includono passaggi manuali di task tra professionisti dello stesso team, creando ritardi e riducendo l’efficienza del flusso. Durante questi processi di costruzione, i team possono anche perdere tempo ispezionando manualmente le task o cercando componenti già creati che potrebbero essere riutilizzati per accelerare la consegna o migliorare la performance.

Automatizzare questi processi aiuta a ridurre tempi e costi, aumentare la produttività e migliorare gli standard di consegna. Nella pratica, questo è molto connesso a ciò che Saint Jude cerca di rendere visibile: dove le task stanno aspettando, dove il workflow è inefficiente e come un lavoro poco chiaro può impattare schedule, costi e performance di delivery.

Questi concetti fanno parte di ciò che il SAFe considera built-in quality. Come avrai notato, la Definizione di Ready (DoR) e la Definizione di Done (DoD) non sono idee isolate. Fanno parte di qualcosa di più grande: la qualità.

Ora vediamo come uso questi concetti per creare una migliore Definizione di Ready e Definizione di Done nei progetti che gestisco.

Definizione di ready/done e qualità nella pratica

Per creare chiarezza e migliorare la documentazione, uso un tripode formato da PO, UI e tech leader per costruire la Definizione di Ready di qualsiasi task, usando la seguente struttura:

• UI documenta il flusso atteso e i flussi alternativi
• PO documenta ciò che è atteso come consegna di business
• Tech leader documenta come deve essere costruita

Perché? Onestamente, non ho mai visto un progetto in cui tutti i membri del team avessero le competenze e l’autorità per prendere ogni decisione. Per questo motivo, diventa necessario creare una leadership tecnica e di business tra le parti interessate per guidare e validare le task. Sulla base dell’esperienza che ho acquisito, avere qualcuno che guidi tecnicamente il team è necessario fino a quando il team stesso diventa autosufficiente.

Per la Definizione di Done, uso questi professionisti anche per validare e concludere formalmente la consegna. Detto questo, ora spiegherò questo punto con maggiori dettagli usando i concetti del SAFe.

Shift learning left

In questo caso, con la documentazione iniziale fornita dal mio tripode di professionisti, il team di sviluppo può iniziare a costruire la task attraverso i test, usando il famoso approccio TDD, mentre il team di QA può già lavorare sugli scenari di test usando BDD. Posso anche portare qui un concetto del mondo agile: se il team non capisce cosa deve essere fatto durante gli eventi di refinement, la task non è pronta per entrare nello sprint. Da questo punto, restituiamo la task al tripode con tutte le domande sollevate dal team e raffiniamo la documentazione fino a quando la task è cristallina per tutti.

Pair programming e peer review

Mi piace molto il pair programming, ma porterò una verità scomoda che quasi nessuno ha il coraggio di dire:

“Se metti due persone a lavorare su una task invece di due persone che lavorano su due task diverse, o hai una notevole influenza dentro la tua azienda, oppure il tuo capo potrebbe non esserne felice.”

La verità è che quasi nessuno vuole sacrificare tempo a favore della qualità. Detto questo, un’azione che applico sempre con i miei team è fare in modo che il mio tripode — PO, UI e tech leader — serva come un gruppo di oracoli durante il processo di costruzione. Non importa quanto tempo dedichiamo a documentare ciò che deve essere fatto, le domande possono ancora emergere nel mezzo del lavoro. Più rapidamente rispondiamo a queste domande, più rapidamente avanziamo. In generale, chiedo a questo tripode di riservare un’ora al giorno per rispondere ai dubbi. Funziona quasi come una daily, ma con più tempo per spiegazioni complesse.

Collective ownership e competenze T-shaped

Qui di nuovo, mi affido al mio tripode di professionisti come persone responsabili di qualsiasi modifica alle task. Ma perché?

All’inizio di un progetto, o anche quando entrano nuovi professionisti, la loro conoscenza ed esperienza sono generalmente pari a zero o molto basse rispetto alle regole di business, a ciò che deve essere fatto e a ciò che ci si aspetta dalle consegne. Per questo motivo, dipendono dalla conoscenza delle persone che hanno più tempo sul progetto o più esperienza, come PO, tech leader e UI. Queste sono le persone che hanno le chiavi per entrare e modificare qualsiasi processo o consegna. Con il tempo, il team acquisisce fiducia e diventa capace di intervenire in qualsiasi fase del processo.

Tuttavia, esiste un punto specifico qui: gli esseri umani si affezionano naturalmente all’autorità che hanno conquistato. Se rimuovi improvvisamente l’autorità precedentemente conquistata da qualcuno, puoi creare problemi comportamentali, a volte arrivando persino a dimissioni o licenziamenti. D’altra parte, quando questi professionisti andranno in vacanza, avrai già un team formato e capace di modificare le consegne quando necessario.

Infine, sulle competenze T-shaped: usando la regola di Pareto, direi che nell’80% dei casi questo semplicemente non accade. Primo, perché serve molto tempo per acquisire una conoscenza ampia, e i progetti non sempre durano abbastanza. Secondo, perché è difficile trovare professionisti interessati a imparare un po’ di ogni nuovo tema coinvolto nella costruzione di un prodotto.

Standard degli artefatti e definizione di done

Ora entreremo un po’ di più nella Definizione di Done, ma prima inizierò dagli standard. Ogni professionista ha i propri pattern di lavoro e, quando questi pattern vengono documentati, diventano gli standard del progetto. Farò un’eccezione per gli standard che arrivano dall’esterno, come standard aziendali o del PMO. In ogni caso, gli standard esistono e influenzano il modo in cui il lavoro viene consegnato.

Per quanto riguarda la Definizione di Done, ho menzionato prima che uno dei punti principali è la validazione e l’accettazione formale da parte del mio tripode. Oltre a questo, uso casi di test e automazione dei test unitari come parte della Definizione di Done. Il motivo principale è creare una barriera di sicurezza ed evitare problemi in produzione. Se i test falliscono, il prodotto non è pronto per i miei clienti.

Automazione del workflow

Per portare più agilità al processo di finalizzazione delle task, dal momento in cui iniziano fino alla loro conclusione, l’approccio migliore è bilanciare ciò che deve essere fatto con il numero di persone disponibili per farlo. Se devi scegliere, è meglio avere persone in attesa di task piuttosto che task in attesa di persone. Alla fine, vogliamo consegnare un prodotto rapidamente e con alta qualità, non è vero?

Per quanto riguarda l’ispezione delle task, quando i casi di test e i test unitari sono automatizzati, l’ispezione manuale diventa meno necessaria. Infine, la ricerca di componenti può essere descritta nella documentazione iniziale della task. Se non lo è, uno dei nostri oracoli dovrebbe essere in grado di rispondere. È anche qui che strumenti come Saint Jude possono creare curiosità nei leader: quando chiarezza della task, stime, flusso, schedule e costi vengono analizzati insieme, diventa più facile capire se il team è davvero produttivo o semplicemente occupato.

Arrivo alla fine di questo articolo. Qui hai imparato alcuni concetti del SAFe sulla qualità e come li uso per creare Definizioni di Ready e Done efficienti per i miei progetti.

Vuoi continuare questa conversazione? Metti like all’articolo, commenta su LinkedIn o condividilo sui tuoi social media.

A presto!

Erik Scaranello