In questi casi, meglio allinearsi come devono essere fatte queste definizioni (o se si devono essere fatte) con gli stakeholder di maggiore potere/impatto. Lascio qui una cronaca che ho scritto su: “Gli stakeholder – migliorando il tuo potere e impatto.”

Caso tu sia un leader che abbia il potere e autonomia necessaria, condividerò prima i concetti del SAFe e poi, come io uso questi concetti.

Definition of ready / definition of done (SAFe)

Shift learning left – test di sistema prima possibile

Lo sviluppo di qualche prodotto include molti scenari sconosciuti che il team scoprirà mentre avanziamo con il progetto e, questo vale pure per le sue attività. Il più pardi troviamo questi nuovi scenari, peggio è sistemarli. Con impatto nello scopo, qualità tempo e i costi. Creare processi che fanno verificazioni e validano scenari possibili si diventa cruciale per il buono avanzamento di un progetto.

Pair programming e revisione di professionisti pari

Questa è una pratica comune e poco usata dai team di tecnologia. Due professionisti lavorano insieme nella stessa attività, dove uno di loro fa la costruzione e l’altro serve come navigatore, dando feedback e promuovendo un miglioramento in tempo reale. L’idea qui è avere più di una prospettiva su come l’attività sarà migliore costruita e portando maggiore conoscenza ai professionisti non soltanto al prodotto ma su come funziona internamente.

Collective ownership e T-skills

Qui il SAFe ci dice che tutte le persone del team devono avere tutte le competenze necessarie e autorità sufficiente per fare un cambiamento nell’attività, indipendente del momento in cui siamo nel processo. Il concetto è semplice: nessuno è il capo della consegna o prodotto e, un altro punto su questo concetto è avere professionisti nel team che, essendo specialisti in u tipo di lavoro, hanno conoscenza di tutto il progetto.

Le norme di consegna e definition of done (DoD)

Le consegne devono inseguire una padronanza già stipulata dall’azienda e devono riflettere quello che è stato richiesto. I team che le svilupperanno devono capire perché la richiesta è stata aperta. Definition of done qui c’entra come un processo di garanzia sulla richiesta, garantendo che l’attività è stata costruita d'accordo con quello che è stato richiesto prima.

Workflow automation

I flussi tendono ad avere processi manuali di passaggio tra professionisti di uno stesso team, generando ritardi. Dentro della costruzione di un prodotto c’è anche la perdita di tempo nell’ispezione delle attività e anche perdita alla ricerca di componenti già creati che possono essere usati per accelerare e/o migliorare la performance di una consegna. L’automazione di questi processi aiuta a diminuire il tempo e i costi, generando incrementi di produttività e migliore standard.

Queste sono state in parte le definizioni che il SAFe ci dà su come possiamo migliorare la qualità. Come avrai percepito, le definition of ready (DoR) e definition of done (DoD) c’entrano come un sott concetto dentro il concetto della qualità. Adiamo adesso a come io uso questi concetti per ottenere una migliore definition of ready e done nei progetti che faccio parte.

Definition of ready e done - qualità nella pratica

Come modo per chiarire e documentare utilizzo il treppiede: PO, UI e tech leader per costruire le definizioni ready a ogni attività, così:

• UI documenta il flusso aspettato e i flussi paralleli
• PO documenta cos’è aspettato come consegna dall’area di business
• Tech leader documenta come dev’essere costruita l’attività

Perché? Onestamente non ho mai visto un progetto dove tutti i professionisti abbiano le competenze e autorità necessarie per prendere tutte le decisioni. Si diventa necessario creare leader tecnici nelle aree coinvolte per organizzare e validare le attività. Dentro della conoscenza che ho acquisito, avere una persona per guidare il team tecnicamente è bisogno fino a che il team sia auto sostenibile, per dire.

Nel caso delle definition of done, utilizzo questi stessi professionisti per validare e finire la consegna di un’attività. Detto questo, c’entro un può di più sui dettagli usando i processi dello stesso SAFe.

Shift learning left – test di sistema prima possibile

Qui, con una documentazione venuta dal mio treppiede di professionisti, il team di sviluppo può cominciare a fare la costruzione di attività dai test (famoso TDD) e il team di QA può andare avanti sugli scenari di test (BDD). Posso anche usare un concetto del mondo agile: se non c’è una comprensione del team rispetto a quello che deve essere fatto nell’evento di raffinatezza, l’attività non è pronta per andare allo sprint. Da questo punto, ritorniamo con l’attività al mio treppiede e i dubbi per dettagliare meglio la documentazione, fino che sia chiara per tutti.

