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.
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.
