¿Cómo proporcionamos estimaciones de tiempo válidas durante la planificación de Sprint sin hacer un diseño "demasiado"?

9

Mi equipo se está poniendo al día con Scrum, pero la mayoría de nosotros estamos más familiarizados con las metodologías no ágiles o "pseudo-" ágiles. La parte que es el mayor obstáculo para nosotros es llevar a cabo una reunión eficiente de Planificación de Sprint en la que dividimos nuestros elementos atrasados ​​en tareas y estimamos las horas. (Estoy usando la terminología de la plantilla VS2010 Scrum; disculpas si uso la palabra incorrecta en alguna parte).

Cuando intentamos calcular cuánto tiempo llevará una tarea, a menudo caemos en la trampa de diseñar la función a nivel de código (diseño de tabla, interfaces, etc.) para determinar cuánto tiempo llevará eso. .

Estoy bastante seguro de que este no es el lugar apropiado para hacer ese tipo de diseño. Deberíamos programar tareas para estas reuniones de diseño durante el sprint. Sin embargo, estamos teniendo problemas para encontrar la manera de obtener estimaciones significativas para las tareas.

¿Existen hábitos / técnicas prácticas / etc. por hacer una llamada de juicio sobre cuánto tiempo llevará una característica, sin saber cómo planea implementarla? Si nuestras estimaciones de tiempo van a cambiar significativamente una vez que se haya completado el diseño, ¿cómo podemos presupuestar adecuadamente nuestra reserva de Sprint con anticipación?

EDITAR:

Solo para aclarar, ya que algunos de los comentarios / respuestas son muy válidos, pero creo que abordar la pregunta incorrecta.

Nosotros sabemos que lo que estamos haciendo no está bien, y que deberíamos construir el tiempo en el sprint para este diseño. Conceptualmente, todos los desarrolladores entienden eso. También traemos a un miembro del equipo con experiencia Scrum para mantenernos en el camino si comenzamos a adentrarnos en la maleza.

El problema es que, sin pasar por este proceso de diseño, nos resulta difícil proporcionar estimaciones de tiempo concretas para cualquier cosa. Constantemente decimos cosas como "bueno, si lo diseñamos de esta manera, podría tomar 8 horas, pero si terminamos teniendo que hacerlo de otra manera, eso tomará alrededor de 32, pero podría no ser tan malo una vez que comencemos a escribirlo ... ".

También supongo que este proceso mejorará una vez que tengamos cierta velocidad histórica para trabajar, pero muchas de las tecnologías y patrones arquitectónicos que estamos utilizando son nuevos para nosotros. Pero si las estimaciones potencialmente erróneas son solo una parte natural de la adaptación de este proceso, entonces solo tendremos que reacondicionarnos para aceptar eso :)

KutuluMike
fuente
¿Qué quieres decir con "apropiado"?
Robert Harvey
Quiero decir que no creo que el equipo deba dedicar entre 25 y 30 minutos al diseño técnico de una función durante la planificación del sprint, pero esa es solo mi intuición (que está haciendo que nuestras reuniones de planificación sean muy largas).
KutuluMike
Tienes razón Michael. Acabo de pensar en otra cosa que agregaré a mi respuesta a continuación. Esencialmente, si está planeando sprint sin un patrocinador comercial allí de algún tipo, entonces realmente no sabe qué priorizar. Más abajo.
Ian
1
Tienes dos opciones. Puede extender la duración de la fase de diseño para que pueda obtener estimaciones adecuadas, o puede vivir dentro de su restricción de tiempo autoimpuesta y aceptar conjeturas salvajes. También puede acumular tiempo en los sprints para el diseño (lo que tendrá que hacer de todos modos) y modificar sus estimaciones de trabajo cuando se complete la fase de diseño.
Robert Harvey
Supongo que la parte de "enmendar sus estimaciones de trabajo" es lo que es una lucha para nosotros; algunos miembros del equipo insisten más que otros en que no damos estimaciones de horas si no sabemos que están en lo correcto. También espero y espero que mejoremos con el tiempo, pero claramente, "todos los demás" logran hacerlo bien, así que siento que hay algo obvio que me estoy perdiendo.
KutuluMike

