Neste tutorial, você aprenderá sobre uma parte importante da abordagem ágil para o desenvolvimento de software: histórias de usuários.

Vou te explicar o que são histórias de usuários, armadilhas comuns que eu vi na criação de histórias de usuários, e as estruturas que existem para validar se sua história de usuário é “boa”.

Aqui está o que vamos cobrir:

Os Princípios do Ágil

É provável que você já tenha ouvido falar do Desenvolvimento Ágil e das Histórias de Usuário. Mas se não ouviu, vamos ter uma breve aula de história:

As Histórias de Usuário fazem parte de um conceito maior chamado metodologias Ágeis.

As metodologias Ágeis existem desde 2001, quando 17 engenheiros de software bem respeitados se reuniram em uma estação de esqui em Utah e criaram o agora famoso Manifesto Ágil.

Se nomes como Robert Martin, Martin Fowler e Kent Beck não significam nada para você, depois de terminar este artigo, pesquise sobre eles. Eles têm um grande conhecimento e juntos deram ao mundo do software uma forma mais fluida de entregar projetos, chamada Ágil.

O que é Ágil?

Ágil é mais uma forma de pensar do que um método prescrito. Métodos prescritos existem, como Scrum e Kanban, mas Ágil é um conceito.

Ágil promove a colaboração, feedback rápido e a entrega frequente de valor ao usuário.

A forma de pensar Ágil incentiva a flexibilidade no planejamento de projetos, o que contrasta fortemente com seu concorrente na época, o planejamento de projetos em Cascata, que era muito rígido em relação ao que estava sendo entregue e quando.

As metodologias ágeis promovem fazer “apenas o suficiente” de pesquisa no início para dar início ao projeto, e então aprender, iterar e mudar o design e o entregável conforme necessário ao longo do projeto até que o código final seja entregue. Essa abordagem de “mudar e aprender à medida que avança” é chamada de “planejamento adaptativo”.

Ágil promove a entrega de algo de valor de forma rápida e frequente, geralmente na forma de entrega de código para produção ao final de cada “sprint” de duas semanas. Isso, novamente, é muito diferente do planejamento tradicional em cascata, que muitas vezes exigiria meses de desenvolvimento antes que qualquer mudança visível para o usuário pudesse ser entregue à produção.

Outra parte fundamental do Ágil é o foco que ele coloca na colaboração próxima e frequente entre as partes interessadas. Produto, QA, Engenharia e Vendas têm uma grande participação e feedback constante sobre o projeto ao longo do ciclo de vida do projeto.

Agora que você sabe um pouco mais sobre como o Ágil funciona, vamos mergulhar mais fundo em como validamos o valor para o usuário.

Apresentamos a História do Usuário.

O que é uma História do Usuário?

Uma história do usuário é uma maneira em inglês simples de conectar o engenheiro ao objetivo final do software.

Ela é projetada para que uma pessoa não técnica possa ler e entender o que está sendo entregue, e para que um engenheiro possa olhar para ela e ver o valor e como validar que você entregou esse valor.

Estrutura de uma História do Usuário

Como um [tipo de usuário], quando eu [realizo a ação], [resultado esperado]

No seu nível mais básico, é isso.

Você está enfatizando o usuário final e o “valor” que você irá entregar.

Vamos analisar as entradas:

  • Tipo de usuário: Não existe um “usuário” que sirva para todos. Você tem “usuários administradores”, você tem “usuários logados”, você tem “usuários com permissão X” ou “usuários no papel Y”. Isso é ser específico sobre quem está realizando a ação

  • Realizar ação: O que o usuário está fazendo? Clicando no botão “login”? Excluindo um registro? Enviando um formulário?

  • Resultado esperado: Depois que seu usuário realizar a ação, o que deveria acontecer? Se eles clicaram em “login” com o endereço de e-mail e senha corretos, para onde eles deveriam ser direcionados? Se eles clicaram em “login” com um endereço de e-mail e senha incorretos, o que deveria acontecer?

Exemplo de Histórias de Usuário:

Vamos olhar exemplos de histórias de usuários para uma página de login.

Não há nada melhor do que exemplos.

Vamos definir o cenário. Você tem uma página de login com uma caixa de texto para inserir um endereço de e-mail e uma caixa de texto para inserir uma senha. Você tem um botão de enviar. É isso.

Quais são as diferentes permutações que podem acontecer nesta página do ponto de vista do usuário?

Como um usuário logado, quando a página carrega, sou redirecionado para a página inicial do usuário logado.

Se eu já estiver logado, não quero ter que reentrar meus dados, apenas me redirecione para a página inicial do usuário logado.

Como um usuário não logado, quando insiro o endereço de e-mail correto, mas a senha incorreta e clico em Login, uma mensagem de erro aparece.

Sou um usuário que não está logado e inseri os dados incorretos. Eu não deveria estar logado.

Como um usuário não logado, quando insiro um endereço de e-mail e senha incorretos e clico em login, uma mensagem de erro aparece.

