2.2 Hacia el desarrollo ágil de software interactivo
2.2.4 El desarrollo ágil
2.2.4.4 Evolución en el desarrollo ágil
Varios autores argumentan la relación existente entre las metodologías clásicas en IS y las MA. Así, Abbas dice que algunas prácticas ágiles tienen raíces en las prácticas antiguas (Abbas et al., 2008).
Scrum (“Scrum Guides | Scrum.org - The home of Scrum,” n.d.) es un método de desarrollo ágil de software concebido por Jeff Sutherland a principios de la década de 1990. Schwaber y Beedle lo han refinado posteriormente (Schwaber and Beedle, 2001). Scrum utiliza patrones de proceso de software o sprint en los que se define un grupo de acciones de desarrollo. Un sprint es una unidad de trabajo necesaria para alcanzar un requisito. Durante el sprint no se introducen cambios, de tal manera que el sprint permite a los miembros del equipo trabajar en un ambiente de plazo corto, pero estable. Se establecen reuniones breves de 15 minutos a diario, dirigidas por un lider (Scrum master). Esto ayuda al equipo a descubrir problemas y a socializar el conocimiento.
El desarrollo rápido (RAD: Rapid Application Development) surge en 1994 y supone una discusión sobre el proceso iterativo previo. Esto deviene en el método DSDM (Dynamic Systems Development Method) (Stapleton and Consortium, 2003), un método iterativo e incremental que define una fase de preparación, un estudio de viabilidad y un estudio de negocio, secuencialmente para la adquisición de normas para el resto del desarrollo. Cada desarrollo realiza: iteración del modelo funcional, iteración del diseño y construcción, y finalmente implementación. Termina con una fase de conclusión en la que se deja la solución operativa. El mantenimiento es una parte más del ciclo de vida. DSDM se rige por la
involucración del cliente, el poder de toma de decisiones del equipo del proyecto, las entregas frecuentes, los cambios reversibles, las pruebas continuas y la fuerte comunicación.
A mediados de los 90 apareció el proceso unificado de Rational (RUP: Rational Unified Process) (Booch, 2006). Las actividades destacan por la creación y el mantenimiento de modelos más que por la documentación en papel. Este enfoque encaja especialmente bien con UML, y su desarrollo está centrado en la arquitectura. El proceso establece al principio una arquitectura software que guía el desarrollo del sistema y las actividades están dirigidas por los casos de uso. RUP impulsa un control de calidad y una gestión del riesgo continuos. Este proceso tiene cuatro fases: iniciación, elaboración, construcción y transición; las dos primeras incluyen actividades de diseño, y las dos últimas su producción. Una iteración representa un ciclo de desarrollo completo, desde la captura de requisitos hasta la implementación y pruebas, que produce como resultado la entrega al cliente de un producto ejecutable.
En la misma época, Kent Beck introdujo XP en su libro Extreme Programming Explained (Beck, 1999), como un método orientado al desarrollo con énfasis en la comunicación, simplicidad y evaluación. Su principal objetivo era la reducción de los costes de producción de software. XP es el método que más se practica en el ámbito académico y en la industria. XP se rige por los cinco valores y los doce principios ágiles, y sus actividades principales incluyen planificación, diseño, codificación y pruebas.
En 1999 apareció el proceso iterativo FDD: Feature-Driven Development en el libro Java Modeling Color with UML (Coad et al., 1999) . FDD describe cinco actividades básicas: desarrollar el modelo general, construir una lista de “features”, planificación por feature, diseño por feature y construcción por feature (Palmer and Felsing, 2002). Al igual que los métodos ágiles, FDD se centra en iteraciones cortas que entregan incrementos software completamente funcionales. FDD utiliza un enfoque basado en modelos UML, que se desarrollan para ayudar a visualizar y poner en práctica cada incremento de software .
Posteriormente, se han sumado otros métodos ágiles con diferentes grados de éxito. Crystal Family, entre ellos Chrystal Clear (Cockburn, 2004), es una colección de métodos creados por Alistair Cockburn y Jim Highsmith que permite a los desarrolladores lograr "maniobrabilidad" cuando surja la necesidad. El movimiento del Lean Software (Larman and
Vodde, 2008), basado en principios económicos y matemáticos, describe un marco de trabajo con cinco elementos:
• El tejado: Los objetivos de producción • El pilar 1: Respeto a las personas • El pilar 2: Mejoras continuas • La base: El soporte a la gestión
• Los contenidos: El flujo de desarrollo del producto
Estos principios han inspirado el desarrollo del método Kanban que define una manera de gestionar el trabajo de software en función de alguna “unidad de valor” (puede ser una user story, característica o requisito mínimo), realizado con restricciones WIP (work in progress) (“limitedwipsociety,” 2013). Se basa en visualizar el flujo de trabajo, limitar el trabajo en curso, medir y gestionar el flujo, hacer expícitas las reglas del proceso y utilizar modelos para reconocer las oportunidades de mejora.
Ventajas e Inconvenientes
Las ventajas vienen dadas por sus características diferenciales de los métodos clásicos. Así, los clientes (usuarios y propietarios del sistema) trabajan con el equipo de desarrolladores a lo largo del ciclo de vida, no únicamente al principio y/o al final. El feedback constante del cliente evita la firma de un contrato formal para el producto total y la documentación extensa necesaria para la transferencia de conocimiento (Maciaszek and Liong, 2004). La continua integración y los ciclos cortos permiten aceptar los cambios de forma temprana.
Chow recoge, en una revisión exhaustiva, una lista de factores de fracaso en proyectos ágiles (Chow and Cao, 2008) que nos remiten a los puntos débiles de este método, que deben ser tenidos en cuenta para su aplicación.
Los factores de fracaso, se clasificaron en cuatro categorías:
• Organizativos: Falta de liderazgo ejecutivo o de compromiso en la gestión, tener una cultura organizativa demasiado tradicional, política o de un tamaño demasiado grande, o una falta de soluciones logísticas ágiles.
• Personas: Falta de habilidades necesarias, límites para el trabajo en equipo, resistencia en los grupos o individuos, o relaciones malas con el cliente.
• Proceso: Una mala definición del alcance del proyecto, de sus requisitos, de la planificación, falta de mecanismos para el seguimiento del progreso del proyecto, falta de presencia del cliente o mal definido su papel.
• Técnicos: Falta de prácticas ágiles correctas y, uso de tecnologías y herramientas inapropiadas.
Áreas y situaciones adecuadas para su aplicación
Las MA tienen éxito en proyectos específicos: complejos y con muchos cambios. Este enfoque obtiene sus mejores resultados en entornos centrados en la gente y organizaciones centradas en la cooperación.
Algunos ingenieros de software tienden a descartar el desarrollo ágil en proyectos grandes porque la mayoría de los procesos ágiles se promueven solo para equipos pequeños, donde la colaboración, la cooperación y la comunicación oral es más fácil. La mayoría de los proyectos que fallan son grandes. Esto se debe en gran medida a una falta de comunicación entre los equipos, gestores, clientes, etc (Eckstein, 2004). La comunicación es uno de los pilares de las MA, es un factor de éxito que se destaca con frecuencia (Chow and Cao, 2008).