Hasta ahora en el blog hemos hablado de la influencia del movimiento Lean en el movimiento DevOps. También hemos visto cómo elaborar un Value Stream Map y cómo usarlo en un entorno DevOps. En este nuevo artículo voy a revisar un concepto básico de DevOps que tiene su fundamento de nuevo en el pensamiento Lean. Este concepto en el mundo Lean es el uso de lotes pequeños de trabajo o small batches, cuyo equivalente en un entorno DevOps sería las entregas pequeñas o pequeños incrementos de funcionalidad.
Como comentamos en el post dedicado al movimiento Lean, uno de los desperdicios más importantes es el exceso de inventario —también conocido como WIP o work in progress— que lleva inevitablemente a largos tiempos de ciclo. Reduciendo este inventario, o lo que es lo mismo, el tamaño de la entrega o el WIP, se reduce de forma considerable el tiempo de ciclo y se suaviza el flujo de entrega de valor. Esto es el fundamento de la ley de Little.
Analizando la Ley de Little
Para analizar la afirmación anterior, podemos utilizar el Value Stream Map elaborado en el post anterior o uno similar y analizar cómo se mueven las funcionalidades a lo largo de dicho flujo de valor.
En una organización que no usa small batches lo que sucederá en nuestra pizarra es que los post-it o funcionalidades se acumularán en cada estado. Cuando se alcanza un volumen suficientemente grande, definido por el tamaño del lote, se pasarán a la vez todos los post-it al siguiente estado. Por ejemplo, la persona encargada de recoger las peticiones de usuario, requisitos, etc. espera a tener todo un documento de requisitos completo o al menos un número suficiente antes de pasarlo a los analistas, quienes a su vez esperarán a tener el análisis completo para pasarlo a desarrollo, y así sucesivamente. Lo que en realidad estamos viendo es un lote grande de trabajo moviéndose por el Value Stream.
Analizando lo que ocurre con cada funcionalidad vemos que en vez de pasar inmediatamente al siguiente paso tiene que esperar a hacerlo—a modo de inventario— hasta que se complete el lote. Cuanto más grande es el lote más tiempo de espera sufre la funcionalidad, con lo que el tiempo de ciclo aumenta.
¿Qué ocurriría si en lugar de esperar a que se complete el lote cambiamos de estrategia y pasamos el bloque de funcionalidad al siguiente paso en la cadena de valor en cuanto esté completo? Que el tiempo de espera se reduciría a cero, y por tanto el tiempo de ciclo total se reduciría considerablemente.
Hagamos un símil con una situación que hemos visto multitud de veces por televisión o el cine: y es la de un grupo de personas que se organizan para apagar un fuego. Se colocan inmediatamente formando una cadena para pasar un cubo de agua de uno a otro con la intención de tener un flujo continuo de agua hacia el fuego. La estrategia equivalente en grandes lotes sería que el primero de la cadena esperara, por ejemplo a tener 10 o más cubos, para pasarlos todos juntos al siguiente. ¿Cuánto tardaría en llegar el primer cubo al fuego? Seguramente que demasiado tarde….
Actualmente en el desarrollo de software podemos usar esta estrategia de generar grandes lotes, pero corremos el riesgo que para cuando llegue nuestro producto al mercado sea demasiado tarde, igual que el conjunto de cubos.
Esto, que parece evidente para una situación en la que la velocidad de entrega es esencial, no parece serlo en el mundo del desarrollo de software a pesar de que el time to market es un factor vital actualmente.
Esta situación de crear grandes lotes es equivalente a lo que veíamos en la producción en masa en la cual se necesitaba un volumen grande de elementos para que la fabricación resultara rentable. Recordemos que el movimiento Lean hizo que fuera posible que la fabricación de coches fuera rentable sin necesidad de generar esos grandes lotes. De igual manera las buenas prácticas y estrategias de DevOps hacen que sea rentable entregar funcionalidad en small batches en vez de en grandes lotes.
¿Dónde podemos encontrar large batches?
Hay muchos puntos dentro de la cadena de valor en los que podemos encontrar grandes lotes de trabajo. Por ejemplo tenemos los siguientes:
- Largos documentos de requisitos o análisis. Un documento de requisitos es en realidad un lote de trabajo con multitud de funcionalidad.
- Grandes backlogs o pilas de producto. Sería el equivalente al documento de requisitos pero siguiendo el framework Scrum.
- Long lived Branches. Cada branch se convierte en un lote y cuanto más tiempo de vida tenga más grande se hará.
- Multitud de trabajo iniciado a la vez y no terminado.
- Etc.
Lo que se busca es reducir este trabajo en progreso. Pero, ¿cuáles son los beneficios de esta estrategia?
Beneficios del uso de small batches
Hemos visto que el beneficio principal del uso de lotes pequeños es la reducción del tiempo de ciclo, pero podemos resaltar otros beneficios que redundan en una implantación exitosa de un enfoque DevOps.
- Un efecto secundario de usar small batches es que obliga a los equipos de Dev y Ops a interactuar más frecuentemente, lo que facilita la transición de un modelo tradicional a DevOps. No es lo mismo que Dev le pase a Ops una entrega cada trimestre que todos los días. Esta interacción crea un fuerte sentimiento de equipo.
- La reducción del tiempo de ciclo derivado del uso de small batches hace que el feedback aumente considerablemente.
- Al hacer entregas más frecuentes se mejora el proceso por repetición. Si algo cuesta hacerlo, hazlo más frecuentemente hasta que se convierta en rutina. Esto enlaza con el concepto Lean de Kata.
- Debido a que las entregas son más pequeñas el riesgo derivado de ellas se reduce drásticamente.
- Al reducirse la complejidad de las entregas se simplifican los procesos de revisión y validación.
- Como ya comentamos los tiempos de espera se reducen considerablemente y eliminamos una gran fuente de desperdicio.
- El flujo de trabajo dentro del value stream se suaviza, lo que lo conlleva un aumento considerable de estabilidad y predictibilidad del proceso.
- Se posibilita la detección temprana de errores aumentándose la calidad, elemento fundamental de DevOps.
- Por último, y no menos importante, se facilita enormemente la implementación de la deployment pipeline y la entrega continua. Pretender hacer entrega continua con entregas grandes se antoja imposible.
Como vemos los beneficios de usar small batches son muchos y justifican por si solo el cambio de un modelo a otro.
Métodos para trabajar en small batches
Aunque parece sencillo, el cambio de metodología de trabajo es, desde mi punto de vista, radical y difícil.
A nivel de definición el cambio de uso del concepto tradicional de requisito al uso de historias de usuario es fundamental. El problema de las historias de usuario es que no es trivial elaborarlas cumpliendo el principio INVEST. En este acrónimo, las letras I (Independiente) y S (Small) son las que nos indican su encaje con las small batches. Si consigo hacer historias de usuario pequeñas e independientes, podré hacer entregas pequeñas.
Esto enlaza con el concepto de Requisitos Verticales en los que se entrega funcionalidad de todas las capas de la aplicación en contraposición a los requisitos horizontales que van construyendo capa por capa.
Fuente: Delta Matrix
Hay varios métodos para dividir historias de esta manera como son el método de la hamburguesa o el método SPIDR. Lo importante en este punto es conseguir dividir una determinada funcionalidad en historias de usuario que podamos entregar en small batches.
A nivel de desarrollo, una vez que tenemos buenas historias de usuario, esto nos habilita para poder usar técnicas como el feature branch o el uso de feature flags lo que nos acerca al concepto de entrega continua, o incluso pensar en el uso de una arquitectura de microservicios.
Conclusión
En la famosa presentación “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” que marca uno de los hitos en el movimiento DevOps, se hace mención explícita al uso de “small frequent changes”. De ella se extrae que un factor que posibilitó realizar ese número de entregas diarias es el tamaño de la release. Si dicha release consiste en el cambio de una línea de código sería muy sencillo implementar la entrega continua. A medida que el tamaño aumenta, la dificultad aumenta exponencialmente. De hecho, muchas implementaciones fallidas de DevOps son debidas a que se intenta automatizar el proceso de entrega usando “big bang releases”. En esa situación la complejidad y dificultad es demasiado grande.
El primer paso debería ser analizar el proceso de entrega e ir moviéndose hacia entregas pequeñas y una vez conseguido eso se podría empezar a automatizar la deployment pipeline.
En este artículo he querido reflejar como una decisión estratégica tan simple como es el tamaño de las releases condiciona totalmente el resultado de nuestra capacidad para entregar de forma continua.
Como esta entrega continua, o al menos rápida, es un pilar básico de DevOps podemos decir que el uso de small batches es fundamental para una implementación exitosa de DevOps.
Y aunque pueda parecer sencillo, no es trivial en absoluto. Por eso es muy importante que ante cualquier duda o cambio consultes con personal experto como el equipo de Xeridia.
Emiliano Sutil es Project Manager en Xeridia
