ndice LEAN DEVELOPMENT (LD) DEFINICIN...................................................................................................................................... 1 UN POCO DE HISTORIA................................................................................................................ 2 CARACTERSTICAS DE LEAN DEVELOPMENT (LD) ............................................................. 2 FUNDAMENTOS DE LA METODOLOGA................................................................................... 3 1.

ELIMINAR BASURA ..................................................................................................................... 3 2.AMPLIFICAR EL CONOCIMIENTO ........................................................................................... 4 3.DECIDIR TAN TARDE COMO SEA POSIBLE......................................................................... 5 4.ENTREGAR TAN RPIDO COMO SEA POSIBLE ................................................................. 6 5.OTORGAR PODER AL EQUIPO ............................................................................................... 6 6.INTEGRIDAD INCORPORADA .................................................................................................. 8 7.VER LA TOTALIDAD (MEASUREMENTS, CONTRACTS). .................................................. 9 OTRA PERSPECTIVA..................................................................................................................... 9 1. ELIMINAR BASURA ............................................................................................................... 10 2. MINIMIZAR INVENTARIO ........................................................................................................ 10 3. MAXIMIZAR EL FLUJO ......................................................................................................... 10 4. SOLICITAR DEMANDA ......................................................................................................... 10 6. SATISFACER LOS REQUERIMIENTOS DEL CLIENTE ................................................. 10 7. HACERLO BIEN LA PRIMERA VEZ ................................................................................... 10 8. ABOLIR LA OPTIMIZACIN LOCAL .................................................................................. 10 9. ASOCIARSE CON QUIENES SUMINISTRAN .................................................................. 10 LAS PRCTICAS DE LEAN SOFTWARE ................................................................................. 11 VENTAJAS Y DESVENTAJAS DE LEAN DEVELOPMENT (LD) .......................................... 11 VENTAJAS ...................................................................................................................................... 11 DESVENTAJAS .............................................................................................................................. 12 VENTAJAS ................................................................................ ERROR! BOOKMARK NOT DEFINED. MAPA CONCEPTUAL .......................................................................................................................... 13 CUESTIONARIO .................................................................................................................................. 14 BIBLIOGRAFIA .................................................................................................................................... 16

Contenido

Lean Development (LD)

Definicin Lean Development (LD). Definida por Bob Charette.s a partir de su experiencia en proyectos con la industria japonesa del automvil en los aos 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 caracterstica es introducir un mecanismo para implementar dichos cambios. Lean Development (LD) es el mtodo menos divulgado entre los reconocidamente importantes. La palabra lean significa magro, enjuto; en su sentido tcnico apareci por primera vez en 1990 en el libro de James Womack La Mquina que Cambi al Mundo . LD, iniciado por Bob Charette, se inspira en el xito del proceso industrial Lean Manufacturing, bien conocido en la produccin automotriz y en manufactura desde la dcada de 1980. Este proceso tiene como precepto la eliminacin de residuos a travs de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo ms perfecto posible. Los procesos a la manera americana corran con sus mquinas al 100% de capacidad y mantenan inventarios gigantescos de productos y suministros; Toyota , en contra de la intuicin, resultaba ms eficiente manteniendo suministros en planta para un solo da, y produciendo slo lo necesario para cubrir las rdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita adems que el inventario degrade o se torne obsoleto, o empiece a actuar como un freno para el cambio. Toyota implementaba adems las tcnicas innovadoras del Total Quality Management de Edward Deming, que slo algunos matemticos y empresarios de avanzada conocan en Estados Unidos. Hasta el da de hoy la foto de Deming en Toyota es ms grande y esplendorosa que la del fundador, Toyoda Sakichi. Otros aspectos esenciales de Lean Manufacturing son la relacin participativa con el empleado y el trato que le brinda la compaa, as como una especificacin de principios, disciplinas y mtodos iterativos, adaptativos, auto-organizativos e
1

Contenido

interdependientes en un patrn de ciclos de corta duracin que tiene algo ms que un aire de familia con el patrn 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 sostena que para ser verdaderamente gil se deba conocer adems el negocio de punta a punta.

