INTRODUÇÃO
No desenvolvimento ágil, a estória de usuário é um substituto mais leve para o que tem sido nossos meios tradicionais de especificação de requisito de software - especificação de requisitos, especificação de casos de uso e assim por diante. De fato, a estória de usuário é o artefato mais importante no desenvolvimento ágil porque ele é a forma principal de exposição do valor que o usuário busca, e desenvolvimento ágil se trata de entrega rápida de valor.
A estória de usuário também serve como uma metáfora para nosso paradigma entrega incremental de valor, i.e.:
- Definir uma estória de usuário com valor agregado;
- implementá-la e testá-la em uma curta iteração;
- demonstrá-la e/ou entregá-la ao usuário;
- capturar o feedback;
- aprender e repetir!
VISÃO GERAL
Uma estória de usuário é uma breve afirmação de intenção que descreve algo que o sistema precisa fazer para o usuário.
Em XP (Extreme Programming), estórias de usuário são geralmente escritas pelo cliente, desta forma integrando o cliente diretamente ao processo de desenvolvimento. Em Scrum, o gestor do produto escreve as estórias de usuário, baseando-se nas necessidades dos clientes, da organização e sob feedback da equipe de desenvolvimento. Contudo, na vida prática, qualquer membro da equipe com suficiente conhecimento do domínio pode escrever estórias de usuário, mas é necessário que o gestor do produto as aceite e priorize para comporem o product backlog.
Estórias de usuário são uma ferramenta para definir um comportamento do sistema de uma forma que seja compreensível tanto para desenvolvedores quanto para usuários. Estórias de usuário focam o trabalho no valor definido pelo usuário ao invés da estrutura funcional, que é a forma de trabalho tradicional. Elas provem uma abordagem leve e efetiva de gerenciar requisitos para um sistema.
Uma estória de usuário captura uma pequena afirmação de função em um cartão indexado ou numa ferramenta online.
Exemplos:
Logar-me no meu web portal de monitoração de gasto de luz
Ver meu gasto diário de luz
Verificar minha conta de luz
Detalhes do comportamento do sistema não aparecem em uma afirmação breve e são deixadas para serem desenvolvidas posteriormente, através de conversações e critérios de aceite entre a equipe e o gestor do produto.
ESTÓRIAS DE USUÁRIO SERVEM DE PONTE DE COMUNICAÇÃO ENTRE O DESENVOLVEDOR E O CLIENTE
No desenvolvimento ágil, é função do desenvolvedor falar a linguagem do usuário, não o contrário. Comunicação efetiva é a chave e precisamos de uma linguagem comum. A estória de usuário provê uma linguagem comum para que seja construído um entendimento entre o usuário e a equipe técnica.
ESTÓRIAS DE USUÁRIO NÃO SÃO REQUISITOS
Enquanto estórias de usuário fazem a maior parte do trabalho que é feito pelas especificações de requisito de software, casos de uso e similares, elas diferem das últimas de várias maneiras.
- Elas não são especificações detalhadas de requisitos (algo como o sistema deve fazer) mas são, na verdade, expressões negociáveis de intenção (é necessário fazer algo desse tipo);
- Elas são curtas e fáceis de ler, compreensíveis a todos os interessados;
- Elas representam pequenos incrementos de valor à funcionalidade, que podem ser desenvolvidos em dias ou semanas
- Elas são relativamente simples de estimar, assim o esforço de desenvolvimento da funcionalidade pode ser rapidamente determinado;
- Elas não são agrupadas em grandes e incômodos documentos: são organizados em listas que podem ser facilmente organizadas e reorganizadas assim que novas informações são descobertas;
- Elas não são detalhadas nas etapas iniciais do projeto, mas são elaboradas no momento em que é necessário detalhá-las - desse modo livrando-se de especificações prematuras, atrasos no desenvolvimento, inventário de requisitos etc.
- Elas precisam de poucas ou nenhuma manutenção no decorrer das versões de software.
FORMATO DA ESTÓRIA DE USUÁRIO
CARTÃO, CONVERSAÇÃO E CONFIRMAÇÃO
Ron Jeffries, um dos criadores do XP, descreveu o que se tornou a maneira favorita de se pensar em estórias de usuário. Ele usou a aliteração Cartão, Conversação e Confirmação para descrever os três elementos de uma estória de usuário. Onde:
Cartão representa 2 a 3 sentenças usadas para descrever a intenção da estória. O cartão serve como um lembrete, que sumariza a intenção e representa o requisito mais detalhado, cujos detalhes ficam pendentes. Exemplo:
Como um usuário registrado, quero autenticar no sistema, para que eu possa acessar o conteúdo do assinante.
Conversação representa a discussão entre a equipe, o cliente e o gestor do produto, necessário para determinar com mais detalhe o comportamento necessário para implementar a intenção. Em outras palavras, o cartão também representa uma "promessa de conversação" sobre a intenção, isto é, o cartão indica que ainda são necessários detalhamentos. Exemplo:
Líder Técnico: A autenticação deve ser feita pelo endereço de e-mail cadastrado ou pelo nickname?
Gestor: a autenticação deve ser feita pelo e-mail. Um mesmo nickname pode ser repetido por outros usuários.
Confirmação representa o Teste de Aceite, que é como o cliente ou o gestor do produto irão confirmar que a estória está sendo implementada de acordo com suas expectativas. Em outras palavras, Confirmação representa as condições para aceite que serão aplicadas para determinar se uma estória atende tanto a intenção quanto os requisitos mais detalhados. Exemplo:
1. Sucesso - Usuário válido é direcionado para a página inicial
a. checkbox "Continuar conectado" marcado - armazenar cookie / autenticar automaticamente no próximo acesso.
b. checkbox "Continuar conectado" desmarcado - exigir autenticação no próximo acesso.
2. Falha - Apresentar mensagem:
a. "Formato inválido para e-mail";
b. "Usuário inválido, por favor tente novamente";
c. "Senha inválida, por favor tente novamente";
d. "Serviço indisponível, por favor tente novamente";
e. "Conta expirada, acesse a página de vendas para renovação".
VOZ DA ESTÓRIA DE USUÁRIO
Nos últimos anos, uma forma padronizada tem sido aplicada para as estórias de usuário. A forma é a seguinte:
Como [usuário/papel], quero [atividade], para que eu possa [valor].
onde:
- usuário/papel - representa quem está executando a ação ou a pessoa que está recebendo o valor proveniente da atividade. Pode ser até outro sistema, se é esse que está iniciando a atividade;
- atividade - representa a ação a ser executada pelo sistema;
- valor - representa o valor para o negócio.
Chamamos isto de padrão "voz do usuário" para essa expressão de estória de usuário e encontramos nela uma estrutura útil porque evidencia o problema ( entregue) e a solução ( que o usuário executa com o sistema). Também provê uma visão em primeira pessoa () para a equipe, o que a mantém focada no valor para o negócio e no solucionar problemas reais para pessoas reais.
Esse formato de estória de usuário aprimora bastante o entendimento porquê e o como que os desenvolvedores precisam para implementar um sistema que realmente atende as necessidades dos usuários.
Por exemplo, um usuário de um sistema de gerenciamento de gasto de luz pode querer:
Como Consumidor (papel), quero poder ver meu gasto diário de luz (atividade), para que eu possa começar a entender como diminuir meus gastos ao longo do tempo (valor que eu recebo).
Cada elemento provê um contexto importante e expansível. O papel permite a segmentação da funcionalidade do produto e tipicamente estendem outras necessidades e contextos para a atividade. A atividade tipicamente representa o "requisito" necessário para o papel. E o valor comunica por que a atividade é necessária, o que geralmente leva a equipe a encontrar possíveis atividades alternativas que poderia prover o mesmo valor com menos esforço.
DETALHES PARA ESTÓRIA DE USUÁRIO
Os detalhes para estórias de usuário são conduzidos principalmente através da conversação entre o gestor do produto e a equipe, mantendo a equipe envolvida desde o começo. Contudo, se mais detalhes são necessários para a estória, eles podem ser providos na forma de um anexo (planilha, algoritmos, documento etc), que é anexado à estória de usuário. Nesse caso, a estória de usuário serve como um "lembrete" que também carrega o comportamento mais específico para a equipe. O detalhe adicional da estória de usuário deveria ser coletada durante todo o tempo através de discussões e colaboração com a equipe e outros interessados antes e durante o desenvolvimento.
CRITÉRIO DE ACEITE PARA ESTÓRIAS DE USUÁRIO
Em acréscimo à afirmação da estória de usuário, notas adicionais, premissas e critérios de aceite podem ser mantidos na estória de usuário. Muitas discussões entre a equipe e os clientes sobre uma estória provavelmente acontecerão antes e durante o tempo em que a estória é codificada. Os fluxos alternativos na atividade, critérios de aceite e outros esclarecimentos deveriam ser capturados no decorrer com a estória. Muitos desses podem se tornar em casos de teste de aceitação ou outros casos de testes funcionais, para a estória.
Por exemplo,
Como Consumidor (papel), quero poder ver meu gasto diário de luz (atividade), para que eu possa começar a entender como diminuir meus gastos ao longo do tempo (valor que eu recebo).
Critérios de Aceite:
- Ler DecaWatts a cada 10 segundos e mostrar no portal em incrementos de 15 minutos e mostrar em um aparelho em casa após cada leitura;
- Ler KiloWatts cada vez que uma nova informação está disponível e mostrar no portal a cada hora e em casa após cada leitura;
- Não é necessário relatório semanal (outra estória)
- etc...
Critérios de aceite não são testes funcionais ou testes unitários, mas são as condições de satisfação sendo inseridas no sistema. Testes funcionais e unitários vão muito além de testar todos os fluxos funcionais, fluxos de exceção, condições limitadoras e funcionalidades associadas à estória.
