Ripensando all’incontro che ho avuto con il responsabile tecnico dell’azienda di software con cui collaboro che mi ha detto la ormai famosa frase: “la direzione è scontenta perchè la pianificazione temporale dei progetti non viene mai rispettata”. Frase già sentita decine se non centinaia di volte, mi sono venute in mente automaticamente le seguenti considerazioni:
punto 1:
Per la sua natura un nuovo progetto software è rappresentato da queste due condizioni:
- la conoscenza del problema da risolvere
- la conoscenza degli strumenti di sviluppo
Nei nuovi progetti capita sempre che una di queste due condizioni sia ignota, o parzialmente ignota. Quando lo sono entrambi sono guai.
Nel caso siano entrambi conosciuti allora siamo nel campo della manutenzione e non di un nuovo progetto.
La pianificazione di un progetto software, sia nuovo che di manutenzione, è regolata dalla seguente formula:
punto 2:
F * Q F * Q
T = ------ che può essere scritta anche così R = ------
R T
T = tempo
F = funzionalità implementate
Q = qualità del software
R = risorse
In parole povere significa che se vuoi dimezzare il tempo devi raddoppiare le risorse o dimezzare le funzionalità.
Nel caso di un progetto di software puro, dove non ci sono parti hardware, le risorse sono corrispondenti al costo. Infatti conoscendo il costo orario delle risorse e conoscendo il tempo si può avere direttamente il costo del progetto.
C = T * R
Da questo si deduce che dimezzando il tempo e raddoppiando le risorse il costo del progetto rimane lo stesso. L’unico modo per modificare il costo del progetto è agire sulle funzionalità o sulla qualità.
Adesso veniamo al problema. La pianificazione.
Quando si pensa ad un nuovo progetto viene immediatamente chiesto quali sono i “tempi e costi”, dai quali si protrebbe rilevare direttamente le risorse. Dalla formula (punto 2) si deduce che se conoscessimo F (dato che Q lo determiniamo noi) potremmo rispondere esattamente alla domanda.
Come facciamo a conoscere F? Con una analisi di dettaglio rispondereste voi.
Purtroppo come abbiamo ampiamente visto nel corso di questi anni la metologia, che fornirebbe un’analisi di dettaglio preventiva (e di conseguenza F) detta waterfall (a cascata), non funziona. Perchè non funziona? Per l’esistenza delle condizioni del punto1.
Le uniche metodologie che hanno una possibilità di successo sono quelle dette agili o a spirale o in decine di altri modi (http://www.agilemovement.it). Queste metodologie non permettono di rispondere alla domanda famosa, “tempi e costi”, semplicemente perchè non è possibile rispondere.
Permettono però di tenere sotto controllo il processo di sviluppo, evidenziando eventuali problemi in una fase in cui è relativamente semplice porvi rimedio.
Permettono di migliorare la stima dei tempi (e di conseguenza dei costi) via via che il progetto procede.
Ma soprattutto permettono di tenere sotto controllo l’avanzamento del progetto anche da parte del management dell’azienda eliminando (o almento riducendo drasticamente) la sensazione che “tutti i progetti non rispettano i tempi previsti”.
Non entro nel dettaglio del perchè con l’adozione di queste metodologie si raggiunge questo risultato, il discorso sarebbe troppo lungo.
Chi fosse interessato può consultare i moltissimi libri sull’argomento, fra tutti segnalo:
-
Agile Project Management with Scrum di Ken Schwaber
-
Agile Software Development di Alistair Cockburn
-
Agile Estimating and Planning di Mike Cohn
Ho scritto queste considerazioni abbastanza di getto, probabilmente non sono molto chiare, gradirei comunque avere i vostri commenti.
posted @ giovedì 2 marzo 2006 15:37