1. En una reunion celebrada en febrero de 2001 en Utah-EEUU, nece el termino "agil" aplicado al desarrollo de software. En esta reunion participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologias de software. su objetivo fue esbozar los valores y pirncipios que deberian permitira los equipos desarrollar software rapidamente y respondiendo a los cambios que pueden sirgir a lo largo del poryecto. Se pretendia ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rigidos y dirigidos por la documentacion que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologias agiles ya estaban sindo utilizadas con exito en proyectos reales, pero les faltaba una mayor difusion y reconocimiento.
2. El Manifiesto Ágil.
2.1. El manifiesto comienza enumerando los principales valores del desarrollo agil.
2.1.1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
2.1.2. Desarrollar software que funcione mas que conseguir una buena documentacion.
2.1.3. La colaboracion con el cliente mas que la negociacion de un contrato.
2.1.4. Responder a los cambios mas que seguir extricamente un plan.
2.2. Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las caracteristicas que diferencian un proceso agil de uno tradicional. Los dos primeros son generales y resumen gan parte del espiritu aguil.
2.2.1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de sofware que le aporte un valor. Un proceso es ágil si a las pocas semadas de empezar ya entrega sofware que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar.
2.2.2. Dar la bienvenidad a los cambios. Se captura los cambios para que el cliente tenga una ventaja competivitva. Este principio es una actitud que deben adoprar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender mas a la vez que logran una mayor satisfaccion de lcliente. Este principio se aplica ademas que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. El paradigma ofientado a objetos puede ayudar a conseguir esta flexibilidad.
2.2.3. entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. Las entregas con el cliente se insiste en que sean software, no planificaciones, ni documentacion de analisis o diseño.
2.2.4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto, El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interaccion con el equipo es muy frecuente.
2.2.5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado
2.2.6. El dialogo cara a cara es el metodo mas frecuente y efectivo para comunicar informacion dentro de un equipo de desarrollo. Los miembros del equipo deben hablar entre ellos. Este es el prinicpal modo de comunicacion. Se pueden crear documentos pero no todo estara en ellos, no es lo que el equipo espera.
2.2.7. El software que funciona es la medida principal de progreso. el estado de un proyecto no viene dado por la documentacion generada o la fase en la que se encuentre sino por el codigo generado y en funcionamiento. Por ejemplo un proyecto se encuentra al 50% si el 50% de los requisitos ya estan en funcionamiento.
2.2.8. Los procesos aquiles primieven un desasrrollo sostenible. Lo promotores desarrolladores y usuarios deberian ser capaces de mantener una paz constante. No se trata de desarrollar lo mas rapido posible, sino de matener el ritmo de desarrollo durante toda la duracion del proyecto asegurando en todo momento dque la calidad de lo priducido es maxima.
2.2.9. La atencion continua a la calidad tecnica y el buen diseño mejora la aguilidad. Producir codigo claro y robusco es la clave para avanzar mas rapidadmente en el proyeco.
2.2.10. La simplicidad es escencial. Tomar los caminos mas simples que sean consistentes con los objetivos perseguidos. si el codigo producido es simple y de alta calidad sera mas sencillo adaptarlo a los cambios que pueden sirguir.
2.2.11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por si mismos. Todo el equipo es informado de las responsabilidades y estas recaen sobre todos sus mienbros. Es el propio equipo el que decide la mejor forma de organziarse. de acuerdo a los objetivos que se persigan.
2.2.12. En intervalos regulares el equipo reflexiona respecto a como llegar a ser mas efectivo y segun esto ajusta su comportamiento. Puesto que el enterno esta cambiando continuamente el equipo tambien debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organizacion. sus reglas, sus convenciones sus relaciones, etc. para seguir siendo aguil.
3. Ejemplos de metodologias Ágiles
3.1. SCRUM4 Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.
3.2. Crystal Methodologies. se trara de un conunto de metodologias para el desarrollo de software caracterizadas por estar centralizads en las las personas que componen el equipo( de ellas depende el exito del proyecto) y la reduccion al maximo del numero de artefactos producicos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros)
3.3. Dynamic Systems Development Method6 (DSDM) Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.
3.4. Adaptive Software Development7 (ASD). Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.
3.5. Feature-Driven Development8 (FDD). Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad
3.6. 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
3.7. Extreme Programming es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
4. Ventajas
4.1. Simplificación de la sobrecarga de procesos
4.2. Calidad mejorada
4.3. Mejorar la previsibilidad a través de una mejor gestión del riesgo
4.3.1. Dar prioridad a los riegos
4.3.2. Evaluación de riesgos en paralelo
4.4. Mejor perfil de productividad
4.5. Capacidad para aprovechar las inversiones realizadas
4.5.1. Los requerimientos que la impulsan.
4.5.2. La arquitectura bajo desarrollo.
4.5.3. El software de la solución
4.5.4. Las pruebas que validan la solución.