Un poco de Historia Lean Development, es el mtodo menos divulgado entre los conocidamente importantes. La palabra "http://www.ecured.culean"http://www.ecured.cu significa magro, enjuto; en su sentido tcnico apareci por primera vez en 1990 en el libro de James Womack La Mquina que cambi al Mundo. LD, iniciado por Bob Charette, se inspira en el xito del proceso industrial Lean Manufacturing, bien conocido en la produccin automotriz y en manufactura desde la dcada de 1980. Este proceso tiene como precepto la eliminacin de residuos a travs de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo ms perfecto posible.

Caractersticas de Lean Development (LD) LD se inspira en doce valores centrados en estrategias de gestin 1.Satisfacer al cliente es la mxima prioridad. 2.Proporcionar siempre el mejor valor por la inversin. 3. El xito depende de la activa participacin 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 solucin al 80% hoy, en vez de una al 100% maana. 9.El minimalismo es esencial.
2

Contenido

10.La necesidad determina la tecnologa. 11.El crecimiento del producto es el incremento de sus prestaciones, no de su tamao. 12.Nunca empujes LD ms all de sus lmites. Dado que LD es ms una filosofa de management que un proceso de desarrollo no hay mucho que decir del tamao del equipo, la duracin 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 pginas consagradas a LSD que mantiene Darrell Norton , donde se promueve el desarrollo del mtodo aplicando el framework .NET de Microsoft. Norton ha reformulado los valores de Charette reducindolos a siete y suministrando ms de veinte herramientas anlogas a patrones organizacionales para su implementacin en ingeniera de software.

Fundamentos de la Metodologa 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 reduccin 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 tpico, 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 aplicacin del mismo principio que subyace a la idea de YAGNI. Todo lo que no agrega valor al cliente se consideran residuos ( muda ). Esto incluye: cdigo innecesario y funcionalidad retraso en el proceso de desarrollo de software poco claros los requisitos
3

Contenido

pruebas insuficientes, dando lugar a la repeticin de procesos evitables burocracia comunicacin interna lenta

Con el fin de ser capaz de eliminar los residuos, uno debe ser capaz de reconocer. Si alguna actividad que se pueden omitir o el resultado podran lograrse sin ella, se trata de residuos. Hecho parcialmente con el tiempo de codificacin abandonado durante el proceso de desarrollo es un residuo. Procesos adicionales y funciones no utilizados a menudo por los clientes son los residuos. Esperando a otras actividades, los equipos, los procesos son los residuos. Defectos y de menor calidad son los residuos. Gastos de gestin no produce valor real es de residuos. Una cadena de valor de asignacin tcnica se utiliza para distinguir y reconocer los residuos. El segundo paso consiste en sealar las fuentes de residuos y eliminarlos. Lo mismo debe hacerse iterativamente hasta incluso esenciales aparentes los procesos y los procedimientos de liquidacin. 2.Amplificar el conocimiento (Feedback, Iterations, Synchronization, Setbased Development). El desarrollo se considera un ejercicio de descubrimiento. El desarrollo de software es un proceso continuo de aprendizaje, con el desafo adicional de los equipos de desarrollo y tamao del producto final. El mejor enfoque para la mejora de un entorno de desarrollo de software es para ampliar el aprendizaje. La acumulacin de defectos debe ser prevenida por medio de pruebas de funcionamiento tan pronto como el cdigo est escrito. En lugar de aadir ms documentacin o la planificacin detallada, las diferentes ideas podran ser juzgados por la escritura de cdigo y la construccin. El proceso de recopilacin de requerimientos de usuario se podra simplificar mediante la presentacin de las pantallas para los usuarios finales y obtener su entrada. El proceso de aprendizaje se acelera por el uso de ciclos de iteracin cortos - cada uno de ellos junto con refactorizacin y pruebas de integracin. El aumento de retroalimentacin a travs de breves sesiones de retroalimentacin con los clientes ayuda a la hora de determinar la fase actual de desarrollo y los esfuerzos de ajuste para mejoras futuras. Durante esas sesiones cortas ambos representantes de los clientes y el equipo de desarrollo obtener ms informacin
4

Contenido

