Cómo hacer un Value Stream Mapping: ejemplo de desarrollo de software

En el artículo de hoy vamos a explicar cómo aplicar la técnica de Lean llamada Value Stream Mapping (VSM), de forma práctica y con un ejemplo real de desarrollo de software. No confundir con Value Stream Management, aunque están muy relacionados como veremos.

¿Qué es el Value Stream Mapping?

Resumiendo mucho, el Value Stream Mapping (o Mapa de Flujo de Valor, en español) se basa en observar, analizar, medir y, sobre todo, entender un proceso en profundidad. Este proceso puede ser de la índole que queramos y de la complejidad que sea, se puede aplicar a pequeña y gran escala. Pero la palabra más importante en la frase anterior es «entender». ¿Por qué? ¿Cuál es el objetivo de entender mi proceso? El objetivo no es más que identificar todos esos puntos de desperdicios (y ya sabemos que en Lean la búsqueda y eliminación de desperdicios debe ser una constante) y actividades que no agregan valor para poder tomar decisiones sobre cómo mejorar el proceso. Y en ese punto, entra el Value Stream Mapping.

Para el caso que nos atañe vamos a imaginarnos un proceso de desarrollo software de una aplicación web.

Pasos para hacer un Mapa de Flujo de Valor

¿Cuáles son los pasos que debemos dar para realizar un Mapa de Flujo de Valor? Podríamos diferenciar los siguientes puntos:

Establecer el proceso a mapear

Definir el proceso a analizar. Este proceso puede ser el desarrollo de un producto, un servicio, una parte del ciclo de vida en específico, etc. Lo importante es que tengamos muy claramente definido qué proceso queremos (intentar) mejorar. Porque sobre esto construiremos el resto. En nuestro caso el proceso sería: «Entrega de software a usuario final, desde que nace la necesidad hasta que llega a las manos del usuario final».

Personas que intevienen en el proceso

Identificar a todas las personas o actores implicados en nuestro proceso. Si es necesario, con nombre y apellidos y, a poder ser, el rol. Ya realizando este paso tendremos debates interesantes como, ¡sorpresa!, alguien que no sabía qué parte del proceso está en su tejado. Es indiferente el grado de participación que haya sobre el proceso, todas las personas son importantes. En nuestro caso tenemos:

• Equipo de desarrollo: Susana, Manuel, Ainhoa, Israel y Paloma.
• Product Owner: Macarena.
• Stakeholders: Alicia y Alfonso.

Tareas y actores que participan en ellas

Determinar todas las tareas que componen el proceso y qué actores participan en cada una. Para nuestro caso vamos a hacer una abstracción porque puede llegar a ser muy complejo, con lo que vamos a coger pasos generales. La asignación de personas a tareas también está simplificada para este ejemplo:

• Recoger feedback de usuarios: Stakeholders
• Analizar feedback: Stakeholders & Product Owner
• Añadir tareas a Backlog: Product Owner
• Refinar tareas de Backlog: Product Owner & Dev Team
• Desarrollar tarea de Backlog: Dev Team
• Despliegue en entorno no productivo: Dev Team
• Validación en entorno no productivo: Dev Team
• Despliegue en entorno final: Dev Team

La casuística puede dar mucho más de sí pero como consejo, lo mejor es pensar qué ocurre en mi proceso el 80% de las veces. El otro 20% serán las excepciones.

Value Stream Mapping ideal

El siguiente paso es el complicado e intentaremos resumir mucho. VSM dice que cada proceso tiene realmente 3 versiones:

• Versión 1: Cómo pensamos que es
• Versión 2: Cómo realmente es
• Versión 3: Cómo debería ser

En nuestro caso, los pasos descritos anteriormente corresponde a una versión 2. Vamos a suponer que previamente hemos hecho un ejercicio de definir la versión 1 (cómo pensamos que es) y, con datos por delante, hemos llegado a definir la versión 2, lo que realmente es. El nivel de detalle de este mapa de flujo de valor puede ser muy profundo.

En nuestro caso vamos a añadir dos métricas del proceso que, creemos, es dónde podemos poner el foco para mejorar el proceso. Vamos a identificar nuestro Lead Time (tiempo desde que se detecta la necesidad hasta que el software llega al usuario final) y nuestro Workflow efficiency (la eficiencia del flujo de trabajo, tiempo efectivo de trabajo sobre la tarea). Obtenemos los siguientes valores:

• Lead time : 10 días.
• Workflow Efficiency: 2 días.

Como nuestro principal objetivo para la mejora es minimizar el tiempo en que tarda el software en llegar a manos del usuario, vamos a definir la versión 3 de nuestro proceso: cómo nos gustaría que fuera. ¿Cómo? Marcando un objetivo claro y conciso: disminuir nuestro Lead Time al 50% (es decir, 5 días) en los próximos 3 meses sin que el Workflow Efficiency se vea afectado.

Plan de acciones de nuestro VSM

Nos queda un último paso. Tenemos que acordar un conjunto de acciones que nos ayude a pasar de la versión 2 a la versión 3 de nuestro proceso y conseguir el objetivo marcado para este caso. En definitiva: desarrollar un Plan De Acción (PDA). Una buena práctica es involucrar a todos los actores implicados en esta parte del proceso (ya que los tenemos identificados) porque se verán afectados por nuestro PDA.

En nuestro caso tendríamos que analizar, basándonos en las métricas que tenemos, dónde se está generando mayor desperdicio para llegar a esos 10 días cuando, realmente, el trabajo efectivo es de 2 días. En nuestro ejemplo una vez que todo el equipo ha analizado toda la información encontramos que el proceso de despliegue no es óptimo. Desde que se termina un desarrollo hasta que llega a producción, una vez validado incluso, tarda varios días. Hay pasos manuales que impiden ir más rápido. Es por ello que se decide tomar la siguiente acción: automatizar despliegues a producción.

Nuestra acción habría que detallarla mucho más, pero no es el objetivo de este post. Lo importante es que sea de tipo SMART:

• S – Specific – Específico
• M – Measurable – Medible
• A – Attainable – Alcanzable
• R – Relevant – Relevante
• T – Timely – Temporal

¿Con esto hemos terminado? No aún. Un paso continuo en el tiempo y que se suele olvidar y, por ello, falla nuestro PDA es seguir el plan y, sobre todo, volver a medir los resultados frecuentemente. Solo así podremos tomar decisiones correctas.

Conclusión

Hemos visto cómo hacer un Value Stream Mapping con un ejemplo real de un proceso de desarrollo de software. ¿Utilizas habitualmente esta técnica de Lean? Si quieres conocer más sobre Agile, suscríbete a nuestro canal de YouTube.