¿Por qué usamos puntos de historia en lugar de días de hombres cuando estimamos historias de usuarios?

132

En metodologías ágiles (p. Ej. SCRUM), la complejidad / esfuerzo necesario para las historias de los usuarios se mide en puntos Story. Los puntos de historia se usan para calcular cuántas historias de usuario puede tomar un equipo en una iteración.

¿Cuál es la ventaja de introducir un concepto abstracto (puntos de la historia), donde podemos usar una medición concreta, como los días hombre estimados? También podemos calcular la velocidad, estimar la cobertura de una iteración, etc. usando días-hombre estimados.

En contraste, los puntos de la historia son más difíciles de usar (porque el concepto es abstracto) y también más difíciles de explicar a los interesados. ¿Qué ventaja ofrece?

Louis Rhys
fuente
16
¿por qué asumes que el día del hombre es más concreto que el punto de la historia, no lo es?
Ryathal
44
¿Es más fácil explicar que su estimación de 5 días-hombre significa que tardará 1 mes en completarse porque su velocidad es de 0.25 días-hombre / día calendario?
Patrick
3
@Izkata eso solo es cierto si tu velocidad siempre es exactamente 1
Patrick
44
@Patrick Cuando se usan días-hombre (ver horas-hombre en Wikipedia), no hay un concepto de velocidad. Eso es algo ágil / scrum.
Izkata
3
Lo interesante es que tan pronto como la velocidad se estabiliza, los puntos de la historia tienden a identificarse con un cierto número de horas o días. Por ejemplo, 1 punto de historia = 1 día. Si creo que tomará 2 días, estimaré 2 puntos de historia.
Giorgio

Respuestas:

126

Creo que una de las principales ventajas es que los humanos y los desarrolladores específicamente son bastante malos para estimar el tiempo. Piense también en la naturaleza del desarrollo: no es una progresión lineal de principio a fin. A menudo es "escribir el 90% del código en 10 minutos y luego arrancarte la depuración durante 17 horas". Eso es bastante difícil de estimar en el sentido del tiempo del reloj.

Pero el uso de una abstracción elimina el enfoque del tiempo real en horas o días y, en cambio, se enfoca en describir el gasto relativo y la complejidad de una tarea en comparación con otras tareas. Los humanos / desarrolladores son mejores en eso. Y luego, una vez que empiece a tararear con esas estimaciones puntuales y algún progreso real, puede comenzar a mirar el tiempo de manera más empírica.

Sospecho que también hay un efecto observador que ocurre con las estimaciones de tiempo que no sucederían con las estimaciones puntuales. Por ejemplo, el incentivo para hacer una estimación de la bolsa de arena y entregarlo "antes de lo previsto" se silenciará con la indirección en un sistema basado en puntos.

Erik Dietrich
fuente
28
+1 para centrarse en la complejidad , no en el tiempo. Traducir a horas crudas será fácil una vez que tenga suficientes sprints en su haber. Descubrí que la variabilidad entre las historias se desvanece con el tiempo.
Kristo
14
Entonces, realmente, los puntos de complejidad pueden ser un término más claro que los puntos de la historia, y cualquier tarea con demasiados puntos de complejidad es demasiado compleja y probablemente implique demasiados riesgos e incógnitas para tratar de una sola vez. La complejidad tiene un costo exponencial, y el pobre pobre que se queda atascado con esa tarea cavará un hoyo tan profundo que no lo volverán a ver en semanas o meses. Mejor hacer primero una tarea más simple de comprender la tarea compleja, y dividirla en tareas más pequeñas con una complejidad menos arriesgada y mejor entendida.
Supr
44
El tiempo y el costo son efectos, la complejidad es la causa y no se puede entender el tiempo sin comprender la complejidad.
Supr
8
Puntos de historia = Puntos de complejidad - 2 sílabas. :-D
Kristo
55
¿Alguien ha considerado llamar a los puntos de la historia "costo de lanzamiento"? => nerd
Aaron Gibralter
59

Si usa números de Fibonacci (o algo similar), limita el número de opciones al estimar una historia. Trabajé con un grupo que solo usaba números bajos: 1, 2, 3, 5, 8 y 13. Teníamos una historia de referencia que era un 5. Esto nos permitió tomar decisiones rápidas sobre la complejidad de una historia mientras hacía Planning Poker . El otro efecto secundario fue que cualquier cosa calificada como 13 probablemente tenía información insuficiente y necesitaba ser desglosada aún más. Dudo seriamente que hubiera sido tan fácil y sencillo si estuviéramos usando horas crudas.

El propietario de su producto habla el idioma de sus partes interesadas y debería poder traducir entre puntos de historia y horas de trabajo (u otras unidades) según sea necesario. Durante mi tiempo como OP, tuve algunos datos sólidos de que 1 punto de historia = 4 horas-hombre, pero obviamente cada equipo es diferente.

Editar:

Con el conocimiento de que 1 punto = 4 horas, teóricamente podrías cambiar tu mazo de Planning Poker a 4, 8, 12, 20, 32 y 52. ​​Pero esos números se sienten más difíciles de manejar. Creo que mentalmente abstraería los valores de regreso a algo simple, por ejemplo, "menos de un día", "más de una semana", etc. Y si voy a hacer eso, también podría seguir con la unidad abstracta sin puntos de historia.

Kristo
fuente
Utilizamos este mismo método, y nuestro mazo de planificación tiene números más altos, pero hemos definido un 20 como que necesita desglosarse o definirse mejor. Para nosotros, un 13 es nuestra tarea más grande y, por lo general, estas son tareas que terminan tomando hasta una semana en terminar.
Bill Leeper el
"El otro efecto secundario fue que cualquier cosa calificada como 13 probablemente tenía información insuficiente y necesitaba ser desglosada aún más". Y supongo que si se descompone aún más, se dividirá en partes equivalentes de Fibonacci.
Joe Z.
@JoeZeng, sí, esos a menudo se convirtieron en 8 + 5 o 5 + 5 + 3. Sin embargo, es una medida abstracta, así que si las nuevas historias son lo suficientemente cercanas, entonces no me preocuparía demasiado. El equipo normalmente podría absorber un 13 convirtiéndose en dos 8 o tres 5, pero tres 8 significaba que necesitaba tener una charla aclaratoria con las partes interesadas. Idealmente, habíamos estimado con suficiente antelación que no afectaría el sprint actual.
Kristo
1
No necesariamente. Hemos tenido suposiciones sobre que las historias tienen 5 puntos, y una suma más detallada y desglosada está en el rango de 15 puntos. Sucede.
cenizas999
24

Es para permitir que la estimación mejore con el tiempo, sin que todos los estimadores tengan que ajustar su estimación.

En lugar de que todos los involucrados en la estimación tengan que pensar como "OK ... parece 2 días hombre ... pero el último sprint subestimamos todo, así que tal vez sean realmente 2,5 días hombre. ¿O 3?", Continúan igual que siempre. "¡5 puntos de historia!"

Luego, ajusta su estimación de cuántos puntos de historia puede superar el equipo en un sprint, en función del logro real medido en sprints anteriores. "¡Hemos estado haciendo 90-110 puntos de historia por sprint anteriormente!"

Diría que la teoría detrás de esto es que los desarrolladores son mejores para estimar la complejidad relativa de diferentes tareas de desarrollo que para estimar los absolutos . Especialmente si varias personas están estimando una tarea que podría realizar cualquiera de ellos (y no todos trabajan a la misma velocidad que los demás).

