Integração de regras de negócios às histórias de usuários

Question

Tenho um conjunto de histórias de usuários e tenho um conjunto de regras de negócios (principalmente leis que vinculam meus requisitos para ser compatível). No SDLC ágil, não tenho certeza de onde essas "regras" estão anexadas às minhas histórias de usuário.

Por exemplo, uma história do usuário como:

Como médico, quero adicionar informações do paciente para criar um novo arquivo de paciente.

E uma regra como:

As seguintes informações devem ser inseridas no registro de cada paciente: (a) paciente: (i) nome e nome dado; (ii) endereço; (iii) data de nascimento; e (iv) sexo;

Esses dois se reúnem claramente, mas como posso vinculá -los? Como definições de aceitação de teste na minha história de usuário? Outra história do usuário?

Answer 1

Existem algumas maneiras diferentes de que eu vi isso tratado:

1. Um artefato é criado para manter a regra de negócios e é armazenado em algum repositório central de todas as regras, para que isso seja conhecido em toda a equipe de desenvolvimento e um armazém de conhecimento seja mantido. Isso pode ficar feio, pois pode haver centenas de regras dentro de apenas alguns anos de construção de um aplicativo.

2. As regras podem ser colocadas em cartões separados na história do usuário. Assim, embora a história do usuário seja que uma linha, pode haver 6-8 cartões que compõem todas as tarefas para que essa história seja concluída. Por exemplo, deve haver um novo formulário de paciente criado, validação no formulário, etc. Portanto, não é difícil ver isso surgir na linha em um cartão como uma maneira de rastrear o requisito dessa maneira. Este é o mais natural para minha mente, embora não seja onde a lista específica será 100% escrita, pois o cartão pode ser "garantir que alguns campos no formulário sejam obrigatórios".

3. Não há um link explícito, mas a regra é algo para o controle de qualidade ou um BA notar para o usuário verificar se o formulário aplica essa regra. Isso é semelhante a um, mas a questão é qual é a responsabilidade do desenvolvedor nisso. Nesse caso, é algo para o controle de qualidade rastrear, em vez de desenvolvedores, possivelmente.

A história do usuário tem como objetivo iniciar uma discussão, não ser uma lista abrangente dos requisitos. A regra é algo que deve surgir quando o desenvolvedor discute com o usuário o que é necessário para criar um novo arquivo de paciente em minha mente.

---

Gosto da idéia de me apegar a cartas por alguns sprints depois que a história foi feita, mas vejo o ponto de que os cartões serão destruídos. Ao mesmo tempo, deve haver código em algum lugar que implemente as regras em sua área adequada. Para usar o exemplo que você postou, pode ser que, em alguns lugares, a lista de campos necessários seja notada, pois existe a camada da interface do usuário que precisa mostrar os campos e provavelmente uma mensagem de erro, mas também deve haver alguma camada lógica de negócios que tem essa lógica para ver que alguns campos foram concluídos especificamente antes de tentar criar um novo arquivo de paciente. O sistema que está sendo construído também abrigará as regras de uma forma ou de outra também.

Answer 2

Como critérios de aceitação. Afinal, essas são regras que podem ser executadas como testes. Definitivamente não são novas histórias, isso seria errado, pois não há objetivo de entrega.