By Courtney
22 settembre 2010 (Ultimo aggiornamento 17 aprile 2019)
Tags:Agile
I criteri di accettazione definiscono cosa deve essere fatto per completare una storia utente agile. Specificano i confini della storia e vengono utilizzati per confermare quando funziona come previsto. Ecco una guida introduttiva alla scrittura e all’utilizzo dei criteri di accettazione.,
Checklist dei criteri di accettazione
Scopri le 13 caratteristiche dei criteri di accettazione efficaci
Assicurati che i tuoi criteri di accettazione forniscano preziose storie utente e un prodotto di valore.
La scorsa settimana ho descritto le ossa della storia utente nel primo post della nostra serie introduttiva sulle storie degli utenti. In breve, una storia utente è una descrizione di un obiettivo che una persona dovrebbe essere in grado di raggiungere quando si utilizza il tuo sito web/applicazione/software. Queste storie sono spesso scritte in questo formato: Come voglio in modo che .,
Ad esempio: Come membro di Flickr voglio essere in grado di assegnare diversi livelli di privacy alle mie foto in modo da poter controllare con chi condivido le foto.
Questo post aggiunge un po ‘ di carne all’idea di storie degli utenti, sotto forma di criteri di accettazione.
Dove sono i dettagli?
A prima vista, può sembrare che le storie degli utenti non forniscano informazioni sufficienti per far passare un team da un’idea a un prodotto. Ecco dove entrano in gioco i criteri di accettazione. Ma prima, ecco alcuni retroscena., Nel 2001, Ron Jeffries ha scritto circa le Tre C della user story:
- Carta – storie sono tradizionalmente scritti su notecard, e queste carte possono essere annotate con dettagli aggiuntivi
- Conversazione – dettagli dietro la storia attraverso le conversazioni con il Proprietario del Prodotto
- Conferma – prove di accettazione confermare la storia è finita e perfettamente funzionante.
In un progetto che segue un processo Agile, il team di sviluppo discute le storie degli utenti negli incontri con il Product Owner., (Il proprietario del prodotto è la persona che rappresenta il cliente per la cosa che stai sviluppando e che scrive le storie degli utenti). In primo luogo il proprietario del prodotto presenta la storia utente, quindi inizia la conversazione.
Ad esempio: come partecipante alla conferenza, voglio essere in grado di registrarmi online, in modo da poter registrarmi rapidamente e ridurre le pratiche burocratiche.
In questo caso, le domande per il proprietario del prodotto potrebbero includere:
- Quali informazioni devono essere raccolte per consentire a un utente di registrarsi?
- Dove devono essere raccolte/consegnate queste informazioni?,
- L’utente può pagare online come parte del processo di registrazione?
- All’utente deve essere inviato un riconoscimento?
Catturi i problemi e le idee sollevate in questa sessione di domande e risposte nei criteri di accettazione della storia.
Criteri di accettazione di esempio
I criteri di accettazione definiscono i limiti di una storia utente e vengono utilizzati per confermare quando una storia è completata e funziona come previsto.
Quindi per l’esempio precedente, i criteri di accettazione potrebbero includere:
- Un utente non può inviare un modulo senza compilare tutti i campi obbligatori.,
- Le informazioni del modulo vengono memorizzate nel database delle registrazioni.
- La protezione contro lo spam funziona.
- Gli utenti possono pagare con carta di credito.
- Una e-mail di conferma viene inviata all’utente dopo aver inviato il modulo.
Quindi, come puoi vedere, scrivi i criteri di accettazione in un linguaggio semplice, proprio come la storia dell’utente. Quando il team di sviluppo ha finito di lavorare sulla storia utente dimostrano la funzionalità al proprietario del prodotto. Mentre fanno questo mostrano come hanno soddisfatto ciascuno dei criteri.,
Ottieni altri esempi di criteri di accettazione
Per ulteriori esempi, puoi scaricare i nostri esempi di user story in PDF.
Criteri di accettazione e definizione di done
A volte le persone non sono sicure della differenza tra i criteri di accettazione e la definizione di done. La differenza fondamentale è che la definizione di done si applica a tutto il tuo lavoro, mentre i criteri di accettazione sono specifici per le singole storie.
Scopri di più sulla differenza tra la definizione di done e i criteri di accettazione.,
Vantaggi dell’utilizzo dei criteri di accettazione
Includere i criteri di accettazione come parte delle storie degli utenti ha diversi vantaggi. Essi:
- ottenere il team di pensare attraverso come una caratteristica o parte di funzionalità funzionerà dal punto di vista dell’utente
- rimuovere l’ambiguità dai requisiti
- formare i test che confermeranno che una caratteristica o parte di funzionalità funziona e completa.,
Introduzione alla user stories — blog serie
- guida per Principianti a storie utente
- Aggiunta di criteri di accettazione per le storie utente
- storie Utente e il processo di sviluppo
- Utilizzare casi vs storie utente
- coinvolgimento delle parti interessate attraverso le storie utente
- Creazione di storie utente con la storia di mapping
- Miglioramento della user story con una definizione di pronto
- User story esempi
bibliografia
io ti consiglio questo post di Sabbia Mamoli., (Sandy è un Wellington Agile coach e scrum master, con cui lavoriamo su Digital New Zealand). Dopo di che, come si potrebbe dare un’occhiata a questa presentazione sulle storie degli utenti efficaci da Mike Cohn. Se stai lavorando in Scrum, questo post mostra come aggiungere criteri di accettazione quando crei storie utente in Scrum.
Avvio di un nuovo progetto? Dai un’occhiata al nostro Agile kit di avvio del progetto per conoscere la mappatura delle storie degli utenti e dare priorità alle storie degli utenti durante la scoperta del progetto.
Lascia un commento