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
No hay comentarios:
Publicar un comentario