Estória de usuário. Você saberia contar?

Levantar requisitos seguindo um modelo tradicional é uma tarefa muito difícil. Normalmente, resulta em equívocos, esforços desnecessários, complexidade e burocracia. Um problema evidente que podemos encontrar é o fato do cliente dificilmente conseguir explanar todas as suas necessidades no início, acarretando naturalmente uma incerteza sobre a direção do projeto. Outra questão é o fato do cliente ver uma versão funcional do software apenas ao final do projeto, sendo assim, qualquer erro no levantamento dos requisitos ocasionará em um desastre e certamente levará o projeto a ruínas. A verdade é que requisitos mudam, a percepção do cliente sobre o que esta sendo construído se modifica e você precisa estar preparado para absorver e se direcionar. A boa notícia é que existe uma forma mais eficiente para especificar requisitos, eu e todos os membros do mundo ágil a chamamos de estória de usuário ou user story se preferir. Criar estórias de usuário é uma prática oriunda dos métodos ágeis, logicamente, não existe apenas essa forma para se levantar requisitos de forma ágil, porém, sem dúvida é uma das mais simples e eficientes.

Mas, o que é uma estória de usuário?

Uma estória de usuário pode ser caracterizada como uma curta e simples descrição da necessidade do cliente, não será uma surpresa encontrá-las em metodologias ágeis como SCRUM e XP. Ela normalmente é contada a partir da perspectiva de quem precisa da nova necessidade, sendo geralmente um usuário, cliente do sistema ou representante de negócios do cliente. Uma estória de usuário deve explicar bem para quem, o que e por que está sendo criada. Isso é importante, principalmente, para desenvolvedores que poderão construir softwares com menor dificuldade e maior qualidade, entendendo os objetivos e necessidades do cliente de forma mais rápida. É normal escrever uma estória de usuário em post-it’s, fichas ou notas. Elas podem ser coladas em paredes ou mesas para facilitar o planejamento e discussão. Aliás, as discussões são mais importantes do que qualquer texto que estará escrito.

O conceito INVEST

Para evitar que uma estória de usuário seja feita de maneira despretensiosa foi criado o acrônimo INVEST. Lembre-se dele e muito provavelmente suas estórias de usuário terão uma boa qualidade. Vamos desmembrar cada sigla:

I – Independent (independente)

Uma boa estória de usuário não deve depender de outra, ela deve andar com as próprias pernas. Estórias de usuário dependentes são difíceis de estimar e priorizar, além disso remover uma estória de usuário dependente acarreta diversos problemas em outras. Procure não encadear uma estória, se por acaso ela for muito grande e não for possível escrevê-la de forma independente, sugiro que crie um épico (já te explico essa palavra) e as divida em estórias menores.

N – Negotiable (negociável)

Uma estória de usuário não é “apenas” um texto detalhando as característica que o Product Owner espera ou um pedaço de funcionalidade que será implementado. Veja uma estória de usuário como um ponto de partida para uma conversa ou uma abertura para que a equipe sugira soluções. Negocie, as coisas mudam e aqui não seria diferente, se for necessário a reescreva ou a descarte, mude sua prioridade ou altere sua ordem de execução.

V – Valuable (de grande valor)

Não podemos apenas criar estórias de usuário divertidas, que façam o desenvolvedor se motivar para codificar, é preciso trazer valor junto com o divertimento. Se você não descrever o valor que o cliente terá com essa estória de usuário, ela não servirá para nada.

E – Estimable (estimável)

“Não consigo estimar o tempo necessário para desenvolver essa estória de usuário.” Essa estória de usuário não entra no sprint backlog, simples! Se não há informação suficiente ou definição para permitir que a equipe faça uma estimativa sobre a estória de usuário, ela não pode ser iniciada.

S – Small (pequena)

Uma estória de usuário não pode demorar mais do que uma sprint para ser concluída. Qualquer estória de usuário maior do que isso será difícil de se planejar ou se estimar com segurança. Se ela for muito grande crie um épico e dividida em estórias de usuário menores, não há nenhum problema em começar o seu sprint backlog com um épico.

T – Testable (testável)

Se você não pode testar uma estória de usuário, você não pode saber se ela funcionará bem ou não. Então? Teste, se a estória de usuário em questão não puder ser testada por falta de informação, não a coloque em seu backlog.

