Como definir regras comerciais complexas usando Histórias de Usuário?

Uma definição rápida e suja da história do usuário :

"As a <role>, I want <goal/desire> so that <benefit>"

Nesta definição comumente aceita, há pouco espaço para definir regras de negócios, restrições ou entrada do usuário.

Exemplo trivial apenas para ilustrar:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Neste exemplo bobo, onde se definiria os campos necessários ao registrar um livro? Deve ser escrito em qualquer lugar? Ou as regras comerciais necessárias devem ser passadas como propaganda boca a boca pelo Dono do Produto?

Os campos fazem parte da conversa que deve ser realizada. Eles podem ser escritos se isso for útil, mas se for um julgamento. Manter a documentação atualizada pode ser um desafio, enquanto o software em funcionamento pode ser visto como documentação até certo ponto.

História do usuário - Uma promessa de ter uma conversa seria uma entrada de blog sobre isso.

Seu exemplo trivial tem alguns pontos que eu não sei o quão bem você notaria isso. O que significa "registrar novos livros?" O que é "Encontrar a disponibilidade deles on-line?" É aí que a conversa começa e, depois que a história é concluída, pode haver novas histórias, pois talvez esses registros precisem ser mantidos em arquivo ou relatórios sejam gerados periodicamente.

As respostas anteriores fornecem pontos válidos, especialmente a respeito de uma história de usuário ser um lembrete para ter uma conversa . Outras coisas a considerar:

1. Se a história é muito complexa, provavelmente é uma epopéia . Você pode dividir épicos em histórias menores agora ou depois que elas forem priorizadas no backlog do produto

2. Os detalhes que implicam casos de teste são separados da própria história. [ Mike Cohn ]

   Você pode adicionar no verso do cartão de história, fazer pequenas anotações se elas forem realmente importantes ou colocá-las no documento de testes de aceitação .

Como orientação para avaliar se suas histórias de usuário são boas, você pode seguir a sugestão de Bill Wake :

• I ndependent (de outras histórias)
• N egotiable
• V aluable (para o utilizador ou cliente)
• E stimable (para uma boa aproximação)
• S shopping (o suficiente para ser estimado)
• T estable

Você pode ler o Capítulo 2 "Escrevendo histórias" do livro User Stories Applied, de Mike Cohn.

Normalmente, em uma história de usuário abrangente e abrangente, com muitas facetas, tento obter o exemplo mais geral da história e, em seguida, para obter detalhes específicos, crio histórias de usuário filho que herdam dela. Muitas ferramentas de gerenciamento de projetos Agile, como o RallyDev, permitem que você faça isso facilmente e acho que faz sentido.

O registro de novos livros é amplo, portanto, talvez haja outras 10 histórias de usuários filhos sobre como <role>gostaria que os livros fossem registrados.

Detalhes extremos dessas coisas ou detalhes extremos bizarros que eu costumo definir em uma ou mais tarefas nessa história de usuário. As tarefas ajudam a definir o trabalho de desenvolvimento e design que deve ser feito (em geral) para atender à história do usuário (por exemplo, escreva o validador para garantir que a entrada no campo de descrição tenha menos de 50 caracteres ...) EDIT: Eu só queria adicionar provavelmente é melhor manter detalhes extremos fora das histórias do usuário, porque provavelmente não é algo com o qual o usuário realmente se importe. Os usuários querem explicar o software em termos gerais e dependem dos desenvolvedores de software para descobrir e ocultar os detalhes deles.

É assim que abordo o problema, mas tenho certeza de que há várias maneiras diferentes.

A resposta é simples: incorpore as regras de negócios aos critérios de aceitação.

Exemplo trivial apenas para ilustrar:

Como bibliotecária, quero registrar novos livros, para que os alunos possam encontrar sua disponibilidade on-line

Ficarei satisfeito quando: * Posso registrar os seguintes campos: - ISDN - Autor - Dewey Decimal blá blá * Posso ver a confirmação de que o livro foi registrado pelo sistema * Posso ver o livro no sistema

Como definir regras comerciais complexas usando Histórias de Usuário?

Não é para isso que servem as histórias de usuários. Eles não são requisitos de software que capturam todos os detalhes ou regras de negócios necessários para escrever a implementação. Eles são apenas uma descrição do que o aplicativo deve fazer da perspectiva do usuário.

Lembre-se do que é importante: criar o software adequado. Você usa o que for necessário para fazer isso e as histórias de usuário são apenas para garantir que reuniu os recursos necessários que o aplicativo deve ter, para que você possa falar sobre eles, priorizá-los, estimar etc. A parte que falta do usuário clássico A história (como ... eu quero ... assim) é sobre a comunicação entre os envolvidos na construção do software.

Ter os detalhes como critérios de aceitação, sub-histórias, tarefas técnicas anexadas à história do usuário, em um documento de especificação ou qualquer outra coisa, vai além do que a história do usuário ajuda. O usuário stoy é apenas o "assunto" da conversa ao decidir como construir o software.

No exemplo dado, há muitos detalhes sobre o registro de livros sobre os quais os desenvolvedores migram pouco, como Dewey ou outros sistemas de classificação, ISBNs, números de aquisição, cópias / títulos / autores duplicados, outras edições e assim por diante. Para um novo sistema, esses detalhes devem ser fornecidos pelo cliente (e um bibliotecário, de todas as pessoas, certamente se preocupará com eles).

Para citar Steve O'Connell, "é aterrorizante contemplar quanta política de negócios é criada por desenvolvedores que careciam dos detalhes necessários nas especificações, apenas inventando por si mesmos".