Lo Sprint richiede più tempo del previsto. Cosa dovremmo fare?

Cosa dovremmo fare se un oggetto in mischia impiega più tempo del previsto? lo sto chiedendo perché ho notato elementi che gli sviluppatori stanno lottando per completare in quanto è molto più difficile di quanto inizialmente pensato.

In tale situazione dovremmo

• rimuovere l'articolo dallo sprint al catalogo dei prodotti in modo da poter rispettare la sequenza temporale dello sprint?
• passare all'elemento di sprint più semplice e lasciare lo sprint problematico fino alla fine della sequenza temporale
• giustificare alla revisione dello sprint perché l'articolo non può essere completato allo sprint corrente per le parti interessate?

Come possiamo evitare tale situazione in futuro? È dovuto alla mancanza di una pianificazione anticipata o non abbiamo fatto uno sforzo per suddividere l'elemento dello sprint in un oggetto più piccolo?

Con "item", suppongo che tu intenda "task".

L'ottimismo della pianificazione nel software è vecchio quanto il software stesso. L'aspetto positivo di Scrum è che presto lo affronterai e ne creerai visibilità: ecco perché la velocità dei team si basa su dati passati e non su stime future.

Per completare una storia, devi anche completare i compiti che risultano molto più difficili del previsto. Nessuna scusa per rimandarli. (Ecco perché la definizione di fatto è così importante). Se ciò significa che la squadra sta fallendo una storia, allora è un peccato, avrai qualcosa di cui parlare nella prossima retrospettiva. La velocità diminuirà (diventerà più realistica) e il team imparerà a fare stime migliori o a lasciare un margine di sicurezza maggiore per compiti imprevisti. Il proprietario del prodotto avrà una visione più realistica della sua pianificazione del rilascio.

Cosa dovremmo fare se un oggetto in mischia impiega più tempo del previsto?

Supponendo che per articolo intendi la storia, alla fine dello sprint di solito lo rimetti nel backlog del prodotto (e probabilmente lo pianifichi per la prossima iterazione). Il team ottiene zero punti per questo nell'iterazione corrente.

Un'altra alternativa, se la storia è abbastanza grande, è di tagliarla verticalmente . Ad esempio, la storia "ricerca nel catalogo prodotti" può eventualmente essere suddivisa in "ricerca per categoria" e "ricerca full-text", ma non in "modulo di ricerca" e "risultati della ricerca".

Come possiamo evitare tale situazione in futuro?

Non esiste una risposta diretta semplice a questo. Nella mischia fai sprint retrospettive ogni iterazione, dove di solito discuti questo tipo di cose con il team. Esistono diverse possibilità:

• La squadra, o alcuni membri della squadra, ha una brutta settimana
• Le pipeline del tuo team lavorano gli oggetti in orizzontale (ad es. Backend-> frontend-> QA)
• Le storie sono troppo grandi per errore
• Il team "placca in oro" le storie aggiungendo lavoro extra che non è strettamente necessario per il completamento della storia.
• Le storie sono molto grandi in natura, hai bisogno di sprint più lunghi (improbabile)
• Il team stima le storie in modo impreciso (incoerentemente)
• Il progetto ha molti debiti tecnologici / codice marcio marcio e la tua velocità è troppo bassa
• Non stai misurando e stimando la tua capacità di sprint correttamente (o per niente).

ecc ecc.

Dici che non lo finirai, ma non è male, sono solo dati.

"Incontra la sequenza temporale dello sprint" non è un obiettivo. Il tuo obiettivo è completare le storie degli utenti. La sequenza temporale è solo uno strumento che ti aiuta a misurare e imparare quanto lavoro puoi fare in uno sprint.

Se sei certo di non poter finire il lavoro nello sprint, una soluzione è spostarlo in fondo all'elenco delle priorità e lavorare prima sulle altre storie nello sprint. Quindi, con il tempo rimanente, puoi iniziare a lavorarci su. Rivalutare il lavoro andando allo sprint successivo e finirlo poi.

Assicurati nella tua retrospettiva di discutere cosa è andato storto in modo da poter migliorare le tue stime in futuro.

Se un'attività richiede più tempo del previsto, questa dovrebbe essere illustrata nella retrospettiva e discussa. Qualche pezzo mancava nelle prime analisi? Era qualcosa che non era già stato fatto spesso dal team? Ci sono molte possibili ragioni per cui qualcosa potrebbe richiedere più tempo di quanto inizialmente stimato.

Il team dovrebbe cercare di svolgere il compito nel miglior modo possibile e poi nella retrospettiva discutere delle strategie su questo in futuro. Se il team è abbastanza nuovo nell'uso di Scrum, potrebbe far parte del calcolo della velocità iniziale del team. Alcune squadre possono pensare di poter fare 20 punti e alcune squadre possono fare 60 punti, il punto è quanto può essere coerente lo stesso numero di punti ogni sprint.

Ciò accadrà in futuro poiché ogni volta che il team ha nuovi compiti che non ha svolto prima che ci sarà un po 'di tempo per elaborare i nodi di fare stime. Questo fa parte del processo di apprendimento che non dovrebbe essere così sorprendente.

Ciò che di solito facciamo nella nostra azienda quando un'attività inizia a richiedere più tempo del previsto è la divisione in attività più piccole.

In questo modo non diamo tutta la colpa allo sviluppatore per essere troppo lento, ma riconosciamo anche che l'attività è stata progettata in modo errato.

Un'altra cosa potrebbe essere quella di assegnare l'attività a un altro membro del tuo team di sviluppo per evitare che il tuo sviluppatore in ritardo si scava in un buco. E se l'attività è davvero critica, alcuni XP potrebbero essere la soluzione.