Mtrica Versin 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Informacin sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos mximos y deber adaptarse y dimensionarse en cada momento de acuerdo a las caractersticas particulares de cada proyecto. La metodologa descompone cada uno de los procesos en actividades, y stas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, tcnicas, prcticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realizacin, ya que stas pueden realizare en orden diferente a su numeracin o bien en paralelo, como se muestra en los grficos de cada proceso. Sin embargo, no se dar por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. As los procesos de la estructura principal de Mtrica V3 son los siguientes: Planificacin de sistemas de informacin Desarrollo de sistemas de informacin Mantenimiento de sistemas de informacin
RUP La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el desarrollo del software: Inicio Elaboracin Construccin Transicin
Cada una de estas etapas es desarrollada mediante un ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes.
Caractersticas de RUP:
Es un proceso iterativo.- Permite considerar las variaciones de los requisitos. La integracin de los distintos elementos se realiza progresivamente. Permite disminuir los riesgos. Facilita la reutilizacin al identificar partes comunes. Permite una arquitectura ms robusta. Se puede autorefinar el proceso de desarrollo.
Gestiona los cambios en los requisitos.- Facilita el control de proyectos complejos. Mejora la calidad del software y la satisfaccin del cliente.
Se basa en las tcnicas de modelado propuestas por UML.
Persigue la calidad del producto y la calidad del proceso.
Contempla la gestin de configuracin y la gestin de cambios.
Es un proceso orientado por los casos de uso.
giles o Poco pesadas AGILES O POCO PESADAS XP (Extreme programming).-
No fue la primera metodologa ligera o gil, pero es de las ms conocidas por su acrnimo XP. Se ha mostrado como una metodologa muy efectiva en grupos de trabajo reducidos gracias a la baja complejidad, por este motivo, los detractores de metodologas giles, apuntan a problemas de escalabilidad en el uso de estos enfoques. XP elimina mucho trabajo superfluo, con lo que consigue mayor eficacia, sin embargo en grandes empresas, este trabajo extra es necesario para su correcto funcionamiento. Los elementos de XP son los siguientes: El juego de la planificacin (The Planning Game).- XP convierte la planificacin de un proyecto en un juego de negocio. Involucra a todo el equipo en la planificacin consiguiendo que la gente cooperativamente tome decisiones sobre su carga de trabajo, sus responsabilidades, y las consecuencias de alcanzar o no los objetivos. Todo este juego se realiza con historias que reflejan cada uno de los requisitos que necesita el cliente en un lenguaje natural y una estimacin del esfuerzo necesario. Estas historias se valoran por el beneficio empresarial del cliente y por su riesgo en el desarrollo. A partir de estos datos se gesta un plan de trabajo basado en iteraciones, donde cada una dar al cliente un producto con un conjunto de servicios priorizando su valor empresarial.
Pequeos estrenos.- La continua liberacin de versiones del software en pequeos incrementos es una caracterstica de todos los enfoques de giles en algn nivel. Esto conlleva varios beneficios: Demuestra que el grupo de trabajo est desarrollando su actividad. Puede proporcionar un valor real al cliente desde el principio, ayudando a compensar el costo del proyecto.
Debido a que las historias son ordenadas por prioridad, la tendencia es entregar las ms valiosas funciones al comienzo y, conforme progresa el desarrollo, perfila estas importantes funcionalidades a travs de las sucesivas, lo que hace ms probable que funcionen correctamente. El uso de una metfora.- Para facilitar que los desarrolladores entiendan el objetivo del sistema para el cliente, XP ofrece crear una metfora que explique con un ejemplo que hay que desarrollar. Diseo simple.- XP obliga a utilizar siempre el diseo ms simple que cumpla los requisitos actuales. En principio esto puede provocar que en futuras versiones se tenga que cambiar todo el diseo, por lo que XP define historias de extensin que indican futuros cambios seguros. Refactorizacin.- Esta es sin duda la parte ms difcil de XP. Con las nuevas iteraciones, la actual representacin de la base de conocimiento debe ser refactorizada o reestructurada para mantener representada todo el conocimiento que se genera en cada iteracin. El reto de modificar la estructura existente de un sistema de software para representar el total de la base de conocimientos es la filosofa del mantenimiento del software. El problema puede encontrarse en que la actual estructura de conocimiento contradice con la nueva que se genera. Pruebas.- La metodologa XP exige a una continua poltica de pruebas de todo el cdigo que se produce, as mismo, pruebas de integracin de cada nueva funcionalidad en el sistema y pruebas globales. Podemos decir que las pruebas tienen una alta importancia en XP. Programacin en parejas.- Es la caracterstica ms famosa de XP. Una persona sola es incapaz de ver sus fallos, por lo que XP recomienda que los trabajos se realicen en parejas, uno ejecuta la tarea y otro comprueba lo que est desarrollando.
Propiedad colectiva.- Adems de la programacin en parejas, XP ensalza la propiedad colectiva de todo el trabajo, incluyendo el cdigo. Integracin continua.- Los cortos ciclos, el desarrollo iterativo y la constante refactorizacin hacen necesario que todo el sistema se integre diariamente. Esto proporciona resultados diarios sobre las pruebas de integracin.
Limitacin de las horas de trabajo seminal.- Para mejorar el trabajo de los desarrolladores, las horas de trabajo a la semana deben estar limitadas. La motivacin y el cansancio del grupo de trabajo pueden hacer que el proyecto no se ejecute correctamente.
En el lado del cliente.- XP intenta romper con las barreras entre clientes y desarrolladores, acercndolos para mejorar su comunicacin. Para resolver los problemas del cliente, este debe estar motivado dentro del grupo de trabajo, as como el grupo de trabajo debe conocer bien el dominio del cliente. Estndares de cdigo.- XP tambin recomienda incluir estndares de cdigo.
Code Science Code Science es una variante del desarrollo de XP que aade, elimina y modifica algunos de los procesos de XP: Anlisis del proceso de negocio.- XP, como la mayora de las otras metodologas, asumen la disponibilidad de los requerimientos de negocio. Sin embargo, que pasa si el equipo no tiene acceso al cliente para responder a sus preguntas. Code Sciente aade un paso inicial en el que analiza el entorno de negocio y su situacin.
Estimaciones Delphi.- Adems del Juego de la planificacin se realiza una estimacin ms formal usando el enfoque Delphi. Esta aproximacin permite no solo estimar, sino aproximar a su varianza que permitir calcular los riesgos.
Arquitectura modular.- XP hace caso omiso de la arquitectura global del sistema a favor de la continua refactorizacin en los ciclos de desarrollo. Code Science toma algunos de los elementos esenciales de diseo ms clsico de los modelos de desarrollo para obtener una base de la arquitectura que ser ms estable.
Automatizacin del contrato y Pruebas de regresin. Code Science aade los contratos basados en la validacin automatizada, en especial para las pruebas de regresin, en el desarrollo y ciclo de pruebas de XP.
Historia de Actores y Requisitos Personalizados.- Adems de los requisitos tpicos de reunin de modalidades tales como casos de uso, Code Science emplea la idea de desarrollar requisitos personalizados. Estos son los requisitos que estn vinculados a una persona ficticia que se utiliza para interactuar con los requisitos. Esto refuerza la historia y permite a los desarrolladores interpolar y extrapolar los requisitos.
Wall GANTT.- El sistema de gestin de proyectos se ubica en un lugar pblico de la oficina donde se registra en un panel como van avanzando cada una de las tareas, cada da hay una reunin informal donde se discute el estado. De esta forma, todos los miembros de la organizacin conocen la totalidad del proyecto.
Generacin automtica de la documentacin.- Incluyendo documentacin a lo largo del cdigo, permite la generacin automtica de la documentacin del trabajo. Para ello todos los ficheros fuentes deben estar totalmente comentados.
Code Science permite otros ajustes como relajar el desarrollo de cdigo en parejas o permite que los trabajadores excedan las 40 horas semanales de trabajo modificar la metodologa para adaptarla a condiciones externas (trabajar para un organismo que las requiera). Crystals Los mtodos Crystals comparten con XP una orientacin humana, pero se centra en las personas de forma diferente. Explora una metodologa menos disciplinada cuyos principios se indican a continuacin:
Se centra en las personas en lugar de en los procesos: los procesos (herramientas, productos de su trabajo, etc.) slo existen para apoyar la capacidad de comprensin humana. Flexibilidad del mtodo: el mtodo debe adaptarse a los diferentes proyectos, no solo por lo que rodea a los proyectos, sino porque cada proyecto es en esencia diferente y puede requerir diferentes procesos.
Productos intermedios de trabajo puede reducirse en nmero, tamao y complejidad: el cdigo de prueba y el producto proporcionan un canal de comunicacin ms ricos que los documentos secundarios en papel.
El proyecto necesita menos control cuando cobra impulso. El desarrollo es cclico; tanto aprendizaje como produccin. La entrega del trabajo software se deber regular cada 2 o 3 meses. Participacin directa del cliente en el proyecto. Los productos de trabajo como: requisitos, casos de uso, pruebas de interfaz de usuario, modelado de objetos, etc. Se deja a la eleccin del grupo de trabajo, en funcin de la naturaleza del proyecto y de sus requerimientos. Adaptative Software Development La tcnica de Adaptive Software Development fue desarrollada por Jim Highsmith y Sam Bayer a comienzos de 1990 y queda referenciada en el libro Adaptive Software Development (Highsmith, 2000).
Al igual que otras metodologas giles, su funcionamiento es cclico y reconoce que en cada iteracin se producirn cambios e incluso errores. ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres componentes: Especular o explorar las opciones. Cclicamente colaborar utilizando una variedad de habilidades y capacidades del equipo para "crecer" la comprensin del sistema y de su solucin. Aprender o mejor extraer lo que se ha aprendido para permitir que los conocimientos se apliquen al sistema.
Estos componentes definen las siguientes actividades: Especular.- Una primera fase de iniciacin para establecer los principales objetivos y metas del proyecto en su conjunto y comprender las limitaciones (zonas de riesgo) con las que operar el proyecto.
Es ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin embargo, estas son necesarias para la correcta atencin de los trabajadores que se mueven dentro de plazos de forma que puedan priorizar sus tareas. Se decide el nmero de iteraciones para consumir el proyecto, prestando atencin a las caractersticas que pueden ser utilizadas por el cliente al final de la iteracin. Son por tanto necesarios, marcar objetivos prioritarios dentro de las mismas iteraciones. Estos pasos se puede volver a examinar varias veces antes de que el equipo y los clientes estn satisfechos con el resultado. Colaborar.- Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cclica. Un trabajo importante es la coordinacin que asegure que lo aprendido por un equipo se transmite al resto y no tenga que volver a ser aprendido por los otros equipos. Aprender.- La ltima etapa termina con una serie de ciclos de colaboracin, su trabajo consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crtico para la eficacia de los equipos.
Jim Highsmith identifica cuatro tipos de aprendizaje en esta etapa: Calidad del producto desde un punto de vista del cliente. Es la nica medida legtima de xito, pero adems, dentro de las metodologas giles, los clientes tienen un valor importante.
Calidad del producto desde un punto de vista de los desarrolladores. Se trata de la evaluacin de la calidad de los productos desde un punto de vista tcnico. Ejemplos de esto incluyen la adhesin a las normas y objetivos conforme a la arquitectura. La gestin del rendimiento. Este es un proceso de evaluacin para ver lo que se ha aprendido mediante el empleo de los procesos utilizados por el equipo. Situacin del proyecto. Como paso previo a la planificacin de la siguiente iteracin del proyecto, es el punto de partida para la construccin de la siguiente serie de caractersticas. Scrum Scrum fue desarrollado por Ken Schwaber y Jeff Sutherland y debidamente documentado en libro Agile Software Development with Scrum (Schwaber, 2001). Scrum se basa en ciclos de 30 das denominados Sprints, conformados por tres fases de planificacin, desarrollo y monitorizacin. Las tres etapas se denominan pre-Sprint, Sprint y Post-Sprint. Pre-Sprint.- Antes de iniciar esta fase es necesario definir el Product Backlog. Este documento es responsabilidad del cliente y en l comentar y priorizar las caractersticas del producto que necesite. A partir de los datos del cliente, en esta primera fase se realiza la planificacin de los elementos que esperan ser completados, tanto funciones del usuario y tecnologa como arquitectura del sistema.
Sprint.- En esta fase se ejecutan las tareas identificadas permitiendo que los grupos se gestionen de forma autnoma. Una caracterstica destacada es la reunin diaria scrum, una reunin informal donde se comenta sobre la planificacin y el progreso que tiene el proyecto. En ella deben intervenir todas las personas involucradas en el proyecto: desarrolladores y usuarios. Durante los ciclos Sprint no se permiten modificaciones de la funcionalidad del producto, para ofrecer a los grupos de trabajo un entorno estable. Post-Sprint.- Al final de cada ciclo se examinan los logros y deficiencias que se produjeron. Y por otro lado, el cliente comprueba la funcionalidad del producto provisional. Feature-Driven Development (FDD) Feature-Driven Development (FDD) fue desarrollado por Jeff De Luca y Peter Coad, para ejecutar un proyecto de un banco en Singapur a finales de 1990; antes el proyecto fue otorgado a una gran consultora que no lo finaliz, generando enormes cantidades de documentacin pero no de cdigo.
FDD est documentado en el libro A Practical Guide to Feature-Driven Development (Palmer, 2002).
FDD tiene un par de caractersticas distintivas que hacen que sea de gran inters:
Es uno de los pocos mtodos diseados a partir del desarrollo de un gran sistema, y muestra algunas de las cuestiones relativas a la escalabilidad. No est centrada en el cdigo como otros mtodos; los trabajos tambin se centran en realizar un modelado.
Por ltimo FDD utiliza un modelo de cinco etapas permitiendo cambios en el proyecto durante su desarrollo y como en otros mtodos giles, flexibilizando las fases.
Desarrollar un modelo general.- En esta primera etapa se desarrolla el modelado general del sistema sin entrar en detalles. Los detalles son pospuestos para fases posteriores. El propsito de esta etapa es crear una base para la planificacin del proyecto. Construir Caractersticas.- A partir del modelo y las prestaciones que necesita el cliente se genera la lista de caractersticas del sistema. Se utiliza un enfoque denominado arriba-abajo, donde se van descomponiendo las funciones solicitadas por el cliente. Plan de Reportaje.- El listado de caractersticas es utilizado por el equipo de planificacin de desarrollo para priorizarlas y definir las funcionalidades del sistema al finalizar cada ciclo. Diseo de Reportaje.- Conjuntos de caractersticas relacionadas se integran en paquetes que sern las unidades que despus se traducirn en cdigo. Construir por Caracterstica.- Cada equipo completa sus caractersticas asignadas implementando las clases y mtodos, escribiendo e inspeccionando el cdigo, generando pruebas, e integrando todo a nivel de sistema.
Rapid Application Development (RAD) Rapid Application Development (RAD) se desarroll como respuesta a los enfoques no giles de la dcada de 1970 como el modelo en cascada. El problema que mantienen los anteriores enfoques radica en el excesivo consumo de tiempo en definir las necesidades y cuando el sistema se desarrollaba quedaba obsoleto por posibles cambios. A partir de las ideas de Brian Gallagher, Barry Boehm y Scott Shultz, James Martin desarroll RAD en 1980 para IBM, formalizndolo en el libro Rapid Application Development (Martin, 1991). La metodologa se basa en el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo de aplicaciones con este enfoque implica compromisos en la facilidad de uso, funcionalidad y velocidad de ejecucin.
Es descrito como un proceso a travs del cual el ciclo de desarrollo de una aplicacin es acelerado, permitiendo productos de calidad que se desarrollarn ms rpido, ahorrando recursos.
diagrama de flujo de rad.
Algunas de sus ventajas son: Velocidad del desarrollo.- Los aumentos de la velocidad son debido al uso de la herramienta CASE. Calidad.- Segn lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios as como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicacin del usuario en las etapas del anlisis y del diseo.
Por contrapartida RAD tiene dos desventajas principales: Caractersticas reducidas. Escalabilidad reducida.- debido a que RAD se desarrolla con prototipos.
Dynamic Systems Development Method (DSDM) Este enfoque surgi a partir de Rapid Application Development (RAD). Cuenta con gran aceptacin en Europa y ha generado grupos de presin en EE.UU. Como su nombre indica, tiene la intencin de ser ms rpido y flexible que los mtodos tradicionales, y su incorporacin en la familia de mtodos giles indica que es capaz de aceptar los cambios. Hay nueve principios bases por los que opera DSDM: La participacin del usuario cliente es imprescindible. Los equipos de desarrollo estn facultados para la toma de decisiones. Entrega frecuente de versiones del producto al cliente. El valor y la aceptacin basan la aptitud para el negocio en lugar de una produccin mtrica. Desarrollo iterativo para converger en la mejor solucin para el negocio. Los cambios realizados durante el desarrollo pueden revertirse, si es necesario. Los requisitos base estn a un nivel alto, que implica un cierto grado de estabilidad de las necesidades durante el desarrollo. Los exmenes estn integrados en todo el ciclo de vida en lugar de ser una fase especfica. DSDM se produce en un entorno de colaboracin entre todos los interesados.
El enfoque DSDM tiene cuatro etapas (incluyendo un estudio de viabilidad), tres de las cuales son cclicas.
Estudio de Factibilidad.- Se desarrolla, bien antes del comienzo de un proyecto (si es nuevo) o entre los principales ciclos de desarrollo. Su propsito es el clsico trabajo de viabilidad para determinar el alcance del proyecto, de este modo, los proyectos que no son viables no se inician. Produce una lista inicial de necesidades funcionales priorizadas, que se usar en la fase de modelado funcional. Modelado funcional.- DSDM explcitamente utiliza un enfoque de prototipos, probando, refinando, y aproximando los requisitos del sistema en cada prototipo, en vez de utilizar documentacin pasiva en papel. Este ciclo se realiza con ciclos de revisin incorporados para comprobar el funcionamiento del prototipo. El xito del prototipo conduce la prxima fase. Diseo y Construccin.- Las fases de diseo y construccin pueden superponerse con otras fases; basan en los prototipos su actividad principal. Los prototipos pueden ser construidos o ampliados en la fase de modelado funcional y puede abordar cualquier aspecto (priorizados) del desarrollo: caractersticas, requisitos, funciones, interfaces, capacidad, rendimiento, etc. DSDM depende ms, o quizs ms especficamente, sobre los prototipos que otros enfoques. Aplicacin.- El final llega a partir de los prototipos de la fase de diseo y construccin con una mejora completa del funcionamiento, incluyendo los servicios adicionales necesarios para que el sistema sea operativo.
DSDM tiene algunas facetas interesantes como que gran parte de la documentacin se considera los propios prototipos. Tambin sugiere interesantes funciones para el director de proyecto y desarrollador. Ofrece distintos roles a los usuarios/clientes del sistema: Visionary.- Responsable de los objetivos del sistema a alto nivel. Ambassador.- Comprende los procesos de negocio. Advisor.- Se convierte en el asesor del equipo de desarrollo en el da a da.
Agile Unified Process (AUP) Scott Ambler centra todo su trabajo en la mejora de Rational Unified Process, ya en 1999 desarroll Enterprise Unified Process (EUP) que converta RUP en un verdadero ciclo de vida para el desarrollo de sistemas informticos. A partir de 2001 se intenta imprimir aspectos giles hasta que en 2005 se libera la primera versin de AUP. As Agile Unifed Process describe de forma simple y fcil la creacin de software funcional usando tcnicas giles y aplicando las mejores caractersticas de RUP. AUP aplica tcnicas comunes a otros enfoques giles como el diseo conducido por pruebas, desarrollo dirigido por modelos giles, gestin gil de los cambios, y tcnicas de refactorizacin de la base de datos para mejorar la productividad.
Como RUP, AUP define cuatro fases: Inicio.- Identifica el alcance inicial del proyecto, una posible arquitectura para el sistema, aborda la financiacin del proyecto y la aceptacin de las condiciones por los implicados en el proyecto.
Elaboracin.- Prueba la arquitectura del sistema. Construccin.- Construye el software sobre una base estable, las necesidades se van resolviendo de forma incremental comenzando por las de ms alta prioridad para los clientes del proyecto. Transicin.- Valida y despliegue del sistema en el ambiente de produccin.
tareas en cada fase de aup.
De forma diferente a como lo define RUP, AUP tiene solamente siete disciplinas: Modelo.- Entender el negocio del cliente, el dominio del problema que trata el proyecto, e identificar una solucin viable para tratar el problema. Puesta en prctica.- Transformar el modelo en cdigo ejecutable y realizar pruebas a un nivel bsico. Prueba.- Realizar una evaluacin objetiva para asegurar la calidad. Esto incluye encontrar defectos, validar que el sistema trabaja segn lo diseado, y verificar que los requisitos estn resueltos. Despliegue.- Plan para la entrega del sistema haciendo que est disponible para los usuarios. Gerencia de la Configuracin.- Manejar el acceso a los artefactos del proyecto. Esto incluye no solamente seguir versiones de los artefactos sino controlando los cambios que se producen en ellos. Gerencia del Proyecto.- Dirigir las actividades que ocurre dentro del proyecto. Esto incluye riesgos asumidos, direccin y coordinacin del personal (asignacin de tareas, seguimiento del proyecto, etc.), y gestin de los recursos externos para asegurar la entrega del producto dentro del tiempo y presupuesto.
Ambiente.- Apoyar el esfuerzo asegurando que el proceso, guas (estndares y pautas), y las herramientas apropiadas (hardware, software, etc.) esten disponibles para el equipo segn lo necesiten. AUP se basa en las siguientes filosofas: El personal sabe lo que est haciendo. El personal no va a leer una documentacin del proceso detallada, sino que prefieren una gua a alto nivel o un tiempo de entrenamiento. El producto AUP proporciona enlaces a muchos detalles que pueden ser vistos si se est interesado, pero es mejor no forzar a leerlos.
Simplicidad.- Se describe todo usando solo unas cuantas pginas, no millones de ellas. Agilidad.- AUP se conforma con los valores y los principios del desarrollo gil del software y de la alianza gil.
Foco de actividades de alto valor.- Centrarse en las actividades que van a suceder realmente, no a cada cosa posible de poder suceder en el proyecto. Independencia de la herramienta.- Se puede utilizar cualquier conjunto de herramientas con la metodologa AUP. La recomendacin es que se utilicen las herramientas que satisfacen lo mejor posible el trabajo, que son a menudo herramientas simples (como muchas soluciones de cdigo abierto).
Desear adaptar el AUP para resolver sus propias necesidades. Por ltimo, AUP distingue entre dos tipos de iteraciones:
lnea de tiempo para proyectos aup. Lean Development (LD) Lean Development (LD) se origin como un enfoque sobre gestin de Bob Charette, y trmino definido en el libro The Machine that Changed the World: The Story of Lean Production (Womack, 1991). Bob Charette se limita a tratar de acelerar el desarrollo, aumentando el riesgo, sin aumentar la capacidad equivalente para hacer frente al riesgo. LD identifica cuatro factores clave y doce principios. Los factores clave de xito son: Crear valor visible para el cliente rpidamente. Construir en vez de cambiar la tolerancia. Desarrollar slo la funcionalidad necesaria, Ser agresivos en la fijacin de objetivos. Los doce principios de LD son los siguientes: Satisfacer al cliente como la ms alta prioridad; no cumplir un plan, llenar un documento, satisfacer a un jefe, o construir algn tcnicamente muy avanzado. Mejorar el valor econmico. El valor es la diferencia entre el coste para la creacin y el valor de negocio que el sistema genera. La participacin activa del cliente como uno de los engranajes que trabaja en el proyecto; formar parte en la toma de decisiones del proyecto y sus consecuencias. Esfuerzo de equipo en todos los aspectos de desarrollo, incluida la planificacin.
Aceptar el cambio como parte de la empresa, anticipar lo que podra ocurrir, esperar que se produzcan, y ocuparse cuando se produzca. Desarrollar soluciones para un dominio y no para un determinado problema. Completar en lugar de construir. Comenzar con diseos base, utilizar lo que ofrezca el mercado, no iniciar la construccin desde cero. Solucin pragmtica de hoy en lugar de la solucin perfecta de maana. Los estudios han demostrado que gran parte de la funcionalidad del software sigue siendo no utilizada a veces aos despus de desarrollo. Impulsado por el primer principio de valor para el cliente, la solicitud anterior de algn valor es a menudo ms valiosa que la solicitud posterior de ms valor. Minimizar el papeleo, los gastos generales, material extra, por el exceso de comunicacin.
La necesidad determina la tecnologa en lugar de utilizar la tecnologa para alcanzar las necesidades. Elegir una tecnologa viable y usarla en lugar de seguir buscando la tecnologa perfecta. El crecimiento est determinado por un mayor nmero de funciones, no por ms cdigo. El tamao de cdigo puede ser irrelevante. Lo importante es lo que (por valor) el sistema puede proporcionar.
Usar Lean Development donde su funcionamiento sea bueno. Si bien el entorno empresarial es cada vez ms cambiante, y las necesidades de metodologas giles est creciendo, ninguno de estos enfoques es perfecto, garantiza el xito al 100 por ciento, est universalmente aceptado en todas las empresas, y no tiene esfuerzo. LD es una herramienta y al igual que otras herramientas, deben ser utilizadas con inteligencia.