Probar grandes sistemas en ágil

Enfrentamos esta situación en nuestra plataforma de publicidad AOL hoy. Como sugiere @MrHinsh, lo primero que debe hacer es trasladar todo el control de calidad a los equipos de scrum. De hecho, estamos en el proceso de mover todo nuestro control de calidad a roles de desarrollo donde están haciendo algo de desarrollo y todos nuestros desarrolladores hacia la automatización completa.

Tienes que dejar de hacer lanzamientos de big bang. Claro que puede activar cosas para el cliente en big bangs, sin embargo, todo debería haber estado funcionando en producción. Code Rots, en el momento en que dejas de codificar, se desincroniza con la producción y cualquier otra persona que codifica. Por lo tanto, debe liberar lo más rápido posible.

Estas son las cosas que están funcionando y lo que estamos haciendo para avanzar más en el camino de la implementación continua.

• Sin verificación de código sin pruebas unitarias automatizadas: se debe escribir una nueva prueba o actualizar una prueba existente para verificar cualquier código.
• Todos escriben pruebas: todo es código, función o prueba automatizada, por lo que todos escriben. El papel del control de calidad debe moverse más hacia ayudar a garantizar que los requisitos estén bien escritos y entendidos para que se puedan escribir buenas pruebas.
• - Implementaciones más pequeñas y más frecuentes: si lanza 100 funciones cada tres meses, tiene 100 cosas funcionando juntas a la vez. Si implementa 5 funciones cada semana, solo tiene cinco cosas que se rompen. Si implementa una función todos los días, solo hay una cosa que podría fallar a la vez.

Distinción importante que debe tener en cuenta: Implementado : código que se envió a producción, bajo banderas para que solo el desarrollo pueda verlo. Esto le permite probar el código con producción, sin que el cliente lo vea. Cada vez que se hace una historia de usuario, se debe implementar.

Lanzado : aquí es cuando permite que los clientes lo vean. Puede mantener sus Lanzamientos trimestrales manteniendo las cosas bajo banderas. O incluso hacer que algunos clientes lo vean mientras que otros no. El código ya debería haberse implementado y probado mucho antes de su lanzamiento.

Que existan 1 y 2 me indica que, si bien sus equipos no son ágiles. Debería estar produciendo software que funcione sin necesidad de más trabajo para enviarlo al menos cada 30 días.

Debe tener todas las pruebas realizadas antes de llegar a la hora 11. Esto generalmente significa que necesita incorporar a sus evaluadores en los equipos de desarrollo e invertir mucho en la automatización.

Cada equipo debe contribuir al mismo incremento de trabajo del software que se prueba con la misma cadencia.

Si no tiene compromiso organizativo para hacer ese cambio, entonces necesita incorporar pruebas en sus equipos de desarrollo por su cuenta. En algún momento, si incorpora suficiente calidad, sus equipos de control de calidad se convertirán en un centro de costos que proporciona poco valor.

Debería lanzar su software con mucha más frecuencia y deshacerse de la idea de los paquetes de servicios.

Concéntrese en el trabajo frecuente y el software integrado.

El objetivo con Scrum es tener un código liberable al final de cada sprint. Ahora bien, eso no significa necesariamente que tengas que hacer un lanzamiento cada sprint. Solo que el código que tiene es potencialmente liberable . Puede ser que su Product Owner no quiera lanzar cada sprint, pero siempre debe tener la opción disponible.

Puede valer la pena considerar tener un entorno de prueba que sea efectivamente un código listo para la producción. Todos los lanzamientos de producción se llevarían a cabo desde este entorno de prueba y el lanzamiento no implicaría pruebas ni configuraciones adicionales . En otras palabras, su entorno de prueba es un código listo para producción que simplemente no está en producción todavía.

Este entorno de prueba representa el final de una canalización de lanzamiento e incluye el código de lanzamiento integrado de todos los equipos de Scrum. Cada equipo prueba a nivel de unidad, a nivel funcional y además ejecuta pruebas de integración y regresión completas en el código troncal principal. Esto se hace en todos y cada uno de los sprints.

Por lo general, no es práctico hacer esto utilizando métodos de prueba manuales. Un mejor enfoque es tener pruebas de integración y regresión automatizadas que sean mantenidas por todos los equipos (y ejecutadas a través de integración continua).

Esto puede parecer un enfoque difícil, pero ofrece el beneficio sustancial de evitar descubrir errores en el último momento (un problema que menciona en su pregunta). También puede ejecutar una canalización de lanzamiento paralela para sus paquetes de servicio, usando una rama de código separada.

Le recomiendo encarecidamente que eche un vistazo al libro "Continuous Deliver" de Jez Humble y David Farley para obtener una descripción detallada de este tipo de configuración.