Pelo que tenho visto, uma user story geralmente é uma descrição resumida da jornada do usuário para realizar alguma ação no sistema. Ocorre que essa ação, aparentemente simples, pode esconder certa complexidade. Imaginando uma história que envolve tributação/impostos que ao ser descrita omite todas as regras envolvidas num determinado processamento. O time precisa de um especialista, um contador para esclarecer alguns pontos durante a Sprint, para além do P.O. Onde devem ser mantidas todas as informações coletadas e que descrevem de forma detalhada as regras de tributação e impostos necessárias para desenvolver a user story?
4
respostas
respostas
Onde manter as regras do negócio que não estão na história do usuário?
A user story é somente um resumo, pra organizar de forma simples e visual. Não significa que não terá documentação. Esta especificação vai ser uma uma tarefa dentro da história, vai ser o meio de como concluir a história.
Raphael, nas empresas que trabalhei que praticavam o agile, nós armazenávamos esse tipo de informação dentro de uma Wiki, onde será essa Wiki seu time deve entrar num consenso. Já vi dentro do GitHub, já vi em Sharepoint, é um local de fácil acesso e qualquer um pode ver a hora que quiser. Espero ter ajudado.
Jáderson e Janaina, muito obrigado pelas respostas. Considerando que a especificação é uma tarefa dentro da user story, vejo que teremos um mini processo cascata dentro da sprint em que o time (pelo menos os desenvolvedores) teria que aguardar a conclusão dessa tarefa de especificação para iniciar a codificação. Nesse cenário, como orquestrar dentro de uma sprint tarefas que tem dependência entre si? Como dividir as tarefas de forma a não termos desperdício de recurso/ociosidade na equipe?
Quando nos deparamos com uma user story com uma complexidade visivelmente maior, como o cenário colocado, vale aquela ideia de "quebrar" a user story em mais de uma. Em nosso time, quando nos deparamos com este cenário, criamos uma tarefa de análise em uma Sprint, que fará o levantamento das informações relevantes, regras de negócio, etc, para inclusive nos dar subsídios para realizarmos as estimativas da implementação. Em outra Sprint, partimos para o desenvolvimento, neste momento munidos dos detalhes relevantes que precisam ser atendidos.