Lean

Lean manufacturing o Lean production, conocido normalmente como Lean, es una es una filosofía de gestión cuyo origen principal es el TPS (Toyota Production System), y que considera como desperdicio cualquier gasto de recursos que no esté orientado a la creación de valor para el cliente. Lo que intenta es crear un mayor valor con el menor gasto.

Lean intenta optimizar el flujo del proceso de producción, tratando de incrementar la eficiencia, reducir el gasto, y usar métodos empíricos para decidir qué es lo verdaderamente importante.

La metodología de desarrollo de software Lean es una translación de los principios y prácticas de la manufacturación Lean hacia el dominio del desarrollo del software. El desarrollo de software Lean tiene origen en el un libro del mismo nombre, escrito por Mary y Tom Poppendieck.

El desarrollo Lean se resume en los siguientes siete principios:

• Eliminar los residuos.
• Fomentar el aprendizaje.
• Retrasar las decisiones.
• Reaccionar rápidamente.
• Potenciar el equipo.
• Fomentar la integridad.
• Ver todo el conjunto.

A continuación, pasamos a explicar cada uno de estos principios.

Eliminar los residuos

En Lean, todo lo que no añade valor al cliente se considera un residuo. Hay que ser capaz de reconocer las actividades que son residuos. Si el resultado esperado se puede alcanzar sin realizar alguna actividad, esta actividad es un residuo:

• La codificación parcial eventualmente abandonada durante el proceso de desarrollo es un residuo.
• Los procesos extra y funcionalidades que no utilizan con frecuencia por los clientes son residuos.
• Las esperas ocasionadas por otras actividades, equipos o procesos son residuo.
• Defectos y menor calidad son los residuos.
• Gastos generales de gestión que no producen valor real son residuos.

A continuación se deben señalar las fuentes de los residuos y eliminarlos. Y todo ello debe hacerse de forma iterativa.

Fomentar el aprendizaje

El desarrollo de software es un proceso de aprendizaje continuo. La forma más eficaz para mejorar un entorno de desarrollo de software es el aprendizaje:

• La acumulación de defectos debe evitarse ejecutando las pruebas tan pronto como el código está escrito.
• En lugar de añadir más documentación o planificación detallada, las distintas ideas podrían ser juzgados escribiendo código y construyendo.
• El proceso de recopilación de requisitos de usuarios podría simplificarse mediante la presentación de las pantallas de los usuarios finales y para que estos puedan hacer sus aportes.

El proceso de aprendizaje es acelerado por el uso de ciclos de iteración cortos que incrementan el feedback de los clientes, ayuda a determinar la fase actual de desarrollo y ajusta los esfuerzos para introducir mejoras en el futuro.

Durante estos ciclos, tanto los clientes como el equipo de desarrollo aprenden sobre el dominio del problema y buscar posibles soluciones para un mejor desarrollo. De esta forma los clientes comprenden mejor sus necesidades y los desarrolladores aprenden a satisfacerlas mejor.

Retrasar las decisiones

El desarrollo de software está siempre asociado con cierto grado de incertidumbre. Los mejores resultados se alcanzan cuando se puede decidir entre varias opciones basándose en hechos y no en suposiciones y pronósticos inciertos.

Cuanto más complejo es un proyecto, más capacidad para el cambio debe incluirse en este, así que debe permitirse el retraso en las decisiones importantes. Este enfoque de desarrollo puede llevar a opciones antes a los clientes. Por lo tanto, es conveniente retrasar algunas decisiones cruciales hasta que los clientes se hayan reconocido mejor sus necesidades. También permite la adaptación tardía a los cambios y previene de las costosas decisiones delimitadas por la tecnología.

Esto no significa que no haya un planificación del proceso. Por el contrario, las actividades de planificación se centran en las diferentes opciones y se las adapta a la situación actual. Esto permite clarificar las situaciones confusas y establecer las pautas para una acción rápida.

Reaccionar rápidamente

En el mercado actual, cuanto antes se entrega el producto final sin defectos considerables, más pronto se pueden recibir comentarios, que pueden ser incorporados en la siguiente iteración. Cuanto más cortas sean las iteraciones, mejor es el aprendizaje y la comunicación dentro del equipo.

La velocidad asegura el cumplimiento de las necesidades actuales del cliente y les da la oportunidad de demorarse pensando lo que realmente necesitan, hasta que adquieran un mejor conocimiento.

La ideología de producción Just In Time se aplica a programas de desarrollo. El equipo se organiza y se divide las tareas para lograr el resultado necesario para una iteración específica. El cliente dispone los requisitos necesarios en pequeñas historias y los desarrolladores estimarán el tiempo necesario para el desarrollo de cada una de ellas. Cada mañana, cada miembro del equipo evalúa lo que se ha hecho ayer, y lo que hay que hacer hoy y mañana, y pregunta por cualquier nueva entrada necesaria de parte de sus colegas o del cliente.

Otra idea clave se establece a base de diseño. Si un nuevo sistema es necesario, tres equipos pueden diseñar soluciones al mismo problema. Cada equipo aprende sobre el problema y diseña una posible solución. Cuando una solución se considera irrazonable, se desecha. Al final de un periodo, los diseños sobrevivientes se comparan y se elige uno, quizá con algunas modificaciones basadas en el aprendizaje de los demás. Mediante esta práctica se minimiza el riesgo provocado por un solo gran diseño realizado por adelantado.

Potenciar el equipo

Hasta el momento los administradores dicen a los trabajadores cómo hacer su trabajo. Ahora, los roles cambian, los trabajadores son los que dicen qué acciones podrían tomarse y sugieren mejoras. Los directores de proyecto más experimentados dicen que la clave de éxito de los proyectos es: "Buscar la buena gente y dejarles hacer su propio trabajo".

Otra creencia errónea ha sido considerar a las personas como recursos. En el desarrollo de software, las personas necesitan motivación y un objetivo hacia el cual trabajar, con la garantía de que el equipo puede elegir sus propios compromisos. Los desarrolladores deberían tener acceso a los clientes, el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difíciles, y asegurarse de mantener el espíritu de equipo.

Fomentar la integridad

La integridad consiste en que los componentes separados del sistema función bien tanto juntos como en un todo.

Una de las maneras más saludables hacia una arquitectura que mantinen la integridad es la refactorización, que consiste en mantener la sencillez, la claridad, la cantidad mínima de funcionalidades en el código. Las repeticiones en el código son signo un mal diseños de código y deben evitarse. El completo y automatizado proceso de construcción debe ir acompañada de una suite completa y automatizada de pruebas, tanto para desarrolladores y clientes, que tengan la misma versión, sincronización y semántica que el sistema actual.

Al final, la integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el cliente espera haga.

Ver todo el conjunto

Los sistemas de software hoy en día no son simplemente la suma de sus partes, sino también el producto de sus interacciones. Cuanto mayor sea el sistema, más serán las organizaciones que participan en su desarrollo y más partes son las desarrolladas por diferentes equipos; mayor es la importancia de tener bien definidas las relaciones entre los diferentes proveedores, con el fin de producir una buena interacción entre los componentes del sistema.


Para terminar, simplemente quiero recalcar que Lean define los principios a aplicar en un desarrollo de software, pero no la forma concreta de aplicarlos.

Referencias:
Desarrollo software Lean
Lean Manufacturing
Lean software development