Come scrivere criteri di accettazione: esempi e best Practice

Qui a Mobindustry, operiamo con un approccio Agile. Ciò significa che utilizziamo componenti agili come le storie degli utenti e i criteri di accettazione. I team e le organizzazioni ad alte prestazioni hanno questi componenti nei loro product backlog e sanno come crearli e utilizzarli in modo efficace.

Se il tuo backlog di prodotto manca di storie utente e criteri di accettazione, o se non sono chiaramente definiti, rischi di non convergere con la realtà., Le storie degli utenti e i criteri di accettazione sono responsabili della rappresentazione di come l’utente finale utilizzerà la tua app e di come il tuo team di sviluppo dovrebbe eseguire ogni attività di sviluppo. Quando iniziamo a lavorare su un nuovo prodotto, il nostro team collabora con il cliente per definire le storie degli utenti.

Una storia utente è una breve, semplice descrizione di una funzione di prodotto dal punto di vista di una persona che vuole utilizzare tale funzione. Le storie degli utenti vengono utilizzate per definire il product backlog in un flusso di lavoro di sviluppo agile.,

Il product backlog è essenzialmente una raccolta di storie utente che informa le specifiche funzionali e lo sviluppo di funzionalità per un particolare prodotto o servizio. Le storie degli utenti sono composte da tre parti: una persona dell’utente per cui viene scritta la storia, una descrizione della funzione richiesta dall’utente e una spiegazione della necessità che la funzione soddisfa.

Ecco come scrivere una storia utente:

Come (utente) voglio una (funzione) in modo da poter (soddisfare un bisogno).

Diamo un’occhiata a come potrebbe apparire una storia utente., Prenderemo Airbnb come esempio. Immaginiamo come una tipica storia utente potrebbe cercare un prodotto come Airbnb.

“Come utente, voglio cercare una destinazione in modo da poter prenotare un alloggio in una città straniera.”

Definizione dei criteri di accettazione

Ora, dobbiamo assicurarci che le storie degli utenti siano completate correttamente e soddisfino le richieste del cliente.

I criteri di accettazione sono le condizioni che un prodotto software deve soddisfare per essere accettato da un utente, cliente o, nel caso di funzionalità a livello di sistema, il sistema che consuma.,

I criteri di accettazione sono un insieme di istruzioni, ognuna con un chiaro risultato pass / fail, che può essere misurato e specificare requisiti funzionali e non funzionali.

La scrittura di criteri di accettazione è importante non solo per stabilire ciò che il cliente si aspetta dal prodotto, ma per il processo di sviluppo. Naturalmente, persone diverse vedono lo stesso problema da diverse angolazioni. Criteri di accettazione ben definiti forniscono una visione uniforme della funzionalità che si intende implementare.,

Chiunque dovrebbe essere in grado di camminare fino a uno Scrum board, afferrare un elemento product backlog, leggere i criteri di accettazione e vedere chiaramente tutto ciò che deve essere completato per quel particolare elemento da spostare nella colonna done. I criteri di accettazione ti dicono cosa deve essere fatto per una particolare parte di un prodotto da finire.

Perché abbiamo bisogno di criteri di accettazione?,

• Definizione dei confini. I criteri di accettazione aiutano il team di sviluppo a definire i confini di una storia utente. Servono come forma di conferma che l’app funziona come previsto, il che significa che la storia dell’utente è completa.
• Raggiungere il consenso. I criteri di accettazione consentono al team di sviluppo di essere sulla stessa pagina del cliente. Informano il team di sviluppo su quali condizioni devono essere soddisfatte e assicurano che il cliente sappia cosa aspettarsi dall’applicazione.
• Ottimizzazione dei test di accettazione., I criteri di accettazione sono alla base del test di accettazione della storia dell’utente. Ogni criterio di accettazione dovrebbe essere testato in modo indipendente e avere scenari chiari per il successo o il fallimento.
• Pianificazione e stima. I criteri di accettazione consentono di distribuire le storie degli utenti tra le attività in modo che vengano valutate e pianificate correttamente.
• Che descrive scenari negativi. I criteri di accettazione possono richiedere al sistema di identificare una password debole e impedire ad un utente di continuare, ad esempio., L’inserimento di un formato di password errato è un esempio di uno scenario negativo in cui un utente inserisce dati errati o si comporta in modo imprevisto. I criteri di accettazione identificano questi scenari e spiegano come il sistema dovrebbe rispondere ad essi.

