Metodologías de desarrollo de software: Principios Lean vs Agile

«Lean» y «Agile» son términos que se han lanzado mucho últimamente, a menudo en referencia a metodologías de desarrollo de software, gestión de proyectos o estilos organizativos.

Pero alguna vez te has encontrado con la pregunta:

¿Qué es Lean? ¿Qué es Agile? ¿Existe alguna diferencia?

El diccionario Merriam-Webster define Ágil como «que tiene un carácter rápido, ingenioso y adaptable, o que se caracteriza por la capacidad de moverse con facilidad y rapidez»

Lean se define simplemente como «delgado y saludable, o que contiene poca o ninguna grasa»

En base a estas definiciones, podemos asumir que alguien que es lean y alguien que es ágil podrían tener muchas características compartidas. Lo mismo ocurre en el contexto del desarrollo de software.

¿Qué es Agile? ¿Qué es Lean?

Agile es ahora ampliamente conocido en el mundo de la tecnología como un conjunto de valores y principios para guiar el desarrollo de software. El «Manifiesto Ágil» establece un conjunto de cuatro valores y 12 principios. Destilado en su esencia, Agile es exactamente lo que crees que puede ser. Es ágil. La metodología favorece la flexibilidad, la comunicación, la colaboración y la simplicidad.

Lean se entiende menos y carece de una definición clara apoyada por un consenso profesional.El término «Lean» se acuñó originalmente para describir un modelo de organización de la fabricación basado en el Sistema de Producción Toyota, pero se considera comúnmente un sub-marco dentro del paraguas ágil de desarrollo de software.

Hoy en día, hay mucha confusión sobre lo que es Lean, lo que es Agile, si son uno y lo mismo, y cuál se debe utilizar.

El nacimiento de las nuevas metodologías de desarrollo de software

Tanto Lean como Agile se desarrollaron en respuesta a las deficiencias de los métodos existentes basados en planes como Waterfall. Utilizados desde los años 70, los desarrolladores y los directores de ingeniería de software empezaron a notar las ineficiencias de Waterfall en los años 90. Con mercados más dinámicos y consumidores conocedores de la tecnología, Waterfall era incapaz de responder con la suficiente rapidez a las demandas del mercado, a los cambios tecnológicos o a la entrega de software libre de errores de forma consistente.

En busca de un modelo mejor, los creadores de Lean y Agile buscaron desarrollar metodologías con un enfoque más centrado en el cliente. Las nuevas metodologías adoptaron la capacidad de adaptación como una ventaja competitiva, favorecieron las pruebas tempranas y continuas, y aportaron un elemento humano a la gestión y ejecución del proyecto.

Principios Lean vs. Agile

El Desarrollo de Software Lean (LSD) fue propuesto por primera vez por el Dr. Robert Charette como una forma de construir organizaciones tolerantes al cambio que se estaban volviendo cada vez más dependientes del software.

Luego vino «El Manifiesto Ágil» que consagró los 12 principios del Desarrollo de Software Ágil.

La otra obra autorizada sobre las metodologías de desarrollo de software se atribuye a Mary y Tom Poppendieck, que publicaron Lean Software Development: An Agile Toolkit.

Aquí hay una comparación lado a lado de los valores y principios de cada uno:

Comparando los 12 principios del LSD del Dr. Charette y los 12 principios de Agile, se puede ver que son sorprendentemente similares. Los siete principios Lean propuestos por los Poppendieck están menos orientados, pero sin embargo se solapan con «The Agile Manifesto» y el Lean Software Development de Charette.

Aquí hay más elementos que tienen en común:

• El valor de responder a las necesidades del cliente con rapidez
• Pruebas tempranas
• Un enfoque iterativo del desarrollo
• El estilo de desarrollo MVP (Producto Mínimo Viable) por encima del feature heavy
• Cooperación tanto dentro de la empresa como con las partes interesadas externas

Línea de tiempo

Hemos investigado los eventos y publicaciones que marcaron el nacimiento de estas terminologías para ver cómo se popularizaron. Echa un vistazo a nuestra línea de tiempo que detalla la progresión, y añádelas a tu lista de lecturas si te apetece!

Orígenes de Lean y Agile

Como puedes ver en la línea de tiempo, el término Lean fue utilizado por primera vez por Womack et. al. en 1990 para describir el Sistema de Producción Toyota en su libro, The Machine That Changed The World. Posteriormente, el Dr. Robert Charette adaptó las ideas de Lean descritas en publicaciones anteriores para crear su «Lean Software Development».