Novamente. Eu não sou um usuário logado. Eu inseri dados incorretos, não deveria estar logado.

Como um usuário não logado, quando insiro o endereço de e-mail e a senha corretos e clico em login, sou redirecionado para a página inicial do usuário logado.

Desta vez, eu não estou logado, insiro os dados corretos e clico em login. Estou logado no sistema.

Você pode ver como todos esses estão focados no usuário?

Você pode notar que alguns dos “comportamentos esperados” acima não estão totalmente definidos. Vamos abordar isso mais tarde nos critérios de aceitação.

Como fazer boas User Stories

Existe um bom modelo chamado modelo INVEST que mostra de forma simples como saber se suas user stories são boas.

Modelo INVEST:

  • Independente: Pode ser desenvolvido separadamente.

  • Negociável: Aberto a discussão e mudança.

  • Valuoso: Entrega valor ao usuário.

  • Estimável: Pode ser estimado para esforço.

  • Simples: Encaixa em um sprint.

  • Testável: Possui critérios de aceitação claros.

Vamos aplicar este modelo INVEST a um dos exemplos de user stories acima:

Como um usuário não logado, quando eu inserir o endereço de e-mail e senha corretos e clicar em login, serei redirecionado para a página inicial logada.

(Vou fazer algumas suposições aqui, pois este é um código teórico e projeto teórico)

Essa história é Independente? Eu diria que sim, sim. É uma pequena história que envolve apenas alguns componentes que provavelmente já existem. No entanto, se o banco de dados ainda não foi criado para o projeto, isso nos daria uma dependência. Isso não seria mais independente.

É Negociável? Bem, novamente, sim. Essa história poderia facilmente ser alterada para redirecionar para a página de perfil do usuário em vez de sua página inicial.

Essa história é definitivamente valiosa. Uma vez implementada, o usuário pode fazer login. Se a história fosse:

Como um usuário não logado, quando eu digito o endereço de e-mail e a senha corretos e clico em login, nada acontece

Isso não seria valioso. O usuário não obteria nada com isso.

A história é estimável? Novamente, temos que fazer algumas suposições nesse cenário inventado, mas eu certamente espero que isso possa ser facilmente estimado. É uma história concisa, envolvendo poucos componentes, em um domínio que todos estão familiarizados e com critérios de aceitação claros.

A história é certamente pequena. Há pouca ambiguidade sobre o que precisa ser feito, há apenas um caminho do usuário e resultados claros. Vamos dar uma olhada em uma história que seria grande demais:

Como um usuário não logado, a página de login deve funcionar como esperado.

Como discutido mais acima neste artigo, há muitas maneiras que a página de login pode e deve funcionar. “Deve funcionar como esperado” parece cobrir todas essas permutações. Isso seria grande demais para ser efetivamente dimensionado como uma história, e provavelmente grande demais para ser concluído em um único sprint.

A história é definitivamente Testável. Existem ações claras do usuário a serem tomadas que têm um resultado claro. Esta história de usuário pode ser coberta por Testes Unitários, Testes de Integração e Testes Manuais.

Parece que criamos uma boa história de usuário!

Se você usar a estrutura que defini acima e a história atender aos critérios do modelo INVEST, provavelmente é uma boa história.

Armadilhas comuns na criação de Histórias de Usuário

Já vi Histórias de Usuário darem errado no passado, onde as pessoas perderam alguns aspectos cruciais da história do usuário:

Focar nos aspectos técnicos

Como meus exemplos mostram acima, a história do usuário é não técnica.

Não deve haver referência a um nome de serviço, um nome de banco de dados, ou validação com base em qualquer coisa que o usuário não possa ver.

Assim que sua história não puder mais ser entendida pelo usuário final, você errou.

Concentre-se no que o usuário vai fazer e no que o usuário vai ver.

Vamos ver um exemplo de uma história focada tecnicamente:

Como um usuário não logado, quando eu clico no link de senha esquecida com um endereço de e-mail correto, um registro é gravado em uma tabela do banco de dados indicando que o link para redefinição de senha foi enviado.

Esta história não pode ser verificada por um usuário e usuários não técnicos podem não entender o que significa.

Vamos corrigir:

Como um usuário não logado, quando eu clico no link de senha esquecida com um endereço de e-mail correto, um e-mail é enviado para o endereço de e-mail fornecido com um link para redefinição de senha esquecida

Usuários não técnicos podem entender isso e isso coloca o foco no usuário, não no produto.

Colaboração das Partes Interessadas

Ágil é colaborativo.

Histórias do usuário precisam de contribuições do Produto, Analista de Negócios, QA, Engenheiros e, o mais importante, Usuários.

É assim que você garantirá que está entregando o que o usuário deseja. Muitas mãos tornam o trabalho mais leve.

Se, por exemplo, apenas uma equipe de engenharia criasse histórias de usuário, elas poderiam se parecer com isso:

Como usuário logado, quando a página carrega, sou redirecionado para a página inicial logada

