Como as histórias de usuários não podem conter requisitos (quando gravadas em um cartão) e ainda podem ser implementadas

Foi-me dito que "Histórias de usuários não são requisitos, é apenas um lembrete do que o cliente deseja, você não pode colocar requisitos em uma história". Mas vamos dar como exemplo que um cliente deseja um processamento diferente para diferentes cartões de crédito. Existem requisitos rigorosos que devem ser implementados e conhecidos para que casos de teste possam ser escritos. Para onde devem ir os requisitos, se não estiverem na história do usuário?

Como os desenvolvedores podem desenvolver a partir de uma história se não houver requisitos mais baixos? Como os testadores podem escrever casos de teste (detalhados) com base na história do usuário? Onde requisitos como restrições de banco de dados, validação de campos etc. residem fora da história do usuário?

Esta resposta se concentrará em como trabalhar com histórias de usuário e requisitos de nível inferior. Não discutirei as virtudes, ou a falta delas, de Scrum ou Agile. Também não vou falar de gurus.

Esta resposta assume que você está no Scrum, mas ainda não encontrou uma maneira de fazê-lo funcionar para você.

Como outros já mencionaram, as Histórias de Usuário destinam-se a cobrir como os Usuários gostariam que o software fosse. Como os Usuários não se importam com coisas de implementação de baixo nível, como tabelas de banco de dados, restrições, padrões de arquitetura etc., você não encontrará esses detalhes em uma História de Usuário.

No entanto, isso não significa que esses detalhes não devem ser registrados em nenhum lugar.

Quando os desenvolvedores implementam as Histórias de usuário, precisam estar cientes dos detalhes de nível inferior que os usuários comuns não sabem. Essas informações podem vir de PMEs, BAs, Dono do produto, seu arquiteto ou qualquer outro especialista ou pessoa de espírito técnico.

Isso significa que detalhes de baixo nível devem ser registrados nas User Stories? Não e sim).

Em algum momento entre o momento em que a história é criada e implementada, alguém precisará descobrir como implementá-la. Isso geralmente toma a forma de conversas com as pessoas envolvidas na história (usuário, arquiteto, desenvolvedor, etc.). Essas conversas devem resultar em critérios de aceitação inequívocos que definem claramente o escopo da implementação da história do usuário. Esses detalhes precisarão ser registrados em algum lugar e onde isso realmente depende de você. A chave aqui é que esses detalhes são obtidos após a criação da história do usuário. Eu acho que é isso que seu guru está tentando enfatizar.

Como desenvolvedor, fica claro que você precisará de uma maneira de associar requisitos mais específicos à sua história do usuário. A maneira como você faz isso depende inteiramente de sua equipe.

Se as pessoas da sua equipe quiserem manter esses detalhes fora das Histórias de Usuário, talvez seja necessário respeitá-lo. Existem benefícios em manter suas Histórias de Usuário de alto nível livres de detalhes de implementação. Ele os mantém enxutos e seu backlog pode ser lido como um histórico do que seus Usuários e Dono do Produto desejavam. Apenas faça com que suas necessidades como desenvolvedor sejam conhecidas. Você deve ser capaz de elaborar um compromisso em que simplesmente vincular a história do usuário mantenha todos felizes.

Sim, é BS. E Scrum não é ágil.

Odeio a rigidez dos chamados praticantes ágeis que lhe dizem que há uma maneira de agir com agilidade e que você deve seguir todas as regras estabelecidas nas escrituras sagradas da metodologia 'ágil' que eles usam. É tudo BS.

Agile é ser ágil.

Agile é sobre fazer as coisas com um mínimo de sobrecarga. Isso não significa "sem documentação", como você geralmente documenta mais em uma função ágil, apenas continua a documentação sem ter que planejar um processo para fazer a documentação. Da mesma forma com a codificação, testes e captura de requisitos. As únicas coisas que importam em um processo ágil são aquelas que ajudam você a realizar seu trabalho, de forma rápida e eficiente, sem qualquer BS.

Portanto, nesse caso, se colocar os requisitos do usuário nos cartões ajuda a escrever, testar, documentar e demonstrar o código necessário ... coloque os requisitos no cartão e diga aos gurus que a equipe está sempre certa.

O que o resto da sua equipe de desenvolvimento pensa? Em uma verdadeira metodologia ágil, se todos eles acham que os requisitos devem ser escritos antecipadamente sem nenhuma 'conversa do usuário', então deve ser isso, você faz o que a equipe acha que funciona melhor para eles fazerem seu trabalho. Se a equipe achar que as conversas com os usuários são boas, ouça-as e entenda por que elas pensam isso e traga a você o modo de trabalhar delas.

