Cuanto antes empieces a codificar más tarde terminará el proyecto

Este proverbio, lo he encontrado en la web de Calidad del Software. Le he dado una leída, y me he dicho: "pero qué pedazo de tontería es ésta".

Pensándolo un poco más despacio...no deja de tener razón. Me explicaré.

En mi experiencia, han sido ya muchos proyectos durante todos estos años en los que aunque se ha hecho el debido análisis y diseño, la presión por parte de la gerencia ha acabado obligando a que "el equipo que vaya echando código, y tú en paralelo ya harás el análisis y diseño". Al final, incluso la planificación iba muy por detrás de la ejecución de actividades.

Esto tiene sus contrapartidas:

• Es necesario dar una visión (funcional), que aunque incompleta, permita al equipo "saber hacia dónde va". Esto obliga a que al menos, esté completada esa visión en el análisis funcional. Es decir, no basta con solamente poner los requisitos (historias de usuario en Scrum) que vayan a empezar de forma inmediata.
• Aunque creamos saber "hacia dónde va" nuestro desarrollo, no todo puede hacerse en base a "bloques independientes". Muchas veces, aceptamos que el software evoluciona en cuanto a sus requisitos (véase SCRUM). Sin embargo, estamos ciegos al pensar que la arquitectura del sistema no va a cambiar también. Y aquí es donde los desarrollos iterativos chocan con la triste realidad de tener que incorporar en cada iteración (o release), un gran esfuerzo en integrarse con lo existente, y probarlo todo otra vez.
• El tamaño importa: en un desarrollo pequeño, estos comentarios pueden ser de escasa importancia. El esfuerzo en "asentar" un software sin análisis o diseño o arquitectura, puede ser despreciable. Conforme el tamaño del software aumenta (y es importante identificar muy al principio el tamaño del software), todo esto cobra importancia de forma exponencial.
• Muchas veces se olvida que la documentación de análisis, diseño y arquitectura son parte de los entregables. ¿Por qué? Simplemente porque realizar el mantenimiento de una aplicación, basándose solamente en los comentarios que nos han dejado los antecesores, es un suicidio. Queda muy bien lo de "yo no necesito documentar, ya que dejo buenos comentarios". Esta frase es muy típica de la gente poco experimentada, que apenas ha hecho mantenimientos, o los ha hecho de aplicaciones con poca trayectoria.

Esta frase tampoco tiene porqué ser tomada a la inversa: si vamos retrasando la programación, llega un punto en que la definición ya está casi cerrada. Es absurdo que pretendamos tener el 100% de la documentación cerrada para empezar a programar. Hay que evaluar la madurez de lo que tenemos, y controlar los riesgos de que cambien las cosas.

A este respecto, nada mejor que contar con la experiencia de un buen analista y un buen arquitecto que cierren los puntos clave, un jefe de proyecto experimentado que coordine la aprobación y seguimiento de esta documentación inicial....y a partir de ahí, versionar esa documentación.

La desgracia, es que muchos programadores (por no decir todos), se sienten cómodos aplicando cambios al código. Pero no actualizando la documentación conforme esos mismos cambios. Además, esto se ve agravado con el hecho de que los jefes de equipo y proyecto no fomentan actualizar esa documentación. Así que dada esta escuela de comportamiento, seguimos fomentando las malas prácticas.

Y ojo, no se trata de tocar la documentación con cada línea de código. Si sabemos qué se ha tocado, bastaría juntar cada 2, 3 o 4 semanas de desarrollo, los principales cambios técnicos y funcionales, y dedicar un rato a que algunos documentos no se desfasaran. También aquí hay que ser pragmáticos, si el entregable principal es el documento funcional, apliquemos ahí el mayor esfuerzo. Si es el técnico, pues lo mismo.