UNIVERSIDAD AUTONOMA DE NUEVO LEON FACULTAD DE CONTADURIA PBLICA Y ADMINISTRACION, POSGRADO

INGENIERIA DE SOFTWARE

DESARROLLO AGIL
Alumnos: Lic. Ral Enrquez Chvez Lic. Alfredo Garca Corpus

Maestra: Dra. Maria de Jess Araiza Vzquez Octubre 8, 2011

NDICE

ndice
1. Metodologa gil 2. Programacin Extrema (XP; Extreme Programming) a. Definicin b. Proceso de Desarrollo 3. SCRUM, Ciclos de desarrollo. a. Caractersticas b. Proceso 4. Metodologa Crystal a. Qu es Crystal Clear? b. Caractersticas c. Tcnicas 5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) a. Fases b. Nueve Principios del DSDM 6. Desarrollo de Sistemas Adaptivos (ASD) a. Definicin b. Ciclo de Vida Especular-ColaborarAprender c. Fases del Proyecto 7. Desarrollo basado en Funcionalidades (FDD) a. Definicin b. Ciclo de Vida c. Ventajas 8. Desarrollo Lean (LD) a. Fundamentos b. 7 Principios del desarrollo Lean 9. Conclusiones

1. Metodologa gil La historia de las Metodologas giles y su apreciacin como tales en la comunidad de la ingeniera de software tiene sus inicios en la creacin de una de las metodologas utilizada como arquetipo: XP - eXtreme Programming. XP surge de la mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham, y utilizando conceptos como el de Chief Programmer creado por IBM en la dcada de los 70. A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad.

1. Metodologa gil El enfoque fue planteado por primera vez por [Martin, 1991] y se dio a conocer en la comunidad de ingeniera de software con el mismo nombre que su libro, RAD o Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo

1. Metodologa gil Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interaccin por encima El software que funciona La colaboracin con el cliente La respuesta al cambio por encima por encima por encima

de los procesos y las herramientas de la documentacin exhaustiva la negociacin contractual seguimiento de un plan

Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda

Kent Beck, Mike Beedle, Arievan Bennekum, AlistairCockburn, Ward Cunningham, Martin Fowler, James Grenning, JimHighsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, DaveThomas

1. Metodologa gil Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental.

1. Metodologa gil La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito.

Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.

1. Metodologa gil

1. Metodologa gil

2. Programacin Extrema (XP; Extreme Programming)

a. Definicin La Programacin Extrema (PX), mejor conocida por su nombre en ingls Extreme Programming (XP), es una de las llamadas Metodologias Agiles de desarrollo de software ms exitosas de los tiempos recientes.

