Newsgroup: it.lavoro.informatica
Titolo: Stime tempi

Quando vi danno un foglio excel e vi dicono di riempirlo di numerelli per le 
stime dei tempi di realizzazione di un progetto, che metodo adottate? 
Tenete sulla scrivania un paio di dadi? O fate le cose pi� seriamente e vi 
rivolgete ad un indovino? 

 ha scritto nel messaggio 
news:h6llu8$rdh$1...@nnrp-beta.newsland.it...

1. Se riesci a trovare una corrispondenza con cose simili gi� fatte metti lo 
stesso tempo +20%;
2. Valuta spannometricamente sulla base dell'esperienza;
3. Poi in base a quanto si ritiene che il cliente sia disposto a spendere si 
aggiustano proporzionalmente i valori...
E' inevitabile fare errori... l'indovino aiuta!!! ;) 

 wrote:

http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
-- 
Living in Barbaropoli
http://www.barbaropoli.com

? O fate le cose pi� seriamente e vi rivolgete ad un indovino?
Alla fine, il tempo piu' lungo per ciascuna voce.....moltiplicalo sempre per 
tre.
ciao
fm 


e aggiungi al totale un 20% per gli imprevisti
m.

 
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
L'avevo visto diverso tempo fa... per� mi pare che non sia altro che una 
formalizzazione del principio dell'esperienza acquisita. Suggerirei di dare 
un'occhiata a pi� metodologie, magari alcune si adattano meglio allo "stile" 
di sviluppo che si adotta:
http://en.wikipedia.org/wiki/Estimation_in_software_engineering
...ricordando sempre che sono solo *STIME*...
Un'altro modo pi� efficace (se si ha la possibilit� di proporlo e se la 
complessit� del progetto lo giustifica) consiste nello sviluppo di uno 
studio di fattibilit� della durata di pochi giorni (3-5). Nello studio (che 
uno si fa pagare e che poi, di solito, se il lavoro va a buon fine lo si pu� 
scontare dal totale) si analizzano macroscopicamente tutte le necessit� del 
cliente e si stila un elenco di funzionalit�, di "mappe" e di controlli 
necessari... in questo modo � pi� semplice valutare i tempi, e soprattutto 
non � una attivit� "gratis et amore dei"! 

 wrote:

Fino a ieri, ti avrei risposto in un certo modo.
Dopo Osid, mi sento in dovere di dirti: "alla pene di segugio".

 seriamente e vi rivolgete ad un indovino?
individuo e suddivido per attività se non è già stato fatto, a ciascuna 
attività attribuisco una stima ottimistica e una pessimistica che 
differiscono fra loro in base all'incertezza. poi in genere la terza 
colonna è la media.
contrariamente a quello che sembra la prima parte (individuare le 
attività) è assai quella più difficile rispetto ad attribuire i numerini 
che di per se è una cazzata. infatti gli errori di valutazione più gravi 
consistono nel dimenticarsi proprio le attività e in particolare ce ne 
sono alcune che gli "inesperti" tendono a dimenticare, tipo la gestione 
del progetto o il rollout.

 rivolgete ad un indovino?
Suddividi in attività e chiedi ad ogni singola parte coinvolta. Poi
moltiplichi per 2.
  ngw

 
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
A parte che devi comunque assegnare dei coefficienti, che piu' o meno
li assegni tramite lancio dei dadi, quando l'ho proposto io mi hanno detto
(o meglio, l'aspirante manager mi ha detto): "eh.... ma il metodo 
co.co.mo
e' troppo orientato allo sviluppo, ovvero i risultati che si hanno
assegnano troppo tempo allo sviluppo..."
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

non � una attivit� "gratis et amore dei"! 
Dalle premesse "riempi sto foglio excel di numeri", possono anche
usare il metodo CDC. :)
Lo studio di fattibilita' comunque dovrebbe far parte del modello di
sviluppo.
Saluti,


 stime dei tempi di realizzazione di un progetto, che metodo adottate? 
Metto X+20% e poi consegno a X-10%.
Certo, non è da tutti... :)
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

Gi=E0 applico una formula "azzoppata" :P di Extreme Programming...
Ho letto solo l'ultimo rigo, mi fido dai.

 rivolgete ad un indovino?
Come molti ti hanno risposto, di fatto è tutto basato sull'esperienza
pregressa, molto meglio se diretta e personale.
Non dimentichiamo poi che il tempo da attribuire ad ogni attività è
fortemente legato alla capacità/esperienza di colui a cui viene
assegnata.
E' vero che puoi calcolare un range minimo-medio-massimo, ma alla fine
nel piano ufficiale devi uscire con un tempo unico, non un range. E
lì  sono dolir, se la "risorsa" assegnata ricade piuttosto verso la
stima massima.

 metti lo stesso tempo +20%;
