User Story My History

Sabermos as reais necessidades dos usuários e como eles se relacionam com o negócio faz toda a diferença para o “Como” iremos entregar o software para o cliente.

Independente da forma que formas realizar o entendimento, qualquer coisa nos gera dúvidas, até a forma na qual fazemos a tradução do termo Story pode gerar polêmica e/ou dúvidas. O correto é: Histórias ou Estórias?

Vamos ao conceito de cada uma destas palavras:

• História: Ciência que estuda o passado da humanidade e o seu processo de evolução, tendo como referência um lugar, uma época, um povo ou um indivíduo específico. Baseado em documentos ou testemunhos.
• Estória: Baseada em elementos fictícios, onde nem sempre é uma ação de fatos reais.

Eu, na verdade não me importo sobre qual termo utilizar, mas tenho uma preferência pela utilização de “Histórias de Usuários”, explicarei o motivo.

Um escritor, famoso professor de escrita criativa, Robert McKee, tem uma definição excelente sobre histórias, onde diz:

“Histórias são a conversão criativa da própria vida numa poderosa, mais clara e significante experiência. Elas são a moeda de troca do contato humano.”

Estudando um pouco sobre storytelling, em um livro – O Guia Completo de Storytelling de Fernando Palacios e Martha Terenzzo, obtive o entendimento que:

“São as VERDADES HUMANAS em histórias que GERAM de fato a EMPATIA.”

A partir disto é que venho traçando os meus objetivos e minhas indicações sobre como pensar as Histórias de Usuários e qual o valor devemos dar a elas.

A História de Usuário define como os usuários irão interagir e se envolver com o requisito solicitado. Detalharemos assim todas as suas necessidades, tendo os insumos suficientes para o time trabalhar, pois através dela definimos o que será construído e testado.

Para o formato de escrita podem haver variações e diferentes padrões. Passarei em exemplos os que vejo mais valor agregado e que podem nos levar a outros benefícios (principalmente se levarmos para BDD – Desenvolvimento dirigido a comportamento).

Um dos modelos mais utilizado é:

Como <tipo de usuário>, desejo <algum objetivo> para que <alguma razão>.

Em cada uma das histórias registramos o que se espera contemplar na sua implementação para que o usuário aceite a funcionalidade, estes são os Critérios de Aceitação.

Os critérios de aceitação em si, podem ser considerados testes de alto nível, quando estiverem satisfeitos a história estará finalizada. Além disso, podemos transformá-los em testes unitários e funcionais.

Exemplos de critérios:

• Senha não pode conter sequencia crescente com mais de 3 números.
• Senha deve conter uma letra maiúscula.

A utilização de Técnicas de Especificação por Exemplos é muito comum e utilizada para escrita dos critérios de aceitação, então é normal identificarmos algumas coisas com tabelas de decisão, como na imagem a seguir.

Uma outra boa prática é manter uma escrita em linguagem natural, com Gherkin, utilizada para a técnica de BDD, conseguimos ter uma linguagem onde todos os envolvidos no processo conseguem ler, entender e agir sobre elas, desde o próprio usuário que pode escrever a sua necessidade e até utilizar essa escrita como regra na automação de um teste funcional sendo estes os cenários a serem executados.

Vamos criar agora um exemplo mais completo de escrita de uma User Story.

Funcionalidade: Adicionar produtos ao carrinho de compras

Como cliente do e-commerce da loja visitada
Desejo adicionar produtos ao carrinho de compras
Para que eu possa compra-los

Critérios de Aceitação
Exibir opção de seleção de garantia estendida para produtos das categorias eletrônicos.

Cenário: Adicionar ao carrinho um produto com garantia estendida selecionada
Dado que estou na página do produto
Quando optar por comprar com garantia estendida
Então devo ter o produto inserido no carrinho com a garantia estendida adicionada
E sem exibição de mensagem sobre garantia estendida.

Cenário: Adicionar ao carrinho um produto sem garantia estendida
Dado que estou na página do produto
Quando optar por comprar sem selecionar garantia estendida
Então devo visualizar uma mensagem perguntando se desejo escolher alguma garantia estendida

Cenário: Adicionar ao carrinho um produto com garantia estendida adicionada
Dado que estou na página de opções da garantia estendida
Quando optar por adicionar uma das opções de garantia estendida
Então devo ter o produto inserido no carrinho com a garantia estendida adicionada

O importante aqui é atendermos um dos valores da agilidade, que visa a geração de documentação que agregue valor e não geração de documentação abrangente que ninguém lê.

O exemplo acima conseguimos ter o entendimento de negócio, ter insumo para desenvolvimento e ser a entrada dos cenários de testes e da automação de testes.

Caso queiram contribuir com este exemplo, adicionem através de comentários as suas dicas, sugestões e até mesmo dúvidas. Vamos juntos elaborar um belo exemplo de User Story.