Mi occupo di sviluppo software a livello professionale da ormai più di 10 anni. Per più di metà di questi anni mi sono chiesto in che modo i project manager effettuassero le stime sui tempi di realizzazione/consegna. Più volte la curiosità mi ha spinto a porre la domanda ai diretti interessati. Devo confessare che le risposte sono state nella maggior parte delle volte più che vaghe, qualche simpaticone mi ha anche parlato di alcune costanti moltiplicative impiegate nella stima dei costi.
La verità è una sola: non esiste un metodo standard per stimare la complessità di un progetto, i PM effettuano stime ad occhio, basate principalmente sulle loro esperienze trascorse, accompagnate sempre da un ampio margine di tolleranza.
Il problema è che in molti casi ho visto "sbordare" tali previsioni da questo benedetto margine e alla fine a pagarne le conseguenze sono state tutte le figure coinvolte direttamente e indirettamente nella conduzione del processo:

• Il cliente,che ha visto lievitare inspiegabilmente i tempi di consegna
• l'azienda, che non è rientrata nel budget
• Il PM, il quale ha vissuto questa esperienza come un fallimento personale
• Il team di sviluppo costretto a lavorare in un clima di elevata tensione
• Il software stesso, risultato diretto del clima in cui opera il team

Qualcuno si è chiesto di chi fosse la colpa, con gli anni e l'esperienza ho imparato che la colpa è esclusivamente imputabile all'approccio.
Per anni infatti ci hanno inculcato, attraverso l'ingegneria del software, l'affidabilità del modello a cascata. 
In questa breve serie di articoli proverò a fornire una breve introduzione ai concetti relativi alla metodologia di sviluppo software che attualmente ritengo vincente: Scrum.