Como escrever User Stories

“Software funcional mais do que documentação extensa”, um dos pilares do manifesto ágil pode dar a entender que nesse contexto documentação não é importante. Mas o próprio manifesto explica que os valores da esquerda são mais importantes mas os da direita também tem valor, mas qual o valor ?

Sem documentação (qualquer que seja o formato) é possível sim produzir software, mas a formalização de regras de negócio é muito útil para deixar todos “na mesma página” e em alguns casos como em consultorias que vendem software é algo essencial devido a forma de contratação.
Utilizando documentação tradicional (leia se escopos, diagramas UML, contratos, entre outros) podemos notar uma frequente falta de atualização devido ao tamanho e complexidade dos artefatos. Grande parte desse material na maioria das vezes é inútil aos desenvolvedores.

Pensando nisso, os criadores do XP (Extreme Programming) desenvolveram uma forma simples e funcional de documentar requisitos de software em uma linguagem clara tanto para o usuário como para os desenvolvedores, as Histórias de usuário, segue um exemplo:

Funcionalidade: Cadastro de Clientes

Como um cliente do site
Quero me cadastrar
Para efetuar minhas compras

Critérios de aceitação:
* Os campos “nome completo”, “CPF”, “RG” e “E-mail” são obrigatórios.
* Ao preencher o CEP, os dados do endereço devem ser carregados automaticamente.

Vamos entender a estrutura:

<Funcionalidade>: O nome ou breve descrição do que deve ser implementado
<Como>: Quem irá utilizar a funcionalidade
<Quero>: Qual a necessidade a ser atendida
<Para>: Qual o objetivo ou resultado após a implementação

<Critérios de aceitação>: Como o nome diz, são critérios utilizados para validação, além informações adicionais da história que poluiriam a descrição se fossem incluídas no corpo principal.

Um recurso muito utilizado é a palavra “E” para compor informações em histórias onde se faz necessário, segue exemplo:

Como um cliente do site
Quero me cadastrar
E confirmar minha senha
Para efetuar minhas compras

Outro exemplo:

Como um cliente do site
Quero me cadastrar
Para efetuar minhas compras
E receber e-mails de promoções

Geralmente as Histórias de Usuário são escritas em um cartão pequeno com linhas onde na frente descrevemos a funcionalidade e atrás os critérios de aceitação. Isso ajuda a não criarmos histórias muito grandes, uma das características que veremos a seguir.

Como escrever boas histórias?

Um conceito bastante útil para escrever histórias de usuário é o INVEST. Trata-se de um acrônimo das características que uma história deve conter, guiando uma boa utilização. Segue um breve descritivo:

Independent (Independente)
Uma história não deve ser vinculada a outra sempre que possível. A independência facilita as estimativas, desenvolvimento, testes e até a movimentação entre iterações.

Negotiable (Negociável)
A maior vantagem de utilizar metodologias ágeis é rápida resposta a mudanças. As histórias de usuário também seguem este principio, devem ser alteradas e renegociadas sempre que necessário.

Valuable (Valorosa)
Toda funcionalidade escrita no formato de história deve ser importante para o usuário, a entrega deve trazer valor ao negócio.

Estimable (Estimável)
Toda história deve conter informações suficientes para que seja possível estimar qual o esforço para entrega. Se o time não consegue estimar, a história não esta pronta.

Small (Pequena)
Uma história deve ser pequena o suficiente para caber em uma sprint. Caso tenha mapeado histórias maiores, deve-se criar um Épico (tópico de histórias) e quebra-lo em histórias menores mas sempre respeitando as características aqui descritas.

Testable (Testável)
Toda história deve ser testável. Os critérios de aceitação são muito importantes para guiar os testes e garantir que o que foi desenvolvido atende as necessidades do negócio.

Conclusão:

A maior vantagem de utilizar User Stories é a objetividade. Facilmente os desenvolvedores podem desenvolver código orientado a uma User Story, as estimativas de esforço para desenvolver também podem ser direcionadas, utilizando os Story Points (tema para outro post).

Uma extensão das user stories é o BDD com seus cenários de testes que podem facilmente compor uma documentação ágil e funcional de software. Em breve trago uma nova postagem sobre documentação ágil detalhando melhor o uso do BDD e outras ferramentas.

Se você gostou desse texto, deixe 50 claps (palminhas), isso ajuda demais a DBSP a continuar criando conteúdos gratuítos.