Uno degli aspetti più critici della gestione dei progetti è la stima delle risorse necessarie al completamento delle attività. Le stime sono per loro natura sempre affette da un certo grado di incertezza, ma statisticamente di osserva che le stime nei progetti software hanno un livello di accuratezza inferiore a quelle di altri campi dell’ingegneria.
I dati pubblicati annualmente dal 1994 nel Chaos Report da Standish Group permettono di osservare l’evoluzione nel tempo delle performance dei progetti software: la percentuale dei progetti conclusi con pieno successo nel tempo è aumentata (con qualche oscillazione negli anni), ma rimane il fatto che circa tre quarti dei progetti finiscono superando il budget inizialmente previsto.
L’analisi di questo problema ha dato origine ad infinite discussioni che possono essere facilmente reperite in letteratura scientifica e sul web. Le dissertazioni accademiche possono anche essere ignorate, ma la realtà non può essere ignorata: I dati dimostrano che è praticamente impossibile, dati gli strumenti e gli approcci attuali, conoscere in anticipo con certezza quanto impiegheremo per la realizzazione di un progetto software e molti progetti (quelli che non falliscono) vengono completati utilizzando risorse maggiori di quelle che erano state stimate.
L’incertezza delle stime è (in parte) dovuta al fatto che il software è soggetto ad un continuo cambiamento. Il cambiamento continuo è una caratteristica intrinseca e distintiva del software che, al contrario dell’hardware, può essere modificato per adattarsi ai mutamenti delle condizioni ambientali. La variabilità insieme all’intangibilità e all’immaterialità sono caratteristiche peculiari dei prodotti software che rendono il software più difficile da misurare e da stimare rispetto a molti altri tipi di prodotto.
Il Cono di Boehm o Cono di incertezza
L’accuratezza delle stime può essere migliorata adottando un metodo rigoroso e corretto dal punto di vista statistico, ma per ridurre l’incertezza di base legata al cambiamento continuo è necessario ridurre la variabilità del progetto. Purtroppo nella maggior parte dei casi la variabilità non può essere eliminata perché è parte intrinseca del progetto stesso!
I dati sperimentali, in accordo con il buon senso, dimostrano che l’incertezza della stima è inversamente proporzionale alle informazioni disponibili. Le prime stime saranno affette da una grande incertezza che nel tempo potrà essere ridotta. Questo concetto è alla base del Cono di Incertezza (o cono di Boehm).
Il Cono di Incertezza è uno strumento “portato” nel mondo del software da Barry Boehm come “Funnel Curve” e basato su una serie di lavori che hanno origine nell’ambito di uno studio sul Risk management nell’ingegneria chimica promosso dall’American Association of Cost Engineers alla fine degli anni ’50 del secolo scorso. Il nome Cone of Uncertainity è stato poi coniato da Steve McConnel, dopo che il lavoro di Boehm è stato raffinato, tra gli altri, dalla US Air Force e dalla NASA.
Il cono di incertezza rappresenta il graficamente il limite dell’accuratezza che è possibile raggiungere nelle stime se tutte le attività del processo di sviluppo sono eseguite al meglio.
Ridurre l’incertezza
L’incertezza non si riduce da sola! Esistono molti strumenti e tecniche di gestione progetti e di sviluppo software consentono di comprimere la regione di incertezza ed avvicinarsi alla curva del cono, che rappresenta un limite inferiore difficile da raggiungere.
Ad esempio un definizione puntuale del prodotto, la descrizione dettagliata dei requisiti e una progettazione dettagliate dell’interfaccia utente condivisa con il cliente contribuiscono a migliorare l’accuratezza della stime.
Quando il cono diventa una clessidra
Un fenomeno che si osserva spesso nella pratica è che l’area di incertezza prima sembra diminuire mentre il livello di definizione del prodotto aumenta, poi improvvisamente l’incertezza esplode nuovamente. Se nelle rilevazioni si osserva questo fenomeno è urgente prendere provvedimenti altrimenti il progetto andrà presto fuori controllo.
Nella mia esperienza l’andamento “a clessidra” può essere causato da due fattori:
- la definizione non corretta o incompleta (di una parte) del prodotto: alcuni aspetti che erano stati considerati come stabili e ben definiti in realtà non lo erano e in una fase successiva si è reso è necessario apportare modificare significative e non previste a cose che si pensava fossero ormai concluse.
- il processo di sviluppo non è definito in maniera chiara e ripetibile e le stime basate sui dati storici sono inattendibili
Cono di Incertezza e Contratti
C’è una relazione molto importante tra il cono dell’incertezza ed il rischio nei progetti software: nelle prime fasi del progetto le stime sono caratterizzate da una incertezza incertezza variabile tra 400% e 200%.
Basare un impegno contrattuale su queste stime è estremamente rischioso. Un organizzazione dotata di processi efficaci definisce i termini del contratto solo dopo che il team di progetto ha ridotto l’incertezza ad un livello accettabile. Nella pratica questo si ottiene facendo precedere il contratto definitivo da studi di fattibilità ed analisi preliminari.
McConnel nel famoso libro “Software Estimation: Demystifying the Black Art (Developer Best Practices)” individua nella milestone “User Interface Design Completed” posta a circa il 30% della durata complessiva del progetto il momento corretto per definire gli impegni contrattuali. In questa fase del progetto è possibile eseguire stime un margine di errore del 20-30% che quindi sono utilizzabili anche per definire budget e tempi di consegna del progetto.
Vedere (anche su carta o come mockup interattivo) ed in una qualche misura interagire con il prodotto porta il cliente ad esprimere in modo più completo i requisiti e lo aiuta a capire di cosa ha realmente bisogno.
Fino a quando non si arriva ad avere una interfaccia utente ben definita e condivisa da tutti gli stakeholder è molto probabile che arriveranno richieste di modifiche sostanziali, con impatto anche a livello funzionale e sull’architettura in grado di far saltare tutte le stime fatte in precedenza.
Cono di incertezza e sviluppo Agile
Le metodologie Agile risolvono il problema suddividendo il progetto in “Sprint” ognuno caratterizzato da un proprio cono di incertezza con durata molto breve (ad esempio 4-6 settimane). In questo modo all’interno di ogni sprint si arriva entro pochi giorni ad poter formulare stime con un livello di accuratezza accettabile, ma non è possibile stimare a priori la durata ed il costo dell’intero progetto perché non sono stati analizzati tutti i requisiti.
Questo approccio che privilegia la flessibilità ed asseconda i cambiamenti è sicuramente preferibile dal punto di vista dello sviluppo del prodotto e della soddisfazione delle aspettative, ma non è quasi mai compatibile con la necessità contrattuale di definire a priori un budget per il progetto. Maggiori possibilità di applicazione si ha nello sviluppo dei prodotti.
Molti team di sviluppo lavorano in una sorta di compromesso tra il modello sequenziale a cascata ed i modelli agili con iterazioni brevi. Il progetto viene gestito in modo sequenziale fino alla milestone “User Interface Design Complete” e poi si passa ad un approccio più iterativo dopo che budget e tempi di consegna sono stati definiti contrattualmente.
Questo compromesso permette certo grado flessibilità rispetto a cambiamenti nei requisiti e consente al tempo stesso un livello di predicibilità a lungo termine compatibile con le esigenze di business.
blog.emanuelebuchicchio.com 