Frustrante sul tracciamento del tempo

La tua azienda non sta seguendo pratiche agili standard.

Idealmente, non dovresti stimare in ore. Dovresti considerare di stimare in Story Points, che è una misura di quanto sia complesso il lavoro. Puoi quindi pianificare i tuoi Sprint in base a questi Story Points e alla Velocity (numero di Story Points completati) da alcuni dei tuoi Sprint precedenti più recenti. Se ti capita di finire il lavoro che hai iniziato, dovresti lavorare al prossimo passo.

La parte successiva è obbligatoria: la squadra di sviluppo dovrebbe essere quella che stima, in qualsiasi unità tu usi (ore o punti storia o qualcos'altro). Se sei tu a fare il lavoro, dovresti essere coinvolto nella stima. Infatti, tutti coloro che sono tenuti a completare la storia devono essere coinvolti nella stima per assicurarsi che la dimensione sia appropriata per la quantità stimata di lavoro.

Come qualcuno che lavora per un appaltatore, capisco la necessità di tenere traccia del tempo. Tuttavia, come ho detto sopra, di solito stimerai in Story Points invece di ore. In genere, una storia che vale più Story Points impiegherà più tempo a completare a causa dei vari fattori. Tuttavia, non esiste una relazione diretta tra i punti storia e le ore. Dovresti considerare il tempo di registrazione su un progetto o un'attività, non necessariamente su una Storia particolare.

Per risolvere questi problemi, è necessario innanzitutto lavorare su stime realistiche e utilizzare tali stime, insieme ai dati storici degli Sprint precedenti, per pianificare gli Sprint futuri. Il passo successivo consiste nel considerare il processo generale per assicurarsi che il team di sviluppo sia in grado di impegnarsi in una quantità ragionevole di lavoro per uno sprint e che, se il lavoro viene completato prima del previsto, tale lavoro aggiuntivo possa essere portato. Infine, le tue Sprint Retrospectives dovrebbero essere utilizzate per parlare di questi problemi e trovare metodi per risolverli.

Anche se sono d'accordo con la risposta di Thomas Owens, penso che questo abbia bisogno di una risposta più strong. Il processo che descrivi è completamente privo di alcune delle parti più importanti della gestione agile e queste sono le parti di cui i manager dovrebbero preoccuparsi di più. (completa divulgazione: sono un manager.)

Al fine di migliorare le previsioni su quando il lavoro sarà svolto, le stime dovrebbero essere fatte in relazione ad altri lavori che il team ha svolto in passato. Quindi vengono utilizzati dati empirici per prevedere quanto tempo impiegherà il lavoro. Questo può essere fatto usando metodi statistici di base e dato che ci sono più dati, l'immagine del throughput del lavoro (medie, varianza) diventa più chiara. I gestori dovrebbero anche essere in grado di rilevare le tendenze sul fatto che il throughput stia aumentando o diminuendo in modo statisticamente significativo.

L'altro problema qui è l'uso di ore. Ci sono alcuni grossi problemi con l'utilizzo delle ore come metrica:

1. Cos'è un'ora? È un'ora di codifica 'flusso'? Un'ora di cercare di debellare un errore di schiaffo e un 'ora'? Se valuti 8 ore al giorno, quando guardi la tua email? Cosa succede se aiuti il collaboratore per 30 minuti. Sottrai quella mezz'ora dalle tue ore del giorno? Come faccio a sapere che l'idea di uno sviluppatore di un'ora è la stessa e quella di un altro?
2. A chi importa quante ore ci vuole comunque? Qual è la precisione della scadenza? Sicuramente non è fino all'ora. Se qualcuno sta tentando di chiamare lo sviluppo così vicino, ha già fallito.
3. Nessuno sviluppatore sa quante ore (indipendentemente da come lo definisci) che serve per fare le cose. Hai mai notato che quando lo stai davvero schiacciando, alzi lo sguardo e il giorno è passato? Le menti degli umani succhiano il tempo di misurazione anche quando sono concentrate sul tentativo di farlo.

Io sostengo che la più piccola unità adeguata per prevedere lo sviluppo è un giorno. A meno che non lavori in una grotta (bunker, casinò), tutti possono essere d'accordo quando è trascorso un giorno. C'è questa grande sfera luminosa che passa sopra le nostre teste con sorprendente regolarità. Un argomento può essere presentato per settimane a seconda della situazione, ma sono meno uniformi (ad esempio vacanze e vacanze).

Non sto dicendo che le stime dovrebbero essere date in giorni (anche se, è un enorme miglioramento nel corso delle ore.) Sto dicendo che i giorni dovrebbero essere l'unità delle previsioni fatte da il manager . E per tornare al punto di partenza, quando il manager (o il supervisore) ha stimato in ore gli sviluppatori, di solito delegano il loro lavoro agli sviluppatori. E se tutto ciò che fanno è controllare se gli sviluppatori hanno raggiunto quella stima, queste stime sono peggio che inutili. Stanno interrompendo attivamente il processo di sviluppo occupando gli sviluppatori con un gioco BS e probabilmente abbassando la produttività aumentando i livelli di stress.

Questo è un problema comune a prescindere dal fatto che sia "appropriato agile" o meno.

Quello che dovresti fare è registrare 8 ore in totale rispetto all'attività principale su cui hai lavorato in un giorno, indipendentemente dal numero di ore effettivamente speso in esso o da altre attività.

Stima in giorni e moltiplicare per le ore richieste al giorno.

Arrotonda le tue stime fino al giorno più vicino. Di solito non ci sarà bisogno di padding in quanto più piccole attività di 1 giorno genereranno un tempo "extra" per le attività più grandi.

Ciò comporterà:

1: bei burn-down con bei grafici a gradiente costante.

2: felici project manager che possono costare tempo al progetto pertinente

3: programmatori felici con timesheet semplici.

4: leggermente superiore alla lunghezza stimata del progetto. potresti dover raggruppare piccole attività

Our boss requires us must to log at least 8 hours every day.

Questo sembra abbastanza semplice: se hai passato l'intera giornata a lavorare su un'attività, il tuo manager vorrebbe che tu registrassi 8 ore contro quell'attività. Se trascorri 1 / 4rds del giorno sull'attività A e il resto sull'attività B, l'attività A ottiene 2 ore, B 6 ore.

Come altri hanno sottolineato, questa non è una buona pratica agile, ma è ciò che il tuo manager ti ha chiesto di fare così, a meno che tu non sia nella posizione di cambiare completamente le tue pratiche lavorative, o dovresti accettarlo o cercarne un altro lavoro.

C'è comunque qualcosa che non si aggiunge ...

Our agile sprint lasts three weeks. Say 40*3 = 120 hours.
...
I am a quick problem solver, maybe I can use 40 hours to finish the project. After I finish my job, I can learn new technology related to the sprint project by myself.

Se ho capito bene, mi stai proponendo di dedicare 120 - 40 ore a.k.a 10 giorni di uno sprint di 15 giorni lavorativi su "tecnologia correlata al progetto sprint da solo".

Sebbene sia una buona idea prendersi del tempo per imparare e migliorare se stessi, i 2/3 dello sprint sono piuttosto eccessivi (per dirla in modo educato). Se hai terminato le attività sprint assegnate a te con 10 giorni di anticipo, aiuterai i tuoi compagni a completare le loro attività (e a registrare il tuo tempo con quelle attività).