Todos desejam adentrar nesse universo ágil e começar a escrever User Story. O teórico é de simples entendimento, mas ao começar as primeiras linhas, muitos acabam tendo muitas dificuldades de conseguir criar as histórias de maneira simples e clara. Vamos ajudar!
Usando o conceito INVEST
O acrônimo INVEST ajuda a lembrar de um conjunto de critérios ou lista de verificação amplamente aceito para avaliar a qualidade de uma User Story. Se a história não atender a um desses critérios, a equipe poderá reformulá-la ou até mesmo reescrevê-la (o que geralmente se traduz em rasgar fisicamente o cartão de história antigo e escrever um novo).
Uma boa história de usuário deve ser:
- Independent (Independente): deve ser independente de uma maneira que permita ser liberada sem depender uma da outra.
- Negotiable (Negociável): capture apenas a essência da necessidade do usuário, deixando espaço para conversas. A história do usuário não deve ser escrita como contrato.
- Valuable (Valioso): entrega valor ao usuário final.
- Estimable (Estimável): as histórias do usuário precisam ser estimadas para que possam ser adequadamente priorizadas e ajustadas aos sprints.
- Small (Pequena): uma história de usuário é um pequeno pedaço de trabalho que permite sua conclusão em cerca de 3 a 4 dias.
- Testable (Testável): uma história de usuário deve ser confirmada através de critérios de aceitação pré-escritos.
Como começar a escrever?
Ao começar a escrever User Story, um modelo pode ajudar a garantir que você não comece inadvertidamente a escrever tarefas técnicas.
Modelo de Escrita
As User Stories capturam apenas os elementos essenciais de um requisito:
- Para quem é?
- O que ele espera do sistema?
- Por quê é importante?
Quem?
Define quem é o usuário que tem a necessidade. Pode ser representado por um tipo de usuário do produto, por uma persona ou até mesmo por um usuário específico.
“QUEM” ajuda a criar no leitor da User Story uma imagem mental desse usuário. User Stories que começam “Eu, enquanto um usuário…” ou “Eu, enquanto um cliente…”, portanto, não atingem esse objetivo e devem ser evitadas.
O que?
Define qual é a necessidade do usuário. Tradicionalmente, os requisitos do produto são representados apenas por essa parte.
Por quê?
Define qual o benefício do usuário ao ter a funcionalidade desenvolvida para atender a essa necessidade. Em outras palavras, qual o valor direto obtido pelo usuário.
As User Stories são escritas na linguagem cotidiana e descrevem um objetivo específico (o que) da perspectiva de um indivíduo (quem), juntamente com o motivo (por que) ele / ela deseja. No desenvolvimento de software, o objetivo geralmente é um novo recurso do produto, o indivíduo é algum tipo de usuário final e o motivo é o benefício que o usuário vê no recurso do produto de destino.
Exemplos
O ponto de vista do usuário é o de quem tem um problema (necessidade) ou uma solução? Um problema. Vejamos, a seguir, uma User Story:
“Eu, enquanto Comprador de Livros, quero buscar livros por nome para escolher o que vou comprar.”
Essa é a forma mais comum de se escreverem User Stories e é perfeitamente aceitável. No entanto, buscar livros por nome é um problema ou uma solução? É uma funcionalidade e, portanto, uma solução. Então essa User Story não está realmente expressa sob a perspectiva do usuário. Qual seria o problema do usuário então? Se a reescrevermos da seguinte forma:
“Eu, enquanto Comprador de Livros, quero encontrar um livro cujo nome sei para escolher comprá-lo.”
O problema do usuário nesse caso é encontrar um livro cujo nome conhece, e uma das possíveis soluções é buscar livros por nome. Outra seria mostrar simplesmente uma lista de todos os livros para que ele possa encontrar o que precisa. Não que uma lista seja melhor que uma busca, mas essa alternativa poderia, por exemplo, ser mais adequada para uma versão inicial do sistema devido a seu custo mais baixo.
Expressar a User Story a partir do problema e não de uma solução particular abre espaço para discussões sobre as possíveis soluções para o mesmo problema. Assim, pode fazer com que soluções mais adequadas sejam encontradas.
Detalhando as histórias com os 3Cs
Ron Jeffries, outro dos criadores do XP, descreveu o que se tornou a maneira favorita de pensar nas histórias de usuários. Uma User Story possui três componentes principais, cada um dos quais começa com a letra ‘C’: cartão, conversa e confirmação, para descrever os três elementos de uma história de usuário.
Cartão
O Cartão é a descrição da necessidade do usuário, ou seja, a própria User Story. Essa descrição é concisa, e assim suficiente para apenas identificar qual é e de que se trata essa necessidade. O nome “Cartão” é dado porque frequentemente as User Stories são escritas em cartões de índice ou fichas.
Conversa
São conversas sobre a User Story, por onde a solução de negócios e os detalhes dessa solução são discutidos, negociados, definidos e então documentados na forma de Critérios e Testes de Aceitação. Elas geram uma compreensão compartilhada sobre o que é necessário para que a funcionalidade gere valor de negócio e retorno ao investimento. As conversas são imprescindíveis para o trabalho do Time de Desenvolvimento, uma vez que o Cartão não possui detalhes que permitam que o item seja desenvolvido.
Em geral, participam dessas conversas o Product Owner, membros do Time de Desenvolvimento e outras pessoas de negócios envolvidas, caso haja, mas qualquer pessoa que possa contribuir com detalhes pode participar.
Tomemos como exemplo a User Story do exemplo anterior, “Um Viajante de Turismo quer mostrar sua viagem para seus amigos para lhes causar inveja”. O Time de Desenvolvimento e Product Owner, por meio de conversas, podem concluir que permitir o compartilhamento de fotos e vídeos na rede social do momento diretamente do aplicativo é a solução de negócios desejada, e a partir daí escrevem os Critérios de Aceitação, que serão transformados em Testes de Aceitação automatizados no decorrer do Sprint.
Confirmação
São critérios e testes deles derivados que documentam os detalhes da User Story, definindo seus limites. Ou seja, são regras que estabelecem como a funcionalidade deve se comportar uma vez implementada. Esses critérios são chamados de Critérios de Aceitação e os testes, de Testes de Aceitação.
Enquanto todas as User Stories devem satisfazer à mesma Definição de Pronto, cada User Story possui seu próprio conjunto de Critérios e Testes de Aceitação.
Critérios de Aceitação são expressos por enunciados pequenos e de fácil entendimento. São utilizados para determinar quando a funcionalidade produzida pelo Time de Desenvolvimento está completa e, assim, nada mais deve ser adicionado a ela.
Os Critérios de Aceitação ajudam o Product Owner a determinar para o Time de Desenvolvimento o que ele precisa para que essa funcionalidade propicie valor. A partir desses critérios, o Time de Desenvolvimento gera os Testes de Aceitação.
Os Critérios de Aceitação são negociados e definidos antes do desenvolvimento da funcionalidade, geralmente em sessões de Refinamento do Product Backlog.
Como refinar uma User Story?
As User Stories devem ser identificadas juntamente com as partes interessadas, de preferência por meio de uma reunião presencial. A User Story é um processo de descoberta de requisitos, em vez de um processo inicial de análise de requisitos.
Nas abordagens tradicionais de captura de requisitos, o analista de sistemas tenta entender as necessidades dos clientes e, em seguida, prepara uma especificação de requisitos para o sistema em detalhes. Não é assim que a abordagem da história do usuário funciona. Em vez de um processo de documentação, a identificação da história do usuário é mais como um processo de anotações. Listamos as principais etapas para identificar histórias de usuários da seguinte maneira:
- Através das discussões com os usuários, ouvimos e entendemos seus problemas e necessidades
- E então, anote suas necessidades como histórias de usuários ao mesmo tempo.
- Essas histórias de usuários se tornarão a fonte de requisitos.
- Os detalhes podem ser preenchidos posteriormente na hora certa, fornecendo à equipe referências de requisitos “suficientes” durante todo o processo de desenvolvimento do projeto.
Fonte:
- Knowledge 21: “Como é a User Story?”