sobre el dominio del problema y averiguar las posibles soluciones para un mayor desarrollo. As, los clientes a entender mejor sus necesidades, en funcin del resultado de los esfuerzos de desarrollo existente, y los desarrolladores aprender a responder mejor a esas necesidades. Otra idea en la comunicacin y el proceso de aprendizaje con el desarrollo de un cliente est basado en conjuntos - esto se concentra en la comunicacin de las limitaciones de la solucin de futuro y no las posibles soluciones, promoviendo as el nacimiento de la solucin mediante el dilogo con el cliente. 3. Decidir tan tarde como sea posible (Options Thinking, The Last Responsible Moment, Making Decisions). Las prcticas de desarrollo que proporcionan toma de decisiones tardas 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 decisin tarda, que mantiene las opciones abiertas, es ms eficiente que un compromiso prematuro. En trminos metodolgicos, este principio se traduce tambin en la renuencia a planificarlo todo antes de comenzar. En un entorno cambiante, los requerimientos detallados corren el riesgo de estar equivocados o ser anacrnicos Como el desarrollo de software siempre se asocia con cierto grado de incertidumbre, mejores resultados se debe lograr con un enfoque basado en las opciones, lo que retrasa las decisiones tanto como sea posible hasta que puedan hacerse sobre la base de hechos y no en suposiciones y predicciones inciertas. Cuanto ms complejo es un sistema, ms capacidad para el cambio debe ser construido en l, lo que permite el retraso de los compromisos importantes y cruciales. El enfoque interactivo promueve este principio - la capacidad de adaptarse a los cambios y corregir errores, que podran ser muy costoso si se descubre despus de la liberacin del sistema. Un desarrollo de software gil enfoque puede mover el edificio de las opciones anteriores para los clientes, lo que retrasa algunas decisiones cruciales hasta que los clientes se han dado cuenta sus necesidades mejor. Esto tambin permite que ms tarde la adaptacin a los cambios y la prevencin de costosos anteriores
5

Contenido

delimitadas tecnologa-decisiones. Esto no quiere decir que no hay planificacin deben participar - por el contrario, las actividades de planificacin debe concentrarse en las diferentes opciones y la adaptacin a la situacin actual, as como aclarar situaciones confusas mediante el establecimiento de patrones de accin rpida. La evaluacin de las diferentes opciones es eficaz tan pronto como se dieron cuenta de que no son libres, pero proporcionan la flexibilidad necesaria para la toma de decisiones finales. 4.Entregar tan rpido como sea posible (Pull Systems, Queueing Theory, Cost of Delay). Se deben favorecer ciclos cortos de diseo ? implementacin ? 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 ms adecuadas. En la era de la rpida evolucin de la tecnologa, no es el ms grande que sobrevive, pero el ms rpido. Cuanto ms pronto el producto final se entrega sin defectos considerables, los comentarios ms pronto se puede recibir, y se incorporan en la siguiente iteracin . El ms corto de las iteraciones, mejor ser el aprendizaje y la comunicacin dentro del equipo. Sin velocidad, las decisiones no pueden ser postergadas. Velocidad asegura el cumplimiento de las necesidades actuales del cliente y no lo que se requiere de ayer. Esto les da la oportunidad de retrasar la toma de sus mentes acerca de lo que realmente lo necesita hasta que adquieran un mejor conocimiento. Los clientes valoran la rpida entrega de una calidad de producto. El justo a tiempo de la ideologa de produccin podra ser aplicado a desarrollo de software , reconociendo sus necesidades especficas y el medio ambiente. Esto se consigue por presentar el resultado necesario y dejando que el equipo de organizarse y dividir las tareas para lograr el resultado necesario para una determinada iteracin . Al principio, el cliente proporciona la entrada necesaria. Esto podra ser simplemente se presenta en pequeas fichas o historias - los desarrolladores estimar el tiempo necesario para la puesta en prctica de cada
6

Contenido

