2.2.4 Metodologas giles en el Desarrollo de Software

Introduccin

En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas pretendieron ser las "balas de plata" para el xito en el desarrollo de software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la metodologa de desarrollo, haba sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas para su aplicacin. As, esta dcada ha comenzado con un creciente inters en metodologas de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado nfasis en el control del proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Por estar especialmente orientadas para proyectos pequeos, las metodologas giles constituyen una solucin a medida para ese entorno, aportando una elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto.

Las metodologas giles son sin duda uno de los temas recientes en ingeniera de software que estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Es tal su impacto que actualmente existen 4 conferencias internacionales de alto nivel y especficas sobre el tema1. Adems ya es un rea con cabida en prestigiosas revistas internacionales. En la comunidad de la ingeniera del software, se est viviendo con intensidad un debate abierto entre los partidarios de las metodologas tradicionales (referidas peyorativamente como "metodologas pesadas") y aquellos que apoyan las ideas emanadas del "Manifiesto gil"2. La curiosidad que siente la mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre las metodologas giles hace prever una fuerte proyeccin industrial. Por un lado, para muchos equipos de desarrollo el uso de metodologas tradicionales les resulta muy lejano a su forma de trabajo actual considerando las dificultades de su introduccin e inversin asociada en formacin y herramientas. Por otro, las caractersticas de los proyectos para los cuales las metodologas giles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeos, con plazos reducidos, requisitos voltiles, y/o basados en nuevas tecnologas.

El artculo est organizado como sigue. En la seccin 2 se introducen las principales caractersticas de las metodologas giles, recogidas en el Manifiesto y se hace una comparacin con las tradicionales. La seccin 3 se centra en eXtreme Programming (XP), presentando sus caractersticas particulares, el proceso que se sigue y las prcticas que propone. En la seccin 4 se citan otros mtodos giles, enumerndose sus principales caractersticas. Finalmente aparecen las conclusiones.

Ventajas/Desventajas de las metodologasgilesBueno, tras analizar las metodologas giles y la crtica realizada en la entrada anterior a la metodologa scrum, voy a enumerar y analizar las ventajas que tienen las metologas giles y, como no, tambin sus inconvenientes. La primera y la que, a mi parecer es la ms importante, es que estas metodologas ofrecen una rpida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como despus poder modificarlos evitando grandes prdidas en cuanto a costes, motivacin, tiempo El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolucin gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad. Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologas, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeo intervalo de tiempo un pequeo trozo del proyecto al cliente, y si ste quiere cambiarlo, solo se habr perdido unas semanas de trabajo. Con las metodologas tradicionales las entregas al cliente se realizaban tras la realizacin de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mnimo cambio que quiera realizar el cliente, conlleve la prdida de todo ese trabajo. Importancia de la simplicidad al eliminar trabajo innecesarioPero claro, aunque las ventajas sean muy apetecibles, estas metodologas tambin presentan inconvenientes que hay que asumir cuando se decide trabajar con ellas. Estos son: Falta de documentacin del diseo. Al no haber documentacin es el cdigo (junto con sus comentarios) lo que se toma como documentacin. Problemas derivados de la comunicacin oral. No hace falta decir que algo que est escrito no se puede borrar, en cambio, algo dicho es muy fcil crear ambigedad. Fuerte dependencia de las personas. Falta de reusabilidad derivada de la falta de documentacin Restricciones en cuanto a tamao de los proyectos 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.

METODOLOGAS GILESEn febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. S e pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas.

Tras esta reunin se cre The Agile Alliance3, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto gil, un documento que resume la filosofa gil.

El Manifiesto gil.Segn el Manifiesto se valora:

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.

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 e l xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. 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.VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo.VII. El software que funciona es la medida principal de progreso.VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante.IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. X. La simplicidad es esencial.XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos.XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

ComparacinLa Tabla recoge esquemticamente las principales diferencias de las metodologas giles con respecto a las tradicionales (no giles). Estas diferencias que afectan no slo al proceso en s, sino tambin al contexto del equipo as como a su organizacin.

PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)XP4 es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin 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 tcnico.Metodologas gilesMetodologas Tradicionales

Basadas en heursticas provenientes de prcticas de produccin de cdigoBasadas en normas provenientes de estndares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyectoCierta resistencia a los cambios

Impuestas intern amente (por el equipo)Impuestas externamente

Proceso menos controlado, con pocos principiosProceso mucho ms controlado, con numerosas polticas/normas

No existe contrato tradicional o al menos es bastante flexibleExiste un contrato prefijado

El clie nte es parte del equipo de desarrolloEl cliente interacta con el equipo de desarrollo mediante reuniones

Grupos pequeos (