Como escrever histórias de usuários: um guia completo

As histórias de usuários são uma parte vital do desenvolvimento de software ágil adequado: vamos examinar sua função e aprender como escrever histórias de usuários.

As estruturas ágeis são uma maneira popular e eficaz de estruturar o desenvolvimento de software e delegar tarefas. Escrever histórias de usuários (não confundir com como escrever um depoimento) é uma ferramenta no desenvolvimento ágil que permite aos desenvolvedores entender o que precisa ser feito e como atender a um requisito. Isso os torna um ponto de partida muito importante – mas também significa que eles devem ser construídos com cuidado. Aqui está o que você deve saber.

O que é uma história de usuário?

É um termo usado no desenvolvimento de software dentro de uma estrutura ágil. A história do usuário é normalmente considerada a menor unidade no projeto ágil ou a primeira etapa no cumprimento de um requisito. Eles são criados quando um projeto é totalmente planejado.

Então, o que exatamente isso significa? Cada recurso de software tem (ou deveria ter) um propósito específico quando é adicionado a um projeto. Esse propósito deve influenciar todo o seu desenvolvimento e como ele é incorporado à estrutura geral. Os desenvolvedores podem fazer referência a esse propósito sempre que necessário para tomar decisões, especialmente sobre como dividir as metas e o que priorizar. A “história do usuário” é simplesmente uma maneira de descrever o propósito de um recurso.

As histórias do usuário são escritas a partir da perspectiva do usuário, geralmente em apenas uma ou duas frases. Eles capturam o ponto de vista do usuário e o que esse usuário deseja fazer. Quando concluídas, boas histórias de usuários são uma maneira fácil de falar sobre objetivos estratégicos, quais recursos podem ser descartados com segurança ou devem ser adicionados e muito mais.

Como escrever uma história de usuário

Etapa 1. Obter informações

Obtenha informações de proprietários, usuários em potencial e gerentes de projeto. Uma história de usuário forte precisa de muita entrada para ser precisa. Obtenha explicações claras desses grupos sobre o que eles querem fazer. Lembre-se de que isso não deve se traduzir diretamente na história do usuário, mas fornecerá as informações necessárias. Um proprietário pode dizer: “Preciso que as pessoas possam pagar com o PayPal em meu aplicativo”, o que é muito útil, mas não a história do usuário em si.

Etapa 2. Decidir como as histórias de usuário são criadas

Isso depende do seu fluxo de trabalho. Nos estágios iniciais, as histórias do usuário são capturadas em cartões de índice ou post-its durante o planejamento da estrutura geral. Mais tarde, eles são incorporados ao software de gerenciamento de projetos. Alguns membros da equipe pulam o estágio de post-it, enquanto outros dependem dele – o que funcionar para você.

Passo 3. Definir, Definir, Definir

Defina o usuário: Com a entrada, agora você pode definir o usuário. Lembre-se de que nem sempre é o usuário final dos recursos do produto; pode variar dependendo do tipo de usuário. Crie personas de usuário, se necessário. Defina a ação que o usuário está realizando e defina o objetivo do usuário ao realizar esta ação. Inclua essas informações importantes ao criar sua história de usuário para falar com seu público-alvo.

Etapa 4. Escreva a história

Comece a escrever sua história de usuário, ela deve ter apenas uma ou duas frases para prender a atenção do leitor. É tentador ser preciso e técnico aqui, mas uma linguagem ampla, como declarações de missão, pode ser útil. Deixe a história clara e certifique-se de que ela pode ser resolvida ou concluída, para que você possa olhar para trás e confirmar: “Sim, os usuários agora podem fazer isso!”.

Etapa 5. Divida em outras etapas

As histórias de usuários podem precisar de várias etapas para atingir o objetivo final, o que pode exigir um pouco de reestruturação, dependendo da estrutura ágil que você está usando. Lembre-se, a história do usuário é sempre a menor unidade da estrutura. Nesse nível granular, as histórias de usuários devem levar vários dias para serem implementadas.

Se parecer que eles vão demorar muito mais, isso é um sinal para revisitar e ver se a experiência do usuário precisa ser mais detalhada e reestruturada. Se novos requisitos forem adicionados, eles também precisarão ser divididos em histórias de usuários. Embora essas poucas frases sejam o núcleo de histórias de usuário eficazes, elas também podem ser expandidas à medida que o desenvolvimento avança. Vamos dar uma olhada nisso.

Quais são os 3 C's em User Stories?