tarjeta. As, los cambios de organizacin del trabajo en s mismo tirando del sistema : cada maana durante una reunin de stand-up , cada miembro de las revisiones del equipo de lo que se ha hecho ayer, lo que hay que hacer hoy y maana, y le pregunta por los insumos necesarios de sus colegas o el cliente. Esto requiere transparencia del proceso, que es tambin beneficioso para la comunicacin del equipo. Otra idea clave en el sistema de Toyota es el conjunto de desarrollo de productos basado en el diseo. Si un nuevo sistema de frenos es necesario para un coche, por ejemplo, tres equipos pueden disear soluciones al mismo problema. Cada equipo aprende sobre el espacio del problema y disea una solucin potencial. Como una solucin no se considera razonable, que se corta. Al final de una poca, los diseos de sobrevivientes se comparan y se elegir uno, tal vez con algunas modificaciones basadas en el aprendizaje de los otros - un gran ejemplo de aplazar el compromiso hasta el ltimo momento posible. Las decisiones de software tambin pueden beneficiarse de esta prctica para minimizar el riesgo provocado por grandes por adelantado de diseo. Ha habido una creencia tradicional en la mayora de las empresas acerca de la toma de decisiones en la organizacin - los administradores de decirle a los trabajadores cmo hacer su propio trabajo. En un Work-Out tcnica, las funciones se activan - los gerentes se les ensea a escuchar a los desarrolladores , por lo que puede explicar mejor lo que se pudieran tomar medidas, as como sugerencias de mejora. El enfoque de grasa favorece el aforismo de "encontrar gente buena y dejar que ellos hagan su propio trabajo," progresos alentadores, la captura de errores y eliminacin de los obstculos, pero no de micro-gestin. Otra creencia errnea ha sido la consideracin de las personas como recursos . Las personas pueden ser recursos desde el punto de vista de una hoja de datos estadsticos, sino en el desarrollo de software , as como cualquier organizacin empresarial, la gente necesita algo ms que la lista de tareas y la garanta de que no se ver afectado durante la realizacin de las tareas. Las personas necesitan motivacin y un propsito ms elevado para trabajar - objetivo dentro de la realidad accesible, con la garanta de que el equipo podra elegir a sus propios compromisos. Los desarrolladores deben tener acceso al cliente, el lder del
7

Contenido

equipo debe proporcionar apoyo y ayuda en situaciones difciles, as como garantizar que el escepticismo no arruina el espritu de equipo. 6.Integridad incorporada (Perceived Integrity, Conceptual Integrity,

Refactoring, Testing). La integridad conceptual significa que los conceptos del sistema trabajan como una totalidad armnica de arquitectura coherente. La investigacin ha demostrado que la integridad viene con el liderazgo, la experiencia relevante, la comunicacin efectiva y la disciplina saludable. Los procesos, los procedimientos y las medidas no son substitutos adecuados. El cliente debe tener una experiencia global del sistema - esto es la integridad de la llamada percepcin: la forma en que se est anunciando, entrega, instalacin, acceso, lo intuitivo su uso es, el precio y lo bien que resuelve problemas. La integridad conceptual significa que los componentes separados del sistema funcionan bien juntos como un todo con el equilibrio entre la flexibilidad, facilidad de mantenimiento, eficiencia y capacidad de respuesta. Esto podra lograrse mediante la comprensin del dominio del problema y su solucin al mismo tiempo, no secuencialmente. La informacin necesaria se recibe en piezas de lotes pequeos - no de una sola vez, con gran preferible cara a cara la comunicacin y no toda la documentacin escrita. El flujo de informacin debe ser constante en ambos sentidos - desde el cliente a los desarrolladores y la espalda, evitando as la gran cantidad de informacin estresante despus del desarrollo de largo en forma aislada. Una de las maneras saludables hacia la arquitectura integral es la refactorizacin . Las caractersticas ms se aaden a la del sistema, el ms flojo de la base de partida el cdigo para futuras mejoras. Como se describi anteriormente en el mtodo de refactorizacin XP gil se trata de mantener la simplicidad, la claridad, la cantidad mnima de funciones en el cdigo. Las repeticiones en el cdigo de seales para diseos de cdigo mal y debe ser evitado. El proceso de construccin completo y automatizado debe ir acompaada de una suite completa y automatizada de los desarrolladores y pruebas de los clientes, tener el control de versiones misma sincronizacin, y la semntica como el estado actual del sistema. Al final de la integridad debe ser verificado con pruebas exhaustivas, asegurando
8

Contenido

que el sistema hace lo que el cliente espera que lo haga. Las pruebas automatizadas tambin se consideran parte del proceso de produccin, y por lo tanto si no agregan valor deben considerarse residuos. Las pruebas