Respuestas:

14
  1. Programe una reunión periódica de "preparación" donde tenga estas discusiones de diseño. El equipo en el que estoy los tiene una vez por sprint, el día antes de la planificación. El objetivo allí es tener el diseño lo suficientemente definido como para que el equipo pueda acordar las estimaciones de tiempo para la historia general. Puede considerar desglosar las tareas en esta reunión, de modo que la planificación se convierta simplemente en un ejercicio para decidir cuánto recoger. En otras palabras, debe hacer el diseño en los sprints ANTES de comenzar a hacer el trabajo real.

  2. Considere usar el póker de planificación , es decir, puntos / unidades de "esfuerzo" en lugar de días-hombre para estimar las tareas. Intenta también desglosar las historias tanto como puedas. Cuanto más larga / más compleja es una historia, menos probable es que su estimación sea precisa.

  3. En la planificación, el scrum master debe mantener la planificación en marcha al detener cualquier discusión que llegue demasiado lejos a la "resolución". En ese punto, se requiere que los miembros del equipo lleguen rápidamente a un acuerdo sobre la estimación, generalmente dando un número de límite superior / peor caso. Es mucho más fácil retomar más trabajo si las tareas terminan siendo más fáciles de lo que planeas, que lidiar con el retraso de los cronogramas debido a que las tareas toman más tiempo de lo planeado y las historias pasan a varios sprints.

  4. Hable acerca de cómo se obtuvieron las estimaciones en la retrospectiva al final del sprint. Particularmente si hubiera alguno que estuviera notablemente lejos. ¿Aprendió el equipo algo de cómo fue la historia versus cómo esperaban que fuera? El scrum master debe centrarse en los cambios accionables que se pueden realizar en su proceso de diseño / estimación.

mongiesama
fuente
Marqué esto como la respuesta porque parece llegar a la raíz de nuestro problema: tenemos que hacer más trabajo inicial antes de la reunión de planificación para que comprendamos mejor los elementos atrasados ​​y las tareas involucradas una vez que lleguemos allí.
KutuluMike
10

Creo que el problema es que estás tratando de estimar el tiempo. No lo hagas

Estime la complejidad. Mire un requisito, (con suerte una historia de usuario) y califique qué tan complicado cree el equipo que será descubrir cómo construirlo y probarlo, en relación con lo complicados que son otros requisitos o historias de usuario. A veces te equivocarás, pero a menudo tendrás una buena idea de lo difícil que va a ser algo. También encontrará que los elementos que son casi de la misma complejidad tienden a requerir la misma cantidad de esfuerzo para completarse.

Por lo tanto, las clasificaciones de complejidad se convierten en los "puntos de historia" asociados con las historias de usuario en la cartera de productos. Después de trabajar algunos sprints, tendrás una idea de cuántos puntos de la historia puedes superar en un sprint, y esa es tu velocidad. En ese momento, tendrá una idea mucho mejor de cuánto tiempo llevará cada elemento.

Recomiendo encarecidamente las historias de usuario de Mike Cohn aplicadas .