Alternativa cínica: lo he visto decir que los desarrolladores nunca llegan bajo estimaciones de tiempo. Si algo lleva más tiempo de lo estimado, te habrás ido. Pero si algo lleva menos tiempo de lo estimado, los desarrolladores pueden jugar con él, dorar, o simplemente reducir la velocidad y tomarlo con calma ya que se les ha asignado una tarea cómoda. Tomar las unidades de tiempo reales de una estimación puede frenar estas tendencias. Fin de la alternativa cínica.

Carson63000
fuente
13
Eso ni siquiera es tan cínico. Es el principio de "rápido, barato o bueno". Puedo darte una versión de FizzBuzz en su mayoría estable y en funcionamiento que te dará lo que generalmente quieres en unos minutos, pero si quieres interacción con el usuario, eso llevará más tiempo, y si quieres pruebas de regresión, eso tomará más tiempo, y si desea que no falle cuando presione MAX_INT, eso llevará más tiempo. Dígame que priorice la velocidad y comenzaré a eliminar los requisitos. Dígame que priorice todo lo demás, y lo usaré todo el tiempo que me den.
deworde
17

Los días del hombre o las horas del hombre son, como usted dice, concretos. Entonces, cuando una tarea se estima en 5 horas y toma 6, ahora es una tarea tardía.

Cuando tienes una historia que tiene 3 puntos y lleva 6 horas, tomó 6 horas, no es tarde, solo tomó seis horas. La medición de la velocidad es más un factor de cuántos de esos puntos se hacen en un sprint, y ese número puede fluctuar, porque no es concreto. Tampoco está midiendo cada tarea, sino el total de todas las tareas. Cuando tienes horas en cada tarea, la tentación está ahí para medir cada tarea. Cuando eso sucede, no obtienes ningún beneficio para el sprint por terminar con el tiempo y es una consecuencia por terminar con el tiempo de una tarea determinada.

Puede ser una transición al pensamiento en términos de puntos. Trabajé en un lugar antes de que incluso introdujiéramos camisetas ágiles usadas solo para tener una idea del nivel de esfuerzo. Los puntos son solo una extensión de eso.

Eso no quiere decir que no haya controversia, o alguna asignación arbitraria a los puntos. Tenemos miembros de nuestro equipo que casi siempre votan el número más bajo y se quejan cuando piensan que una tarea es un 1 y creemos que es un 3 que estamos sufriendo de inflación puntual.

Bill Leeper
fuente
13

La abstracción es una especie de punto. Usar el 'día del hombre' como medida tiene una serie de dificultades, que incluyen:

  1. Si el equipo no está familiarizado con la tecnología que van a utilizar, puede ser muy difícil dar estimaciones en tiempo real de cuánto tiempo puede llevar una tarea. Es mucho más probable que puedan dar buenas estimaciones relativas, por ejemplo, "la tarea A probablemente tomará el doble de tiempo que la tarea B".
  2. ¡Diferentes personas trabajan a ritmos diferentes! Si usa 'días hombre', prácticamente tiene que cambiar el tiempo estimado cuando se pasa una tarea de un desarrollador a otro. ¿Quién define cuánto trabajo constituye un 'día del hombre' de todos modos?

Si desea estimar días-hombre, es un cálculo simple:

