Nella mia azienda, un singolo compito non può mai essere completato da un individuo. Ci sarà una persona separata per il controllo qualità e la revisione del codice per ogni attività. Ciò significa che ogni individuo fornirà le proprie stime, per attività, su quanto tempo ci vorrà per completare.

Il problema è, come dovrei avvicinarmi al burn-down? Se aggrego le ore insieme, assumiamo la seguente stima:

10 ore - Tempo di sviluppo

4 ore - QA

4 ore - Revisione del codice.

Stima dell'attività = 18 ore

Alla fine di ogni giorno chiedo che l'attività venga aggiornata con "quanto tempo rimane fino a quando non viene eseguita". Tuttavia, ogni persona in genere pensa solo alla propria parte. Dovrebbero contrassegnare lo sforzo rimanente e quindi AGGIUNGERE le stime dello sforzo a quello? Come state ragazzi?

AGGIORNARE

Per chiarire alcune cose, nella mia organizzazione ogni compito all'interno di una storia richiede 3 persone.

1. Qualcuno per sviluppare l'attività. (fare unit test, ect ...)
2. Uno specialista di QA per rivedere l'attività (eseguono principalmente test di integrazione e regressione)
3. Un vantaggio tecnico per fare la revisione del codice.

Non penso che ci sia un modo sbagliato o giusto, ma questo è il nostro modo ... e questo non cambierà. Lavoriamo come una squadra per completare anche il più piccolo livello di una storia quando possibile. Non puoi effettivamente testare se qualcosa funziona fino a quando non è completo, e non puoi nemmeno rivedere la qualità del codice ... quindi il meglio che puoi fare è dividere le cose in piccole porzioni logiche in modo da poter testare la minima funzionalità minima e revisionato il prima possibile nel processo.

La mia domanda a coloro che lavorano in questo modo sarebbe come bruciare un "compito" quando sono impostati in questo modo. A meno che un'attività non abbia le sue attività secondarie (che JIRA non consente) ... Non sono sicuro del modo migliore per eseguire il monitoraggio di "ciò che resta" su base giornaliera.

Sono 3 compiti, non uno.

Potrebbe essere una caratteristica / storia, ma è tre compiti. Una singola attività può essere completata da una sola persona a tempo finito.

TL; DR

Stai utilizzando il burn-down in modo errato in diversi modi. Compiti e storie sono fatti o non fatti; provando a tracciare le deviazioni dalle stime di pianificazione basate sul tempo nel tuo burn-down, stai effettivamente rivalutando il tuo programma piuttosto che stimare il lavoro residuo prodotto.

In Scrum, dovresti misurare i progressi verso un obiettivo Sprint piuttosto che misurare la fascia oraria dello Sprint. Ciò mantiene l'attenzione sulla capacità del team e sull'erogazione delle funzionalità piuttosto che sulle continue regolazioni della pianificazione.

Compiti contro storie

Stai combinando compiti e storie. Le storie comprendono tutti i compiti necessari per completare la storia secondo la "definizione di fatto" della tua squadra. La storia è considerata incompleta al 100% a meno che tutti i suoi compiti non siano completi. In Scrum, le storie sono sempre stimate in qualche modo; più frequentemente, sono stimati in punti della storia.

I compiti sono i passaggi o le pietre miliari necessari per completare la storia. Sebbene ogni attività possa avere dipendenze e prerequisiti, puoi certamente dire che la revisione del codice è completa o meno, indipendentemente dalle altre attività.

Bruciare

In Scrum, il tuo grafico di burn-down mostra la quantità di lavoro rimanente per lo sprint o il progetto. I grafici di burn-down reali hanno spesso plateau; in alcuni casi, il grafico può persino aumentare. Ad esempio, in uno sprint di una settimana con due storie del valore di 3 e 5 punti, i tuoi punti dati potrebbero essere simili a questi:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

In questo scenario idealistico, inizi con 8 punti trama. La storia in 3 punti è stata completata martedì pomeriggio, mentre la storia in 5 punti non è stata completata fino a venerdì. I punti della storia non vengono dedotti dal rogo fino a quando la storia non ha soddisfatto la definizione di fatto. Se stai usando le ore ideali anziché i punti della storia, l'unica cosa che cambia è la tua scala.

