Nella mia organizzazione quando spostiamo un'attività nella colonna "Fine" scriviamo il numero di ore impiegato per completare l'attività. Può essere utile quando durante la retrospettiva il team cerca di capire perché alcune storie hanno richiesto più tempo dell'attuazione del previsto. Tuttavia è anche gravoso e gli sviluppatori si sentono un po 'micromanicati o stressati quando devono farlo.
Che cosa fai nei tuoi team? Cosa consiglia?
Non esiste alcun concetto di "tempo impiegato" in Scrum, semplicemente perché tutte le attività in Scrum sono raggruppate nel tempo (le storie sono raggruppate nel tempo all'interno di un'iterazione).
Esiste un concetto di "tempo rimasto", ma è utile solo per costruire un grafico di burn-down dello sprint attuale: non è un'indicazione del lavoro svolto in alcun modo (il tempo rimasto può salire, scendere o rimanere lo stesso anche se le persone stanno lavorando su un compito).
In altre parole: il tempo necessario per fare qualcosa non è un problema rilevante in Scrum. La velocità (punti per sprint) è invece interessante, ma l'obiettivo non è mai quello di aumentarlo. L'obiettivo è far muovere la squadra a un ritmo prevedibile.
Consiglierei di non registrare il tempo trascorso allora!
In primo luogo, queste metriche sono effettivamente utilizzate, o generalmente dicono "approssimativamente ciò che la stima ha detto"? Se le stime sono dappertutto, allora hai altri problemi. Se le stime sono precise al 90%, allora saprai quali compiti problematici hanno causato problemi e non è necessario registrare quelli che erano - la persona che ci lavora ci urlerà tranquillamente "Non darmi un altro compito come quello *** uno di nuovo "e si può discutere perché è stato così problematico:)
Il rendimento complessivo del lavoro è ciò che conta nei sistemi Agile, se la squadra sta facendo il lavoro, chi dà una figa quanto tempo ha impiegato ogni bit ?! (ok, lo so, alcuni tipi manageriali a ritenzione anale lo fanno. Devono rilassarsi e concentrarsi sul quadro più grande, non micromesticare ogni attività).
Non dimenticare - in definitiva i compiti sono un modo artificiale di dividere il lavoro in morsi facili da realizzare. La stima che viene loro assegnata è ugualmente artificiale. Ciò che conta è ciò che ottieni.
Non chiedo mai alle squadre di registrare il tempo effettivo impiegato per le attività. La mia esperienza mi insegna che non ha uno scopo utile. Ma sono anche consapevole che non è una decisione da parte dello Scrum Master.
Gli Scrum Teams si auto-organizzano e spetta a loro decidere se è utile registrare il tempo di attività effettivo. Se decidono di farlo, potrei indicare i problemi che penso possano sorgere, ma soprattutto, li lascio provare per loro stessi e retrospettivamente sul risultato.
Sono d'accordo con le altre risposte che dicono che il tempo di tracciamento per attività potrebbe non essere utile ai fini Scrum. (La velocità è meglio tracciata a intervalli di tempo di iterazione, non per storia o attività.)
Tuttavia, credo anche che lo sviluppo del software richieda disciplina. Ci sono cose che i programmatori professionisti dovrebbero fare anche se si sentono come un dolore, come inserire messaggi di commit utili in SCM, condividere dati regolarmente, recensioni di codici, ecc. Alcuni requisiti di lavoro non sono divertenti, ma devono ottenere fatto.
Quindi direi che torni alla tua squadra (o al management) e scopri se tracciare quel tempo è effettivamente vantaggioso. Se non lo è, sbarazzati di esso. Ma se lo è, la squadra ha bisogno di arrendersi e farlo. Cerca solo di capire come renderlo il più semplice possibile. (Sul mio team, usiamo JIRA per indicare a cosa sta lavorando ogni membro del team, quindi è abbastanza semplice registrare il tempo mentre procediamo.)
Come ha sottolineato Sklivvz, Scrum non ha il concetto di tempo rimasto sul singolo compito : nella mia esperienza, il monitoraggio del tempo di un singolo compito può stressare lo sviluppatore in modo strong (ricordo il mio ex-boss che mi diceva che avrebbe misurato anche l'ora della telefonata personale e dei minuti in toilette: |) e consideri gli eventi del contesto fuori controllo (ad esempio, la corruzione dei dischi rigidi della macchina di deposito e la perdita del codice (Sì , questo appesantisce:)).
Penso che il tempo impegnato sia un effetto di definizione di compito ; più il tempo è impegnato, più il compito ha qualche punto di grande sforzo o qualche evento problematico imprevedibile o non riproducibile nel contesto, fuori dal tuo controllo. Esco dai dati, perché? Difficile in algoritmico? In ritardo riceveranno i requisiti coerenti? Problemi con la configurazione dell'hardware? Hai perso tempo nel correggere vecchi bug che danno effetti in un nuovo sviluppo?
Secondo la mia esperienza, penso che sia meglio utilizzare alcune metriche standard (Function Point, complessità, ecc.) e vedere se l'attività rispetta i normali valori di questa metrica di troppa differenza.
È il compito aziendale ciò che determina il tempo di impegno, non il tempo che determina gli obiettivi di business del software.
Leggi altre domande sui tag scrum