Presentando stime agili per il progetto Pivotal Tracker

Question

Presentando stime agili per il progetto Pivotal Tracker

#1 da (1 voti)

1

Ho sviluppato per 6-7 anni ma mai in modo particolarmente agile. Con l'ultimo progetto sto cercando di rendere il nostro processo di sviluppo più professionale e più agile.

Stiamo utilizzando Pivotal Tracker per tracciare il progetto e abbiamo raccolto alcune storie ben pensate. Stiamo anche cercando di mantenere felici alcuni dei nostri project manager (Prince2 / Waterfall mind.)

Finora li ho accettati per accettarlo

requisiti cambiano sempre
cambiano sempre
alcuni requisiti non verranno forniti se si aggiusta la scala temporale
devi correggere la scala temporale
gli sprint brevi e la revisione regolare sono buoni

Tuttavia sentono ancora di aver bisogno di ottenere una presa migliore di circa quanto verrà consegnato entro un certo tempo.

Ho trovato un foglio di calcolo per dimostrare cosa ci si aspetta di fare in un intervallo di 4 diverse scale temporali.

Domande

Ci stiamo preparando per fallire
Ci sono modi migliori per farlo

estimation agile

posta Tom Styles 22.10.2013 - 10:42

fonte

1 risposta

Leggi altre domande sui tag estimation agile

Acquisizione ricorsiva dei dati della tabella relazionale in XML Animazione personalizzata iOS

score 1 · Accepted Answer

Il pericolo con questo foglio è che può essere facilmente letto come una pianificazione finale con garanzie. Le persone trascurano la piccola stampa (le note in basso). Mentre anche le scatole verdi non sono garantite.

In un progetto a cui sto lavorando, stiamo lottando con lo stesso. Stiamo cercando di non dare stime; difficile ma non impossibile. Abbiamo trovato alcune cose.

È molto pericoloso dare stime (o persino garanzie) quando qualcosa è fatto. La gente dimentica che hai detto loro che nulla è garantito; "perché vorresti altrimenti dire che verrà fatto la prossima settimana?". Quando non ce la fai, la gente si arrabbia.
Quando le persone hanno una data, la comunicano all'esterno (leggi i client). Poi dà ancora più fastidio quando non ce la fai, dato che devono tornare dalla persona esterna e dire che non ci sarà (quando ne avranno bisogno).
È meglio, e più facile, dare loro una visione dei progressi attuali. Uno strumento comune in agile, naturalmente, è un grafico di masterizzazione. Nel nostro progetto utilizziamo una scheda Trello , molto simile a questo . ( Ecco la nostra scheda Trello , ma è in olandese, quindi potresti non ottenere tutto.) Li terremo aggiornati su se qualcosa è stato elaborato e quali risultati genera. Aggiungiamo note, progetti di interazione, progetti grafici, schermate, ecc. A volte chiediamo anche feedback o per testare insieme. Ciò coinvolge le persone in quello che sta succedendo.
Appena possibile, trasmetti il mantra che il prodotto è già stato fatto e ottieni miglioramenti nel tempo. Questo aiuta le persone a non aspettare un momento specifico. Questo è più difficile quando la base del prodotto non è ancora lì. Anche se devi stare attento che "la base" è sempre estesa.

Non importa quanto buone siano le tue storie, c'è il rischio che durino più a lungo o che non ci arrivino affatto. Ci è capitato parecchie volte di dover ripensare completamente una funzionalità; trova un'altra soluzione per il problema sottostante; o vieni alla conclusione che non ha più una priorità assoluta. Tutto ciò incasina così tanto la pianificazione, che è davvero difficile dare delle stime.