Chi scrive i criteri di accettazione?,

La scrittura di criteri di accettazione aiuta a stabilire una comprensione comune tra il proprietario del prodotto e il team di sviluppo per quanto riguarda la risoluzione del problema di un cliente o la creazione di funzionalità di prodotto. Poiché i criteri di accettazione si riferiscono al cliente e al team, dovrebbero essere scritti dal cliente o da un membro del team.

In Mobindustry, i nostri analisti aziendali scrivono tutti i criteri di accettazione per le storie degli utenti. Gli analisti aziendali comprendono le esigenze del cliente e ciò che gli sviluppatori devono sapere per soddisfare i requisiti del progetto.,

I criteri di accettazione sono documentati e confermati prima dell’inizio del progetto, poiché il team e il cliente devono concordare quali risultati soddisferanno i requisiti del cliente.

Esempi di storie utente con criteri di accettazione

Ora che hai una chiara comprensione di quali sono le storie utente e i criteri di accettazione, diamo un’occhiata ad alcuni esempi.,

Esempio 1

User story: Come utente, voglio essere in grado di registrarmi nel servizio in modo da poter iniziare a fare acquisti online.

Criteri di accettazione:

• L’utente può inviare un modulo solo compilando tutti i campi obbligatori.
• L’e-mail fornita dall’utente non deve essere fornita da un servizio di posta elettronica gratuito.
• Gli invii dallo stesso IP possono essere effettuati solo tre volte entro 30 minuti.
• Gli utenti ricevono e-mail di notifica dopo la registrazione con successo.,

Esempio 2

User story: Come utente, sono in grado di accedere a una notifica sul mio dispositivo immediatamente dopo averla ricevuta.

Criteri di accettazione:

• Scorrere / toccare una notifica porta l’utente direttamente al messaggio.
• Visualizza conversazione-se il nuovo messaggio era una risposta, viene visualizzato sopra l’originale.
• Il conteggio dei messaggi viene aggiornato.
• Un messaggio viene contrassegnato come letto dopo la visualizzazione.

7 suggerimenti su come scrivere buoni criteri di accettazione

I criteri di accettazione non sono facili da scrivere., Nonostante il formato semplice, scrivere il testo è una sfida. Ecco sette suggerimenti per aiutarti a evitare errori comuni durante la scrittura di criteri di accettazione o per rivedere i criteri scritti da un membro del tuo team.

• Documentare i criteri prima dell’avvio del processo di sviluppo. In questo modo, il team ha maggiori probabilità di cogliere tutte le esigenze del cliente in anticipo. Inizialmente, è sufficiente impostare criteri per un piccolo numero di storie utente per completare i backlog per due sprint. I criteri di accettazione documentati vengono quindi utilizzati dagli sviluppatori per pianificare il processo tecnico.,
• Non rendere i criteri di accettazione troppo stretti. Criteri di accettazione troppo specifici lasciano agli sviluppatori poco spazio di manovra. Per evitare ciò, ricorda che i criteri di accettazione dovrebbero essere un’espressione di intenti, non una decisione finale. Inoltre, i criteri di accettazione ristretti potrebbero non tenere conto di tutte le azioni dell’utente.
• Mantieni i tuoi criteri realizzabili. Criteri di accettazione efficaci definiscono una quantità minima ragionevole di funzionalità che è possibile fornire. Ma se continui a descrivere tutti i piccoli dettagli, c’è il rischio che la tua squadra rimanga bloccata su centinaia di piccoli compiti.,
• Evitare criteri di accettazione troppo ampi. I criteri di accettazione ampi rendono vaga una storia utente. Criteri di accettazione efficaci devono delineare la portata del lavoro in modo che gli sviluppatori possano pianificare e stimare correttamente i loro sforzi.
• Evitare dettagli tecnici. I criteri di accettazione dovrebbero essere scritti in un linguaggio semplice. I tuoi stakeholder e manager potrebbero non avere background tecnici, quindi l’uso di un linguaggio semplice renderà i criteri comprensibili per tutti.
• Raggiungere il consenso., Lo stesso problema può essere risolto in modi diversi dai membri del team e dalle parti interessate a seconda dei loro punti di vista. Assicurati di comunicare i criteri di accettazione alle parti interessate e ai membri del team e raggiungere un accordo reciproco.
• Scrivere criteri di accettazione testabili. Ciò darà ai tester l’opportunità di garantire che tutti i requisiti siano soddisfatti e consentirà agli sviluppatori di sapere se la storia dell’utente è completa.,

