Ciao lista, ho un pensiero che mi ronza per la testa riguardo la
presunta
(in)utilit
di fare time-tracking delle attivit lavorative (incluse quelle per
produttivit personale).
Lo fate regolarmente? Vi utile? Se si, solo psicologicamente o poi
analizzate i dati raccolti?
Mi piacerebbe sapere cosa ne pensate, soprattutto se in contesti dove si
praticano metodi
agili dove l’argomento molto controverso (vedi ad esempio [1]).
Qui in Workshare (Londra) lo facciamo. In sintesi (sorry sono di fretta
oggi):
usiamo Kanban, circa 20 sviluppatori/QA suddivisi in tre team
ogni storia, quando “ingerita” da uno dei development team, viene
splittata in engineering tasks, stimati in quarti di giornate.
ogni membro del team fa l’accounting del suo tempo su ogni task,
inclusi
bugfix sulla storia stessa, con una biro sulla carta.
abbiamo una carta specifica periodica per bug causati da regressioni.
un team tracker si occupa di raccogliere i dati dai tre team e
inserirli
in un excel, che poi viene utlizzato per monitorare il progresso e per
stimare la data di shipment
In generale imho non fare tracking (e quindi non essere in grado di
stimare
con una certa precisione quando una certa feature sara’ consegnata) e’
un
po’ come scrivere codice senza TDD. Si puo’ fare, ma non e’
consigliabile.
Centro di genomica HSR (san Raffaele). Usiamo Asana per le task.
Utile per organizzarsi il lavoro. non lo stiamo usando per il time
tracking
dei singoli utenti (che ansia!) piuttosto per valutare lo stato di
completamento dei progetti.
Il 04/dic/2014 23:30 “Pietro Di Bello” [email protected] ha
scritto:
Anche noi facciamo da diverso tempo il tracking dell’effort sulla
maggior
parte dei nostri progetti, in modo simile a quanto racconta Bruno.
In particolare noi segniamo il tempo in “pomodori” (usiamo una versione
adattata al lavoro in team della tecnica del pomodoro http://pomodorotechnique.com/), segnando anche il tipo di pomodoro
speso
sul retro della user story o del task tecnico: C=code, R=refactoring,
E=exploration, I=integration, P=planning, O=other.
L’uso di questi dati molteplice: ad esempio teniamo traccia di come
spendiamo il tempo, se pi su attivit di coding o pi di refactoring o
magari di planning.
Questo ci consente di riflettere assieme su come stiamo lavorando avendo
dei dati oggettivi da portare nella discussione (es “nell’ultima
iterazione
abbiamo ridotto molto la percentuale di refactoring: secondo voi la
qualit
del codice ne sta risentendo?”).