ma il bonus aziendale è agile ?
Luca | September 17, 2006Nell’azienda in cui lavoro è stato introdotto da alcuni mesi un bonus per il team di sviluppo, con obiettivi molto precisi (non per niente siamo in Inghilterra 
) definiti su ogni singolo Sprint.
Dopo alcune iterazioni con questa novità mi sono fermato un attimo a riflettere sul concetto di bonus in un contesto agile, perchè nella mia testa c’era qualcosa che non tornava.
Quale è l’idea dietro un bonus ?
“lavora forte, raggiungi gli obiettivi fissati ed io ti riconosco lo sforzo con il bonus”
Questo, implicitamente spesso significa “l’obiettivo sarà alto, ma se tu fai tanti straordinari riuscirai a raggiungere l’obiettivo ed avere il bonus”.
Cosa dicono le metodologi agili ?
- Fai una stima accurata e fissa con il tuo cliente un obiettivo sensato, che puoi ragionevolmente garantire di raggiungere
- mantieni un ritmo di lavoro regolare, perchè se la tua stima e la conseguente pianficazione sono sensate non servirà fare strordinari anche perchè la qualità dle tuo lavoro scende quando aumenti le ore lavorative
Sotto quest’ottica, il bonus non è per niente agile!
Come provocazione è forse più agile un bonus rovesciato, dove non prendi una quantità X se fallisci gli obiettivi che il team in fase di painificazione in accordo con il cliente hai ragionevolmente fissato!
Sono piccoli dettagli, ma che dimostrano come una vera cultura agile è estremamente difficle da assimilare: non basta lavorare in iterazioni ed avere suite di test, bisogna profondamente capire cosa è effettivamente agile e cosa no…ed il bonus (secondo me) non lo è per niente.
Sicuramente in questa accezione il bonus è negativo (e nel
marcello | September 18, 2006Sicuramente in questa accezione il bonus è negativo (e nel 90% dei casi il bonus è questo)… potresti vederlo anche come il modo di apprezzare il lavoro dei propri dipendenti, ovvimante non dovrebbe essere legato al raggiungimento del singolo obiettivo ma alla continuità di risultati
ottimo il libro di mike cohn! avrei dato un'occhio per
simone genini | October 5, 2006ottimo il libro di mike cohn! avrei dato un’occhio per partecipare all’incontro di cui parli. (c:
la nostra esperienza…
abbiamo cominciato ad adottare le “stime a punti” dopo due anni di tentativi vari e – soprattutto – dopo aver letto “agile estimating and planning”.
siamo passati dai giorni perfetti, ai “giorni e basta”, alle mezze giornate, alle ore e alle mezz’ore (aka pomodori, per i task).
non siamo mai stati molto soddisfatti perchè il costo delle stime era sempre maggiore al vantaggio che ci portavano, soprattutto pensando anche alle loro fluttuazioni.
domande tipiche che ci ponevamo erano: “ma vale la pena buttare tutto questo tempo per delle stime non proprio usabili?”
da qualche tempo – come detto – valutiamo per difficoltà (o peso) che significano la stessa cosa per noi.
non “buttiamo” più molto tempo per le stime (non abbiamo più questa sensazione) e sembra funzionare meglio anche se mi sembra un po’ prematuro cantare vittoria, attenderei ancora un po’…
la cosa che mi fa pensare è questa:
il primissimo modo di stimare del quale ho letto anni fa era quello famoso degli “orsetti di gomma” (ora non ricordo più se era per le storie, per i task o per entrambi)
beh, non erano punti quelli? certo che lo erano… purtroppo – qui da noi – eravamo troppo giovani per capire esattamente a cosa potessero servire.
in effetti il mio rammarico è che abbiamo letto, provato, adattato, modificato… il tutto spendendo dei soldini… per arrivare al punto di partenza…
sarebbe ingiusto comunque dire che le due consapevolezze sono uguali; non si assomigliano proprio per niente, forse anche dato dal sudore che abbiamo versato per raggiungere la seconda però…
… si sarebbe probabilmente potuto risparmiare qualcosa con un po’ di fede in più e cercando di capire cosa significava prima di cercare nuove soluzioni.
per tornare in tema:
per il momento l’utilizzo dei punti soddisfa me (come manager), soddisfa gli sviluppatori e sono convinto che soddisferà pienamente anche il cliente che per il momento è *solamente* neutro (c:
noi li usiamo solo per le storie siccome abbiamo abolito i task (anche se esistono comunque come “lista di cose da fare in una storia”, non vengono però stimati).
se ti va ti faccio sapere se e quando cambio opinione… in meglio, in peggio non lo so ancora. so solo che succederà . (c;
ciao
simone
e certo che mi interessa sapere se cambi opinione!! e
Administrator | October 5, 2006e certo che mi interessa sapere se cambi opinione!! e soprattutto nel caso cambiaste modo di stimare…cosa vi ha spinto a cambiare!
[...] qualche giorno fa mi sono trovato sul blog di
Perchè non stimiamo più i task « Enri Blog | October 6, 2006[...] qualche giorno fa mi sono trovato sul blog di luca grulla e ho risposto ad un suo articolo riguardante la stima agile delle storie. poi luca mi ha mandato un email con le seguenti domande: “come siete passati da stimare i task a decidere di che non era più utile e stimare solo le storie ? quale è stato il passaggio che vi ha spinto in questa direzione ?“ [...]
Ciao Luca! Ho cambiato dominio, quello nuovo è: RED GREEN REFACTOR
Enri | November 10, 2006Ciao Luca!
Ho cambiato dominio, quello nuovo è:
RED GREEN REFACTOR IT!
Il blog su wordpress.com non lo utilizzerò più.
A presto!