La Gran Brecha de la Fatalidad

Acabo de verme enterita una presentación de Dan North y Martin Fowler en la QCon 2007 de Londres titulada “The Yawning Crevasse of Doom” (La Gran Brecha de la Fatalidad) donde hablan (durante 1 hora) sobre la necesidad de construir puentes de comunicación entre el negocio y la técnica. Llegué a ella a partir del blog de Gojko Adzic (que está preparando un libro sobre pruebas de aceptación ágiles) y de ella es posible obtener muy buenos argumentos y técnicas agilistas. Insisto: muy recomendable.

Durante 1 hora da para decir muchas cosas, pero yo me quedaría con lo siguiente:

Construir puentes
En vez de tener a los analistas yendo y viniendo entre los usuarios y los técnicos (la brecha), es mejor conseguir que la organización permita establecer puentes entre ambos mundos. Aquí insisten en la importancia vital de las conversaciones entre usuarios y técnicos porque ayudan a evitar trabajar en funcionalidades que no aportan valor de negocio y además permiten encontrar mejores soluciones que trabajando a través de intermediarios.

Fatalidad
Si creemos que no es posible construir esos puentes, estaremos de alguna manera influyendo en nuestro entorno para que la brecha se siga manteniendo e incluso se amplíe. Así se defienden unas partes de otras mediante contratos, documentos de requisitos, diagramas de arquitectura… En cambio, si la actitud es positiva, es posible colaborar en un entorno de confianza en la que incluso se pueda trabajar en construir un sistema sin conocer cómo será el “desplegable” final.

Lenguaje ubicuo
Para que todos dentro del equipo (gente de negocio y gente técnica) puedan entenderse es conveniente usar un lenguaje ubicuo (tal y como recomienda Eric Evans en su estupendo libro “Domain-Driven Design“).
Sin embargo, el uso de un lenguaje común entre usuarios y técnicos que permita y/o facilite la comunicación entre ambas orillas no debe obligarnos a que este lenguaje sea “universal” para toda la empresa. Fowler dice explícitamente que es mejor un conjunto de “modelos locales” (más manejables y comprensibles y menos abstractos) y un mecanismo de mapeo entre ellos.

Construir juntos
Técnicas como construir juntos “Prototipos de baja fidelidad” (ya sabéis, “paper prototyping” con Post-Its, etc), “Storyboards” (como los que se usan para las películas de cine),… ayudan a construir esos puentes.

Hecho
Para especificar qué entienden los usuarios y los técnicos por “tarea completada” es conveniente utilizar ejemplos, idealmente que se puedan comprobar automáticamente. (Es lo que se conoce como pruebas de aceptación ejecutables).

Suficiente
Otro término muy relacionado con “hecho” es “suficiente”. Se trata de conocer lo suficiente para avanzar hasta el siguiente paso. Para ello es necesario asumir que las prioridades están en constante cambio durante la construcción del proyecto.

Productividad
Un detalle, ¿sabíais que sólo el 15% aprox del coste total del software corresponde a la programación?
Es muy importante trabajar continuamente en encontrar todas las oportunidades posibles que nos permitan recoger reacciones (feedback) de todos los miembros del equipo y conocer aquellos factores puedan afectar al estado de ánimo del equipo puesto que éste es un aspecto psicológico que afecta significativamente a la comunicación y, por tanto, a la productividad.