Ecco perch� ormai vengono richiesti anche 80 gg di tempo per sviluppare 
una form di login per una webapp....
a forza di +20% chissa dove finiremo...


Cio�? Dietro la form di login ci pu� essere un mondo. Dipende da che si
sta parlando. Se di una demo, oppure di un'applicazione vera e propria.
In quei 80 gg che di metti dentro?


 ha scritto nel messaggio 
news:4a8e80d2$0$43591$4faf...@reader1.news.tin.it...

...beh... se uno ci mette ogni volta un 20% in pi�!!!! ;) 

calendario?
Perche' non ti compri un libro sul project management con la paghetta
come ti avevo gia' consigliato tempo fa, cosi' la smetti di
fossilizzarti sugli straordinari e fai un favore a tutto il gruppo?


 rivolgete ad un indovino?
per quanto mi riguarda dipende da molti fattori, alcuni di questi
fattori li posso valutare direttamente io, altri devo chiedere.
se mi viene richiesto di sviluppare una nuova funzionalità, devo
considerare se ho le conoscenze, non tanto tecniche, ma dell'ambito
della richiesta (se no aivoglia a dare stime), per esempio mi è stato
chiesto ultimamente di sviluppare una applicazione che inviasse delle
comunicazioni al personale (è poco che conosco l'ambito delle risorse
umane) quindi nella stima ho dovuto mettere in conto anche lo studio
dell'ambito applicativo e il vedere come la cosa può essere
sviluppata, incastrandosi nei processi di business gia esistenti.
la nuova funzionalità prevede la creazione di una struttura dati ex-
novo, (in test lo posso fare io, ma in collaudo e produzione c'è il
settore DBA), anche questo si deve mettere in conto.
altri fattori sono la disponibilità degli utenti per l'analisi
funzionale (riunioni, telefonate, la richiesta dei requisiti, loro
disponibilità, miei dubbi, ecc..)
extreming programming e fase di test (questi aime sono mooolto
volatili), per fare un esempio, la funzionalità di cui sopra è
completamente diversa dall'idea originale, da "comunicatore" ora è
diventato un "gestore".
comunque tutte questi fattori che sommati danno la stima, sono per la
maggior parte frutto di anni di esperienza sia tecnica che di
rapporti.
per mia personale esperienza non esiste un modello matematico certo.
comunque in genere si tende a dare X*3 e cercando di consegnare in X*2
dove X è la stima REALE.
Ciao

Il cliente ti fa sparire a pedate.
beh...se parli da tecnico, sicuramente.
Faglielo invece vendere ad uno di quei commerciali lecchini bla bla bla...
(gli esempi ci sono anche in questo ng)...
come minimo in cliente sara' convinto di aver risparmiato met� soldi !!!
ehhh le vendite....:-)))))
ciao
fm 

 Il cliente ti fa sparire a pedate.
Ferma.
La stima per un progetto non è che c'entra con il costo dello stesso.
se lavori a tempo forse hai ragione (e qui ne discutiamo), ma se
lavori a commessa, stai dicendo una fesseria.
nel caso della commessa (realizzare sito web) stimi la sua
complessita, le tecnologie impiegate, l'ambito di utilizzo, i rapporti
che devi avere con il cliente, il tempo e altre cose, ed il costo è
dato dall'insieme di tutti i fattori, non solo del tempo.
il tuo modo di ragionare è anche per le commesse, un tanto al chilo,
un consiglio che ti hanno gia dato, comprati o trova in rete argomenti
di project manager.
http://www.pmi.it/file/whitepaper/000255.pdf
http://www.pmi.it/file/whitepaper/000256.pdf
http://www.pmi.it
Ciao

 calendario?
Le risorse (da ora in poi passatemi il termine "ragazzi"... mi viene pi� 
spontaneo)... i ragazzi sono coinvolti nella stima dei tempi, quindi loro 
sanno. Il problema non � quasi mai la stima dei tempi, ma la pianificazione 
multiprogetto, dove "il battito d'ali di una farfalla....etc...etc..." 

 stime dei tempi di realizzazione di un progetto, che metodo adottate?
In genere strappo il foglio.

 In genere strappo il foglio.
e chi sei per strappare un foglio excel, clippy la graffetta di office? :-D


