Subtasking anticipato all'inizio di ogni sprint

Ho aderito a un nuovo team che utilizza Agile / Scrum e il loro processo di sviluppo è il seguente:

1) gli sviluppatori rivedono ogni storia prima di ogni sprint per assicurarsi che non manchi nulla di critico. C'è uno stato formale per questo nel flusso di lavoro.

2) durante il calcio d'inizio dello Sprint, l'intera squadra fa una stima (pianificazione del poker) su quanti punti della storia costerebbe ogni storia.

3) infine, immediatamente dopo l'inizio di ogni sprint, ogni sviluppatore è tenuto a scomporre avidamente tutte le storie assegnate in sottoattività con le stime del tempo (al contrario di sottoattività prima di iniziare ciascuna storia).

L'argomento principale per l'ultimo passaggio è che aiuta a scoprire se l'implementazione di una storia richiederebbe più tempo del previsto e avvisa il mastro scrum dei potenziali rischi di perdere le scadenze dello sprint.

Eppure lo trovo controproducente, principalmente per i seguenti motivi:

• se l'obiettivo è fornire una stima approssimativa, i punti della storia (fase 2) sono ciò che fa il lavoro. Altrimenti perché preoccuparsi dei punti della storia? - esegui subito il sub-tasking.
• se l'obiettivo è fornire stime accurate, questo è un chiaro esempio di ciò che è descritto in Human Task Switches Considered Harmful . Questo, penso, è particolarmente vero per i nuovi sviluppatori che si uniscono ai team esistenti in grandi progetti in cui la comprensione di ciò che deve essere fatto può richiedere fino al 50% del tempo. Ti viene richiesto di entrare nei dettagli della storia n. 1, quindi della storia n. 2, n. 3, ecc. Ecc. Che produce molte informazioni.

Mi viene anche detto che tale pratica è "dal libro" e non ho nemmeno intenzione di discuterne. Qualcuno può fornire un riferimento a tale pratica - se questo è chiaramente definito nelle Scrum Bibbie e / o forse fornire ulteriori spunti?

Questo non è dissimile dal modo in cui eseguiamo alcuni dei nostri processi di mischia. Noi

1. Stimare le storie nella parte superiore del backlog in "punti della storia"
2. Seleziona / spiega le storie in base ai punti della storia che riteniamo possano "compensare" lo sprint
3. Suddividere le storie in attività tecniche più dettagliate
4. Stimare le attività tecniche e confrontarle con la stima dei punti della storia originale (sappiamo approssimativamente quanto tempo di sviluppo equivale normalmente a un punto della trama)

Ma quello che vuoi sapere è perché stimiamo due volte!

