- Home
- /News Autoware
- /Soluzioni
- /Sistemi MES
- /Stimare un Progetto Agile – Best Practices
Stimare un Progetto Agile – Best Practices
Al post del mese scorso, a proposito di gestione del progetto Agile, sono arrivati molti commenti, ed alcune richieste di approfondimento, fra cui come stimare un progetto Agile. Sul blog di Automation World il punto di vista di Luigi De Bernardini.
Quando il mese scorso ho scritto di come secondo me un approccio agile non convenzionale può essere determinante per il successo di un progetto MES/MOM, non mi aspettavo di suscitare tutto l’interesse che è stato espresso sull’argomento. Più di qualcuno ha commentato l’articolo su linkedin e mi sono state chieste spiegazioni ed approfondimenti su alcune questioni in particolare: come sia possibile effettuare una stima del progetto con tale approccio e come si possano gestire i cambi di scopo che possono intervenire durante i vari sprint. Ho quindi deciso di tornare sull’argomento questo mese ed il prossimo, affrontando nello specifico questi due temi. Ovviamente quanto esposto non ha la presunzione di costituire una “verità” sull’argomento, ma vuole solo essere uno spunto di riflessione e discussione a partire da alcune considerazioni dettate dalla mia esperienza con Autoware.
Stimare un progetto software è sempre una cosa complessa. Molta teoria è stata sviluppata nel tentativo di ricondurre l’attività di stima ad un approccio quantitativo algoritmico. Dal momento però che lo sviluppo del software è un processo fondamentalmente creativo, nessun approccio si è, secondo me, effettivamente dimostrato in grado di produrre una stima sufficientemente corretta da risultare più efficace dell’esperienza. Questo è tanto più vero nel caso di sviluppo di progetti su commessa, ove le varianti che intervengono da un progetto all’altro sono estremamente elevate. Voler affrontare il progetto in modalità agile, da questo punto di vista è un ulteriore elemento di complessità, perché alla flessibilità elevata che offre, corrisponde anche una indeterminazione del risultato finale da ottenere. Come posso quindi effettuare una stima delle risorse necessarie a realizzare qualche cosa che non è ben definito e specificato? Nel momento in cui ci troviamo nella necessità di definire l’impegno necessario per sviluppare un nuovo progetto cerchiamo di affrontare il problema seguendo questo flusso:
-
- definire con il cliente i contorni approssimativi dei suoi desiderata e mappare le macro richieste in altrettante macro aree di nostra esperienza. Questo ci aiuta ad identificare, almeno in maniera grossolana, i problemi ed a comprendere da quali bagagli di esperienza poter attingere le informazioni per cercare di ricondurli a qualche cosa di già noto;
- elaborare una macro architettura della soluzione tecnologica da utilizzare come riferimento per tenere in considerazione la complessità del progetto, ed avere un elemento comune definito cui fare riferimento in ogni successivo confronto con il cliente;
- individuare quanto dei requisiti esposti è indicativamente riconducibile a funzionalità standard o a componenti già sviluppati per altri progetti, e quanto invece risulta diverso o ancor più al di fuori della sfera di esperienza disponibile in azienda.
