Scrum: come lavorare su una storia alla volta

Perché tutto il team dovrebbe lavorare su una singola storia?

Perché non rendere le storie abbastanza piccole (e abbastanza indipendenti) in modo che una persona (o meglio una coppia che fa la programmazione della coppia) possa lavorare su una singola storia. Questo processo aiuta anche a definire meglio i requisiti e a pensare di più sul problema e sull'implementazione. Le stime possono anche essere più accurate, ma non ci sono garanzie qui.

Sebbene ciò dipenda in larga misura dalle dimensioni della trama dell'utente, in molti casi è necessario assegnare a un solo sviluppatore uno story per evitare che gli sviluppatori si calpestino gli uni sugli altri. Anche se storie più grandi o molto complesse possono richiedere più sviluppatori, ma potrebbe anche essere possibile suddividere quelle storie in molte storie più piccole che possono essere assegnate individualmente.

Ciò che generalmente facciamo è suddividere le storie in sotto-attività di sviluppo / analisi / analisi.

1. Generalmente tutto ciò che è più di un giorno di lavoro è una storia.

2. Una volta che le attività sono suddivise, uno o massimo due sviluppatori lavorano su a storia, a seconda del no: dei compiti a portata di mano. Di solito è quello.

3. Registriamo il tempo trascorso e aggiorniamo la stima rimanente alla fine del giorno prima di partire o prima che il quotidiano si alzi.

4. Le attività secondarie vengono create per eventuali nuovi problemi che si verificano durante il lavoro.

5. Una storia che dura più di 2 settimane di lavoro è considerata un'epica.

6. Un Epic può essere costituito da molte storie

Quello che vuoi che la tua squadra faccia è chiamato sciame , ma non tutti gli elementi del backlog possono essere sciamati da tutto il team. Il pensiero comune è che lo sciame richiede alcune condizioni preliminari:

• un team interfunzionale e collocato
• una storia non banale
• una definizione di "fatto" che implica il coinvolgimento dell'intero team

Quando si interrompe una storia in attività, la squadra dovrebbe già essere in modalità sciame in modo che le attività generate siano compatibili con sciami e possano coinvolgere l'intero team.

Ma fai attenzione quando usi sciami di troppo spesso o con troppe persone in una volta, poiché potresti incontrare un problema di riscaldamento eccessivo, quando potrebbero apparire alcuni conflitti tra i membri del team poiché sono troppi a lavorare sullo stesso elemento.

Potresti voler leggere Un team sciami su un elemento di un backlog alla volta? o su questo articolo che ho scritto (ieri) che tratta in modo più specifico di bug: sciamare o non sciamare

Gran parte di SCRUM è che la squadra dovrebbe prendere questo tipo di decisioni. L'arretrato dovrebbe avere le storie degli utenti con informazioni abbastanza speranzose per le attività da generare.

Anche se è possibile costringere una storia di un utente in un oggetto su cui tutto il team può lavorare contemporaneamente, ciò che è più importante è che il team scelga gli oggetti su cui lavorare, definisce i compiti per completare la storia dell'utente e usa il quotidiano alzarsi per vedere se si è sulla buona strada con il lavoro promesso.

Il dolore che provi nel cercare di lavorare su una sola storia alla volta deve essere riconosciuto dal team e nelle potenziali soluzioni di retrospettiva dello sprint bisogna essere educati. Scopri cosa stai facendo bene e quali cose devono essere migliorate.

Usando il tuo esempio della difficoltà nella distribuzione di compiti che possono essere lavorati contemporaneamente, una possibile soluzione è quella di assumere più storie e delievery 3 o 4 elementi in uno sprint. Dal momento che i compiti di questa user story si basano l'uno sull'altro, sarà difficile distribuire il lavoro. Quindi piuttosto che combattere che lo abbraccia.

Le tue attività, come indicato, sembrano "piccole" abbastanza da essere distribuite, ma esiste un certo accoppiamento tra attività come quella sulla modellazione dei dati e il loro recupero dal database.

Ciò che sarebbe possibile è dividerlo in tre cose principali su cui le persone possono lavorare contemporaneamente, con qualche lavoro extra / impostazione:

• Back-end (database, modello ecc.)
• Front-end (utilizzando dati fittizi)
• Test (impostazione di aspettative, scenario, ecc.)

Le attività che non possono essere divise possono essere fatte a coppie. E, naturalmente, non c'è nulla di intrinsecamente sbagliato in più di una storia in corso in un punto qualsiasi; basta che ogni membro del team sappia cosa stanno facendo gli altri e possono dare una mano ogni volta che è necessario (come in "proprietà condivisa del codice").

Mantieni la tua squadra concentrata, sì, ma allo stesso tempo devi tenere tutti impegnati e tutti coinvolti.

Inoltre, quanto è grande la tua squadra? Anche questo è un fattore; è piuttosto difficile avere dieci persone che lavorano su una storia, e se puoi, la tua storia è molto, troppo grande e dovrebbe essere divisa (come dovrebbe il tuo team).