En el primer artículo de esta serie vimos los siete principios Lean y sus bases fundacionales esenciales. Durante la segunda parte analizamos cada principio Lean y mostramos algunas prácticas Ágiles que los implementan. En esta tercera y última parte refleccionaremos sobre la práctica de Justo-A-Tiempo (JIT) y sobre el uso de Lean en general.
Reflexionando sobre Justo-A-Tiempo (Just-In-Time o JIT)
Existe un paralelismo entre la producción estándar y JIT de la misma forma que existe un paralelismo entre el proceso de software por Cascada y el Desarrollo Iterativo. En Cascada, tomamos todos nuestra "materia prima" (los requerimientos) y los comenzamos a procesar en grandes bloques. Los recursos que necesita el equipo (DBAs, analistas, testers) están disponibles en distintos intervalos, así que ubicamos estos bloques de trabajo (analisis, diseño, codificación, pruebas) para utilizarlos los más posibles a estos recursos. Como estamos construyendo tantas cosas a la vez, hacemos un gran esfuerzo para averiguar qué se necesita hacer antes de comenzar el proceso de producción (similar al análisis completo de Cascada). En cambio, en JIT sólo trabajamos en aquellas partes que necesitamos, y además, sólo trabajamos justo antes de que se necesiten. Esto es similar a a tomar una historia con una metodología Ágil, y hacer el análisis justo antes de construirla y validarla.
Al realizar el trabajo de a pasos pequeños y completos, JIT en el mundo del software nos permite cambiar la dirección al finalizar cada pequeña parte completa - sin generar desperdicios. Uno de los mantras de la producción es minimizar el trabajo en progreso (WIP). Vamos a ver que los métodos Ágiles apuntan a esto mismo también.
Por supuesto, lograr JIT no es facil. Requiere de un proceso con una tasa de errores baja y constante. Sin embargo, es este requerimiento el que hace que las deficiencias en un proceso sean más evidentes. Así resulta más facil verlas y por lo tanto más facil arreglarlas. Este es justamente uno de los pilares de Scrum, que se esfuerza en eliminar los impedimeintos que surgen en el flujo de las historias.
JIT tiene otras ventajas. No sólo sirve para descubrir problemas en el proceso, sino que también descubre problemas en la producción. Esto ocurre porque los errores durante la producción se suelen descubrir recién en los últimos estadíos de la producción. Si existe un gran inventario entre pasos, va a pasar un largo tiempo antes de descubrirlo, y por lo tanto pueden llegar a producirse un enorme inventario de errores. En el software, esta demora en descubrir los errores de un requerimiento, por ejemplo, se traduce en esfuerzo desperdiciado para construirlo y probarlo, y luego la complejidad añadida que resulta en agregarlo al sistema aunque no le brinde valor al cliente. Esencialmente, si el código terminado puede ser entregado a los clientes (o al menos demostrado) de forma rápida, vamos a obtener feedback de ellos y sabremos si estamos produciendo cosas de valor.
Entonces, JIT brinda una guía para el desarrollo de software. Podemos ver a los métodos Ágiles como una implementación de los principios de JIT. No hacemos un análisis completo de las historias hasta justo antes de construirlas. El análisis, diseño, codificación y prueba ocurren justo antes de que sean necesarios. JIT debe usarse también para hacer explícitos los impedimientos en nuestro proceso. Nos alienta a construir cosas en bloques más pequeños. Y brinda una base para crear un feedback rápido con el cliente.
Lean va más allá de Ágil
Al usar principios demostrados en el tiempo, Lean brinda una guía para nuestras prácticas Ágiles cuando ocurren situaciones nuevas. Lean nos dice que nos enfoquemos en el tiempo del desarrollo, no en los recursos utilizados. Lean nos recuerda que debemos optimizar el total en vez de intentar hacer cada paso lo más eficientemente posible.
Lean nos lleva más allá del enfoque a veces miope de Ágil en los proyectos/equipos/software. Debemos prestarle atención a la organización en su totalidad, viendo cómo se seleccionan los productos para mejorar y cómo trabajan los equipos dentro de la estructura organizacional. Ágil no nos ayuda aquí, pero a veces resulta afectado negativamente por la falta de una buena estructura en donde trabaja el equipo.
Resumen de esta guía
Lean nos insita a enfocarnos en mejorar el sistema que usamos para producir software. Esto involucra enfocarse en los procesos que le dan soporte al equipo. Dado que el equipo conoce más que nadie sobre cómo desarrollar software, ellos son quienes necesitan crear y mejorar los procesos.
Lean nos brinda siete principos para el desarrollo de software:
- Respetar a las personas
- Eliminar el despercidio
- Posponer el compromiso
- Crear conocimiento
- Entregar rápidamente
- Construir la calidad desde adentro
- Optimizar el total
Una metáfora esencial es el flujo-rápido-flexible. Es decir, resulta útil pensar en el desarrollo de software como en una línea de producción. Cualquier cosa que causa demoras en la línea genera desperdicios. En el software, los desperdicios incluyen a demoras, errores, malas interpretaciones, y la espera de recursos. Al quitar los impedimientos del flujo mejoramos nuestro proceso.
Entonces, Lean se convierte en una guía para los equipos Ágiles. De hecho, Scrum puede verse como una manifestación de los principios de Lean. Comprender a Lean nos asistirá en la implementación de Scrum. Lean también para aplicarse a través de toda la empresa, logrando así asistir a las implementaciones de Scrum a lo largo de la organización.
Trabajos citados
- Kennedy, Michael. Product development for the Lean enterprise. Oaklea Press, 2003.
- Poppendieck, Mary y Tom Poppendieck. Implementing Lean Software Development: From concepto to cash. Addison-Wesley, 2006.
- Womack, James P, y Daniel T Jones. Lean Thinking: Banish waste and create wealth in your corportaion. Simon & Schuster, 1996.
La guía completa
- Parte 1: los principios Lean
- Parte 2: Lean y Ágil
- Parte 3: Justo A Tiempo y conclusión (este artículo)
