Desarrollo de software. Entregas limpias, por favor
Siempre en el peor momento y después toca correr para corregirlas. El problema es cuando no hay espacio para frenar y tras él solo queda el abismo.
No somos infalibles, de hecho no debemos serlo, salvo que el sistema sea tan crítico como para que de él dependan vidas humanas o se comprometa la viabilidad económica o de negocio de una organización. Pero una cosa es saber que cometeremos errores, aceptar un determinado umbral adecuado a las características del proyecto y su presupuesto y otra que esas incidencias se produzcan de forma sistemática.
Se ha convertido ya en algo comúnmente aceptado que las entregas no sean limpias y que se tenga que iterar varias veces hasta alcanzar una versión aceptable para pasar a producción, cuando no iterar sobre versiones que han llegado a producción.
Os lo aseguro, vale la pena hacer testing (bien hecho), invertir esfuerzo en ello, el que sea necesario.
Cuántas veces se me viene a la cabeza la famosa cita de Boris Beizer: «Una amenaza bien vale mil pruebas«.
Jummp 
Hola,
acabo de terminar un trabajo sobre metodologías ágiles y como gestionar los su pase a ITIL. Hay un rol muy interesante para evitar estos problemas. Y es el «Coordinador de operaciones». Su labor sería realizar un control de calidad (sería miembro de la Oficina de Calidad de IT – de ITIL vamos).
De este modo, se coordina el pase pruebas y producción.
Este rol, debe ser miembro del equipo de desarrollo, su responsabilidad que haya las menos incidencias posibles en la «transición» al servicio.
Un saludo
Lo que planteas es la última barrera de defensa. Sin embargo, entregas limpias implican procesos a realizar desde que comienza el sprint o incluso antes, en la fase de definición del proyecto.
Es más, es el mismo proveedor el que debería tener unos mecanismos de control de calidad estándar con el objetivo no solo de satisfacer los umbrales de calidad que se tenga pactado con un cliente concreto sino para armonizar un nivel de calidad de los trabajos dentro de una misma organización.
¿Por qué te digo que es la última barrera de defensa? Imagina un desarrollo en cascada con errores graves previos a la entrega, la oficina de calidad o los mecanismos de control del proveedor podrán detectar algunos (tal vez, la mayoría), pero serán necesarias diferentes iteraciones de entrega y mucho tiempo y esfuerzo conseguir una entrega aceptable, que probablemente verá afectada su deuda técnica por las prisas en corregir algo que no debería haber llegado tan lejos.
Esto al final afecta a las expectativas del cliente y supone importantes pérdidas para el proveedor.