Os voy a contar una situación muy típica con la que seguro muchos os vais a sentir identificados, y que trata sobre los desajustes y dudas que se producen a la hora de cerrar un sprint, o una iteración, y hacer un paso a producción.
La siguiente situación, me la he encontrado ya en tantos sitios que seguro que en un futuro formará parte de la serie de post-informes que te estoy dejando en el blog sobre aquello de después de pasar por 80 empresas, herramientas más típicas encontradas (informe 2) y después de pasar por 80 empresas, datos detallados de situaciones encontradas (informe 1)
La historia comienza con algo muy común, la siguiente situación: a la mayoría de equipos, o empresas, les gusta hacer los pasos a producción los viernes por la noche. Situación especialmente típica en empresas cuyo producto software se basa en la web.
Por si alguien muy junior, aun no fogueado en las batallas del mundo del software, estuviera leyendo este post y no supiera qué es un paso a producción, lo voy a resumir mucho diciendo que es la acción de poner una nueva versión de software a disposición de los usuarios reales del mismo.
Las razones de pasar a producción los viernes por la tarde noche suelen ser dos, que suelen venir juntas
1 – Normalmente, estos equipos hacen alguna parada en el software (es decir, interrumpen el servicio que da) que ahora esta en producción para poner la nueva versión. Y hacen los pasos a producción viernes noche, para parar cuando menos tráfico hay, por si hay algún problema y la parada se alarga, así afectan a menos usuarios.
2 – A la mayoría de los equipos les gusta hacer coincidir el final de un sprint o iteración con el final de una semana, es decir, terminar un viernes. Y, normalmente, los viernes antes de la hora de la comida, ya que en algunos sitios los viernes por la tarde no se trabaja.
Lo anterior, lógicamente, crea una situación, llamemos… extraña. Si el sprint termina el viernes por la mañana y hacéis las reuniones típicas de final del sprint (la de revisión de sprint, con su demo correspondiente, y la retrospectiva) el viernes por la mañana, siendo el paso a producción el viernes por la noche… el paso a producción está fuera del Sprint.
Cuando en algún sitio veo la situación anterior, asumo, lógicamente, que, al estar el paso a producción está fuera del Sprint el Product Owner en su definición de “qué es necesario para terminar este Sprint” (te recomiendo leer aquí lo de en un proyecto ágil, acordar una buena definición de lo que significa terminado, el done) dijo que para terminar con éxito el Sprint NO era necesario pasar a producción.
De hecho, la demo de la reunión de revisión de sprint no puede mostrar las nuevas funcionalidades desarrolladas en producción (se pasa a producción por la noche y esta reunión es por la mañana).
Cuando algún equipo me pide ayuda para mejorar su proyecto, en base a un ciclo de vida ágil, y expongo cómo afrontan este problema… muy pocos me saben responder cómo y por qué les pasa esto. Algunos equipos ni se lo habían planteado.
Los pasos a producción están en tierra de nadie, se hacen entre sprints.
Realmente, esto no tiene porque ser un problema, o sí, siempre y cuando asumamos todos que terminar un sprint con éxito, y sus correspondientes historias de usuario y tareas, no implica el paso a producción (y todo aquello que allí pase). Pero, claro, expuesto así… a algunos responsables y product owners esto no les gusta mucho…. «¿Terminar sin un paso a producción?»
Como consecuencia de lo anterior, hay quien hace otra nueva reunión para revisar la versión en producción desarrollada en el sprint previo dentro del siguiente sprint, los lunes, por ejemplo.
Pero, claro, esta reunión de los lunes para revisar el paso a producción debería ser antes de la planificación del siguiente sprint, porque si de dicha revisión salen nuevas tareas, esas nuevas tareas deben contemplarse en la reunión de planificación del sprint que empieza el lunes. Si se hace al revés, primero reunión de planificación de sprint y luego revisión del paso a producción… pueden pasar cosas raras, tareas derivadas de la revisión del paso a producción que entran en el sprint sin haber sido planificadas, etc.
Si empiezan a aparecer muchas tareas nuevas, detectadas en la revisión del paso a producción del lunes, la que revisa el paso a producción del viernes anterior, aparecen los nervios, y hay quien alarga el sprint (que ya te comenté en su día que deberían todos los sprint, o las iteraciones, durar el mismo tiempo y, como ves, esto es un síntoma de que algo puede ir mal)
Como ves, por no extenderme mucho, pasan cosas raras que cuando las expones la gente se queda pensando un rato y no sabe qué contestar. Y esto no es bueno para una planificación, cuanto más clarito esté todo mucho mejor.
Tres soluciones (dos fáciles otra difícil)
La fácil, lo razonable es que el paso (o pasos, ya llegaremos a eso) a producción sea previo al fin de sprint, que esté dentro del “done” que determina la correcta finalización de un sprint.
Si haces los pasos a producción los viernes noche, y quieres evitar los anteriores problemas, una opción es hacer la revisión de sprint y la demo los lunes.
Lo anterior resuelve vacíos en la planificación, pero genera tres reuniones el lunes, uff, la de fin de sprint, la retrospectiva y la de planificación del siguiente sprint.
En este punto hay quien se plantea, mover los pasos a producción los jueves, así, el viernes se realizará la reunión de revisión del sprint, posteriormente al paso a producción, y el “done” del sprint puede, correctamente, contemplar que las cosas terminan si están en producción.
El problema ahora es el que contaba al principio, tienes que pasar a producción un día de mayor trafico y usuarios… un jueves.
La tercera solución viene del principal problema de todo esto… dejar para el final el paso a producción y, además, el paso a producción de todo. Un gran paso a producción de todo al final. Y un paso a producción que implica una parada.
Claro, si el paso a producción no fuese el gran final de todo, si no nos diese miedo hacerlo, y fuese una actividad más, rutinaria, algo no tan grande… esto no pasaría.
T
e estoy hablando de hacer pequeños pasos a producción, de manera frecuente, durante el sprint, cada vez que se termina una funcionalidad o historia de usuario. Y sin parada.
A muchos al escuchar lo anterior se les queda la cara blanca… ¿hacer muchos pasos a producción en un sprint?
Pero ya lo hemos comentado muchas veces, esto muchas empresas lo hacen, las que de manera privada uno pueda conocer o las públicas, como aquello que te conté del Caso de estudio: cómo trabaja Quora en Continuous Deployment.
Lo sé, esto no está al alcance de cualquiera, requiere de un proceso de integración continua, de un proceso de pruebas robusto, de que no se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints), de una arquitectura preparada para pasar a producción sin paradas, es lo que viene a llamarse “entrega continua”, algo tan deseado como difícil para algunos, pero que si lo logras situará a tu equipo y a tu empresa muy por encima.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Nosotros nunca entregamos un producto un viernes! lo teníamos prohibido por nosotros mismos.
Creo que la finalización de un Sprint, no tiene que llevar consigo un paso a producción del software entregado.
El ciclo de vida para poder pasar a producción, lleva una serie de procedimientos que no deben tenerse en cuenta en el Sprint.
Se puede pasar a producción después de la ejecución de varios Sprints.
Nunca se me habían planteado estos problemas:
– Nosotros tampoco pasamos nunca a PROducción los viernes. Prohibido. Supongo que hablamos de aplicaciones de intranet que es donde le veo más sentido. Aunque eso de volver un lunes a trabajar y que falle algo no debe sentar muy bien.
– Los pasos a PROducción no están incluidos en el sprint. Ni siquiera los pasos a PRE. El sprint termina con una demo y ni siquiera es obligatorio. Puedo imaginarme un Product Owner quiera incluirlos pero en mi opinión es un error, salvo que cuentes con Continous Deployment. No es mi caso. Lo que nosotros hacemos es una entrega que puede instalar un mono. En plan: 1- Ejecutar script x-m.n.0.sql sobre bdd X. 2- Configurar propiedad de sistema P=V. 3- Sustituir WAR. En caso de fallo ejecutar script REGx-m.n.sql (cuando no es posible restaurar copia de seguridad de la bdd) y volver a WAR anterior.
Estos pasos de entrega han sido probados en nuestro servidor de desarrollo.
Aún así, a veces Sistemas no realiza bien la puesta o había algún bug en el paso. Ambos generan una tarea de soporte o versión bugfix, respectivamente, que tiene máxima prioridad (se para lo que se estuviera haciendo).
Y todo este rollazo por si pudiera servirle a alguien 🙂
Javier como recomendarías trabajar la parte de pruebas en agile? Esta parte por lo general sigue siendo cascada. Hay algo que se pueda hacer adicional a la automatización de pruebas?
Gracias
Hola, trabajar en BDD – TDD, y así no hay cascada
En nuestro caso la ultima tarea que consideramos en el Sprint es la Documentación del Pase a Producción, esto sucede por que la revisión e instalación del pase es realizada por un tercero. En el caso que el pase sea devuelto, creamos una tarea no planificada para atender el ajuste que corresponda.
Muy pocas veces nos han devuelto un pase, ya que antes de enviarlo realizamos un set de pruebas en ambientes de desarrollo para asegurar que cumpla con todos los estándares de programación y que la funcionalidad cumpla con lo solicitado por el usuario