#NoEstimates non significa “Non stimare”

Il secondo giorno del phpDay 2017 si è aperto con il keynote di Vasco Duarte.

Per chi non lo conoscesse, Vasco è un coach, uno speaker e un autore riconosciuto e apprezzato a livello internazionale nell’ambito delle metodologie agili.

Un paio di anni fa ho avuto l’occasione di leggere in anteprima il suo libro “No Estimates” e mi sono subito appassionato al tema. Al phpDay ho finalmente avuto l’opportunità di conoscerlo di persona e stringergli la mano.

Non oso immaginare cosa deve aver passato in questi anni; se volete avere una idea di cosa significhi “scatenare un flame” provate a scrivere un tweet usando l’hashtag #NoEstimates. Tutte le volte che l’ho fatto ho sollevato l’ira di alcuni project manager della vecchia guardia, secondo i quali tutto è predeterminabile e controllabile, meglio se con un Gantt chart.

D’accordo, ammetto che forse questo tweet è decisamente provocatorio:

Alcune risposte non vale nemmeno la pena riportarle, se siete curiosi potete cliccare qui e leggerle. Quelle meno insensate su cui vale la pena soffermarsi erano del tipo “certo, perché i gantt non esprimono l’incertezza, a differenza di questo o quel metodo”.

Sono d’accordo sul fatto che l’incertezza si possa esprimere.

Stimando possiamo tenere in considerazione l’incertezza; sarà capitato a molti di utilizzare la tecnica del “worst case/best case”: supponendo di stimare in ore/uomo, l’impegno viene rappresentato con una forbice che va da un numero minimo (best case) a un numero massimo (worst case) di ore che ipotizziamo siano richieste per l’implementazione. Al posto delle ore possiamo rimpiazzare giornate, story point o altro, il risultato è lo stesso.

Personalmente preferisco utilizzare la tecnica del planning poker (di cui ho già raccontato in questo articolo), che invece ci porta a raggiungere il consenso su un numero preciso.

Tanto il punto è un altro: quando stimiamo ci limitiamo a valutare la complicazione essenziale, vale a dire “quanto è difficile” implementare un dato requisito in un contesto ideale.

Il problema è che, per quella che è stata la mia esperienza in quasi vent’anni di lavoro in questo settore, un cliente non vuole solo sapere “quanto costa” un progetto ma anche “quando sarà consegnato”.

Affermare che per implementare un requisito occorrono, diciamo, cinque giornate/uomo non significa che, se inizio a lavorare domani mattina, dopo una settimana consegnerò il lavoro.

Infatti, calato in un contesto reale, un progetto è dominato dalla complicazione accidentale e questa, checché se ne dica e scriva, non è calcolabile con una formula matematica.

Per esprimerla con la Legge di Murphy, la complicazione accidentale è tutto quello che, potendo, andrà storto.

Per esprimerla più seriamente, la complicazione accidentale è l’insieme di tutti quei fattori che emergono soltanto dopo che si comincia a lavorare e che non sappiamo di non conoscere al momento della stima (i cosiddetti unknown unknowns).

Ecco alcuni esempi:

• specifiche che si rivelano incomplete o mal comprese: “ah ma davo per scontato che potendo esportare in formato XML avrei potuto anche esportare in PDF.”
  Ricordiamoci che comunichiamo utilizzando il linguaggio naturale che purtroppo è ambiguo, cioè soggetto a diverse interpretazioni; solo i linguaggi di programmazione non lo sono, con qualche rara eccezione (mi hanno detto di chiedere a un programmatore C++)
• specifiche che cambiano completamente nel giro di pochi giorni; figuriamoci quando passano mesi dall’analisi all’implementazione
• disallineamento tra le competenze: chi ha prodotto la stima non è la stessa persona che successivamente si occuperà dell’implementazione; non accade per forza intenzionalmente ma magari a causa di ripianificazione dettata da alcune delle circostanze sopra elencate o, ad esempio, del prolungarsi delle trattative commerciali
• debito tecnico
• necessità di integrarsi in maniera bloccante con uno o più fornitori terzi su cui non abbiamo il minimo controllo
• cause naturali: malattie, infortuni, trasferimenti, ferie, festività, eclissi di ADSL, ecc.
• e tanto, tanto, tanto altro