Matthew Flynn
fuente
Eso tiene sentido, pero estamos tratando de seguir la Plantilla Scrum VS2010, en la teoría de que muchas personas inteligentes que saben lo que están haciendo se les ocurrió. Si no estamos estimando las horas, ¿cómo hacemos un seguimiento de cosas como el trabajo restante en las tareas o producir un gráfico de quemado?
KutuluMike
No realiza un seguimiento del trabajo restante en las tareas. O está hecho o no lo está. Al comienzo de un sprint, el equipo se compromete a realizar una cierta cantidad de historias, en función de su prioridad, cuán complejas son y la mejor estimación del equipo sobre cuánta complejidad pueden enfrentar. En la reunión de planificación de Sprint, deben decidir qué tareas se requieren para completar las historias. Estas tareas conforman la cartera de pedidos del sprint; solo puede decir que son 1 punto cada una para el sprint. A medida que se completan, se pueden marcar como hechas.
Matthew Flynn
No es necesario que haya ninguna relación entre los puntos de complejidad en la cartera de pedidos del Producto y los puntos de tarea en la cartera de Sprint. Actualizas el backlog de Sprint diariamente, marcando las tareas. Actualizas la cartera de pedidos del producto al final del sprint, cuando has demostrado que se han completado historias completas.
Matthew Flynn
Hrm, entonces realmente estamos haciendo algo mal. Sé que hay más de una forma de hacer Scrum, pero esta es la guía que estamos usando, que dice que debe rastrear el trabajo restante en una tarea: msdn.microsoft.com/en-us/library/ff731574.aspx . ¿Eso no está bien?
KutuluMike
3
Ahhhhh Veo. No está mal como tal, pero obviamente no es particularmente útil para usted. La Guía Scrum dice "A medida que el trabajo se realiza o se completa, el trabajo restante estimado se actualiza", por lo que la plantilla de MS tiene sentido. Como dije, sin embargo, no es realmente una métrica útil: nadie hace un buen trabajo al estimar el trabajo restante para una tarea, y usted pierde el tiempo tratando de hacerlo. Haga sus tareas pequeñas y binarias (0 = hecho o 1 = no), y tendrá una medida de lo que se hizo y lo que queda, y no tiene que pensar en ello.
Matthew Flynn
6

Sé que su pregunta es específicamente sobre evitar el diseño en la planificación. Pero esto es una especie de problema XY .

He estado donde estás En lugar de darle algo que pueda proporcionar una mejora incremental, me gustaría ayudarlo a superar algunos de esos estados intermedios.

Aquí hay tres cosas que nuestro equipo hace específicamente relacionadas con la planificación y ejecución del trabajo. Estos nos han ayudado a evitar la agitación del diseño y escapar de estimaciones de tiempo inexactas.

Criterios de aceptación automatizables

Nuestras historias están señaladas por su número de Criterios de aceptación automatizables . Esto significa que si escribiéramos pruebas automatizadas para confirmar que la historia está hecha, ¿qué serían?

Por ejemplo, "Cuando el usuario hace clic en 'reproducir' en un iPad con iOS 6+, el video comienza a reproducirse". Puede ser difícil automatizar esta prueba, pero es un criterio de aceptación (AC) de la historia y aporta un punto.

Usamos la escala de Fibonacci, y siempre redondeamos. Entonces, si una historia tiene cuatro criterios de aceptación automatizables, es una historia de cinco puntos.

Nuestro tamaño máximo de puntos de historia es de ocho puntos, pero rara vez los tenemos. Si una historia tiene más de cinco criterios de aceptación automatizables, encontramos una manera de dividirlos.

Pre-aseo

Tenemos una reunión inicial el lunes, pero nuestras reuniones de preparación son donde ocurre la planificación del equipo. Antes de la preparación, los miembros del equipo prepararán una historia describiendo el resultado y apuñalando los criterios de aceptación automatizables.

Grooming aporta la experiencia del equipo a las historias preparadas, descubriendo requisitos no especificados, rompiendo historias, etc.

A veces enumeramos tareas además de los criterios de aceptación, pero estos no son estimados por tiempo. Nunca estimamos el tiempo. Las tareas son solo declaraciones de trabajo que deben hacerse en apoyo de los criterios.

Limitar el trabajo en progreso

El scrum tradicional intenta limitar el tiempo de trabajo a la duración del sprint. Descubrimos que esto artificialmente nos hizo apurarnos para cumplir con los plazos de sprint, matando nuestros fines de semana porque el sprint termina el viernes.

Otro enfoque es limitar el trabajo en progreso en un momento dado. Hemos migrado a este último y hemos sido significativamente más felices por ello.

Una vez que una historia pasa del trabajo atrasado al trabajo en progreso, la caracterizamos como uno de varios estados:

  • En espera: el trabajo en equipo no puede suceder porque estamos esperando alguna actividad extra del equipo
  • En desarrollo: trabajando para lograr los criterios de aceptación
  • Prueba de necesidades: creemos que hemos cumplido con el AC, esperando que alguien más verifique
  • En Test: la historia se está evaluando contra el AC, los errores se están abordando
  • Listo para implementar: en la próxima oportunidad disponible, se pondrá en marcha