Time-Boxing

La pratica generalmente accettata è quella di garantire che i compiti siano scomposti in blocchi di dimensioni pari a un morso tra 1/2 giorno e 2 giorni. La varianza di più di un giorno dovrebbe essere evidente dagli stand-up quotidiani o dallo Sprint Backlog; non dovrebbe essere necessario eseguire un pull formale dello status.

Puoi anche eseguire analisi statistiche sul grafico di burn-down per determinare se lo sprint sta andando correttamente. Piccole deviazioni o plateau sono normali, ma se nessuno sta alzando i bloccanti negli stand-up quotidiani ma il tuo burn-down sembra bloccato, questo è generalmente un segno che lo Sprint Backlog è stato mis-stimato o c'è "lavoro invisibile" che deve essere reso esplicito nel processo.

Puoi definire l'attività di sviluppo come "completata" prima che il QA faccia la sua parte? Puoi definire la revisione del codice come "completata" prima che lo sviluppo sia completato? Il QA può essere "eseguito" se lo sviluppo e la revisione del codice non lo sono?

Direi che dovresti aggregare i tre elementi in un unico compito e le tre persone dovrebbero lavorare insieme su di esso.

Scrum NON afferma che qualsiasi articolo è responsabilità di un membro del team. Al contrario, gli elementi del registro sprint sono a carico del TEAM. Se sono necessarie tre persone per eseguire un'attività, questo è quello che serve.

Non importa Finché è relativamente coerente tra le storie, il tuo grafico di burndown funzionerà comunque in entrambi i modi. Usa il modo più naturale per il tuo team di segnalare.

La mia squadra in realtà fa una sorta di ibrido, sebbene non per accordo formale. Diamo 16 ore se pensiamo che un'attività richiederà una persona due giorni, ma se due persone finiscono per lavorarci insieme, non la cambiamo.

Dopo la stima iniziale, diventa informalmente completa per il nostro team più di una percentuale di un'ora rimanente. Se inizialmente pensavamo che ci sarebbero voluti due giorni, ma dopo un giorno, pensiamo che sia completo solo per il 25%, prendiamo 4 delle 16 ore originali. Questo lascia 12 ore in cui tecnicamente stiamo stimando 24, perché probabilmente dedurremo 4 ore per i restanti 3 giorni.

All'inizio mi ha infastidito come scrum master, ma a quanto pare strano, è un modo molto naturale di fornire stime, perché gli sviluppatori odiano davvero aggiungere ore a una stima. Tutto fa una media per rendere il burndown ancora utile, ed è quello che è importante.

Il tempo rimanente del compito non conta molto: nulla può essere consegnato fino a quando l'intera storia non è terminata.

Se vuoi tenere traccia di quanto tempo rimane su una storia (in generale) facendo in modo che le persone riempiano il tempo rimanente sulle attività, quindi dividi le attività per persona.

Detto ciò:

• Grandi compiti potrebbero essere un'indicazione che le tue storie sono troppo grandi. In questo caso, la soluzione migliore è ridurre l'ambito e le dimensioni delle storie e, se lo riduci abbastanza, tenere traccia del tempo rimanente sulle attività non ha più importanza (sono completate o meno - somma del preventivo sulle attività non completate è abbastanza granulare).
• SCRUM incoraggia tutti a raccogliere ciò che deve essere fatto. Se stai assegnando compiti alle persone (al contrario dei ruoli), allora potenzialmente stai impedendo di consegnare una storia, anche se lo sviluppatore non sta facendo nulla - perché il QA è un collo di bottiglia.

Dividi l'attività in più attività e inseriscile come attività in cui ciascuna è gestita da una persona diversa.

Attività originale: correggere qualcosa

Nuove attività: (figlio del genitore dell'attività originale)

• Dev A - Risolvere il problema
• Dev B - Aiutare Dev A a risolvere il problema (ad es. Programmazione di coppie, revisione del codice)
• Dev A - dev test della correzione usando Dataset X
• Dev B - dev test della correzione utilizzando il set di dati Y