archivo

Archivos diarios: julio 15, 2011

Capers Jones es un ingeniero de software americano especialista en estimación de costes, metodologías de desarrollo y calidad del software. También es autor de artículos y libros sobre esas materias.

En la segunda edición de su libro “From Applied Software Measurement” realiza la siguiente reflexión (traducción libre):

“El software es una industria que hace un uso intensivo del papel. El volumen total de documentos utilizados en proyectos software es superior al utilizado en la mayoría de los productos fabricados por el hombre… En proyectos software de gran tamaño del ámbito militar, el volumen total de documentos en papel puede superar el millón de páginas.

Lo que resulta sorprendente es que en sistemas muy grandes el volumen de documentación de las especificaciones y documentos técnicos puede ser lo suficientemente extenso como para ser leído en la vida de un solo analista. Suponiendo una velocidad de lectura técnica de alrededor de 200 palabras por minuto, hay algunos sistemas en los que un empleado puede llevarse una vida laboral de 40 años sin hacer nada salvo leer la documentación y encima no terminar de realizar esa tarea”

Lo más significativo de esa reflexión es que es absolutamente cierta. ¿Qué porcentaje de la documentación generada en un proyecto de desarrollo de software resulta de utilidad?. Esto no es una cruzada contra la documentación es más, estoy a favor de ella, siempre y cuando sirva para algo.

Los primeros dos principios del manifiesto ágil indican que:

– Los individuos y su interacción se encuentran por encima de los procesos y las herramientas.
– El software que funciona se encuentra por encima de la documentación exhaustiva.

Venimos de una cultura de desarrollo de software centrada en la consecución de hitos documentales, si pongo mi caso personal encima de la mesa tengo que confesar que me ha costado mucho entender que los modelos de desarrollo que me enseñaron en la universidad y que se ponen en práctica en mi trabajo están en contra de la verdadera naturaleza del desarrollo de software.

También que la calidad del software se encuentra en un estrato diferente a la calidad documental, pese a que las metodologías de corte clásico lo ponían al mismo nivel, ya que no se podía conseguir lo uno sin lo otro, algo que la experiencia nos dice que no tiene por qué ser cierto.

Una naturaleza adaptativa, donde el software se va modelando como una pieza de barro en un torno y para ello requiere una dinámica de trabajo ágil que no interrumpa el objetivo principal que no es otro que satisfacer las expectativas del usuario.

En el sentido opuesto están los modelos predictivos como el ciclo de vida clásico o en cascada donde la documentación es el testigo que se hereda entre un proceso o fase y otra del proyecto.

Soy totalmente contrario al Cowboy Coding pero también lo soy de los modelos de desarrollo de software que giran alrededor de la documentación.

La documentación es importante como instrumento de soporte al proceso de desarrollo pero deja de ser útil cuando en vez de una herramienta se considera una finalidad.

En este sentido y como he comentado antes, en el plano personal he evolucionado hacia otra forma de enfocar el desarrollo de software, esa evolución se puede apreciar incluso en mis artículos, no veo igual como enfocar un proyecto ahora que hace dos años y en esto ha tenido mucho que ver la experiencia de muchos desarrollos en cascada y de la mejora que se obtiene en los resultados cuando se evoluciona de ese modelo a otros iterativos e incrementales.