8

Eu tenho várias histórias de usuários em que o mesmo recurso precisa ser compartilhado por várias funções. Comecei a escrever essas histórias assim:

Como Função-A ou Função-B
Ao executar o Action-X, o
Event-Y deve ocorrer.

Essa é a maneira correta de representar esse conceito nas histórias de usuários ou devo dividi-lo em uma história para cada função?

agile

— Sean Hunter
fonte

14

Break It Up

um papel por história; forçando você a considerar cada papel isoladamente, você pode encontrar diferenças aparecendo naturalmente

[um exemplo pode ajudar; pode haver alguma confusão de papéis ocorrendo nos papéis A e B compartilham muitas das mesmas histórias; as chances são de que existe um papel C que 'possui' as histórias comuns]

— Steven A. Lowe
fonte

Obrigado pela resposta. Isso torna as coisas um pouco mais claras. E se o recurso for algo como um relatório. O relatório teria a mesma funcionalidade para a Função A e a Função B, mas a Função A e a Função B ainda precisariam ter permissões diferentes no sistema.

— Sean Hunter

2

O @Sean reexamina suas definições de função. Se as permissões diferentes no sistema para as funções A e B não afetarem o relatório, elas serão irrelevantes e parece provável que A e B não sejam as funções corretas para a matéria do relatório. Por exemplo, o arquiteto de funções e o gerente de funções têm acesso ao Relatório 401K. Não faria mais sentido definir "Participante 401K" como uma função mais apropriada para este relatório?

— Steven A. Lowe

Sim, faz sentido que eu chegue de onde você está vindo agora. Obrigado pelo bom conselho: D.

— Sean Hunter

10

Eu concordo com @Steven. Você deve contar a história ou introduzir generalização nas funções. Isso significa que você terá uma generalização de A e B, que será usada sempre que a história for a mesma para A e B. (É como herança de papéis / atores em que a generalização é a mãe de A e B).

— Ladislav Mrnka
fonte

1

Se você concorda com Steven, por que simplesmente não o votou em vez de adicionar outra resposta idêntica?

— pdr

2

@pdr: Não acho que a segunda parte da minha resposta seja "idêntica" e votei na resposta de Steven. Não há regra de que você não possa estender respostas postadas por outras pessoas. Cabe à comunidade julgar isso e votar com antecedência as respostas de que gosta. Como você pode ver, Steven recebeu mais votos positivos, o que é justo, então não vejo nenhum problema com a minha resposta.

— Ladislav Mrnka

1

@pdr Eu concordo com a adição de Ladislav e também votei na resposta dele. Quanto mais informações boas, melhor!

— Steven A. Lowe

Entendo que a criação de generalização de usuários suportaria uma verificação formal de integridade de suas histórias, mas acho que é uma má idéia escrever histórias como essa. O motivo é que ele está em conflito direto com a primeira regra do manifesto ágil: "Indivíduos e interações sobre processos e ferramentas".

— Max Hohenegger

1

Você precisa identificar e abstrair funções

O exemplo que você forneceu ...

As a Role-A or a Role-B 
When I perform Action-X 
Event-Y should occure.

não é escalável porque há um número exponencial de combinações que o programa pode executar.

Para extrair papéis individuais, você precisa imaginar as etapas de uma perspectiva em primeira mão, ignorando o estado global.

Eu sugiro que você dê uma olhada em ' Como tomar uma xícara de café '. Ele demonstra como uma API REST para uma cafeteria pode ser modelada usando diagramas de estado.

O ponto é que você não poderá desenhar uma imagem precisa de como o sistema interage globalmente até que você possa vê-lo funcionando em nível local.

— Evan Plaice
fonte

Qual é a melhor prática para histórias de usuários contendo duas funções

Break It Up