Presentación del problema: la documentación en los métodos ágiles

Desde su aparición, los métodos ágiles han generado un debate que aún es de actualidad. Como se comenta en (Boehm, 2002), estos métodos enfatizan, entre otras cosas, la producción de un software funcional frente a la elaboración de la documentación técnica completa. En los métodos basados en planificación, existen unas tareas explícitas para la producción de la documentación técnica que no se contemplan en los ágiles. Se produce, por lo tanto, una controversia dentro de la comunidad del desarrollo software. Como ejemplo de este debate abierto, en (Briand, 2003) se hace una descripción de la documentación en Extreme Programming. Si se aplicase estrictamente esta aproximación, no existirían documentos de Análisis o Diseño, ya que se basa en la “comunicación oral, pruebas y código fuente, para describir la estructura del sistema y su propósito” (Beck & Andres, 2004). Esta aproximación se justifica por los siguientes supuestos:

 XP (Extreme Programming) se creó para equipos de trabajo pequeños, de entre dos y diez desarrolladores.

 La rotación del personal es menor ya que hay “menos posibilidades de que se sientan frustrados”.

 El cliente es parte integral del equipo, a través de una continua realimentación con respecto a los requisitos.

 Mantenimiento de un conjunto completo de pruebas que, de alguna forma, describe el propósito del software.

 Con las nuevas tecnologías, el costo del cambio no aumenta de forma exponencial, sino que se incrementa poco a poco con el tiempo.

No hay necesidad, por tanto, de realizar un análisis ni un diseño de todo el sistema por adelantado, ni sus correspondientes documentos.

Existen, no obstante, una serie de posibles contradicciones en las premisas y principios de XP y de los métodos ágiles en general que vale la pena discutir e investigar.

 ¿Cómo se puede derivar la batería de pruebas? ¿Cómo se garantiza una estrategia de evaluación sistemática, sin análisis o documentación de diseño?

 La especificación del software se refina de forma continua a medida que el sistema se desarrolla. ¿No presenta la falta de documentación un problema para esta actividad? ¿Se puede considerar el conjunto de pruebas realmente como un sustitutivo de la documentación a este respecto?

 XP propone la refactorización del diseño como una parte de las tareas diarias de todo el equipo de desarrollo. ¿Son las baterías de pruebas y la comunicación oral suficiente para garantizar que todos los miembros del equipo tienen controlados todos los conceptos sobre el diseño?

5-4 Capítulo 5 En cualquier caso, las cuestiones anteriormente planteadas hacen referencia al proceso de desarrollo, cuando lo cierto es que los verdaderos problemas por la falta de documentación parecen surgir a la hora del mantenimiento del software. En (Kajko- Mattsson, 2008) se informa de problemas detectados en este sentido en varias organizaciones ágiles. Los principales problemas encontrados, a medida que el sistema crece y debe ser mantenido, se pueden resumir en los siguientes:

 La comunicación oral también lleva tiempo.

 La comunicación oral propicia las distracciones y la pérdida de tiempo.

 Es difícil encontrar a la persona que conoce las respuestas correctas.

 La comunicación oral es la razón por la cual los ingenieros olvidan las decisiones tomadas con respecto a los sistemas; sobre todo su justificación. Los ingenieros terminan olvidando lo que dijeron, lo que les contaron o preguntas que realizaron.

 Los ingenieros no tienen claro los cambios a realizar ni dónde.

 Los ingenieros no recuerdan qué cambios realizaron ni porqué.

 Los ingenieros hacen preguntas que denotan falta de conocimiento del sistema.

 Los ingenieros repiten muchos de los errores anteriormente cometidos.

 Las organizaciones pueden perder repentinamente conocimiento valioso debido a la marcha de algún ingeniero.

 La marcha de ingenieros repercute muy negativamente en la gestión de cambios en términos de tiempo y costes.

 Los ingenieros no conocen el sistema en su conjunto. El conocimiento del sistema está repartido separadamente entre distintos ingenieros.

 La arquitectura software se deteriora sustancialmente.

 Muchos de los elementos de productos o procesos terminan sin entenderse.

 Cuando el sistema crece, los equipos de desarrollo van encontrando más dificultades para comprenderlo y realizar cambios. Los ingenieros comienzan a perder la pista de la visión de la organización.

 El equipo de pruebas tiene dificultades para probar a fondo el sistema.

 Debido a la comunicación oral, los probadores no entienden la funcionalidad que debe ser puesta a prueba.

Las organizaciones participantes en el estudio de Kajko-Mattson tomaron medidas del siguiente tipo para paliar estos problemas:

 Para remediar la expansión ad hoc de la arquitectura del sistema, las organizaciones han creado el rol de architect, que asegura la calidad de la arquitectura. Esta práctica es común en los proyectos tradicionales.

 Para paliar el problema de la comunicación, las organizaciones han creado el rol

de Communicator Owner, responsable de comunicar la información global del

Capítulo 5. 5-5 que la información de importancia esté documentada. Esto último es diferente con respecto a los métodos tradicionales.

 Para remediar los problemas de escalabilidad, las organizaciones han adoptado prácticas utilizadas en el mantenimiento y evolución tradicional, creando el rol

de Sytem/Component Owner. También han mejorado la documentación del

sistema y de los procesos.

Si bien es cierto que los métodos ágiles pretenden la reducción al mínimo de la documentación técnica, lo cierto es que los métodos planificados o tradicionales hacen, en muchos casos, una declaración de principios con respecto a la documentación que, a la hora de la verdad, no se cumplen como debería, como se ha visto en el capítulo de la calidad de la documentación técnica.

5.4 Tendencias en la búsqueda de soluciones: Adecuación de procesos