In BDD, passando da feature a user story come funziona?

3

Il mio background è il libro BDD in azione.

Come si va da Feature a Stories? Più specificamente mi piacerebbe capire quanto segue:

1- Quando si fornisce la scomposizione in storie? Lo fai mentre noti gli esempi che illustrano la tua funzione?

2 - In caso affermativo, come procedi nel tuo sviluppo, quindi: inizi a lavorare sui racconti lasciando la tua funzione in sospeso? Hai prima ragione sullo scenario e poi, passa alle storie che ne derivano, lasciando in sospeso il test delle funzionalità?

La chiave qui è il processo, se faccio una scomposizione di una caratteristica in una storia, prima di scrivere il mio scenario reale che individua quelle storie, potrei scrivere storie che non sono rilevanti per la funzione, vero?

Questo però mi fa pensare che le storie debbano essere spiegate nello stesso modo in cui i test di unità / integrazione sono ricavati da storie di utenti?

Tuttavia, se lo fai bene, è difficile pianificare una funzione per l'iterazione di mischia.

Comprendo che si tratta solo di uno strumento di pianificazione, ma sarebbe interessante capire in che modo questa pianificazione viene effettivamente utilizzata nel contesto della gestione di una funzionalità.

Credo che non si debba fare una pianificazione troppo anticipata, non impegnarsi per le cose senza esserne sicuri, ma nel frattempo mi sembra che la scomposizione nei diversi processi (storie) coinvolte nel processo delle caratteristiche richieda alcune anticipazioni pianificazione.

Gradirei un chiarimento su questo punto.

    
posta MaatDeamon 21.07.2014 - 15:45
fonte

1 risposta

1

In definitiva, le storie degli utenti traducono in requisiti software, e così fanno anche le funzionalità.

Tutte le descrizioni di alto livello del software dovrebbero in ultima analisi tradursi in requisiti software individuali che sono specifici, misurabili, assegnabili, realistici e tempestivi . Se hai ragione, lo stai facendo "correttamente", assumendo che il tuo processo di raccolta dei requisiti sia sufficientemente completo.

Una User story è una o più frasi nel linguaggio quotidiano o commerciale dell'utente finale o dell'utente di un sistema che cattura ciò che un utente fa o deve fare come parte della sua funzione lavorativa. In genere, una User Story assume la forma:

"As a <role>, I want <goal/desire> so that <benefit>"

Ad esempio:

As a Customer Service Representative, I want to search for my customers by their first and last names, so that I can find them in the system if they don't know their account number.

Questo si traduce nel requisito:

The Customer Service screen shall provide the capability to look up customers by first and last name.

Le User Story non devono necessariamente derivare da caratteristiche. La maggior parte dei rappresentanti del servizio clienti sa già che hanno bisogno di uno strumento per cercare i clienti, indipendentemente da qualsiasi elenco di funzionalità che potrebbe essere o non essere ancora creato.

Ulteriori letture
User Story

    
risposta data 21.07.2014 - 15:54
fonte

Leggi altre domande sui tag