Apenas não chame isso de História do usuário e todos ficarão felizes.

Eu acho que a resposta é: você pode escrever isso onde quiser.

Em geral, implementações específicas não são incluídas na história do usuário por alguns motivos:

1. Você sabe o que o cliente deseja, mas não sabe como ele será implementado.
2. O cliente está ciente de que existem requisitos mais específicos envolvidos, mas realmente não se importa e / ou os entende de qualquer maneira.
3. Todo mundo pensa que está totalmente ciente das implementações específicas no momento, mas ninguém quer anotá-las porque, em sua experiência, tudo vai mudar de qualquer maneira e ninguém vai querer reescrevê-las.

Não há regras que omitam documentos adicionais quando necessário. Talvez o cliente precise acessar e talvez não. Se você espera gerar algum tipo de contrato entre você e o cliente na implementação específica, como se você pudesse segui-lo e quando não funcionar, culpe o cliente por concordar com isso, você está enganado. Se o cliente entender os detalhes técnicos do processamento do cartão de crédito, compartilhe esses documentos com eles e, possivelmente, faça parte da conversa.

Acho que se o que seus consultores do Scrum estão dizendo é que o Scrum não exige requisitos, então você tem alguns consultores muito ruins. Eles estão errados em dizer que uma história de usuário não é de fato um requisito, apenas um tipo de requisito.

Quais são os diferentes tipos de requisitos de software?

Requisitos de negócio

Geralmente, é uma necessidade comercial de alto nível, algo que geralmente equivaleria a algum tipo de declaração de estilo executivo sobre um sistema. É propositadamente alto nível e amplo e, por si só, não pode ser implementado sem muito mais detalhes.

Requisitos do usuário

Esses são os requisitos da história do usuário com os quais você está familiarizado. Eles geralmente podem caber em uma nota adesiva.

• Ator - Normalmente, um usuário ou parte interessada.
• Necessário - Algum item ou funcionalidade geral necessária ao usuário
• Razão - A razão ou o contexto por que essa necessidade existe
• Critérios de aceitação - Essa é a estrutura para testes de aceitação do usuário e, durante a Demonstração da Sprint, como o Dono do produto poderá decidir se uma história de usuário é Aceita ou não.

Requisitos funcionais ou do sistema

Esta parece ser a peça que falta no seu quebra-cabeça. Dirigido a partir dos requisitos no nível do usuário, um requisito funcional define os atores e as propriedades de um sistema, bem como os comportamentos e funções de um sistema. Isso também pode ser feito em um formato de história e incluído no seu backlog. Esses itens devem ser independentes e podem ser implementados independentemente de qualquer requisito de usuário.

• Ator - Um sistema ou componente de algum tipo.
• Necessidade - uma necessidade, propriedade ou declaração de comportamento de um sistema que deveria existir.
• Razão - Um contexto por que isso é necessário no sistema
• Critérios de aceitação - Cenários, comportamentos, funções e fluxos necessários para comunicar como os testes de sistema e integração devem ser executados. Quando esses tipos de testes são aprovados para o requisito, sabemos que esse requisito funcional foi concluído. Eles podem existir na documentação externa de suas histórias de usuário, mas devem ser concluídos antes da atribuição dessas histórias em um sprint.

Os requisitos funcionais definem sua solução, que soa como o que você está descrevendo como a lacuna em seu processo.

Tipos de requisitos notáveis ​​que precisam ser mencionados, mas são irrelevantes para sua pergunta: Requisitos não funcionais, Requisitos técnicos, etc ...

Uma História do Usuário é um tipo específico de artefato com o objetivo de descrever a interface que o usuário espera do sistema e é por isso que os detalhes de baixo nível simplesmente não pertencem a ele. Se você colocá-los lá, está mudando a intenção do artefato e ele não se encaixa mais na definição de um EUA.

Use outras formas de especificação para capturar requisitos de nível inferior e decisões de design. Exatamente o que esses outros formulários devem ser é algo que precisa ser resolvido em sua organização e customizado para seu ambiente específico.

Sua pergunta parece muito semelhante a algo como

Eu tenho esse CarFactory e preciso que ele também faça bicicletas, mas nosso "Guru" da OOD diz que não tenho permissão para fazer isso. O que é isso BS!?!

Respeite a separação de preocupações e a coesão de seus artefatos, tanto em seu código quanto em seus processos.

Eu acho que o objetivo dessa abordagem não é restringir as histórias de usuários, mas evitar requisitos ruins.

Na minha experiência, os usuários geralmente são incapazes de escrever requisitos. Os desenvolvedores geralmente são incapazes de escrever requisitos. Caramba, vamos admitir: os requisitos são difíceis de escrever!

