Come stimare le ore di progetto utilizzando il tracker principale se si è un'azienda di servizi?

Naviga le tue risposte
1

Sono nuovo di Pivotal Tracker e sto cercando di imparare come utilizzarlo al meglio per la nostra attività. Siamo una società di servizi di consulenza per lo sviluppo di app. Come sapete, i clienti vogliono avere un'idea del tempo e dei costi totali prima di firmare qualsiasi contratto.

Come stai mappando il tuo progetto su Pivotal a ore e scadenze totali? Qualche buona pratica? Puntatori?

In questo momento io e il mio team abbiamo infranto il progetto in storie (amo come Pivotal ci fa pensare a un livello molto più basso) e abbiamo approssimativamente mappato i punti in ore.

  • 1 - 1 ora
  • 2 - 2 ore
  • 3 - 6 ore
  • 5 - 10 ore

Quindi pensiamo fondamentalmente a 2 come un quarto di giorno, 3 come 3/4 al giorno e 5 come un giorno intero o un po 'più lungo.

Poi calcolo quanti 1, 2, 3 e 5 dobbiamo ottenere una stima approssimativa delle ore totali. Pivotal mi fornisce una stima della data di completamento in base alla velocità predefinita (so che questo può cambiare). Riporto quindi le ore totali approssimative, i costi e la data di scadenza al mio cliente. Capisco che questo è agile e iterativo dove le cose cambiano, ma quando le persone assumono te come consulente vogliono i costi in anticipo.

    
posta Anand C 12.01.2012 - 18:30
fonte

2 risposte

6

Stai tentando di riutilizzare uno strumento di pianificazione del progetto agile in uno a cascata.

Non sono un esperto, ma questo è il problema che Agile intende affrontare, ad esempio: "Rispondere al cambiamento dopo aver seguito un piano" . "Going Agile" implica una sorta di compromesso - esaltando costi e scadenze concreti per la flessibilità e la reattività dello sviluppo. In poche parole, il cliente deve (delicatamente) porre la seguente domanda:

Which of these is more important to your business, the features or the delivery/cost?

NB: Questa è un'abbreviazione di una regola empirica comunemente accettata, vedi il commento di Thomas Owens sotto ri: triangolo di gestione del progetto. Ho scelto di presentare un tocco leggermente più cinico su di esso ...

Inevitabilmente, i clienti vogliono entrambi, ma gli eserciti di sviluppatori / agenzie bruciati mostrano che la stima anticipata raramente corrisponde alla realtà dell'esecuzione e generalmente questo porta a orribili straordinari o consegne "in ritardo" ea clienti arrabbiati.

L'intero punto di Agile è che si tratta di un tentativo di portare un elemento di empirismo alle date di consegna, misurando le prestazioni in termini di velocità relative alla "complessità del compito". IMO il problema è che hai equiparato la dimensione della storia con stime orarie. Il significato della dimensione della storia dipende interamente da come lo si suddivide, motivo per cui 1-5 non è già presentato come unità di tempo (a differenza degli strumenti di stima tipici).

Se hanno assolutamente bisogno di una stima concreta, allora non sono pronti per una relazione Agile, quindi usa il metodo rispettato nel tempo per completare il tuo programma, e spera che la competizione stia inserendo più padding di te.

Come ho detto, non sono un esperto, ma ho vissuto un'esperienza simile a quella che stai descrivendo, e ho anche fatto una domanda simile: Finanziare progetti agili

EDIT: JFTR - Approvo vivamente Pivotal Tracker, lo abbiamo ampiamente utilizzato nell'ultimo progetto a cui ho lavorato, ma è stato un po 'un cambio di paradigma per il team di gestione / vendite per fare un giro ... come illustrato da la discussione sopra, Agile non è una vendita così semplice al di fuori della comunità di sviluppatori /

    
risposta data 12.01.2012 - 19:10
fonte
0

Fondamentalmente stai provando a fare sia Agile che Waterfall nello stesso momento, che è una cattiva idea.

Questo è dettagliato qui: link

    
risposta data 24.04.2012 - 02:00
fonte

Leggi altre domande sui tag

Entity Framework e "ViewModel" Controlli condizionali contro un elenco