Recupero da una trama dell'utente al codice durante l'utilizzo di TDD (scrum)

Is it true to say that the product manager and the QA should be responsible for taking the user-story and breaking it down to acceptance tests?

Per lo più. In realtà, potrebbero non scrivere il test di accettazione effettivo. Possono approvare qualcosa che hai scritto. Ma approvano i test di accettazione. Sì.

the acceptance tests need to be formal, so they can be used as tests, but also human readable so that the product can approve they are the requirements, right?

irrilevante. Possono essere formalizzati come test automatici. Oppure possono essere informali e potrebbe essere il tuo lavoro creare test automatici dai criteri di test di accettazione informali.

Anche. I "requisiti" sono la storia dell'utente. Non è assolutamente necessario creare un'altra versione della storia chiamata "requisiti". Alcune persone a cui piace elaborare la storia prima che codificano. Puoi chiamare questo requisito, ma "design" è una parola migliore. "Elaborazione" è la parola migliore.

Is it also true that I later take these acceptance tests and use them as my requirements, i.e. they are a set of use-cases which I implement (through TDD)?

Sì. La storia conduce a test di accettazione. La storia è un comportamento richiesto (ad esempio, "requisiti"). La storia conduce a test che guidano la progettazione e lo sviluppo del software.

that's the current flow I have in mind right now.

Non c'è molto "flusso" in questo.

Storia - > test di accettazione.

Storia - > elaborazione ("design", "requisiti") - > unit test - > codice.

Storia - > L'utente è in grado di fare qualcosa di valore.

Storia - > Punti della storia - > calcolo della velocità.

Nota il modello. La storia guida in gran parte tutto.

When, by whom and to which format are the requirements compiled?

Per prima. Definire "requisiti". In che modo si differenzia dalla storia stessa?

What I had in mind was that the product and QA define the requirements via acceptance tests

Di solito.

during the iteration then the developer might get stuck waiting for them.

non corretto. Lo sviluppatore può (e spesso lo fa) aiutare a scrivere questi. Questo è il punto di "sviluppo": elaborare la storia per un "fatto" ben definito.

Ancora una volta. Quando hai dubbi o domande, devi veramente leggere il Manifesto Agile. Il Manifesto è abbastanza chiaro: gli sviluppatori devono parlare con i proprietari dei prodotti, gli utenti, il controllo qualità e tutti gli altri soggetti interessati. L'interazione è in realtà la cosa più importante che può accadere.

Ho intenzione di risponderti dal punto di vista di Extreme Programming (XP) per quanto riguarda i test di accettazione.

Quando stavo per entrare (e leggere i libri), ho letto che è proprio il ruolo dello sviluppatore lavorare con il cliente / utente per sviluppare / documentare i test di accettazione. Uno degli obiettivi di XP è aumentare la comunicazione diretta tra utente / cliente e sviluppatore. Questo è spesso l'ideale, perché riduce la possibilità di errori di codifica dovuti a problemi di comunicazione dei requisiti.

Ho fatto TDD per circa 8 anni e ho seguito l'approccio di cui sopra. Penso che abbia migliorato la velocità di sviluppo e la soddisfazione con il sistema perché client / utenti vedono come influenzano direttamente lo sviluppo dell'applicazione.

La principale difficoltà che ho incontrato (con clienti più piccoli) è che è molto difficile convincerli a partecipare alla specifica dei test di accettazione. (Di solito devo farlo per loro e inviarlo a loro per la revisione.) I clienti più grandi con cui ho lavorato, di solito avevano questa mentalità, quindi erano pronti a fornire test di accettazione specifici.

Da quello che ho letto su scrum, non sono sicuro che definisca quale ruolo è responsabile della definizione / scrittura dei test di accettazione. Presumo che possa variare da un team all'altro.

Il mio consiglio è che, come sviluppatore, dovresti partecipare il più possibile al processo di definizione del test. E l'obiettivo è ottenere i risultati dello sprint di fronte agli utenti il più rapidamente possibile, in modo che possano dirti tutto ciò che hanno dimenticato di pensare (o quello che ti hanno detto in modo errato) il più rapidamente possibile.

La User story non è "Come utente voglio XXX in modo che YYY" ! La storia degli utenti è una promessa per la futura comunicazione con l'OP. Questo risolve il tuo problema con maggiori dettagli. È necessario comunicare con l'OP durante lo sprint per ottenere tutte le informazioni necessarie.

La storia degli utenti ha anche più funzioni, quindi la frase breve promette la comunicazione. La parte necessaria della user story sono i criteri di accettazione. I criteri di accettazione devono essere noti prima di impegnarsi nella storia dell'utente (dovrebbero essere noti prima di stimare la trama dell'utente). I criteri di accettazione sono l'input per i test di accettazione = i test di accettazione devono testare i criteri di accettazione.

Quindi, quando inizi a lavorare sulla storia degli utenti con l'approccio TDD, non devi prima creare un test di accettazione automatico basato su criteri di accettazione per ottenere un test negativo per questo. Continuerai con l'implementazione del codice necessario usando TDD prima del test di accettazione. Continuerete con il prossimo test di accettazione. Ne ho scritto anche in un'altra domanda .