¿Cuál es el enfoque sugerido para la organización de sprints durante la fase de pruebas? Supongamos que hemos terminado los sprints de desarrollo, las pruebas internas (analistas y desarrolladores) han terminado. La aplicación se implementa en el entorno de prueba para las pruebas de aceptación del usuario. Esas pruebas están cubiertas por los usuarios comerciales de la aplicación.
¿Qué debemos hacer ahora?
En la situación ideal, debe implementar una nueva versión después de cada sprint cuando estaba creando la aplicación para que la fase de prueba se extienda durante un período de tiempo más largo.
Habiendo dicho eso, entiendo que hay clientes que esperan que la fase de prueba de aceptación se realice al final, después de la entrega de toda la funcionalidad.
Para esta situación, considero que corregir errores tiene mayor prioridad que desarrollar nuevas funciones. Tienes algunas opciones aquí:
Comience un nuevo sprint, planee una velocidad más pequeña que la típica. Para el primer sprint, puedes seguir tu instinto para establecer la velocidad esperada. Luego corrige los errores a medida que surgen, lo que afecta negativamente la cantidad de trabajo nuevo que puede hacer. De esta manera, debería poder corregir errores y hacer un nuevo trabajo. Sin embargo, corre el riesgo de cambiar mucho el contexto, ya que las personas dejarán de trabajar en nuevas tareas para corregir errores antiguos.
Comienza un nuevo sprint pero elimina la parte del equipo como equipo de mantenimiento del proyecto anterior. De esta manera, tiene un sprint estándar, aunque con un grupo más pequeño de personas, y algunas otras personas que deben lidiar con los errores enviados. Puede ajustar la cantidad de personas en ambos grupos después de cada sprint, según la carga de trabajo relacionada con los errores. La velocidad del equipo que trabaja en nuevas funciones será flotante, pero limita el cambio de contexto. Sin embargo, te arriesgas a la frustración de las personas que se enfrentan a errores, ya que se enfrentarán a errores creados por ellos mismos y por otros, que actualmente trabajan en nuevas tareas interesantes. Es una buena idea mezclar personas entre esos equipos después de cada sprint si es posible.
Establezca happy hours/days para la corrección de errores: hora del día/semana en la que todo el mundo está lidiando con errores. Aparte de eso, están construyendo nuevas funciones. Puede ajustar la duración de las horas felices a la cantidad de trabajo que tiene con la corrección de errores. Nuevamente, corre el riesgo de que las personas corrijan el código creado por otros, especialmente cuando alguien crea un código de muy baja calidad con muchos errores. Sin embargo, introduce uno para todos, todos para un tipo de actitud en el equipo que generalmente funciona bien.
Si hay suficientes correcciones de errores para llenar todos los días para todo el equipo, esperaría con el lanzamiento de un nuevo sprint hasta que haya al menos alguien que pueda ocuparse de las nuevas tareas, sin importar el método que elija.
En el entorno que está describiendo, la forma ideal sería entregar la funcionalidad en pequeños incrementos. Cada sprint debe presentar una nueva funcionalidad o una funcionalidad mejorada para que los usuarios la prueben.
No debe esperar hasta que termine toda la fase de desarrollo y solo entonces comenzar las pruebas de usuario. Es como perder el punto de desarrollo iterativo.
En la empresa en la que trabajo, tenemos equipos de desarrollo (también responsables de las pruebas funcionales) y luego tenemos un equipo de pruebas de soluciones. Los equipos de desarrollo entregan contenido en sprints. El equipo de pruebas de nivel de solución tiene sprints posteriores en los que prueban las nuevas características.
De esta manera, puede obtener comentarios de los usuarios en una etapa temprana, en la que aún puede realizar cambios y concentrarse en las características más importantes.
Si está haciendo Scrum, haría las pruebas durante el Sprint donde ocurrió el desarrollo. La función se desarrolla, la función se prueba, ambas se tienen en cuenta en el plan de Sprint: la función no se "termina" hasta que se haya desarrollado y probado.
Si no puede completar las pruebas en el mismo Sprint, probablemente no esté dividiendo sus historias en partes lo suficientemente pequeñas. En el peor de los casos, prueba cada historia en el Sprint inmediatamente después de desarrollarla.
Si tiene una "fase" de desarrollo (número X de Sprints) y una "fase" de prueba (número Y de Sprints), eso es Waterfall (o cascada iterativa).
He estado involucrado en pruebas de aceptación de usuarios mientras usaba scrum. Nuestros ciclos UAT fueron definidos por contrato y fuera de nuestro alcance de control. Por lo general, teníamos 3 días de UAT seguidos de 2 días para corregir errores, cada lanzamiento de producto tendría al menos tres de estos ciclos de UAT.
Entonces, nuestro equipo dividió todo el período UAT, aproximadamente dos semanas en varios mini-sprints. No estrictamente en el marco de scrum, pero esa es la belleza de scrum, puede y debe adaptarlo a su entorno. Cuando el cliente tenía el producto y el entorno bloqueados para realizar pruebas, codificábamos las correcciones de errores. Cuando se nos devolviera el entorno para la corrección de errores, implementaríamos las correcciones de errores del mini-sprint de corrección de errores anterior y realizaríamos pruebas ambientales.
Descubrimos que, por lo general, teníamos algunos ciclos libres durante la UAT si habíamos hecho bien nuestro trabajo y no había muchos errores. Usamos este tiempo para cualquier tarea de limpieza descuidada.
alan larimer