Stima del tempo per una user story

Question

Come stimare il tempo necessario per implementare una user story? Se è qualcosa che hai fatto prima di sapere quanto tempo ci vorrà. E se fosse completamente nuovo per te? Quanto tempo ti riservi per "sorprese"?

Answer 1

Un'ottima tecnica per questo è quella di spezzare la storia in compiti un po 'più piccoli e stimarli confrontandoli l'uno con l'altro (invece che assolutamente). Quindi puoi dire:

• L'attività A richiederà 2 unità (arbitrarie)
• L'attività B è circa 2 volte più complicata dell'operazione A (4 unità)
• L'attività C è complicata per circa la metà (1 unità)

Siamo più bravi a stimare la complessità relativa che la complessità assoluta. Quindi esegui effettivamente una delle attività e scopri quanto "tempo reale" ti serve per implementare 1 unità - ora puoi calcolare tutte le attività. Continui ad aggiornare le tue stime in base ai tuoi progressi.

Questa tecnica è tratta da Stima e pianificazione agile di Mike Cohn, che è un grande libro sull'argomento.

Answer 2

Nella scuola di sviluppo agile di XP, sostengono che non si stima in tempo reale ma in unità arbitrarie. (Usano " Gummy Bears " ma puoi usare qualunque cosa). Assegni la tua ipotesi migliore al numero di unità necessarie per implementare quella user story.

È vero, potresti avere torto, ma colpirai una fase del tuo sviluppo, alcune iterazioni, quando le tue ipotesi sono per lo più giuste, ed è facile per l'azienda / il cliente ottenere un bilancio accurato di quante storie possono includere in un'iterazione.

Una buona regola empirica nelle fasi iniziali quando è difficile stimare, è quella di prendere una delle attività più semplici e assegnarla a un valore di 1. Valutare le storie degli altri utenti in relazione a quella, e dare il massimo indovina. Se qualcosa è troppo complicato o non sufficientemente definito, sarai costretto a dargli un numero davvero grande.

Un altro concetto chiave è che è necessario rivalutare i tempi per ogni user story ogni iterazione. Man mano che le tue storie vengono meglio definite e mentre migliora la stima della tua velocità, otterrai tempi più precisi sulle tue storie.

Per quanto riguarda le sorprese, in realtà non si basa sulla stima delle storie degli utenti ... dal momento che non hai storie utente per rappresentare le sorprese.

Answer 3

Steve McConnel in " Stima del software - demistificazione dell'arte nera " lo dicevo meglio di quanto avrei fatto:

  

" Contare se possibile. Calcola quando   non puoi contare. Usa il giudizio da solo   solo come ultima risorsa. "

Capitolo 7 - Count, Compute, Judge (PDF).

(grazie per avermelo ricordato :)

Answer 4

Una tecnica implementata dove lavoro. Per ogni storia utente, scrivila su un pezzo di carta con un'intestazione. Fai in modo che ogni persona prenda una carta e scriva su di essa il numero di ore che pensa ci vorranno per completare. Falli posizionare le carte contro l'attività senza mostrarle l'una all'altra. Una volta che avrai tutti i risultati a guardare le figure e vedere i valori superiore e inferiore. Normalmente otterrai cifre abbastanza vicine tra loro.

Per quei valori molto al di sopra o molto al di sotto, chiedi allo sviluppatore o alla persona con l'input perché pensano che richiederebbe così tanto o così poco rispetto alla media. Venire a trovare un consenso da parte della squadra rispetto a un individuo significa che tutti prendono la loro decisione sull'attività.

Questa è un'idea di un libro che ho letto su tecniche agili e che ho dimenticato all'autore di accreditarle.