Eu acho que seria válido para um usuário escrever algo no idioma dos requisitos como parte de uma história de uso. No entanto, fazer isso não deve torná-lo automaticamente um requisito. Ter duas histórias de uso conflitantes é uma questão menor; ter dois requisitos conflitantes é uma questão importante de quebra de contrato. Não faz sentido promover um ao outro antes da hora.

Eu acho que o ponto de vista draconiano vem do reconhecimento da natureza humana. Se as pessoas começarem a pensar nas histórias de usuários como um local para colocar requisitos, elas começarão a fazê-lo. A vantagem real de usar histórias sobre outros meios de reunir requisitos, como informações, é que elas estão escritas nas formulações e notações naturais do usuário. Isso torna mais provável que os desenvolvedores pensem da perspectiva do cliente. Em um mundo perfeito, a linguagem dos requisitos frios também poderia ser usada. Na realidade, essas palavras tendem a fazer com que os desenvolvedores se atinjam aos requisitos fáceis de entender e perdem as palavras e nuances sutis que o desenvolvimento ágil deseja descobrir usando histórias de uso.

Tome suas próprias decisões

A resposta para 'Então, como os desenvolvedores podem realmente desenvolver uma história se não houver requisitos mais baixos?' é muito simples - os requisitos detalhados ortogonais às necessidades do usuário final (por exemplo, restrições de banco de dados, validação de campos etc.) não são realmente importantes para o usuário. Se as necessidades do usuário puderem ser atendidas por validação de campos muito diferentes, estruturas de banco de dados muito diferentes ou talvez até mesmo nenhum banco de dados tradicional, seria contraproducente fazer com que os usuários criassem essas informações com uma implementação específica em mente, o que pode ser muito diferente de como o sistema é implementado no final.

Como desenvolvedores profissionais, tome decisões profissionais da melhor maneira possível sobre os detalhes da implementação. Um usuário que deseja uma mesa pode dizer ao carpinteiro que tipo de madeira gostaria, mas é esperado que o carpinteiro decida a espessura das pernas da mesa para lidar com cargas razoáveis. Se você não possui algumas informações para tomar uma decisão significativa, isso precisa ser discutido com o usuário, mas cerca de 90% do conteúdo de um documento de requisitos detalhado, na verdade, não precisa de nenhuma informação, além do senso comum e das boas práticas do setor. .

Todos esses detalhes não são arbitrários - há más e melhores escolhas, e eles devem ser documentados, pois afetam outras partes da implementação, mas no final ainda são detalhes de implementação que podem e devem ser decididos pela equipe de implementação de acordo com às necessidades e práticas recomendadas do usuário.

Uma analogia padrão do carro - se um cliente quiser que o carro seja pintado de vermelho, um esclarecimento apropriado para a história do usuário seria perguntar qual tom de vermelho seria melhor, mas não a composição química da tinta; no entanto, seria de esperar que eles não optassem por pintar o carro com aquarelas que seriam lavadas na chuva, já que é uma prática recomendada não fazê-lo.

TL; DR

As histórias de usuário são para documentar qual valor deve ser adicionado ao produto e por quê. Os detalhes da implementação (por exemplo, como o valor deve ser adicionado, testado, medido ou validado) são limitados pela história, mas não estão contidos nela. Eles são deliberadamente deixados como artefatos separados para manter a flexibilidade e a agilidade dentro da estrutura.

As especificações e os detalhes da implementação costumam ser capturados em outros artefatos, como ATDD (Desenvolvimento Orientado a Testes de Aceitação), Desenvolvimento Orientado a Testes (TDD) e scripts e cenários de Desenvolvimento Orientado a Comportamentos (BDD). Esses artefatos específicos não são obrigatórios pela estrutura do Scrum, mas certamente fornecerão um bom ponto de partida se você ainda não tiver outros controles de processo eficazes em vigor.

Histórias de usuários não são especificações

O pôster original (OP) fez a seguinte pergunta :

[Um] cliente deseja um processamento diferente para diferentes cartões de crédito, existem requisitos rígidos que devem ser implementados e conhecidos para que casos de teste possam ser escritos ... ONDE DEVO COLOCAR SE NÃO ESTAR NA HISTÓRIA?

Uma história de usuário é um recurso que agrega valor , fornece algum contexto para orientar conversas sobre implementação e um ponto de vista vinculado a um consumidor de valor que se beneficiará do valor entregue pelo recurso.

O ponto principal de uma história de usuário é que os detalhes da implementação não são prescritivos. A equipe é livre para implementar o recurso de qualquer maneira que entregue o valor identificado ao consumidor de valor dentro do contexto apropriado.

Um Exemplo Trabalhado

Um exemplo de história do usuário