user points in story / average user points per developer per day = estimated man days
vaughandroid
fuente
Con respecto al punto 2: ¿cómo resuelve esto el punto de la historia? Estima una historia como 4 puntos de historia. Se lo da a un programador más rápido y demora 4 días. Se lo das a un programador lento y tarda 8 días. Me parece que el problema no se resuelve sino que simplemente se mueve.
Giorgio
Con respecto al punto 1. La idea es que si el equipo se familiariza más con las tecnologías necesarias para el proyecto, su velocidad aumentará y el tamaño relativo de las historias, medido en puntos de historia, seguirá siendo el mismo. Pero, ¿qué pasa si dos historias de usuario requieren un conocimiento diferente? Por ejemplo, tiene una historia de usuario de front-end que se debe hacer en Javascript / HTML y una historia de usuario de back-end que se debe hacer en Java. A medida que el equipo aprende más sobre Javascript, HTML y Java, descubren que la parte de front-end es mucho más fácil que la parte de back-end y las estimaciones relativas de las historias vuelven a estar equivocadas.
Giorgio
@Giorgio Re. punto 2: su programador más rápido tiene una tasa de trabajo de 1 punto de historia / día, y su programador más lento tiene una tasa de trabajo de 0.5 puntos de historia / día. Si lo hace en horas, o su programador más rápido va a trabajar hasta la muerte, o su programador más lento necesita ser despedido. La respuesta de Bill Leeper hace este punto muy bien.
vaughandroid
1
Re. punto 1: por mi dinero, si estás hablando de 2 conjuntos diferentes de tecnología y 2 áreas diferentes del producto, tienes dos equipos.
vaughandroid
Más re. punto 2: las historias de usuarios son desarrolladas por el equipo , no por desarrolladores individuales. Es la tasa de trabajo del equipo que es la parte importante. Tenga en cuenta que al implementar historias de usuarios, primero debe dividirlas en tareas. ¡Dele al desarrollador más rápido más tareas!
vaughandroid
6

Como ya se mencionó, los puntos de la historia son una medida relativa de complejidad. Se puede usar la potencia de 2 series (1,2,4,8,16 ...) o una escala de Fibonacci (1,2,3,5,8,13,20 ...) para la estimación. Como los desarrolladores propuestos son bastante expertos en decir algo como esto:

La función A es casi dos veces más difícil que la función B

Pero es realmente difícil decir "cuánto tiempo" llevará esta característica para su implementación. Dejas que eso sea equilibrado por la velocidad. Entonces, si algo se estimó como un 5 pero resultó ser un 13, una velocidad más lenta normalizaría eso para la iteración (o podría volver a estimar).

Ahora, hay otra alternativa, se llama 'días ideales' (algo similar a los días hombre pero no estoy seguro de si eso es lo que querías decir) y sé de algunos equipos que prefieren eso. Los días ideales deben interpretarse como:

Si eso es todo lo que hago después de llegar a la oficina y tomar solo los descansos necesarios, no tengo interrupciones y tendré todo lo que necesito para 'implementar la historia', es decir, no actividades periféricas como reuniones, responder correos electrónicos, etc.

Mike Cohn, uno de los muchos evangelistas ágiles bien conocidos, ofrece la siguiente comparación entre los puntos de la historia y los días ideales.

Puntos de historia

  • Ayuda a impulsar el comportamiento interfuncional, es decir, los equipos estiman historias con una complejidad de implementación total desde la interfaz de usuario hasta la base de datos y viceversa.
  • Las estimaciones de SP no decaen, es decir, dentro de unos meses, es probable que una historia de 5 puntos sea de 5 puntos, pero una estimación del día ideal puede cambiar dependiendo de la habilidad / velocidad de desarrollo adquirida de ese programador en particular
  • Los SP son una medida pura del tamaño, es decir, solo reflejan el tamaño y la complejidad del wrt. Período. Sin duración, etc., tirarlo. Ese es el trabajo de la velocidad. Pero no es así con los días ideales. De hecho, con los días ideales hay una tendencia a confundirlo con los días calendario. Manteniéndolo abstracto como SP lucha contra la tentación de comparar con la realidad. Solo una medida de tamaño. Sin tonterías.
  • Es típicamente más rápido que los días ideales. Puede ser complicado para el primer par de historias, pero una vez que te acostumbras, es más rápido.
  • Los diferentes desarrolladores pueden tener una opinión diferente sobre su estimación de día ideal para completar una historia. Yo podría hacer lo mismo en 3 y tú en 5. Los SP son más o menos uniformes en todos los ámbitos. Nivelan el campo de juego, por así decirlo.

Días ideales

  • Más fácil de explicar fuera del equipo; por obvias razones :)
  • Más fácil de estimar al principio como se mencionó anteriormente. Pero una vez que te acostumbras a los SP, es algo natural

