Desarrollo Ágil de Software: Métodos Iterativos y Programación Extrema

Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos iterativos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas. El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas funcionalidades al sistema. Aunque existen muchos enfoques para el desarrollo rápido de software, comparten las mismas características fundamentales:

Los procesos de especificación, diseño e implementación son concurrentes. No existe una especificación del sistema detallada, y la documentación del diseño se minimiza o es generada automáticamente por el entorno de programación utilizado para implementar el sistema. El documento de requerimientos del usuario define solamente las características más importantes del sistema.
El sistema se desarrolla en una serie de incrementos. Los usuarios finales y otros stakeholders del sistema participan en la especificación y evaluación de cada incremento. Pueden proponer cambios en el software y nuevos requerimientos que se deben implementar en un incremento posterior del sistema.
A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colocando iconos en la interfaz. El sistema puede generar una interfaz basada en web para un navegador o una interfaz para una plataforma específica como Microsoft Windows.

Ventajas del Desarrollo Incremental

El desarrollo incremental implica producir y entregar el software en incrementos más que en un paquete único. Cada iteración del proceso produce un nuevo incremento del software. Las dos ventajas principales de adoptar un enfoque incremental para el desarrollo del software son:

Entrega acelerada de los servicios al cliente. En los incrementos iniciales del sistema se pueden entregar las funcionalidades de alta prioridad para que los clientes puedan aprovechar el sistema desde el principio de su desarrollo. Los clientes pueden ver sus requerimientos en la práctica y especificar cambios a incorporar en entregas posteriores del sistema.
Compromiso del cliente con el sistema. Los usuarios del sistema tienen que estar implicados en el proceso de desarrollo incremental debido a que tienen que proporcionar retroalimentación sobre los incrementos entregados al equipo de desarrollo. Su participación no sólo significa que es más probable que el sistema cumpla sus requerimientos, sino que también los usuarios finales del sistema tienen que hacer un compromiso con él y conseguir que éste llegue a funcionar.

Desafíos del Desarrollo Iterativo y la Entrega Incremental

Sin embargo, puede haber verdaderos problemas con este enfoque, particularmente en las grandes compañías con procedimientos bastante rígidos y en organizaciones donde el desarrollo del software normalmente se subcontrata con un contratista exterior. Los principales problemas con el desarrollo iterativo y la entrega incremental son:

Problemas de administración. Las estructuras de administración del software para sistemas grandes se diseñan para tratar con modelos de proceso del software que generan entregas periódicas para evaluar el progreso. Los sistemas desarrollados incrementalmente cambian tan rápido que no es rentable producir una gran cantidad de documentación del sistema. Además, el desarrollo incremental muchas veces puede requerir el uso de tecnologías desconocidas para asegurar una entrega más rápida del software. A los administradores puede resultarles difícil utilizar al personal existente en los procesos de desarrollo incremental puesto que carecen de las habilidades requeridas.
Problemas contractuales. El modelo contractual normal entre un cliente y un desarrollador de software se basa en la especificación del sistema. Cuando no existe tal especificación, puede ser difícil diseñar un contrato para el desarrollo del sistema. Los clientes pueden estar descontentos con un contrato que simplemente pague a los desarrolladores por el tiempo invertido en el proyecto, ya que puede conducir a que el sistema se desarrolle lentamente y se sobrepase el presupuesto; los desarrolladores probablemente no aceptarán un contrato con precio fijo debido a que no pueden controlar los cambios requeridos por los usuarios finales.
Problemas de validación. En un proceso basado en la especificación, la verificación y la validación están pensadas para demostrar que el sistema cumple su especificación. Un equipo independiente de V & V puede empezar a trabajar tan pronto como esté disponible la especificación y puede preparar pruebas en paralelo con la implementación del sistema. Los procesos de desarrollo iterativo intentan minimizar la documentación y entrelazan la especificación y el desarrollo. Por lo tanto, la validación independiente de los sistemas desarrollados incrementalmente es difícil.
Problemas de mantenimiento. Los cambios continuos tienden a corromper la estructura de cualquier sistema software. Esto significa que cualquiera, aparte de los desarrolladores originales, puede tener dificultades para entender el software. Una forma de reducir este problema es utilizar refactorización, donde se mejoran continuamente las estructuras del software durante el proceso de desarrollo. Además, si se utiliza tecnología especializada, como los entornos RAD, para ayudar al desarrollo rápido del prototipo, la tecnología RAD puede convertirse en obsoleta. Por lo tanto, puede ser difícil encontrar personas que tengan los conocimientos requeridos para dar mantenimiento al sistema.