Ciao,
il capire quanto durer� lo sviluppo di un progetto � un problema
piuttosto annoso per il quale trovo difficile suggerire una soluzione 
definitiva.
In tutti i modi per�, si pu� provare ad utilizzare tecniche facenti 
riferimento
ai cosidetti metodi "agili", che per quella che � la mia esperienza, aiutano 
a
scrivere numerini abbastanza sensati sui fogli excel.
Il contesto nel quale queste cose tentano di dare aiuto � quello di: 
progetto
lungo/incasinato, cliente abbastanza confuso che cambia/integra/"disintegra" 
il progetto
in maniera non troppo marginale in corso d'opera.
Provo a riassumere i concetti nella maniera pi� sintetica possibile:
- Il "progetto" in quanto tale � troppo grande, gi� se supera i 3/4 gg di 
sviluppo
� difficile da stimare.
- Per il motivo di cui sopra, il progetto va diviso in parti pi� piccole e 
se queste
sono ancora difficilemte stimabili vanno divise nuovamente, fino a che non 
si ritiene
di poter dare una stima un minimo sensata sulla singola unit�.
- Quando si operano queste divisioni (gli agili le chiamano "storie") � 
importante tenere
bene presente una cosa: ogni unit� deve avere un valore business, ovvero 
deve essere
il pi� possibile "vendibile" in maniera indipendente (ovviamente non in 
senso assoluto,
ma in relazione al lavoro fatto dalle storie precedenti).
Questo diventa importante non tanto per riuscire a mettere i numeri accurati 
sull'excel
ma per impostare una certa metodologia di avanzamento del progetto.
- E' fondamentale assicurarsi di poter avere la collaborazione ed un 
feedback
continuo dal cliente, il cliente � un'attore fondamentale durante tutto il 
progetto.
- La giusta suddivisione delle storie e la collaborazione del cliente 
portano ai seguenti
vantaggi:
1) Le storie sono solitamente abbastanza corte da sviluppare (qualche giorno 
al massimo)
e dovrebbero quindi avere una stima abbastanza accurata.
2) Le featurse vengono sottoposte il prima possibile ai tester ed al cliente 
stesso, che man mano
prende visione di quello che sta "pagando" ed immediatamente propone 
modifiche o apporva
la feature.
Questo solitamente piace molto ai clienti ed evita l'armageddon, ovvero 
trovarsi a finire un mega
progettone per poi scoprire che non ci si era capiti fino in fondo.
3) L'idea � che in realt� il progetto in corso d'opera muta in maniera 
abbastanza frequente, la giusta
suddivisione iniziale delle storie � fondamentale ma � solo l'inizio.
Se c'e' la giusta collaborazione, il cliente sentir� nuove esigenze sul 
progetto che gli nasceranno al momento,
probailmente suggerite dal lavoro fatto fino a quel momento, prender� 
coscienza di quello che � davvero
indispensabile e di quello che in realt� non gli serve davvero.
Il risultato � che ci sono continuamente nuove storie da stimare, da 
dividere perch� non stimabili cos� come sono, alcune
saranno ad alta priorit�, altre diventano inutili e alla fine non si 
faranno.
Ho voluto dilungarmi su tutti questi concetti perch� ritengo importante non 
solo il "mettere i numeri"
(so benissimo che ci vogliono e secondo me la suddivisione in "storie" 
aiuta) ma anche il come si pensa di
portare avanti il progetto.
Queste cose le ho provate personalmente e secondo me sono abbastanza valide 
e portano ad un buon
livello di soddifazione sia del cliente che del team di sviluppo.
In realt� i metodi agili danno un'altra valanga di consigli che vanno dalla 
"disciplina" ("pomodori", pair programming ...)
a consigli puramente tecnici (unit test, continuos integration ... ) che se 
la cosa ti interessa puoi
trovare info in larga quantit� in rete.
Fino a qui ho fatto riferimento al come stimare le storie in maniera 
accurata, nel tempo si aggiungono coefficienti
per venire incontro agli imprevisti, ai tempi morti, all'errore medio che 
alla fine si fa sulel stime ...
Questi coefficienti sono, a mio parere, molto personali (variano a seconda 
delle risorse, del progetto, del team, ecc..)
e devono essere valutati statisticamente attarverso l'esperienza nel 
contesto in cui si fanno le stime.
Ciao e scusa se mi sono dilungato. 

 e chi sei per strappare un foglio excel, clippy la graffetta di office? :-D
Il sarcasmo questo sconosciuto ... per quanto riguarda clippy la fondo
e ne ricavo una pallattola per chi ha richiesto la stima.
:-)


