Domanda

Quando stimano la dimensione relativa delle storie degli utenti nello sviluppo di software Agile, i membri del team dovrebbero stimare la dimensione di una storia dell'utente come 1, 2, 3, 5, 8, 13, ... Quindi i valori stimati dovrebbero assomigliare alla serie Fibonacci. Ma mi chiedo, perché?

La descrizione di http://en.wikipedia.org/wiki/planning_poker Su Wikipedia detiene la frase misteriosa:

Il motivo per l'utilizzo della sequenza di Fibonacci è riflettere l'incertezza intrinseca nella stima di elementi più grandi.

Ma perché dovrebbe esserci un'incertezza intrinseca negli articoli più grandi? L'incertezza non è più alta, se effettuiamo meno misurazione, il che significa che un minor numero di persone stimano la stessa storia? E anche se l'incertezza è più alta nelle storie più grandi, perché ciò implica l'uso della sequenza di Fibonacci? C'è una ragione matematica o statistica per questo? Altrimenti usare la serie Fibonacci per la stima mi sembra di Cargocult Science.

È stato utile?

Soluzione

La serie Fibonacci è solo un esempio di una scala di stima esponenziale. Il motivo per cui viene utilizzata una scala esponenziale proviene dalla teoria dell'informazione.

Le informazioni che otteniamo dalla stima crescono molto più lenti della precisione della stima. In effetti cresce come una funzione logaritmica. Questo è il motivo della maggiore incertezza per gli articoli più grandi.

Determinare la base più ottimale della scala esponenziale (normalizzazione) è difficile nella pratica. La base corrispondente alla scala Fibonacci può o meno essere ottimale.

Ecco una spiegazione più dettagliata della giustificazione matematica: http://www.yakyma.com/2012/05/why-progretive-estimation-scale-is-so.html

Altri suggerimenti

Tra i primi sei numeri della sequenza di Fibonacci, quattro sono Prime. Ciò limita le possibilità di abbattere un'attività equamente in compiti più piccoli per far sì che più persone ci lavorino in parallelo. In questo modo potrebbe portare all'idea sbagliata che la velocità di un'attività potrebbe ridimensionare proporzionalmente al numero di persone che ci lavorano. La serie 2^N è più vulnerabile a tale problema. La sequenza di Fibonacci in realtà costringe a ripristinare i compiti più piccoli uno per uno.

Secondo Questo blog agile

"Perché crescono alla stessa velocità con cui noi umani possiamo percepire cambiamenti significativi di grandezza."

Si, come no. Penso che sia perché aggiungono un'aria di legittimità (Fibonacci! Matematica!) A quello che è in sostanza un esercizio di dimensionamento (non Scoping) di livello molto alto (che ha valore).

Ma puoi ottenere gli stessi risultati usando il dimensionamento della maglietta ...

Vuoi sicuramente qualcosa di esponenziale, in modo da poter esprimere qualsiasi quantità di tempo con un errore relativo costante. È molto probabile che la precisione della tua stima sia proporzionale alla tua stima.

Quindi vuoi qualcosa: a) con numeri interi b) esponenziale c) facile

Ora perché Fibonacci invece di, 1 2 4 8? La mia ipotesi è che è perché Fibonacci diventa più lentamente. È in Golrato^n e GoldRatio = 1.61 ...

La sequenza di Fibonacci è solo una delle tante utilizzate nella pianificazione del progetto.

È difficile stimare accuratamente grandi unità di lavoro ed è facile impantanarsi nelle discussioni su ore rispetto ai giorni se i tuoi numeri sono troppo "realistici".

Mi piace la spiegazione a http://www.aglelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/, vale a dire la serie Fibonacci rappresenta un insieme di numeri che possiamo distinguere intuitivamente tra loro come magnitudini diverse.

Uso Fibonacci per un paio di motivi:

  • Man mano che l'attività diventa più grande, i dettagli diventano più difficili da cogliere
  • La stima dell'attività è il numero di ore per chiunque nella squadra per completare l'attività
  • Non tutti nella squadra avranno la stessa quantità di esperienza per un compito particolare in modo che anche si aggiunge all'incertezza
  • L'uomo ottiene affaticamento su un compito più grande e potenzialmente più complesso. Mentre un compito due volte come complesso è risolto nel doppio tempo per un computer, potrebbe richiedere un po 'di più per uno sviluppatore.

Mentre aggiungiamo tutte le incertezze, siamo meno sicuri di quali dovrebbero essere le ore. Finisce più facile se possiamo solo valutare se questa attività è più grande/più piccola di un'altra in cui abbiamo già dato una stima. Mentre aumentiamo le dimensioni/complessità del compito, l'effetto dell'incertezza è anche amplificato. Prenderei felicemente una stima di 13 ore per un compito che sembra due volte più grande di quello che ho precedentemente stimato a 5 ore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top