Tecniche di stima (2 di 4): lo sforzo

<< Tecniche di stima (3 di 4): il calendario dei rilasci | Home

Tecniche di stima (2 di 4): lo sforzo

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

Quanto sforzo è necessario per completare il progetto? (la cossidetta stima in giorni uomo)
Quanto tempo di calendario serve? (il cossidetto commitment o impegno sulla data di rilascio)
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 |

Print | posted @ mercoledì 2 agosto 2006 0.16

Comments on this entry:

# re: Tecniche di stima (2 di ?)

by Antonio Ganci at 02/08/2006 0.22

Voglio farti un esempio pratico, il cliente ti chiede un nuovo progetto, le specifiche appaiono sufficientemente chiare e si passa alla realizzazione.
Mentre lo implementi ti accorgi di non aver calcolato qualcosa di fondamentale perchè non ne eri a conoscenza.
Il tempo richiesto raddioppia come minimo, cosa fai?

# re: Tecniche di stima (2 di ?)

by Luca Minudel at 02/08/2006 0.53

Hai vinto il premio x il commento più veloce del mondo!

Se sto lavorando col cliente in modo XP è facile, mi acorgo della velocità ridotta alle prime iterazioni e lo comunico al cliente che può ridurre lo scope scegliendo le user story che danno maggiore valore o valutare un'altra alternativa come una diversa soluzione al suo problema (un diverso software o altro).

Altrimenti come diceva quella pubblicità, turista fai da te, no XP? Ahi Ahi Ahiiiii ! :D

Inoltre mi chiederei perché non ero a conoscienza di quella complessità e non ho avuto nemmeno un dubbio che mi spingesse ad investigare e non ho chiesto ad altri esperti di fare una stima e confrontarla con la mia.
- il dominio applicativo o il problema tecnico sono così innovativi che era impossibile scoprire in antici po la complessità ?
- oppure il dominio applicativo ed il problema tecnico sono noti in letteratura e ho sottovalutato una mia mancanza di conoscienza tanto da ritenere di non fare gli approfondimenti necessari prima di stimare?

Nel primo caso niente male, basta avvisare in anticipo il cliente del rischio insito in un problema nuovo e mai investigato prima.

Nel sencondo caso avrei commesso un errore di "presunzione" che cercherei di non ripetere in futuro.

# Re: Tecniche di stima (2 di ?)

by Roberto Messora at 02/08/2006 9.44

Grande post Luca.
Queste perle valgono da sole seguire UgiDotNet tutti i giorni!
Ovviamente l'ideale sarebbe poter applicare un approccio agile con il cliente, cliente che capisca l'importanza di un profondo coinvolgimento nel progetto stesso.
Ovviamente (2) la maggior parte delle volte si torna al famoso paradigma del carroziere (voglio questo che faccia questo e quello, quanto mi costa?) ed il dilemma diventa quello di accettare il rischio del 400% di errore di stima oppure quello di perdere il cliente se si cerca in tutti i modi di convincerlo ad un approccio al problema diverso, agile appunto (qualcuno potrebbe non gradire e rivolgersi ad altri).
In tutti i casi sono perfettamente d'accordo con il concetto di consulenza aperta verso il cliente, credo moltissimo nel valore della professionalità del consulente, ma professionalità _non_ significa che per forza di cose è necessario mostrarsi sicuri di se e potenzialmente infallibili, bensì dare prova della conoscenza della materia che si sta trattando, quindi avere ben presente che esistono aree di incertezza che non significano automaticamente ignoranza, ma che sono insite nel dominio del problema (ed il problema è "realizzare un sistema software informatico").
Per concludere una nota sulla metodologia di stima basata sul giudizio di esperti. Credo in generale che sia molto poco utilizzata più che altro per un fattore emotivo, forse dovremmo abituarci molto di più di quanto non si faccia oggi a pensare al mondo della consulenza informatica come ad una sorta di network connesso che offra servizi anche di questo tipo. Ho l'impressione che, almeno in Italia, ci si stia limitando ad una community prettamente tecnica (che è già un bel traguardo intendiamoci) che si limita a creare momenti di convergenza in ambito esclusivamente tecnico (ed è quanto realiziamo in UGIDotnNet). Dovremmo a mio avviso invece evolvere e liberarci di quel pudore o di quell'imbarazzo che in qualche modo ci impedisce di instaurare rapporti di inter-consulenza (non so come chiamarla) basati su accordi commerciali condivisi e che ci permettano di appunto di relazionarci l'un l'altro a volte in qualità di esperti (quindi fornendo consulenza), altre volte in qualità di non-esperti (quindi ricevendo consulenza). In gener credo che esista una sorta di gelosia propria rispetto al proprio lavoro ed ai propri clienti, atteggiamento che rischia appunto di portare ad errori di valitazione anche dolorosi, se riuscissimo a creare uno spazio aperto, basato sul rispetto professionale (quindi a tariffe che rispettino il valore di conoscenza erogato ed in assenza di giochetti strani verso il cliente finale), credo che potremmo veramente cominciare a: vivere meglio noi affrontando con una certa serenità il nostro lavoro e gli impegni che ci siamo presi in termini di progetti da realizzare, offrire un servizio consulenziale migliore ai nostri clienti, ma soprattutto cominciare a creare un ambiente di professionisti realmente valido che cominci a fare "cultura" andando piano piano ad erodere la gramigna dei venditori di fumo un tanto al pezzo.
saluti

# re: Tecniche di stima (2 di ?)

by Luca Minudel at 02/08/2006 17.59

@Roberto

Condivido le considerazione.

In un prox post vorrei parlare anche la definizione del prezzo anche in funzione della stima. Questo nelle mie intenzioni è il passo che unisce un bravo tecnico consapevole del grado di incertezza dalla stima alla definizione di un prezzo che beneficia di questa info in più rispetto a quelle disponibili ai venditori di fumo.

# Tecniche di stima (3 di ?)

by (luKa) at 03/08/2006 19.26

# Tecniche di stima (3 di ?)

by (luKa) at 03/08/2006 19.27

# Tecniche di stima (4 di 4): i costi

by (luKa) at 09/08/2006 22.53

# Tecniche di stima (4 di 4): i costi e il prezzo

by (luKa) at 09/08/2006 22.54