En mi empresa, trabajamos con éxito con prácticas ágiles, pero sin usar iteraciones. La razón principal es que no podemos encontrar una forma limpia de ajustar el control de calidad en un ciclo de iteración.
Entendemos el control de calidad como un poco de verificación adicional para una determinada compilación (candidato de versión) antes de que esta compilación se implemente para el cliente. El punto es evitar que un solo ataque malicioso dañe la versión completa. Como nunca se sabe cuál es, el control de calidad debe esperar hasta que todas las funciones / confirmaciones para el lanzamiento estén en la compilación. (No se permiten las últimas palabras famosas "Fue solo un pequeño cambio").
Si QA encuentra errores en un candidato de lanzamiento, los desarrolladores corrigen estos errores en la rama de lanzamiento respectiva (y los combinan en el tronco). Cuando se corrigen todos los errores, se implementa una nueva compilación para que QA vuelva a probar. Solo cuando no se encuentran errores en un determinado candidato de lanzamiento, se ofrece al cliente para su verificación.
Esto generalmente toma alrededor de dos o tres candidatos, aproximadamente una semana, por lanzamiento. El tiempo para escribir las soluciones suele ser mucho menor que los esfuerzos de prueba. Entonces, para mantener ocupados a los desarrolladores, trabajan en la versión N + 1 mientras que QA funciona en N.
Sin usar iteraciones, esto no es un problema porque podemos superponer el trabajo para las versiones N y N + 1. Sin embargo, por lo que entiendo, esto no es compatible con enfoques basados en iteraciones como Scrum o XP. Exigen que una iteración sea liberable al final con todos los esfuerzos de prueba incorporados en la iteración.
Creo que esto necesariamente conduce a uno de los siguientes resultados no deseados:
(A) Los desarrolladores están inactivos al final de una iteración porque el control de calidad necesita tiempo para verificar un candidato de lanzamiento y el trabajo de corrección de errores no mantiene completamente ocupados a los desarrolladores.
(B) El control de calidad comienza a funcionar antes de que el primer candidato de lanzamiento esté listo. Esto es lo que se recomienda principalmente en Stack Exchange. Pero no es lo que mi empresa entiende como QA porque no se ha probado un candidato de lanzamiento específico. Y el "pequeño cambio" que rompe todo aún puede introducirse sin ser visto.
(C) Los errores se transfieren a la siguiente iteración. Esto también se recomienda en Stack Exchange. No creo que sea una solución en absoluto. Básicamente significa que nunca obtendremos una compilación verificada porque cada vez que se realizan correcciones de errores, también se agregan confirmaciones nuevas y no verificadas a la misma rama.
¿Hay alguna forma de salir de este dilema?