Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.