Imagina que tu equipo se embarca en un nuevo proyecto. El equipo de producto entrega las historias de usuario y los wireframes, perfectamente empaquetados, y todo el mundo parece satisfecho. Los requisitos parecen suficientemente claros; nadie quiere hacer demasiadas preguntas en esta coyuntura.
Parece que el tren ha salido de la estación. El jefe de producto está de pie en la cabecera de la sala o en Zoom, hablando sin parar de lo mucho que el equipo ha invertido en el producto.
El resultado es que el equipo de desarrollo se sumerge con optimismo, pero bajo ese optimismo se esconde un riesgo silencioso: ¿Están construyendo lo correcto? Rara vez alguien se detiene a pedir más información, a profundizar en la intención subyacente detrás de esas historias o wireframes.
La claridad inicial es una ilusión, y las grietas empiezan a aparecer, no inmediatamente, sino más tarde; los plazos de desarrollo se esfuman, falla el control de calidad (QA) y, si se llega a las pruebas de aceptación del usuario (UAT), podemos hablar de ese problema más tarde.
Es en estos lugares donde los malentendidos salen a la superficie. Las características se comportan de forma inesperada. No se han tenido en cuenta los casos extremos. La interpretación de los requisitos por parte del equipo choca con las expectativas de las partes interesadas. Lo que parecía un progreso constante, de repente requiere una revisión. Y no sólo pequeños retoques: a veces hay que volver a la mesa de dibujo. Una comprensión incompleta se ha convertido en un trabajo incompleto.
La dirección no entiende lo que está pasando. Han visto las historias de usuario y los wireframes, así que es culpa del desarrollador, ¿no?
No. Es culpa del proceso. Entonces, ¿qué hacer?
Creación de productos digitales
BDD (desarrollo basado en el comportamiento) es una metodología que nos ayuda a crear las características de producto adecuadas para nuestros clientes. El método nos obliga a profundizar más en el producto que estamos construyendo que simplemente utilizando historias de usuario para definir un producto.
Historias de usuarios: Un punto de partida
Las historias de usuario proporcionan una amplia comprensión de una característica desde la perspectiva de un usuario. Suelen ser breves y seguir este formato «Como [rol de usuario], quiero [algún objetivo] para que [alguna razón]».
Aunque las historias de usuario son esenciales, a menudo carecen de detalles. Describen lo que el usuario quiere conseguir, pero no necesariamente cómo. Utilízalas como punto de partida, no como toda la «historia».
Desarrollo orientado al comportamiento: Profundizando
Las historias BDD ofrecen ejemplos concretos de cómo interactúa un usuario con una funcionalidad y cuáles son los resultados esperados. Siguen un formato estructurado:
Aunque los enunciados «y» pueden añadir condiciones adicionales, deben utilizarse con moderación para simplificar la historia.
Un consejo profesional: Evite por completo las sentencias «or». Aunque algunas personas enseñan BDD con sentencias «or», tienden a confundir a los desarrolladores. Si necesita una «or», escriba una historia separada.
Para mayor claridad, nos gusta emparejar cada historia de usuario tradicional con un escenario escrito en el formato dado-cuando-entonces. Esto asegura que todo el mundo entiende lo que está leyendo y crea una conexión más fuerte entre los objetivos abstractos y las acciones específicas.
BDD: el «cómo», no sólo el «qué
El BDD se centra en el «cómo», exigiendo a los diseñadores que describan los pasos necesarios para alcanzar el objetivo de un usuario. Una ventaja significativa de BDD es que los escenarios son comprobables cuando se escriben correctamente.
BDD también mejora los equipos de producto. Escribir de esta forma estructurada obliga a los diseñadores de productos a ir más allá de las ideas abstractas, considerar casos extremos y definir ejemplos concretos de cómo debería funcionar una función. Este proceso de pensamiento más profundo conduce a una comprensión más clara del resultado deseado.
Conclusión
Cuando formamos a equipos de producto y desarrollo, a menudo descubrimos que la raíz de los problemas es la falta de comunicación sobre lo que hay que construir. Aunque los directivos puedan culpar a los desarrolladores, el verdadero problema suele ser la mala definición de las especificaciones.
BDD ayuda a los equipos de producto a pensar en profundidad sobre los nuevos productos y garantiza que desarrolladores y probadores estén alineados. Reducir los malentendidos ahorra tiempo y dinero y mejora el impulso. Cuando se hace bien, BDD mejora significativamente las posibilidades de entregar un gran producto y puede salvar la brecha entre los objetivos abstractos y los pasos prácticos, garantizando una mejor alineación entre los equipos y resultados de mayor calidad.
El contenido original de esta nota fue publicado en Forbes.com. Para leer la nota completa ingresá acá
