A pesar de la brevedad de este capítulo, puede considerarse probablemente el más importante de todo el libro. Si no somos capaces de entendernos con el cliente, ni la mejor técnica de desarrollo de todos los tiempos producirá un buen resultado.
La mayor diferencia entre las metodologías clásicas y la Programación Extrema es la forma en que se expresan los requisitos de negocio. En lugar de documentos de Microsoft Word, son ejemplos ejecutables. El Desarrollo Dirigido por Test de Aceptación (ATDD), técnica conocida también como Story Test-Driven Development (STDD), es igualmente TDD pero a un nivel diferente.
Los tests de aceptación o de cliente son el criterio escrito de que el software cumple los requisitos de negocio que el cliente demanda. Son ejemplos escritos por los dueños de producto. Es el punto de partida del desarrollo en cada iteración, la conexión perfecta entre Scrum y XP; allá donde una se queda y sigue la otra.
ATDD/STDD es una forma de afrontar la implementación de una manera totalmente distinta a las metodologías tradicionales. El trabajo del analista de negocio se transforma para reemplazar páginas y páginas de requisitos escritos en lenguaje natural (nuestro idioma), por ejemplos ejecutables surgidos del consenso entre los distintos miembros del equipo, incluido por supuesto el cliente. No hablo de reemplazar toda la documentación, sino los requisitos, los cuales considero un subconjunto de la documentación.
El algoritmo es el mismo de tres pasos pero son de mayor zancada que en el TDD practicado exclusivamente por desarrolladores. En ATDD la lista de ejemplos (tests) de cada historia, se escribe en una reunión que incluye a dueños de producto, desarrolladores y responsables de calidad. Todo el equipo debe entender qué es lo que hay que hacer y por qué, para concretar el modo en que se certifica que el sotfware lo hace. Como no hay única manera de decidir los criterios de aceptación, los distintos roles del equipo se apoyan entre sí para darles forma.