Lean Development
| ||||
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.
Sumario
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.
Ventajas y Desventajas de Lean Development (LD)
Como metodología en fin, esta presenta ventajas y desventajas como son:
Ventajas
- La eliminación de los residuos conduce a la eficiencia global del proceso de desarrollo. Esto a su vez acelera el proceso de desarrollo de software que reduce el tiempo y el costo del proyecto. Lo que es absolutamente vital en el entorno actual. Cualquier cosa que permite a las organizaciones para entregar más proyectos en el mismo periodo de tiempo que va a ser popular.
- La entrega del producto temprana es una ventaja definitiva. Esto significa que su equipo de desarrollo puede ofrecer mayor funcionalidad en un corto periodo de tiempo, por lo tanto, permitir que más proyectos para ser entregados. Esto sólo va a satisfacer tanto su departamento de finanzas, como a los clientes finales.
- El empoderamiento del equipo de desarrollo ayuda a desarrollar la capacidad de decisión de los miembros del equipo que a su vez, crea un equipo más motivado. Este beneficio realmente no se puede insistir demasiado suficiente. Los desarrolladores no aborreces nada más que ser micro-administrado y que las decisiones impuestas sobre ellos. De esta manera se puede determinar la mejor forma para desarrollar la funcionalidad que dará lugar generalmente a un producto final mucho mejor.
Desventajas
- El proyecto depende en gran medida la cohesión del equipo y los compromisos individuales de los miembros del equipo. En la mayoría de las profesiones que esto podría ser un factor muy importante, pero en él largas horas de trabajo y poco sociable es la norma por lo que no debería ser una gran desventaja. Y, por supuesto, si usted no darse cuenta de que los desarrolladores y probadores de trabajar largas horas, largos entonces usted está en para un rudo despertar. Por ejemplo, yo gestionar grandes proyectos y programas y de fin de semana pasado trabajé 33 horas de las 48 horas disponibles en la dirección del diagnóstico y la fijación de un problema importante que afecta a mi proyecto.
- El éxito del proyecto depende de la disciplina de los miembros del equipo son y cómo son excepcionales sus habilidades técnicas. Si usted no tiene un equipo de personas con buenas habilidades que se complementan entre sí, entonces usted tiene un problema inmediato.
- Los patrocinadores del proyecto y los clientes necesitan saber lo que quieren y tomar las decisiones pertinentes. En desarrollo ágil de software estas decisiones pueden ser tomadas más adelante que, por ejemplo cuando se utilizan metodologías de cascada, que debería ser una ventaja. Pero el problema es que los promotores de proyectos tienden a ser paralizado por el miedo a la hora de tomar las decisiones difíciles. Y en grasa todo el objetivo de utilizar esta metodología ágil más decir que es para permitir que su desarrollo se hace más rápido y más barato de lo que sería posible. Por supuesto, esto significa que las decisiones tienen que hacerse rápidamente cuando sea necesario y se pegó.
- El papel de un analista de negocios es de vital importancia para garantizar la documentación de los requerimientos del negocio (BRD) se entiende correctamente. Si usted no tiene una persona con las habilidades correctas analista de negocios, entonces rápidamente podría encontrar esta convertido en una de las causas de la corrupción del alcance.
- En magra que permite la especificación de requisitos software (SRS) para evolucionar. Sin embargo, esto causa problemas de su propia. La flexibilidad es grande, pero demasiado pronto dará lugar a un desarrollo que pierde de vista su objetivo original y que nunca termina.
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
