Evaluación de la eficacia del proceso con mapas de flujo de valor
Cuando se crea un mapa de flujo de valores, o VSM, este sirve de ayuda para analizar el proceso del ciclo de versión actual. El propósito de un mapa de flujo de valor es mostrar visualmente en qué punto exacto del proceso un equipo crea valor y dónde lo desperdicia. El objetivo es lograr un proceso que ofrezca el máximo valor al cliente, con un desperdicio mínimo. Un mapa de flujo de valor puede ayudarle a identificar las áreas que no aportan ningún valor o que, en realidad, reducen el valor del producto.
Veamos cuáles son las medidas de Tailspin.
Mara, que es nueva en el equipo, va a crear un mapa de flujo de valor para comprender mejor el proceso existente. Con un mapa de flujo de valor, tendrá una idea de dónde encaja el equipo en el modelo de madurez de DevOps. Según parece, los equipos más experimentados suelen lanzar versiones más rápidamente, con mayor confianza y con menos errores que los menos maduros.
Mara sabe que aún no conoce todo, por lo que va a crear un mapa de flujo de valores rápido en la pizarra de la sala de reuniones. Habrá algunos huecos y preguntas sin responder, pero no importa. Es un comienzo. Cuando lo tenga todo listo, compartirá sus impresiones con el equipo. Este mapa proporcionará a todos los usuarios un punto de partida común para identificar los primeros pasos que deben darse para mejorar la forma en que Tailspin desarrolla sus sitios web y los publica.
Echemos un vistazo al mapa.
Comprensión del proceso actual
Mara reúne al equipo en la sala de juntas para presentar el mapa de flujo de valor.
Mara: Un mapa de flujo de valor nos ayuda a calibrar qué parte del proceso tiene valor para los clientes y dónde estamos perdiendo tiempo sin generar ningún valor. Nuestro mapa comienza en la parte superior izquierda, con la especificación de las funciones del software. Vamos a centrarnos en una sola característica para ver cómo avanza por nuestro ciclo de lanzamiento actual.
Algunas personas ponen los ojos en blanco, pero Mara insiste.
Procesos de desarrollo
Actualmente, para crear una característica se empieza por crear una etiqueta de control de código fuente 
. Tenemos una persona que sabe crear etiquetas, que es Andy. Le pedimos que cree una etiqueta por correo electrónico. Usamos un sistema de control de versiones centralizado, por lo que Andy espera hasta que todo el código existente esté sincronizado y estable para crear la etiqueta. Una vez creada la etiqueta, recibimos un correo electrónico en el que se nos dice que podemos empezar a trabajar. Este proceso tarda hasta tres días y no tiene ningún valor para el cliente. Lo que no tiene valor para el cliente debería llevar el menor tiempo posible.
Una persona tarda alrededor de cuatro días en crear el código de una característica, una vez que tenemos acceso a todos los archivos que necesitamos 
. Debemos estar en la red corporativa para acceder al control de código fuente. Esta vez sí que hay valor para los clientes. Quieren esta característica.
Pruebas de los procesos
Después de constatar que tenemos una versión estable, actualizamos una hoja de cálculo para indicar a Amita que hay una compilación lista para realizar pruebas y dónde puede encontrarla 
. Tarda dos días en recibir la notificación.
Amita comprueba manualmente la compilación 
. Este proceso se va prolongando cada vez más a medida que la base de código va creciendo. Por ahora, vamos a decir que tres días. Después, envía un correo electrónico a Andy con un informe de errores. Las pruebas no agregan valor, pero son necesarias.
Ahora Andy tiene que dedicar tiempo a evaluar los errores y asignar trabajo . Andy puede tardar otros tres días más en comprender los problemas y asignarlos a los desarrolladores adecuados.
Procesos de las operaciones
Cuando Amita aprueba una compilación, se la entrega a Tim. Tim necesita implementar esta compilación en los servidores de preproducción para realizar más pruebas. A menudo, los servidores de preproducción no están sincronizados con las últimas revisiones y actualizaciones necesarias para ejecutar el sitio web. Tim tarda unos dos días en realizar la implementación en el entorno de preproducción y en llevar a cabo algunas pruebas. De nuevo, la implementación en un entorno de preproducción no agrega valor, pero es necesaria 
.
Cuando haya una compilación lista para producción, los jefes deben aprobar la versión antes de que esta pueda implementarse. La aprobación se produce en una reunión. Transcurren cuatro días hasta que los jefes se reúnen y revisan la versión.
Finalmente, Tim implementa la característica y esta llega al cliente aquí, en la esquina superior derecha del mapa de flujo de valor. Si la configuración del servidor de producción se desvía y no está sincronizada con el entorno de preproducción, Tim tiene que actualizarla antes, y este proceso tarda un día 
.
Cálculo de las métricas de valor para el cliente
Ahora podemos observar las métricas de rendimiento clave y ver qué hemos conseguido.
El plazo total de ejecución es el tiempo necesario para que una característica esté disponible para el cliente. En este caso, el tiempo total es de 22 días. El tiempo de proceso es el tiempo invertido en la característica que tiene valor para el cliente. En este caso, el tiempo de proceso incluye cuatro días para la creación de código más un día para implementar la característica, lo que nos da un total de cinco días.
El coeficiente de actividad es el tiempo de proceso dividido entre el plazo total:
$${Coeficiente \ de actividad\ =\ }{\dfrac{Tiempo de\ proceso}{Plazo\ total\}}$$
Este valor corresponde a nuestra eficacia. Ahora multipliquémosla por 100 para obtener un porcentaje. El resultado es mayor que 0 y suele ser menor al 100 %. Un porcentaje más alto indica una mayor eficacia.
Si sustituimos las cifras, obtenemos esto:
$${Coeficiente\ de actividad\ =\ }{\dfrac{5\ días}{22\ días}}{ = 0,23}$$
Si el resultado se multiplica por 100 %, se obtiene un 23 %.
Como se puede apreciar, tenemos mucho que mejorar. Además, tardar 22 días en desarrollar una característica es demasiado.
Tim: ¿Cómo nos ayuda esto?
¿Qué hacemos ahora?
Mara: Esto nos sirve para ver dónde estamos ahora mismo; así, podemos identificar las áreas en las que no somos rentables. Queremos reducir al mínimo el tiempo que empleamos y que no tiene valor alguno para el cliente. Estoy convencida de que podemos ser más eficaces si adoptamos un método de DevOps. En primer lugar, podemos automatizar muchos de estos pasos, lo que reduce drásticamente el tiempo necesario.
No estoy sugiriendo que abandonemos los procesos actuales, pero creo que podemos trabajar para lograr un proceso más eficaz en pequeños pasos, sin interrumpir lo que tenemos actualmente.
Echemos un vistazo a un par de áreas donde podemos mejorar.
Andy: También podríamos comenzar por el principio. Tardo muchísimo en obtener una etiqueta en el código para poder empezar con la nueva característica. Tengo que dirigirme a los desarrolladores y pedirles que comprueben lo que tienen para poder compilar y probar. Si eres capaz de averiguar cómo acelerar esto, te escucho.
Además, me he dado cuenta de que ahí no hay tiempo especificado para la compilación en sí. Actualmente, estamos tardando medio día para ello. Estaría bien mejorar ese plazo.
Amita: Aparte de eso, el equipo de desarrollo no siempre actualiza la hoja de cálculo para avisarme de que hay una nueva compilación que debe probarse. Ahorraríamos tiempo si hubiera alguna forma de garantizar que esa parte se lleva a cabo.
Mara: ¡Genial! Creo que DevOps nos puede ayudar con todas estas cuestiones.
Andy: No tenemos tiempo para cambiar el proceso ahora. Ya habéis oído a Irwin. ¡Estamos en plena crisis!
Mara: Entiendo. Por ahora, vamos a hacer lo que siempre hacemos. Pero también podemos reflexionar sobre cuál es nuestro papel en el proceso y cómo podemos mejorarlo. Podemos empezar a realizar pequeños cambios en paralelo a los procesos actuales. Luego podemos ver si DevOps nos resulta útil sin interrumpir lo que ya tenemos. Guardaré el mapa y las métricas de rendimiento. Si al final adoptamos procedimientos de Azure DevOps, podemos volver a revisar las cifras. Quizás podemos actualizar el mapa de flujo de valor en algún momento.