Lavorare attraverso una User Story

Sembra che tu stia cercando BDD e il linguaggio delle specifiche Gherkin. Il linguaggio Gherkin è un modo per esprimere scenari di business che possono essere utilizzati per spegnere test a livello di codice. Una volta ottenuti gli stub di test, è possibile iniziare a implementare la soluzione utilizzando metodi di stile TDD red / green / refactor più tradizionali.

Ecco un post sul blog: link

Esistono framework BDD in grado di leggere gli scenari di cetriolino in più lingue, quindi è probabile che si possa iniziare con qualsiasi cosa gli sviluppatori si sentano a proprio agio.

Hm. Guardo i tuoi tre scenari e vedo una dipendenza che mi preoccupa: lo scenario 1 sembra presumere che tu abbia già realizzato lo scenario 2. Quando mi succede, cerco modi alternativi per dividere la storia. Come minimo, questo mi porta a chiedere: "Cosa c'è di veramente diverso in questi tre scenari?" Forse niente. Forse ho solo bisogno di uno scenario.

O forse c'è qualche asimmetria qui. Una persona ha bisogno di un permesso speciale (autorizzazione?) Per invitare un'altra persona? Sembra qualcosa da esplorare con qualcuno che conosce il dominio e il comportamento previsto del sistema.

Diciamo che il sistema ha bisogno di regole di autorizzazione speciali. Nessun problema. Scriverei la prima storia come se permettessi a tutti di invitare tutti gli altri (sistema di onore), quindi aggiungere più storie per ogni tipo di regola di autorizzazione "interessante". Una volta che chiunque può invitare qualcun altro, ciascuna ulteriore storia correlata perfeziona la funzione impedendo le richieste di invito che non dovrebbero essere consentite. Ciò va bene per una serie di motivi, ma se il sistema ha serie preoccupazioni in termini di sicurezza / privacy, potrebbe essere necessario capovolgerlo, in modo da iniziare con "nessuno può invitare nessuno", quindi aggiungere le autorizzazioni una storia alla volta. Cercare di dividere la storia più grande in una più piccola tende a indurmi a porre domande su potenziali ipotesi non dette. Non vogliamo aspettare troppo a lungo per sentire "Beh naturalmente abbiamo le politiche di autorizzazione ... chi non ha questo?!"

Per me, la tecnica killer è Talking in Examples. Quando discuto di una storia con qualcuno, descrivo inesorabilmente esempi che illustrano la mia attuale comprensione della storia. In questo modo, l'altra persona ha l'opportunità di ascoltare il mio esempio e dirmi come ho sbagliato. Quel momento porta ad imparare un dettaglio che mi serviva per costruire il sistema giusto. Lo faccio più e più volte, raccogliendo questi dettagli. Continuo a cercare di descrivere esempi più semplici e più semplici e che spinge l'altra persona a "combattere" per aggiungere nuovamente variazioni importanti. Entro pochi minuti conosco molto. In 15 minuti quasi certamente ne so abbastanza per iniziare senza andare nella direzione sbagliata. Poi costruisco roba (TDD o no, qualsiasi cosa funzioni per te), metto qualcosa di fronte a loro, e poi ottengo più feedback. Negli esempi Ancora e ancora. Funziona.

Questi esempi, a proposito, possono diventare test automatici per guidare il comportamento del sistema. Automatizzali come più ti piace, a seconda di quanto attivamente il Cliente parteciperà alla scrittura e perfezionerà quegli esempi. Ricorda solo che il 90% del valore di quegli esempi deriva dal parlare, non dall'automazione.