• Facciamo una stima approssimativa (basata sulla storia) perché ci piace essere in grado di fare previsioni su ciò che potrebbe essere nel prossimo sprint, e forse anche quello successivo. In definitiva, il management deve essere in grado di comunicare con il cliente in merito a probabili scale temporali, quindi se non disponiamo di questa stima approssimativa, la pianificazione a lungo termine è praticamente impossibile.
• Ovviamente, questo significa che facciamo stime approssimative per qualcosa di più del semplice sprint corrente. Poiché non vi è alcuna garanzia che l'ordine di backlog non cambierà per il prossimo sprint, non vogliamo investire il tempo a fare ripartizioni delle attività e stime su vasta scala fino a quando non saranno necessarie.
• Suddividiamo il compito per assicurarci che tutti i compiti siano stati elencati e che le storie possano essere elaborate in parallelo più facilmente.
• Facciamo stime su larga scala (in base all'attività) perché ciò ci fornisce un grafico di burn-down molto più fluido (in particolare dove non esiste un modo semplice per dividere una grande storia in "funzionalità" praticabili).
• Poiché facciamo entrambi, agiscono come controlli di integrità l'uno sull'altro - una discrepanza selvaggia indica che abbiamo bisogno di un errore da qualche parte che dobbiamo identificare. Questo è un sottoprodotto utile, ma non il motivo in sé per cui stimiamo "due volte".

Rileggendo la tua domanda e commento, vedo che ci sono alcune differenze tra il nostro flusso di lavoro e il tuo.

• Facciamo guasti come una squadra , scopriamo che, sebbene il sovraccarico sia maggiore, la discussione tecnica che ne traggiamo è spesso molto preziosa e può rilevare carenze nella nostra storia. Quando abbiamo esperienza, conoscenza o disparità di capacità, questa discussione è anche quella in cui quelli con più possono aiutare quelli con meno (molto utile con i nuovi assunti).
• Facciamo stime a livello di attività come una squadra , uno dei motivi per cui "pianificare il poker" funziona a causa del fenomeno della "saggezza della folla" - come ho già detto nei commenti, a questo punto stimare un'attività dovrebbe richiedere meno di 30 secondi , quindi il sovraccarico è trascurabile.

Sembra che il motivo per cui il tuo team esegue le interruzioni delle attività e le stime delle attività è per un regolare burn-down - il che va bene, fa tutto parte del monitoraggio dello stato di avanzamento dello sprint e consente al tuo scrum master di rilevare e risolvere i problemi in anticipo. Se si desidera che queste informazioni si hanno a che fare i guasti e le stime e si hanno a che fare in primo luogo.

A mio avviso, il passaggio da un'attività all'altra non è probabilmente un problema per te qui, non penso che la suddivisione di attività diverse sia in realtà un cambio di attività nello stesso senso in cui passare da uno sviluppo a un altro a metà strada è un cambio di attività . Penso che acquisire una comprensione dell '"architettura" complessiva dello sprint sia probabilmente una cosa abbastanza utile.

Tuttavia, penso che potrebbero esserci altri problemi che potresti prendere in considerazione. Come sempre con Agile dovresti identificare un problema che hai e proporre una soluzione , quindi decidere se la soluzione ha funzionato nella retrospettiva . Questo è il nocciolo della costruzione di una soluzione agile che funzioni per la tua azienda e il tuo team. Quindi, alcuni problemi che potresti avere:

• Stai effettuando guasti individualmente, quindi in che modo i membri del tuo team junior / inesperti imparano dai membri del tuo team senior? Certo, probabilmente potranno imparare tutto da soli - ma impareranno più velocemente se sono guidati. I membri del team junior impiegano molto tempo per scomporre le cose? Stanno commettendo errori o cose mancanti che costano il tempo della squadra nel lungo periodo? Abbattere come una squadra può aiutare qui.
• Stai facendo stime individualmente - lo stesso vale per il primo punto, ma in più queste stime sono meno accurate di quanto potrebbero essere?
• Sembra che i compiti siano assegnati all'inizio dello sprint, ma se questo è il caso allora quanto costa trovarlo quando devi cambiare l'incarico? Se qualcuno è in ritardo o malato, quanto è facile per qualcun altro raccogliere i propri compiti? Devono passare attraverso le ripartizioni delle attività e cercare di capirle senza interrompere l'assegnatario originale? Se fallisci e fai una stima come squadra, allora tutti dovrebbero essere in grado di lavorare su tutto!
• Le tue storie sono troppo grandi? Se la scomposizione richiede il 50% delle volte, le storie sembrano molto coinvolte - forse possono essere ridotte? Conserviamo le nostre storie entro 1 settimana lavorativa.
• I tuoi compiti sono troppo piccoli? Se stai impiegando molto tempo a creare elenchi di attività, forse stai entrando in troppi dettagli? Tendiamo ad avere compiti tra 1 e 8 ore di lavoro in modo tale che nel corso della giornata tutti facciano progressi per riferire al prossimo standup giornaliero.

Se è così che la tua azienda vuole gestire il proprio sviluppo e interrompere la discussione, le tue scelte sono limitate o almeno corri il rischio di turbare le persone.

Dato che l'obiettivo finale di Agile è lavorare con software di valore, potresti provare a offrirti di aiuto misurando la capacità del tuo team di consegnare (punti consegnati / stimati, bug nello sprint, numero di test, copertura del codice, tempo di attività, vendite generate - qualunque cosa). Preparati a tutti i risultati - può darsi che questo modo di lavorare funzioni per loro anche se non ha senso per te. Se hai ragione, i rifiuti diventeranno evidenti.

Diffidare di seguire il processo per amor di processo - questo fa perdere tempo e offre ancora prodotti scadenti. Un buon team agile sperimenta, misura e impara. Il modo migliore per cambiare comportamento senza scendere a opinioni è con decisioni basate sull'evidenza.

Questa è anche la mia opinione. Ti suggerisco di provare da solo e misurare il risultato - guarda cosa ho fatto lì :)

Suppongo che il tuo Sprint Kickoff significhi l'incontro di Sprint Planning. Penso che il tuo Scrum Master abbia frainteso come dovrebbe andare questo incontro. Non solo decidi su quali storie sviluppare, ma le metti anche alla prova con il team per definirle pronte per assicurarsi che non perdano nulla (di solito usando INVEST ) e suddividi tali storie in attività. Per citare Mike Cohn (uno dei fondatori della Scrum Alliance);

Il backlog dello sprint è l'altro output della pianificazione dello sprint. Un backlog di sprint è un elenco degli articoli di backlog di prodotto che il team si impegna a consegnare più l'elenco delle attività necessarie per consegnare quegli articoli di backlog di prodotto. Di solito viene stimata anche ogni attività nel backlog dello sprint.

Quindi la scomposizione delle storie e la loro stima fa parte della sessione di Sprint Planning; non dopo che la sessione di pianificazione è terminata e non individualmente.

Per fornire ulteriori informazioni, il nostro flusso di lavoro durante la riunione di Sprint Planning è il seguente:

