Páginas

domingo, 12 de enero de 2020

Qué son las “The Three Ways” de DevOps.


Antecedentes

Uno de los conceptos fundamentales en Lean es el de “Value Stream”.  El “Value Stream” entendido cómo la secuencia de actividades requeridas para diseñar, producir, entregar un bien o dar servicio a un cliente; esto incluye los flujos de información y de materiales necesarios.
En Devops se define el “Value Stream”  de TI como el proceso requerido para convertir una hipótesis de negocio en un servicio proporcionado por la tecnología que entrega valor al cliente.
El tiempo de entrega es el tiempo que transcurre desde que el cliente hace una petición hasta que le es entregado el producto o servicio. El tiempo de proceso es el que transcurre desde que el trabajo se empieza a hacer hasta que se termina. Ver la siguiente figura:



El tiempo de entrega siempre es superior o igual al de proceso. Si se mejora cualquiera de estos tiempos la entrega de valor es más pronta y cuanto antes se entregue el valor más competitiva será la organización.

Particularizando en DevOps

En el caso de DevOps el “ Value Stream” de TI en muchas organizaciones está compuesto por múltiples actividades que llevan a cabo diversos profesionales con habilidades y conocimientos distintos. En “The DevOps HandBook” se muestra la siguiente figura:


 Aquí se representa el flujo de trabajo para poner en marcha un sistema en el entorno productivo, desde su concepción hasta su implantación. Al final de este flujo los clientes pueden utilizarlo y de esta forma recoger el valor que entrega el sistema.  La figura muestra un flujo de trabajo con muchas trasferencias, es decir en un paso el equipo correspondiente  hace un trabajo (por ejemplo:  desarrollar) a continuación se transfiere el trabajo al equipo que tiene que dar el siguiente paso (por ejemplo: Instalar el sistema en el entorno de pre-producción). Cada paso tiene sus propios tiempos de entrega y proceso. Mejorando estos tiempos entregaremos antes las aplicaciones, apps, webs, etc.
Además también hay que tener en cuenta el porcentaje de trabajo completado y asegurado. Este es el porcentaje de trabajo que en cada paso llega utilizable tal cual al siguiente paso, es decir se puede usar sin pedir más información o corregir la información suministrada.  Por ejemplo: para la instalación del sistema en preproducción, el equipo no tiene suficientes instrucciones para la creación de las tablas de la base de datos. Cuanto más elevado sea este porcentaje, habrá menos idas y venidas, no se re-trabajará y de nuevo se entregará el trabajo con más prontitud.

Las “Three ways”

En “The DevOps HandBook” los autores proponen una secuencia de mejora del “Value Stream” de DevOps. En la secuencia recomiendan abordar las mejoras en tres fases, que son las tres formas de mejorar. Estas son:

  •  Primera forma: Mejorar el flujo.
  •  Segunda forma: Hacer buen uso del feedback.
  • Tercera forma: Establecer el aprendizaje y mejora continua.

Recomiendan abordar las mejoras de estas 3 formas y hacerlo una tras otra. Es decir, primero poner el foco en mejorar el flujo, luego agregar al objetivo usar el feedback y para terminar sistematizar la forma en que se aprende de los errores y los éxitos e incorporar ese aprendizaje a la  mejora.

Primera forma: Mejorar el flujo

Aquí se trata de conseguir que el flujo de actividades para llevar los sistemas al entorno productivo sea constante y sin sobresaltos. Para ello existen múltiples recomendaciones:

  • Hacer el trabajo visible
  • Reducir el tamaño de los paquetes de trabajo es decir entregar menos funcionalidades juntas, pero más a menudo.
  • Automatizar los trabajos.
  • Construir con calidad.
  • Integración/entrega/despliegue continuos.
  • Fácil creación de entornos.
  • Prepararse para el cambio.

Segunda forma: Hacer buen uso del feedback

Se trata de establecer mecanismos para que en cada paso seamos capaces de hacer llegar información sobre el resultado de su trabajo a los pasos anteriores.  Cuando los equipos conocen el resultado de su trabajo corriente abajo, son capaces de aprender de sus éxitos y sus errores. Repitiendo lo que se hace bien y cambiando lo que hacen mal para intentar no repetir los errores.

Tercera forma: Establecer el aprendizaje y la mejora continua

Permitir un enfoque dinámico, disciplinado y científico hacía la experimentación y la aceptación de riesgos para aprender de los éxitos y los fracasos. Por ejemplo, estableciendo programas de uso de ataques a los propios sistemas como los recomendados por el Chaos Monkey. Esta es una iniciativa de Nexflix, donde periódicamente lanzan ataques contra sus propios servidores para observar las consecuencias y hacerse más resistentes a posibles problemas.

Bibliografía

The DevOps Handbook
 John Willis; Jez Humble; Gene Kim; Patrick Debois
 Publicado por IT Revolution Press, 2016

No hay comentarios:

Publicar un comentario