Como escrever melhores histórias de utilizador com Gherkins (modelo incluído)

As histórias de utilizador são uma técnica Agile para definir a funcionalidade e os requisitos do produto. Concentram-se em contar uma história sobre uma ação que o utilizador irá realizar e quais são as expectativas quando for bem sucedido. O conceito de histórias de utilizadores é muito utilizado, mas contar boas histórias pode ser bastante difícil.

No entanto, as histórias de utilizadores têm sido um pouco criticadas nos últimos anos, uma vez que são ligeiramente simplificadas e carecem de empatia para com o utilizador.

Boas notícias – há uma forma melhor! Chamam-se pepinos, mas ao contrário dos pickles, não estão aqui para azedar a sua vida. (A não ser que se goste de pickles, suponho!) 🥒

TL;DR

Se estiver com um pouco de pressa, aqui está o TL;DR (embora eu o encoraje a continuar a ler para aceder aos modelos!)

• As histórias de utilizadores centram-se no utilizador e não no produto.
• Delineie as suas personas para acrescentar contexto.
• Adicione empatia às suas histórias para compreender acções e motivações.
• Pepinos: uma forma melhor de escrever histórias.
• Utilize os pepinos para se concentrar nos resultados e não apenas nos produtos.

O que são histórias de utilizadores?

As histórias de utilizadores são descrições curtas e simples de uma solução que a sua equipa concebeu, contadas a partir da perspetiva da pessoa que está a realizar a interação. Fazem parte de uma epopeia maior que descreve o problema real a resolver e a razão pela qual o está a resolver.

A palavra-chave aqui é utilizador, o que significa que uma história de utilizador coloca o foco no utilizador e não no produto.

Uma história de utilizador centra-se normalmente em três áreas:

• Como um(quem)
• Quero(o quê)
• Para que(porquê)

Tudo isto é normalmente seguido de critérios de aceitação, que definem como saber se a interação foi bem sucedida.

Quem: Utilizar personas para delinear histórias de utilizadores

Se ainda não definiu ou compreendeu os seus utilizadores, então não deveria estar a escrever histórias de utilizadores. Comece por fazer algumas descobertas, trace um percurso do cliente e crie personas de utilizador relevantes que o ajudarão a definir melhor estas histórias.

Uma persona pode ajudá-lo a compreender e a contextualizar o “quem” da história do utilizador – por outras palavras, quem está a conduzir esta interação.

Isto é importante, uma vez que terá inevitavelmente diferentes segmentos de clientes, funções e permissões envolvidas, pelo que é importante definir essas interacções para responder a esses diferentes tipos de utilizadores.

O quê: Interacções de histórias de utilizadores

O “o quê” de uma história de utilizador centra-se na própria interação. O mais difícil aqui é garantir que o seu “o quê” se concentra no que o utilizador tem de fazer, em vez do que o utilizador quer fazer, e é aqui que o modelo de história típico se desmorona um pouco.

Para acrescentar um pouco de empatia à própria história, é importante realçar como o utilizador se poderá sentir ao interagir com uma determinada ação.

Por exemplo, ninguém quer introduzir uma palavra-passe complicada com uma letra maiúscula, caracteres especiais e um comprimento mínimo – mas sabe que deve fazê-lo. Neste caso, é algo que o utilizador é obrigado a fazer.

Porquê: A razão para a ação da história do utilizador

A terceira parte do modelo de história do utilizador é o “porquê” – ou seja, porque é que o utilizador quer (ou é obrigado a) realizar uma determinada ação.

Voltando ao nosso exemplo anterior de introdução de palavras-passe:

Como administrador, sou obrigado a criar uma palavra-passe complicada, para que a minha conta esteja segura.

Compreendemos agora o quem, o quê e o porquê da história – mas há aqui um problema. Isto continua a carecer de empatia e de contexto porque, sejamos honestos, ninguém quer que as palavras-passe complicadas sejam um requisito, mas todos queremos contas seguras.

Ao testar isto, a equipa de garantia de qualidade limita-se a verificar se a palavra-passe é segura e não se o processo é frustrante para o utilizador.

Introduzir o modelo de história de utilizador Gherkin

Os Gherkins são uma forma de acrescentar às histórias de utilizador e de apresentar um cenário completo que ajudará os programadores e os testadores a compreenderem o resultado e o produto de uma determinada interação com o utilizador.

1. Scenario – o comportamento que vai descrever
2. Given – o estado inicial do cenário
3. When – uma ação específica que o utilizador realiza
4. Then – um resultado testável, geralmente causado pela ação em When
5. And – esta operação continua qualquer uma das outras três operações, se necessário

Tomando o cenário da palavra-passe descrito anteriormente:

1. Ao definir uma palavra-passe (Scenario),
2. Given que eu sou um administrador de conta,
3. WhenIntroduzo uma palavra-passe no campo da palavra-passe,
4. ThenDeveria ser avisado dos requisitos da palavra-passe,
5. And Deveria poder fazer correcções de imediato,
6. Then que posso criar uma conta segura.

Agora, temos uma visão completa de quem está a realizar a ação específica e quais são os requisitos para os critérios de aceitação, e a equipa sabe quais são as potenciais frustrações, para que possa garantir que o processo flui mais facilmente.

Geralmente, o gestor de produto ou o proprietário do produto é responsável por escrever as histórias Gherkin, criando assim uma melhor comunicação entre o resto da equipa e assegurando que todos se concentram nos resultados e não apenas nos outputs.

Quais são as suas formas preferidas de delinear histórias? Depois diz-me! ✌️