En la introducción hablé sobre los aspectos generales del desarrollo en cascada y cómo podría integrarse DevOps en su ciclo de desarrollo de software. Sin embargo hay un punto importante a tener en consideración:
El desarrollo en cascada tiene tres etapas de diseño: levantamiento de requisitos, análisis y diseño. DevOps no puede integrarse a estas etapas y por lo tanto solo la mitad del modelo es aplicable. No es óptimo, los ciclos de desarrollo siguen siendo largos y los artefactos numerosos. Dado que la premisa principal de DevOps es acortar los ciclos de desarrollo por medio de la automatización y el monitoreo, resulta difícil llamar DevOps cuando se implementa este modelo. Por definición hay tres capas incompatibles, y solo las otras tres son monitoreables y automatizables.
Al final sería solo una modificación más del desarrollo en cascada, en donde se añadiría un etapa transversal entre la etapa de codificación y la etapa de integración y operaciones.
Desarrollo en espiral
Hay un modelo más que vale la pena mencionar antes de llegar a la guinda del pastel: el desarrollo en espiral.
El principal objetivo de este modelo es reducir las situaciones y eventos que pueden hacer que el proyecto falle y no alcance sus objetivos. Esto es muy importante, tanto así que muchos modelos de mejora como CMMI dan una importancia relevante a la gestión de riesgos, y muchas empresas se preocupan por implementar normas como la ISO 31000 en sus flujos de trabajo.
El desarrollo en espiral pretende que la definición y las implementaciones de un sistema crezcan, mientras los riesgos disminuyen. Es una premisa muy ambiciosa y para que funcione realmente las personas deben estar completamente alineadas con el modelo. En el siguiente diagrama vemos la representación de este modelo:
Los elementos en color naranja se comparten con el modelo en cascada. Todos los demás son nuevos o tienen un papel explícito en el ciclo de desarrollo. Aquí se puede apreciar tareas repetitivas, que están presentes en cada ciclo: el análisis de riesgos, prototipado y evaluaciones. Estos tres elementos garantizan el objetivo: disminuir riesgos y crecer el sistema. Las tareas nuevas dan peso a la retroalimentación y validación, el ámbito del que carecía el desarrollo en cascada.
Ahora bien, existe la idea de que este modelo es solo un conjunto de desarrollos en cascada modificados y en secuencia, sin embargo esto no es cierto: cada etapa del desarrollo en espiral incrementa la madurez del proyecto y reduce el cono de incertidumbre. Aunque hay una línea de evolución explícita, las tareas pueden repetirse si es necesario, y no necesariamente hay que seguir el orden estricto. Esta flexibilidad es posible gracias a las divisiones de etapas, las cuales definen el inicio del hito y el punto de llegada en cada etapa, donde las partes interesadas evalúan y acuerdan su satisfacción en el progreso hecho y acumulado del sistema. Una vez pasado ese punto todo lo que se hizo atrás está «bien hecho», y se puede seguir con la siguiente lista de tareas.
DevOps se convierte en una herramienta transversal en este modelo pero no está presente en todas las etapas, al menos no de manera directa. La automatización característica de esta técnica puede validar gran parte de todo un ciclo al final con los prototipos –que tecnicamente es el producto de una planeación y verificación en las primeras etapas de cada ciclo–, sin embargo dicho monitoreo no es constante (solo está presente en los prototipos y en la implementación). Su retroalimentación puede llegar muy tarde, ya que para que haya un prototipo que se pueda evaluar el equipo tuvo que haber pasado por el diseño, planeación, análisis de riesgos y demás. Luego de plasmado es más fácil dejarlo pasar que devolverse todo un hito para replantear de nuevo el diseño, sin mencionar que puede llegar a ser muy costoso.
¿Recuerda que este modelo no es un conjunto de desarrollos en cascada? Esto tiene que ver mucho, y es que el ciclo completo de desarrollo de software no es cuando se lanza un prototipo, sino cuando finaliza con la implementación. Ubique en este momento la tarea de implementación en el diagrama, ¿dónde está? Sí, al final de toda la espiral, por lo que todo el ciclo de desarrollo lleva 15 etapas y todas las tareas que esto conlleva. ¿Esto es crucial para DevOps? Por supuesto, y para darme a entender voy a explicar un concepto usado en proyecto de software a menudo grandes: el congelamiento.
El objetivo del congelamiento es restringir la adición de artefactos en el proceso de desarrollo luego de determinado punto. Después de que todo un equipo ha diseñado, planeado, estimado tiempos y generado decenas de artefactos, añadir un nuevo requisito que por lo general están en las etapas iniciales tendría muchísimo impacto en las tareas subsecuentes, y obligaría al equipo a devolverse al principio para replantear sus diseños, planeación y estimaciones teniendo en cuenta el nuevo requisito que llegó a «última hora». Por eso los equipos, luego de determinado punto invocan un congelamiento, lo cual obliga a que nuevos requisitos o características sean tenidos en cuenta en el siguiente ciclo de desarrollo. De esta manera el proyecto podrá seguir su curso normal, mientras que se puede planear a futuro una próxima liberación.
Hay diferentes tipos de congelamiento: congelamiento por votación, en donde el equipo vota si la nueva característica tiene un impacto alto o bajo –y pueden usar otras métricas– y si ven que el impacto en sus diseños ya hechos es bajo o muy bajo lo pueden tener en consideración. Está el congelamiento suave, el cual deja pasar las características que cumplan con alguna condición especial, como tener prioridad muy alta o que haya un cambio en la lógica de negocio. Y está el congelamiento duro. Este congelamiento no acepta ningún tipo de cambio y por lo general se encuentra en las últimas etapas de desarrollo, justo antes de empezar con la etapa de codificación.
Recordemos que DevOps busca acortar los ciclos de desarrollo para hacer las liberaciones más frecuentes, e implementar congelamientos en ciclos de desarrollo con muchas etapas y tareas implica alargar el mismo desarrollo y tener que esperar más tiempo para la liberación de las nuevas características, lo que lleva a pensar que este tampoco es un modelo óptimo para implementar esta práctica.
Hasta ahora hemos visto dos modelos: cascada y espiral. Ambos son rígidos y alienantes. Tratan de llevar el azar al mínimo y su orquestación es casi perfecta, como los compases de música, así son cada una de las etapas de ambos modelos.
Debo recordar una vez más que la eficiencia de un modelo depende del tipo de proyecto y equipo de trabajo. Por eso ningún modelo es anticuado, sino al contrario, nos abre la posibilidad de organizarnos de distintas formas, según cual nos convenga más.
Ahora, hay un modelo más, la cual está siempre agarrado de la mano con DevOps y dificilmente se pueden concebir de manera separada. Esta, o mejor dicho, estos modelos son los bien conocidos como «ágiles», pero de estos hablaré en la próxima entrega.
Continuará…
En la próxima entrega hablaré sobre los modelos ágiles, sus características y mostraré por qué su integración con DevOps es eficiente e intuitiva, y la codependencia entre ambos.