Somos un equipo pequeño (3 desarrolladores y 2 probadores) y hemos usado Scrum con éxito durante 6 meses, a pesar de ser un equipo realmente pequeño para esta metodología. Soy novato como Scrum Master.
Ahora, hemos comenzado a experimentar problemas con Sprints que terminan con tickets que los desarrolladores terminan, en teoría, pero el evaluador no ha tenido suficiente tiempo para probarlos.
¿Cómo debemos manejar esto? No se permite extender el Sprint, por lo que mover los boletos al próximo Sprint parece estar bien, pero ¿cómo podríamos estimarlos? Dado que los evaluadores podrían encontrar grandes problemas que podrían generar nuevas soluciones.
Editar: Más información: teníamos 7 boletos... este boleto principal se tomó primero, y tomó desde el principio hasta el final del sprint, por lo que solo tenemos UN boleto terminado. Es el sprint más raro que hemos tenido. Por supuesto: la peor estimación de la historia, pero nuestra retrospectiva se verá tan extraña con solo un boleto terminado, y el otro con el desarrollo terminado pero nada de prueba... Administrativamente, ¿qué debo hacer? volver a la cartera de pedidos y empezar de nuevo? estimando el punto original de la historia - tiempo de desarrollo (que ya está "terminado")?
Necesita inspeccionar y adaptar todo su proceso de estimación y establecimiento de objetivos. Sin embargo, a corto plazo, el trabajo incompleto debe volver a colocarse en el Product Backlog, volver a priorizarse y reestimarse.
Administrativamente que debo hacer? volver a la cartera de pedidos y empezar de nuevo? estimando el punto original de la historia - tiempo de desarrollo (que ya está "terminado")?
Debes tener un Sprint Goal. El objetivo de un Sprint es lograr el Sprint Goal, no hacer muchos tickets. Sin un Sprint Goal, realmente no estás siguiendo el marco Scrum y no podrás evaluar correctamente el éxito del Sprint.
Independientemente, su pregunta específica es sobre qué hacer con el trabajo que realmente no está hecho . Si su definición de hecho incluye la finalización del control de calidad, entonces el elemento de la cartera de productos simplemente está incompleto. No está parcialmente hecho, no está algo hecho, simplemente no está hecho.
Cuando los elementos de la lista de pedidos del producto no están completos al final de un sprint, regresan a la lista de pedidos del producto para que el propietario del producto vuelva a priorizarlos . El elemento puede seguir siendo relevante o no, y solo el propietario del producto puede determinar si todavía tiene valor asignar recursos para él en un Sprint futuro.
Siempre y cuando el trabajo vuelva a estar dentro del alcance de Backlog Refinement o Sprint Planning, el trabajo debe volver a estimarse. La Guía Scrum dice:
Todos los elementos incompletos de la cartera de productos se vuelven a estimar y se vuelven a colocar en la cartera de productos. El trabajo realizado en ellos se deprecia rápidamente y debe reestimarse con frecuencia.
La cantidad de trabajo que se realizó previamente en el elemento es irrelevante. El trabajo debe reestimarse para determinar cuánto esfuerzo queda (dado el conocimiento sobre la capacidad actual del equipo y las lecciones aprendidas acumuladas, entre otras cosas) para implementar la función dentro de un nuevo Sprint. Las estimaciones históricas y el esfuerzo realizado deben descartarse como puntos de datos, porque los cuadros de tiempo son efímeros; lo que importa es el esfuerzo restante.
Hay un límite en la cantidad de consejos que se pueden obtener de extraños en Internet. Se supone que su equipo es consciente del problema y Scrum prescribe un equipo autoorganizado. Así que discuta el problema y haga una lluvia de ideas/evalúe las posibles soluciones durante la Retrospectiva.
Habiendo dicho eso...
Específicamente, durante la estimación. Las estimaciones deben ser para el esfuerzo necesario para terminar la historia℠, no solo para el desarrollo. Habiendo dicho eso...
Entonces no estás completando todas las historias, está bien, no es gran cosa. ¿Estás completando tu Sprint Goal? Eso es en lo que deberías centrar tus esfuerzos. Si tiene su objetivo de Sprint completamente desarrollado pero el control de calidad está atrasado, ¿tal vez sería mejor para los desarrolladores ignorar las historias de 'extensión' y ayudar al control de calidad en su lugar? Solo una sugerencia: nuevamente, consulte al Equipo.
Si no tienes un Sprint Goal, entonces tienes problemas más grandes que historias incompletas.
Ahora, hemos comenzado a experimentar problemas con Sprints que terminan con tickets que los desarrolladores terminan, en teoría, pero el control de calidad no ha tenido suficiente tiempo para probarlos.
estimación del punto original de la historia: tiempo de desarrollo (que ya está "terminado")
Trate de no pensar en las pruebas como una actividad de control de calidad. Es una actividad de equipo .
Los QA pueden realizar pruebas, pero también deben hablar con el Propietario del producto / Desarrolladores sobre los problemas y las correcciones de errores generalmente involucrarán a los desarrolladores. Además, considere actividades como análisis de causa raíz, automatización de pruebas, métricas de calidad de código, etc.
Si la prueba no se completa con éxito, el ticket simplemente no se realiza . Regréselo a la cartera de pedidos y, si vuelve a priorizarse, deberá volver a estimarlo.
teníamos 7 boletos... este boleto principal se tomó primero, y tomó desde el principio hasta el final del sprint, por lo que solo tenemos UN boleto terminado
Esta es una excelente oportunidad de aprendizaje. Como equipo, piensen por qué sucedió esto. ¿Qué se puede hacer para evitar que vuelva a suceder en el futuro?
pero ¿cómo podríamos estimarlos? Dado que el control de calidad podría encontrar grandes problemas que podrían generar nuevas soluciones.
Esta es la razón por la que muchos equipos de Scrum adoptan enfoques como el desarrollo basado en pruebas y el desarrollo basado en el comportamiento. Los errores son notoriamente difíciles de estimar, por lo que tiene sentido dedicar tiempo a prevenir que ocurran en lugar de corregirlos.
Daniel
Sarov
Todd A. Jacobs