LEAN
El término “Lean” o “Lean Manufacturing” (cuya traducción sería algo así como fabricación esbelta) es otro término que, al igual que el Kanban (te recomiendo este post sobre Kanban), tiene su origen en Toyota. De hecho, “Lean” es sinónimo de Toyota Production System, una estrategia de fabricación aplicada con mucho éxito en Japón y ahora muy famosa en el mundo del software, muchas veces bajo el término de Lean Software Development.
En los 50 la industria japonesa estaba recuperándose de la segunda guerra mundial y logró con gran éxito aplicar a sus fábricas de coches los conceptos de calidad en la producción creados por los principales gurús estadounidenses, de entre los que destaca Deming. La paradoja fue que siendo métodos idealmente originados por estadounidenses… fueron aplicados por los japoneses, convirtiendo a Japón líder en la industria automovilística, pasando por encima de los EEUU.
La idea principal de la filosofía Lean es aplicar un método sistemático consistente en eliminar los desperdicios, o lo que es lo mismo, el trabajo que no aporta valor al resultado final (servicio o producto).
El artífice del Lean, quien introdujo esta nueva manera de fabricar en Toyota, fue Taiichi Ohno (1912 – 1990), cuya estrategia se fundamentó en tres bases:
- Construir sólo lo necesario.
- Eliminar todo aquello que no añade valor.
- Parar si algo no va bien (lo que está relacionado con el principio de cero defectos).
Además, conviene destacar que el Lean incluye siete importantes principios, los siguientes:
Eliminar desperdicios / restos: Por desperdicio o basura consideramos todo aquello que no aporta valor al cliente. En Lean y en su nombre original en japonés se conoce como Muda 無駄.
Dentro del desarrollo de software podríamos incluir los siguientes elementos:
- Código generado que ofrece funcionalidades no deseadas o necesarias.
- Retrasos en el proceso de desarrollo de software.
- Mala toma de requisitos.
- Problemas con la comunicación interna.
- Documentación excesiva o mal procedimentada.
- Amplificar el aprendizaje
Es de vital importancia que todos los miembros del equipo de desarrollo trabajen con una mentalidad de aprendizaje continuo. El hecho de que un desarrollador trabaje con una tecnología o lenguaje concreto (JavaScript, .NET, J2EE, Angular, NodeJS, etc.) no quiere decir que no pueda aprender de otros compañeros o proyectos.
Estamos en una era en la que la tecnología que hoy es noticia en unos días puede haber cambiado radicalmente. Por este motivo los principales implicados tienen que estar al día tanto por su bien como profesionales como por el bien de las empresas de desarrollo de software.
Tomar decisiones lo más tarde posible: Este principio que a priori puede parecer malo desde un punto de vista tradicional (ciclo de vida en cascada) en la filosofía Lean es primordial. Los requisitos de los clientes pueden cambiar de un día para otro, bien por cambios en las necesidades o bien por una mala definición de los mismos.
En un modo tradicional (sin aplicar Lean) el proyecto parte de unos requisitos iniciales que condicionan todo el ciclo de desarrollo de software y cualquier cambio plantea replanificación y adición de Muda al proyecto.
En una filosofía Lean, Agile generalmente, los requisitos suelen ser sustituidos por user stories que están más cerca de la necesidad real. Por este motivo podemos esperar a construir el software hasta que la user story esté definida claramente y sin ambigüedades.
Entregar lo antes posible: En un modelo Lean, las entregas de software son más frecuentes incluyendo features alineadas con las user stories. Por este motivo, cada entrega incluirá funcionalidades que necesitan los usuarios lo antes posible basadas en prioridades, impacto, valor o cualquier otro motivo.
Potenciar el equipo: Facilitar que los desarrolladores participen en la toma de decisiones de tiempos asociados a tareas, priorización de las mismas y demás hacen que los miembros del equipo se sientan parte importante en él.
Además, los propios desarrolladores saben de primera mano qué tareas cuestan más, cuales menos y qué implicaciones tienen el ciclo de vida del proyecto.
Técnicas como el Planning Poker en las que se asignan pesos, esfuerzos o complejidades a las tareas a realizar caen dentro de este principio.
Crear la integridad: Contar con un buen sistema de integración continua que incluya pruebas automatizadas, builds, pruebas de usabilidad son críticas para que un software sea fácil de mantener, de mejorar y de reutilizar. Con esto evitaremos añadir Muda a dicho software e intentar aprovechar lo aprendido de proyectos anteriores.
Visualizar todo el conjunto: La consigna “Pensar en grande, actuar en pequeño, equivocarse rápido y aprender con rapidez” podrían resumir los siete principios Lean para el desarrollo de software.
Analizar las interacciones de nuestro software con el resto de sistemas dentro de la compañía nos permitirán estudiar posibles mejoras y cambios que redunden en una mejor experiencia de usuario y aporten un mayor valor para el cliente y para el equipo del proyecto.
Situación no ideal vs Situación ideal: Además de la Muda, ya mencionada como todo aquello que no aporta valor al cliente, también contamos con otros dos términos, Muri y Mura relacionados con la filosofía Lean.
El primero hace referencia a la sobrecarga de trabajo a alguno de los miembros del equipo y el segundo a errores de balanceo de trabajo en función del proyecto.
Aprendamos un poco más acerca de esta metodología:
