Por Rodrigo Farqui Lopes

Ao desenvolver um projeto, ou um produto para um cliente, você se preocupa em criar uma boa história de usuário? Segundo Ken Schwaber, idealizador do movimento de desenvolvimento ágil de software e co-criador do Scrum, se fossemos comparar uma produção de carros com uma de software, a cada 3 carros construídos, um seria entregue ao cliente sem motor, outro quebraria nos primeiros quilômetros e apenas um seria entregue sem defeito.

Mas por que muitos projetos falham ou não atendem a expectativa real do usuário? Um dos principais motivos é porque não dão a devida importância a entender e detalhar a necessidade do usuário, que é representada através de uma história de usuário bem escrita.

Mesmo que o Scrum ou outro framework ágil não defina um padrão para escrita de história de usuário, existem técnicas e dicas para se escrever uma boa história de usuário, e entender e esclarecer o que o usuário deseja realizar na aplicação ou sistema que está sendo desenvolvido. E neste artigo, exploraremos algumas dicas que como Scrum Master tento repassar para meu time e aplicar no dia a dia dos projetos que trabalho.

#01 Representar valor de negócio

Nos projetos tradicionais (cascata), é comum ter etapas e fases pré-estabelecidas, deixando a validação com usuário somente no final. Muitas vezes está prática é desfavorável, porque demora-se para que o cliente comece a utilizar o que solicitou.

Já os projetos ágeis trazem uma abordagem diferente. Ao invés de pensar no projeto, pensa-se em produto, utilizando o conceito de MVP (mínimo valor do produto). Desta forma, a história de usuário deve ser escrita pensando em pequenas entregas que representem valor de negócio ao consumidor final.

Fonte: What is Minimum Viable Product? (http://bit.ly/2MBmcRj)
Fonte: What is Minimum Viable Product? (http://bit.ly/2MBmcRj)

#02 INVEST

Mas de nada adianta pensar em valor de negócio para o usuário, se a necessidade dele for representada de forma complexa, abrangente e difícil de mensurar. Por isso, uma boa história de usuário deve seguir alguns critérios e uma dica para não esquecer nenhum é utilizando o método INVEST – um acrônimo para Independente, Negociável, Valiosa, Estimável, Small, Testável.

  • Independente: Toda história de usuário deve ser independente de outras histórias;
  • Negociável: Lembre-se toda história de usuário é apenas um desejo do usuário, logo, pode considerar ela sendo apenas um ponto de partida. Portanto, deve ser totalmente negociável;
  • Valiosa: Deve representar valor de negócio, sempre. Sem valor de negócio não faz sentindo existir, é simples assim;
  • Estimável: O time deve ser capaz de estimá-la;
  • Small: Deve ser pequena e assim reduzindo as incertezas e dificuldades de estimativas;
  • Testável: Todas histórias de usuário devem ser testáveis, ou seja, deve ser possível validar se atingem os critérios de aceitação.

#03 Defina o ator da história – utilize persona

Como a história de usuário representa a necessidade do mesmo, uma dica para escrever uma boa história é estabelecer três parâmetros:

  1. Ator: é o proprietário da história, quem irá utilizar a funcionalidade ou requisito. Uma imagem mental desse ator ajuda a representar um grupo distinto de usuários do produto. A criação de uma persona ajuda a estabelecer essa imagem mental;
  2. Ação: é o que o ator quer fazer dentro do sistema ou produto, esperando que o objetivo seja alcançado;
  3. Objetivo: é o que o ator esperar que aconteça, após a ação ser executada. Pode ser vista também como uma justificativa.

Exemplo: “Como um VENDEDOR preciso CONSULTAR os meus clientes pelo CNPJ, PARA conseguir negociar com eles estando bem informado.”

Amanda - Persona da Transformação digital
Amanda – Persona da Transformação digital

#04 Elimine ambiguidades

É muito importante tomar cuidado com ambiguidades ao escrever histórias de usuário. Por isso, evite usar palavras que tenham duplo sentido ou expressões que possam representar mais de uma possibilidade. Troque palavras como QUERO, POSSO, ACHO, por DEVO ou PRECISO.

Exemplo: COMO um usuário não administrativo DEVO modificar meus próprios horários, mas não os horários de outros usuários PARA QUE não seja necessário abrir um chamado sempre que minhas atividades mudarem.

SENDO um vendedor EU PRECISO consultar os meus clientes pelo CNPJ PARA conseguir negociar com ele estando melhor informado.

#05 Valide a História

Falamos que a história deve utilizar o critério INVEST. A melhor forma de validar o critério T (testável) é criando-se cenários de uso.

Exemplo: SENDO um vendedor EU PRECISO consultar os meus clientes pelo CNPJ PARA conseguir negociar com ele estando bem informado. Cenário de uso para essa história.

Cenário 1: CNPJ Inválido

DADO QUE o vendedor consulta o cliente E insere um CNPJ inválido
QUANDO apertar no botão “Consultar”
OU clicar fora do campo de CNPJ
ENTÃO uma mensagem informando “CNPJ Inválido, por favor coloque um CNPJ válido” deve ser exibida

Cenário 2: CNPJ Válido

DADO QUE o vendedor consulta o cliente
E insere um CNPJ válido
QUANDO apertar no botão “Consultar”
OU clicar fora do campo de CNPJ
ENTÃO será exibido uma tabela com uma única linha, contendo a Razão social, CNPJ e Status do cliente
E um botão chamado “Visualizar dados do cliente” será exibido junto a linha retornada

#06 Comece por épicos e termine com pequenas histórias

O ágil prega o conceito de pequenas entregas e constantes interações, de forma que o usuário veja mais cedo o valor do produto. Baseando-se nesse critério, as histórias não devem ser complexas e nem listar todos os casos possíveis. Uma boa saída é quebrar a funcionalidade a ser implementada em várias histórias.

Exemplo ruim (toda funcionalidade em uma história):

Bom exemplo (quebrando a funcionalidade em várias histórias):

  1. Usuário deleta email;
  2. Usuário recebe mensagem com confirmação que o e-mail foi deletado;
  3. Usuário vê contador de emails na lixeira aumentar;
  4. Usuário vê contador de emails na caixa de entrada diminuir;
  5. Usuário vê os e-mails deletados quando clica na lixeira;
  6. O sistema apaga automaticamente os emails que foram deletados há 30 dias.

Exemplo ruim:
História: “Como usuário eu DEVO conseguir fazer login no sistema perfeitamente”
Cenário: Usuário acessa o site quando o login e senha estão corretos
Dado que eu sou um usuário com login e senha corretos
E eu clico em “Entrar”
Então eu devo acessar o meu perfil

Bom exemplo:

  • Histórias individuais para cada cenário;
  • Usuário acessa o site com login e senha corretos;
  • Usuário vê mensagem de erro quando tenta acessar com login incorreto;
  • Usuário vê mensagem de erro quando ele não confirmou sua conta;
  • Usuário vê mensagem de erro quando conta não existe.
  • Usuário vê mensagem de erro quando conta não existe.

#07 Complemente a história

Nos métodos ágeis, uma das principais ferramentas de auxílio ao levantamento de requisitos é a utilização de protótipos e narrativas visuais que ajudam a visualizar o projeto.

1- Storyboards: são narrativas sequenciais e visuais que podem ser feitas com imagens em que uma pessoa simula as situações de uso.

2- Esboços: São feitos com diagramas e desenhos combinados, como histórias em quadrinhos, diagramas com setas e processos, somados a esboços de usuários. Facilitam a ambientação das situações e a interação do usuário com o site/mídia digital.

3- Simulação de uso em protótipos: A partir das personas e de um protótipo, simula-se várias situações de uso e registra-se os resultados em modelos semelhantes aos usados em testes de usabilidade.

Conclusão

Apesar de não existir uma fórmula pronta que garanta o sucesso das necessidades do usuário, as técnicas, dicas e práticas deste artigo auxiliam para que possamos escrever histórias de usuários cada vez melhores, pensando-se sempre na sua grande importância que é representar e evitar que um projeto falhe ou que não atenda às expectativas do usuário final.

Você se preocupa em criar uma boa história de usuário? Se a resposta foi não, você deveria considerar isto o quanto antes!

Rodrigo Farqui Lopes é scrum master com experiência e vivência no ágil desde 2008, onde nos últimos anos direcionou sua carreira para disseminar o ágil nas empresas e apoiar times e clientes em seus projetos.

Quer acelerar a transformação digital da sua empresa?_

Nós te ajudamos a prever tendências e alcançar objetivos futuros.

Telefone +55 (11) 3504-1100 Email contato@programmers.com.br                    Entre em contato