Los criterios de aceptación, dado/cuando/entonces, ¿reducen la legibilidad de la historia de usuario?

Estoy creando criterios de aceptación para historias de usuarios.

Ya que parece ser la principal forma de hacerlo en mi empresa actual.

Siento que Given/When/Then siempre degrada la legibilidad de la historia del usuario y aumenta la comunicación innecesaria.

¿Alguien se ha encontrado con este problema o solo yo?

Si es el problema de los datos reales, hay algunas opciones en las que pienso

  1. Escriba la viñeta AC simplificada y escriba G/W/T como un caso de prueba para cada viñeta (Consume mucho tiempo para PO y puede perder el enfoque para refinar el producto).

  2. Escriba el AC de viñetas simplificado y si el equipo realmente lo necesita, simplemente créelo por sí mismo. (Consume mucho tiempo para el equipo y puede perder el enfoque para la entrega).

  3. O debería presionar para deshacerme de él por completo, y usar esos puntos simplificados como casos de prueba.

¿Qué opción sugeriría, por qué? ¿Y hay algo más que pueda hacer?

Esa es una queja muy común. BDD es un buen concepto a primera vista, pero en la práctica es tan ineficaz desde cualquier lado: BA, QA, Dev. Mencione esto con el equipo, piense si lo que escuchó al respecto es realmente cierto o es solo otro cuento de hadas de marketing.
El propietario del producto es un miembro de pleno derecho del equipo Scrum. Deberían colaborar con los Desarrolladores para refinar las historias e identificar los criterios de aceptación. El tiempo del PO no es más importante que el del resto del Equipo Scrum, ni el PO debe trabajar de forma aislada. Ambos son olores de implementación del marco.

Respuestas (2)

El formato Dado/Cuando/Entonces es útil cuando se automatizan los criterios de aceptación y se escriben pruebas para verificarlos. Básicamente, escribe una prueba para cada uno de sus Given/When/Then .

Marcaste tu pregunta como BDD, por lo que parece que querrás seguir con este formato. La ventaja es que pasa unos minutos resolviendo sus pruebas de aceptación y luego las escribe. Si usa listas con viñetas, ¿cuántas pruebas de aceptación derivará de cada viñeta? ¿Y quién decidirá, el desarrollador, el PO? Puede terminar con el mismo resultado al final, entonces, ¿por qué no hacer un esfuerzo por adelantado para evitar perder algunos casos de prueba más adelante?

Pero realmente depende de cómo los uses. Si está utilizando este formato solo como una forma elegante de enumerar los criterios de aceptación, y no para escribir pruebas de aceptación ejecutables a partir de ellos, entonces tal vez una lista con viñetas con un lenguaje más natural funcione mejor.

Siempre puede preguntarle a su equipo de qué manera lo prefieren, y también puede experimentar en ambos sentidos y seguir con el enfoque que funcione mejor.

Dado-cuándo-entonces es una forma de detallar escenarios en lugar de historias de usuarios.

Un formato común es tener una historia de usuario seguida de uno o más escenarios de tiempo determinado asociados con esa historia. En efecto, el dado-cuándo-entonces se convierte en el criterio de aceptación de la historia.