Cartão : A fase Cartão refere-se a escrever histórias de usuários para a equipe de desenvolvimento em uma ou duas frases. É chamado de cartão porque as histórias do usuário foram originalmente escritas em cartões de índice e muitas equipes ainda preferem fazê-lo dessa forma. O cartão é o núcleo de seu requisito de software específico e o ponto de partida para todas as discussões. Também é fácil verificar se sua história de usuário é muito longa – se não couber em um cartão de índice que todos possam ler, ela precisa ser abreviada.

Conversa : Uma vez que as frases do cartão foram criadas, é hora de elaborar os detalhes. Isso geralmente começa com uma série de perguntas entre os desenvolvedores, como: “Quanto tempo isso vai levar para ser implementado?” ou “Como podemos incorporar esta ação?” ou “Essa história de usuário é essencial aqui?” E assim por diante.

Esse exame minucioso da história do usuário provavelmente resultará em perguntas adicionais a serem feitas aos gerentes de projeto e proprietários de produtos, que devem ser incluídos na conversa conforme necessário. À medida que a conversa continua, as histórias do usuário podem ser alteradas, refinadas, mescladas ou removidas até que todos estejam na mesma página. À medida que as histórias do usuário são finalizadas, elas são movidas para a implementação, um sinal de que a conversa está essencialmente encerrada.

Confirmação : A confirmação tem tudo a ver com testes de aceitação, também conhecidos como critérios de aceitação. Assim que a mudança for implementada e os desenvolvedores informarem que ela está pronta – que a história do usuário foi satisfeita – é hora de testá-la.

Os testes de aceitação devem ser criados com a entrada do proprietário do produto e vinculados diretamente à história do usuário. Na melhor das hipóteses, é um usuário simplesmente tentando fazer o que a história do usuário indica e vendo se consegue. Mas os testes de aceitação podem variar e nem sempre são feitos com as histórias do usuário em mente como deveriam. Se isso criar um problema, é hora de voltar para a etapa de Conversação até que os testes de aceitação e as histórias de usuários estejam devidamente alinhados. Se todos os testes de aceitação forem concluídos, a história do usuário ficará encantada. Agora é hora de passar para a próxima etapa no desenvolvimento do produto ou liberar o recurso.

Um 4º C? : Curiosamente, alguns argumentam que há um 4º C: Contexto essencial. Nesse caso, a história do usuário é visualizada juntamente com as outras histórias do usuário na estrutura maior do projeto. Aqui, os desenvolvedores perguntam se a história do usuário complementa outras histórias do usuário sem problemas ou se há lacunas – coisas que o usuário precisa fazer ou entender que foram perdidas entre as histórias do usuário.

Idealmente, isso é percebido durante a fase de Conversação, mas nem sempre isso acontece. Algumas equipes de desenvolvimento podem querer uma revisão final de como a história de usuário concluída se encaixa no todo maior e se algum trabalho adicional precisa ser feito.

Qual é um bom formato para uma história de usuário?

Vamos examinar duas técnicas de formatação que são muito úteis ao criar frases de história de usuário. A primeira é muito simples: “Quem, o quê e por quê?” Em um modelo de frase, isso pode ser descrito assim:

Como [quem é o usuário], eu quero [o que o usuário deseja] (para que [por que o usuário deseja]).

Este modelo também pode ser enquadrado como: “Como [função], quero [ação], (para que [beneficie])”, para simplificar a terminologia. Seguir esse formato básico é suficiente para criar a maioria das histórias de usuários. Normalmente, é tudo o que você precisa e pode ajudar a economizar muito tempo quando usado para cada história de usuário.

Às vezes, no entanto, as histórias de usuários são mais difíceis de definir em projetos mais complexos. Nesse caso, uma segunda técnica de modelo de história de usuário pode ser útil. Chama-se INVEST, uma sigla que significa:

• Independente : as histórias devem ser totalmente independentes umas das outras e, como resultado, as histórias devem poder ser trabalhadas fora da sequência.
• Negociável : as histórias devem ser projetadas para serem alteradas durante a parte de Conversação do processo.
• Valioso : a história do usuário deve demonstrar um valor claro para o projeto. Se não puder, pode ser um desperdício de recursos.
• Estimável : uma história de usuário deve ser medida em valor e priorização para ajudar a decidir no que trabalhar em ordem de importância.
• Pequeno : as histórias do usuário devem ser a menor unidade de funcionalidade e, caso contrário, devem ser divididas ainda mais.
• Testável : A história do usuário deve ser declarada de forma testável durante o processo de confirmação.

Perguntas frequentes sobre como escrever histórias de usuários

Você também pode estar interessado em nosso guia sobre como escrever uma crítica de jogo.