Come scrivere i criteri di accettazione

Ecco cinque regole generali che ti aiuteranno a risolvere i problemi con la formulazione dei criteri di accettazione. Queste regole consentono di risparmiare tempo prezioso e stabilire una comprensione tra il proprietario del prodotto e il team di sviluppo.

Regola #1: Evitare “not”

“Not” significa “in nessun caso” e quindi non sarà sufficiente alcun tempo per verificare la conformità a tale condizione., Se riscrivi il requisito senza usare “non”, sarà più chiaro e, soprattutto, verificabile.

Esempio:

User Story

Non: Come utente, non voglio dover inserire la mia password ogni volta che accedo al mio account.
Do: Come utente, voglio che la mia password sia ricordata e compilata automaticamente in modo da poter accedere al mio account senza reinserire la mia password.

Criteri di accettazione

Non farlo: il sistema non deve fallire.
Fare: Il sistema dovrebbe avere una disponibilità non inferiore al 90%.,

Eccezione

È possibile utilizzare “not” nei criteri di accettazione per introdurre un’obiezione logica, ad esempio “il modulo di accesso non dovrebbe essere rosso.”Nella maggior parte dei casi, questo si applicherà ai requisiti non funzionali. In questo esempio, formuliamo un vincolo che può essere facilmente verificato se la gamma di sfumature di rosso è chiaramente definita (ad esempio, specificata in formato RGB).,

Regola #2: Utilizzare la voce attiva

una voce Attiva quando il soggetto della frase non è l’esecutore dell’azione. Se l’entità responsabile dell’esecuzione dell’azione non è chiaramente indicata, non sarà chiaro chi o cosa dovrebbe eseguire l’azione e sarà più difficile per l’utente verificare se un requisito è soddisfatto.,

Esempio:

User story

Non: come shopper online, voglio che i filtri vengano applicati in modo da poter trovare ciò che voglio.
Do: Come utente, voglio applicare filtri di ricerca in modo da poter trovare elementi.

Criteri di accettazione

Non: L’identità del cliente deve essere confermata. (Non è chiaro chi o cosa sia responsabile della conferma dell’identità del cliente.)
Do: Accounting_System dovrebbe confermare Customer_Indentity. (Si noti che le definizioni dei termini “Accounting_System” e “Customer_Indentity” dovrebbero essere aggiunte al glossario.,)

Regola #3: Evita di usare i pronomi (specialmente quelli non definiti)

Usa nomi invece di pronomi quando ti riferisci agli elementi a cui fai riferimento in altri requisiti. I pronomi dovrebbero essere evitati perché possono introdurre ambiguità.,

Ciò è particolarmente importante quando i criteri di accettazione sono memorizzati negli strumenti di gestione dei requisiti (come Jira) come istruzioni separate che non sono necessariamente organizzate. Usa sempre nomi invece di pronomi e eviterai questo problema.

Esempio:

User story

