mvp orizzontale  psm1 small  cdap safe sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

Criteri di Accettazione e Definition of Done… una questione di “3 Amigos”

Durante le varie attività di coaching, spesso mi sento chiedere: “chi deve scrivere i Criteri di Accettazione?” oppure: “a Chi spetta il compito di specificare la Definition of Done?”.

Ebbene, la mia riposta è più o meno sempre la stessa: “non si tratta di identificare Chi, ma di Condividere al meglio una responsabilità”.

Soprattutto, bisogna sempre ricordare che i Criteri di Accettazione sono elementi “vivi” che maturano durante la vita del progetto e sono direttamente legati all’evoluzione stessa e alla comprensione della specifica Feature/User Story; il tutto sotto il cappello della Definition of Done.

In quest’ottica, la definizione dei Criteri di Accettazione aiuta a capire più in dettaglio i boundary relativi alla specifica User Story e pone le basi per la realizzazione dei Test di Accettazione. Una loro prima stesura può essere effettuata parallelamente alla scrittura stessa delle User Story o in uno specifico meeting dedicato (es: Story-writing workshop, backlog grooming, ecc).

Fondamentale è che il team collabori alla definizione e al riferimento di tali criteri e, possibilmente, alla definizione dei relativi test. Nella pratica, però, può capitare che il team sia impossibilitato, ad esempio, a rivedere una Feature presente del Product Backlog in modo rapido, soprattutto se è nel mezzo dell’iterazione e la sua attenzione è quindi sull’Iteration Backlog.

Come fare, allora, a supportare il PO nella sua interazione con il cliente? Ebbene, può essere utile sfruttare una tecnica nota come “3 Amigos”, formalizzata probabilmente per la prima volta da George Dinwiddie e molto simile a quanto proposto da Janet Gregory e Lisa Crispin, nel libro Agile Testing, con il nome di “The Power of Three”.

L’idea è quella di organizzare un meeting snello e veloce, nel momento in cui serve, a cui partecipa un temporary team per discutere puntualmente e in modo conciso su uno specifico argomento, in stile Kaizen Blitz. Il temporary team è composto da tre figure, i “tre Amigos” appunto: Product Owner, Developer e QA Tester.

3amigos

3 Amigos

Si pensi alla differenza con il classico planning meeting o al grooming che, tipicamente, avvengono ad inizio e fine iterazione: che succede se l’iterazione è di 3 settimane ed è appena partita? Sicuramente non possiamo aspettare che termini, ma non è neanche opportuno distogliere tutto il team dalle proprie attività, soprattutto se quanto richiesto dal nostro cliente non viene prima calato nel contesto specifico.

Grazie alle diverse competenze dei 3 Amigos, la specifica richiesta del cliente viene discussa da più punti di vista, andando a realizzare una prima formalizzazione delle Feauture relative che cercano di coniugare al meglio le esigenze del cliente con quelle delle attività in corso. Il tutto avviene in chiave Given-When-Then, template tipico dei Criteri di Accettazione:

  • (Given) some context
  • (When) some action is carried out
  • (Then) a particular set of observable consequences should obtain

ottenendo una serie di asserzioni simili alle seguenti:

  • (Dato) il mio conto bancario online e accertato di avere un saldo sufficiente
  • (Quando) provo ad effettuare un bonifico che rientra nelle mie possibilità
  • (Allora) il sistema deve completare l’operazione senza errori

Chiariti i dubbi primari lato business (si spera ;-)), è responsabilità del Team rifinire la User Story e gli stessi Criteri di Accettazione: take it to the team!

La cosa su cui bisogna fare molta attenzione nell’utilizzo di questa pratica è la capacità del Developer e del QA Tester di discutere in funzione del Dominio e del Contesto specifico, al fine di evitare che il meeting si trasformi in un workshop per spiegare tali elementi, vanificandone sostanzialmente lo scopo.