Lean software development

Una de las "metodologías" o interpretaciones del manifiesto ágil, es Lean software development,  no es tan conocida como XP o SCRUM, pero suele integrase con estas dos para complementarla en la vida real. Cuando no encontramos solución a nuestros problemas en XP, SCRUM, etc por ejemplo.

Su origen es fruto del Leam Manufacturing, adaptado del sistema de producción de Toyota, de donde también se ha adoptado Kanban.

Dedicaremos algunos artículos a enumerar y reflexionar sobre los principios de las "metodologías" más conocidas, con el objetivo de ver que nos puede ser más interesante para cada caso concreto.

¿Qué es Lean software development?

Como siempre, repasemos de wiki-definició: Lean sofware development, siguiendo con su versión original, busca eliminar los desperdicios en la producción, originalmente se hablaba de:

• sobreproducción
• tiempo de espera
• transporte
• exceso de procesado
• inventario
• movimiento
• defectos

Principios de Lean

Veamos como trasladamos esto al mundo Software. Los siete principios del Lean Software Development son:

• Eliminar los desperdicios. Es decir todo aquello que no añade valor al cliente debe ser eliminado (funcionalidades innecesarias, burocracia, comunicación interna lenta ...) Si una actividad del proceso de desarrollo puede ser excluida ... es un residuo. Pero también lo es la baja calidad de software, la gestión extra ... Podemos aplicar la técnica stream mapping para identificar el flujo de valor óptimo. Siendo además un proceso iterativo (Parece una métrica candidata a ser incluida en las retrospectivas ¿no creéis? ;D )
  
• Ampliar el aprendizaje. Debemos fomentar el aprendizaje del equipo, dando mayor relevancia a la creación y ejecución de test, que a la elaboración de documentación o planificación. Las iteraciones cortas que permiten interacción con el usuario, la presentación de pantallas al usuario para recibir su feed-back, nos repercuten en un conocimiento que enriquece al equipo (es un punto claramente promovido por user-center design, así que ya es algo que teníamos en cuenta, pero que además vemos una reflexión del beneficio que tiene internamente)
  
• Decidir lo más tarde posible. Ante la incertidumbre se deben tomar decisiones, que en muchos casos son apuestas arriesgadas puesto que no se basan en hechos, si no en estimaciones que nos llevan a pronósticos inciertos. Atrasar todo lo posible estas decisiones nos permitirá reducir la incertidumbre durante la propia vida del proyecto, durante la propia auto-definición del cliente y de sus necesidades.
  
• Reaccionar lo antes posible. Menores iteraciones, más pronto se recibe el feed-back, y se convierte en aprendizaje. Y nos permite ofrecer la posibilidad al cliente de expresar sus nuevas necesidades, así como de reaccionar y reflejar los cambios en el trabajo previsto. Personalmente creo que hay que encontrar un equilibrio las reuniones de definición de Sprint y de retrospectiva no son tan ágiles como podemos creer a priori, y suponen precisamente ese tipo de burocracia a la que hacíamos referencia en el primer punto
  
• Potencial el equipo. Dar espacio a tu equipo para que aporte opiniones, ellos son los que más en contacto están con la tecnología y con el cliente. Además de promover su crecimiento, fomentas su compromiso, implicación y motivación. El gestor en muchas ocasiones debe ser un facilitador del equipo que le rodea y fomentar el espíritu de equipo.
   
• Crear con integridad y calidad interna. Es un concepto complejo que viene a referirse a la integridad conceptual de la solución final, que sea homogénea, y alineada a la necesidad del cliente. Para ello es conveniente una comunicación fluida, por encima de la generación de vasta documentación que permita el aislamiento del equipo. Así como dar espacio a la refactorización, a la filosofía del cambio en relación a la incorporación de mejoras.
  
• Visión de conjunto / Mejora el proceso. "Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez" es una de las frases que encontramos en la definición de éste punto. Alienar a todos los players involucrados en el proyecto en esta filosofía es clave para el éxito del mismo. Vamos, que no pensemos en utilizarlo como excusa

¿Qué nos aporta Lean como valor añadido respecto al resto?


Algunas organizaciones ven claramente las ventajas de las metodologías ágiles, y intentar cambiar sus organizaciones basadas en metodologías estrictas, como pueden ser CMMI, METRICA, ESPRIT, etc ... a metodologías ágiles.


Pero hay que ir con cariño, y por eso dedicaré un algún que otro artículo al caso concreto de las grandes organizaciones. Tenemos que tener clara la diferencia entre normas a seguir, doctrina ... a unas guías o recomendaciones.


Las metodologías ágiles son guías, y en ningún caso son validas para todas las situaciones, para todas las circunstancias, y todos los contextos. Simplemente aplicando sobre nuestra implementación ágil el primer principio Lean, ya nos puede aportar un valor diferencial. En cada retrospectiva deberíamos analizar cuales de las actividades NO aportan valor y considerar su supresión.


Creo personalmente que el resto de principios pueden ser inherentes en equipos ágiles, aunque la reflexión sobre potencial al equipo, especialmente a algún que otro HiPPo ...


;-)
  

Referencias

• Lean Institute 
• ProyectoAgiles.org - Principios de Lean Software Development

Saludos,