<< Stimare per la prevedibilità | Home | [OT] Per gli appassionati di AI esce nelle sale italiane Ghost In The Shell 2: Innocence >>

Tecniche di stima (1 di 2): i presupposti

Noi sviluppatori impariamo in fretta che fare una stima accurata a inizio progetto è difficile e farla inaccurata è il primo passo verso il dolore.

Un turista chiede al servizio metereologico che tempo farà il 25 del prossimo mese e la risposta non c'è.
Una signora vuol sapere dal parrucchiere quanto ci metterà, lui chiede cosa desidera: taglio, colore, messa in piega... e poi le risponde.
Ci sono cose che è inutile dettagliare perché cambieranno, altre che conviene conoscere per esprimere una stima possibilmente accurata.

Per formulare una stima su un nuovo software conviene conoscere

  1. i requisiti funzionali (il problema)
  2. il relativo dominio applicativo ed i processi aziendali coinvolti (il problema)
  3. i requisiti non funzionali (il problema)
  4. l'infrastruttura tecnologica (la soluzione)
  5. l'architettura intesa come scomposizione del sistema nei principali moduli e loro interazioni (la soluzione)

Per una evoluzione ad un software esistente a volte basta chiarire i nuovi requisiti perché il resto lo si conosce già da prima.

 

Tags :   |  |  |

Print | posted @ mercoledì 26 luglio 2006 02:07

Comments on this entry:

Gravatar # re: Tecniche di stima (1 di 2)
by Antonio Ganci at 26/07/2006 02:22
Le stime diventano più accurate, man mano prendiamo confidenza con il progetto.
Può essere utile nelle stime farsi aiutare da qualcuno che ha affrontato un problema simile al nostro.
E' importante anche essere attenti all'unità di misura che si sceglie es: se dico ci vogliono 130 giorni, mi aspetto una precisione maggiore che dire circa 6 mesi.
Gravatar # re: Tecniche di stima (1 di 2)
by Lorenzo Barbieri at 26/07/2006 10:21
Secondo me ha ragione steve mcconnel quando dice che c'è differenza tra stima e commitment.
Una cosa è la stima, (che a volte non piace) e una cosa è il commitment a consegnare entro un certo periodo.
Il dolore è quando si scambia la stima col commitment e si aggiustano le stime.
E' come se non si accetta il proprio peso e al posto di dimagrire si "modifica" la bilancia...
Gravatar # Re: Tecniche di stima (1 di 2)
by Roberto Messora at 26/07/2006 13:22
Il vero nocciolo sta, come in parte dice Lorenzo, nella comunicazione con il cliente. Io credo che il cliente non debba necessariamente essere introdotto troppo alla stima precisa dei giorni uomo. credo sia altamente controproducente. In genere il "commitment" come lo definisce Lorenzo è ciò che il cliente dovrebbe conoscere, quindi un valore di impegno temporale a cui può far riferimento per la propria programmazione interna (ovviamente accompagnato da una serie di milestone di vario genere).
Ciò che fa delle stime più precise un vero calvario è invece a mio avviso l'effetto interno all'azienda fornitrice, in cui la necessità di parlare di effettivi gg/uomo, è legata all'analisi dei cisti e alla disponibilità delle risorse anche per altri progetti. La mia esperienza si concentra proprio in questo ambito, ed i problemi sono tanto più difficili da risolvere quanto più aumenta la debolezza commerciale dell'azienda stessa nei confronti del cliente. Voglio dire che fra soluzione e problema, il soggetto di cui statisticamente si conosce meno (e peggio) la definizione è certamente il problema (e qui non dico nulla di nuovo), e spesso accade che ad il committente pretenda (ed ottenga) variazioni in corso d'opera al problema senza un'adeguta politica di change requirements da parte del fornitore.
Probabilmente sarebbe necessario cominciare ad introdurre in maniera formale e su larga scala, nel mondo della consulenza informatica, il concetto per cui la fase pre-ordine non possa più essere una review veloce e leggera, ma un'attività importante ed in qualche modo impegnativa per entrambi i player, addirittura da remunerarsi (a parte se non viene poi seguita da un ordine, integrata nell'ordine in caso di prosecuzione del madato allo sviluppo del sistema). Questo oggi non accade e credo sia una delle maggiori cause del fallimento della stima dei tempi (anche perchè Luca, i fondamentali 5 punti che citi, ognuno in se racchiude un piccolo universo, soprattutto quelli relativi al problema)
saluti
Gravatar # Re: Tecniche di stima (1 di 2)
by Roberto Messora at 26/07/2006 13:53
A me molto più semplicemente basterebbe conoscere di più il problema dal punto di vista di 2-3 stakeholder diversi lato cliente. ma più spesso mi capita di conoscere parzialmente il problema dalla bocca di un'unica persona...
saluti
Gravatar # Re: Tecniche di stima (1 di 2)
by Roberto Messora at 26/07/2006 15:25
Luca, mi piace vederti ottimista... perchè come diceva quello là, l'ottimismo è il sale della vita :-)
nel frattempo sto facendo un pensierino sul cercar casa in uno "stato evoluto"
saluti
Gravatar # Re: Tecniche di stima (1 di 2)
by Roberto Messora at 26/07/2006 18:16
Luca...
lo so che su questo tasto delle stime e del monitoraggio della velocità per me è come toccare un nervo scoperto (lo stesso nervo di Igor), ma...
ma misurare la velocità e correggere il tiro, significa una cosa nei famosi paesi evoluti, significa un cliente scontento, molto scontento in italia (già me lo sento... "ma come avevi detto per il giorno x, ora mi dici che è per il giorno y!"
a volte ho quasi il terrore a pronunciare una stima di commitment anche solo a voce, una volta anche solo sussurrata rimane scolpita nella roccia col sangue.
oggi di informatica hanno bisogno tutti, anche gente che non ne capisce letteralmente nulla. a volte capita che il problema non stia tanto nel fatto che è il cliente che conosce bene i propri processi aziendali, e bla bla bla.. il vero problema sta nel fatto che lui si immagina che la prassi preventivo-consuntivo funzioni esattamente come nel suo settore, insomma come è abitutato a fare sempre con i suoi tradizionali fornitori. e statisticamente parlando la stragrande maggioranza dei casi è una prassi incompatibile con quella della produzione informatica.
cultura, cultura, cultura.
ragazzi sarebbe utile cominciare a pensare a workshop anche per il clienti non solo per noi informatici perchè le tecnolgie cambiano, ma i clienti rimangono fin troppo uguali a se stessi...
e già che ci siamo facciamo anche dei workshop per i commerciali e diciamoli di smetterla con la "banfa" del software facile da installare, usare, configurare, come se si stesse parlando di un rasoio usa e getta: nessuno si lamenta del fatto che per guidare la macchina ci voglia la patente (non è affatto facile guidare...), quindi non vedo perchè qualcuno dovrebbe lamentarsi se certi sw che fanno cose complicate debbano necessariamente prevedere una fase di formazione specifica (ma oggi guai a parlare di queste cose, se non dici che il sw è una idiozia da usare nessuno te lo comprerà o te lo commissionerà mai, poi ci credo che il cliente si lamenta quando capisce la dura realtà, non esiste solo sap a questo mondo).
scusate ancora una volta lo sfogo... :-)
saluti
Comments have been closed on this topic.