1. prendiamo una storia dalla cima del backlog del prodotto e la dividiamo in attività. Come regola generale, un'attività dovrebbe essere generalmente più piccola di un giorno.

2. Stimiamo la storia dati i compiti che abbiamo dedotto. Se la storia diventa grande, proviamo a dividere la storia in storie più piccole.

3. Risciacquare e ripetere fino a raggiungere il totale dei punti stimati

Contrariamente a quanto afferma Cohn, ho scoperto che non è necessario stimare separatamente ciascuna attività, poiché le attività sono specificate per essere più piccole di un giorno. Dato che le attività sono inferiori a un giorno di lavoro, è possibile notare facilmente durante lo Standup giornaliero quando un'attività richiede più tempo del previsto, poiché la persona che lavora sull'attività specifica dirà che ci sta ancora lavorando.

Durante lo sprint la squadra si fa strada attraverso le storie e alla fine la squadra dovrebbe riflettere su quanto effettivamente è stato fatto. Questo è lo scopo dell'incontro retrospettivo sulla mischia. Se ci sono ancora storie sul tavolo, puoi dedurre che la tua stima era troppo ottimista e agire su di essa per il prossimo sprint. In alternativa, potrebbero essersi verificati alcuni incidenti che incidono su quanto è stato fatto, ecc. Scoprirai che le stime miglioreranno nel tempo quando rifletti su di esse.

"dal libro" - questo è il tuo problema. Stai affogando in un processo maggiore di quello che avresti avuto se stessi lavorando cascate.

Non esiste un "libro" per Agile, c'è solo il manifesto agile che dice "fai cose senza spese generali". Quindi, se stai valutando le dimensioni e poi suddividendo le storie in attività per rivalutarle, allora è un sovraccarico di processo inutile che deve essere reso più efficiente - questo è ciò di cui è agile. Scrum e tutti gli altri sono in realtà le linee guida del punto di partenza per come iniziare a fare agile. Mentre lo fai, dovresti identificare questi punti che non hanno senso o non aiutare il tuo team a lavorare in modo più efficace e dovresti cambiarli.

Tuttavia, alcune persone pensano che i modi di lavorare proibiti debbano essere scritti nella pietra e da cui non deviano mai, non importa quanto stupidi diventino. Vorrei provare a dividere le storie in attività prima della riunione della mischia: tu dici che gli sviluppatori sono tenuti a rivedere ogni storia, beh, ecco la possibilità di fare la scissione contemporaneamente alla parte della recensione. Quindi puoi dichiarare i compiti che compongono la storia nella riunione della mischia (non dedicare loro tempo!) E lasciare che le persone decidano quanto è grande il pacchetto di lavoro della storia, sulla base di queste informazioni aggiuntive contenute (che non è mai una cosa negativa, il processo decisionale informato è molto meglio delle congetture, e si può fare solo quando si hanno informazioni da inserire nel processo decisionale).

Dopo l'incontro, puoi ancora assegnare i tempi alle attività (anche se non riesco a vedere il punto di ciò, gli sprint non si basano sul tempo, sono basati su "quante cose ti aspetti di fare" che si misura nei punti della storia , non il tempo. Questo è un problema comune con la mischia, i punti non significano tempo ma devi completare, diciamo, 20 punti per quindici giorni quindi 2 punti = 1 giorno di lavoro. Dovrebbe essere una rapida ipotesi su quanti compiti mettere nello sprint in modo da non essere né sovraccaricato né sottoutilizzato, non quanti ne verranno effettivamente eseguiti. I migliori sprint sono quelli che hanno lasciato un paio di compiti, il che mostra che si è stimato perfettamente. ritardato completandoli alla fine - nessuno dei due è produttivo).

Quindi, in breve, stampa una copia del Manifesto Agile e la versione anti-agile . Scommetto che stai facendo più anti che agile. Scrum tende ad essere così. L'unico modo per risolverlo è interagire con il tuo team e ottenere il buy-in per il cambiamento. Non lasciare che la direzione ti dica come deve lavorare il tuo team, che non è nemmeno agile e che sarà scritto nel Libro.

Ad un certo punto durante ogni Sprint, dovresti avere una Riunione di perfezionamento del portafoglio ordini . In questa riunione, ti assicuri che la parte superiore del portafoglio ordini del prodotto sia suddivisa in modo sufficiente per gli articoli in quella parte da aggiungere al successivo registro sprint.

Se il perfezionamento del portafoglio ordini è gestito correttamente, la riunione di pianificazione Sprint può essere più efficiente. Idealmente, ciò eviterebbe la necessità per gli sviluppatori di "scomporre avidamente" le storie dopo l'avvio dello Sprint.

Se gli articoli Backlog prodotto vengono aggiunti allo Sprint Backlog prima di essere sufficientemente suddivisi per stimare realisticamente, ciò renderà difficile prendere buone decisioni su cosa aggiungere allo Sprint.