Una delle attività più importanti di un progetto è la valutazione delle tempistiche e, di conseguenza, dei costi necessari alla sua realizzazione.
Un errore in questa fase può avere delle conseguenze che possono ripercuotersi in maniera importante su tutto il flusso di lavoro.
Nonostante siano stati definiti vari approcci e metodologie per la gestione di un progetto software, tutte prevedono una fase di stima.
Per questo motivo è bene prestare attenzione ad alcuni semplici accorgimenti.
1) STIMARE TUTTE LE ATTIVITÀ
Uno degli errori più comunemente commessi è quello di considerare solamente le attività prettamente legate allo sviluppo.
Non c’è niente di più sbagliato che pensare che il tempo necessario per completare un task sia quello che serve per svilupparlo.
Oltre al puro sviluppo, esistono una serie di attività di supporto che è indispensabile considerare:
- Architettura: prima di sviluppare un task è buona prassi investire del tempo per analizzarne gli impatti all’interno dell’architettura applicativa.
- Test automatici
- 4eyes: la fase di 4eye occupa tempo sia da parte dei QA che dello sviluppatore.
- Integration testing: al termine dell’integrazione del task nel progetto, sarà necessario testare nuovamente tutte le sezioni correlate all’attività.
- Bugfix: in un mondo ideale tutto funzionerebbe sempre al primo tentativo, ma la realtà è ben diversa ed è importante considerare che molto spesso sarà necessario apportare alcune piccole (nel caso migliore) correzioni.
2) DIVIDE ET IMPERA
Stimare un task complesso o di alto livello senza scomporlo in parti più piccole aumenta il rischio di errore e può nascondere delle insidie inattese: per questo è sempre consigliabile effettuare il breakdown dei task più onerosi. Sarebbe ideale non avere attività che richiedano più di 4 o 5 giornate di sviluppo. In caso contrario potrebbero esistere dei subtask che non sono stati considerati.
Questa scomposizione favorisce anche un approccio iterativo allo sviluppo, consentendo di organizzare in maniera più agevole eventuali tranche di lavoro.
Al contrario, strutturare uno sprint bisettimanale risulterebbe molto più complicato se tutte le attività avessero una durata superiore a 5 giorni.
La suddivisione in microtask è inoltre estremamente utile per giustificare stime elevate: rende più chiara l’effettiva complessità del progetto a chi dovrà approvarlo ed è sintomo di un’analisi effettuata in modo accurato. A volte questo può fare la differenza fra un opportunità persa e una guadagnata.
3) IMPARA DAGLI ERRORI
Per migliorare progressivamente la propria capacità di fare delle stime corrette è importante effettuare un’analisi retrospettiva al termine di ogni progetto, al fine di comprendere quali siano stati i principali errori in fase di analisi e cosa non sia stato opportunamente considerato.
Tale analisi ha però bisogno di dati a supporto: per questo è consigliabile, per ciascuno dei task stimati e per ciascuna attività non considerata inizialmente, riportare le ore stimate e le ore effettivamente impiegate. Mantenere aggiornato quotidianamente questo registro consente inoltre una miglior governance del progetto.
4) THINK NEGATIVE
I programmatori sono persone ottimiste per vocazione, con un’innata convinzione nelle proprie capacità e in StackOverflow. Questo fa sì che, valutando un task che presenta delle incognite, si tenda a sottostimarne il rischio.
É importante valutare tutte le possibili complicazioni legate a una feature in modo da avere un’idea di quanto tempo richiederebbe il worst case scenario, dopodiché bisogna effettuare una valutazione intermedia fra questo e il caso “medio”, utilizzando una delle apposite tecniche (es: Planning poker).
5) NIENTE PASSI INDIETRO
Può capitare che alcune valutazioni possano essere ritenute eccessive da parte del cliente, ma è importante ricordarsi che abbassare le tempistiche senza una giustificazione appare poco professionale e rischia di far perdere credibilità.
É consigliabile piuttosto contrattare su quali funzionalità rimuovere o posticipare a una fase successiva.
6) UN ERRORE IN POSITIVO È COMUNQUE UN ERRORE
Può capitare di commettere un errore di stima “in positivo”, ovvero impiegare meno tempo di quello stimato. Nonostante sia un indicatore del fatto che il team abbia lavorato bene, bisogna tenere a mente che si tratta comunque di un errore che avrebbe potuto compromettere l’avvio del progetto.
7) KNOW YOUR TEAM
In contesti particolarmente dinamici è probabile che nelle primissime fasi di avvio di un progetto il team non sia interamente noto a priori. É importante essere consapevoli che ciò costituisce un rischio.
Anche conoscendo a priori tutti i membri del team, è comunque impossibile mettere tutti d’accordo, dato che ciascuno ha la propria esperienza e la propria sensibilità in tema di stime. A tale scopo è consigliabile l’utilizzo dei medesimi strumenti citati al punto 4.
CONCLUSIONI
I punti indicati rappresentano solamente alcuni degli aspetti e dei passaggi da considerare per effettuare una buona stima; è buona prassi definire i propri processi, sia a livello personale che di team, cercando costantemente di raffinarli e potenziarli.
Ciò consentirà un graduale miglioramento dei risultati e una maggiore precisione nella propria capacità di analisi, da cui conseguiranno, per le motivazioni indicate in apertura, importanti benefici sia per i singoli progetti che per l’azienda stessa.
