(luKa)

La stima dei tempi durante un progetto viene fatta in almeno 2 momenti molto diversi.

Qui il punto è che la pianificazione è un documento vivo che viene continuamente aggiornato in base alle nuove informazioni raccolte e in ogni momento esprime con la migliore precisione possibile l'ora di arrivo prevista.
Procedendo così il cliente otterrà tanto valore quanto paga ed in modo prevedibile. Non è poco! Siamo anni luce avanti allo standard del pre Anno 2000/EURO.
Ogni imprevisto potrà essere gestito in modo tempestivo, reagire cambiando i piani sarà la cosa naturale da fare.

Release Planning
La prima stima va fatta per il Release Planning ossia la pianificazione dei tempi del rilascio. Ad un rilascio corrisponde una "lista della spesa" (con un elenco di singole funzionalità ogniuna delle quali è direttamente utilizzabile dall'utente finale e produce un risultato finito di cui l'utente potrà usufruire come emissione di un ordine, registrazione di una fattura, emissione di un'offerta, etc.). A questo rilascio corrisponde solitamente il budget concordato con il cliente.

Nel Release Planning per ogni punto della "lista della spesa", una funzionalità, viene fatta la stima.
Il primo obiettivo è quello di centrare il Totale sul quale viene concordato il budget (qui le stime delle singole funzionalità sono considerate nel loro insieme).
Il secondo obiettivo è quello di avere errori di stima ridotti nella singola funzionalità per poter sostituire a richiesta del cliente una (o +) funzionalità della lista con una nuova funzionalità di pari stima mantenendo serenamente l'accordo preso sul Budget.

Quando la stima è fatta senza imbrogliare e con un minimo di criterio, gli errori di stima delle singole funionalità sulla "lista della spesa" sono di segno alternato, quando sulla lista ci sono almeno 10 funzionalità gli errori di stima tendono ad annullarsi portando il Totale ad un errore ridotto. Cosi si raggiunge il primo obiettivo. 

Il secondo obiettivo si ottiene con lo stesso processo cioè scomponendo l'implementazione della funzionalità in più task stimati singolarmente e quindi sommandone la stima. In questo momento il focus è l'intero rilascio e non il dettaglio della singola funzionalità, mancano le conoscienze necessarie ad individuare i task che corrisponderanno al reale piano esecutivo dell'implementazione; ora ci si accontenta di uno zoom approssimato sulla singola funionalità quindi i task sono una generica suddivisione della funzionalità secondo un criterio a piacere (per es. le entità di dominio coinvolte oppure i moduli da realizzare oppure i livelli da implementare).

Vedi anche http://www.extremeprogramming.org/rules/planninggame.html

Iteration Planning
Iniziata l'implementazione la stima ora va fatta per ogni iterazione della singola funzionalità (se la funzionalità viene implementata e non passa i controlli ci sarà un'altra iterazione altrimenti avanti con la prox funzionalità).

La funzionalità viene nuovamente scomposta in task che ora descrivono i singoli passi da compiere per implementare la funzione, sono cioè un reale piano esecutivo dell'implementazione. I task vengono stimati e sommati ottenendo una stima più dettagliata che beneficia della conoscienza del sistema e dei dettagli implementativi maturata nelle preceedenti iterazioni e la conoscienza della velocità del team nella implementazione .

Vedi anche http://www.extremeprogramming.org/rules/iterationplanning.html

- - - -

Vedi anche il post precedente Prezzo da Ipermercato, qualità da Boutique.