Especificando con ambigüedad

En múltiples ocasiones he escuchado el término 'ambigüedad', que hay que evitarla, que no debemos incurrir en ella, que los requerimientos son ambiguos etc. etc. ¿Alguien se ha planteado qué significa este enemigo de la humanidad (y de los proyectos) llamado ambigüedad? Pues simplemente significa que 'algo' se puede interpretar de 'distintas' maneras. Y eso ¿en qué nos afecta? Supongamos que un conjunto de requerimientos es documentado por el equipo de análisis, la forma en que ellos hayan descrito al requerimiento dará lugar a una buena implementación de dicha especificación en el producto. La lista de requerimientos pasará por varias manos, y si existen requerimientos ambiguos, cada quien los entenderá a su manera, cada quien le dará un significado diferente al requerimiento (con eso de que cada cabeza es un mundo) y al final tendremos que diferentes miembros del equipo entendieron el mismo requerimiento de diferentes formas.

Si un requerimiento no se encuentra debidamente detallado (empezamos con imprecisiones), entonces producirá ambigüedad. Pero los requerimientos pueden ser ambiguos incluso por la forma en que están redactados, entonces tenemos que cuidar hasta el lenguaje con el que describimos los requerimientos. El decir 'el sistema debe ser flexible' realmente carece de significado, más bien deberíamos indicar las formas en que el sistema podría cambiar para responder a los cambios del entorno o del negocio. O en ocasiones he leído requerimientos que dicen: 'el sistema no debe' (negatividad y ambigüedad pura), no no y no (hablando de negatividad) los requerimientos deben de ser positivos y enunciar aquellas acciones que el sistema debe realizar. Otro ejemplo de un requerimiento ambiguo es 'el sistema debe acelerar la velocidad del proceso de negocio x', pensemos... como diantres vamos a saber cuales son los valores mínimos aceptables de velocidad para el 'proceso de negocio x' si no lo tenemos especificado. Estás lagunas de ambigüedad forzaran en la mayoría de los casos a que el desarrollador interprete e implemente a su juicio un requerimiento, algo así como 'rellenar los espacios en blanco'.

Pero claro, se nos está olvidando un rol que rara vez existe en un proyecto y nos podría auxiliar en el combate de la ambigüedad... si adivinaron, el arquitecto de software. Esta persona tiene la dura tarea de enfrentarse a las ambigüedades de los requerimientos y rellenar aquellos vacíos. Esta persona bien nos podría ahorrar el hecho de que cada desarrollador interprete a su manera un mismo requerimiento (pausa... el mismo requerimiento podría estar implementado mas de una sola vez de distintas maneras en un mismo proyecto). Y bien, esta persona podría ahorrarnos bastante tiempo en el proyecto, ya que un requerimiento ambiguo se podría convertir en tiempo desperdiciado de desarrollo, ya que podríamos haber implementado una solución acertada para un problema equivocado. Y si nos vamos mas allá del desarrollo... pongamos un ejemplo de un tester, leyendo e interpretando un requerimiento ambiguo a su manera, el tester realizará una suposición de lo que 'debe hacer' dicho requerimiento, la cual es muy probable que sea una interpretación distinta a la del desarrollador que lo implementó, y al final hasta podrían llegar a un interminable debate sobre de 'quien tiene la razón'.

Lo anterior no significa que debamos leer los requerimientos como desquiciados en busca de ambigüedades, mas bien significa que debemos de estar conscientes del problema que estos representan, tratar de llevar un buen control de cambios de los requerimientos, diseñar nuestros casos de pruebas (regresando al ejemplo de 'el sistema debe acelerar la velocidad del proceso de negocio x', no hay manera de probar si el sistema cumple con este requerimiento, por lo tanto al intentar diseñar un caso de prueba para este requerimiento se descubrirá la ambigüedad), y sobre todo mantener informados a todo el equipo acerca de cuales son los requerimientos.

Corregir una ambigüedad en una etapa tardía del proyecto será costoso. Pero pues para nuestro objetivo del blog que es desadministrar proyectos, las ambigüedades son aceptables siempre y cuando no se excedan del rango permitido de manera razonable y suficiente (nunca había visto tanta ambigüedad en una sola frase), total... que más puede pasar si una simple línea que detalla un requerimiento se puede interpretar de distintas maneras (sarcasmo puro).