Ahora, cuál elegir depende del equipo. Sin embargo, como la mayoría de las respuestas aquí y mi experiencia personal, prefiero los puntos de la historia. Los días ideales realmente no tienen tanto beneficio sobre los SP (y Mike Cohn también aboga por SP junto con muchos otros evangelistas ágiles).

Doctor
fuente
El próximo número de Fibonacci es 21, no 20.
Joe Z.
44
21 o 20 no importa al estimar. Los SP completan el siguiente número de Fibonacci para eliminar la sensación de falsa precisión. El siguiente número en la secuencia no es 34 sino 40 (doble de 20) y luego 100. Los números representan 'incertidumbre' en complejidad y no en precisión. Es solo una aproximación.
Doctorado
1
Eso es cierto, solo estaba recogiendo liendres (y bromeando).
Joe Z.
1
@PhD: "Las estimaciones de SP no decaen, es decir, dentro de unos meses, es probable que una historia de 5 puntos siga siendo de 5 puntos, pero una estimación del día ideal puede cambiar dependiendo de la habilidad / velocidad de desarrollo adquirida de ese programador en particular": asume implícitamente que el equipo mejorará sus habilidades de manera uniforme en todas las áreas del proyecto. No veo por qué este debería ser siempre el caso: algunas partes de un proyecto (y las tecnologías necesarias para ellos) podrían resultar más difíciles que otras, lo que invalida la estimación inicial de las complejidades relativas en los puntos de la historia.
Giorgio
3

Los puntos de historia también lo ayudan a medir la mejora del rendimiento del equipo con el tiempo. Además, no necesita volver a estimar todo a medida que mejora el rendimiento.

Tome este ejemplo que usa días hombre:

El equipo estima diferentes tareas con días-hombre. Funciona por un tiempo, pero después de un tiempo ves que el equipo se hace más rápido con muchas tareas de lo que originalmente se pensaba. Entonces el equipo vuelve a estimar las tareas. Funciona por un tiempo, y después de un tiempo vuelves a ver lo mismo: el equipo se hace más rápido con muchas tareas nuevamente. Entonces vuelves a estimar nuevamente, y esta historia se repite una y otra vez ...

¿Por qué? Porque el rendimiento de su equipo aumentó. Pero no lo sabes.

El mismo ejemplo con puntos de historia:

El equipo estima el tamaño de las historias de los usuarios. Después de algunos sprints, ves que el equipo puede hacer alrededor de 60 puntos de historia por sprint. Más tarde, verá que el equipo ha logrado más de 60 puntos de historia, tal vez 70. Y el equipo continúa así y saca más historias de usuarios para los próximos sprints y los entrega.

¿Por qué? Porque el rendimiento ha aumentado. Y puedes medirlo. Y no necesita volver a estimar todo después de que el rendimiento de su equipo haya aumentado.

Uooo
fuente
3
"¿Por qué? Debido a que el rendimiento de su equipo aumentó". estimación de historias para sprints posteriores).
Giorgio
2

Primero, las personas son mejores en estimaciones relativas que en estimaciones absolutas. El mapeo de los babilonios y la calificación del brillo relativo de las estrellas es un gran ejemplo. No obtuvieron las cifras absolutas correctas, pero el orden fue mayoritario incluso para intensidades muy similares.

La segunda ventaja es que una razón principal para hacer este ejercicio es impulsar la conversación. Si comienza a discutir en días exactos, la conversación puede descarrilarse rápidamente.

Como dijo Napoleón: el plan no tiene valor, la planificación es invaluable.

En tercer lugar, el gerente del proyecto no tiene que editar todas las estimaciones, solo porque resulta que las estimaciones estaban apagadas por un factor de, por ejemplo, 130%.

Tormod
fuente
0

Los Story Points reflejan la complejidad del problema y, por lo tanto, reflejan la confianza (o riesgo) de cuán precisa es la estimación.

