2010-01-19 14 views
7

Habiendo usado "días" como unidad para la estimación de tareas en Scrum, me resulta difícil cambiar a Story Points. Creo que los puntos de la historia deberían usarse, ya que son más comparables entre sí, menos dependientes de las calificaciones de quien aborda la tarea, etc. Sin embargo, no es fácil hacer que un equipo comience a usar Story Points cuando están acostumbrados a hacerlo. estimando en días.Cómo cambiar para usar Story Points para estimaciones en Scrum

Entonces, ¿cómo hacer que un equipo cambie a Puntos de historia? ¿Qué debería motivar a los miembros del equipo a hacerlo y cómo deberíamos aplicar el cambio?

+0

Ver http://stackoverflow.com/questions/414346/giving-estimates-for- proyectos a gran escala en un entorno ágil, y todos estos: http://stackoverflow.com/search?q=[agile]+estimate –

Respuesta

4

Si desea cambiar el uso de puntos de historia en lugar de duración, debe comenzar a estimar en puntos de historia. (Supongo que usted tiene la autoridad para tomar esa decisión para su equipo.)

Seleccione una escala, podría ser pequeña, mediana, grande podría ser una secuencia de fibonacci, podría ser de 1 a 5, cualquiera que sea la que elija y use durante varios sprints esto le dará su velocidad. Si comienzas a cambiar la escala de uno a otro, entonces la velocidad entre escalas no será comparable (es decir, no lo hagas). Estas estimaciones deben incluir todo su equipo de Scrum.

Habiendo dicho que todavía necesita una idea de cuánto le costará esto. No hay muchos contadores que aceptarán la respuesta "Te diré cuánto costará esto en 6 meses". Por lo tanto, aún necesita estimar el proyecto en duración también, esto le dará el costo. Probablemente, este cálculo lo realizará una persona mayor en el equipo

Luego, cada mes, su velocidad le indicará a usted y a los contadores qué tan preciso fue el primer cálculo de costos y puede adaptarse en consecuencia.

2

Comience haciendo que un día sea igual a un punto (o una proporción estricta). Es una buena manera de comenzar. Después de un par de sprints, puede comenzar a alentarlos a utilizar más puntos relativos (es decir, qué tan grande es esto en comparación con esa cosa).

1

El problema es que los puntos de la historia definen el esfuerzo.

Los días son de duración.

Ambos tienen una relación casi aleatoria. . Esa función se basa en la habilidad de la persona que realmente hace el trabajo.

Una persona sabe cuánto tiempo tardarán en hacer el trabajo. Eso es duración. En días.

No conocen esta cosa abstracta de 'esfuerzo'. No saben cuánto tiempo una persona hipotética de habilidades promedio requerirá para hacerlo.

Lo mejor que puede hacer es ambos: puntos de historia (esfuerzo) y días (duración).

No puede reemplazar una con la otra. Si intenta utilizar solo esfuerzo, eventualmente tendrá que llegar a días para planificar. Tendrás que aplicar una persona a los puntos de la historia y calcular la duración del esfuerzo.

+0

Sí, pero necesita una forma de estimar el esfuerzo y la duración es una buena primera aproximación. El truco es usarlo para arrancar y luego alejarse de él. Consulte "Estimación y planificación ágiles" por Mike Cohn, que describe esta técnica. Además, la velocidad (Puntos de historia/Tiempo) le proporciona una forma de medir la duración, que promedia esto sobre el equipo. Con el tiempo, la velocidad se vuelve muy estable y se puede usar para planificar con bastante precisión. –

+0

Pragmáticamente, todavía necesita ambos. La relación de duración a esfuerzo, incluso asumiendo un equipo muy estable, no es simple ni lineal.Además, el supuesto de "equipo muy estable" rara vez se cumple en la práctica. No está claro cuál es la estimación de "velocidad". ¿Es una duración utilizada para recortar el esfuerzo en algo que se puede entregar? ¿Se usa el esfuerzo para avanzar hacia una duración esperada según la composición actual del equipo? Parece ser a la vez: esfuerzo y duración mushed juntos. –

+0

Obtiene la duración de la velocidad, la velocidad a la que su equipo puede implementar la funcionalidad. Pero esto plantea la pregunta: ¿por qué necesita saber la duración? ¿Es para la planificación de sprint? Entonces no necesitas duración, necesitas esfuerzo porque puedes derivar velocidad del esfuerzo y el trabajo de sprint se mide en términos de velocidad (puntos por sprint). ¿Es para la planificación de lanzamiento? Entonces puedes derivar la duración de la velocidad; el lanzamiento tomará sprints (puntos totales/velocidad) por la longitud de un sprint (+/- para el Cono de Incertidumbre que se estrechará a medida que progreses). –

11

Cuando cambié a puntos, lo decidí solo si podía cumplir con los dos puntos siguientes; 1) búsqueda y argumento que justifican el cambio y que convencerá al equipo 2) Encuentra un método sencillo para usarlo.

Convencer

Me tomó un montón de lectura sobre el tema, sino un fin encontró el argumento de que mi equipo y yo convencido: Es casi imposible encontrar dos programadores que ponerse de acuerdo sobre el tiempo de una tarea tomará pero los mismos dos programadores casi siempre acordarán cuál tarea es la más grande cuando se muestran dos tareas diferentes.

Esta es la única habilidad que necesita para "estimar" su retraso. Aquí utilizo la palabra 'estimar', pero en esta etapa inicial es más como ordenar el retraso de lo difícil a lo fácil.

Poniendo puntos en la reserva de pedidos

Este paso se realiza con la participación de todo el equipo de scrum.

Comience a dejar caer las historias una por una en una nueva hoja de cálculo, manteniendo el siguiente orden: la historia más grande en la parte superior y la más pequeña en la parte inferior. Haz eso hasta que todas las historias estén en la lista.

Ahora es el momento de poner puntos en esas historias. Personalmente utilizo la Escala de planificación de póker (1/2,1,2,3,5,8,13,20,40,100) así que esto es lo que usaré para este ejemplo. Al final de la lista, es probable que tengas micro tareas (cosas que tardan 4 horas o menos en hacerlo). Dé a cada micro tareas el valor de 1/2. Luego, continúe en la lista dando el valor 1 (siguiente en la escala) a las historias hasta que quede claro que la historia es mucho más grande (2 en lugar de 1, por lo tanto, dos veces más grande). Ahora, usando el valor '2', continúe en la lista hasta que encuentre una historia que claramente debe tener un 3 en lugar de un 2. Continúe este proceso hasta el final de la lista.

NOTA: Trate de mantener la gran mayoría de los puntos entre 1 y 13. La primera vez puede tener un montón de historias importantes (20, 40 y 100) y tendrá que frenarlas en trozos menor o igual a 13.

Eso es todo por los puntos y la acumulación original. Si alguna vez tienes una historia nueva, compárala con esa lista para ver dónde encaja (proceso más grande o más pequeño) y dale el valor de sus vecinos.

velocidad & Estimación

Para estimar el tiempo que le llevará a pasar por estos pagos pendientes, hace la primera planificación del sprint. Haga el total de los puntos adjuntos a las historias que eligieron los equipos y ¡VOILA !, esa es su primera medida de velocidad. A continuación, puede dividir el total de puntos en la acumulación de esa velocidad, para saber cuántos sprints se necesitarán.

que la velocidad va a cambiar y se asientan en los primeros 2-3 carreras así que siempre es bueno mantener un ojo en ese valor

+0

Si necesita más información sobre el proceso, responderé a cualquier pregunta – pcantin

+1

Buena explicación, Gracias :) –

Cuestiones relacionadas