2012-02-23 13 views
5

Acabamos de comenzar a hacer scrum en mi empresa. Estamos gastando un poco de tiempo en estimar el esfuerzo utilizando la planificación del póquer y luego, cuando las tareas detalladas se resuelven, se asigna un tiempo estimado a cada tarea.Estimación del tiempo en las tareas

El problema que tenemos es que las estimaciones de tiempo son constantemente erróneas (por lo general, más de lo estimado). Aunque todos podemos estar de acuerdo en un esfuerzo, lograr que un equipo acuerde el tiempo para una tarea es mucho más difícil: lo que le lleva a 1 persona por hora puede llevarle a otra persona 3 horas. Terminamos yendo a algún lugar en el medio.

¿Quién debería tener el tiempo estimado para una tarea y cuándo sucede esto?

¿Es esto algo a lo que necesitamos más práctica o lo estamos haciendo mal?

Respuesta

8

Las personas que realmente hacen el trabajo estiman el costo involucrado. Si está utilizando el tiempo sin procesar como una métrica para la estimación, las metodologías ágiles no le dan importancia. Su equipo debería usar una abstracción para estimar el costo, como "puntos". Puede comenzar con una línea base aproximada de 1 hora por punto con un mínimo de 1 punto. Entonces los desarrolladores pueden hacer estimaciones en bruto de cuánto tiempo debería tomar algo. Ponles una bofetada a ellos oa alguien más en la muñeca si hablan en horas o en cualquier otra unidad de tiempo.

El punto es que a medida que el desarrollo avanza a través de múltiples sprints, los gerentes de proyecto pueden ajustar las estimaciones de tiempo "puntuales" proporcionadas por el equipo para que coincidan con la realidad. Esto se puede hacer por desarrollador individual. Los participantes serán cada vez mejores a medida que avancen los proyectos. Entonces, dado que Sprints es un proceso iterativo, las estimaciones de tiempo mejoran con más iteraciones.

Esto plantea otra pregunta: ¿Por qué te preocupa el tiempo? El tiempo es básicamente costo en el modelo Waterfall. En Agile, el objetivo es desarrollar software a VALOR sin costo. El motivo por el que se utilizan los puntos es que se trata de una base de comparación abstracta que los propietarios de negocios, los gerentes de proyecto y los creadores (desarrolladores) pueden ver en forma abstracta. (Sin importar las percepciones culturales, sociales o psicológicas del tiempo de los participantes). Los dueños de negocios pueden echar un vistazo a los puntos disponibles en un sprint dado, y conociendo los puntos disponibles, pueden elegir la funcionalidad que es más importante. Siempre es una decisión un poco difícil, pero una vez más, el objetivo es desarrollar hacia el valor y lejos del tiempo de boxeo o relleno de características.

+0

Gracias por la respuesta .Estamos usando la plantilla ágil TFS y tiene Esfuerzo en un PBI/Error, pero las tareas individuales tienen tiempo. Todo el quemado ocurre desde el momento. ¿Es solo una breve venida del modelo de Microsoft? Si no le damos tiempo, no obtenemos una quemadura para decirnos cómo vamos – Greg

+2

Como dijo aquí, no debe usar el tiempo sin procesar para su estimación, o mejor: no puede usar el tiempo como valor de costo en Scrum. Solución para su problema: Adhiérase a los puntos de las historias, pero NO calcule las tareas únicas. Si desea crear su burndown, cuente las tareas y divida los puntos de la historia con el recuento de tareas; por ejemplo, Story tiene 8 puntos, tiene 4 tareas, por lo que cada tarea tiene un valor de 2 puntos. Si resuelve 2 tareas durante el día, su burndown disminuirá 4 puntos. –

+1

Como ha señalado, el tiempo utilizado para una tarea depende de la persona que trabaja en ella. Pero la idea de los puntos de la historia es no depender de las personas. El equipo está en foco. Entonces, los puntos reflejan cuánto esfuerzo de equipo necesita para cumplir esta historia. Simplemente haz lo mismo con las tareas. Si desea estimar el esfuerzo de cada tarea individualmente, solo use el punto del cuento. La suma debe redondear a los puntos de la historia de acuerdo con la historia. – RaphMclee

-1

"¿Quién debería tener el tiempo estimado para una tarea y cuándo sucede esto?" Depende de cómo manejas tu equipo. ¿Dejas que los miembros del equipo realmente se autogestionen, por lo que las tareas se asignan cuando una persona lo agarra durante el sprint? Puede que tenga que seguir usando el tiempo para completar en función de las capacidades de un desarrollador promedio en el equipo. ¿Tiene un líder de equipo que asigna las tareas a las personas a medida que se crean durante la reunión de planificación de Sprint? Deje que la persona asignada calcule el tiempo para completar la tarea.

Acepto que quitar tiempo de la estimación de esfuerzo es un poco confuso. La gran pregunta es: ¿qué importa que estés sobreestimando el tiempo de la tarea? ¿Está el equipo sentado durante 4-5 días al final de un sprint sin nada que hacer? Si es así, ve al propietario del producto y hazle saber que el equipo quiere agregar uno o dos artículos pequeños al Sprint. Normalmente no agrega cosas a un sprint continuo, pero Scrum es un marco para administrar el trabajo, y mientras el equipo cierre la sesión al agregar los nuevos elementos, no hay necesidad de dejar que Scrum trabaje para su equipo ... .no obligue a su equipo a trabajar para Scrum.

Además, sus preguntas parecen indicar que su equipo tiene una velocidad mayor a la que se planea. Si tu carrera de 2 semanas (10 días hábiles) tiene una velocidad de 10, pero tu equipo se está completando todo el día 7, solo sube tus puntos en el siguiente sprint a 11 o 12.

+0

Me gustaría saber por qué mi respuesta fue rechazada. –

Cuestiones relacionadas