Desarrollo de software. Metodologías ágiles y sistemas que requieren una documentación exhaustiva
Una rápida adaptación al cambio requiere que llevemos con nosotros las menores cargas posibles, bastante tenemos ya con el sistema que se está desarrollando (o que ya está desarrollado). Cuanto mayor sea la carga, mayor será la inercia, más lenta será nuestra capacidad de cambio, más nos impactará y más tiempo tardaremos en volver a encauzar el sistema.
La documentación es una herramienta más para conseguir nuestro propósito que no es otro que el desarrollo de un sistema que satisfaga las expectativas del usuario. Cuando la documentación se convierte en un objetivo puede comenzar a convertirse en un problema.
Digo puede porque realmente lo que hay que cuestionar es si tener una documentación exhaustiva aporta valor real al sistema una vez desarrollado, en unos casos sí que lo hará y en otros mucho no. La ruptura de ese equilibrio tanto por defecto como por exceso es negativa.
Por tanto, ante un sistema donde a priori se puede pensar que se requiere una documentación abundante, lo primero que hay que hacer es analizar si realmente es necesaria o no. En el caso de que sea necesaria hay que tener en cuenta que será necesario adaptar los tiempos del proyecto a la misma y que se requerirá un esfuerzo importante mantenerla actualizada y esto es independiente de la metodología que se decida utilizar.
¿Recomendaría la aplicación de metodologías ágiles en proyectos de estas características? No es el contexto ideal, pero ¿acaso es un contexto ideal para un desarrollo en cascada? Sí que es más natural para este tipo de desarrollos donde se construye a partir de análisis detallado y un diseño, sin embargo, ante situaciones de cambio y que requieran una rápida adaptación, una documentación copiosa sigue siendo un lastre.
Como decía antes, lo importante es analizar el valor de tener una documentación exhaustiva, si realmente lo tiene se debería considerar que su función es como la de un módulo del sistema de información que estamos desarrollando y que ha sido solicitado desde el área usuaria, por tanto y visto desde esta perspectiva podría encajar con una metodología ágil, teniendo en cuenta que se requiere dimensionar el proyecto para tener en cuenta este objetivo y que impactará en la capacidad de adaptación del mismo.
Todo es relativo en esta vida, y en nuestro trabajo más si cabe.
La documentación completa y a veces demasiado compleja depende del tiempo y el presupuesto, no lo vamos a negar, es el nerd del baile de fin de curso con el que nadie quiere asistir.
Así y todo, como he dicho, dependiendo del tamaño del proyecto y de su posible complejidad con la documentación que se debería agregar en el código debería ser más que suficiente. Para ello se necesita más profesionales concienciados de la necesidad de la documentación entre código y al comienzo de las funciones y archivos para lograrlo.
Aunque no hay nada perfecto, las normas de documentación de la comunidad de Drupal me han parecido siempre un buen punto de partida (http://drupal.org/node/1354) y se pueden adaptar tanto a pequeños proyectos como a grandes.
Un saludo
Oskar
De hecho, la mejor documentación que se puede hacer sobre un código es el mismo código.
Lo anterior es extensible a los manuales de usuario, el mejor manual de una aplicación es que la misma sea lo suficientemente simple o coherente con la forma de pensar de un usuario como para que no haga falta.
No obstante y en consonancia con los principios ágiles mi visión sobre la documentación no es su eliminación, sino su optimización, la generación de aquella que realmente aporte valor al proyecto o a su trazabilidad, todo lo demás es esfuerzo de más que podíamos haber invertido de otra forma o carga que tenemos que llevar con nosotros a lo largo del resto del proyecto ya que tendremos que estar continuamente actualizándola para que la misma siga teniendo utilidad.
Sin embargo, quien no documenta, como bien comentas, no es empujado por esa visión, sino por el hecho de que es una actividad pesada en comparación con lo que realmente gusta que no es otra cosa que codificar.