Una user story dovrebbe essere condivisa tra gli sviluppatori? [chiuso]

Vedo comunemente storie che hanno uno sviluppo back-end e front-end. Ad esempio, considera una finestra di dialogo di grandi dimensioni con alcune tabelle e alcuni controlli dinamici. Faremo diverse storie (forse una per ogni tavolo e un'altra per il sistema di controllo dinamico).

Il team di sviluppo si dividerà quindi con una persona sul back-end e un'altra sul front-end. Questo rende facile per la persona back-end preoccuparsi solo della struttura del livello SQL mentre la persona front-end si concentra su cose come il layout. Dopo che è stata concordata l'interfaccia iniziale tra back-end e front-end, i due sviluppatori possono focalizzare la loro attenzione per ottenere la loro parte entro la fine dello sprint.

Poi arriva il caos. Chi "possiede" quale storia? Che cosa significa "in corso" o "completato"? Dovremmo creare due storie separate per il back-end e il front-end? In tal caso, ciò non spezza l'idea delle storie degli utenti in base alla funzionalità? Il nostro sistema ha una nozione di "sottoattività", che facilita alcuni di questi problemi. Ma i compiti secondari aggiungono ulteriore complessità. C'è un modo migliore? È un modo "cattivo" di usare Scrum?

Ho usato una qualche forma di Agile negli ultimi anni in un paio di posti. Non ho ancora una formazione ufficiale, quindi per favore perdona qualsiasi terminologia o ideologia sbagliata. Sto solo cercando di imparare modi pratici per migliorare il nostro processo.

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

Nel tuo caso, penso che sia il front-end che il back-end dovrebbero essere una storia unica. Dividilo in compiti. Gli sviluppatori hanno i loro diversi compiti. Queste attività possono essere monitorate individualmente attraverso le loro fasi: In corso, Codifica eseguita, Test del modulo fatto, ecc.

Assicurati di includere le attività assegnate al QA nella stessa storia - senza convalida una storia è inutile. Il QA metterà alla prova la storia integrata end-to-end che un cliente vedrà. Solo allora la storia generale dovrebbe essere contrassegnata come Fine. In un ambiente Agile ideale, un cliente reale o un proxy cliente prova anche la storia in un'applicazione in esecuzione e contrassegna la storia Accettata se soddisfa i requisiti concordati.

Se desideri cicli di feedback più rapidi, prova a suddividere il caso d'uso in funzionalità end-to-end più piccole. Ad esempio, invece di un caso d'uso come "Un cliente può acquistare oggetti utilizzando un carrello", dividerlo in "Un cliente può aggiungere un prodotto a un carrello" e così via ... Quindi completare 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 in modo conciso con un acronimo chiamato " INVEST ". È stato creato da Bill Wake e reso popolare dal movimento Scrum. Nota in particolare che gli articoli sulle storie sono indipendenti e verticali.

Qualche informazione in più qui e qui .

Chi "possiede" quale storia?

Chiunque afferra la storia. Sono fondamentali dal punto di vista organizzativo se una persona è responsabile del lavoro. Una volta che hai due persone, è troppo facile passare il dollaro.

Dovremmo creare due storie separate per il back-end e il front-end? In tal caso, ciò non spezza l'idea delle storie degli utenti in base alla funzionalità?

Dipende. Ho visto lavorare in entrambi i modi. Se la storia è abbastanza grande da consentire a due sviluppatori di lavorarci 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.

È un modo "cattivo" di usare 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 ciò che vorrebbero, tutti negoziano e poi fornisci un feedback nella storia sui suoi progressi.

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

Laddove abbiamo implementato i modelli Scrum, ci si aspetta perfettamente che più sviluppatori possano essere coinvolti in una storia per singolo utente. Potrebbe esserci del lavoro per livello dati, integrazione, CSS front-end, infrastruttura, ecc. Il team può riunire le varie attività secondarie affinché una storia possa essere eseguita.

Detto questo, una persona possiede la storia ed è responsabile per l'aggiornamento sullo stato di avanzamento e garantire che tutti abbiano fatto il loro pezzo e che stia lavorando insieme. Questa è la persona per noi che riferisce 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 alle attività sarebbe quella di riassegnare la proprietà man mano che ogni persona finisce la propria parte. Quindi la storia viene passata in giro - forse lo sviluppatore 1 inizia con il lavoro di back-end, quindi passa allo sviluppatore 2 per eseguire l'interfaccia utente. Quindi viene passato al tuo tester di qualità per la verifica. Questo metodo dovrebbe funzionare bene in ambienti in cui si utilizzano carte reali sul muro o se il software non tiene traccia delle attività.

Ma in ogni caso, consiglio di non definire mai "fatto" una storia fino a quando il team non acconsente a farlo, compresi i test. In questo modo ognuno ha la possibilità di dare il proprio contributo. E se lo combini con idee sulla proprietà del codice collettivo e le revisioni del codice, ogni storia è comunque "di proprietà" del 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 le storie degli utenti come parte del nostro incontro mattutino / SCRUM. In questo modo tutti possono facilmente riconoscere o contestare se è davvero "fatto". Altre volte lasciamo semplicemente che il nostro ingegnere addetto al controllo qualità lo faccia - se è soddisfatta del fatto che sia stata testata e funzionante e che tutte le attività siano complete, allora lo chiamiamo fatto.

Dove sono oggi chiamiamo questo grande progetto un "epico". Un'epopea è composta da più storie e può comprendere più sprint / iterazioni. Una storia, per noi, viene sempre data a un singolo sviluppatore e dovrebbe rientrare in un singolo sprint. Una singola storia viene quindi suddivisa in compiti. Ognuna delle attività è completata dallo stesso sviluppatore su quella storia. I compiti hanno lo scopo di fornire informazioni sullo stato di avanzamento della storia durante lo sprint / iterazione. Man mano che ogni storia è completata, da ogni sviluppatore, l'epopea mostra progressi.

Il punto dell'epopea è avere un obiettivo più ampio che non si adatta necessariamente a un singolo sprint / iterazione. Nel tempo tutte le storie sono completate e l'epopea è terminata. Le epiche vengono messe in una versione.

Poi arriva il caos. Chi "possiede" quale storia? Che cosa significa "in corso" o "completato"?

Demoliamo il codice ogni due settimane in cui le storie per 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 sua storia ed è responsabile per mostrarla (questa parte è una specie di semplificazione eccessiva, ma abbastanza buona per questa risposta; coordiniamo le nostre demo attraverso una sola persona). "Fatto" significa che può essere dimostrato con successo. "In corso" significa che ho compiti in sospeso e la storia non è completa. Un'epopea è completa quando tutte le storie di quell'epopea sono state dimostrate con successo.

Ora questa è la progressione del caso perfetto. Abbiamo storie e dimostrazioni che falliscono, utenti che vogliono qualcos'altro, ecc. Sopra c'è l'obiettivo e per la maggior parte funziona.