La programacin extrema es una metodologa de desarrollo ligera (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programacin.

2. Programacin Extrema (XP; Extreme Programming)

b. Proceso de Desarrollo El juego de Planeamiento: Rpidamente determinar el alcance del prximo release mediante la combinacin de prioridades del negocio y estimaciones tcnicas. A medida que la realidad va cambiando el plan, actualizar el mismo. Pequeos Releases: Poner un sistema simple en produccin rpidamente, luego liberar nuevas versiones en ciclos muy cortos. Metfora: Guiar todo el desarrollo con una historia simple y compartida de cmo funciona todo el sistema. Diseo Simple: El sistema deber ser diseado tan simple como sea posible en cada momento. Complejidad extra es removida apenas es descubierta. Testing: Los programadores continuamente escriben pruebas unitarias, las cuales deben correr sin problemas para que el desarrollo contine. Los clientes escriben pruebas demostrando que las funcionalidades estn terminadas. Refactoring: Los programadores reestructuran el sistema sin cambiar su comportamiento para remover duplicacin, mejorar la comunicacin, simplificar, o aadir flexibilidad.

2. Programacin Extrema (XP; Extreme Programming)

b. Proceso de Desarrollo Programacin de a Pares: Todo el cdigo de produccin es escrito por dos programadores en una mquina. Propiedad Colectiva del Cdigo: Cualquiera puede cambiar cdigo en cualquier parte del sistema en cualquier momento. Integracin Continua: Integrar y hacer builds del sistema varias veces por da, cada vez que una tarea se completa. Semana de 40-horas: Trabajar no ms de 40 horas semanales como regla. Nunca trabajar horas extras durante dos semanas consecutivas.

Cliente en el lugar de Desarrollo: Incluir un cliente real en el equipo, disponible de forma full-time para responder preguntas.
Estndares de Codificacin: Los programadores escriben todo el cdigo de acuerdo con reglas que enfatizan la comunicacin a travs del mismo.

2. Programacin Extrema (XP; Extreme Programming)

2. Programacin Extrema (XP; Extreme Programming) Conclusin: Extreme Programming es una disciplina de desarrollo de software basado en los valores de la simplicidad, la comunicacin, la retroalimentacin y valenta. Funciona al llevar todo el equipo reunido en la presencia de prcticas simples, con suficiente informacin para que el equipo para ver dnde estn y para ajustar las prcticas a su situacin particular.

3. SCRUM, Ciclos de desarrollo. a: Caractersticas Scrum define un proceso emprico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge de un artculo de 1986 de la Harvard Business Review titulado The New New Product Development Game de Takeuchi y Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995.

3. SCRUM, Ciclos de desarrollo.

3. SCRUM, Ciclos de desarrollo.

Conclusiones: La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede ser combinado con cualquiera de las metodologas mencionadas.
http://www.youtube.com/watch?v=EF-duw7-nOY&feature=related

4. Metodologa Crystal a. Qu es Crystal Clear? En los inicios de 1990, en un estudio realizado en IBM se lleg a los siguientes acuerdos (Cockburn, 2001). Los equipos exitosos enfatizaban que no haban seguido mtodos formales ni herramientas CASE y que haban estimulado la comunicacin y los test. Los equipos con problemas no entendan sus fallas o si haban cumplido con los mtodos formales. Crystal Clear no es una metodologa en si misma sino una familia de metodologas con un cdigo gentico comn. El nombre Crystal deriva de la caracterizacin de los proyectos segn 2 dimensiones, tamao y complejidad (como en los minerales, color y dureza).

4. Metodologa Crystal

b. Caractersticas Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son: Aspecto humano del equipo Tamao de un equipo (nmero de componentes) Comunicacin entre los componentes Distintas polticas a seguir Espacio fsico de trabajo

4. Metodologa Crystal

b. Caractersticas Crystal Clear se corresponde con el color Blanco en la codificacin de colores de Crystal 3 8 personas

Crystal Orange se corresponde con el color Naranja en la codificacin de colores de Crystal 25 50 personas

3-8

10-20

25-50

50-100 100-200 200-500

800+

4. Metodologa Crystal

4. Metodologa Crystal b. Caractersticas 1) Entrega frecuente. Consiste en entregar software a los clientes con
2) frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal o mensual. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseador senior y discutir respecto del tema que se trate. Mejora reexiva. Tomarse un pequeo tiempo (unas pocas horas cada o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reexionar, discutir. Seguridad personal. Hablar con los compaeros cuando algo molesta dentro del grupo. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Fcil acceso a usuarios expertos. Tener alguna comunicacin con expertos desarrolladores.

3)

4) 5) 6)

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM)

Mtodo de Desarrollo De Sistemas Dinmicos (DSDM) es un proceso organizado centrada en proporcionar soluciones de negocio de forma rpida y eficiente. Es similar en muchos aspectos a SCRUM y XP, pero tiene sus mejores usos para los cuales se fija el tiempo requerido.

DSDM se centra en la entrega de la solucin de negocio, y no slo la actividad del equipo. Tiene las medidas necesarias para garantizar el sentido de viabilidad y de negocios de un proyecto antes de que se crea. Hace hincapi en la cooperacin y colaboracin entre todas las partes interesadas. DSDM hace un uso intensivo de creacin de prototipos para asegurarse de que las partes interesadas tengan una imagen clara de todos los aspectos del sistema.

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Nueve Principios

1. El involucramiento del usuario es imperativo. 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco est puesto en la entrega frecuente de productos. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados a un alto nivel. 8. El testing es integrado a travs del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Proceso DSDM

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 1. Estudio de Factibilidad - Averiguar si y cmo el proyecto se
resolver.
Se puede hacer dentro de las limitaciones de tiempo y recursos? Esta fase se lleva a cabo lo ms rpidamente posible, porque DSDM es la mejor opcin donde el tiempo es corto, y por lo tanto, el producto debe ser entregado rpidamente.

2. Estudio de Negocios - Estudiar los aspectos comerciales del proyecto.

Tiene sentido un buen negocio? Quines son los participantes y las partes interesadas? Cul es el mejor plan de trabajo? Lo que se necesita para: Construirlo Probarlo Implementarlo Mantenerlo Qu tecnologas se utilizarn para construir e implementarlo?

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 3. Modelo Funcional
En esta etapa, los prototipos funcionales del sistema se hacen y se revisan. Un prototipo funcional es un prototipo de las funciones que el sistema debe realizar y cmo debe llevarlas a cabo. Prototipos cubren diferentes aspectos del sistema: Empresas Usabilidad - qu tan fcil es usarlo? El rendimiento y la capacidad - puede manejar el volumen y frecuencia de uso que va a recibir? Tcnica - Cul es la mejor manera de ocuparse de resolver el problema?

