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.

3 comentarios
  1. oskar dijo:

    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

    • jummp dijo:

      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.

  2. Ricardo dijo:

    Muchas veces me he encontrado que, bajo enfoques tradicionales como Cascada, se produce documentación que se utiliza sólo una vez, y después nadie utiliza. Por ejemplo, las Especificaciones de Diseño se utilizan para que alguien decida que en efecto eso es lo que se quiere. Al final se produce quizás manuales de sistema y de usuario. ¿Que sucede con las Especificaciones de Diseño?, pues nadie las vuelve a utilizar.

    Supongamos que en lugar de hacer eso, elaboramos el Manual de Usuario y Manual de Sistema y utilizamos eso como Especificación de Diseño, nos ahorraríamos dos documentos, ¿no sería un mejor aprovechamiento de recursos?.

    O que por ejemplo, hagamos un Diseño Funcional ligero, en la forma de Historias de Usuario (como establece Scrum por ejemplo) y luego desarrollamos un prototipo funcional que el usuario pueda revisar y aprobar, de esta forma estaríamos avanzando en el desarrollo y especificación del funcionamiento al mismo tiempo, ¿No sería mejor de esta forma?.

    El Manifiesto ágil establece que “Valoramos más el Software que funciona que la documentación exhaustiva”, sin embargo, eso no es una invitación a no documentar nada, es una invitación a documentar solamente lo que realmente tenga significado y sea útil, en lugar de documentar por documentar cosas que nadie va a leer después.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: