Definizione di Fatto (DoD) è un elenco di requisiti che una storia utente deve rispettare per il team di chiamarlo completo. Mentre i criteri di accettazione di una storia utente consistono in una serie di scenari di test che devono essere soddisfatti per confermare che il software funziona come previsto.
La differenza tra questi due è che il DoD è comune per tutte le Storie utente mentre i criteri di accettazione sono applicabili a Storie utente specifiche., I criteri di accettazione di ogni Storia utente saranno diversi in base ai requisiti di quella Storia utente.
In altre parole, sia i criteri DoD che quelli di accettazione devono essere soddisfatti per completare la storia dell’utente. L’incremento del prodotto non è considerato completo, a meno che non vengano eseguiti entrambi questi due elenchi., Quindi, abbiamo bisogno di definire due aspetti della Definizione di Fatto (DOD) — Criteri di Completamento e Criteri di Accettazione:
La definizione di Fatto è strutturato come un elenco di elementi, ognuno utilizzato per convalidare una Storia o PBI, che esiste per assicurare che il Team di Sviluppo d’accordo sulla qualità del lavoro che stanno tentando di produrre., Serve come una lista di controllo che viene utilizzato per controllare ogni elemento Product Backlog (aka PBI) o Storia utente per completezza. Gli elementi nella definizione di “Fatto” sono destinati ad essere applicabili a tutti gli elementi nel Product Backlog, non solo a una singola storia utente.,il termine implica che l’incremento di prodotto è che può essere spedito
Gli obiettivi di Definizione di Fatto
- Costruire una comune comprensione all’interno di un Team di circa la Qualità e la Completezza
- Utilizzare una lista di controllo che l’Utente Storie (o PBIs) sono controllati contro
- Assicurarsi che l’incremento spedito alla fine di Sprint è di alta qualità e che la qualità è ben compreso da tutti i soggetti coinvolti.,
Ad esempio, nel settore del software, i team potrebbero dover porre alcune delle seguenti domande per elaborare il loro DoD:
- Codice peer reviewed?
- Codice completato?
- Codice rivisto?
- Codice registrato?
- Test unitari superato?
- Test funzionali superati?
- Test di accettazione completati?
- Proprietario del prodotto esaminato e accettato?,
Criteri di accettazione
Le storie utente sono uno degli artefatti di sviluppo primari per lo sviluppo Agile, ma Scrum non richiede esplicitamente l’uso di Storie utente o Criteri di accettazione., Se un elemento di backlog di prodotto è considerato troppo grande per essere messo in uno sprint, normalmente suddivise in user story e, successivamente, in una serie di attività, come mostrato in Figura:
le Storie Utente incapsulare i Criteri di Accettazione, così vediamo spesso la definizione di fatto e dei criteri di accettazione co-esistenti nel nostro mischia processo di sviluppo. La storia utente fornisce il contesto della funzionalità che il team deve fornire., I criteri di accettazione forniscono indicazioni sui dettagli di tali funzionalità e su come il cliente li accetterà. I due di loro insieme forniscono l’intero deliverable.
Alcuni dei criteri di accettazione verranno scoperti negli eventi di perfezionamento del backlog in corso prima dell’inizio dello Sprint, e altri verranno scoperti subito dopo la pianificazione dello Sprint quando ci si siede per avere una conversazione sulla storia dell’utente in un piccolo team. Pertanto, i criteri di accettazione sono attributi unici per la storia utente o l’elemento di backlog del prodotto.,e i Criteri sono diversi per ogni PBI/Storia
Gli obiettivi di Criteri di Accettazione
- Chiarire che la squadra deve costruire prima di iniziare a lavorare
- Assicurarsi che ognuno di noi ha una comprensione comune del problema
- Aiutare i membri del team sanno quando la Storia è completa
- verificare la Storia attraverso test automatizzati.,
Esempio — Criteri di Accettazione
- Un utente non può inviare un modulo senza completare tutti i campi obbligatori
- Informazioni dal modulo viene memorizzato nei registri del database
- Pagamento può essere effettuato tramite carta di credito
- Un avviso e-mail viene inviata all’utente, dopo aver compilato il modulo
Esempio di User Story con Criteri di Accettazione
La figura sottostante mostra un esempio di criteri di accettazione di una user story.,
