Dove inserire dettagli sui criteri di accettazione di un utente?

Question

Dove inserire dettagli sui criteri di accettazione di un utente?

Naviga le tue risposte

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)

8

In questo post del blog sui criteri di accettazione l'autore spiega che i buoni criteri di accettazione dovrebbero:

Indica un intent non una soluzione (ad es. "L'utente può scegliere un account" piuttosto che "L'utente può selezionare l'account da un menu a discesa")
Sono indipendenti dall'implementazione (idealmente il fraseggio sarebbe il lo stesso indipendentemente dal fatto che questa caratteristica / storia sia implementata per esempio. web, mobile o un sistema a comando vocale)
Sono di livello relativamente alto (non tutti i dettagli devono essere scritti)

E ulteriori dettagli come:

L'intestazione della colonna è "Saldo"
Il formato del saldo a rotazione è 99.999.999.999,9 D / CR
Dovremmo utilizzare un menu a discesa anziché le caselle di controllo

deve essere spostato su una documentazione interna del team o test di accettazione automatici

Tuttavia , Sento spesso persone accigliate sull'uso di Cetriolo o strutture simili per fare test GUI. Inoltre, l'utilizzo di una documentazione interna potrebbe generare molti problemi a causa del mancato aggiornamento periodico della documentazione.

Sto ancora cercando di trovare un modo efficace per acquisire tali dettagli durante la conversazione con il cliente.

development-process requirements agile scrum user-story

posta Songo 29.04.2013 - 17:13

fonte

4 risposte

Leggi altre domande sui tag development-process requirements agile scrum user-story

L'esperienza del programmatore può essere espressa in ore di codice come ore di volo per un pilota? [chiuso] Futuro di WPF e controlli gratuiti? [chiuso]

score 2 · Answer 1

Ho due posizioni (come proprietario del prodotto)

I nuovi feedback dei clienti possono tradursi in più storie, un cambiamento delle priorità della storia o alcuni nuovi dettagli su una storia. Nel registro posteriore prendo nota di questi dettagli per storie future che altrimenti potrei dimenticare. Queste sono note per me stesso.

Poco prima della riunione di pianificazione, traduco ciò che è nella mia testa + queste note in qualcosa che il team può esaminare. Questo documento (usiamo una pagina wiki per utente epico) è ulteriormente rifinito e amp; completato durante la pianificazione dello sprint come parte della discussione della storia con il team.

score 2 · Answer 2

Mi piace acquisire "Vincoli" come "P.S." alla fine della mia storia.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Questi vincoli sono limitazioni che i clienti hanno messo sul mio progetto, che devono essere considerati quando si valutano soluzioni diverse - ho bisogno di conoscerli in anticipo, quindi conferisco loro molta priorità.

score 0 · Answer 3

Mi piace definire i test di accettazione per ogni stile Story BDD come parte della documentazione di alto livello (Funzionalità - Storie - Test)

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Dettagli specifici come quelli sopra menzionati potrebbero essere parte di un mockup di schermate che il cliente firma; tali dettagli non sono sempre noti in anticipo, ma in ogni caso rientrano in "vincoli progettuali". Lo faccio, quando i mockup sono noti in anticipo, includendo i prototipi e i vincoli di progettazione concordati nella documentazione di alto livello, perché il client deve firmarlo prima che inizi il lavoro.

Quindi, mentre concettualmente separato, non vedo alcun danno includendolo nello stesso documento. Anche se non è richiesto per l'accesso al client, è conveniente avere tutti i requisiti per una funzionalità / storia in un unico posto.

score 0 · Answer 4

Prendo un approccio piuttosto pragmatico - se un dettaglio tecnico è importante per l'accettazione di una storia, allora dovrebbe essere nei criteri di accettazione, indipendentemente da ciò che dice qualche post del blog. Se è davvero fondamentale che il nome della colonna sia "saldo", questo deve far parte dei criteri di accettazione.

Ciò potrebbe portare a criteri di accettazione troppo lunghi. In tal caso, penso che sia necessario avere un criterio di accettazione "deve superare la suite di test X", ed è nella "suite di test X" dove si inseriscono tutti i dettagli nitidi e grossi sul prodotto.