automatizadas no debe ser una meta, sino un medio para un fin, en particular la reduccin de defectos. 7.Ver la totalidad (Measurements, Contracts). Uno de los problemas ms intratables del desarrollo de software convencional es que los expertos en reas especficas (por ejemplo, bases de datos o GUIs) maximizan la correccin de la parte que les interesa, sin percibir la totalidad. Los sistemas de software hoy en da no son simplemente la suma de sus partes, sino tambin el producto de sus interacciones. Los defectos en el software tienden a acumularse durante el proceso de desarrollo - por la descomposicin de las tareas grandes en tareas ms pequeas, y por la normalizacin de las diferentes etapas de desarrollo, las causas de los defectos deben ser encontrados y eliminados. Cuanto mayor sea el sistema, las organizaciones ms que estn implicados en su desarrollo y las partes ms son desarrollados por diferentes equipos, mayor es la importancia de tener relaciones bien definidas entre las diferentes proveedores, con el fin de producir un sistema con componentes que interactan con suavidad. Durante un largo perodo de desarrollo, una red ms fuerte subcontratista es mucho ms beneficioso que la optimizacin de beneficios a corto plazo, que no permite relaciones ganar-ganar. El pensamiento Lean tiene que ser bien entendido por todos los miembros de un proyecto, antes de implementar de manera concreta, en la vida real situacin. "Pensar a lo grande, pequeo acto, no rpido, aprender rpidamente" - estas consignas resumir la importancia de entender el campo y de la idoneidad de la aplicacin de principios de eficiencia a lo largo del proceso de desarrollo de software. Slo cuando todos los principios de eficiencia se implementan juntos, combinado con un fuerte "sentido comn" en relacin con el entorno de trabajo, hay una base para el xito en el desarrollo de software .

Otra perspectiva
9

Contenido

Otra preceptiva algo ms amplia es la de Mary Poppendieck , cuidadosamente decantadas del Lean Manufacturing y de Total Quality Management (TQM), que slo 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 diseo. 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, permitindole cambiar de ideas. 7. Hacerlo bien la primera vez Verificar temprano y refactorizar cuando sea preciso. 8. Abolir la optimizacin local Alcance de gestin 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 metodologa, se detallan en un texto de Mary y Tom Poppendieck , consistentemente encomiado por sus lectores. Igual que Agile Modeling, que cubra sobre todo aspectos de modelado y documentacin, LD y LSD han sido pensados como complemento de otros mtodos, y no como una metodologa 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 tcnicas concretas de programacin, LD promueve el uso de otros MAs que sean consistentes con su visin, como XP o sobre todo Scrum. Aunque la formulacin del mtodo es relativamente reciente, la familiaridad de muchas empresas con los principios de Lean Production & Lean Manufacturing ha facilitado la penetracin en el mercado de su anlogo en ingeniera de software. LD se encuentra hoy en Amrica del Norte en una situacin similar a la de DSDM en Gran Bretaa, llegando al 7% entre los MAs a nivel mundial (algo menos que
10

Contenido

Crystal pero el doble que Scrum). Existen abundantes casos de xito documentados empleando LD y LSD, la mayora en Canad. Algunos de ellos son los de Canadian Pacific Railway, Autodesk y PowerEx Corporation. Se ha aplicado prcticamente a todo el espectro de la industria.

Las Prcticas De Lean Software Lean las prcticas de desarrollo de software o lo que l llama "Poppendiecks herramientas" se expresan de forma ligeramente diferente a sus equivalentes en el desarrollo gil de software , pero existen paralelismos. Ejemplos de estas prcticas incluyen: Ver a los residuos Valor Stream Mapping Establecer un desarrollo basado en Tire de los sistemas de Teora de colas Motivacin Las mediciones

Ventajas y Desventajas de Lean Development (LD) Como metodologa en fin, esta presenta ventajas y desventajas como son:

Ventajas La eliminacin 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 ms 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

11

Contenido

tiempo, por lo tanto, permitir que ms proyectos para ser entregados. Esto slo 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 decisin de los miembros del equipo que a su vez, crea un equipo ms motivado. Este beneficio realmente no se puede insistir demasiado suficiente. Los desarrolladores no aborreces nada ms 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 cohesin del equipo y los compromisos individuales de los miembros del equipo. En la mayora de las profesiones que esto podra ser un factor muy importante, pero en l largas horas de trabajo y poco sociable es la norma por lo que no debera 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 direccin del diagnstico y la fijacin de un problema importante que afecta a mi proyecto. El xito del proyecto depende de la disciplina de los miembros del equipo son y cmo son excepcionales sus habilidades tcnicas. 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 ms adelante que, por Ventajas y Desventajas de Lean Development (LD) Como metodologa en fin, esta presenta ventajas y desventajas como son:

