Evidence Based Scheduling
Joel Spolsky ha scritto un interessante articolo sulle modalità con cui vengono stimati e poi tracciati i tempi di scrittura del software nella sua azienda (Fog Creek Software). L'articolo merita una lettura approfondita perché i principi applicati sono pienamente attuabili anche nella realtà italiana (talvolta ho citato altri suoi articoli in cui alcune cose andavano adattate alla nostra realtà, in questo caso direi di no).
Va detto subito che la metodologia descritta è anche inserita nelle funzionalità di un prodotto che questa azienda produce e vende, ma riflettere su tali concetti in maniera oggettiva non è tempo perso.
I concetti "rivoluzionari" (rispetto alla media con cui molti operano) sono:
- Definire task in termini di ore e non avere task con più di 16 ore.
- Misurare il tempo speso per i task (includendo eventuali "distrazioni", come la chiacchierata con il capo-progetto e la telefonata inaspettata)
- Simulare il futuro utilizzando il rapporto di ore stimate/effettive per creare scenari statistici con simulazioni Monte Carlo.
- Richiedere ai programmatori di fare le stime e non ai loro capi
- Mantenere le informazioni e le stime separate (e quindi personalizzate) per programmatore.
- Includere nei costi della feature il tempo speso a correggere i bug - senza allocare tempi preventivi per il "debugging" generico.
A mio parere la metodologia è scientifica e chiara, non è così semplice da applicare per abitudine, mentalità e definizione dei ruoli all'interno di un team, certo non per una complessità che non c'è. Se avete altre opinioni, o se qualcuno già usa una metodologia simile, sarebbe interessante avere qualche opinione.