Luego usamos el número de historias en cada estado para impulsar el enfoque del equipo. Por ejemplo, un desarrollador puede estar disponible para asumir una nueva historia, pero si tenemos muchas historias en prueba, es mejor que ayuden en las historias existentes.

jimbo
fuente
3

Primero, reconozca que las estimaciones precisas son imposibles bajo esas circunstancias. No te estreses si te equivocas. Sin embargo, aún necesita una idea aproximada para planificar, y realmente la única forma de explicar la incertidumbre completa es agregar más puntos de historia a su estimación. Si no sabe si es un 5 o un 13, use el 13.

También es útil desglosar las historias lo más pequeño posible. A menudo tenemos una historia de investigación / diseño con el único propósito de hacer el trabajo suficiente para tener una mejor idea de cómo hacer la función, luego la historia en sí misma entra en un sprint posterior. Piensa por qué esto funciona. Incluso si no tiene idea de lo difícil que será algo, generalmente sabe con bastante precisión por experiencia pasada cuánto tiempo llevará averiguarlo.

Karl Bielefeldt
fuente
2

Hay dos cosas que puedes hacer aquí.

Primero tenga algún tipo de maestro scrum cuyo rol sea monitorear la discusión y decir "Hola, estás diseñando de nuevo" cuando lo estés. Es más difícil de lo que parece, rotar a las personas en él día a día e inicialmente hacer que todos sean el maestro scrum para que cualquiera pueda hablar.

En segundo lugar, si está diseñando durante la planificación del sprint, debe poder diferenciar entre no saber lo suficiente como para hacer una llamada sobre la duración de una tarea, o si solo está diseñando porque es más divertido.

Una vez más, el scrum master debería patear aquí y decirle que vuelva a poner el elemento en espera hasta que sepa lo suficiente para programarlo, o que deje de diseñar y responda la pregunta original (¿Cuánto tiempo tomará?).

Entonces, si está haciendo una planificación de sprint, tiene sentido tener un patrocinador de negocios allí para repasar el trabajo atrasado con usted y priorizar las cosas que quieren ver primero. Si haces eso, encontrarás que es más difícil diseñarlo durante la sesión porque se inquietarán y eventualmente no querrán venir.

Ian
fuente
De hecho, estamos agregando un scrum master (alguien con experiencia Scrum, contratado para desempeñar este papel por nosotros), así que espero que eso ayude; pero todos reconocemos que esto es un problema, con lo que lucho es cómo hacerlo mejor .
KutuluMike
Bueno, has identificado el problema. Usted diseña en la reunión. La próxima reunión que tenga, si se encuentra diseñando, deténgase, diga "No sabemos lo suficiente" o "Sabemos lo suficiente". Si no sabe lo suficiente, póngalo en espera hasta que tenga más información (Diseñe la sesión fuera de la reunión de planificación) Si tiene suficiente información, prográmela (o no) y continúe.
Ian
Otro comentario que debo agregar. Ten cuidado cuando contrates a un scrum master. Con todos los métodos ágiles, la clave es ser flexible. Adopta lo que funciona, cambia lo que no funciona. Ese es un gran cambio para las empresas a las que les gusta tener procedimientos documentados y planes planificados.
Ian
0

Hemos estado operando sobre la base de estimar la historia 'fría' durante la planificación del sprint con solo una discusión limitada. Las estimaciones son realmente bastante inexactas a pesar de la creación de equipos con un enfoque razonablemente estrecho ... principalmente debido a la existencia de un código heredado indocumentado y no comentado sin una idea real de lo que realmente se supone que está sucediendo y un personal que ha cambiado en gran medida desde que se escribió el original.

Lo que estamos intentando ahora es pasar un poco de tiempo antes de planificar la investigación de cada historia, y aquí solo un desarrollador investigará una historia ... Esperamos que esto signifique que el desarrollador que investigó podrá proporcionar alguna aclaración y conocimiento para Ayudar a la estimación. Hasta ahora, esto ha ayudado en las ocasiones en que se ha probado.

Todavía tengo que estar convencido de que la investigación adicional realmente hace que las estimaciones sean lo suficientemente más precisas para justificar el costo, pero lo intentaremos durante unos pocos sprints para ver.

Dave
fuente