Una storia utente può essere condivisa tra gli sviluppatori? [chiuso]

Una "storia" è così denominata perché rappresenta una storia completa, , dal punto di vista del cliente. Senza il front-end o il back-end, non esiste un percorso del caso d'uso da eseguire da parte del cliente.

Nel tuo caso, penso che sia il front-end che il back-end dovrebbero essere una storia singola. Dividilo in compiti. Gli sviluppatori hanno i loro diversi compiti. Queste attività possono essere monitorate individualmente attraverso le loro fasi: In corso, Coding Done, Module Testing Fatto, ecc.

Assicurati di includere le attività assegnate dal QA nella stessa storia - senza convalida una storia è inutile. Il controllo qualità testerà la storia integrata end-to-end che un cliente vedrà. Solo allora la trama generale dovrebbe essere contrassegnata come Completata. In un ambiente Agile ideale, un vero cliente o un proxy cliente prova anche la storia in un'applicazione in esecuzione e segna la storia Accettata se soddisfa i requisiti concordati.

Se desideri cicli di feedback più rapidi, prova a rompere il caso d'uso in funzionalità end-to-end più piccole. Ad esempio, invece di un caso d'uso come "Un cliente può comprare cose usando un carrello della spesa", dividerlo in "Un cliente può aggiungere un prodotto a un carrello della spesa" e così via ... Quindi completa ogni caso d'uso più piccolo end to end come descritto sopra.

EDIT: Volevo eseguire il backup dei punti sopra con alcune fonti. Le caratteristiche di una buona user story sono rappresentate sinteticamente con un acronimo chiamato " INVEST ". È stato creato da Bill Wake e reso popolare dal movimento Scrum. Nota in particolare gli articoli su storie indipendenti e verticali.

Altre informazioni qui e here .

Who "owns" which story?

Chiunque afferra la storia. La chiave da un punto di vista organizzativo è che la persona one è responsabile del lavoro. Una volta che ottieni due persone, è troppo facile passare il tempo.

Should we make two separate stories for back-end and front-end? If so, doesn't that break the idea of user stories based on feature?

Dipende. Ho visto lavorare in entrambi i modi. Se la storia è abbastanza grande da far lavorare due sviluppatori a tempo pieno, allora forse dovrebbe essere divisa. Se i due sviluppatori fanno parte di due team diversi, allora forse dovrebbe essere diviso. Se i due sviluppatori lavoreranno su di esso durante diversi sprint, allora forse dovrebbe essere diviso.

Is this a "bad" way to use Scrum?

La chiave da ricordare è che il processo è lì per servirti, non viceversa. Le storie degli utenti sono un modo per persone tecniche e persone non tecniche per facilitare la comunicazione. Spiegano cosa vorrebbero, tutti negoziano e quindi fornisci feedback nella storia dei suoi progressi.

Finché il processo funziona per te, non può essere poi così male.

Dove abbiamo implementato i modelli Scrum, ci si aspetta che più sviluppatori possano essere coinvolti in una singola storia utente. Potrebbe esserci lavoro per livello dati, integrazione, CSS front-end, infrastruttura, ecc. Il team può combinare le varie sotto-attività per una storia per farlo.

Detto questo, una persona possiede la storia ed è responsabile dell'aggiornamento sul suo progresso e garantisce che tutti abbiano fatto il loro pezzo e che stia lavorando insieme. Questa è la persona per noi che segnala che una storia è "fatta".

Come altri hanno suggerito, il mio team divide anche le storie degli utenti in attività. Questo è generalmente facile da fare se gestisci le tue storie utente tramite software (come JIRA o Rally). Quindi è facile dire quali parti della storia si stanno muovendo.

Ma un'alternativa per i compiti sarebbe semplicemente riassegnare la proprietà quando ogni persona finisce la sua parte. Così la storia viene passata in giro - forse lo sviluppatore 1 inizia con il lavoro di back-end, quindi passa allo sviluppatore 2 per fare l'interfaccia utente. Quindi viene passato al tuo tester QA per la verifica. Questo metodo dovrebbe funzionare bene in ambienti in cui si utilizzano schede reali a parete o se il software non traccia le attività.

Ma in ogni caso, mi raccomando di non chiamare mai una storia "fatta" fino a quando il team non accetterà che è stata fatta, compresa la verifica. In questo modo tutti hanno la possibilità di dare il loro contributo. E se si combina questo con le idee sulla proprietà del codice collettivo e le revisioni del codice, ogni storia è comunque "posseduta" dal team. Può essere "assegnato" a persone diverse lungo la strada, ma se qualcuno è fuori (malato / ferie / troppe riunioni? / Altro) il lavoro può ancora essere svolto.

Il mio team accetta spesso storie di utenti come parte della riunione mattutina / riunione SCRUM. In questo modo tutti possono facilmente riconoscere o contestare se è davvero "fatto". Altre volte lasciamo che sia il nostro ingegnere del QA a farlo - se è soddisfatta che sia testata e funzionante e che tutte le attività siano complete, allora la chiamiamo fatta.

Dove sono oggi chiamiamo questo "progetto più grande" un "epico". Un'epica è composta da più storie e può comprendere più sprint / iterazioni. Una storia, per noi, è sempre data a un singolo sviluppatore e dovrebbe rientrare in un singolo sprint. Una singola storia è quindi suddivisa in attività. Ciascuno dei compiti è completato dallo stesso sviluppatore su quella storia. I compiti hanno lo scopo di dare un'idea del progresso della storia durante lo sprint / iterazione. Man mano che ogni storia è completata, da ogni sviluppatore, l'epico mostra progressi.

Il punto dell'epica è avere un obiettivo più grande che non rientra necessariamente in un singolo sprint / iterazione. Nel corso del tempo tutte le storie sono completate e l'epopea è finita. Le epiche sono inserite in una versione.

Then comes the chaos. Who "owns" which story? What does "in progress" mean or "done"?

Abbiamo codice demo ogni due settimane in cui le storie relative a tale sprint / iterazione devono essere mostrate agli stakeholder e approvate. In questo contesto, "fatto" per una storia significa che posso mostrarti cosa fa. Uno sviluppatore possiede la propria storia ed è responsabile di mostrarla (questa parte è una specie di semplificazione eccessiva, ma abbastanza buona per questa risposta: coordiniamo i nostri demo attraverso una singola persona). "Fatto" significa che può essere dimostrato con successo. "In corso" significa che ho compiti in sospeso e la storia non è completa. Un'epica è completa quando tutte le storie di quell'epica sono state dimostrate con successo.

Questa è la progressione del caso perfetta. Abbiamo storie e demo che falliscono, utenti che vogliono qualcos'altro, ecc. Sopra è l'obiettivo e per la maggior parte funziona.