Una historia con un punto de historia alto me dice que están sucediendo muchas cosas con la historia del usuario que no es concreta.

La idea es ver cuál es un buen equilibrio entre los diferentes puntos de la historia. Si se me muestra un plan de iteración con historias con todos los puntos importantes de la historia, esto me da poca confianza en que la iteración se ejecutará como se esperaba y que necesitamos ver otras historias para la iteración o comenzar a desglosar las historias.

Cuando se comunica con un gerente o propietario del producto, los puntos importantes de la historia significan que será extremadamente confuso cuándo obtendrán una característica particular. Una de las soluciones a esto es desglosar la historia y, con suerte, tendrá una combinación de puntos de historia bajos y altos con los que trabajar para que pueda demostrar de manera iterativa el progreso al propietario del producto.

grumpasaurus
fuente
0

Los días del hombre estiman el tiempo que lleva hacer algo. Se utilizan mejor cuando los elementos que está estimando son muy precisos y medibles. Las tareas específicas, bien conocidas y repetibles son estimables en días humanos.

Por ejemplo, si una persona de ventas puede hacer 20 llamadas de clientes por día, en promedio, podemos calcular cuánto tiempo toma cada llamada y a partir de eso podemos estimar cuántos días hombre tomará hacer 1000 llamadas.

En este ejemplo, se puede pensar concretamente en términos estadísticos acerca de la duración media de una llamada porque se puede suponer que todas las llamadas son efectivamente la misma cosa.

Los puntos de historia determinan qué combinación de historias se puede hacer en una iteración. Se utilizan para combinar objetivos heterogéneos con límites difusos y para medir cuántos se pueden hacer en un marco de tiempo fijo. Estiman la complejidad de los fragmentos de trabajo comparados entre sí para poder sumarlos.

Por ejemplo, su equipo desarrolló 5 historias para un total de 23 puntos en la iteración 1, y 8 historias para 20 puntos en la iteración 2. A partir de esto, puede estimar que en la iteración dos su equipo hará algunas historias cuyo total es de alrededor de 20 puntos en iteración 3.

Tenga en cuenta que no necesitamos determinar el tamaño de un punto y, en particular, ¡no se asume que cada historia del mismo tamaño llevará el mismo tiempo para desarrollarse! Solo trabajamos con sumas y puntos por iteración. Ni siquiera mencioné cuánto dura la iteración.

Sklivvz
fuente
0

Si caminas hacia un humano en la calle y le preguntas "¿Qué tan grande era un T-rex?" las respuestas fluctuarían aunque la mayoría de los humanos sepan qué es un T-rex, qué tan grande era, pero nadie lo sabe con certeza, porque NO tenemos una escala relativa desde la línea de base.

Ese es el comportamiento cognitivo que estás tratando de descubrir con el pronóstico y muchas metodologías giran ciclos con "¡ Lo tengo! .. ¡Tengo el secreto para un pronóstico preciso! ", El aceite de serpiente para las masas. Cuando realmente pronosticas, estás diciendo en voz alta " PERMITIRÉ x días / horas / puntos para que eso se complete ", es en cierto sentido crear una "caja de tiempo" para que ese evento se lleve a cabo dentro.

Para mí, Points solo está cambiando los límites, al final del día, a menos que estés en un equipo que esté feliz de decir " * Bueno, tenemos 3 semanas por sprint y chupa el pulgar ... Supongo que deberíamos disparar por ¡30 puntos para completar en ese ciclo! ¡Quién está conmigo! * "Y eso es lo más profundo que puede llegar en el modelado de pronósticos, ¡bien! ..asisticamente, solo estás estableciendo un presupuesto arbitrario y eso es todo. También estás en retrospectiva mirando el trabajo completado con una sensación de "mierda sagrada, hicimos 33 puntos que corrieron, eso fue bastante bueno" y no se puede hacer mucho al respecto. Puede usar la velocidad para determinar la mitad del sprint que está recibiendo su inversión de presupuesto preguntando en voz alta " ¿Ya hemos alcanzado los 15 puntos? ¿Lo haremos?""pero el peligro aquí es que ahora estás usando Velocity para medir la productividad, no la capacidad, que por lo que entiendo patea la gestión de liberación reactiva (puntos de historia) en la cabeza ...

