Los 3 caminos de DevOps

Los Tres Caminos de DevOps

Primer Camino

El enfoque está en todas las corrientes de valor de negocios que están habilitadas por TI. Comienza cuando los requisitos son identificados por la empresa o TI, se integran en el desarrollo y luego pasan a las operaciones de TI donde el valor se entrega al cliente en forma de un servicio.

Los resultados de The First Way incluyen:

    Nunca pasar un defecto conocido a los centros de trabajo aguas abajo;

    Nunca permitiendo que la optimización local cree una degradación global;

    Siempre buscando aumentar el flujo;

    Siempre buscando lograr una comprensión profunda del sistema;

El propósito de la Primera forma es ver la TI como una cadena de valor, en la que se ejecutan las actividades de valor agregado. Al igual que en una fábrica de ensamblaje de automóviles, cada paso en el proceso agrega valor y se recomienda encarecidamente hacerlo correctamente la primera vez.

El punto principal detrás de este primer principio es que el trabajo fluya de izquierda a derecha lo más rápido posible, desde Negocios, a través de Desarrollo, a Operaciones, y, en última instancia, al Cliente, donde realmente se crea el valor.

Una forma de acelerar el flujo es reducir la cantidad de trabajo en proceso (WIP) que, por sí solo, no proporciona ningún valor: al igual que las materias primas en un almacén, WIP solo crea valor como producto terminado al final de el flujo. Es por eso que queremos que los trabajos más pequeños pasen por la tubería de izquierda a derecha, lo que da como resultado un flujo más rápido, que en última instancia ayuda a generar valor más rápido, y también permite una retroalimentación más rápida sobre ese trabajo (consulte la Segunda vía para más información sobre este ).

Otra acción importante a considerar cuando se enfoca en este principio es la eliminación de restricciones. Su flujo nunca será más rápido que su mayor restricción en el camino de ese flujo. Si tiene un nodo que está muy ocupado, y si el flujo que está considerando necesita pasar por ese nodo, entonces la velocidad del trabajo se reducirá por esa restricción. En The Phoenix Project , el nodo o la mayor restricción es una persona, Brent. 

Mejorar el rendimiento del flujo en su empresa podría no solo ser gente o tecnología, sino que también podría estar relacionado con la cultura y los procesos de la empresa. ¿Podría ser que su mayor restricción es un proceso que la compañía está utilizando durante mucho tiempo y que vale la pena revisar? Tal vez mirar en el proceso no es tan atractivo como mirar en nuevas tecnologías, pero podría ganar mucho si es allí donde reside su mayor restricción. 

Segundo Camino

La segunda forma consiste en crear bucles de retroalimentación de derecha a izquierda. Con casi cualquier iniciativa de mejora de procesos, el objetivo es acortar y amplificar los bucles de retroalimentación para que se puedan hacer las correcciones necesarias continuamente.

[pic 1]

Los resultados de The Second Way incluyen:

• Entendiendo y respondiendo a todos los clientes, internos y externos.
• Acortando y amplificando todos los bucles de realimentación.
• Incrustar conocimiento donde lo necesites.

El propósito de Second Way es comprender que una cadena de valor solo puede optimizarse incorporando retroalimentación. ¿En qué parte del proceso hemos esperado sin cesar? ¿Por qué necesitamos rehacer un paso específico? Al mejorar constantemente la cadena de valor completa, su organización de TI se vuelve mejor, más productiva y menos propensa a errores.

The Second Way se enfoca en aumentar los ciclos de retroalimentación de derecha a izquierda . Aquí, la atención se centra en aumentar tanto el número de bucles de retroalimentación que tiene en su flujo (¿solo está recibiendo retroalimentación de lo que tiene en su sistema de producción?) Y también en la rapidez con la que recibe esa retroalimentación (cuánto tiempo dura) ¿Es necesario detectar un requisito empresarial defectuoso? ¿O un error introducido por un desarrollador?). Un punto importante aquí es que queremos que nuestro flujo se detenga una vez que se encuentren los errores y queremos que la retroalimentación proveniente de ese error se transmita lo más rápido posible a la fuente, para que pueda ser corregida. 

...