Non: come membro del sito, voglio condividere informazioni su di me in modo che gli altri possano vederlo.
Fare: Come membro del sito, voglio aggiungere una descrizione del profilo in modo che gli altri possano conoscere me.

Criteri di accettazione

Non: Il controllore deve inviare al conducente l’itinerario per la giornata., Deve essere consegnato almeno 8 ore prima del turno.
Fare: Il controller deve inviare il Driver_Itinerary per il giorno al conducente almeno 8 ore prima del Driver_Shift.

Regola n.4: Evita le congiunzioni

Le congiunzioni sono parole e frasi come “e”, “o”, “ma” e “così come” che combinano frasi semplici in frasi complesse., Il loro uso nei requisiti è di solito un segno che un requisito può essere suddiviso in diversi requisiti separati.

Esempio:

User story

Non: come designer dell’interfaccia utente, voglio creare e visualizzare un problema in modo da sapere cosa testare.
Do: Come designer dell’interfaccia utente, voglio creare un problema in modo da sapere cosa testare. / Come designer dell’interfaccia utente, voglio visualizzare un problema in modo da sapere cosa testare.

Criteri di accettazione

Non: l’utente deve essere attendibile o non attendibile.
Do: Security_System dovrebbe classificare ogni Utente come Trusted o Not_Trusted.,

Eccezione

“And,” “or,” e “not” possono essere usati per descrivere condizioni logiche e aggiungere qualificatori.

Regola #5: Evita gli assoluti irraggiungibili

Un assoluto (come la disponibilità al 100%) è irraggiungibile. Pensa a come controllare l’indicatore: sarà possibile dimostrare che il livello di disponibilità del sistema è esattamente al 100%?, E anche se un tale sistema potrebbe essere creato, puoi permettertelo?

Evita le parole ” tutti”, “sempre” e “mai”, poiché il controllo di tali requisiti assoluti richiederà un numero infinito di test.

Esempio:

User story

Non: Come viaggiatore, voglio sapere la mia posizione precisa aggiornata in tempo reale in modo da non perdermi. (“Tempo reale” può essere interpretato in modi diversi. Ad esempio, può essere visto come un assoluto (l’assenza di qualsiasi ritardo), che non può essere raggiunto e che non è verificabile.,)
Do: Come viaggiatore, voglio conoscere la mia posizione precisa, aggiornata ogni secondo, in modo da non perdermi.

Criteri di accettazione

Non: il sistema dovrebbe avere una disponibilità del 100%. (100% è un assoluto che non può essere raggiunto e non può essere verificato.)
Do: Il sistema dovrebbe avere una disponibilità di almeno il 98%.

Breve riepilogo dei criteri di accettazione

Speriamo che questo articolo abbia fatto luce sul mondo dei criteri di accettazione e delle storie degli utenti., Ecco i principali takeaway:

• I criteri di accettazione sono le condizioni che un prodotto software deve soddisfare per essere accettato da un utente, un cliente o, nel caso di funzionalità a livello di sistema, il sistema che consuma.
• I criteri di accettazione devono essere documentati e completati prima dell’inizio di un progetto, poiché il team e il cliente devono concordare quali risultati soddisferanno i requisiti del cliente.
• Ricorda che i criteri di accettazione dovrebbero essere un’espressione di intenti, non una decisione finale.
• Criteri di accettazione efficaci definiscono una quantità minima ragionevole di funzionalità.,
• I buoni criteri di accettazione devono delineare lo scopo del lavoro in modo che gli sviluppatori possano pianificare e stimare correttamente i loro sforzi.
• I criteri di accettazione devono essere scritti in un linguaggio semplice.
• Assicurati di comunicare i tuoi criteri di accettazione alle parti interessate e ai membri del team e raggiungere un accordo reciproco.
• Mentre scrivi i criteri di accettazione, evita di usare “non”, congiunzioni e assoluti irraggiungibili. Formulare frasi usando la voce attiva.,

Se vuoi creare criteri di accettazione e storie utente per la tua app mobile o se hai domande su questo argomento, contatta Mobindustry per una consulenza gratuita.