Passando de uma história do usuário para o código enquanto estiver usando TDD (scrum)

Estou entrando no scrum e no TDD e acho que tenho alguma confusão sobre a qual gostaria de receber seus comentários. Vamos supor que eu tenha uma história de usuário em minha lista de pendências. Para começar a desenvolvê-la como parte do TDD, preciso ter requisitos, até agora?

É verdade dizer que o gerente de produto e o controle de qualidade devem ser responsáveis ​​por pegar a história do usuário e dividi-la em testes de aceitação?

Eu acho que o exposto acima é verdadeiro, pois os testes de aceitação precisam ser formais, para que possam ser usados ​​como testes, mas também legíveis por humanos, para que o produto possa aprovar que são os requisitos, certo?

Também é verdade que, posteriormente, faço esses testes de aceitação e os uso como meus requisitos, ou seja, são um conjunto de casos de uso que eu implemento (por meio do TDD)? Espero não estar bagunçando muito, mas esse é o fluxo atual que tenho em mente agora.

Atualização
Acho que minhas intenções iniciais não eram claras, então tentarei reformular. Quero saber mais detalhes sobre o fluxo scrum de transformar uma história de usuário em código enquanto estiver usando TDD.
O ponto de partida é óbvio: um usuário apresenta uma necessidade (ou o representante do usuário como produto), que é uma descrição curta de 1 a 2 linhas no formato conhecido e que é adicionada à lista de pendências do produto.
Quando há um planejamento de primavera, as histórias de usuários são retiradas da lista de pendências e atribuídas aos desenvolvedores.
Para que um desenvolvedor escreva código, eles precisam de requisitos (especialmente no TDD, pois os requisitos são de onde os testes são derivados).
Quando, por quem e em qual formato os requisitos são compilados?
O que eu tinha em mente era que o produto e o controle de qualidade definem os requisitos por meio de testes de aceitação (estou pensando em usar o FitNesse automaticamente ou o tipo, mas esse não é o principal, acho) que ajuda a servir a dois propósitos ao mesmo tempo:

1. Eles definem "Concluído" corretamente.
2. Eles dão ao desenvolvedor algo para derivar testes.

Eu não tinha certeza de quando eles foram escritos (antes da sprint eles são escolhidos, isso pode ser um desperdício, pois informações adicionais chegarão ou a história não será escolhida. Durante a iteração, o desenvolvedor pode ficar parado esperando por eles. ..)

É verdade dizer que o gerente de produto e o controle de qualidade devem ser responsáveis ​​por pegar a história do usuário e dividi-la em testes de aceitação?

Na maioria das vezes. Eles podem realmente não escrever o teste de aceitação real. Eles podem aprovar algo que você escreveu. Mas eles aprovam os testes de aceitação. Sim.

os testes de aceitação precisam ser formais, para que possam ser usados ​​como testes, mas também legíveis por humanos, para que o produto possa aprovar que são os requisitos, certo?

Irrelevante. Eles podem ser formalizados como testes automatizados. Ou eles podem ser informais e pode ser seu trabalho criar testes automatizados a partir dos critérios de teste de aceitação informal.

Além disso. Os "requisitos" são a história do usuário. Não há necessidade real de criar mais uma versão da história chamada "requisitos". Algumas pessoas gostariam de elaborar a história antes de codificarem. Você pode chamar isso de requisitos, mas "design" é uma palavra melhor. "Elaboração" é a melhor palavra.

Também é verdade que, posteriormente, faço esses testes de aceitação e os uso como meus requisitos, ou seja, são um conjunto de casos de uso que eu implemento (por meio do TDD)?

Sim. A história leva a testes de aceitação. A história é um comportamento necessário (ou seja, "requisitos"). A história leva a testes que conduzem o design e desenvolvimento de software.

esse é o fluxo atual que tenho em mente agora.

Não há realmente muito "fluxo" para isso.

História -> testes de aceitação.

História -> elaboração ("design", "requisitos") -> testes de unidade -> código.

História -> Usuário capaz de fazer algo de valor.

História -> Pontos da história -> cálculo de velocidade.

Observe o padrão. A história basicamente guia tudo.

Quando, por quem e em qual formato os requisitos são compilados?

Primeiro. Defina "requisitos". Qual a diferença da história em si?

O que eu tinha em mente era que o produto e o controle de qualidade definiam os requisitos por meio de testes de aceitação

Normalmente não.

durante a iteração, o desenvolvedor pode ficar parado esperando por eles.

Incorreta. O desenvolvedor pode (e geralmente o faz) ajudar a escrevê-los. Esse é o ponto do "desenvolvimento": elabore a história para um "bem feito" bem definido.

Novamente. Quando você tiver dúvidas ou perguntas, deve ler o Manifesto Ágil. O Manifesto é bastante claro: os desenvolvedores devem conversar com os proprietários do produto, usuários, controle de qualidade e todos os demais que são partes interessadas. A interação é realmente a coisa mais importante que pode acontecer.

Vou responder da perspectiva da Extreme Programming (XP) sobre os testes de aceitação.

Quando eu estava entrando (e lendo os livros), li que era realmente o papel do desenvolvedor trabalhar com o cliente / usuário para desenvolver / documentar os testes de aceitação. Um dos objetivos do XP é aumentar a comunicação direta entre o usuário / cliente e o desenvolvedor. Isso geralmente é ideal, pois reduz a possibilidade de erros de codificação devido à falta de comunicação dos requisitos.

Faço TDD há cerca de 8 anos e segui a abordagem acima. Eu acho que melhorou a velocidade do desenvolvimento e a satisfação com o sistema, porque clientes / usuários veem como estão influenciando diretamente o desenvolvimento do aplicativo.

A principal dificuldade que encontrei (com clientes menores) é que é muito difícil fazê-los participar na especificação de testes de aceitação. (Geralmente, eu tenho que fazer isso por eles e enviá-los para revisão.) Os clientes maiores com quem trabalhei geralmente têm essa mentalidade; portanto, estavam preparados para fornecer testes de aceitação específicos.

Pelo que li sobre scrum, não tenho certeza se define qual função é responsável por definir / escrever testes de aceitação. Presumo que possa variar de equipe para equipe.

Meu conselho é que você, como desenvolvedor, participe o máximo possível do processo de definição de teste. E o objetivo é colocar os resultados do sprint na frente dos usuários o mais rápido possível, para que eles possam dizer tudo o que se esqueceram de pensar (ou o que disseram incorretamente) o mais rápido possível.

A história do usuário não é "Como usuário, quero XXX para que AAAA" ! A história do usuário é uma promessa para a comunicação futura com o PO. Isso resolve seu problema com mais detalhes. Você deve se comunicar com o PO durante o sprint para obter as informações necessárias.

A história do usuário também possui mais recursos do que a frase curta que promete a comunicação. Parte necessária da história do usuário são critérios de aceitação. Os critérios de aceitação devem ser conhecidos antes de se comprometer com a história do usuário (eles devem ser conhecidos antes da estimativa da história do usuário). Os critérios de aceitação são a entrada para os testes de aceitação = os testes de aceitação devem testar os critérios de aceitação.

Portanto, quando você começa a trabalhar na história do usuário com a abordagem TDD, primeiro você (e não o controle de qualidade) deve criar um teste de aceitação automatizado com base em critérios de aceitação para obter uma falha no teste. Você continuará implementando o código necessário usando TDD antes da aprovação no teste de aceitação. Você continuará com o próximo teste de aceitação. Eu escrevi sobre isso também em outra pergunta .