Lean Development

Lean Development Concepto: Lean Development (LD) es el método menos divulgado entre los conocidamente importantes. Se inspira en el éxito del proceso industrial Lean Manufacturing, bien conocido en la producción automotriz y en manufactura desde la década de 1980.

Lean Development(LD): Definida por Bob Charette a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.

Un poco de Historia

Lean Development, es el método menos divulgado entre los conocidamente importantes. La palabra “lean” significa magro, enjuto; en su sentido técnico apareció por primera vez en 1990 en el libro de James Womack La Máquina que Cambió al Mundo. LD, iniciado por Bob Charette, se inspira en el éxito del proceso industrial Lean Manufacturing, bien conocido en la producción automotriz y en manufactura desde la década de 1980. Este proceso tiene como precepto la eliminación de residuos a través de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo más perfecto posible.

Características de Lean Development(LD)

Charette sostenía que para ser verdaderamente ágil se debía conocer además el negocio de punta a punta. LD se inspira en doce valores centrados en estrategias de gestión

• Satisfacer al cliente es la máxima prioridad.
• Proporcionar siempre el mejor valor por la inversión.
• El éxito depende de la activa participación del cliente.
• Cada proyecto LD es un esfuerzo de equipo.
• Todo se puede cambiar.
• Soluciones de dominio, no puntos.
• Completar, no construir.
• Una solución al 80% hoy, en vez de una al 100% mañana.
• El minimalismo es esencial.
• La necesidad determina la tecnología.
• El crecimiento del producto es el incremento de sus prestaciones, no de su tamaño.
• Nunca empujes LD más allá de sus límites.

Fundamentos de la Metodología

Dado que LD es más una filosofía de management que un proceso de desarrollo no hay mucho que decir del tamaño del equipo, la duración de las iteraciones, los roles o la naturaleza de sus etapas. Últimamente LD ha evolucionado como Lean Software Development (LSD); su figura de referencia es Mary Poppendieck . Uno de los sitios primordiales del modelo son las páginas consagradas a LSD que mantiene Darrell Norton , donde se promueve el desarrollo del método aplicando el framework .NET de Microsoft. Norton ha reformulado los valores de Charette reduciéndolos a siete y suministrando más de veinte herramientas análogas a patrones organizacionales para su implementación en ingeniería de software. Los nuevos principios son:

• Eliminar basura (las herramientas son Seeing Waste, Value Stream Mapping). Basura es todo lo que no agregue valor a un producto, desde la óptica del sistema de valores del cliente. Este principio equivale a la reducción del inventario en manufactura. El inventario del desarrollo de software es el conjunto de artefactos intermedios. Un estudio del Standish Group reveló que en un sistema típico, las prestaciones que se usan siempre suman el 7%, las que se usan a menudo el 13%, “algunas veces” el 16%, “raras veces” el 19% y “nunca” el 45%. Esto es un claro 80/20: el 80% del valor proviene del 20% de los rasgos. Concentrarse en el 20% útil es una aplicación del mismo principio que subyace a la idea de YAGNI.
• Amplificar el conocimiento (Feedback, Iterations, Synchronization, Set-based Development). El desarrollo se considera un ejercicio de descubrimiento.
• Decidir tan tarde como sea posible (Options Thinking, The Last Responsible Moment, Making Decisions). Las prácticas de desarrollo que proporcionan toma de decisiones tardías son efectivas en todos los dominios que involucran incertidumbre porque brindan una estrategia basada en opciones fundadas en la realidad, no en especulaciones. En un mercado que cambia, la decisión tardía, que mantiene las opciones abiertas, es más eficiente que un compromiso prematuro. En términos metodológicos, este principio se traduce también en la renuencia a planificarlo todo antes de comenzar. En un entorno cambiante, los requerimientos detallados corren el riesgo de estar equivocados o ser anacrónicos.
• Entregar tan rápido como sea posible (Pull Systems, Queueing Theory, Cost of Delay). Se deben favorecer ciclos cortos de diseño, implementación, feedback, mejora. El cliente recibe lo que necesita hoy, no lo que necesitaba ayer.
• Otorgar poder al equipo (Self Determination, Motivation, Leadership, Expertise). Los desarrolladores que mejor conocen los elementos de juicio son los que pueden tomar las decisiones más adecuadas.
• Integridad incorporada (Perceived Integrity, Conceptual Integrity, Refactoring, Testing). La integridad conceptual significa que los conceptos del sistema trabajan como una totalidad armónica de arquitectura coherente. La investigación ha demostrado que la integridad viene con el liderazgo, la experiencia relevante, la comunicación efectiva y la disciplina saludable. Los procesos, los procedimientos y las medidas no son substitutos adecuados.
• Ver la totalidad (Measurements, Contracts). Uno de los problemas más intratables del desarrollo de software convencional es que los expertos en áreas específicas (por ejemplo, bases de datos o GUIs) maximizan la corrección de la parte que les interesa, sin percibir la totalidad.

Otra preceptiva

Otra preceptiva algo más amplia es la de Mary Poppendieck , cuidadosamente decantadas del Lean Manufacturing y de Total Quality Management (TQM), que sólo coincide con la de Norton en algunos puntos:

• Eliminar basura – Entre la basura se cuentan diagramas y modelos que no agregan valor al producto.
• Minimizar inventario – Igualmente, suprimir artefactos tales como documentos de requerimiento y diseño.
• Maximizar el flujo – Utilizar desarrollo iterativo.
• Solicitar demanda – Soportar requerimientos flexibles.
• Otorgar poder a los trabajadores.
• Satisfacer los requerimientos del cliente – Trabajar junto a él, permitiéndole cambiar de ideas.
• Hacerlo bien la primera vez – Verificar temprano y refactorizar cuando sea preciso.
• Abolir la optimización local – Alcance de gestión flexible.
• Asociarse con quienes suministran – Evitar relaciones de adversidad.
• Crear una cultura de mejora continua.

Fuente

• Análisis de Diseño de Sistemas. http://www.adsfrank.blogspot.com/2007/06/metodologias-agiles-ld.html
• http://www.strategosinc.com/principles.htm
• carlos-reynoso-metodos-agiles-academia.ppt. http://carlosreynoso.com