Metodologías para el desarrollo ágil del software.
Actualmente los negocios operan en un entorno global que cambia rápidamente. Tienen que responder a nuevas oportunidades y mercados, condiciones económicas cambiantes y la aparición de productos y servicios competidores. El software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el software nuevo se desarrolle rápidamente para aprovechar nuevas oportunidades y responder a la presión competitiva. Actualmente el desarrollo y entrega de manera rápida son los requerimientos más críticos de los sistemas. De hecho, muchas organizaciones están dispuestas a obtener una pérdida en la calidad del software y en el compromiso sobre los requerimientos en favor de una entrega rápida del software.
Los procesos de desarrollo del software basados en una completa especificación de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el diseño o implementación del sistema se tiene que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el tiempo un proceso en cascada convencional y el software definitivo se entrega mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando esté disponible el software, la razón original de su adquisición puede ser que haya cambiado de forma radical que en realidad éste sea inútil. Dicha metodología combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental, equipos pequeños con alta motivación, métodos informales y una simplicidad general del desarrollo. Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.
En los años 80 y principios de los 90, existía una opinión general de que la mejor forma de obtener un software de calidad era a través de una planificación cuidadosa del proyecto y de la utilización de métodos de análisis y diseño soportados por herramientas CASE (Computer Aided Software Engineering). Esta opinión venía fundamentalmente de la comunidad de ingenieros de software implicado en el desarrollo de grandes sistemas y que normalmente se componían de un gran número de programas individuales. Este software era desarrollado por grandes equipos que trabajaban para compañías diferentes y que a menudo estaban dispersos geográficamente y trabajaban durante largos periodos de tiempo.
Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeños y de tamaño medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso de desarrollo del software, es decir, se pasaba más tiempo pensando en cómo se debía desarrollar el sistema que en cómo programar el desarrollo y cómo hacer las pruebas pertinentes. El descontento de esto produjo que varios desarrolladores propusieran nuevos métodos que eran más ágiles. Aunque estos métodos se basan principalmente en la noción del desarrollo y en las entregas incrementales, proponen procesos diferentes para alcanzar el objetivo.
En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término «ágil» aplicado al desarrollo de software. En esta reunión participan un grupo de diecisiete expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos a desarrollar software rápidamente y respondiendo a los cambios que podrían surgir a lo largo de los proyectos. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento. Tras esta reunión se creó “The Agile Alliance” (2001), una organización, 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 fue el manifiesto ágil, un documento que resume la filosofía «ágil». A continuación en la tabla 2.8, vamos a enumerar las principales diferencias de una Metodología Ágil respecto a las Metodologías Tradicionales (llamadas peyorativamente “no ágiles” o “pesadas”). Estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.
Si bien la idea de participación del cliente en el proceso de desarrollo es atractiva, el éxito dependerá de tener un cliente que esté dispuesto y lo más importante pueda pasar tiempo con el equipo de desarrollo para así presentar a todos los implicados del sistema, los clientes están sometidos a otras presiones y no pueden participar plenamente en el desarrollo del software. El cliente es el punto clave, solicita los requerimientos que se deben de incluir. Los miembros individuales del equipo puede no tener la personalidad propia para una participación intensa. Por lo tanto, es posible que no se relacionen adecuadamente con los otros miembros del equipo. Priorizar los cambios puede ser extremadamente difícil, específicamente en sistemas en los que existen muchos implicados.
Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presión por las agendas de entregas, los miembros del equipo no pueden tener a tiempo las especificaciones del sistema. Por consiguiente los métodos ágiles tienen que depender de contratos donde el cliente paga por el tiempo necesario para el desarrollo del sistema en lugar de por el desarrollo de un conjunto de requerimientos específicos. Siempre y cuando el proyecto vaya caminando en forma, esto beneficiará tanto al cliente como al desarrollador. Todos los métodos tienen límites y los métodos ágiles son apropiados para algunos tipos de desarrollo de sistemas. Son los más idóneos para el desarrollo de sistemas para pequeños negocios y medianas empresas. No son adecuados para el desarrollo de sistemas a gran escala con equipos de desarrollo situados en diferentes lugares geográficamente hablando ya que puede haber complejas interacciones con otros sistemas o hardware.
Los métodos ágiles no se deben de utilizar para el desarrollo de sistemas críticos en los que es necesario generar un análisis detallado de todos los requerimientos del sistema para así comprender mejor sus implicaciones de seguridad o de protección. El crecimiento de los métodos ágiles y su penetración ocurre a un ritmo pocas veces visto en la industria: en tres o cuatro años, según el Cutter Consortium, el 50% de las empresas define como “ágiles” más de la mitad de los métodos empleados en sus proyectos (Charette, 2004). Algunas de las metodologías agiles mas usadas en la actualidad se describen a continuación.
La participación del cliente se lleva a cabo a través del compromiso y del tiempo completo del cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan en el desarrollo y son los responsables de definir las pruebas necesarias que servirán para la aceptación del sistema. El interés de las personas, en vez de los procesos, se lleva a través de la programación en parejas, la propiedad colectiva del código y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua. El mantenimiento se lleva a cabo a través de una recta actualización constante para mejorar la calidad del código y la utilización de diseños sencillos que no prevén cambios futuros en el sistema.
En XP, los clientes están implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema. Dichos requerimientos no se especifica como una lista de funciones requeridas en el sistema. Más bien, los clientes del sistema son parte fundamental del equipo de desarrollo esto permite que discutan escenarios con todos los miembros del equipo. Desarrollar conjuntamente tarjetas de historia (story card) que recogen las necesidades del cliente. Por ende el equipo de desarrollo intentará implementar esos escenarios en una entrega futura del software. Un punto fundamental en la ingeniería del soporte tradicional es que se debe de diseñar para futuros. Esto es que se deben de prever los cambios futuros y diseñar éste de forma que tales cambios se puedan implementar fácilmente. La metodología XP ha descartado este principio partiendo del hecho de que diseñar para el cambio es a menudo un esfuerzo inútil. Con frecuencia los cambios previstos nunca se materializa y realmente se efectúan peticiones de cambios completamente diferentes. La metodología extrema aborda este problema sugiriendo que se debe revisar constantemente el software. Esto es, que el equipo de programación busca posibles mejoras y las implementa de forma inmediata así lo que se busca es que siempre sea fácil de entender y cambiar cuando simplemente nuevas historias.