4. Disear y Construir.
En esta etapa, el producto es diseado y desarrollado en las iteraciones. En cada iteracin una parte del modelo de diseo se estn desarrollando, y luego se codifica y revisa.

5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 5. Implementar y Mantener
En la ltima fase, el producto se implementa, se escribe la documentacin y se elabora un documento de revisin comparando los requisitos con lo cumplido con en el producto. Los usuarios son capacitados en el uso del sistema y los usuarios dan su aprobacin al sistema. Despus de que el producto es creado, el mantenimiento, inevitablemente, tendr que llevarse a cabo. Este mantenimiento se hace generalmente en un ciclo similar al utilizado para desarrollar el producto.

6. Desarrollo de Sistemas Adaptivos (ASD)

El Desarrollo de Sistemas Adaptivos fue propuesto por Jim Highsmith como una metodologa para desarrollar software y sistemas muy complejos. ASD consiste en un cambio de filosofa en las organizaciones pasando de la transicin del modelo Comando-Control al modelo Liderazgo-Colaboracin El ciclo de vida del ASD se conforma de 3 fases: Especular-Colaborar-Aprender

6. Desarrollo de Sistemas Adaptivos (ASD) Las 3 Fases del ASD 1. Especulacin

Se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se irn realizando. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no ser el lugar en que finalizar el proyecto. Sin embargo, no es ms que una especulacin ya que el carcter adaptativo del proceso permite pequeas desviaciones en un sentido por lo que Highsmith sugiere que cada ciclo se componga de un mix entre funcionalidades crticas, tiles, y opcionales, previendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro.

6. Desarrollo de Sistemas Adaptivos (ASD) Las 3 Fases del ASD 2. Colaborar

Es aquella en la que se construye la funcionalidad definida durante la especulacin. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteracin el equipo colabora intensamente para liberar la funcionalidad planificada. Tambin, existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente.

6. Desarrollo de Sistemas Adaptivos (ASD) Las 3 Fases del ASD 3. Aprender

Consiste en la revisin de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender: Calidad del resultado de la desde la perspectiva del cliente Calidad del resultado de la desde la perspectiva tcnica El funcionamiento del equipo de desarrollo y las prcticas que este utiliza El status del proyecto Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre la calidad de los mismos. En este caso, el nfasis estar puesto en aprender cuales han sido los errores o desvos y poder resolverlos, y no en encontrar culpables. Asimismo, est es la etapa en que se evaluarn las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algn camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos.

6. Desarrollo de Sistemas Adaptivos (ASD)

ASD y las metodologas giles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender ms respecto al dominio y construir la aplicacin que mejor satisfaga las necesidades del cliente. Highsmith lo expone claramente en la siguiente frase: En ambientes complejos, el seguir un plan al pie de la letra produce el producto que pretendamos, pero no el producto que necesitamos.

7. Desarrollo Basado en Funcionalidades (FDD)

Es un modelo de proceso prctico para la ingeniera del software orientada a objetivos. Es aplicado en proyectos de software de tamao moderado y grande. Para la metodologa una caracterstica es una funcin validad por el cliente y que puede ser implementada el dos o menos semanas. La definicin de estas caractersticas permite a la metodologa poseer los siguientes beneficios: Las caractersticas son pequeos bloques de funcionalidad entregables, los usuarios las describen con mayor facilidad, permitindoles revisarlas de mejor manera en bsqueda de errores u omisiones. Las caractersticas pueden ser agrupadas por orden jerrquico relacionado con el negocio. La caracterstica es el incremento del software entregable, as que el equipo desarrolla caractersticas operativas cada dos semanas. La planificacin del proyecto lo gua la jerarqua de la caracterstica, en lugar de hacerlo un conjunto de tareas de la ingeniera de software adaptado en forma arbitraria

7. Desarrollo Basado en Funcionalidades (FDD)

El FDD concede una mayor importancia a las directrices y tcnicas de la gestin del proyecto que muchos otros mtodos giles, ya que enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacin del progreso. Se encuentra definido por cinco fases o actividades . Desarrollar un modelo general Elaborar una lista de caractersticas Plan por caracterstica Diseo por caracterstica Construccin por caracterstica

7. Desarrollo Basado en Funcionalidades (FDD) Desarrollo de un modelo general

Se tiene el dominio de la visin, el contexto y los requerimientos del sistema a construir. En este momento se posee informacin bsica de las especificaciones funcionales.