Prototipado vs. Desarrollo Incremental

Se utiliza aquí el término prototipado para expresar un proceso iterativo para desarrollar un sistema experimental que no está destinado a la utilización por parte de los clientes. Se desarrolla un prototipo del sistema para ayudar a los desarrolladores de software y a los clientes a comprender qué se debe implementar. Sin embargo, algunas veces se utiliza la expresión prototipado evolutivo como sinónimo del desarrollo de software incremental. El prototipo no se descarta sino que se desarrolla para cumplir los requerimientos del usuario.

La Figura 17.2 muestra que el desarrollo y el prototipado incremental tienen objetivos diferentes:

El objetivo del desarrollo incremental es entregar a los usuarios finales un sistema funcional. Esto significa que normalmente debe comenzar con los requerimientos del usuario que mejor se comprendan y que tengan la prioridad más alta. Los requerimientos inciertos y de prioridad más baja se implementan cuando sean requeridos por los usuarios.
El objetivo del prototipado desechable es validar u obtener los requerimientos del sistema. Debe comenzar con aquellos requerimientos que no se comprendan bien ya que requiere saber…

Principios de los Métodos Ágiles

Participación del cliente: los clientes deben estar fuertemente implicados en todo el proceso de desarrollo. Su papel es proporcionar y priorizar nuevos requerimientos del sistema y evaluar las iteraciones del sistema.
Entrega Incremental: el software se desarrolla en incrementos, donde el cliente especifica los requerimientos a incluir en cada incremento.
Personas, no procesos: se deben reconocer y explotar las habilidades del equipo de desarrollo. Se les debe dejar desarrollar sus propias formas de trabajar, sin procesos formales, a los miembros del equipo.
Aceptar el cambio: se debe contar con los requerimientos del sistema cambian por lo que el sistema se diseña para dar cabida a estos cambios.
Mantener la simplicidad: se deben centrar en la simplicidad tanto en el software a desarrollar como en el proceso de desarrollo. Donde sea posible, se trabaja activamente para eliminar la complejidad del sistema.

Desafíos en la Implementación de Métodos Ágiles

Si bien la idea de la participación del cliente en el proceso de desarrollo es atractiva, su éxito depende de tener un cliente que esté dispuesto y pueda pasar tiempo con el equipo de desarrollo y que pueda representar a todos los stakeholders del sistema. Frecuentemente, los representantes de los clientes están sometidos a otras presiones y no pueden participar plenamente en el desarrollo del software.
Los miembros individuales del equipo pueden no tener la personalidad apropiada para la participación intensa que es típica de los métodos ágiles. Por lo tanto, es posible que no se relacionen adecuadamente con los otros miembros del equipo.
Priorizar los cambios puede ser extremadamente difícil, especialmente en sistemas en los que existen muchos stakeholders. Por lo general, cada stakeholder proporciona prioridades distintas a diferentes cambios.
Mantener la simplicidad requiere un trabajo extra. Bajo presión por las agendas de entregas, los miembros del equipo pueden no tener tiempo de llevar a cabo las simplificaciones deseables del sistema.

Programación Extrema (XP)

La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente utilizado. El nombre fue acuñado por Beck (Beck, 2000) debido a que el enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo iterativo, y con la participación del cliente en niveles «extremos».

