¿Cómo se incluyen los informes de errores en un sprint?

He estado leyendo sobre Scrum recientemente. Según tengo entendido, se lleva a cabo una reunión antes de que comience el sprint, para decidir qué se mueve de la cartera de pedidos del producto a la próxima cartera de pedidos de sprint. Una vez que se completa una característica en el sprint actual, entrará en el cubo "Listo para QA", y es en este punto que me estoy confundiendo. ¿Los informes de errores vuelven a la cartera de pedidos del producto? Supongo que no pueden volver al backlog de Sprint, ya que ya hemos decidido qué trabajo se hará para este ciclo. ¿Qué sucede cuando QA encuentra un error? ¿A dónde va?

A mi modo de ver, hay dos soluciones principales para esto:

1. No asignes el 100% de tu tiempo al sprint actual. Permita un 10-15% de su tiempo para la corrección de errores y otras actividades de soporte que surgirán durante el sprint. Luego, si aparece un error de bloqueo , tienes tiempo para arreglarlo en el sprint actual.

   Si aparece un error que no es de bloqueo, puede arreglarlo al final del sprint actual si le queda tiempo o entra en el "bote" para el próximo sprint.

2. Haga un sprint de "corrección de errores" de vez en cuando. Probablemente justo antes del próximo lanzamiento importante. Puede usar esto para "eliminar" tantos errores como pueda / quiera arreglar para la próxima versión.

Probablemente ninguna de estas soluciones sea fiel a Scrum "puro", pero funcionan en el mundo real.

Durante un sprint "regular" aún puede incluir tareas para corregir errores específicos, tratándolos como si fuera una nueva funcionalidad.

En un mundo de scrum ideal, no hay un cubo "Listo para QA" (al menos no visible fuera del equipo), ya que una característica no se completa hasta que las actividades de QA hayan finalizado y se hayan corregido los errores. Esto significa que debería haber personas en el equipo que puedan asumir las actividades de control de calidad.

En el mundo real, es posible que tenga un equipo de control de calidad / prueba separado que trabaje en paralelo con el equipo scrum (desarrollo). En ese caso, el siguiente enfoque podría funcionar bien:

1. Justo antes de que una característica se coloque en el segmento "Listo para QA", el desarrollador (principal) de esa característica y el representante de QA que (probablemente) se encargará de sentarse y caminar a través de la característica. Todos los problemas encontrados en ese momento se resuelven antes de que la función se coloque en el depósito "Listo para QA". Tenga en cuenta que esto no es una parte temprana de una demostración de sprint. Está destinado a obtener la fruta más baja en los problemas resueltos lo antes posible.

2. Cualquier problema que se encuentre después de la transferencia al control de calidad debe colocarse en la cartera de pedidos del producto como historias, para tenerlo en cuenta en la próxima reunión de planificación.

3. Para errores de show-stopper, reserve una cantidad fija de tiempo cada sprint. Si, cerca del final del sprint, queda tiempo en este búfer, podría llenarse con problemas de menor prioridad.

Según cómo describa su flujo de trabajo a partir de una historia, con una acumulación de productos, una acumulación de sprint y otros segmentos (supongo que se ven como "en progreso / en desarrollo", "listos para el control de calidad", "terminado "), parece que está agregando algunos elementos de Kanban a Scrum, una combinación común que a veces se llama Scrumban . La noción de Kanban agrega límites al tamaño de cada segmento para evitar que sus desarrolladores tengan demasiadas historias en progreso o que sus evaluadores prueben demasiado. Es similar a la velocidad para mover elementos de la cartera de pedidos de su producto a su cartera de pedidos de sprint, pero dentro de un sprint.

Abordaría el problema haciendo que sus tareas sean las historias de usuario, con sus historias de usuario moviéndose desde la cartera de pedidos del producto a la cartera de Sprint, a la cubeta en progreso, a la cubeta lista para el control de calidad y a la cubeta terminada. Después de que el desarrollador termine la historia (según su definición de terminado), la moverá al cubo "listo para el control de calidad", donde la siguiente persona lo sacará y trabajará en él. Si hay algún problema con él, se introducirá un defecto en su sistema de seguimiento y la historia del usuario se trasladará al depósito terminado ya que se ha implementado y probado. Si no hay problemas con él, se mueve directamente al cubo terminado.

