Histórias de Usuário

De acordo com Leffingwell (2021) “Uma história é uma descrição de uma pequena funcionalidade que o cliente pretende ver desenvolvida no sistema”, ou seja, “É uma breve declaração de intenções que descreve algo que o sistema precisa fazer para o usuário”.

Ron Jeffries, um dos criadores do XP, descreveu o que se tornou a forma mais usual de pensar em histórias de usuários, a partir da seguinte estrutura: Cartão, Conversa, e Confirmação.

Cartão

Representa 2-3 frases usadas para descrever a intenção da história, e serve como um símbolo que memoriza (registra) o resume de uma a intenção, a qual ainda não foi detalhada.

Os cartões usam a seguinte padrão: "Eu, como [persona], [quero] (atividade a ser realizada) [para] (valor de negócio).", como mencionado por REHKUPF (2021). Onde:

• Persona: registra quem está realizando a ação ou, talvez, aquele que está recebendo o valor da atividade. Pode até ser um outro sistema, se é isso que está iniciando a atividade.
• Atividade: registra a ação que será executada pelo sistema.
• Valore de Negócio: registra o valor de negócio (objetivo) a ser gerado pela gerado com a execução da história.

Conversação

Representa (registra) uma conversa entre a equipe, cliente, proprietário do produto (product owner), e de outras partes interessadas, a qual é necessária para determinar o comportamento mais detalhado e necessário para implementar a história. Em outras palavras, o cartão também representa uma “conversa de promessa" sobre a intenção a ser construída.

As conversas devem ser realizadas desde o início do projeto para que a equipe seja envolvida.

Caso sejam necessários mais detalhes sobre a história, isso pode ser fornecida na forma de um anexo (mockup, planilha, algoritmo, ou qualquer outro). Detalhes adicionais da história devem ser coletados ao longo do tempo (just-in-time) por meio de discussões e colaboração com a equipe e outras partes interessadas antes e durante o desenvolvimento.

Critérios de Aceitação (Confirmação)

Registra o teste de aceitação, que é com o cliente ou proprietário do produto (product owner) irá confirmar se a história foi implementada satisfatoriamente. Em outras palavras, a confirmação representa as condições de satisfação que devem ser utilizadas para determinar se a história cumpre ou não, a intenção, bem como os requisitos mais detalhados.

Exemplo

Cartão

• “Como administrador eu quero cadastrar um jogo para que os apostadores possam fazer seus palpites de resultado"

Conversação

• O administrador pode cadastrar o jogo quando quiser? E se ele cadastrar muito em cima?
• Ah, eu acho que ele tem que cadastrar com no mínimo 48h de antecedência
• Ok, entendi. Concordo.

Confirmação

• Um administrador não poderá cadastrar um jogo com menos de 48h de antecedência.
• O jogo deve pertencer ao campeonato corrente.
• Um administrador não poderá cadastrar dois jogos envolvendo os mesmos times no mesmo horário.

Por que Histórias de Usuário?

1. Tiram o foco da escrita e vão para a fala;
2. São facilmente entendidas por desenvolvedores e clientes;
3. Apoiam e incentivam o desenvolvimento iterativo;
4. São do tamanho certo para o planejamento;
5. Apoiam a elaboração participativa;
6. Enfatizam os objetivos do usuário, não os atributos do sistema;
7. Pode ser entendida e priorizada pelo cliente;
8. São basicamente, pequenos pedaços de funcionalidades.

Como escrever boas Histórias de Usuário?

Siga o acrônomo INVEST, sugerido por Bill Waker (2003), o qual propõe seis atributos para uma boa história de usuário, sendo:

• Independet (Indenpendente): As histórias são mais fáceis de trabalhar se forem independentes. Ou seja, elas não devem ser sobrepor em conceito. Neste sentido, seria bom que os desenvolvedores pudessem programá-las e implementá-las em qualquer ordem.
• Negotiable (Negociável): Uma boa história é negociável. Não é um contrato explícito para recursos; em vez disso, os detalhes serão co-criados pelo cliente e pelo programador durante o desenvolvimento. Uma boa história captura a essência, não os detalhes. Com o tempo, o cartão pode adquirir notas, ideias de teste e assim por diante.
• Valuable (Valor de Negócio): Uma história precisa ser valiosa para o cliente. Os desenvolvedores podem ter preocupações (legítimas), mas estas são formuladas de forma que o cliente as considere importantes.
• Estimatable (Estimável): Uma boa história deve ser estimada. Não é preciso uma estimativa exata, mas apenas o suficiente para ajudar o cliente a classificar e programar a implementação da história. Ser estimável é em parte uma função de ser negociado, pois é difícil estimar uma história que se pode entender.
• Small (Pequena): Boas histórias tendem a ser pequenas. As histórias geralmente representam, no máximo, algumas semanas de trabalho por pessoa. (Algumas equipes os restringem a algumas pessoas-dias de trabalho). Acima desse tamanho, pode ser muito difícil saber o que está no escopo da história.
• Testable (Testável): Uma boa história pode ser testada. Escrever um cartão de história carrega uma promessa implícita: “Eu entendo o que quero bem o suficiente para poder escrever um teste para isso”. Várias equipes relatam que, ao exigir testes do cliente antes de implementar uma história, a equipe é mais produtiva. “Testabilidade” sempre foi uma característica de bons requisitos; Na verdade, escrever os testes com antecedência ajuda a saber se essa meta foi alcançada.

Referências Bibliográficas

- COHN, Mike. User Stories Applied. Addison-Wesley, 2004.

- LEFFINGWELL, D. Scaled Agile Framework, http://www.scaledagileframework.com/

- WAKE, B. INVEST in Good Stories, and SMART Tasks, Posted on August 17, 2003. https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/.