Isso é mais fácil de explicar se você começar com um conjunto menos ambíguo de histórias de usuários. Como o OP não forneceu uma história de usuário acionável que segue o mnemônico do INVEST , inventarei uma por uma questão de exemplo. Considere a seguinte história:

Como usuário que prefere pagar com cartão Discover,
eu gostaria da opção de fazer minhas compras com o cartão Discover,
para que eu não me limite ao Visa, Mastercard ou American Express.

Isso fornece um recurso concreto, fornece algum contexto que pode orientar as decisões de implementação que a equipe deve tomar e identifica o consumidor de valor como um cliente proprietário do cartão Discover. Esse não é um conjunto de especificações, mas é o que você precisa para ter as conversas certas com o cliente e com a equipe sobre a melhor forma de implementar a história durante uma iteração de desenvolvimento.

Análise e Implementação

A implementação real é com a equipe. A equipe precisará fazer algumas análises para determinar:

• A maneira mais fácil de implementar um novo recurso.
• Qual das várias opções de implementação será mais fácil de suportar no futuro, sem acumular dívida técnica.
• Como aplicar os princípios de aberto e fechado e do YAGNI para garantir que seu novo recurso seja robusto sem ser excessivamente projetado.

Um dos princípios centrais do Agile Manifesto é a colaboração do cliente. Espera -se que uma equipe multifuncional e auto-organizada seja capaz de colaborar com o cliente para elaborar os detalhes da implementação dentro das diretrizes fornecidas pela história do usuário.

Se suas histórias de usuário não foram bem escritas, ou se a equipe não possui as habilidades ou a maturidade do processo para fazer a análise suficiente necessária para sua estrutura ágil, isso obviamente será muito mais difícil do que precisa. Livros inteiros foram escritos sobre o assunto de como criar boas histórias de usuários no nível adequado de granularidade; infelizmente não existe uma bala de prata, mas é uma habilidade aprendível para equipes ágeis.

Design orientado a teste e orientado a comportamento

A melhor maneira de garantir que a análise seja sólida e que a implementação seja sã e suportável é através do uso de práticas de TDD e BDD. Por exemplo, dada a história acima, a equipe deve capturar a implementação planejada por meio de artefatos como:

• Recursos de pepino com cenários testáveis.

  Isso é mais útil para impulsionar o desenvolvimento de testes de aceitação e para documentar as expectativas do usuário em relação ao comportamento do aplicativo. Por exemplo, a história do usuário deve ter um ou mais recursos relacionados ao Pepino que descrevem como o usuário pode fazer check-out com um cartão Discover e como esse processo se parece com o usuário.

• Testes RSpec que validam o comportamento (não os detalhes da implementação interna) dos novos recursos de código.

  Isso é mais útil para documentar e validar o comportamento pretendido do recurso no aplicativo. Por exemplo, a história do usuário orientará a criação de testes de unidade e integração que garantem que o uso de um cartão Discover invoque qualquer comportamento específico do cartão que o aplicativo exija para autorizar uma venda pelo gateway de pagamento.

As ferramentas específicas não importam. Se você não gosta do Cucumber ou do RSpec, use as ferramentas ou metodologias que funcionam melhor para sua equipe. No entanto, o ponto é que os detalhes da implementação são baseados na história do usuário , mas não são prescritos por ela . Em vez disso, a implementação (ou especificações, se você preferir) são detalhes a serem trabalhados durante o desenvolvimento do recurso de forma colaborativa.

Muitas boas respostas aqui. Espero poder acrescentar algum valor com outro ...

Eu acho que um desligamento que sua equipe pode estar migrando de uma metodologia não-ágil.

Isso geralmente é uma metodologia em cascata e, na prática, geralmente envolve tentar documentar todos os requisitos técnicos antes que uma linha de código seja escrita.

Mas isso nem sempre funciona. Muitas vezes não funciona. O motivo? Porque os requisitos raramente se alinham com a realidade. As coisas mudam. Daí a mudança para o Agile.

Com o Agile, a história do usuário é tudo de que o usuário se importa. Eles querem obter o ponto A do ponto B. Como chegar lá em termos de implementação, está em suas mãos. Se você está esperando alguém lhe dizer os requisitos técnicos, isso não é realmente ágil. Se você possui dúvidas, pergunte. Se você precisar de documentação, documento, mas não deseja que o cliente tome todas essas decisões por você. Eles podem ter opiniões, mas em um ambiente ágil, essas opiniões devem ser discutidas (como sugere o seu guru) em uma conversa.

Pode parecer que isso é um fardo para sua equipe, mas considere um luxo. Sua equipe agora tem muito a dizer na solução - o que não era necessariamente o caso no modelo em cascata.