El sistema de puntos es casi demasiado inteligente como para no darse cuenta de que todavía le asigna un tiempo relativo a la ecuación, todo, desde sus "ciclos de sprint" acordados hasta sus paradas diarias en las que promulga alguna regla oculta sobre la duración + complejidad = " Max se está demorando demasiado con esa tarea "instinto innato código del equipo momento rojo?

El cerebro humano no puede pronosticar porque implica una gran cantidad de memoria de trabajo mezclada con un recuerdo a largo / corto plazo, por lo que es como pedirle a un estudiante de matemáticas novato que haga fracciones en su cabeza, no en papel ... Es por eso que otras industrias nunca acuerdan un pronóstico y validar constantemente los pronósticos en un tiempo relativo (por ejemplo, el geólogo nunca detiene el modelado de pronósticos hasta que ese metro cúbico haya sido excavado del suelo y luego esté "listo").

Yo diría que el sistema de puntos funciona si no estás pronosticando . Estás de acuerdo con una gran parte del trabajo que se basa en un algoritmo de sub-fragmentación, pero ese es realmente tu enfoque más cercano a la predicción como sea posible. De hecho, la administración de su versión buscaría interrupciones naturales en la cola de "trabajos pendientes" que se ajustan a los temas (es decir, en Silverlight, los gerentes de producto esperaríamos hasta después de completar su trabajo atrasado y juntar los temas que establecimos inicialmente. nunca supimos lo que el equipo de ingeniería estaba haciendo específicamente, solo teníamos un esquema básico. Luego tomábamos ese cuerpo de trabajo y construíamos nuestro evento de marketing en torno a él (Microsoft Mix))

Cuando comienzas a bloquear las expectativas de velocidad dentro de los ciclos de sprint que dependen de la velocidad + el tiempo, vuelves a pronosticar las estimaciones nuevamente solo que esta vez estás peor porque estás jugando el juego "depende" ... Más importante aún También está matando el potencial para el crecimiento del equipo / crecimiento profesional también.

El impuesto que paga por Puntos vs Tiempo es con los puntos que necesita para buscar fórmulas de medición alternativas para rastrear el desarrollo / mentoría de habilidades laborales o el comportamiento del desarrollador.

Como aún necesitará mirar a un "desarrollador mediano" como su persona ideal para unir habilidades / esfuerzos, puede poner en línea a otros desarrolladores con esa persona para determinar cómo se desenvuelven en su crecimiento continuo dentro de su equipo. También destaca situaciones en las que los desarrolladores "rápidos" llevan la mayor parte del agua, pero se están aburriendo o peor, están trabajando más horas y no hay reconocimiento / recompensa debido a plazos competitivos, etc. allí para detectar malos olores dentro del equipo por decir, como en "esa persona está luchando, vamos a ayudar"

A continuación también vienen las historias de "arrastre", historias que no se agrupan en ese ciclo de sprint pero luego se extienden al siguiente ciclo de sprint. Lo que luego puede crear fácilmente un efecto indirecto si está factorizando en el tiempo, pero en el momento en que sí tiene en cuenta el tiempo relativo ... nuevamente, simplemente regresó a "pronóstico / estimación basado en el tiempo" y nuevamente el sistema de puntos es solo enturbiando las aguas.

Si vas a puntos, ignoras el tiempo por completo y me refiero completamente al momento en que dejas pasar el tiempo, estás jugando con la idea / metodología.

