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

Eu vou te mostrar o que são histórias de usuário, armadilhas comuns que eu já vi ao criar histórias de usuário e as estruturas que existem para validar se sua história de usuário é “boa”.

Aqui está o que vamos cobrir:

Os Primórdios 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.

Metodologias Ágeis existem desde 2001, quando 17 engenheiros de software respeitados se reuniram em um resort 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, vá procurá-los. Eles têm um vasto 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 entrega de valor frequentemente ao usuário.

A forma de pensar Ágil encoraja a flexibilidade no planejamento de projetos, o que é um grande contraste com seu concorrente na época, o planejamento de projetos Cascata, que era muito rígido com o 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, em seguida, aprender, iterar e mudar o design e a entrega 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”.

A metodologia ágil promove a entrega de algo de valor rapidamente e com frequência, 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 frequentemente 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 coloca na colaboração próxima e frequente entre as partes interessadas. Produto, QA, Engenharia e Vendas têm uma grande contribuição e feedback constante sobre o projeto ao longo de seu ciclo de vida.

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

Apresentando 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 lê-la 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á colocando ênfase no usuário final e no “valor” que você irá entregar.

Vamos aprofundar nos insumos:

  • 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”? Deletando um registro? Enviando um formulário?

  • Resultado esperado: Uma vez que seu usuário tenha realizado a ação, o que deve acontecer? Se ele clicou em “login” com o endereço de e-mail e senha corretos, para onde ele deve ser direcionado? Se ele clicou em “login” com um endereço de e-mail e senha incorretos, o que deve acontecer?

Exemplo de Histórias de Usuário:

Vamos olhar para 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 entrada de um endereço de e-mail e uma caixa de texto para entrada de 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 eu 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. Abordaremos isso mais tarde nos critérios de aceitação.

Como criar boas Histórias de Usuário

Existe um bom modelo chamado modelo INVEST que mostra de forma simples como saber se suas histórias de usuário 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 o esforço necessário.

  • Simples: Cabe dentro de um sprint.

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

Vamos aplicar este modelo INVEST a um dos exemplos de histórias de usuário acima:

Como um usuário não logado, quando eu inserir o endereço de e-mail e a 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 base teórico e um projeto teórico)

Essa história é independente? Eu diria que sim. É uma história pequena que envolve apenas alguns componentes que provavelmente já existem. 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 ser facilmente 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 usuário não logado, quando eu inserir o endereço de e-mail e senha corretos e clicar 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 esperaria que isso fosse facilmente estimado. É uma história concisa, envolvendo poucos componentes, em um domínio com o qual 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 de usuário e resultados claros. Vamos dar uma olhada em uma história que seria muito grande:

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

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

A história é definitivamente Testável. Há ações claras do usuário a serem tomadas que têm um resultado claro. Essa história do 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

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

Focando 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 baseada em qualquer coisa que o usuário não possa ver.

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

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

Vamos olhar para um exemplo de uma história focada tecnicamente:

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

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

Vamos corrigir isso:

Como um usuário não logado, quando 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 de redefinição de senha esquecida.

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

Colaboração entre Stakeholders

Agile é colaborativo.

Histórias de usuários precisam de input de Produto, BA, QA, Engenheiros e, mais importante, Usuários.

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

Se, por exemplo, apenas uma equipe de engenharia elaborasse as histórias de usuários, elas poderiam ser algo assim:

Como um usuário logado, quando a página carrega, sou redirecionado 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

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

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

Como um 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 um 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 completo de histórias de usuários agora que cobrem mais situações. Mas o que acontece se envolvermos o Produto?

Como um 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 do caminho.

Eu mencionei acima que falaria sobre critérios de aceitação, e agora é hora de fazer isso.

Vamos reexaminar a seguinte história de usuário:

Como um usuário não logado, quando eu digito um endereço de e-mail e senha incorretos e clico 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, o campo de nome de usuário deve ser redefinido para vazio ou pré-preenchido com o valor anteriormente digitado? 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, assinou o cancelamento, etc.)

Como você pode ver, os detalhes importam.

Essa história de usuário é um exemplo bastante artificial e consegui encontrar muitas perguntas sobre ela.

Vamos corrigir o problema:

Como um usuário não logado, quando eu digito um endereço de e-mail que não está registrado no sistema, quando clico 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 definem 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 Endereço de E-mail e Senha são redefinidas para vazias ao recarregar

  • Usuário não consegue acessar páginas que requerem login

  • Usuário é apresentado com a opção de “esqueceu a senha”.

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 em 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. Muitas vezes, isso é feito com a abordagem dos “3 Amigos”, onde você terá um engenheiro, uma pessoa de produto e um QA todos sentados juntos e pensando em diferentes permutações que você precisa apoiar.

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 encontraram, que a QA e a UAT encontraram, e esses 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 participando da criação das histórias de usuário, mais provável será que você cubra o conjunto completo de fluxos de trabalho.

O usuário é o foco. Se você estiver incluindo 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 conforme você faz mais e mais, mais rápido e mais eficaz você se torna. Tome isso de alguém que faz isso há mais de 10 anos. A diferença em velocidade e qualidade na criação das minhas Histórias de Usuário hoje em comparação com 10 anos atrás é um mundo à parte.

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