Cuando el defecto proviene de su sprint, no hay ningún problema con volver a colocarlo en el backlog de sprint (o tal vez algún tipo de depósito "en progreso"). Una historia con defectos conocidos generalmente se considera inacabada. Si se determina que no hay tiempo suficiente para terminar la historia o los defectos se atribuyen a no entender la historia, una opción podría ser eliminarla del sprint por completo hasta que pueda comprender mejor la necesidad; en este caso, recomendaría no incluida la implementación defectuosa en su producto lanzado.

Si, debido a tu defecto, la historia no termina en tu carrera, esto saldrá en tus cálculos de velocidad para carreras futuras. Las historias inacabadas (historias defectuosas) no le otorgan puntos de historia, por lo que planeará sprints más pequeños. Menos historias complejas conducirán a más tiempo en las pruebas y lo alentarán a dedicar más esfuerzo a encontrar defectos de manera temprana; prevenir los defectos no solo es más barato, sino que lleva menos tiempo que la suma del tiempo dedicado a identificar que existe un problema, encontrar el problema en el diseño o implementación, solucione el problema y vuelva a realizar la prueba para asegurarse de que el problema se haya resuelto sin ningún otro impacto negativo en el sistema. Dado que el timebox es clave, la capacidad de prevenir defectos conduce a sprints más productivos en el futuro.

Independientemente de lo que haga, debe involucrar al propietario del producto (que es de esperar un representante del cliente / usuario) a la hora de decidir cómo priorizar los defectos. Algunos defectos pueden ser aceptables para ser lanzados si hay soluciones o son raros, lo que significa que el defecto se mostrará como una historia en un futuro sprint. Otros defectos pueden ser urgentes y "showtoppers": estos deben abordarse de inmediato y un producto no se puede usar si existe.

Si el tiempo dedicado al defecto es bastante constante de un resorte a otro, entonces no es necesario que lo maneje, la velocidad de su equipo lo reflejará.

De lo contrario, si se puede planificar la reparación de defectos (es decir, puede posponer la reparación durante la duración de un sprint), entonces hágalo.

De lo contrario, Scrum no tiene una buena respuesta: los defectos serán un cambio de contenido de sprint no planificado en medio de un sprint, lo que significa que deberá renegociar sus compromisos.

Un sprint debe ser autónomo. Eso significa que todas las actividades, incluido el control de calidad, la corrección de errores y la documentación, deben completarse antes del final del sprint. Las actividades previas a la implementación también deben realizarse antes de que termine el sprint.

El problema con no terminar es que te distraes en el próximo sprint.

Si, en el sprint B, debe volver su atención al código del sprint A para que pueda corregir los errores, entonces su capacidad para concentrarse en las tareas del sprint B desaparece. También tu velocidad de avance.

En mi último trabajo, los sprints se programaron según el concepto de "horas ideales"; de un día de desarrollador de 8 horas, 5 horas fueron nuevas características de TDD que nunca antes existieron. Los otros tres estaban haciendo todo lo demás; correos electrónicos, reuniones, compilación / confirmación / actualización de código, refactorización del trabajo y, sí, corrección de errores.

Consideramos un trabajo que estaba hecho pero tenía errores que aún contaban para la velocidad del equipo; sin embargo, los errores eran deudas técnicas que debían pagarse cuando se acumulaban y, por lo tanto, obviamente debían evitarse. Nunca tuvimos un problema real con la gente que hacía un trabajo descuidado; nadie quería tener que retroceder.

De vez en cuando, también tendríamos sprints para corregir errores. Tuvimos la dudosa suerte de tener un cliente que no podía cumplir con los requisitos al ritmo que podíamos consumirlos, por lo que para dejar que el trabajo acumulado se acumule un poco, a menudo programamos dos semanas en las que el objetivo era "matar tantos defectos y pagar tanta deuda técnica como puedas ". Técnicamente, la velocidad para tal sprint es cero, pero este es un trabajo que debe hacerse y que hace feliz al cliente, por lo que vale la pena.