Polymorphic Rants

L’altra sera sono andato al primo incontro dell’APLN London: speaker della serata Mike Cohn che ha parlato di stime e pianificazione; l’ospite non poteva non esser più gradito, dato che sto finendo il suo libro proprio su questo argomento.

Continuo a pensare che il concetto di stimare per dimensione e non per durata sia grande: cerchiamo di capire quanto lavoro siamo capaci di fare, il tempo è una grandezza secondaria che otteniamo dalla velocità del team.

Questo secondo me ha alcuni grandi vantaggi:

• sposta l’attenzione sul “fare”
• semplifica le stime
• ottieni una stima temporale data dalla velocità che è accurata per gli obiettivi del progetto (“quando finiamo ?”… a nessuno interessa sapere “quando è pronto il CRUD ?”)

Questo in realtà si scontra parzialmente con quanto affermato da Mike: lui ha detto di evitare di farsi guidare dalla velocità nella fase di planning ma di fare stime in ore reali dei task…io invece vorrei proprio uscire dalla stima dei singoli task in ore e passare ai punti pure su quelli!!

Usare ore reali per stimare i task e definire il lavoro di ogni iterazione ed usare punti e velocità per capire quante iterazioni servono per finire il progetto mi sembra riduttivo: al momento nel team di cui faccio parte stimiamo sempre in ore reali e francamente la cosa non mi sembra molto produttiva, perchè si hanno comunque delle fluttuazioni nelle stime che le rendono tutte inaccurate…se invece stimo che su una iterazione posso produrre 20 punti non mi preoccupo se per 10 di questi impiego 5 giorni e per i restanti 15! E’ ovvio che anche in questo caso si può ribattere che la stima non è perfetta, ma la pianificazione dell’iterazione è comunque funzionale !!

Mi piacerebbe dare una chance all’approccio appena descritto per capire se può funzionare (ovviamente io credo di si )
..ci sto provando da un pò ad introdurlo nel team, vediamo se in futuro vorremo provare.

Nell’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.

Sabato 30 settembre a Sarzana ci sarà Teknos, manifestazione incentrata sull’innovazione tecnologica. Se siete in zona fateci un salto!

il 6 e 7 ottobre sarò a CITCON, conferenza su continuous integration and testing. Se qualcuno è in zona batta un colpo che ci si incontra!