La definicin moderna de desarrollo gil de software evoluciono ha mediado de los aos 1990 como parte de una reaccin contra

los mtodos de peso pesado, muy estructurados y estrictos, extrados del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrtico lento, degradante e inconsistente con la forma de desarrollo de software que realmente utilizaban un trabajo eficiente

En la dcada de los 90 surgi un enfoque revolucionario para su momento ya que iba en contra de toda creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo costo y con la requerida calidad En la comunidad de ingeniera de software conocido como RAD o aplicacin rpida de desarrollo Entorno de desarrollo altamente productivo Grupos pequeos de programadores Herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel

Metodologas livianas dieron paso al termino agiles considerada por muchos como meramente intuitiva en febrero de 2001 nace formalmente el termino gil aplicado al desarrollo

Un proceso es gil cuando el desarrollo de software es:

Incremental. Entregas pequeas de software, con ciclos rpidos.

Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin.

Sencillo. El mtodo en s mismo es simple, fcil de aprender y modificar.

Est bien documentado y es adaptable. Permite realizar cambios de ltimo momento. Sus elementos claves son:

Poca documentacin. Simplicidad. Anlisis como una actividad constante. Diseo evolutivo. Integraciones. Testeos diarios. Las propias prcticas de los mtodos giles limitan o descartan su uso en algunos proyectos. A continuacin se detallan algunos casos donde no conviene usar mtodos giles.

Aplicaciones distribuidas. Las pruebas unitarias son complicadas de aplicar entre componentes. Sera necesario construir una arquitectura de pruebas para probar directamente los componentes, que podra ser tan complicada como el sistema que se desea construir.

Aplicaciones que requieren seguir un diseo estricto. Por ejemplo: sistemas operativos, software de

telecomunicaciones.

Aplicaciones que requieren una documentacin exhaustiva. Por ejemplo: sistemas militares, mdicos o industriales.

Aplicaciones basadas fundamentalmente en interfaces grficas de usuario: No es fcil aplicar pruebas unitarias a las interfaces grficas.

Aplicaciones con cdigo heredado. Habra que reescribir todo el cdigo heredado siguiendo los principios giles.

Proyectos muy grandes. La comunicacin entre los miembros del equipo es difcil de conseguir.

Proyectos escritos en lenguajes no orientados a objetos. Lenguajes como C, Pascal, Cobol o Fortran hacen imposible tcnicas como la refactorizacin.

Aplicaciones donde la escalabilidad o la eficacia sean importantes. La escalabilidad o la eficacia no son caractersticas que se pueden aadir durante el proceso del desarrollo del software o que puedan obtenerse refactorizando: deben considerarse desde un principio.

Las metodologas giles presentan diversas ventajas como:

Rpida respuesta a cambios de requisitos a lo largo del desarrollo.

Entrega continua y en plazos cortos de software funcional.

Trabajo conjunto entre el cliente y el equipo de desarrollo.

Minimiza los costos frente a cambios.

Importancia de la simplicidad, al eliminar el trabajo innecesario.

Atencin continua a la excelencia tcnica y al buen diseo.

Mejora continua de los procesos y el equipo de desarrollo.

Evita malentendidos de requerimientos entre el cliente y el equipo.

El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente.

Cada componente del producto final ha sido probado y satisface los requerimientos.

Como en cualquiera otra metodologa, tambin hay desventajas y problemas que surgen a la hora de implementarlas:

Falta de documentacin del diseo. El cdigo no puede tomarse como una documentacin. En sistemas de tamao grande se necesitar leer los cientos o miles de pginas del listado de cdigo fuente. Problemas derivados de la comunicacin oral. Este tipo de comunicacin resulta difcil de preservar cuando pasa el tiempo y est sujeta a muchas ambigedades. Falta de calidad. Probar el cdigo de forma constante no genera productos de calidad, slo revela falta de anlisis y diseo. Fuerte dependencia de las personas. Como se evita en lo posible la documentacin y los diseos convencionales, los proyectos giles dependen crticamente de las personas. Falta de procesos de revisin del cdigo. Con mtodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programacin en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador. Falta de reusabilidad. La falta de documentacin hacen difcil que pueda reutilizarse el cdigo gil. Sobre costos y retrasos derivados de la refactorizacin continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorizacin no pueden despreciarse. Restricciones en cuanto a tamao de los proyectos abordables. Rigidez. Algunos mtodos giles son muy rgidos: deben cumplirse muchas reglas de una forma estricta para garantizar el xito del proyecto. Por ejemplo XP exige en realidad mucho esfuerzo, concentracin y orden. Cambios. Los modelos de datos son pesados y no pueden cambia rse as como as solo porque el cliente que ira incorporar ms funciones al sistema. Problemas derivados del fracaso de los proyectos giles. Si un proyecto gil fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el diseo. La comprensin del sistema se queda en las mentes de los desarrolladores.