Ricapitolando: quando ci chiedono una stima ci stanno chiedendo due cose:

• quanto costerà?
• quanto tempo ci vorrà?

Si può riuscire a rispondere alla prima domanda specificando “per le informazioni che ho in questo momento il costo è X” sapendo che “questo momento” rappresenta un contesto ideale non più attuale nel momento stesso in cui pronunciamo quella frase, immaginiamoci dopo qualche settimana, se non qualche mese, dall’inizio dei lavori.

Ma è la risposta alla seconda domanda quella ancor più difficile, perché influenzata da fattori che non sappiamo di non conoscere (ricordate gli unknown unknowns).

Cosa c’entra tutto questo con “No Estimates”?

Il titolo del libro è provocatorio; “No Estimates” non significa che non si dovrebbe stimare ma piuttosto che non si dovrebbero basare decisioni di business su stime che non possono tener conto di tutti i fattori imprevedibili di cui sopra abbiamo elencato una minima parte.

Un esempio di decisione di business di questo tipo: definire le date della campagna di marketing per il lancio del nuovo sito e-commerce basandosi sulle date stimate di consegna.

Un altro esempio ancora più frequente: decidere il budget da allocare per il progetto.

La domanda reale da farsi, infatti, non dovrebbe essere “quanto costa il progetto?” ma “quanto vale?”.

Il software è, per definizione, adeguabile; il cliente può decidere di investire più o meno denaro a seconda del risultato che vuole raggiungere e quel risultato da raggiungere rappresenta il valore che si desidera ottenere (se volete una descrizione di cosa sia il valore vi consiglio questo video di Andrea Provaglio).

Salvo casi particolari, il cliente non dovrebbe spendere per il progetto più del valore che ne può ricavare; quanto vale (e, di conseguenza, quanto costa) non dovrebbe essere determinato esclusivamente dal fornitore ma quasi sempre è così.

Ricapitolando: oggi utilizziamo le stime per definire il costo di un progetto e una data di consegna; facendolo ignoriamo due aspetti fondamentali:

• il costo del progetto non dovrebbe superare il valore che questo consente di ottenere; aiutati dal cliente, dovremmo partire dal definire il valore e di conseguenza adeguare il costo perché sviluppiamo software che, per sua natura, è facilmente adeguabile alle esigenze del progetto
• il tempo impiegato è fortemente e imprevedibilmente influenzato dalla complicazione accidentale e fissare una data di calendario equivale a ignorare questo aspetto e a gettare le basi per fallire

A questo punto l’obiezione è nell’aria: nessun cliente si imbarcherebbe in un progetto senza sapere quanto costa e quando è previsto l’approdo.

È vero. È altrettanto vero però che il 70% dei progetti IT fallisce. E alcune delle cause le ho appena elencate.

Giro dunque l’obiezione: è preferibile definire tempi e costi sapendo che abbiamo il 70% di probabilità che quel tempo e quel denaro saranno completamente e irrecuperabilmente persi o è meglio avere il 100% di probabilità di non sprecare tempo e denaro spostando l’incertezza sui costi e sui tempi, fattori che, con il giusto approccio, possono essere misurati e controllati?

E qui sta il punto di ”No Estimates”: l’autore descrive come affrontare un progetto con un approccio che consenta di mantenere il controllo e di raggiungere l’approdo misurando i progressi; in questo modo le decisioni potranno essere basate su dati concreti e la rotta corretta man mano che si renderà necessario.

Magari alla fine si spenderanno più tempo e denaro del previsto ma il risultato sarà raggiunto e consegneremo valore.

Concludendo: stimare rimane ancora un’attività utile anzi fondamentale per definire orizzonti di budget e di tempo, avviare la discussione tra le parti e far emergere dettagli importanti; ma non è sulla stima che si dovrebbero scommettere le sorti del progetto.

È misurando i progressi e correggendo di volta in volta la rotta che potremo aumentare le probabilità di raggiungere l’approdo sani e salvi.

Crediti: la foto di copertina è di Ezra Jeffrey, rilasciata con licenza Creative Commons CC0.