e parecchio....:-)
Cmq da quanto scrivi ti vedo abbastanza a 90� di fronte al cliente (scritto 
con l'iniziale minuscola),
fatti pagare a  fine settimana, come negli USA.
ciao
fm 

 con l'iniziale minuscola),
Che c'entra il cliente? La stima dei tempi serve a te, al cliente 
traduci in richiesta di danaro frusciante.
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

1-2 ore che spesso non rientravano nella stima fatta.
Questo penso potrebbe accadere perch� non prendi "nota" in modo
sufficientemente preciso di dove ti sei fermato con il lavoro il
venerd�, di quanto hai progredito e di cosa dovrai fare il lined�
mattina appena operativo.
Per roba quick & dirty, magari ti basta anche avere un puntatore ai
files su cui lavoravi (es. "load session" e "save session" in SciTe);
per attivit� pi� complesse dello studio di un singolo sorgente e/o
programmazione veloce di un qualche script magari potresti servirti di
un logbook personale (un file di testo e un lightweight markup
language van pi� che bene) nel quale annoti i passi presenti e futuri
da eseguire.
Se invece gi� usi un sistema di tracking del tuo lavoro e ne sei
soddisfatto, il non riuscire a riprendere da un certo punto
efficacemente potrebbe essere causato da chiss� quali altre cose; in
tal caso dovresti essere pi� specifico per discuterne al meglio.

gioved=EC, 1 ora venerd=EC, mezz'ora luned=EC e mezz'ora martedi.
Perch� tanta frammentazione? E' appurato che quei tempi siano davvero
troppo esigui anche solo per divenire produttivi e concentrati come si
deve in una attivit� di sviluppo. Intendo, pu� accadere di rado e
vabb� ma non pu� essere una abitudine lavorare costantemente in
sessioni di un'ora al giorno soltanto.
In un'ora per bene ci fai giusto il timbracarte per me.

 rivolgete ad un indovino?
conosco una baronessa che può fare al caso tuo
http://www.magiamagaclara.it/

CUT
conosco una baronessa che pu� fare al caso tuo
http://www.magiamagaclara.it/
...un'altro ciarlatano, come se ce ne fossero pochi.
Questo  ha anche il sito web per fare meglio o'  bisinissi .
Naturalmente per il fisco sara' nullatenente.
Baronessa? ...rivorrei Maximilien de Robespierre.
ciao
fm 

 rivolgete ad un indovino?
Bella questione.
1.
Come molti hanno detto la prima cosa da fare e polverizzare il progetto in
micro unita isolate + le trasversali
2.
Stimi le microunita'
3.
Una tecnica che uso spesso e' di fare le stime delle microunita' da 2
persone senza influenzarsi e confrontarle e in particolare discutere le
microunita' discordanti
4.
Dopo questa stima fatta in modo "tecnico" io faccio una contrro stima con un
altra logica inversa. Suddivido il prugetto per unita' funzionali. Ogni
unita' funzionale ha un suo "costo da pescheria" cioe' chesso una tabella
col suo crud e la navigazione non e' che puo' valere 20k e comuqneu la somma
delle unita' funzionali = costo del progetto.
Quindi un crud mi aspetto che costi 2-3k e valutando il giorno/uomo a 400
vale 5-7 giorni uomo
Si verifichera' che quasi sempre i giorni uomo calcolati in reverse con sto
metodo vanno a concordare con quelli calcolati col punto 2. Se c'e'
discrepanza si analizza e si apre il "caso"
Al tutto poi metto sempre in fondo
2-3 giorni di refactorng per pulizia ( facoltativi )
testing se si prevede di farlo, puo' essere 1 o 0.5 giorno per task o 1
settimanella a fondo progetto
tuning 1-2 settimane imho obbligatorio
ciauz N
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> Quando vi danno un foglio excel e vi dicono di riempirlo di numerelli per le
ah, ed ecco una delle (molte) cose di questo lavoro che sono frutto
dell'esperienza e non delle chiacchere metodologiche di turno. Oddio,
in realtà le stime le fanno tutti, con i punti fusione, contando le
maschere, qualche pazzo masochista usa l'uml ecc...
Comunque, per un progetto tecnico io scompongo in elementi unitari,
non necessariamente funzioni o maschere, dipende dal tipo di progetto,
poi faccio una semplice moltiplicazione ed applico dei coefficienti
correttivi che variano dalla tecnologia al cliente al tipo di attività
ecc...
PS: quello che mi ha insegnato questo lavoro mi diceva di fare la tua
stima, moltiplicare per 2 e poi cambiare l'unità di misura. Quindi
stima 8 ore, moltiplicate sono 16, cambiando unità 15 giorni. Ma erano
altri tempi.

 altri tempi.
io questa regola la conoscevo con una moltiplica per tre ;^)
bye!

 riferimento ai cosidetti metodi "agili", che per quella che è la mia esperienza, aiutano
C'è un aspetto fondamentale dei metodi "Agili" che secondo me va
sempre sottolineato : serve il cliente giusto.
Permettendo infatti una ampia libertà al cliente che può chiedere
modifiche in corso d'opera i costi possono lievitare, i tempi
allungarsi e se il cliente non ha voglia di collaborare / non ha le
idee chiare, il progetto va a finire malissimo.