En posts anteriores hemos visto parte de los principios que aplican a DevOps y cómo podemos utilizarlos para guiarnos en la transición de nuestra empresa hacia DevOps. En éste quiero dar un paso atrás y revisar cómo, desde mi punto de vista, el pensamiento Lean ha influido de gran manera en la aparición y desarrollo del movimiento DevOps.
No pretendo hacer una descripción detallada de qué es el pensamiento Lean ya que hay mucha literatura al respecto, sino que quiero dar mi visión de cómo los mismos principios que revolucionaron el sector de la producción han revolucionado el sector del desarrollo de software y cómo DevOps se alimenta de los mismos principios.
En este sentido es importante recordar que cuando apareció el movimiento Lean, de la mano de Taichi Ohno de Toyota, el modelo de fabricación estaba basado en la producción en masa, considerada la única manera de producir coches a bajo coste.
La imposibilidad por parte del mercado japonés de seguir esa estrategia hizo posible la aparición del movimiento Lean. Es decir, si los japoneses hubieran podido seguir la estrategia dominante, seguramente lo habrían hecho y no habrían tenido que idear una nueva estrategia competitiva. Por tanto, esa desventaja competitiva hizo que tuvieran que idear nuevas maneras de trabajar para poder competir y que a la larga se convirtieron en la estrategia establecida en el sector de la fabricación.
De igual manera, en el ámbito de desarrollo de software la crisis del modelo tradicional ha propiciado el desarrollo de nuevas estrategias mucho más competitivas. Si mediante los métodos tradicionales pudiéramos cumplir con esa entrega de valor, seguramente el movimiento DevOps no habría tenido tanto impacto; Pero la realidad es que ante la imposibilidad de desarrollar software y entregar valor a la velocidad y calidad que demanda el mercado siguiendo “métodos tradicionales” de desarrollo, en la actualidad el enfoque DevOps se está imponiendo como la estrategia de éxito a la hora de realizar la entrega de valor al cliente.
Tras esta reflexión sobre el pensamiento Lean voy a describir brevemente qué principios hicieron posible esta revolución y presentaré su influencia en el movimiento DevOps.
Los principios del pensamiento LEAN
El pensamiento Lean es muy amplio y nada más lejos de mi intención hacer una descripción rigurosa de los mismos, pero sí que conviene saber cuáles son estos principios. Me voy a centrar en los principios que aplican al desarrollo de software tal cual se definieron en el libro «Lean Software Development: An Agile Toolkit» de Mary Poppendieck y Tom Poppendieck —cuya lectura recomiendo.
Los principios del pensamiento lean son los siguientes:
- Eliminar el desperdicio. Es el principal principio y es el que primero viene a la mente cuando se habla de Lean. Solo eliminando el desperdicio la mejora de productividad es realmente notable. Lo importante es determinar qué es desperdicio y qué no. En este punto una herramienta muy útil para detectar desperdicios es el Stream Value Map que cualquier persona que practique DevOps debería usar. Mediante esta herramienta se mapean de manera visual todas las actividades que se realizan para llevar a cabo un determinado trabajo a lo largo de todo el flujo de entrega de valor. Para cada etapa se identifica cuáles aportan valor, cuales tienen tiempos de espera más altos, cuales generan inventario… De esta manera se pueden identificar los cuellos de botella y los puntos de mejora. En siguientes posts describiré maneras de aplicarlo para descubrir estos desperdicios.
- Amplificar el aprendizaje. El pensamiento Lean se basa en la mejora continua y en crear una cultura de aprendizaje continuo. En este punto la relación con el movimiento DevOps es más que evidente ya que es un pilar fundamental del mismo.
- Entregar lo más rápido posible. Este punto enlaza directamente con el “First DevOps Way” de acelerar el flujo. De este principio surgen todas las prácticas que intentan disminuir los tiempos de ciclo.
- Decidir lo más tarde posible. Este principio está íntimamente relacionado con el anterior. Si soy capaz de hacer entregas muy rápidas puedo esperar a tener la mayor cantidad de datos posible y evitar así tomar decisiones con información incompleta o errónea. Lo que sí tengo que ser capaz es de que en cuanto se toma la decisión, esta se entrega se realice rápidamente.
- Empoderar al equipo. La idea del agilismo de equipos auto-organizados surge de este principio y es un pilar básico de DevOps como ya vimos en el post anterior.
- Embeber la integridad. Este principio enlaza directamente con las prácticas de diseño incremental, refactoring, testing y aseguramiento de la calidad. El pensamiento Lean está muy centrado en la calidad y en no dejar pasar errores a lo largo de la cadena de valor. El concepto de la deployment pipeline se alimenta directamente de este principio.
- Considerar el sistema como un todo. Por último y no por ello menos importante el pensamiento Lean considera la entrega de valor como un sistema completo, huyendo de las optimizaciones locales que son fuente importante de desincronizaciones y desperdicio.
Muy resumidamente estos son los principios del pensamiento Lean, donde observamos que su influencia en DevOps resulta evidente. Pero quiero hacer algunas reflexiones (personales) sobre algunos puntos de especial interés en esta comparación.
Lean y DevOps
Si comparamos los principios del pensamiento Lean con los 3 principios de DevOps condensados en los 3 caminos de la metodología DevOps (acelerar el flujo, ampliar el feedback y crear cultura de continua experimentación y aprendizaje) vemos que tienen una traslación directa.
En cuanto al principio de “eliminar el desperdicio” el punto clave es ver qué se considera desperdicio desde la perspectiva del desarrollo de software en general y para DevOps en particular. Desperdicio será todo aquello que no aporte valor y para el caso particular de DevOps aplican todos los desperdicios descritos en la literatura Lean, como son el exceso de inventario en forma de trabajo parcialmente terminado, los bugs, etc. Uno de los desperdicios en concreto es el relacionado con el transporte de paquetes de trabajo, que si bien en fabricación está muy claro, en un entorno DevOps tiene un significado especial. En este entorno tiene que ver con movimiento de trabajo entre equipos. Es decir cada vez que se pasa trabajo de un equipo a otro se está incurriendo en un desperdicio relativo al transporte o motion. En DevOps, al trabajar conjuntamente Dev y Ops, este desperdicio desaparece. Nos sorprenderíamos de la cantidad de desperdicio generado derivado de esta separación.
Otro desperdicio derivado de la separación de departamentos es el tiempo de espera. Todos los tiempos que se pasan en una cola esperando son desperdicio. De nuevo con el uso de DevOps este tiempo se disminuye ya que virtualmente el tiempo de espera entre Dev y Ops se reduce a cero. Esto, unido al empoderamiento del equipo a la hora de la toma de decisiones, hace que los tiempos de espera generados por complicados comités de cambio o burocracias se reduzcan drásticamente.
Desde mi punto de vista solo la reducción de estos dos desperdicios (motion y esperas) justifican la mejora en los tiempos de ciclo como se puede observar al utilizar la herramienta Value Stream Mapping.
Por último, el cambio de pensamiento fundamental es el relativo a “Considerar el sistema como un todo”. Es fundamental por el enorme impacto que tiene y por lo difícil que es de llevar a cabo.
El hecho de darse cuenta de que el proceso de entrega de valor en un sistema es un proceso holístico en el cual el todo es mayor que la suma de sus partes implica un cambio importante en la estrategia para conseguir el objetivo de entregar valor lo más rápido posible.
La dificultad para el cambio de mentalidad viene derivada de que para afrontar un problema grande, las enseñanzas tradicionales dicen que se debe dividir el problema en partes más pequeñas de manera que optimizando éstas por separado se puede llegar a optimizar el proceso. Esta manera de pensar lleva ineludiblemente a optimizaciones locales dentro del proceso que a su vez acaban generando pérdidas de eficacia en el proceso en su conjunto.
Esto es lo que ha venido pasando a raíz de la idea de que se puede separar desarrollo de operaciones, optimizar ambas partes por separado y conseguir que el rendimiento global del sistema aumente. Se ha demostrado que lejos de mejorar el sistema, empeora.
Una comparación muy popular para ilustrar esta idea es la preparación de una maratón. Para ganarla, no es una buena estrategia optimizar al máximo cada kilómetro porque nos llevaría a esprintar en cada kilómetro y a perder la carrera en última instancia. Lo importante es el todo, no la optimización local. En DevOps ocurre lo mismo; su mayor fortaleza es precisamente la optimización del proceso en su conjunto y por eso realmente DevOps es más una transformación de una empresa completa a todos los niveles y no una optimización de uno u otro proceso.
Lo importante es darse cuenta que el proceso de entrega de valor es un sistema complejo con elementos no lineales. Estos elementos no lineales son las personas que forman parte del proceso.
Una vez que hemos determinado que nos enfrentamos a la difícil tarea de controlar un sistema complejo, intentar aplicar las técnicas de control erróneas al mismo nos llevaran al fracaso. El pensamiento Lean y DevOps tienen esto en cuenta y de ahí su efectividad.
» La mayor fortaleza de DevOps es la optimización del proceso en su conjunto y por eso realmente DevOps es más una transformación de una empresa completa a todos los niveles y no una optimización de un proceso u otro »
Para resumir, en este post he querido reflejar la gran influencia que tiene el pensamiento Lean en el movimiento DevOps para que ayude a comprender el porqué de muchas de las estrategias que se aplican a DevOps y porque realmente son efectivas.
En siguientes post iremos viendo algunas de estas estrategias y veremos cómo se alinean con estos principios del pensamiento Lean que he descrito brevemente.
Emiliano Sutil es Project Manager en Xeridia
