Histórias de Usuário (User Stories)

Cada item do Product Backlog de um produto de software, precisa ser detalhado de alguma forma, para que o time de desenvolvimento possa construir um software.

No modelo tradicional, é muito comum a utilização de documento de levantamento de requisitos, especificações técnicas, especificações funcionais, diagramas dos diversos tipos (caso de uso, atividades, sequência entre outros).

No Scrum, não é diferente, você poderá utilizar qualquer uma das técnicas acima e outras várias para detalhar as necessidades dos usuários e o que precisará ser desenvolvido.

Entre as mais comuns, estão os Casos de Uso, com seus diagramas e detalhamentos, descrições textuais simples (até mesmo o famoso papel de pão) e acredito que a mais difundida, as histórias de usuário.

Vamos falar hoje sobre as histórias de usuário.

As histórias de usuário é uma técnica para descrever requisitos ou funcionalidades do produto de maneira simples, objetiva, eficaz e eficiente. É uma descrição pequena e sucinta, de um requisito, desejo ou necessidade do usuário. Normalmente são utilizados pequenos cartões para criar uma história de usuário.

O modelo é bastante simples, contém um título, o ator (no caso o usuário ou uma pessoa que irá utilizar a funcionalidade), a ação e o objetivo. Veja o modelo abaixo:

Ator: o proprietário da história, no caso, quem irá utilizar ou está interessado na funcionalidade ou requisito.

Ação: é o que o ator quer fazer dentro do sistema, esperando que o objetivo seja alcançado

Objetivo: é o que o ator espera que aconteça, após a ação ser executada. Pode ser entendida também como uma justificativa.

Não entendeu? Então veja alguns exemplos:

Veja que nesta história, o ator “Vendedor”, gostaria de ter uma “Listagem de todos os produtos” cujo o objetivo e visualizar não só os produtos, mas também a quantidade em estoque e o preço destes produtos. Viu como é simples? Acredito que é bem mais fácil do usuário solicitar algo desta forma, do que utilizar o levantamento de requisitos com todos os detalhes.

Você pode perguntar, mas se for necessário detalhar mais, como por exemplo, quais filtros devem ser permitidos na consulta? É preciso consultar por código de barras? Precisa imprimir a lista ou só visível em tela?

Neste caso, você poderá criar novas histórias de usuário, a fim de detalhar. Por exemplo, poderia criar outras histórias como a abaixo, transformando cada história em um item do backlog do produto:

Além disso, uma história de usuário poderá ter mais alguns detalhes quanto às regras de negócio ou validações importantes que precisam ser feitas. Essas regras são chamadas de “testes de aceitação”.

Os testes de aceitação têm a finalidade de confirmar se a funcionalidade está de acordo com a especificação, é uma condição de teste que deve ser verdadeira após a história do usuário ser concluída.

Cada história, poderá ter seu conjunto de testes de aceitação e deverão ser validadas pelo time de desenvolvimento durante os testes.

Para ficar mais fácil, vamos continuar no exemplo da listagem de produtos.

Supomos que na listagem dos produtos, surjam duvidas como: pode listar produtos desativados? Podem ser listados produtos sem estoque? Pode ser listado produtos sem preço definido?

Nos testes de aceitação, que poderão ser descritos no verso do cartão da seguinte forma:

Veja que o desenvolvedor precisará filtrar os produtos desativados e depois, o testador terá que desativar um item e verificar se o mesmo aparece. Se não aparecer, está correto e o teste de aceitação está validado. O mesmo é válido para os outros dois itens. Por fim, o teste de aceitação serve para dar alguns detalhes que ficariam confusos se colocados nas ações ou no objetivo.

Para se fazer uma boa história de usuário, atentar-se aos critérios:

• Independente: a história precisa ser independente, ou seja, tem que ser compreendida sozinha e sem dependência de outra história (não quer dizer que possa ser implementada antes de outra, mas não pode depender de outra para ser compreendida).
• Negociável: a história precisa captar a essência e não detalhes. Com o tempo, essa história poderá ser detalhada, incluindo-se testes de aceitação, novas ideias, etc.
• Valiosa: a história do usuário precisa ter valor, se não tiver, não deve ser implementada.
• Estimável: uma boa história precisa ser estimável quanto a sua complexidade, em grau suficiente para auxiliar no planejamento. Se estiver difícil de estimar, essa história precisa ser quebrada em histórias menores.
• Tamanho apropriado: uma história de usuário deve ser implementada em no máximo uma sprint. Se isso não for possível, a história deve ser quebrada em histórias menores.
• Testável: uma história de usuário precisa ser clara o suficiente para que possa ser validado se o resultado obtido está de acordo com o que foi definido na história.

Espero ter ajudado você a compreender melhor como funciona as User Stories, mas se tiver alguma dúvida, deixe nos comentários ou entre em contato.

Até a próxima.