(luKa)

Quando un progetto inizia e si va verso una offerta economica è necessario trovare la risposta a queste domande:

1. Quanto sforzo è necessario per completare il progetto? (la cossidetta stima in giorni uomo)
2. Quanto tempo di calendario serve? (il cossidetto commitment o impegno sulla data di rilascio)
3. Quel'è il costo di realizzazione del progetto? (e di conseguenza il prezzo)

Quello di cui parlo è il punto 1 ossia la stima dello sforzo in giorni uomo, che poi contribuisce a determinare i restanti due punti.  La difficoltà di formulare la stima per una attività è descritta in questo grafico (clicca x ingrandire) si va da un errore del 400% in fase di studio fattibilità ad un errore del 100% in fase di disegno/codifica:

Stima per analogia
E' il metodo di stima più conosciuto ed è applicabile per stimare un progetto simile a progetti già realizzati con il medesimo dominio applicativo e  architettura/infrastruttura/tecnologia simile. Basandosi sullo sforzo necessario a realizzare le singole parti dei progetti passati e tenendo conto dele differenze è possibile calcolare la stima dello sforzo necessario al nuovo progetto. Nel mometo in cui una azienda fa un salto tecnologico ad esempio da COM/VB a .NET e da architetture Client/Server ad architetture Distribuite/Web Based magari affrontando mercati e domini applicativi nuovi questo metodo non è applicabile.

Giudizio dell'esperto
E' un metodo efficace che consiste nel far scomporre e stimare il progetto a 2 o più persone del team esperte delle tecniche di implementazione e del domino applicativo del progetto e quindi confrontare e discutere le differenze nelle stime sino a fare luce su tutti i punti giungendo quindi ad una stima condivisa. E' un vantaggio quando coloro che fanno la stima hanno esperienze diverse in modo da complementarsi.

Note
E' preferibile fare la stima botton-up per ridurre gli errori di sottostima partendo dal considerare i mattoni che dovranno via via essere realizzati per comporre il sistema (in XP le singole user story scomposte in task). In questo caso è frequente sottovalutare i costi di integrazione (in XP la continuous integration aiuta a farli emergere e quindi minimizzare da subito). Inoltre il grafico sopra suggerisce di relizzare dei prototipi (in XP le spike solution) per investigare i punti più oscuri già in fase di stima e di procedere in modo incrementale arrivando a disegno/codifica/rilascio il più presto possibile (in XP ad ogni singola user story) per portarsi velocemente nel lato destro del grafico.

Per progetti grandi conviene applicare più metodi di stima e confrontare i risultati.

Capita anche che il cliente stesso non sia disponibile a fare tutto lo sforzo necessario a raccogliere gli elementi necessari a formulare una stima possibilmente accurata. In questi casi è bene includere insieme alla stima gli elementi forniti dal cliente chiarendo e non nascondendo il grado di approssimazione della stima (che deve essere noto) dovuta alla parzialità degli elementi disponibili precisando quindi che la stima è indicativa e soggetta a variazioni dovute ad aggiunte e modifiche che potrebbero emergere in fase di micro-analisi. In pratica per ogni task stimato si può classificare il grado di certezza della stima con Low / Medium / High .

Stime algoritmiche
Un'altra categoria di tecniche di stima sono quelle algoritmiche, ossia calcolate in base ad un modello matematico di previsione basato su dati storici raccolti, sono molto più costose da applicare, è interessate conoscere i principali parametri che prendono in considerazione:

• La dimensione del progetto che deve essere realizzato (come ad esempio il numero di classi, di form, di linee di codice o il numero e la complessità delle funzioni utente)
• L'esperienza del team nel dominio applicativo e nelle tecnologie impiegate e la coesione del team (un team di persone junior appena composto o un team di senior abituato a lavorre insieme da tempo?)
• La validità e maturità del processo di sviluppo impiegato (esiste un processo di sviluppo definito condiviso? quanto si è dimostrato efficace?)
• Il supporto tecnologico (inteso come disponibilità e qualità dei tool impiegati)
• L'ambiente fisico di lavoro (comodo, ergonomico, quieto, strutturato per favorire la cominuazione e permettere i necessari momenti di riservatezza/isolamento/tranquillità)

Tags :  Team Work | Agile | Pratiche |