Use temas e épicos quando necessário

Se você seguir o conceito INVEST para criar suas estórias de usuário, muito provavelmente, terá estórias de qualidade. Em algumas situações verá a necessidade de separá-las em temas ou épicos. Não que você vá realmente ter essa necessidade, não estou pondo isso como requisito, porém, as vezes será necessário. Deixa eu te explicar melhor:

Temas

Um tema é um grupo de estórias de usuário que compartilham atributos em comum. Muitas vezes, várias estórias de usuário terão objetivos similares ou estarão relacionadas de uma maneira óbvia. Todas elas direcionadas juntas a um único caminho, no entanto, elas não precisam encapsular um fluxo de trabalho específico ou ser entregues necessariamente juntas. Vale ressaltar também que um tema pode conter vários épicos ou várias estórias de usuário.

Épicos

Épico é uma grande estória de usuário que não pode ser concluída em uma única sprint, se assemelhando a um tema por ser construída com múltiplas estórias. Apesar das estórias que compõem um épico serem concluídas de forma independente, o seu valor para o negócio não será entregue até que todo o épico esteja completo. Isso significa que não faz sentido entregar um épico sem que todas as estórias atreladas a ele estejam completas.

Criando estórias de usuário

Como já te falei uma estória de usuário deve explicar bem para quem (quem receberá essa funcionalidade), o que (descrição da funcionalidade em si) e por que (o motivo da funcionalidade) está sendo criada. Essas informações são fundamentais para qualquer estória de usuário e precisam constar na sua especificação de requisitos. Existem vários formatos que você pode seguir para escrever suas estórias de usuário, eu particularmente utilizo um bem genérico que supre todas as minhas necessidades e segue as informações fundamentais que citei. Deixa eu te apresentar esse modelo:

COMO/SENDO <QUEM>, EU QUERO/GOSTARIA/DEVO/POSSO <O QUE>, PARA QUE/DE/PARA <PORQUE/RESULTADO>.

Com essas informações ficará mais fácil para o desenvolvedor elaborar uma funcionalidade que expresse realmente a necessidade do cliente. Vejamos alguns exemplos utilizando esse formato:

Exemplo 1 – Consultar cliente pelo CNPJ

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

Exemplo 2 – Alterar os próprios horários

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.

Exemplo 3 – Épico – Relatório de chamados

COMO usuário POSSO visualizar o relatório de solicitação DE chamados no painel (épico)

Perceba que essa estória ficou muito grande para ser concluída em apenas uma sprint, além de não estar totalmente explicita. Neste caso, vamos transformá-la em um épico e criar algumas dezenas (até mesmo centenas) de estórias de usuário para o mesmo, incluindo essas duas abaixo:

COMO administrador do sistema POSSO visualizar o relatório de solicitação de todos os usuários PARA obter um melhor feedback sobre o seu andamento e solução.

SENDO um usuário comum do sistema POSSO visualizar o relatório de solicitação de chamados abertos apenas por mim PARA obter um melhor feedback sobre o seu andamento e solução.

Descrevendo comportamentos com BDD

O BDD (Behavior Driven Development) indica o comportamento que determinada funcionalidade deve possuir, sendo ela um aperfeiçoamento das práticas TDD e ATDD. Com BDD podemos testar a funcionalidade de nossas estórias de usuário, criando cenários de uso para validá-las. Dessa forma, nossas estórias de usuário ficam mais descritivas, possuindo cenários que indicam o seu funcionamento esperado. As palavras chave dado que, quando e então nos apoiam na criação de cenários para descrever o seu comportamento. Vejamos um exemplo utilizando uma estória de usuário já exemplificada:

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

Exemplo de cenários para a estória acima

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

Perceba que usamos o DADO QUE para indicar o cenário atual, o QUANDO para indicar a ação do usuário e o ENTÃO para indicar o comportamento esperado. Também utilizamos o E e o OU para refinar ainda mais os nossos cenários de teste. BDD merece bem mais que alguns parágrafos de explicação, por isso em breve escreverei mais sobre o mesmo. Com prática você irá ganhar velocidade e contar estórias de usuário com facilidade e excelência. Lembre-se ninguém nasce sabendo, então, pratique e siga as boas práticas que te expliquei aqui. Um grande abraço e até a próxima!

Gostou? Então deixe seu comentário e compartilhe com seus amigos.