12

Contenido

Mapa Conceptual

LEAN DEVELOPMENT (LD)

DEFINICION

CARACTERISTICAS

LAS PRCTICAS DE LEAN SOFTWARE

Lean Development (LD). Definida por Bob Charette.s a partir de su experiencia en proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa.

Lean Development (LD) es el mtodo menos divulgado entre los reconocidamente importantes. La palabra lean significa magro, enjuto; en su sentido tcnico apareci por primera vez en 1990 en el libro de James Womack La Mquina que Cambi al Mundo

1. Satisfacer al cliente es la mxima prioridad. 2. Proporcionar siempre el mejor valor por la inversin. 3. El xito depende de la activa participacin 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 solucin al 80% hoy, en vez de una al 100% maana. 9. El minimalismo es esencial. 10. La necesidad determina la tecnologa. 11. El crecimiento del producto es el incremento de sus prestaciones, no de su tamao. 12. Nunca empujes LD ms all de sus lmites.

Ver a los residuos Valor Stream Mapping Establecer un desarrollo basado en Tire de los sistemas de Teora de colas Motivacin Las mediciones

13

Contenido

CUESTIONARIO 1. - Por quin fue definida y cundo? R.- Lean Development (LD) fue definida por Bob Charette.s a partir de su experiencia en proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa 2.- Qu precepto tiene este proceso? R.-. Este proceso tiene como precepto la eliminacin de residuos a travs de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo ms perfecto posible 3.- Nombra algunas caractersticas de Lean Development R.- Satisfacer al cliente es la mxima prioridad. Proporcionar siempre el mejor valor por la inversin. El xito depende de la activa participacin del cliente. Cada proyecto LD es un esfuerzo de equipo 4.- Qu se puede decir de LD? R.- Dado que LD es ms una filosofa de management que un proceso de desarrollo no hay mucho que decir del tamao del equipo, la duracin de las iteraciones, los roles o la naturaleza de sus etapas 5.- Cmo es el desarrollo de software? R.- El desarrollo de software es un proceso continuo de aprendizaje, con el desafo adicional de los equipos de desarrollo y tamao del producto final 6.- Por qu se acelera el proceso de aprendizaje? R.- El proceso de aprendizaje se acelera por el uso de ciclos de iteracin cortos cada uno de ellos junto con refactorizacin y pruebas de integracin. .7.- Qu puede ser aplicado a la produccin? R.- El justo a tiempo de la ideologa de produccin podra ser aplicado a desarrollo de software, reconociendo sus necesidades especficas y el medio ambiente 8.- Qu significa la integridad conceptual? R.- La integridad conceptual significa que los conceptos del sistema trabajan como una totalidad armnica de arquitectura coherente
14

Contenido

9.- Las pruebas automatizadas tambin se consideran parte del proceso? R.- Las pruebas automatizadas tambin se consideran parte del proceso de produccin, y por lo tanto si no agregan valor deben considerarse residuos. 10.- Menciona lagunas practicas R.- Ver a los residuos Valor Stream Mapping Establecer un desarrollo basado en 11.- Menciona alguna ventaja R.- La eliminacin de los residuos conduce a la eficiencia global del proceso de desarrollo 12.- En qu ayuda el empoderamiento del equipo de desarrollo? R.- El empoderamiento del equipo de desarrollo ayuda a desarrollar la capacidad de decisin de los miembros del equipo que a su vez, crea un equipo ms motivado. 13.- Por qu es una ventaja la entrega temprana del producto? R.- 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 14.- De qu depende el xito del proyecto? R.- El xito del proyecto depende de la disciplina de los miembros del equipo son y cmo son excepcionales sus habilidades tcnicas. 15.- Antes de implementar el proyecto que debe ocurrir con el pensamiento de Lean? R.- El pensamiento Lean tiene que ser bien entendido por todos los miembros de un proyecto, antes de implementar de manera concreta, en la vida real situacin

15

Contenido

BIBLIOGRAFIA Anlisis de Diseo de Sistemas. http://www.adsfrank.blogspot.com/2007/06/metodologias-agiles-ld.html http://www.strategosinc.com/principles.htmcarlos-reynoso-metodos-agilesacademia.ppt. http://carlosreynoso.com

16