Pasar de una historia de usuario a código mientras se usa TDD (scrum)

Me estoy metiendo en scrum y TDD y creo que tengo cierta confusión sobre la que me gustaría recibir sus comentarios. Supongamos que tengo una historia de usuario en mi cartera de pedidos, para poder comenzar a desarrollarla como parte de TDD. Necesito tener requisitos, ¿hasta ahora?

¿Es cierto decir que el gerente de producto y el control de calidad deberían ser responsables de tomar la historia del usuario y desglosarla en pruebas de aceptación?

Creo que lo anterior es cierto ya que las pruebas de aceptación deben ser formales, para que puedan usarse como pruebas, pero también legibles por humanos para que el producto pueda aprobar que son los requisitos, ¿verdad?

¿Es también cierto que luego tomo estas pruebas de aceptación y las uso como mis requisitos, es decir, son un conjunto de casos de uso que implemento (a través de TDD)? Espero no estar haciendo un gran desastre, pero ese es el flujo de corriente que tengo en mente en este momento.

Actualización
Creo que mis intenciones iniciales no estaban claras, así que intentaré reformular. Quiero saber más detalles sobre el flujo de scrum de convertir una historia de usuario en código mientras uso TDD.
El punto de partida es obvio, un usuario muestra una necesidad (o el representante del usuario como producto), que es una breve descripción de 1-2 líneas en el formato conocido y que se agrega a la cartera de pedidos del producto.
Cuando hay una reunión de planificación de primavera, las historias de usuarios se toman del trabajo atrasado y se asignan a los desarrolladores.
Para que un desarrollador escriba código, necesita requisitos (especialmente en TDD, ya que los requisitos son de los que se derivan las pruebas).
¿Cuándo, por quién y con qué formato se compilan los requisitos?
Lo que tenía en mente era que el producto y el control de calidad definen los requisitos a través de pruebas de aceptación (estoy pensando en usar automáticamente FitNesse o algo así, pero creo que ese no es el núcleo) que ayudan a cumplir 2 propósitos al mismo tiempo:

1. Definen "Hecho" correctamente.
2. Le dan a un desarrollador algo de lo que derivar pruebas.

No estaba seguro de cuándo se escribieron (antes del sprint que se seleccionaron, entonces eso podría ser un desperdicio ya que llegará información adicional o la historia no se elegirá, durante la iteración, entonces el desarrollador podría quedarse atrapado esperándolos. ..)

¿Es cierto decir que el gerente de producto y el control de calidad deberían ser responsables de tomar la historia del usuario y desglosarla en pruebas de aceptación?

Principalmente. Es posible que en realidad no escriban la prueba de aceptación real. Pueden aprobar algo que usted escribió. Pero aprueban las pruebas de aceptación. Si.

las pruebas de aceptación deben ser formales, para que puedan usarse como pruebas, pero también legibles por humanos para que el producto pueda aprobar que son los requisitos, ¿verdad?

Irrelevante. Pueden formalizarse como pruebas automatizadas. O pueden ser informales y puede ser su trabajo crear pruebas automatizadas a partir de los criterios de prueba de aceptación informal.

También. Los "requisitos" son la historia del usuario. No hay necesidad real de crear otra versión de la historia llamada "requisitos". A algunas personas les gusta elaborar la historia antes de codificar. Puede llamar a estos requisitos, pero "diseño" es una palabra mejor. "Elaboración" es la mejor palabra.

¿También es cierto que luego tomo estas pruebas de aceptación y las uso como mis requisitos, es decir, son un conjunto de casos de uso que implemento (a través de TDD)?

Si. La historia lleva a pruebas de aceptación. La historia es un comportamiento obligatorio (es decir, "requisitos"). La historia conduce a pruebas que impulsan el diseño y desarrollo de software.

ese es el flujo de corriente que tengo en mente en este momento.

Realmente no hay mucho "flujo" para esto.

