lean deve original terminado
TRANSCRIPT
LEAN DEVELOPMENT (LD)
Índice
LEAN DEVELOPMENT (LD)
DEFINICIÓN....................................................................................................................................1UN POCO DE HISTORIA...............................................................................................................2CARACTERÍSTICAS DE LEAN DEVELOPMENT (LD).............................................................2FUNDAMENTOS DE LA METODOLOGÍA..................................................................................31.ELIMINAR BASURA....................................................................................................................32.AMPLIFICAR EL CONOCIMIENTO..........................................................................................43.DECIDIR TAN TARDE COMO SEA POSIBLE........................................................................54.ENTREGAR TAN RÁPIDO COMO SEA POSIBLE.................................................................65.OTORGAR PODER AL EQUIPO...............................................................................................66.INTEGRIDAD INCORPORADA.................................................................................................87.VER LA TOTALIDAD (MEASUREMENTS, CONTRACTS)...................................................9OTRA PERSPECTIVA....................................................................................................................91. ELIMINAR BASURA –..............................................................................................................102. MINIMIZAR INVENTARIO.......................................................................................................103. MAXIMIZAR EL FLUJO –........................................................................................................104. SOLICITAR DEMANDA –........................................................................................................106. SATISFACER LOS REQUERIMIENTOS DEL CLIENTE –.................................................107. HACERLO BIEN LA PRIMERA VEZ –...................................................................................108. ABOLIR LA OPTIMIZACIÓN LOCAL –..................................................................................109. ASOCIARSE CON QUIENES SUMINISTRAN –..................................................................10LAS PRÁCTICAS DE LEAN SOFTWARE.................................................................................11VENTAJAS Y DESVENTAJAS DE LEAN DEVELOPMENT (LD)..........................................11VENTAJAS.....................................................................................................................................11DESVENTAJAS.............................................................................................................................12VENTAJAS.....................................................................................................................................13MAPA CONCEPTUAL.........................................................................................................................14CUESTIONARIO.................................................................................................................................15BIBLIOGRAFIA...................................................................................................................................17
i
Conten ido
Lean Development (LD)
Definición
Lean Development (LD). Definida por Bob Charette.s 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.
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
1
Conten ido
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.
Un poco de Historia
Lean Development, es el método menos divulgado entre los conocidamente
importantes. La palabra "http://www.ecured.culean"http://www.ecured.cu 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)
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.
2
Conten ido
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.
Fundamentos de la Metodología
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.
Todo lo que no agrega valor al cliente se consideran residuos ( muda ). Esto
incluye:
código innecesario y funcionalidad
retraso en el proceso de desarrollo de software
poco claros los requisitos
3
Conten ido
pruebas insuficientes, dando lugar a la repetición de procesos evitables
burocracia
comunicación 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 podrían lograrse sin ella,
se trata de residuos. Hecho parcialmente con el tiempo de codificación
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 gestión no produce valor real es de residuos.
Una cadena de valor de asignación técnica se utiliza para distinguir y reconocer
los residuos. El segundo paso consiste en señalar las fuentes de residuos y
eliminarlos. Lo mismo debe hacerse iterativamente hasta incluso esenciales
aparentes los procesos y los procedimientos de liquidación.
2.Amplificar el conocimiento (Feedback, Iterations, Synchronization, Set-
based Development). El desarrollo se considera un ejercicio de descubrimiento.
El desarrollo de software es un proceso continuo de aprendizaje, con el desafío
adicional de los equipos de desarrollo y tamaño del producto final. El mejor
enfoque para la mejora de un entorno de desarrollo de software es para ampliar el
aprendizaje. La acumulación de defectos debe ser prevenida por medio de
pruebas de funcionamiento tan pronto como el código está escrito. En lugar de
añadir más documentación o la planificación detallada, las diferentes ideas
podrían ser juzgados por la escritura de código y la construcción. El proceso de
recopilación de requerimientos de usuario se podría simplificar mediante la
presentación de las pantallas para los usuarios finales y obtener su entrada.
El proceso de aprendizaje se acelera por el uso de ciclos de iteración cortos - cada
uno de ellos junto con refactorización y pruebas de integración. El aumento de
retroalimentación a través de breves sesiones de retroalimentación 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 más información
4
Conten ido
sobre el dominio del problema y averiguar las posibles soluciones para un mayor
desarrollo. Así, los clientes a entender mejor sus necesidades, en función del
resultado de los esfuerzos de desarrollo existente, y los desarrolladores aprender
a responder mejor a esas necesidades. Otra idea en la comunicación y el proceso
de aprendizaje con el desarrollo de un cliente está basado en conjuntos - esto se
concentra en la comunicación de las limitaciones de la solución de futuro y no las
posibles soluciones, promoviendo así el nacimiento de la solución mediante el
diálogo con el cliente.
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
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 más complejo es un sistema, más 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 podrían ser muy costoso si se
descubre después de la liberación 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 también permite que
más tarde la adaptación a los cambios y la prevención de costosos anteriores
5
Conten ido
delimitadas tecnología-decisiones. Esto no quiere decir que no hay planificación
deben participar - por el contrario, las actividades de planificación debe
concentrarse en las diferentes opciones y la adaptación a la situación actual, así
como aclarar situaciones confusas mediante el establecimiento de patrones de
acción rápida. La evaluación 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 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.
En la era de la rápida evolución de la tecnología, no es el más grande que
sobrevive, pero el más rápido. Cuanto más pronto el producto final se entrega sin
defectos considerables, los comentarios más pronto se puede recibir, y se
incorporan en la siguiente iteración . El más corto de las iteraciones, mejor será el
aprendizaje y la comunicación 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 rápida entrega de una
calidad de producto.
El justo a tiempo de la ideología de producción podría ser aplicado a desarrollo de
software , reconociendo sus necesidades específicas 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 iteración . Al principio, el cliente proporciona la entrada necesaria.
Esto podría ser simplemente se presenta en pequeñas fichas o historias - los
desarrolladores estimar el tiempo necesario para la puesta en práctica de cada
6
Conten ido
tarjeta. Así, los cambios de organización del trabajo en sí mismo tirando del
sistema : cada mañana durante una reunión de stand-up , cada miembro de las
revisiones del equipo de lo que se ha hecho ayer, lo que hay que hacer hoy y
mañana, y le pregunta por los insumos necesarios de sus colegas o el cliente.
Esto requiere transparencia del proceso, que es también beneficioso para la
comunicación del equipo. Otra idea clave en el sistema de Toyota es el conjunto
de desarrollo de productos basado en el diseño. Si un nuevo sistema de frenos es
necesario para un coche, por ejemplo, tres equipos pueden diseñar soluciones al
mismo problema. Cada equipo aprende sobre el espacio del problema y diseña
una solución potencial. Como una solución no se considera razonable, que se
corta. Al final de una época, los diseños 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 también pueden beneficiarse de esta práctica
para minimizar el riesgo provocado por grandes por adelantado de diseño.
Ha habido una creencia tradicional en la mayoría de las empresas acerca de la
toma de decisiones en la organización - los administradores de decirle a los
trabajadores cómo hacer su propio trabajo. En un Work-Out técnica, las funciones
se activan - los gerentes se les enseña 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 eliminación de los obstáculos, pero no de micro-gestión.
Otra creencia errónea ha sido la consideración de las personas como recursos .
Las personas pueden ser recursos desde el punto de vista de una hoja de datos
estadísticos, sino en el desarrollo de software , así como cualquier organización
empresarial, la gente necesita algo más que la lista de tareas y la garantía de que
no se verá afectado durante la realización de las tareas. Las personas necesitan
motivación y un propósito más elevado para trabajar - objetivo dentro de la
realidad accesible, con la garantía de que el equipo podría elegir a sus propios
compromisos. Los desarrolladores deben tener acceso al cliente, el líder del
7
Conten ido
equipo debe proporcionar apoyo y ayuda en situaciones difíciles, así como
garantizar que el escepticismo no arruina el espíritu de equipo.
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.
El cliente debe tener una experiencia global del sistema - esto es la integridad de
la llamada percepción: la forma en que se está anunciando, entrega, instalación,
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 podría lograrse
mediante la comprensión del dominio del problema y su solución al mismo tiempo,
no secuencialmente. La información necesaria se recibe en piezas de lotes
pequeños - no de una sola vez, con gran preferible cara a cara la comunicación y
no toda la documentación escrita. El flujo de información debe ser constante en
ambos sentidos - desde el cliente a los desarrolladores y la espalda, evitando así
la gran cantidad de información estresante después del desarrollo de largo en
forma aislada.
Una de las maneras saludables hacia la arquitectura integral es la refactorización .
Las características más se añaden a la del sistema, el más flojo de la base de
partida el código para futuras mejoras. Como se describió anteriormente en el
método de refactorización XP ágil se trata de mantener la simplicidad, la claridad,
la cantidad mínima de funciones en el código. Las repeticiones en el código de
señales para diseños de código mal y debe ser evitado. El proceso de
construcción completo y automatizado debe ir acompañada de una suite completa
y automatizada de los desarrolladores y pruebas de los clientes, tener el control de
versiones misma sincronización, y la semántica como el estado actual del sistema.
Al final de la integridad debe ser verificado con pruebas exhaustivas, asegurando
8
Conten ido
que el sistema hace lo que el cliente espera que lo haga. Las pruebas
automatizadas también se consideran parte del proceso de producción, 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
reducción de defectos.
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.
Los sistemas de software hoy en día no son simplemente la suma de sus partes,
sino también el producto de sus interacciones. Los defectos en el software tienden
a acumularse durante el proceso de desarrollo - por la descomposición de las
tareas grandes en tareas más pequeñas, y por la normalización de las diferentes
etapas de desarrollo, las causas de los defectos deben ser encontrados y
eliminados. Cuanto mayor sea el sistema, las organizaciones más que están
implicados en su desarrollo y las partes más 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
interactúan con suavidad. Durante un largo período de desarrollo, una red más
fuerte subcontratista es mucho más beneficioso que la optimización 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 situación.
"Pensar a lo grande, pequeño acto, no rápido, aprender rápidamente" - estas
consignas resumir la importancia de entender el campo y de la idoneidad de la
aplicación de principios de eficiencia a lo largo del proceso de desarrollo de
software. Sólo cuando todos los principios de eficiencia se implementan juntos,
combinado con un fuerte "sentido común" en relación con el entorno de trabajo,
hay una base para el éxito en el desarrollo de software .
Otra perspectiva
9
Conten ido
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
10
Conten ido
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.
Las Prácticas De Lean Software
Lean las prácticas 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
prácticas incluyen:
Ver a los residuos
Valor Stream Mapping
Establecer un desarrollo basado en
Tire de los sistemas de
Teoría de colas
Motivación
Las mediciones
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
11
Conten ido
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 Ventajas y Desventajas de Lean
Development (LD)
Como metodología en fin, esta presenta ventajas y desventajas como son:
12
Conten ido
Mapa Conceptual
13
LEAN DEVELOPMENT (LD)
CARACTERISTICASLAS PRÁCTICAS DE
LEAN SOFTWARE
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.
•Ver a los residuos•Valor Stream Mapping•Establecer un desarrollo basado en•Tire de los sistemas de•Teoría de colas•Motivación•Las mediciones
Lean Development (LD). Definida por Bob Charette.s 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.
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
DEFINICION
Conten ido
CUESTIONARIO
1. - ¿Por quién fue definida y cuándo?
R.- Lean Development (LD) fue definida por Bob Charette.s 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
2.- ¿Qué precepto tiene este proceso?
R.-. 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
3.- Nombra algunas características de Lean Development
R.- 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
4.- ¿Qué se puede decir de LD?
R.- 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
5.- ¿Cómo es el desarrollo de software?
R.- El desarrollo de software es un proceso continuo de aprendizaje, con el
desafío adicional de los equipos de desarrollo y tamaño 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 iteración cortos -
cada uno de ellos junto con refactorización y pruebas de integración.
.7.- ¿Qué puede ser aplicado a la producción?
R.- El justo a tiempo de la ideología de producción podría ser aplicado a desarrollo
de software, reconociendo sus necesidades específicas y el medio ambiente
8.- ¿Qué significa la integridad conceptual?
R.- La integridad conceptual significa que los conceptos del sistema trabajan como
una totalidad armónica de arquitectura coherente
14
Conten ido
9.- ¿Las pruebas automatizadas también se consideran parte del proceso?
R.- Las pruebas automatizadas también se consideran parte del proceso de
producción, 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 eliminación 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 decisión de los miembros del equipo que a su vez, crea un equipo más
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
cómo son excepcionales sus habilidades técnicas.
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 situación
15
Conten ido
BIBLIOGRAFIA
Análisis de Diseño de Sistemas.
http://www.adsfrank.blogspot.com/2007/06/metodologias-agiles-ld.html
http://www.strategosinc.com/principles.htmcarlos-reynoso-metodos-agiles-
academia.ppt. http://carlosreynoso.com
16