El término Agile no fue ampliamente adoptado hasta la publicación de «The Agile Manifesto» en 2001. Los términos Agile y Lean fueron acuñados por profesionales de la tecnología o académicos occidentales que hacían referencia al Sistema de Producción Toyota (más sobre esto más adelante).

Podríamos recibir algunas críticas por decirlo, pero teniendo esto en cuenta, los términos Lean y Agile no son realmente tan importantes. Tener dos términos derivados de los mismos principios en realidad contribuye a la confusión sobre el tema. Dicho esto, esta es la terminología que la industria ha adoptado, así que en adelante seguiremos utilizándolos.

La línea de tiempo es también otra fuente de confusión. El Dr. Robert Charette introdujo sus ideas sobre Lean Software Development a principios y mediados de los años 90. El propósito táctico y los 12 principios de su enfoque de Lean Development se describieron en 1998 en un artículo titulado «Lean Development», casi tres años antes de «The Agile Manifesto». Como testimonio del solapamiento entre Lean y Agile, este artículo fue escrito por Jim Highsmith, que posteriormente se convirtió en uno de los principales fundadores del movimiento Agile. Sin embargo, el artículo de Highsmith no tuvo mucha difusión y no fue hasta 2003 cuando el propio Charette escribió una explicación más profunda de su enfoque de desarrollo lean en el informe de investigación «Challenging the Fundamental Notions of Software Development» (Desafiando las nociones fundamentales del desarrollo de software).

En un intercambio de correos electrónicos con el Dr. Charette, se apresuró a señalar que su concepción del desarrollo ajustado estaba pensada para el nivel organizativo dentro del campo del software:

La mía surgió de una necesidad tanto estratégica como operativa de mejorar el valor del negocio/misión de la TI para la organización, y la enfoqué desde una perspectiva de gestión del riesgo.
-Dr. Robert N. Charette

Esto difiere ligeramente de Agile, que se propuso por primera vez estrictamente como una «mejor manera de desarrollar software», pero ahora se aplica a varios proyectos y métodos de gestión.

2003 fue también el año en que los Poppendieck publicaron Lean Software Development: An Agile Toolkit. Este libro detallaba siete principios de desarrollo Lean, que se correlacionan directamente con las siete formas de despilfarro de Lean Manufacturing.

El libro de los Poppendieck reforzaba simultáneamente Lean como metodología de desarrollo de software y difuminaba la distinción entre Lean y Agile, al proponer Lean como método complementario dentro de Agile. De hecho, en el momento de su publicación, el libro se vendió como la última publicación dentro de The Agile Software Development Series.

Hoy en día, los múltiples trabajos de los Poppendieck sobre el tema se consideran una lectura esencial para los profesionales del desarrollo de software Lean, y «aspirantes a Lean».

Divergencia en la aplicación

Según el Dr. Charette, una de las principales diferencias entre Lean y Agile es que Agile es ascendente, mientras que Lean es descendente. Esto es evidente en la estructura de extremo a extremo (E2E) de Lean y en el principio de Ver el Todo propuesto por los Poppendieck. A continuación explicamos estos principios en la práctica del mapeo del flujo de valor.

Mapeo del flujo de valor

Para realizar el principio de Ver el Todo, los Poppendieck detallan un método de mapeo del flujo de valor para revelar las actividades de valor añadido frente a las actividades sin valor añadido a lo largo del proceso de desarrollo de extremo a extremo.

El mapeo del flujo de valor analiza el ciclo de desarrollo desde el momento en que se recibe un requisito hasta el momento en que se entrega al cliente. El objetivo es identificar los despilfarros de inventarios y esperas (retrasos en la producción), y explorar nuevas prácticas para reducir el trabajo en curso (WIP) y el tiempo de entrega.

Según los Poppendieck, el mapeo de su flujo de valor es un ejercicio sencillo que sólo requiere un lápiz y un papel. El proceso es el siguiente:

1. Mapear su flujo de valor actual (comenzando con un requisito y una línea de tiempo de las acciones en el viaje a la entrega)
2. Analizar la mayor causa de desperdicio (¿Qué está retrasando el trabajo en curso?)
3. Desarrollar un plan para reducir este desperdicio a la mitad
4. Crear un mapa de flujo de valor futuro

El paradigma ágil, tal y como se establece en «El Manifiesto Ágil», favorece los ciclos de iteración cortos y las entregas frecuentes por encima de una visión holística de principio a fin. El enfoque E2E es, por tanto, exclusivo de Lean. De hecho, es debido a la construcción E2E que Lean (en lugar de Agile) se aplica más a menudo como una estructura organizativa y estilo de gestión.

