Scrum: come lavorare su una storia alla volta

Sono stato nominato maestro di mischia in una nuova squadra di scrum formata. Abbiamo già fatto alcuni sprint. All'inizio ho cercato di far lavorare la mia squadra su una storia alla volta. Ma non ha funzionato. Il mio team ha avuto difficoltà a distribuire i compiti in modo che possano lavorare contemporaneamente su una storia. Forse stiamo facendo qualcosa di sbagliato?

Ad esempio: abbiamo una storia per creare una nuova finestra di dialogo. Creiamo le seguenti attività:

• Crea classi modello
• Leggi i dati del modello dal database
• Collega le classi del modello con la vista
• Implementare la gestione delle finestre di dialogo
• Salva i dati alla chiusura
• Documentazione di prova
• Descrizione della soluzione

Queste attività possono essere svolte da più di una persona alla volta? I compiti - più o meno - si basano l'uno sull'altro. O progettiamo i compiti in modo sbagliato?

Perché tutto il team dovrebbe lavorare su un'unica storia?

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

Sebbene ciò dipenda fortemente dalle dimensioni della user story, in molti casi un solo sviluppatore dovrebbe essere assegnato a una story per evitare che i tuoi sviluppatori facciano un passo sulle dita degli altri. Sebbene storie più grandi o molto complesse possano richiedere più sviluppatori, può anche essere possibile suddividere tali storie in molte storie più piccole che possono essere assegnate individualmente.

Ciò che generalmente facciamo è scomporre le storie in sottoattività di dev / infra / analyst.

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

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

3. Registriamo il tempo trascorso e aggiorniamo la stima rimanente alla fine della giornata prima di partire o prima dello stand up giornaliero.

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

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

6. Un'epica può essere composta da molte storie

Quello che vuoi che la tua squadra faccia è chiamato sciame , ma non tutti gli oggetti arretrati possono essere sciamati da tutto il team. Il pensiero comune è che lo sciame richiede alcune pre-condizioni:

• una squadra interfunzionale e collocata
• una storia non banale
• una definizione di "fatto" che implica il coinvolgimento di tutto il team

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

Ma fai attenzione quando usi lo sciame troppo spesso o con troppe persone contemporaneamente, poiché potresti incorrere in un problema di surriscaldamento, quando potrebbero apparire dei conflitti tra i membri del team in quanto troppi lavorano sullo stesso oggetto.

Potresti voler leggere Mike Cohn's dovrebbe un team sciamare su un oggetto arretrato alla volta? o questo articolo che ho scritto (ieri) che si occupa più specificamente di bug: sciamare o non sciamare

Una parte importante di SCRUM è che il team dovrebbe prendere questo tipo di decisioni. L'arretrato dovrebbe contenere le storie degli utenti con le informazioni sperate sufficienti per generare attività.

Mentre può essere possibile forzare una user story in un oggetto su cui tutto il team può lavorare contemporaneamente, ciò che è più importante è che il team raccoglie gli articoli su cui lavorare, definisce le attività per completare la user story e utilizza lo stand giornaliero per vedere se sei sulla buona strada con il lavoro promesso.

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

Utilizzando il tuo esempio della difficoltà di distribuire compiti su cui è possibile lavorare contemporaneamente, una possibile soluzione è quella di affrontare più storie e consegnare 3 o 4 elementi in uno sprint. Poiché le attività di questa user story si basano l'una sull'altra, sarà difficile distribuire il lavoro. Quindi, piuttosto che combattere che l'abbraccio.

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

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

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

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

Dovresti mantenere la tua squadra concentrata, sì, ma allo stesso tempo devi tenere occupati tutti e tutti i soggetti 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 essere la tua squadra).