Pair programming e revisione di professionisti pari

Adoro pair programminig, ma alzerò una verità scomoda che nessuno ha il coraggio di dire nelle aziende:

“Se metti due professionisti per fare un’attività invece di due professionisti per fare due attività, o hai un considerabile potere dentro dell’azienda o tuo capo si diventerà arrabbiato con te.”

La verità è che quasi nessuno vuole sacrificare tempo per avere un’ottima qualità (tranne i giapponesi). Detto questo, una delle mie azioni che impongo sempre è fare del mio treppiede: PO, UI e tech leader come oracoli durante la costruzione. Comunque abbiamo documentato il possibile di quello che dobbiamo fare, possono succedere dubbi nel mezzo del processo. Il più veloce gli rispondiamo, più veloce avanziamo.

In generale chiedo al mio treppiede da rimanere un’ora tutti i giorni per rispondere i dubbi. Sarebbe come un daily, però con un può di tempo per spiegazioni complesse.

Collective ownership e T-skills

Di nuovo, ricado sul mio treppiede come responsabili di qualche cambiamento dell’attività, ma perché?

Nell’inizio del progetto o nei primi contatti dei nuovi professionisti con esso, la conoscenza ed esperienza sono zero o troppi bassi relativo alle regole di business, cosa deve essere fatto e qual'è l'aspettativa sulle consegne. Per questo motivo, si appoggiano nella conoscenza di persone con più tempo ed esperienza, come il PO, tech leader e UI. Sono queste persone che hanno le chiavi per modificare qualche processo o consegna. Dopo qualche tempo, il team guadagna confidenza ed è già pronto a intervenire in qualsiasi fase del processo.

Però qui c’è un punto molto specifico: esseri umani sono vanitosi per la sua propria natura. Se tu rimuovi l’autorità conquistata previamente da un professionista, avrai dei problemi comportamentali, finendo in dimissioni. Diciamo che, quando questi professionisti usciranno nelle ferie, tu avrai un team già preparato per modificare le consegne se necessario.

E alla fine, la questione dei T-skills... usando la regola di Pareto io direi che nell’80% dei casi questo non succede. Prima perché si dimora molto tempo per avere questa conoscenza e progetti non durano così tanto, poi perché è troppo difficile trovare professionisti interessati a sapere un può di ogni cosa coinvolta nella costruzione di un prodotto.

Le norme di consegna e definition of done (DoD)

C’entriamo qui un può alle definition of done. Però prima comincio dallo standard. Tutti i professionisti hanno uno schema di lavoro e quando questi schemi sono stampati sulle sue documentazioni, essi si diventano lo schema del progetto. Apro un’eccezione nel caso delle documentazioni venute da fuori (per esempio una padronanza per tutta l’azienda oppure venute dal PMO). Diciamo che la padronanza succede

Relativo alle definition of done, ho commentato prima che uno dei punti è la validazione e accettazione formale dal mio treppiede. Aggiungo qui l’automazione dei casi di test e degli unity test come definizione di done perché gli uso come una barriera di sicurezza da evitare qualche problema in produzione. Se non passano i test, non è pronto per i miei clienti.

Workflow automation

Per una maggiore agilità nel processo di sviluppo delle attività, da quando sono create fino a quando sono finite, ci vuole un equilibrio tra quello che deve essere fatto VS Quante persone ce l’ho per farlo. Nel caso tu debba scegliere, scegli lasciare le persone in attesa dell’attività che le attività in attesa dalle persone. Alla fine, vogliamo consegnare un prodotto di una forma veloce e con qualità, vero?

Relativo alle ispezioni delle attività, con una buona automazione usando i casi di test e unity test, non si sono più necessarie. Per ultimo, la ricerca dei componenti verrà scritta sulla documentazione iniziale dell’attività e, caso non sia, verrà risposta da uno dei nostri oracoli.

Arrivo alla fine di questa cronaca. Qui hai imparato alcuni concetti del SAFe sulla qualità e come io gli uso per creare definition of ready e definition of done, di una forma efficace per i tuoi progetti.

Vuoi continuare questa chiacchiera? Ha qualche contrappunto che vorresti presentare? Metti un like sulla cronaca, commenti sul LinkedIn o condividi sulle tue reti sociali.

A presto!

Erik Scaranello