La visión de extremo a extremo requiere que toda la organización participe para eliminar los residuos. Esto se hace eco del propósito declarado por el Dr. Charette para su concepto original de Lean Development:

Lean Development es una filosofía, una forma de ver y pensar en las TI y su relación con una organización, tanto como un enfoque de desarrollo.

Lean Kanban Vs. Agile Kanban

Tanto Lean como Agile han adoptado el sistema TPS Kanban con ligeras variaciones. El sistema Kanban de Toyota fue diseñado para limitar el Trabajo-en-Progreso.

A diferencia de la «fabricación de empuje» tradicional, que empuja el inventario al siguiente paso en el proceso, Kanban sólo tira de nuevo material a la producción una vez que la pieza actual ha sido procesada y los componentes necesitan ser repuestos.

Las tarjetas Kanban se convierten en órdenes de reabastecimiento y se envían de vuelta al paso anterior en la producción. Como resultado, se minimiza el trabajo en curso y se reduce el inventario ocioso.

En el desarrollo de software, en lugar de pasar las tarjetas Kanban de un paso de fabricación de vuelta al anterior, se utiliza un tablero Kanban. Se utilizan notas adhesivas, la mayoría de las veces para representar los requisitos en curso.



Según el capítulo aportado por Kai Petersen en Modern Software Engineering Concepts and Practices: Enfoques Avanzados, tanto Agile como Lean utilizan una lista priorizada de requisitos de la que extraer tareas.

A diferencia de Agile, que utiliza ciclos de iteración de duración fija para limitar el tiempo de desarrollo y gobernar el tablero Kanban, Lean limita el número de tareas permitidas en un momento dado. Esto permite a Lean cumplir con su objetivo principal de limitar el WIP, a la vez que medir con mayor precisión el tiempo de entrega, e identificar el desperdicio en la producción. Una vez que se ha completado una tarea, se puede extraer una nueva de la lista priorizada. Mientras que Lean utiliza el concepto de flujo continuo, Agile comienza cada nueva iteración con un tablero fresco.

Algunos equipos reconocen los beneficios de ambos enfoques, y están empezando a utilizar un método híbrido conocido como scrumban.

Estas son sólo dos de las sutiles diferencias de enfoque que Lean y Agile adoptan para lograr objetivos comunes. Otro artículo publicado en Codementor explora más usos y aplicaciones de Lean y Agile.

En la práctica, que tu equipo adopte un enfoque llamado «Agile» o un enfoque «Lean» no es importante. Lo importante es encontrar las prácticas correctas para optimizar tus flujos de trabajo y entregar constantemente valor a tus clientes, lo que ambas metodologías ven como el propósito final.

La conexión TPS

Entonces, ¿qué tiene que ver todo esto con el Sistema de Producción Toyota? Prácticamente todo. Los creadores tanto de Agile como de Lean estuvieron fuertemente influenciados por el TPS, como describen Womack et. al. en La máquina que cambió el mundo. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. La empresa no podía esperar seguir el modelo de producción en masa de Detroit y sobrevivir.

En estas condiciones, Taiichi Ohno y Kiichiro Toyoda se propusieron seguir siendo rentables eliminando el despilfarro en la producción, reduciendo el tiempo de entrega y produciendo sólo lo que los clientes necesitaban, lo que también se conoce como fabricación justo a tiempo (JIT).

Para eliminar el despilfarro, Ohno resolvió fabricar sólo lo que se necesitaba, cuando se necesitaba y sólo en la cantidad que se necesitaba.

El proceso iterativo de Lean y Agile que se centra en minimizar el desarrollo de características, y maximizar la entrega de actualizaciones refleja directamente la fabricación Just-in-Time de Toyota.

Jidoka

Jidoka (自働化) puede traducirse como automatización con un toque humano, a veces referido como «automatización inteligente.» Jidoka desempeña un papel importante en la eliminación de los residuos en la producción haciendo que las máquinas sean más independientes, lo que libera a las personas para que desempeñen un papel más activo en la producción y libera la creatividad humana.

Jidoka se basa en máquinas inteligentes que se detienen automáticamente cuando hay una irregularidad. Los trabajadores humanos pueden entonces ir a solucionar el problema, impidiendo que los defectos se transmitan al proceso de producción.

Jidoka también faculta a cada empleado para detener la línea de producción cuando se detecta un problema. El principio incluye un proceso de cuatro pasos para eliminar el desperdicio de productos defectuosos:

