Come stimare il costo di un progetto

Introduzione

Stando al dizionario, una stima è la valutazione approssimativa della misura di qualcosa in termini di dimensioni, peso, quantità, costo o durata.

Trattandosi di una valutazione a priori di qualcosa che non si conosce ancora, va da sé che una stima, per sua stessa definizione, non può essere considerata una misura accurata e realmente attendibile.

Ciononostante, ci viene chiesto spesso di fornire “la stima corretta” per lo sviluppo di un progetto, possibilmente in tempi brevi (perché le gare non aspettano) e, come se non bastasse, senza una visione chiara del contesto.

Perché le stime non funzionano

Prima di presentare il nostro approccio al calcolo del costo di un progetto, è necessario porre l’attenzione sui due aspetti principali che minano l’attendibilità di una stima:

• Complicazione accidentale
• Ciò che non sappiamo di non sapere

Complicazione accidentale

Nel suo celebre video “7 Minutes, 26 Seconds, and the Fundamental Theorem of Agile Software Development”, J. B. Rainsberger ci mostra come il costo di un requisito sia esprimibile come la somma del costo della complicazione essenziale con quello della complicazione accidentale.

La complicazione essenziale è dovuta alla difficoltà intrinseca del problema da risolvere. Grazie all’esperienza, che ci consente di confrontare i problemi nuovi con quelli già risolti in passato, è possibile stimare la complicazione essenziale con un buon grado di approssimazione.

La complicazione accidentale è invece dovuta al fatto che non sempre siamo così diligenti nel risolvere i problemi. Essa scaturisce dagli errori di design del sistema; dal disordine che lasciamo in giro nel codice perché non ci prendiamo il tempo di re-fattorizzare; dalla complessità che si genera dai membri che aggiungiamo al gruppo di lavoro (perché ci dimentichiamo che nove donne non possono fare un figlio in un mese).

Come è facile intuire, la lista è lunga e la striscia di Jason Heeris che segue è solo un altro emblematico esempio di complicazione accidentale:

Poiché il costo della complicazione accidentale sovrasta quello della complicazione essenziale, un modo per aumentare l’affidabilità della stima del costo totale di sviluppo consiste nel ridurre il più possibile i fattori che accrescono la complicazione accidentale.

Ciò che non sappiamo di non sapere

Un altro aspetto che incide negativamente sull’attendibilità delle nostre stime è l’attitudine a ignorare ciò che è fuori dal contesto in esame.

È senza dubbio molto più semplice concentrarsi su ciò che sappiamo di non conoscere.

Facciamo un esempio: un cliente ci chiede di integrare funzionalità di marketing automation nel suo sito e-commerce. La specifica è senza dubbio vaga ma il contesto è noto e analizzandolo possiamo far emergere i dettagli utili a produrre una stima.

Ecco di seguito un altro esempio di qualcosa che non sappiamo di non sapere; probabilmente suonerà familiare: durante lo sviluppo di un progetto su Magento  viene rilasciata una patch di sicurezza che rompe l’integrazione con il sistema di marketing automation.

Un simile evento non è prevedibile, dal momento che non ha nulla a che fare con il dominio su cui ci siamo concentrati (l’integrazione con il sistema di marketing automation). Stiamo pur certi che ogni minuto speso per installare la patch e sistemare ciò che è andato rotto non fa parte della nostra stima iniziale.

Potremmo andare avanti ad elencare tutti gli eventi improbabili che possono accadere, i cosiddetti cigni neri che cambiano le regole del gioco e mandano in fumo le stime iniziali. Ma la lista, per quanto dettagliata, risulterebbe comunque incompleta, perché l’incertezza trova sempre il modo di farsi strada nel progetto in maniera creativa e imprevedibile.

Come stimare il costo di un un progetto

Come abbiamo visto, per calcolare il costo di un progetto non basta considerare la sola complicazione essenziale ma anche la complicazione accidentale e l’incertezza.

Per poter produrre una stima di costo quanto più attendibile possibile, possiamo provare ad applicare le seguenti regole:

