Para los desarrolladores y líderes que están llegando a las metodologías ágiles a través de Scrum o XP, todo este asunto alrededor de Lean puede ser un poco misterioso. Aquí está una introducción a Pensamiento Lean y la forma en que se aplica al desarrollo de software, el editor de InfoQ Ágil China, Jacky Li. Ning Lu, de ThoughtWorks china, cuya conversación se resume aquí, hizo hincapié en el mayor obstáculo para Lean en ágil, como: el perjuicio que se formó durante la producción a gran escala.
A principios de este año, InfoQ China promovió una Open Party, en conjunto con la matriz, ThoughtWorks da China, Java User Group da Beijing, Google Group AgileChina e Python User Group de Beijing, etc. La Open Party, que se celebró siguiendo el molde de las conferencias OpenSpace, ocurrido en las oficinas de ThoughWorks China, y contó con alrededor de 30 congresistas. Lu Ning, un consultor de ThoughtWorks, dio un buen discurso: Pensamiento Lean con ejemplos. Analizó, el mayor obstáculo en la adopción Lean en ágil, y explicó cómo reconocer y reducir los desperdicios. En este artículo se resume el discurso desde la perspectiva de un desarrollador ágil.
La actividad comenzó con una simple reunión diaria, seguida de una votación sobre todos los temas - hemos tenido una serie de interesantes temas en ese día, incluyendo "El crecimiento de la comunidad del software libre", "GPE", "Mingle", "Earlang", etc. Los temas fueron divididos en 3 lugares, y Lu Ning dio su conferencia en uno. Comenzó con el Sistema de producción de Toyota y manufactura Lean, despues abordó el mayor obstáculo en la adopción de Lean en ágil: el perjuicio que se formó durante la producción a gran escala. Asimismo, Ning Lu habló acerca de como Toyota exploró su propio sistema de producción. Él comentó:
Lean es la tecnología que puede reconocer y eliminar los desperdicios - las actividades que no producen valor adicional.
Explicó cómo reconocer y eliminar los desperdicios con los 5 principios Lean con ejemplos, y enumeró varios fenómenos típicos que generalmente acompañan a este tipo de desperdicios:
- Existencias (Stock) -, mientras que el control de inventario puede evitar lo provisión ineficiente, esto también aumenta el costo, y torna a la empresa insensible al mercado. La empresa puede enfrentarse a la sobrecarga de inventario cuando los requisitos del mercado cambian. El stock está en todas partes. Piense en sus estanterías, refrigeradores y el trabajo que termina sin ningún resultado.
- Lotes de procesos y espera en las filas -, así como las intersecciones que están siempre congestionadas, donde la mayoría de los conductores tienen que pasar por la experiencia de "esperar".
- Desequilibrio - por ejemplo, las ventas de temporada y los períodos de debilidad de ventas.
- Complicaciones - si las cosas son mucho más complicadas de lo que usted esperaba, entonces debe haber algún desperdicio. Por ejemplo: un documento o proceso complicado.
- Enfoque en "seguir los reglamentos" - no todas las normas y reglamentos son razonables y, por otra parte, no deben ser valiosos para los clientes.
Ning Lu hizo hincapié en que:
Cualquier trabajo no finalizado es un tipo de desperdicio. Lean en Ágil puede reducir al mínimo el trabajo no terminado.
Wow, esto da a entender que todo el código que se está haciendo es también un desperdicio. Esto es una locura! Si seguimos las palabras de arriba y tratamos de minimizar los desperdicios, entonces tenemos las impresión que nosotros debemos parar de codificar! ¿Cómo podemos entregar algo al cliente entonces? ¿Y de dónde es que viene el valor?
OK, vamos a tratar de analizar esto de manera diferente. Tal vez usted pueda reconocer estas palabras de "Preconstrucción":
Usted puede predecir todo? No. Las decisiones que usted tome hoy son las finales? No. Es prácticamente imposible pensar en todo y saber todo en el comienzo de un proyecto.
De hecho, ni el cliente tendrá certeza de que la función es exactamente lo que necesita antes de que pueda ser demostrado el valor a él. Si nosotros tomamos el trabajo no terminado como una forma de desperdicio, entonces estaremos dedicados a transformar código en software funcionando, e implementar este software en un entorno de producción tan pronto como sea posible. Más tarde, recoger el feedback de los requisitos más detallados del cliente, entonces sí podemos concluir que la funcionalidad necesaria está terminada (o no). Cuanto más trabajo tenemos no finalizado, mayor es el riesgo.
Si compramos esta idea, entonces vamos a precisar encontrar una solución para eliminar los desperdicios, ej. trabajo NO terminado. ¿Qué es lo que debemos hacer?
Los 5 principios Lean nos dan una dirección paso a paso bastante clara, y cuando esto se aplica al desarrollo de software, tenemos una caja de herramientas muy útil, compuesto de muchas prácticas ágiles que nos pueden ayudar a resolver cualquier problema. Para reducir el tiempo entre que el código está terminado, probado e integrado, tenemos que tomar pequeños pasos hacia adelante, haciendo frecuentes check-ins e integración contínua. Para reducir el tiempo entre que la funcionalidad es terminada y el momento en que empieza a generar valor para el cliente, precisamos entregar frecuentemente. Como puede ver, Lean y Desarrollo Agil se integran perfectamente en este punto!
Hace cuatro meses, AMR Elssamadisy sugirió la noticia, "Opinión: refactoring es un desperdicio necesario":
... Hay dos tipos de desperdicio en Lean: desperdicio puro, y desperdicio necesario. Desperdicio puro es aquel que no tiene ningún valor para el equipo que está construyendo el software como para cliente que está utilizando el software. El desperdicio necesario, por otra parte, es la mejor manera conocida actualmente de como hacer el trabajo, incluso si no aportar valor al cliente.
Ning Lu también habló acerca de los tipos de desperdicio definidos en Lean, especialmente el segundo tipo, denominado "desperdicio necesario". En su opinión, prueba, integración, refactoring y gestión se caracterizan como este tipo de desperdicio. Enumeró varios patrones interesantes que normalmente se utilizan para reducir estas formas de desperdicio:
- Tratarlo de una manera positiva: reducir el número de miembros del equipo y aumentar los requisitos para la contratación.
- Cambiar las tareas personales por "tareas de equipo": todo el equipo en conjunto es el responsable de los trabajos de diseño, pruebas, y parte de la integración. El equipo es auto-organizado. La responsabilidad del código es compartida por el equipo.
- Separar las responsabilidades entre personas y máquinas: pase todo tipo de trabajo posible a automatizado.
- Hacer el trabajo siempre antes de tiempo, y con frecuencia: introduzca desarrollo orientado a las pruebas (TDD), hacer test unitarios con frecuencia, refactoring e integración en las primeras etapas. Asegúrese de que todas las personas tienen una comprensión clara de los objetivos del proyecto tan pronto como sea posible, y asegúrese de que el status del proyecto es siempre visible.
