Una de las claves de ATDD es justamente que nos permite centrarnos en el qué y no en el cómo. Aprovechamos los frameworks tipo Concordion para desarrollar nuestra habilidad de preguntar al cliente qué quiere y no cómo lo quiere. Evitamos a toda costa ejemplos que se meten en el cómo hacer, más allá del qué hacer:
- Al rellenar el cuadro de texto de buscar y pulsar el botón contiguo, los resultados aparecen en la tabla de la derecha
- Al introducir la fecha y hacer click en el botón de añadir, se crea un nuevo registro vacío
- Los libros se almacenan en la tabla Libro con campos:
id,tituloyautor - Seleccionar la opción de borrar del combo, marcar con un tick
- las líneas a borrar y verificar que se eliminan de la tabla al pulsar el botón aplicar.
- Aplicación Flash con destornilladores y tornillos girando en 3D para vender artículos de mi ferretería por Internet
Cuando partimos de especificaciones como estas corremos el riesgo de pasar por alto el verdadero propósito de la aplicación, la información con auténtico valor para el negocio del cliente. Salvo casos muy justificados, el Dueño del Producto no debe decir cómo se implementa su solución, igual que no le decimos al fontanero cómo tiene que colocar una tubería.
La mayoría de las veces, el usuario no sabe exactamente lo que quiere pero, cuando le sugerimos ejemplos sin ambigüedad ni definiciones, generalmente sabe decirnos si es o no es eso lo que busca. Uno de los motivos por los que el cliente se empeña en pedir la solución de una determinada manera es porque se ha encontrado con profesionales poco experimentados que no le han sabido sugerir las formas adecuadas o que no llegaron a aportarle valor para su negocio.
Con ATDD nos convertimos un poco en psicólogos en lugar de pretender ser adivinos. A base de colaboración encontramos y clasificamos la información que más beneficio genera para el usuario.
Encuentro particularmente difícil practicar ATDD cuando los dueños de producto están mal acostumbrados al sistema clásico en el que el análisis de los requisitos acaba produciendo un diagrama de componentes o módulos y luego un diagrama de clases. En las primeras reuniones de análisis, se empeñan en que dibujemos ese diagrama de módulos en los que el sistema se va a dividir a pesar de que les explique que eso no aporta más valor a su negocio. Les digo que la abstracción de los requisitos en forma de módulos o grupos no sirve más que para contaminar el software con falsos requisitos de negocio y para limitarnos a la hora de implementar, aunque a veces les resulta difícil de ver en un principio.
Los únicos módulos que hay que identificar son los que tienen valor de negocio, es decir, aquellos conjuntos lógicos que tengan relación con una estrategia de negocio. Por ejemplo, de cara a ofrecer determinados servicios: servicio de venta, de alquiler, de consultoría, etc.
La forma en que comprenden el proceso iterativo, es sentándose frente a ellos en un lugar cómodo y adoptando el rol de psicólogo de las películas norteamericanas, abordando los ejemplos. Una vez llevo la voz cantante, empiezo a formular ejemplos para queme digan si son válidos o no. Al principio no son capaces de distinguir entre una descripción y un ejemplo preciso por lo que se apresuran a darme descripciones que consideran suficientes como para implementar el software pero que para mí, ajeno a su negocio, no lo son:
- Buscando por Santa Cruz de Tenerife, aparece una lista de pisos en alquiler.
Entonces reconduzco la conversación haciéndoles ver que su descripción se corresponde en realidad con varios ejemplos.
- Buscando que el precio sea inferior a 600 euros, e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que no superan los 600 euros mensuales de alquiler y que se encuentran en la ciudad de Santa Cruz de Tenerife
- Buscando que el precio esté entre 500 euros y 700 euros y que tenga 2 habitaciones e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que cumplen las tres condiciones
- Buscando que tenga 3 habitaciones y 2 cuartos de baño, e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que cumplen las tres condiciones
- Buscando con el texto "Tenerife", el sistema muestra la lista de pisos de toda la provincia de Santa Cruz de Tenerife
- En la lista, cada piso se muestra mediante una fotografía y el número de habitaciones que tiene
Para responder si los ejemplos son verdaderos o falsos, ellos mismos descubren dudas sobre lo que necesitan para su negocio. Dejan de ir teniendo pensamientos mágicos para ser conscientes de la precisión con que tenemos que definir el funcionamiento del sistema. A partir de ese momento, entienden que la distancia entre los expertos en desarrollo y los expertos en negocio va menguando y dejan de preocuparse por diagramas abstractos.
Entonces dicen... ¿Tenemos que pensar todas estas cosas? Y tengo que contarles que, aunque los ordenadores hayan avanzado mucho, no dejan de ser máquinas muy tontas. Les cuento que si esas decisiones sobre el negocio no me las validan ellos, tendré que decidir yo, que no soy experto en su negocio. Así comienzan a involucrarse más en el desarrollo y todos comenzamos a hablar el mismo idioma.
Al final, todo esto no consiste en otra cosa que en escribir ejemplos e implementarlos.