• Raggiungere il consenso sulla complicazione essenziale
• Fare del nostro meglio per ridurre la complicazione accidentale
• Predisporsi al cambiamento

Raggiungere il consenso sulla complicazione essenziale

Generalmente siamo abbastanza bravi a stimare la complicazione essenziale: potendo contare sulla nostra abilità nel trovare somiglianze, l’esperienza passata ci aiuta a pesare il costo dei requisiti.

Procediamo dunque con elencare tutti i requisiti; possiamo scegliere un qualsiasi formalismo ma il mio consiglio è di utilizzare le user story. Il principale vantaggio di tale formalismo è, infatti, quello di focalizzarsi sullo scopo, cioè sul perché dobbiamo implementare un determinato requisito.

Il passo successivo consiste nel radunare il team che si occuperà di realizzare i requisiti. Utilizzo volutamente il termine generico team e non sviluppatori perché un requisito non consiste soltanto di sviluppo software. Idealmente anche il cliente dovrebbe partecipare all’attività di stima, per poter fornire i dettagli necessari durante la discussione che ne nasce (ma anche per rendersi conto di quanto sia realmente complicato sviluppare il suo prodotto).

Il team dovrà stimare l’impegno richiesto dallo sviluppo di ciascun requisito.

Possiamo misurare l’impegno in ore-uomo, giornate-uomo, story point, banane o qualunque altra unità di misura che ci consenta di confrontare i requisiti tra loro.

Quale che sia l’unità di misura scelta, suggerisco di utilizzare una sequenza numerica in progressione non lineare, come ad esempio: 1, 2, 3, 5, 8, 13, 20, 40, 100.

In questo modo, maggiore sarà la complicazione stimata del requisito, più impegnativo risulterà dover scegliere tra numeri distanti tra loro; ciò farà emergere l’incertezza e la necessità di discutere e approfondire i dettagli del requisito. Facilmente saremo portati a scomporre il requisito, riducendo l’incertezza sulla stima.

Per ogni requisito:

• ciascun componente del team stima individualmente l’impegno a carte coperte, cioè senza rendere noto il valore prima del passo successivo;
• tutti i componenti del team rivelano contemporaneamente la propria stima; le eventuali differenze generano una discussione che prosegue finché non si raggiunge il consenso su un valore;
• se non si raggiunge il consenso in un tempo ragionevole (qualche minuto di discussione) è molto probabile che manchino dettagli; se il cliente è presente può fornire i dettagli mancanti e si può tornare a votare, iterando la procedura; in assenza di maggiori dettagli è possibile sfruttare l’esperienza di chi ha già implementato un requisito molto simile e prendere per buona la sua stima.

La tecnica descritta è nota come planning poker e di sicuro rende l’attività di stima più coinvolgente e divertente, invogliando le persone a intraprenderla.

Ci vuole un po’ di tempo per abituarsi ma dopo un primo momento di inerzia ci si stupirà nel vedere quanto il processo possa diventare veloce ed efficace.

Adotto la tecnica del planning poker da molto tempo (sia utilizzando carte fisiche sia questo strumento gratuito) e il suo principale vantaggio a mio avviso risiede nella discussione e nella quantità di dettagli che riesce a far emergere.

Fare del nostro meglio per ridurre la complicazione accidentale

Per cercare di ridurre la complicazione accidentale dobbiamo affrontare le cause che la generano.

Ad esempio, fare refactoring di codice è consigliabile per “tenere in ordine la cucina”, cioè ridurre il debito tecnico che si accumula via via che le dimensioni del progetto aumentano.

Scrivere test automatici incoraggia il refactoring. Se ci spingiamo oltre e lasciamo che siano i test a guidare lo sviluppo (Test Driven Development, TDD) potremmo progettare architetture migliori evitando ottimizzazioni premature e sovra-ingegnerizzazione del codice.

Le pratiche del pair programming e del code review sono altri strumenti utili a riconoscere errori di progettazione e di implementazione prima che questi arrivino in produzione.