Como usuário não logado, quando insiro o endereço de e-mail correto, mas a senha incorreta e clico em Login, uma mensagem de erro aparece

Como usuário não logado, quando insiro um endereço de e-mail e senha incorretos e clico em login, uma mensagem de erro aparece.

E isso é ótimo. Mas agora vamos envolver o QA, que está vindo de uma perspectiva diferente, pois eles têm experiências diferentes com software:

Como usuário não logado, quando insiro um endereço de e-mail correto em hebraico e uma senha correta, sou redirecionado para a página inicial

Como usuário não logado, quando insiro um endereço de e-mail e senha corretos e clico repetidamente em login, sou redirecionado para a página inicial

Ótimo. Estamos obtendo um conjunto mais abrangente de histórias de usuário agora que abrangem mais situações. Mas o que acontece se envolvermos o Produto?

Como usuário não logado, quando a página carrega, meu gerenciador de senhas deve pré-carregar meu nome de usuário e senha, quando clico em login, sou redirecionado para a página inicial

A equipe de Produto conhece os usuários. Eles sabem que as pessoas realmente usam gerenciadores de senhas. Devemos garantir que, quando o usuário não digitar nada (já que o texto é carregado pelo gerenciador de senhas), o login ainda funcione corretamente.

Histórias de Usuário Vagas

A ideia por trás de uma boa história de usuário é que todos, independentemente da expertise, possam entendê-la.

Se você escreveu uma História de Usuário que pode ser interpretada de 10 maneiras diferentes por 10 pessoas diferentes, você se desviou um pouco.

Eu mencionei acima que abordaria os critérios de aceitação, e agora é a hora de fazer isso.

Vamos reexaminar a seguinte História de Usuário:

Como um usuário não logado, quando eu inserir um endereço de e-mail e senha incorretos e clicar em login, uma mensagem de erro aparece.

Há vaguidade nisso.

Que mensagem deve aparecer? Quando a página recarregar após uma tentativa de login inválida, a caixa de texto do nome de usuário deve ser definida como vazia ou pré-preenchida com o valor anteriormente inserido? O que significa “endereço de e-mail incorreto”? Um endereço de e-mail que nunca foi visto antes, ou um endereço de e-mail que não é válido no momento (não pagou a assinatura, assinatura cancelada, etc.)

Como você pode ver, os detalhes importam.

Esta História de Usuário é um exemplo bastante forçado e consegui encontrar muitas perguntas sobre ela.

Vamos corrigir o problema:

Como um usuário não logado, quando eu inserir um endereço de e-mail que não está registrado no sistema, ao clicar em login, uma mensagem de erro aparece.

Isso removeu as dúvidas em torno da ação do usuário, mas não resolveu a questão sobre a mensagem de erro esperada.

Insira os critérios de aceitação.

Dentro da história do usuário, você precisa ter um conjunto de critérios de aceitação que define se a implementação da história do usuário está conforme o esperado.

Coisas como:

  • Mensagem de erro: “Endereço de e-mail ou senha inválidos”

  • Caixas de texto de E-mail e Senha são redefinidas para vazias ao recarregar

  • Usuário incapaz de acessar páginas onde o login é necessário

  • Usuário é apresentado com um “esqueceu a senha” sugerido.

Os critérios de aceitação indicam o que é esperado da implementação.

Como começar com Histórias de Usuário

Comece pequeno.

Você não será perfeito ao refinar e criar histórias de usuário no início.

Criar histórias de usuário é tanto uma arte quanto uma ciência. A prática leva à perfeição.

A criação de Histórias de Usuário deve ser feita em grupo. Frequentemente, isso é feito com a abordagem dos “3 Amigos”, onde você terá um engenheiro, uma pessoa do produto e um QA sentados juntos para idealizar diferentes permutações que você precisa suportar.

Uma vez que você tenha entregue seu projeto, faça uma retrospectiva. Olhe para trás e veja quais lacunas você tem em suas histórias de usuário. Haverá bugs que os usuários encontram, que QA e UAT encontram, e estes são devido a lacunas em suas histórias de usuário ou lacunas em seus testes. De qualquer forma, você deve aprender com eles para a próxima vez.

Conclusão

Ágil é colaborativo. Scrum é colaborativo. Criar Histórias de Usuário é colaborativo. Lembre-se disso.

Quanto mais pessoas de diferentes áreas de especialização você tiver colaborando na criação de histórias de usuário, maior a probabilidade de cobrir todo o conjunto de fluxos de trabalho.

O usuário é o foco. Se você estiver incluindo alguma terminologia que seu usuário não entende, repense a história de usuário.

Você não será perfeito nisso desde o início, mas à medida que você faz mais e mais, mais rápido e mais eficaz você se torna. Tome isso de alguém que está fazendo isso há mais de 10 anos. A diferença em velocidade e qualidade da minha criação de Histórias de Usuário hoje em comparação com 10 anos atrás é um mundo à parte.

Confira meus posts no blog no meu site, Just Another Tech Lead, ou inscreva-se na minha newsletter semanal aqui.