1. Detectar la anormalidad
2. Parar la producción
3. Arreglar o corregir la condición inmediata
4. Investigar la causa raíz y remediar la situación

Puedes ver el concepto Jidoka en el enfoque Lean y Agile en las pruebas tempranas y frecuentes para erradicar los errores, y el énfasis en la consulta a los clientes para identificar los dolores de los usuarios.

Desperdicios de TPS en un contexto de desarrollo de software

Para lograr la fabricación JIT, Taiichi Ohno esbozó siete formas de desperdicio que debían eliminarse. La número ocho se añadió posteriormente. Si se echa un vistazo más de cerca a los valores, objetivos y principios de Agile y Lean, se puede ver que están diseñados para protegerse de los ocho desperdicios de TPS. En su libro de 2003 Lean Software Development: An Agile Toolkit, los Poppendieck presentaron los desperdicios TPS en un contexto de desarrollo de software.

1. El desperdicio de la sobreproducción. El desperdicio de la sobreproducción es una de las mayores razones por las que se ha abandonado el método Waterfall. La sobreproducción se considera codificación extra para características que no fueron solicitadas y que el cliente puede no querer.

Esto se refleja en los siguientes principios:

Agile ⟶ simplicidad
Charette’s Lean⟶ minimalismo
Poppendiecks’s Lean ⟶ eliminar el desperdicio

2. El despilfarro de la espera. En la fabricación JIT, esperar a una máquina o a un trabajador inactivo es un despilfarro. En el desarrollo de software, el despilfarro es esperar a un equipo con exceso de capacidad. Si hay retrasos en la producción que hacen que un equipo esté en espera, o hacen que el cliente espere la entrega, hay desperdicio.

Los principios que coinciden son los siguientes:

Agile ⟶ ciclos frecuentes
Charette’s Lean ⟶ ⅓ del tiempo (objetivo de LSD), 80% de solución hoy
Poppendieck’s Lean⟶ entregar lo más rápido posible

3. El desperdicio del transporte. En el desarrollo de software, el transporte se traduce como «cambio de tareas». Demasiados traspasos o empleados asignados a múltiples equipos con una demanda de multitarea excesiva es ineficiente y un desperdicio.

Principios coincidentes:

Agile ⟶ colaboración de las partes interesadas, equipos auto-organizados, cultura de
confianza, apoyo y motivación
Charette’s Lean ⟶ esfuerzo en equipo
Poppendiecks’s Lean ⟶ empoderar al equipo

4. El Desperdicio del Sobreprocesamiento. Esto es simplemente procesos extra que no son realmente necesarios para entregar valor al cliente. El ejemplo principal es la documentación. La documentación excesiva para procesos inflexibles no será valiosa, como tampoco lo son los manuales de usuario demasiado detallados que podrían resumirse en una o dos páginas. La documentación consume mucho tiempo y, sin embargo, ofrece un valor limitado al usuario final.

Principios de concordancia:

Agile ⟶ simplicidad, software de trabajo como medida
Charette’s Lean ⟶ minimalismo
Poppendiecks’s Lean ⟶ eliminar residuos

5. El despilfarro del inventario. El despilfarro de inventario es el Trabajo en curso para el que se ha realizado una inversión, pero que no tiene valor hasta su finalización. En otras palabras, el software incompleto no proporciona ningún valor al usuario. Lean y Agile valoran las entregas rápidas y frecuentes, con énfasis en los ciclos iterativos frecuentes y la entrega de software que funcione.

Principios coincidentes:

Agile ⟶ satisfacción del cliente (a través de la entrega temprana y frecuente al cliente
)
Charette’s Lean ⟶ 80% de solución hoy
Poppendieck’s Lean ⟶ entregar tan rápido como sea posible

6. El desperdicio de movimiento. El desperdicio de movimiento es el exceso de esfuerzo requerido para obtener información o responder preguntas. Esto es común cuando los equipos no están co-localizados, si las tareas se completan y los resultados no están disponibles inmediatamente para todas las partes relevantes, o cuando las partes interesadas no están fácilmente disponibles para consultar.

Principios de coincidencia:

Agile ⟶ colaboración de las partes interesadas, comunicación cara a cara
Charette’s Lean ⟶ participación del cliente, esfuerzo del equipo
Poppendiecks’s Lean ⟶ eliminar el desperdicio

7. El desperdicio de los defectos. Al igual que en la fabricación, producir software defectuoso o con errores representa una inversión desperdiciada por la empresa. Cuanto más rápido se detecte un defecto, más probable es que se mitigue el desperdicio. Muchos principios de Agile y Lean buscan detener el desperdicio de defectos. Para reducir los defectos, las tres metodologías dan prioridad a las pruebas tempranas y frecuentes.

