Fatto: All'inizio di ogni progetto il cliente chiede una data di consegna e i termini del contratto vengono decisi sopratutto sulla base delle stime fatte dagli sviluppatori.
E' quindi importante stimare minimizzando gli errori. Attualmente le tecniche di stima sono rozze e imprecise. Spesso si sottostima del 30% circa (dati calcolati su diversi team in diversi progetti).
Nel libro 'Agile Estimating and Planning' di Mike Cohn ne vengono citate alcune: Expert Opinion, Estimating by Analogy, Disaggregation, Planning Poker. Inoltre i team agili usano due principali unità di misura: stima in tempo ideale (al netto di impegni lavorativi extra-progetto) e in punti complessità.
Una mia ipotesi è che l'unità di misura usata influenza l'errore di stima con un fattore significativo. I punti complessità hanno molti vantaggi, ma dal punto di vista di minimizzare gli errori di stima in fase di analisi del progetto sono uno strumento assai impreciso.
La teoria psicologica è che l'uomo riesce a stimare meglio considerando le relative complessità. L'esempio classico riguarda la stazaz di alcune razze di cani: è difficile indovinare il peso ma è facile dire che un san bernardo è 4 volte piu grande di un bulldog.
Pur approvando intuitivamente tale ipotesi, penso che debba sempre essere verificata nel contesto applicato. Ad esempio quando faccio la spesa alla cassa 'indovino' la somma da pagare con un piccolissimo errore di stima, minore del 10% il piu delle volte. E nel mio processo non dico '1 kg di arancie costa 1.5 volte due etti di prosciutto crudo'. O ad esempio se devo indovinare il peso di una persona non penso a quanto è piu grossa o piu piccola rispetto a me.
Ma alla fin della fiera penso che qualsiasi strumento si usi per stimare si debba uscire dalla mentalità 'artistica' per dare un carattere scientifico. Propongo il seguente esperimento: avendo dei dati oggettivi, due gruppi separati usano l'unità di misura assoluta ideale oppure i punti complessità. Si valutano alla fine gli errori. Alcune persone si sentono a loro agio usando una unità di misura o l'altra, probabilmente è meglio che i gruppi si formino volontariamente.
Con questo esperimento oggettivo, dove i dati sono verificabili, penso si possano raggiungere conclusioni interessanti. Ad esempio potrei valutare la tecnica che un tempo ho usato, con particolare profitto, che prevede una suddivisione orizzontale, per layer tecnologici. Ogni user story attraversa diversi livelli tecnologici. Ad esempio:
- codifica del dominio applicativo in sorgenti java/ruby ...
- file di properties
- database
- chiamate a sistemi esterni
- test di accettazione
- deploy
- aggiornare il processo di build etc.
Ad esempio la prima carta avrà a che fare tipicamente con il setup dell'ambiente, con la creazione di script di build, un minimo di logica di dominio e un deploy sull'application server. Supponiamo di usare maven per la build, java per il dominio e jboss come application server. Poichè nulla è stato già implementato il costo sarà oggettivamente alto e fortemente dipendente dalla competenza in tutti e tre i layer.
Una analoga carta fatta dopo la prima release partirà da una situazione stabile, ed è probabile che lo sviluppatore abbia approfondito la conoscenza in almeno uno dei layer. Tenendo traccia dei layer attraversati e della tabella di competenza dello sviluppatore penso che si possa raggiungere una precisione di stima davvero ragguardevole.
Ovviamente senza un esperimento sono solamente fantasie.
Nessun commento:
Posta un commento