Adottare principi di programmazione solida, le buone pratiche e i migliori strumenti di sviluppo è tutto grasso che cola.

Poiché non esiste una ricetta valida per chiunque, il mio consiglio è quello di sperimentare quante più tecniche e scegliere quelle che ci restituiscono reali benefici.

Per poter riconoscere i benefici è importante misurare i risultati: dobbiamo tracciare il tempo che impieghiamo a sviluppare i requisiti; possiamo utilizzare diverse pratiche per ciascun requisito o per requisiti equivalenti per stima e confrontare i risultati. Misurare è alla base di tutto.

Nota: prima di cominciare una sessione di planning poker occorre chiarire al team le pratiche di sviluppo che si vogliono adottare in modo da tenere in considerazione il relativo costo aggiuntivo nella stima.

Predisporsi al cambiamento

Se accettiamo l’idea che presto o tardi l’incertezza rimescolerà le carte nel nostro progetto dobbiamo essere pronti al cambiamento.

Poiché gli imprevisti influenzano tanto i costi quanto i tempi, accettare il cambiamento significa abbandonare l’idea che si possano controllare tutti gli aspetti del progetto attraverso un piano a lungo termine (solitamente rappresentato con un diagramma di Gantt).

Proprio come accade quando utilizziamo un navigatore satellitare per andare da A a B, dobbiamo essere pronti a ricalcolare il percorso non appena incontriamo un imprevisto che lo ostacola.

Poiché questo significa che probabilmente i costi del progetto aumenteranno o le date di consegna slitteranno, il cliente deve esserne consapevole. Naturalmente tali cambiamenti non fanno felice nessuno ma dopotutto dobbiamo considerare che non siamo pagati per lavorare per un tempo o un importo prestabilito: il nostro impiego è subordinato al raggiungimento di un risultato. Se qualcosa ci ostacola, il meglio che possiamo fare è trovare delle alternative che ci consentano di raggiungere gli obiettivi prefissati. Occorre tenere a mente che fermare un progetto a metà strada per non eccedere limiti di tempo o di budget non porta alcun valore al cliente.

Non è detto che si debba necessariamente superare i limiti di tempo e budget: possiamo sempre ridurre il numero o la complessità dei requisiti da implementare.

Per farlo è però necessario aver definito le priorità dei singoli requisiti, il che consente di stabilire cosa rimandare o a cosa rinunciare del tutto quando si incrocia per strada un cigno nero.

Conclusioni

Come abbiamo visto, stimare il costo di un progetto non è solo questione di stabilire quanto è difficile implementare un insieme di requisiti.

Ci sono altri fattori che influenzano notevolmente la stima che non possono essere ignorati per poter ottenere una previsione quanto più possibile vicina alla realtà.

Nonostante ciò non possiamo fare a meno di prepararci al cambiamento, perché pensare che tutto andrà sempre come prestabilito è puramente illusorio.

Se anche voi avete sperimentato alcuni degli strumenti e delle tecniche riportate nell’articolo o avete esperienze diverse da raccontare, non esitate a lasciarci un commento, saremo lieti di discuterne.

Bibliografia

• Duarte, Vasco. No Estimates: How to measure project progress without estimating. OikosofySeries, 2016. Web.
• Rainsberger, J. B. 7 Minutes, 26 Seconds, and the Fundamental Theorem of Agile Software Development. Web.
• Brooks, Frederick P. The Mythical Man-month: Essays on Software Engineering. Reading, MA: Addison-Wesley Pub., 1982. Print.
• Fowler, Martin, and Kent Beck. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, 2000. Print.
• Taleb, Nassim Nicholas. The Black Swan: The Impact of the Highly Improbable. New York: Random House Trade Paperbacks, 2010. Print.
• Taleb, Nassim Nicholas. Antifragile: Things That Gain from Disorder. New York: Random House Trade Paperbacks, 2014. Print.
• Gonçalves, Luis. Planning Poker And Scrum Poker Everything You Need To Know. Web.

Crediti: la foto di copertina è di Maor-X, rilasciata in accordo ad una licenza Creative Commons.