La subida a producción es un momento especial para cualquier equipo software. En ese momento, el software deja de ser “de prueba” y pasa a ser real, con usuarios que lo utilizan y que pueden beneficiarse del mismo. El delivery del software es un momento importante, y depende de cada equipo y sus circunstancias. ¿Tiene sentido hacer Scrums si no entrego en producción el software de manera constante?
Se sube a producción cuando tiene sentido
En Scrum, no hay muchas instrucciones sobre cuándo se sube a producción. Se aplica la regla general de “cuando tenga sentido”. Esto significa que dependerá mucho del negocio al que prestemos servicio y de las condiciones en las que nos encontremos. Además, debemos recordar que el Product Owner es la persona que se encargará de decidir cuándo debemos subir a producción. Por tanto, la subida se hará en función del momento que se considere.
Seguramente, en sistemas dónde la seguridad sea crítica, no nos atrevamos a hacer subidas cada poco tiempo. En líneas generales, en productos digitales suele ser interesante que las subidas se hagan cada poco tiempo, para reducir el riesgo de estar construyendo un producto que nadie quiera.
Esto se hacía antes
En un modelo waterfall tradicional, la subida a producción ocurría tras mucho tiempo de desarrollo. Esto se producía porque la cultura tradicional busca la entrega de grandes productos en periodos muy largos de tiempo, así eficientamos el trabajo al hacer solo una subida a producción. Por tanto, lo que tiene sentido en estos modelos es hacer una subida a producción al final.
Por tanto, si hacemos un análisis simplista, Scrum y Waterfall son similares a la hora de aplicar la misma regla: subimos cuando tenga sentido. Sin embargo, las diferencias son enormes en cuanto a sus estrategias.
En waterfall, enfocamos el éxito de nuestro software en llegar a una fecha concreta con un alcance construido. Este planteamiento ha funcionado bien hasta que hemos entrado en un mundo tan cambiante que las necesidades de los usuarios son volátiles. La única manera de acertar es la entrega contínua, para aprender rápido de nuestros usuarios y poder acertar. Incluso si acabamos construyendo el producto equivocado; seguramente, lo detectemos antes con un planteamiento Scrum, lo que nos permite abandonar una iniciativa no rentable antes de llevarnos al fracaso total (por habernos gastado todo el presupuesto).
Que no subas a producción no significa que no llegues a producción
¿Si el Product Owner decide que no subiremos hasta que no tengamos un conjunto de features importantes, tiene sentido “llegar a producción”? En Scrum, debemos dejar los desarrollos en estado releseable, es decir, listos para subir a producción. Toda funcionalidad que se desarrolle tiene que estar terminada, sin que queden tareas pendientes si lo quisiéramos poner en producción. De esta manera, garantizamos que, en el momento que decidamos subir, lo podamos hacer rápidamente. En un modelo waterfall tradicional, nos acabábamos encontrando “setas” a última hora que retrasaban la subida o la convertían en un infierno.
Por tanto, el equipo debe tener muy claro qué significa que un desarrollo está “terminado” y después aplicarlo. Una vez que terminamos nuestros desarrollos, será el Product Owner quien determine si pasamos de releaseable a release, es decir, si subimos a producción para ponerlo a disposición de los usuarios.
Estrategia de subida a producción
El Product Owner dispone de diferentes estrategias para gestionar el producto y las subidas a producción, que se resumen en tres.
La primera es la “major release” o el famoso Big Bang. Una gran cantidad de funcionalidad que ponemos en producción pasado un largo período de tiempo o muchos Sprints. En esta estrategia, asumimos una mayor cantidad de riesgo de que lo que estemos haciendo no sea lo que realmente quieren los usuarios. Y por tanto, la subidas se distancian mucho en el tiempo y, también, las oportunidades de inspeccionar y adaptar nuestros usuarios y su feedback. Es una estrategia válida, pero el Development Team seguirá dejando cada feature terminada en un estado “releaseable”.
La segunda estrategia es conocida como minor o por Sprints. Normalmente, se produce una subida coincidiendo con los Sprints. De esta manera, reducimos el riesgos con respecto a la major. Este tipo de subidas nos permite acelerar el feedback, lo que nos debería ayudar a tomar mejores decisiones. En este tipo de estrategia, seguimos usando la Sprint Review para inspeccionar un incremento que todavía no están disfrutando los usuarios.
La tercera estrategia es la de varias veces por Sprint. En esta estrategia, hacemos subidas cuando tenga sentido, pero sin importarnos la cadencia. El haber hecho subidas durante el Sprint enriquece nuestra Sprint Review. Ahora, podemos analizar esa subida con datos reales de los usuarios. En las otras dos estrategias, no podíamos analizar la subida hasta que no pasara un tiempo, por lo que solo podíamos inspeccionar el trabajo terminado pero no puesto en producción.
Por último, tenemos la subida funcional o continuous delivery. En esta estrategia, cada vez que finalizamos una feature, la subimos a producción. De esta manera, reducimos al máximo la liberación de código y obtenemos feedback instantáneo. Una vez más, la Sprint Review se convierte en un momento magnífico para analizar todas las subidas que hemos hecho y el impacto que están teniendo en el usuario o en nuestro mercado.
Conclusiones
La estrategia que estemos usando debe ser conocida por todos los stakeholders. Las subidas tras largos periodos de tiempo pueden provocar ansiedad en negocio, cuando ven que pasa el tiempo y no entregamos trabajo terminado. ,Sin embargo, en ciertos contextos se quiere garantizar que la subida es de calidad y, por tanto, es muy difícil hacer subidas con una estrategia funcional.
Mi consejo es que, al comenzar, tengamos una conversación con el equipo sobre qué estrategia nos conviene y lograr que todos estemos alineados con la misma.
Y tú, ¿qué estrategia de subida utilizas?