Elaboracin de la lista de caractersticas, Los ensayos, modelos de

objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de caractersticas.

Plan por caracterstica

Las funciones se agrupan conforme a diversas actividades en reas de dominio especficas. La lista de caractersticas es revisada por los usuarios para asegurar su validez y exhaustividad.

Diseo y Construccin por caracterstica

Se selecciona las caractersticas a desarrollar y los equipos dispuestos por cada una de ellas. Luego se procede iterativamente hasta que se producen las caractersticas seleccionadas.

8. Desarrollo Lean (LD)

El Desarrollo de Software Lean tiene sus inicios en el Sistema de Produccin de Toyota (TPS) y ayuda a las organizaciones de software a optimizar sus procesos y sus mtodos de produccin de manera de poder entregar sus productos al mercado de manera ms rpida y con mejor calidad. El movimiento Lean puede considerarse como un nuevo mtodo de desarrollo que intenta identificar y erradicar todos los problemas y "desventajas" de metodologas antiguas, como Cascada. Lean hace nfasis en las personas y la comunicacin - si se respeta a las personas que producen software y se pueden comunicar de forma eficiente, es ms probable que logren entregar un buen producto y satisfacer al consumidor final.

8. Desarrollo Lean (LD)

Los 7 Principios de Lean

1. Eliminar el desperdicio
Brindar un liderazgo tcnico y de mercado - la organizacin puede ser exitosa si produce productos innovadores y tecnolgicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnologa que se est usando.

Crear solamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son tiles y estn enfocados en crear valor.
Escribir menos cdigo - mientras ms cdigo se tenga, ms pruebas se van a necesitar, por lo que se necesitar ms trabajo. Si escribiramos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.

8. Desarrollo Lean (LD)

Los 7 Principios de Lean

2. Crear conocimiento
Crear equipos de diseo y construccin - el lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los insite a buscar respuestas y volver lo ms pronto posible con los problemas que surgen, o con las soluciones inventadas.

Mantener una cultura de mejora continua - crear un ambiente en donde las personas estn mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algn rea que pueden mejorar.
Ensear mtodos de resolucin de problemas - los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.

8. Desarrollo Lean (LD)

Los 7 Principios de Lean

3. Construir la calidad
Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de l antes de empezar a escribir una sola lnea de cdigo. Automatizar - automatizar las pruebas, la construccin, las instalacionoes, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualqueir cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactor - eliminar la duplicacin de cdigo a CERO - cada vez que aparezca la oportunidad, realizar el refactor del cdigo, de las pruebas y de la documentacin para minimizar la complejidad.

8. Desarrollo Lean (LD)

Los 7 Principios de Lean

4. Postergar el compromiso
Agendar las decisiones irreversibles hasta el ltimo momento responsable debemos saber hacia donde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo da a da - lo ms importante es mantener la direccin correcta. Romper con las dependencias - los componentes deben estar lo ms desacoplados posible para que puedan implementarse en cualquier orden. Mantener opciones - desarrollar mltiples soluciones para todas las decisiones crticas y ver cuales funcionan mejor.

5. Optimizar el total
Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera completa (que es el software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y optimizar a la organizacin en su totalidad.

Entregar un producto completo - los equipos necesitan tener buenos lderes, y tambin buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.

8. Desarrollo Lean (LD) 6. Entregar rpido

Trabajar en bloques pequeos - reducir el tamao del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo (escucha lo que te dice la velocidad), repetir lo bueno y erradicar las prcticas que crean obstculos. Limitar el trabajo a la capacidad - limitar la cola de tareas al mnimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola - rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. Enfocarse en el tiempo del ciclo, no en la utilizacin - agregar tareas pequeas a la cola que no puedan atascar al proceso por un tiempo largo - reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola

7. Respetar a las personas

Capacitar a los lderes de equipo - darles a los lderes de equipo entrenamiento, guas y espacio libre para implementar el pensamiento Lean en su ambiente.
Mover la responsabilidad y la toma de decisiones al nivel ms bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cmo implementar algoritmos difciles y aplicar tecnologas de ltima generacin. Fomentar orgullo por el trabajo - fomentar la pasin y la participacin del equipo hacia lo que hacen y cmo lo hacen

9. CONCLUSIONES Las metodologas giles surgen como respuesta a problemas reales. Se basan en el sentido comn, pero rompen con creencias arraigadas. Pero la metodologa perfecta no existe. Se estn extendiendo con rapidez. Son aplicables al mundo del software libre? Se enfocan en la colaboracin y en el aprendizaje.