math - planificacion - scrum sprint planning poker
¿Por qué se usa la serie Fibonacci en el póker de planificación ágil? (6)
Al estimar el tamaño relativo de las historias de usuario en el desarrollo de software ágil, se supone que los miembros del equipo estiman el tamaño de la historia de un usuario como 1, 2, 3, 5, 8, 13, .... Entonces los valores estimados deberían parecerse a la serie de Fibonacci. Pero me pregunto, ¿por qué?
La descripción de http://en.wikipedia.org/wiki/Planning_poker en Wikipedia contiene la misteriosa oración:
La razón para usar la secuencia de Fibonacci es reflejar la incertidumbre inherente en la estimación de artículos más grandes.
Pero, ¿por qué debería haber incertidumbre inherente en los artículos más grandes? ¿No es mayor la incertidumbre si hacemos menos mediciones, es decir, si menos personas estiman la misma historia? E incluso si la incertidumbre es mayor en las historias más grandes, ¿por qué eso implica el uso de la secuencia de Fibonacci? ¿Hay una razón matemática o estadística para ello? De lo contrario, usar la serie de Fibonacci para la estimación me parece ciencia de CargoCult.
De acuerdo con este blog ágil
"porque crecen a una velocidad similar a la que los humanos podemos percibir cambios significativos en magnitud".
Sí claro. Creo que es porque agregan un aire de legitimidad (¡Fibonacci! Matemática!) A lo que es, en esencia, un ejercicio de muy alto nivel, de tamaño inicial (no de alcance) (que sí tiene valor).
Pero puedes obtener los mismos resultados usando el tamaño de la camiseta ...
De los primeros seis números de la secuencia de Fibonacci, cuatro son primos. Esto limita las posibilidades de dividir una tarea por igual en tareas más pequeñas para que varias personas trabajen en paralelo. Hacerlo podría llevar a la idea errónea de que la velocidad de una tarea podría escalar proporcionalmente al número de personas que trabajan en ella. La serie 2 ^ n es más vulnerable a tal problema. La secuencia de Fibonacci de hecho obliga a uno a volver a estimar las tareas más pequeñas una por una.
Definitivamente quieres algo exponencial, para que puedas expresar cualquier cantidad de tiempo con un error relativo constante. La precisión de su estimación también es muy probable que sea proporcional a su estimación.
Entonces quieres algo: a) con números enteros b) exponencial c) fácil
Ahora, ¿por qué Fibonacci en lugar de, 1 2 4 8? Supongo que es porque el fibonacci crece más lento. Está en goldratio ^ n, y goldratio = 1.61 ...
La secuencia de Fibonacci es solo una de varias que se usan en la planificación de proyectos de póquer.
Es difícil estimar con precisión grandes unidades de trabajo y es fácil atascarse en las discusiones de horas versus días si sus números son demasiado "realistas".
Me gusta la explicación en http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/ , es decir, la serie de Fibonacci representa un conjunto de números que podemos distinguir intuitivamente entre ellos como diferentes magnitudes.
La serie de Fibonacci es solo un ejemplo de una escala de estimación exponencial. La razón por la que se usa una escala exponencial proviene de la Teoría de la información.
La información que obtenemos de la estimación crece mucho más lentamente que la precisión de la estimación. De hecho, crece como una función logarítmica. Esta es la razón de la mayor incertidumbre para los artículos más grandes.
Determinar la base más óptima de la escala exponencial (normalización) es difícil en la práctica. La base correspondiente a la escala de Fibonacci puede o no ser óptima.
Aquí hay una explicación más detallada de la justificación matemática: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
Yo uso Fibonacci por un par de razones:
- A medida que la tarea se hace más grande, los detalles se vuelven más difíciles de captar
- La estimación de tareas es la cantidad de horas para que cualquiera en el equipo complete la tarea
- No todos en el equipo tendrán la misma cantidad de experiencia para una tarea en particular, lo que aumenta la incertidumbre también.
- El ser humano se fatiga por una tarea más grande y potencialmente más compleja. Si bien una tarea dos veces más compleja se resuelve en el doble de tiempo para una computadora, puede tomar bastante más para un desarrollador.
A medida que sumamos todas las incertidumbres, estamos menos seguros de cuáles deberían ser las horas realmente. Termina siendo más fácil si solo podemos medir si esta tarea es más grande / más pequeña que otra en la que ya hemos dado una estimación. A medida que aumentamos el tamaño / complejidad de la tarea, el efecto de la incertidumbre también se amplifica. Estaría felizmente tomando un estimado de 13 horas para una tarea que parece ser el doble de una que he estimado previamente en 5 horas.