Il Cono d’Incertezza, descritto da Steve McConnel, mostra quello che ogni professionista del software esperto sa. Cioè che all’inizio di ogni progetto non sappiamo esattamente quanto tempo un progetto richiederà.
Le ragioni di questo sono molte. Non ci sono mai due progetti che abbiano:
- le stesse esigenze.
- le stesse persone.
- lo stesso contesto aziendale.
- la stessa tecnologia.
- le stesse priorità & vincoli.
Ognuno è unico. Ogni linea di codice è fatta a mano. E il lavoro di conoscenza che coinvolge persone intelligenti e creative non si presta alla precisione come lo fa lo scavo di un fosso.
Anche se la precisione è ciò che si chiede. Gli sponsor vogliono sapere esattamente quando il progetto sarà finito e quanto costerà.
Gestire questo enigma è quasi vecchio come il tempo stesso. Ecco alcuni modi in cui i team e le aziende affrontano questa incertezza.
Affrontare il cono
Compensare la stima
Dopo aver sentito il pungiglione della sottovalutazione, una reazione comune è raddoppiare o triplicare la stima la volta successiva. Questo sicuramente abbassa il rischio iniziale, ma gonfiare le cifre è più difficile di quanto sembri.
Dare una cifra troppo grande, e gli sponsor si tireranno indietro e non approveranno il tuo progetto. Dai una cifra troppo bassa e rischi di rimanere senza soldi. Questo diventa doppiamente rischioso quando si fa un’offerta su contratti a offerta fissa, dove c’è ancora più pressione per mantenere i numeri bassi.
La maggior parte dei progetti aggiunge qualche tipo di imbottitura sui numeri finali per darsi un margine di manovra sufficiente. Un’altra cosa che i team possono fare è confrontare questo progetto con altri.
Dimensiona il progetto relativamente
Gli esseri umani sono davvero bravi a dimensionare le cose relativamente. Non possiamo dirvi esattamente quanto è grande una roccia. Ma possiamo dirvi quanto è grande rispetto a qualcos’altro. Possiamo usarlo anche quando dimensioniamo i progetti.
Siiate schietti e onesti
La modalità operativa di default di Agile è la trasparenza e la visibilità. Quindi non dovrebbe essere una sorpresa che il modo Agile di trattare con il cono sia quello di essere onesti e diretti.
Guarda. Non sappiamo quanto tempo ci vorrà. Questa è la nostra migliore ipotesi. Ma se ci dai un paio di iterazioni, possiamo costruire qualcosa, misurare quanto tempo ci vuole, e poi dirti quanto è grande questa cosa.
Un altro approccio che alcuni team Agile adotteranno per aiutare a comunicare l’incertezza è di presentare le stime come un intervallo.
Questo ha il vantaggio di mostrare visibilmente agli sponsor l’incertezza che viene con il progetto, e quindi lasciare che gli sponsor decidano quanto rischio possono permettersi di assumere.
Finanziare incrementalmente
Un altro approccio che ha molto senso, ma purtroppo non lo vedo applicato abbastanza spesso, è il finanziamento incrementale.
Con il finanziamento incrementale non si chiede l’intera borsa di soldi in anticipo. Solo quanto basta per far passare abbastanza lavoro, per riportare un numero migliore su quanto tempo ci vorrà.
Non è infallibile. Si può ancora incorrere in problemi in seguito. Ma dando ai team $30-50K, lasciando che costruiscano qualcosa e vedendo quanto tempo ci vuole, si può andare molto lontano per ridurre la varianza in quel numero iniziale.
Puoi leggere di più su questo modo di pianificare e i vantaggi che porta in Beyond Budgeting
La causa principale
Viviamo in un mondo di bilanci annuali. E sfortunatamente questo guida molte delle tensioni e dei drammi nel nostro posto di lavoro. Per certi versi i budget annuali sono naturali (viviamo e seguiamo il tempo in cicli annuali) ma in altri sono terribili per la pianificazione, perché un anno è un tempo lungo nel mercato.
Se vi trovate ad essere inciampati nel cono d’incertezza, ricordatevi che l’intero scopo della stima del software è di determinare se il progetto è possibile.
O come dice Steve McConnell:
Lo scopo principale della stima del software non è quello di prevedere il risultato di un progetto; è quello di determinare se gli obiettivi di un progetto sono abbastanza realistici da permettere al progetto di essere controllato per raggiungerli.
-Steve McConnell, Software Estimation: Demistificare l’arte nera