En la programación extrema, todos los requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se implementan directamente como una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integre al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema. La Figura 17.4 ilustra el proceso de la XP para producir un incremento del sistema que se está desarrollando.

Prácticas de la Programación Extrema

La programación extrema implica varias prácticas, resumidas en la Figura 17.5, que se ajustan a los principios de los métodos ágiles:

El desarrollo incremental se lleva a cabo través de entregas del sistema pequeñas y frecuentes y por medio de un enfoque para la descripción de requerimientos basado en las historias de cliente o escenarios que pueden ser la base para el proceso de planificación.
La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del cliente en el equipo de desarrollo. Los representantes de los clientes participan en el desarrollo y son los responsables de definir las pruebas de aceptación del sistema.
El interés en las personas, en vez de en los procesos, se lleva a cabo a través de la programación en parejas, la propiedad colectiva del código del sistema, 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 de la simplicidad se lleva a cabo a través de la refactorizació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.

Elementos Clave de la Programación Extrema

Planificación incremental: los requerimientos se registran en tarjetas de historias y las historias en una entrega se determinan según el tiempo disponible y su prioridad relativa. Los desarrolladores dividen estas historias en TAREAS DE DESARROLLO.
Entregas pequeñas: el mínimo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.
Diseño sencillo: solo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.
Desarrollo previamente probado: se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que estas se implementen.
Refactorización: se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentren posibles mejoras en el código. Esto conserva el código sencillo y mantenible.
Programación en parejas: los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y proporcionando la ayuda necesaria para hacer siempre un buen trabajo.
Propiedad colectiva: las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen ideas de conocimientos y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.
Integración continua: en cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Después de la integración, se deben pasar al sistema todas las pruebas de unidad.
Ritmo sostenible: no se consideran aceptables grandes cantidades de horas extras, ya que a menudo el efecto que tienen es que se reduce la calidad del código y la productividad a medio plazo.
Cliente presente: debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la programación extrema, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementación.

Pruebas en la Programación Extrema (XP)

Como se ha indicado en la introducción de este capítulo, una de las diferencias importantes entre el desarrollo iterativo y el desarrollo basado en la planificación es la forma de probar el sistema. Con el desarrollo iterativo, no existe una especificación del sistema que pueda ser utilizada por un equipo de pruebas externo para desarrollar las pruebas del sistema. Por consiguiente, algunos enfoques para el desarrollo iterativo tienen un proceso de pruebas muy informal.

Para evitar algunos de los problemas de las pruebas y de la validación del sistema, XP pone más énfasis en el proceso de pruebas que otros métodos ágiles. Las pruebas del sistema son fundamentales en XP, en la que se ha desarrollado un enfoque que reduce la probabilidad de producir nuevos incrementos del sistema que introduzcan errores en el software existente.

Características Clave de las Pruebas en XP

Desarrollo previamente probado.
Desarrollo de pruebas incremental a partir de los escenarios.
Participación del usuario en el desarrollo de las pruebas y en la validación.
El uso de bancos de pruebas automatizados.

El desarrollo previamente probado es una de las innovaciones más importantes en XP. Al escribir primero las pruebas se define implícitamente tanto una interfaz como una especificación del funcionamiento para la funcionalidad a desarrollar. Se reducen los problemas en los requerimientos y las confusiones de la interfaz. Se puede adoptar este enfoque en cualquier proceso en el que exista una relación clara entre un requerimiento del sistema y el código que implementa ese requerimiento. En XP, siempre puede verse este vínculo debido a que las tarjetas de historias que representan los requerimientos se dividen en tareas, y las tareas son las unidades principales de implementación.

Como se ha señalado, los requerimientos de usuario en XP se expresan como escenarios o historias y el usuario establece las prioridades de éstos para su desarrollo. El equipo de desarrollo evalúa cada escenario y lo divide en tareas. Cada tarea representa una característica distinta del sistema y se puede diseñar entonces una prueba de unidad para esa tarea.

