miércoles, 13 de junio de 2007

Metodologias Agiles (LD)

Lean Development



Lean Development (LD) es el método menos divulgado entre los reconocidamente 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.

Los procesos a la manera americana corrían con sus máquinas al 100% de capacidad y mantenían inventarios gigantescos de productos y suministros; Toyota , en contra de la intuición, resultaba más eficiente manteniendo suministros en planta para un solo día, y produciendo sólo lo necesario para cubrir las órdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita además que el inventario degrade o se torne obsoleto, o empiece a actuar como un freno para el cambio. Toyota implementaba además las técnicas innovadoras del Total Quality Management de Edward Deming, que sólo algunos matemáticos y empresarios de avanzada conocían en Estados Unidos. Hasta el día de hoy la foto de Deming en Toyota es más grande y esplendorosa que la del fundador, Toyoda Sakichi.

Otros aspectos esenciales de Lean Manufacturing son la relación participativa con el empleado y el trato que le brinda la compañía, así como una especificación de principios, disciplinas y métodos iterativos, adaptativos, auto-organizativos e interdependientes en un patrón de ciclos de corta duración que tiene algo más que un aire de familia con el patrón de procesos de los MAs (http://www.strategosinc.com/principles.htm). Existe unanimidad de intereses, consistencia de discurso y complementariedad entre las comunidades Lean de manufactura y desarrollo de software.Mientras que otros MAs se concentran en el proceso de desarrollo, 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

1.

Satisfacer al cliente es la máxima prioridad.

2.

Proporcionar siempre el mejor valor por la inversión.

3.

El éxito depende de la activa participación del cliente.

4.

Cada proyecto LD es un esfuerzo de equipo.

5.

Todo se puede cambiar.

6.

Soluciones de dominio, no puntos.

7.

Completar, no construir.

8.

Una solución al 80% hoy, en vez de una al 100% mañana.

9.

El minimalismo es esencial.

10.

La necesidad determina la tecnología.

11.

El crecimiento del producto es el incremento de sus prestaciones, no de su tamaño.

12.

Nunca empujes LD más allá de sus límites.

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:

1.

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.

2.

Amplificar el conocimiento (Feedback, Iterations, Synchronization, Set-based Development). El desarrollo se considera un ejercicio de descubrimiento.

3.

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.

4.

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.

5.

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.

6.

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.

7.

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 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:

1.

Eliminar basura – Entre la basura se cuentan diagramas y modelos que no agregan valor al producto.

2.

Minimizar inventario – Igualmente, suprimir artefactos tales como documentos de requerimiento y diseño.

3.

Maximizar el flujo – Utilizar desarrollo iterativo.

4.

Solicitar demanda – Soportar requerimientos flexibles.

5.

Otorgar poder a los trabajadores.

6.

Satisfacer los requerimientos del cliente – Trabajar junto a él, permitiéndole cambiar de ideas.

7.

Hacerlo bien la primera vez – Verificar temprano y refactorizar cuando sea preciso.

8.

Abolir la optimización local – Alcance de gestión flexible.

9.

Asociarse con quienes suministran – Evitar relaciones de adversidad.

10.

Crear una cultura de mejora continua.

Las herramientas, junto con el prolijo desarrollo de la metodología, se detallan en un texto de Mary y Tom Poppendieck , consistentemente encomiado por sus lectores. Igual que Agile Modeling, que cubría sobre todo aspectos de modelado y documentación, LD y LSD han sido pensados como complemento de otros métodos, y no como una metodología excluyente a implementar en la empresa. LD prefiere concentrarse en las premisas y modelos derivados de Lean Production, que hoy constituyen lo que se conoce como el canon de la Escuela de Negocios de Harvard. Para las técnicas concretas de programación, LD promueve el uso de otros MAs que sean consistentes con su visión, como XP o sobre todo Scrum.

Aunque la formulación del método es relativamente reciente, la familiaridad de muchas empresas con los principios de Lean Production & Lean Manufacturing ha facilitado la penetración en el mercado de su análogo en ingeniería de software. LD se encuentra hoy en América del Norte en una situación similar a la de DSDM en Gran Bretaña, llegando al 7% entre los MAs a nivel mundial (algo menos que Crystal pero el doble que Scrum). Existen abundantes casos de éxito documentados empleando LD y LSD, la mayoría en Canadá. Algunos de ellos son los de Canadian Pacific Railway, Autodesk y PowerEx Corporation. Se ha aplicado prácticamente a todo el espectro de la industria.

No hay comentarios: