Realmente los términos «Lean» y «JIT» (just in time) no fueron popularizados por los Japoneses, fueron popularizados por los estadounidenses, concretamente por el “best-seller” del MIT “La máquina que cambió el mundo” (1990).
Fueron los autores de aquel libro los que usaron el término «lean» para describir cualquier práctica eficiente de gestión que minimice el desperdicio (waste), lo que incluía a las técnicas de desarrollo de productos japonesas, con las que los fabricantes de automóviles japoneses habían logrado recortar mucho los tiempos (alrededor de un tercio) y las horas de ingeniería (aproximadamente a la mitad) en comparación Estados Unidos y Europa, hasta tal punto fue el paralelismo que hoy lean es sinónimo del método de fabricación de Toyota.
En el mundo del software, fue el libro “Microsoft Secrets” el que primero habló de la similitud de la estrategia de “daily builds” que usaba Microsoft (similar a la integración continua pero planificada, en la que diariamente se compila el software y se pasan algunas pruebas unitarias automatizadas, o el “smoke test”, te recomiendo aquí este post sobre el tema), donde los ingenieros software tenían que parar y corregir errores diariamente y la filosofía de producción de Toyota – JIT, donde los trabajadores paraban las líneas de montaje cuando detectaban problemas, solucionándolos inmediatamente.
El libro “Microsoft Secrets” no utilizó el término «lean», ni lean software development, aunque hablaba de la aplicación de JIT, del control de calidad, y la reducción de la burocracia en Microsoft.
Hay claramente muchos elementos comunes entre estilo el de producción de Toyota, el estilo iterativo de Microsoft y el desarrollo ágil (teniendo en cuenta que en Microsoft no siempre se desarrolló así, a finales de 1990 y principios de 2000 trabajaban con equipos de desarrollo exageradamente grandes). La popularización del término «lean” aplicado al software, el lean software development, y su asociación a lo «ágil» aparece principalmente con el libro “Lean Software Development” de Mary y Tom Poppendieck.
Estos también hacen hincapié en la eliminación de desperdicios, eliminar la burocracia en el desarrollo de productos, fomentarse el aprendizaje por ciclos cortos y frecuentes, iteraciones rápidas, etc., obteniendo una rápida retroalimentación que “tire” (pull) del producto, en lugar de documentos de requisitos y planes rígidos que “empujen” (push) el trabajo de desarrollo. Y la diferencia entre métodos antiguos y más basados en mano de obra, burocráticos, “pushstyle”, inicialmente asociados con el negocio de las computadoras mainframe.
En el libro, “Lean Software Development” Mary y Tom también destacan los siete principios del Lean desarrollo de software (que más tarde modificaron):
- Optimizar el todo,
- Eliminar desperdicios,
- Calidad en la construcción,
- Aprender constantemente,
- Entregar rápido,
- Involucrar a todo el mundo
- Seguir mejorando
El lean, y el lean software development, no es una metodología de ingeniería de software en el sentido convencional. Es más una síntesis de principios y una la filosofía para construir sistemas de software. Si lean se considera un conjunto de principios más que prácticas, la aplicación de conceptos lean al desarrollo software y la ingeniería software tiene más sentido y puede ayudar a mejorar la calidad.
Referencias y para leer más sobre Lean Software Development
La mayoría de la información, e inspiración para este post, viene de este artículo de IEEE software escrito por Mary Poppendieck y Michael A. Cusumano.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com