Programación en Parejas

Otra práctica innovadora que se ha introducido es que los programadores trabajan en parejas para desarrollar el software. De hecho, se sientan juntos en la misma estación de trabajo para desarrollar el software. El desarrollo no siempre implica la misma pareja de personas trabajando juntas. Más bien, la idea es que las parejas se creen de forma dinámica para que todos los miembros del equipo puedan trabajar con los otros miembros en una pareja de programación durante el proceso de desarrollo.

Ventajas de la Programación en Parejas

Apoya la idea de la propiedad y responsabilidad comunes del sistema. Esto refleja la idea de Weinberg de la programación sin ego (Weinberg, 1971), en la que el equipo como un todo es dueño del software y las personas individuales no tienen la culpa de los problemas con el código. En cambio, el equipo tiene una responsabilidad colectiva para resolver estos problemas.
Actúa como un proceso de revisión informal ya que cada línea de código es vista por al menos dos personas. Las inspecciones y revisiones del código (tratadas en el Capítulo 22) consiguen descubrir un alto porcentaje de errores del software. Sin embargo, requiere mucho tiempo organizarlas y, por lo general, generan retrasos en el proceso de desarrollo. A pesar de que la programación en parejas es un proceso menos formal que probablemente no encuentre tantos errores, es un proceso de inspección mucho más económico que las inspecciones formales de programas.
Ayuda en la refactorización, la cual es un proceso de mejora del software. Un principio de la XP es que se debe refactorizar constantemente el software. Es decir, se deben escribir nuevamente partes del código para mejorar su claridad y estructura. El problema para implementar esto en un entorno de desarrollo normal es que es un esfuerzo que se gasta para obtener un beneficio a largo plazo, y se puede juzgar a una persona que practique la refactorización como menos eficiente que otra que simplemente realice el desarrollo del código. Cuando se utiliza la programación en parejas y la propiedad colectiva, otros se benefician inmediatamente con la refactorización, por lo que probablemente apoyarán el proceso.

Desarrollo Rápido de Aplicaciones (RAD)

Aunque los métodos ágiles como un enfoque para el desarrollo iterativo han recibido una gran atención en los últimos años, los sistemas de negocio se han desarrollado de forma iterativa durante muchos años utilizando técnicas de desarrollo rápido de aplicaciones. Las técnicas de desarrollo rápido de aplicaciones (RAD) evolucionaron de los llamados lenguajes de cuarta generación en los años 80 y se utilizan para desarrollar aplicaciones con un uso intensivo de datos. Por consiguiente, normalmente están organizadas como un conjunto de herramientas que permiten crear datos, buscarlos, visualizarlos y presentarlos en informes. La Figura 17.9 ilustra una organización típica de un sistema RAD.

Herramientas en un Entorno RAD

Un lenguaje de programación de bases de datos, que contiene conocimiento de la estructura de la base de datos y que incluye las operaciones básicas de manipulación de bases de datos. El lenguaje estándar de programación de base de datos es SQL (Groff et al., 2002). Los comandos SQL se pueden introducir directamente o generar de forma automática a partir de formularios rellenados por los usuarios finales.
Un generador de interfaces, que se utiliza para crear formularios de introducción y visualización de datos.
Enlaces a aplicaciones de oficina, como una hoja de cálculo para el análisis y manipulación de información numérica o un procesador de textos para la creación de plantillas de informes.
Un generador de informes, que se utiliza para definir y crear informes a partir de la información de la base de datos.

Muchas de las aplicaciones de negocio se apoyan en formularios estructurados para las entradas y salidas, por lo que los entornos RAD proporcionan recursos potentes para la definición de pantallas y generación de informes. A menudo, las pantallas se definen como una serie de formularios vinculados (en una aplicación que estudiamos, hubo 137 definiciones de formularios), por lo que el sistema de generación de pantallas debe proporcionar:

