Scrum - histórias de usuários
Como você entendeu, as Estórias de Usuário são comumente usadas para descrever os recursos do produto e farão parte dos Artefatos Scrum - Product Backlog e Sprint Backlog.
Histórias de usuários
No desenvolvimento de software, os recursos do produto desempenham um papel crucial. São os recursos que o usuário mais gosta de usar no produto final. Eles são conhecidos como Requisitos na terminologia geral. O sucesso do projeto de desenvolvimento de software reside na compreensão dos requisitos do usuário de forma precisa e adequada e, em seguida, implementá-los no produto final. Portanto, os requisitos ou recursos do produto precisam ser totalmente conhecidos pela equipe do projeto de desenvolvimento.
Em 1999, Kent Beck criou o termo User Stories para os recursos do produto. Ele descreveu que uma história de usuário é narrada da perspectiva do usuário em relação ao que ele deseja ter, em vez do que o sistema pode fazer por ele. Assim, a visão mudou completamente de produto para usuário e as Estórias de Usuário se tornaram o padrão de fato para Requisitos em todas as estruturas Agile.
Em projetos Scrum, o Product Backlog é uma lista de histórias de usuários. Essas Estórias de Usuário são priorizadas e levadas para o Backlog da Sprint na Reunião de Planejamento da Sprint.
A estimativa também é baseada em histórias de usuários e o tamanho do produto é estimado em pontos de histórias de usuários.
A estrutura da história do usuário
A estrutura da história do usuário é a seguinte -
Como um <tipo de usuário> ,
Eu quero <para realizar alguma tarefa> ,
Para que <eu possa atingir algum objetivo / benefício / valor> .
Vejamos como uma história de usuário é estruturada para o cenário de um cliente bancário retirando dinheiro de um caixa eletrônico.
História do usuário: Retirada de dinheiro do cliente
Como um Customer,
eu quero withdraw cash from an ATM,
De modo a I don't have to wait in line at the Bank
Critérios de aceitação de história de usuário
Cada história de usuário também tem um critério de aceitação definido, de modo que a correção da implementação da história de usuário é confirmada passando no teste de aceitação que se baseia no critério de aceitação.
A seguir estão os exemplos de critérios de aceitação para o exemplo de Retirada de Dinheiro do Cliente de História de Usuário.
Acceptance Criterion 1:
Given que a conta tem crédito
- E o cartão é válido
- E o distribuidor contém dinheiro,
When o cliente pede o dinheiro
Then garantir que a conta seja debitada
- E garantir que o dinheiro seja distribuído
- E certifique-se de que o cartão seja devolvido.
Acceptance Criterion 2:
Given que a conta está a descoberto
- E o cartão é válido
When o cliente pede o dinheiro
Then certifique-se de que a mensagem de rejeição seja exibida
- E garantir que o dinheiro não seja distribuído
- E certifique-se de que o cartão seja devolvido.
Escrever histórias de usuários
O Product Owner é responsável pelo Product Backlog e, portanto, pelas User Stories. No entanto, isso não significa que apenas o product owner escreve as histórias de usuário. Qualquer pessoa na equipe Scrum pode escrever histórias de usuário e a atividade pode ser espalhada pelo projeto conforme os requisitos são refinados e novas funcionalidades são adicionadas.
Requisitos não funcionais em histórias de usuários
É possível incorporar os requisitos não funcionais também nas histórias de usuário. No exemplo de ATM fornecido, o ATM disponível para o usuário 24X7, 365 dias é um requisito não funcional, que pode ser descrito por um caso de uso.
Gerenciando histórias de usuários
As histórias do usuário são gerenciadas no Backlog do produto. As histórias de usuário são ordenadas de acordo com a prioridade. As histórias de usuário mais priorizadas são refinadas para um nível granular, enquanto as histórias de usuário de menor prioridade são mantidas em um nível de detalhe menor. Para cada sprint, as histórias de usuário mais priorizadas e, portanto, mais granuladas são incluídas no backlog do sprint. Se uma história de usuário tiver que ser adicionada ao backlog do produto, sua prioridade é primeiro determinada e colocada de acordo com seu lugar de acordo com a prioridade. As histórias de usuário podem ser priorizadas a qualquer momento. Também é possível remover qualquer uma das histórias de usuário, se necessário.
Benefícios com histórias de usuários
O principal benefício da história do usuário está na própria definição centrada no usuário. Isso ocorre porque, em última análise, é o usuário que usará o produto nos cenários de usuário relevantes. Ele conecta os usuários finais aos membros da equipe.
A sintaxe da própria história do usuário garante a captura da meta, benefício ou valor que o usuário deseja alcançar.
Uma vez que os critérios de aceitação fazem parte da própria história do usuário, será uma vantagem adicional para o Time Scrum.
É possível fazer alterações em uma história de usuário durante a execução do projeto. Se o escopo da história do usuário se tornar grande, ele precisará ser dividido em histórias de usuário menores. As condições no critério de aceitação também podem ser alteradas.
À medida que os incrementos do produto de trabalho são entregues aos usuários no final de cada sprint, a equipe scrum pode obter feedback dos usuários na reunião de revisão do sprint. Isso permite a incorporação de feedback no produto continuamente.
Conclusão
As Estórias de Usuário do Scrum aproximam os usuários da equipe Scrum e evita surpresas de última hora.