Principios coincidentes:

Agile ⟶ excelencia técnica, software de trabajo como medida
Charette’s Lean ⟶ satisfacción del cliente
Poppendiecks’s Lean⟶ amplificar el aprendizaje

8. El despilfarro de la creatividad no utilizada de los empleados. En el desarrollo de software, la creatividad no utilizada es el resultado de una hoja de ruta rígida y de la falta de colaboración humana. Al igual que Jidoka (自働化), Agile y Lean buscan maximizar la cooperación humana y la innovación para obtener los mejores resultados de la tecnología.

Principios coincidentes:

Agile ⟶ colaboración de las partes interesadas, reflexión del equipo
Charette’s Lean ⟶ principio 13 «no escrito» de satisfacción a través del
trabajo
Poppendiecks’s Lean ⟶ amplificar el aprendizaje

Valores TPS en la metodología de desarrollo de software

Muchos de los valores fundamentales que conforman TPS también se reflejan en las metodologías de desarrollo de software Agile y Lean.

Kaizen (改善) se traduce como mejora continua. Con modelos flexibles, iterativos y centrados en el cliente, la mejora continua es quizás el valor más importante de las metodologías de desarrollo de software Agile y Lean.

Hansei (反省) significa autorreflexión. Como medio para mejorar la eficiencia, el Manifiesto Ágil adopta directamente la autorreflexión del equipo como su 12º principio. Al introducir su modelo de Desarrollo Lean, el Dr. Charette desafía a los lectores a reflexionar sobre todos los supuestos actuales que dictan los procesos que utilizan como paso inicial para encontrar otros mejores. El principio de amplificación del aprendizaje de los Poppendieck también puede considerarse Hansei.

El respeto por las personas (尊重) es fundamental en los tres paradigmas. El primer valor del «Manifiesto Ágil» es «valorar a los individuos y las interacciones por encima de los procesos y las herramientas»

El respeto por las personas también aparece en la afirmación del Dr. Charette sobre la importancia de que los individuos experimenten satisfacción a través del trabajo, y en el principio Lean de los Poppendieck sobre el empoderamiento de los equipos. Este valor reconoce que cuando los individuos participan en la toma de decisiones y en la mejora de su entorno de trabajo, son trabajadores más innovadores y eficientes.

Seiri (整理) es el principio que refleja el despilfarro. Seiri dicta que lo que es innecesario debe ser eliminado. Esto abarca todos los siete desperdicios originales de TPS, para los que ya hemos identificado los desperdicios paralelos en el entorno de desarrollo de software.

Gengchi Genbutsu (現地現物) se traduce literalmente como «lugar real, cosa real». En la práctica, significa «inspeccionar para entender». Cuando hay un problema en el proceso de producción, el gestor debe ir al origen para entender el problema y determinar cómo solucionarlo.

En el desarrollo de software, este valor se manifiesta en el énfasis en los ciclos de iteración cortos, las pruebas tempranas y la colaboración con el cliente para que los ingenieros de software puedan construir un software que funcione y que los usuarios realmente quieran.

Conclusión

Como mencionamos en los párrafos iniciales de este post, la metodología Lean es menos conocida y a menudo se considera una práctica ágil. Lean está quizás menos definido simplemente por sus aplicaciones más amplias.

Lean tiene una relación más directa con el Sistema de Producción Toyota y se propuso por primera vez como un conjunto organizativo de métodos y prácticas para la gestión empresarial, y sólo posteriormente se aplicó al desarrollo de software. Agile, por otro lado, fue desarrollado específicamente para el desarrollo de software por profesionales dedicados a este campo.

Después de detallar los antecedentes compartidos y los principios generales de estas dos metodologías, se puede ver que estos dos paradigmas tienen más en común que diferencias.

Uno de los principales autores de «The Agile Manifesto», Martin Fowler, que también ha trabajado estrechamente con los Poppendieck, ha señalado que Lean y Agile no son mutuamente excluyentes:

Lean y Agile están profundamente entrelazados en el mundo del software. Realmente no se puede hablar de que sean alternativos….no se hace Agile o Lean, se hace Agile y Lean.

1. Los 12 principios del Lean Software Development de Charette fueron en realidad descritos por primera vez en el artículo de Jim Highsmith «Lean Development» en 1998. Posteriormente se elaboraron en el artículo del propio Dr.Charette «Challenging the Fundamental Notions of Software Development» ︎

.