Definición de formularios interactivos que permitan al desarrollador definir los campos a visualizar y la manera en que éstos deben organizarse.
Vinculación de los formularios que permitan al desarrollador especificar que ciertas entradas provocan la visualización de formularios adicionales.
Verificación de campos que permitan al desarrollador definir los rangos permitidos para los valores de entrada en los campos de los formularios.

Prototipado del Software

Como se ha indicado en la introducción de este capítulo, existen algunas circunstancias en las que. por razones prácticas o contractuales, no se puede utilizar un proceso de entrega del software incremental. En esas situaciones, se completa una declaración de los requerimientos del sistema y es utilizada por el equipo de desarrollo como la base para el software del sistema. Como se ha explicado, se pueden conseguir algunos de los beneficios de un proceso de desarrollo incremental creando un prototipo del software. Este enfoque se denomina a veces prototipado desechable debido a que el prototipo no es entregado al cliente o mantenido por el desarrollador.

Un prototipo es una versión inicial de un sistema software que se utiliza para demostrar conceptos, probar opciones de diseño y, en general, informarse más del problema y sus posibles soluciones. El desarrollo rápido e iterativo del prototipo es esencial, de modo que los costes sean controlados y los stakeholders del sistema puedan experimentar con el prototipo en las primeras etapas del proceso del software.

Usos del Prototipado en el Desarrollo de Software

En el proceso de ingeniería de requerimientos, un prototipo puede ayudar en la obtención y validación de los requerimientos del sistema.
En el proceso de diseño del sistema, se puede utilizar un prototipo para explorar soluciones software particulares y para apoyar al diseño de las interfaces de usuario.
En el proceso de pruebas, se puede utilizar un prototipo para ejecutar pruebas back-to-back con el sistema que se entregarán al cliente.

Beneficios del Prototipado

En un estudio de 39 proyectos de prototipado, Gordon y Bieman (Gordon y Bieman, 1995) observaron que los beneficios de utilizar el prototipado fueron:

Mejora en la usabilidad del sistema.
Una mejor concordancia entre el sistema y las necesidades del usuario.
Mejora en la calidad del diseño.
Mejora en el mantenimiento.
Reducción en el esfuerzo de desarrollo.

Puntos Clave

Al crecer la presión por una entrega rápida del software, se utiliza cada vez más un enfoque iterativo para el desarrollo del software como una técnica de desarrollo estándar para sistemas pequeños y de tamaño medio, especialmente en el dominio de los negocios.
Los métodos ágiles son métodos de desarrollo iterativo que se centran en la especificación, diseño e implementación del sistema de forma incremental. Implican directamente a los usuarios en el proceso de desarrollo.
Reducir la sobrecarga en cuanto al esfuerzo de desarrollo puede hacer posible un desarrollo del software más rápido.
La programación extrema es un método ágil conocido que integra una variedad de buenas prácticas de programación, como las pruebas sistemáticas, la continua mejora del software y la participación del cliente en el equipo de desarrollo.
Un punto fuerte particular de la programación extrema es el desarrollo de pruebas automatizadas antes de que se cree una funcionalidad en un programa. Se deben ejecutar de forma satisfactoria todas las pruebas cuando se integra un incremento en un sistema.
El desarrollo rápido de aplicaciones implica la utilización de entornos de desarrollo que incluyan herramientas potentes para apoyar la producción del sistema. Éstas comprenden lenguajes de programación de bases de datos, generadores de formularios e informes, y enlaces a aplicaciones de oficina.
El prototipado desechable es un proceso de desarrollo iterativo en el que se utiliza un sistema prototipo para explorar los requerimientos y las opciones de diseño. Este prototipo no está destinado para su utilización por parte de los clientes del sistema.
Cuando se implementa un prototipo desechable, primero se tienen que desarrollar las partes del sistema que menos se comprenden; por el contrario, en un enfoque de desarrollo incremental, se empieza desarrollando las partes del sistema que mejor se comprenden.