El desarrollo ágil de software es un paradigma de desarrollo que se basa en una serie de principios y valores de desarrollo iterativo, con grupos auto-organizados y multidisciplinarios, y soportado por un nuevo conjunto de metodologías de desarrollo de software [28].
Su historia se remonta al 17 de febrero de 2001, cuando varios desarrolladores de software
de reconocido prestigio hoy en día (Robert C. Martin, Jim Highsmith, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Dave Thomas, Martin Fowler, etc.) se reunieron en Utah para discutir nuevas metodologías de desarrollo. Estos desarrolladores se habían dado cuenta que un gran número de proyectos fracasaban debido a cuestiones relacionadas con el presupuesto y planificación, la interfaz del software que era non-user-friendly y a la poca flexibilidad para permitir cambios en su software. Además, habían comprobado que la principal causa de todos estos problemas solía ser la falta de comunicación y coordinación entre las parte involucradas. Es aquí cuando surgió el Manifiesto Ágil (ver Fig. 57) junto con sus Principios (ver Fig. 58).
Fig. 57 Manifiesto por el Desarrollo Ágil de Software [29]
60
61
El desarrollo ágil de software se apoya en un conjunto de prácticas que cubren áreas tales como requisitos, diseño, modelado, código, test, gestión de procesos, calidad, etc. Algunas de estas prácticas son:
Sobre el desarrollo del software:
o Planificación conjunta:
Recopilación informal de requisitos.
Estimación inicial de los requisitos recopilados.
Priorización de los requisitos.
Selección de los requisitos más importantes para formar versiones parciales del producto, pero completa funcionalmente (constituyen una entrega). o Pequeñas y frecuentes revisiones:
Ciclo de vida incremental y evolutivo.
Al final de cada ciclo, validación del producto por parte del cliente.
o Diseño sencillo: desarrollar la solución más sencilla que cumpla las especificaciones y sólo de los requisitos actuales sin predecir las necesidades futuras.
o Accesibilidad del cliente: siempre disponible para clarificar y validar los requisitos Sobre el código:
o Estandarización: el código desarrollado debe ser entendido por todo el equipo. o Repositorio común: el código pertenece al equipo y es compartido.
o Revisión continua y refactorización: el código se revisa y restructura continuamente para mejorar su estructura.
o Integración continua: el repositorio común contiene las últimas versiones del código, el cual se compila y se prueba continuamente para detectar fallos cuanto antes. Sobre pruebas:
o Test unitario: automático y exhaustivo, previo a la creación del código. Se deben superar todos los tests unitarios para que un módulo de código se considere válido. o Test de aceptación: garantiza que el sistema proporciona la funcionalidad requerida.
62 Sobre la forma de trabajo:
o Reuniones diarias: reuniones de 15 minutos, antes de empezar el trabajo, en el mismo lugar y hora para que cada miembro del equipo haga un resumen de que es lo hizo ayer y que es lo que va a hacer.
o Revisión del sprint/iteración: demo informativa donde se presenta lo que se ha hecho para el sprint/iteración.
o Reuniones retrospectivas: se evalúa como se ha trabajado en el último sprint/iteración para tratar de mejorar el proceso.
o Programación en parejas: colaboración e interacción entre los miembros del equipo. o No hacer horas extra: implican cansancio y poca calidad en el trabajo.
o Áreas de trabajo abiertas y comunes: facilitan la comunicación entre los desarrolladores y clientes.
Respecto al desarrollo ágil de software, existen varios metodologías [31] tales como Agile, Scrum, Extreme Programming (XP), Lean Development, etc. En particular, la metodología Scrum (ver Fig. 59) comienza con una pila priorizada de objetivos o requisitos, escritos en forma de historias de usuario (HU), que de alguna manera van a configurar el plan de proyecto. Una HU describe necesidades requeridas por el sistema en una o dos frases utilizando el lenguaje común del usuario, así como las discusiones con los usuarios y las pruebas de validación. Las HU deben ser escritas por los clientes. Éstas son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las HU permiten responder rápidamente a los requisitos cambiantes. El conjunto de HU constituye el product backlog. Del
product backlog el equipo selecciona el grupo de HU que se van a realizar en el siguiente iteración (sprint). de 2 a 4 semanas. Generalmente, esta selección está basada en el ratio prioridad/esfuerzo, seleccionándose las HU que aportan mayor valor y requieren menos esfuerzo. Una vez que el equipo ha decidido qué HU se van a implementar comienza el sprint. Durante el sprint, los miembros del equipo llevan a cabo una corta reunión diaria de unos 15 minutos como máximo, llamada daily meeting, a modo de sincronización. Cuando acaba el
sprint, se presenta el valor al dueño del producto para que lo revise y apruebe su subida a producción en la review meeting, y por otro lado, el equipo tiene una restrospective meeting, en la cual se evalúa cómo se ha trabajado en el último sprint.
63
Fig. 59 Proceso de desarrollo ágil de software. Metodología SCRUM [32]
Un elemento que se suele utilizar en Scrum para ayudar a los miembros del equipo en la organización del sprint es el board. Pueden ser físicos o digitales y consisten en un panel que representa el sprint actual con varias columnas que representan los distintos estados (To do/In progress/Done) en que se pueden encontrar las tareas que componen una HU (ver Fig. 60).
64