Historia -> pruebas de aceptación.

Historia -> elaboración ("diseño", "requisitos") -> pruebas unitarias -> código.

Historia -> El usuario puede hacer algo de valor.

Historia -> Puntos de historia -> cálculo de velocidad.

Tenga en cuenta el patrón. La historia conduce en gran medida todo.

¿Cuándo, por quién y con qué formato se compilan los requisitos?

Primero. Definir "requisitos". ¿En qué se diferencian de la historia misma?

Lo que tenía en mente era que el producto y el control de calidad definen los requisitos mediante pruebas de aceptación.

No Usualmente.

durante la iteración, entonces el desarrollador podría quedarse atascado esperándolos.

Incorrecto. El desarrollador puede (y a menudo lo hace) ayudar a escribir esto. Ese es el punto de "desarrollo": elaborar la historia a un "hecho" bien definido.

De nuevo. Cuando tenga dudas o preguntas, debe leer el Manifiesto Ágil. El Manifiesto es bastante claro: los desarrolladores deben hablar con los propietarios de los productos, los usuarios, el control de calidad y todos los demás interesados. La interacción es en realidad lo más importante que puede suceder.

Le responderé desde la perspectiva de Extreme Programming (XP) con respecto a las pruebas de aceptación.

Cuando me metí por primera vez (y leí los libros), leí que realmente es el rol del desarrollador trabajar con el cliente / usuario para desarrollar / documentar las pruebas de aceptación. Uno de los objetivos de XP es aumentar la comunicación directa entre el usuario / cliente y el desarrollador. Esto suele ser ideal, ya que reduce la posibilidad de errores de codificación debido a la falta de comunicación de los requisitos.

He estado haciendo TDD durante aproximadamente 8 años y he seguido el enfoque anterior. Creo que ha mejorado la velocidad de desarrollo y la satisfacción con el sistema porque los clientes / usuarios ven cómo influyen directamente en el desarrollo de la aplicación.

La principal dificultad con la que me he encontrado (con clientes más pequeños) es que es muy difícil lograr que participen en la especificación de pruebas de aceptación. (Por lo general, tengo que hacerlo por ellos y enviárselos para que los revisen). Los clientes más grandes con los que he trabajado suelen tener esta mentalidad, por lo que estaban preparados para proporcionar pruebas de aceptación específicas.

Por lo que he leído sobre scrum, no estoy seguro de que defina qué rol es responsable de definir / escribir las pruebas de aceptación. Supongo que puede variar de un equipo a otro.

Mi consejo es que, como desarrollador, debe participar tanto como sea posible en el proceso de definición de la prueba. Y el objetivo es obtener los resultados del sprint frente a los usuarios lo más rápido posible, para que puedan contarle todo lo que olvidaron (o lo que le dijeron incorrectamente) lo más rápido posible.

¡La historia de usuario no es "Como usuario quiero XXX para que YYY" ! La historia del usuario es prometedora para futuras comunicaciones con PO. Eso resuelve tu problema con más detalles. Debe comunicarse con PO durante el sprint para obtener la información que necesita.

La historia del usuario también tiene más características que la frase corta que promete la comunicación. Parte necesaria de la historia del usuario son criterios de aceptación. Los criterios de aceptación deben conocerse antes de comprometerse con la historia del usuario (deben conocerse antes de estimar la historia del usuario). Los criterios de aceptación son la entrada para las pruebas de aceptación = las pruebas de aceptación deben probar los criterios de aceptación.

Entonces, cuando comience a trabajar en la historia del usuario con el enfoque TDD, usted (no el control de calidad) primero debe crear una prueba de aceptación automática basada en los criterios de aceptación para obtener una prueba fallida. Continuará implementando el código necesario utilizando TDD antes de la aprobación de la prueba de aceptación. Continuará con la próxima prueba de aceptación. Escribí sobre eso también en otra pregunta .