Después de haber viajado por todo el mundo como evangelista, vi que muchos equipos juraban lo que querían que habían descifrado el código del Pronóstico Ágil ... pero siempre hacía clic en mi lengua, sonreía y me alejaba con el pensamiento " sí ... casi lo hiciste, pero esa amante que llamamos 'tiempo' ... ella es cruel ... "

Scott Barnes
fuente
-1

El libro de Mike Cohn "Estimación y planificación ágiles" describe las ventajas y desventajas de estimar con "días ideales" o puntos de historia, por lo que la respuesta rápida a su pregunta es que no tiene que estimar con puntos de historia. Si es más natural estimar en días ideales, adelante.

David M
fuente
1
Esto no necesariamente responde la pregunta; solo proporciona una referencia de libro en su lugar. Podría fortalecer su respuesta al proporcionar un resumen de las ventajas y desventajas.
-1

Creo que el método Story Point tiene al menos dos ventajas importantes sobre el método del día del hombre: Primero, es más fácil de estimar en SP. SP es relativo y los humanos como nosotros son mejores en estimación relativa que absoluta como el método del día del hombre.

En segundo lugar, cuando calcula en SP, obtiene "Team SP" y no "Individual Manday". Cuando preguntas "¿Cuánto tiempo llevará esta tarea?", El desarrollador Senior puede darte 1 día pero 5 días para un Junior. Ese es Man-Day depende de quién llevará a cabo esa tarea. Si el propietario se ve obligado a cambiar (¡y lo hará!), Debe volver a programar todo. Con SP, sigue siendo el mismo quien toma la tarea.

Amp Tanawat
fuente
-1

Me sorprende que nadie haya mencionado la Ley de Parkinson todavía.

El trabajo se expande para llenar el tiempo disponible para su finalización.

Básicamente, si está estimando en cualquier tipo de unidad de tiempo para tareas grandes, los desarrolladores tenderán a tomarse el tiempo que estimaron para completarlo o repasarlo. Cuando calcula en un tiempo nebuloso como Story Points o Shirt Sizes, evita esta trampa.

Vadim
fuente
1
"Cuando estimas en un tiempo nebuloso como Story Points o Shirt Sizes, evitas este escollo": No realmente: si durante un sprint de 2 semanas me han asignado dos historias de usuario por un total de 10 puntos de historia, puedo tomar el dos semanas enteras y establezca la velocidad en 5 puntos de historia por semana. Creo que el aumento de la productividad tiene más que ver con la motivación del equipo y las condiciones de trabajo que con la unidad utilizada para medir la complejidad de las tareas.
Giorgio
No me refería al aumento de la productividad, más al hecho de que si una estimación de una historia llega a 3 días. Es mucho más probable que un desarrollador tarde 3 o más días en terminarlo que entrar por debajo de la estimación.
Vadim
¿Hay buena evidencia para la ley de Parkinson? La página de Wikipedia no parece mencionar ninguna.
bdsl
-2

La estimación del punto de la historia sigue la serie de Fibonacci 1,2,3,5,8,13,21 ...

Un cerebro humano puede mapear fácilmente cosas en función de los tamaños. Por ejemplo: tenemos una tarjeta postal y le asignamos un punto de historia 2 y tres el tamaño de la tarjeta significaría 2 * 3 = 6 puntos de historia.

Story Point 6 se encuentra entre las series de Fibonacci número 5 y 8, siendo 5 el número más cercano y, por lo tanto, el punto de la historia sería 5.

ecoGreen
fuente
1
No mapeamos las cosas en función del tamaño, en realidad utilizamos la memoria de trabajo para tratarlas como "esquemas" para trabajar. Al igual que nuestro cerebro tiene una pequeña cantidad de RAM que, cuando introducimos pequeños patrones discernibles en (Fibonacci, A000079, camisetas, etc.), estos pueden atraer a nuestros poderes cognitivos intrínsecos para ayudar a proyectar en este caso, una respuesta. .que es realmente un modelo de "pronóstico relativo".
Scott Barnes