Il nostro cervello è una macchina di previsione. Perché è così? perché attraverso la previsione crea una sensazione di fiducia e certezza. Alcuni studi affermano che il nostro cervello riserva tra il 60% – 80% delle sue energie per l’attività di previsione [1]. Per questo motivo ci piace la pianificazione e naturalmente stimare. Perché tramite  questi strumenti possiamo aumentare il livello di prevedibilità.

Se accettiamo che stimare fa parte di un comportamento normale di una persona e/o di un team di lavoro, allora perché alcuni sono contrari e perché nascono i movimenti come #NoEstimates.

Per avere l’idea su questo movimento, vi invito a guardare questi video:

In breve, #NoEstimates fornisce i tre motivi per non stimare :

• Una stima accurata è impossibile;
• Le stime possono mettere una pressione inutile e improduttiva sul team;
• La stima è uno spreco di tempo, quindi meglio spendere meno tempo possibile.

Negli ultimi anni in particolare nel settore dello sviluppo di software questo pensiero di non stimare ha suscitato diversi reazioni. Nell’articolo “The #NoEstimates movement is a pointless infatuation” Maarten Dalmijn risponde alle perplessità e racconta la sua esperienza personale al riguardo.

Ma quali sono i principali motivi che ci spingono a fare una stima?

1. Determinare in ordine di grandezza la dimensione e il costo del progetto/task per avere un’idea approssimativa allo scopo di pianificare l’attività.
2. Dare un feedback al cliente in termini di tempo. Quindi abbiamo una deadline da rispettare.
3. Decidere di allocare le risorse per un determinato tempo.
4. Qualcuno vuole sapere a chi dare la colpa.

Fare la stima non è un’attività semplice, spesso quando dobbiamo rispondere alla domanda “Quanto ci metti per finire questo lavoro?”  Ti passano per la testa mille cose e vorresti rispondere:  “dipende!”. Tu che pensi sei in trappola e l’altra parte che vuole in qualche modo ottenere una data di rilascio.

Forse il problema non è proprio il fatto di stimare. Si tratta di avere  due prospetti diversi su un argomento dove entrambe le parti, in modo indipendente, potrebbero aver ragione.

Tu, per fare la stima pensi a giornate ideali e parti dal presupposto che  non ci saranno i lavori urgenti che interrompono l’attività, che i requisiti non cambiano, non ci saranno complicazioni insomma totale focus sull’attività da fare. Dall’altra parte c’è il responsabile, che considera le giornate di calendario e per la sua esigenza  pretende di avere una stima accurata, certificato al 100%

A questo punto come si può conciliare questi due punti di vista?

Mi sembra che l’anello mancante è capire l’obiettivo di stimare e creare una visione condivisa rispetto al problema e alla soluzione. Allo scopo di stimare, potrebbe essere d’aiuto tenere in considerazione due macro categorie:

1. l’attività con maggiore conoscenza in termini di requisiti, documentazione, tecnici etc;
2. l’attività con livello di conoscenza medio.

Per la prima categoria, potremmo parlare di Misurare l’attività piuttosto che stimare, perché il livello di conoscenza è abbastanza alta e mettendo in conto le esperienze simili avute nel passato possiamo utilizzare l’unità assoluta come uomo/giorno oppure uomo/ora per misurare un’attività.

Mentre la seconda categoria è il classico caso di incertezza. In questi casi forse è utile fare una stima relativa all’inizio dell’attività/progetto utilizzando le esperienze passate e coinvolgere gli esperti con un vincolo. Si comincia a realizzare la soluzione con l’impegno di aggiornare la stima iniziale.

Le metodologie di project management offrono diverse tecniche per le stime del progetto. Prendendo in considerazione il mondo Agile ed in particolare lo Scrum. Noi abbiamo il  Product Backlog che è un elenco ordinato di funzionalità che si intende sviluppare e può contenere anche altri elementi come i bug, tech task e compiti tecnici.

In particolare, gli elementi di funzionalità del prodotto vengono inseriti in Product Backlog sotto forma le User Story  ovvero una breve e semplice descrizione della funzionalità che si vorrebbe avere raccontata dal punto di vista dell’utente. Lo Scrum Team attraverso la definition of ready (DoR) perfeziona le User Story affinché queste ultime vengano incluse nello Sprint Backlog, in alcuni team tra vari elementi della definition of ready includono anche la stima di lavoro da fare .

Stimare User Story

Mike Cohn nel suo libro “Agile Estimating and Planning” suggerisce l’uso degli story point come l’unità di misura  per stimare le User Story.

Attraverso Story Point, noi intendiamo fare una valutazione sulla grandezza e sulla complessità di implementazione di una User Story rispetto ad un’altra.

Per sapere meglio come Story Point funziona vi suggerisco di guardare questi due video:

Io penso che questa tecnica è molto utile perché coinvolge tutto il team e favorisce una stima “collegiale”. Inoltre, la nostra mente funziona meglio con il sistema di relatività  cioè avendo un punto di riferimento possiamo esprimerci meglio.

Invece, quando ogni membro del team deve seguire un task sarebbe meglio utilizzare l’unità di misura uomo/ore oppure uomo/giorno perché un task viene seguito da una persona e quest’ultima a seconda della sua esperienza e le sue skills potrebbe stimare il lavoro da fare.

Conclusioni

Stima è un elemento importante del progetto. Personalmente, penso che una valutazione esatta al 100% del tempo non sia sempre possibile e si cerca di farla più accurata possibile.

A seconda della situazione ci dobbiamo chiedere:

• Nella stima quanto vogliamo essere accurati?
• Quanto conosciamo l’attività da fare?
• Quanto tempo vogliamo dedicare alla stima e se dedichiamo troppo tempo il risultato sarà soddisfacente?

Però In realtà per tanti team, la vera sfida è quella di stimare un’attività nuova per la quale non hanno proprio conoscenza e l’idea.

Tu cosa ne pensi? Che tecnica utilizzi per fare la stima? commenta questo post e se il contenuto  ti è piaciuto condividilo con altre persone.

[1] Read Your Passions