Como Escrever Histórias de Utilizador (com Exemplos e Critérios de Aceitação)
Uma história de utilizador é uma descrição curta de uma funcionalidade do ponto de vista do utilizador: “Como [tipo de utilizador], quero [objetivo] para que [motivo].” Por baixo, escreve-se os critérios de aceitação, algumas condições específicas que têm de ser verdadeiras para que a história seja considerada concluída. Mantenha cada história pequena o suficiente para ser construída e testada de uma vez, e escreva os critérios de forma a que qualquer pessoa os possa verificar.
As histórias de utilizador tornaram-se populares em equipas ágeis de software, mas são igualmente úteis quando constrói sozinho com um criador de aplicações com IA. Uma boa história é um bom prompt.
O formato
Uma história de utilizador tem três partes:
Como [quem], quero [o quê] para que [porquê].
- Quem é um tipo específico de utilizador: um visitante que chega pela primeira vez, um membro pagante, um rececionista de uma clínica, um administrador. Não “o utilizador”.
- O quê é aquilo que a pessoa quer fazer, nas suas palavras. Não a forma como o ecrã funciona.
- Porquê é o resultado que a pessoa valoriza. É a parte que as pessoas costumam saltar, e a que impede que construa a coisa errada.
Exemplo:
Como membro do ginásio, quero cancelar uma reserva de aula no telemóvel para que alguém da lista de espera possa ocupar o meu lugar e eu não seja cobrado por falta de comparência.
O “porquê” diz-lhe duas coisas que o “o quê” não dizia: tem de funcionar num telemóvel, e a lista de espera e as regras de taxas estão envolvidas.
Critérios de aceitação
Uma história diz o que se pretende. Os critérios de aceitação dizem quando está pronta. Devem ser suficientemente específicos para que duas pessoas concordem sobre se cada um passa ou não.
Uma forma comum de os escrever é Dado / Quando / Então:
- Dado uma situação inicial
- Quando o utilizador faz algo
- Então este é o resultado
Para a história da reserva no ginásio:
- Dado que tenho uma reserva com mais de 12 horas de antecedência, quando toco em Cancelar e confirmo, então a reserva é removida e vejo “Reserva cancelada”.
- Dado que cancelo uma reserva e a aula tem lista de espera, quando o cancelamento é guardado, então a primeira pessoa da lista de espera fica com o lugar e recebe um e-mail.
- Dado uma reserva com menos de 12 horas de antecedência, quando toco em Cancelar, então vejo que se aplica uma taxa de cancelamento tardio antes de confirmar.
- Dado que estou num ecrã da largura de um telemóvel, então o botão Cancelar está visível sem fazer deslocamento lateral.
Uma lista de verificação simples também funciona, desde que cada item seja testável. “Cancelar é fácil” não é testável. “Cancelar demora no máximo dois toques a partir da lista de reservas” é.
Passo a passo: como escrever uma boa história
Passo 1: Parta de um utilizador real e de um problema real
Escolha um tipo de utilizador e algo com que tenha dificuldade hoje. Se fez entrevistas a clientes, use as palavras deles. “Esqueço-me sempre de cancelar e sou cobrado” é um ponto de partida melhor do que “adicionar funcionalidade de cancelamento”.
Passo 2: Escreva a história numa linha
Preencha o modelo. Se não conseguir escrever um “para que” convincente, pergunte-se se a funcionalidade é mesmo necessária.
Passo 3: Acrescente entre três e seis critérios de aceitação
Cubra primeiro o caso de sucesso principal e depois as variações importantes: um papel diferente, um estado vazio, um limite, um erro. Se escrever mais de seis, a história é provavelmente demasiado grande.
Passo 4: Indique o que está fora do âmbito
Uma linha poupa muito vaivém: “Fora do âmbito: reembolsos de aulas pagas; administradores que cancelam em nome dos membros.” Impede que a história cresça enquanto a constrói.
Passo 5: Verifique-a com o INVEST
O INVEST é uma lista de verificação comum para boas histórias. Uma história deve ser:
| Letra | Significa | Teste rápido |
|---|---|---|
| I | Independente | Pode ser construída sem esperar por outra história |
| N | Negociável | Descreve a necessidade, não um desenho fixo |
| V | Valiosa | Um utilizador daria por ela se fosse lançada |
| E | Estimável | Consegue adivinhar mais ou menos a sua dimensão |
| S | Pequena | Construída e testada numa só sessão |
| T | Testável | Cada critério de aceitação pode ser verificado |
Não precisa de pontuar cada história. É mais útil quando uma história parece errada e quer perceber porquê.
Exemplos bons e maus
| História fraca | Problema | História melhor |
|---|---|---|
| Como utilizador, quero um painel. | Sem utilizador específico, sem motivo, não testável | Como dona de uma loja, quero ver as encomendas e as receitas de hoje num só ecrã para que saiba de imediato se o dia está a correr bem. |
| Como administrador, quero que a base de dados tenha uma coluna de estado. | Descreve a implementação, não uma necessidade | Como administrador, quero marcar encomendas como enviadas para que os clientes deixem de enviar e-mails a perguntar onde estão. |
| Como cliente, quero gerir a minha conta. | Demasiado grande: abrange muitas funcionalidades | Como cliente, quero alterar o meu endereço de e-mail para que os recibos cheguem à minha nova caixa de entrada. |
| Como visitante, quero que o site seja rápido. | Não é uma história; é uma qualidade que todos precisam | Escreva-o como critério em cada história, ou como um objetivo de desempenho separado. |
Como dividir uma história demasiado grande
As histórias grandes são onde os projetos param. Formas comuns de as dividir:
- Por tipo de utilizador. Os membros cancelam as suas próprias reservas; o pessoal cancela as de qualquer um.
- Por passo do fluxo. Navegar pelas aulas; reservar uma aula; receber um lembrete.
- Primeiro o caso simples. Cancelar uma aula gratuita agora; tratar de taxas e reembolsos numa história posterior.
- Por variação de dados. Suportar primeiro uma localização; várias depois.
- Caminho feliz e depois erros. Construir primeiro a funcionar e depois acrescentar o tratamento para aulas cheias, passes expirados, e assim por diante.
Cada parte deve continuar a ser algo que um utilizador possa usar e notar.
Usar histórias de utilizador como prompts
Uma história de utilizador com critérios de aceitação está muito próxima de um bom prompt para um criador de aplicações com IA. Dá à IA o quem, o quê, o porquê e uma definição de conclusão. Envie uma história por mensagem:
Como membro do ginásio, quero cancelar uma reserva de aula no telemóvel para que alguém da lista de espera possa ocupar o meu lugar. Critérios de aceitação:
- Cancelar aparece em cada reserva em As Minhas Reservas, com um passo de confirmação.
- Cancelar com mais de 12 horas de antecedência remove simplesmente a reserva.
- Com menos de 12 horas, mostre “Aplica-se uma taxa de cancelamento tardio de 5 €” antes de confirmar, e registe a taxa na reserva.
- Se a aula tiver lista de espera, a primeira pessoa fica com o lugar e recebe um e-mail.
- Funciona num ecrã da largura de um telemóvel. Fora do âmbito: reembolsos, cancelamentos feitos pelo pessoal em nome dos membros. Construa isto e depois verifique cada critério na pré-visualização e diga-me quais passam.
Pode também pedir à IA que redija histórias a partir de uma ideia aproximada e depois editá-las você:
Esta é a minha ideia de aplicação: [duas ou três frases]. Escreva as histórias de utilizador para uma primeira versão, agrupadas por tipo de utilizador, cada uma com 3 a 5 critérios de aceitação Dado/Quando/Então. Marque quais são essenciais para o lançamento e quais podem esperar.
Leia e edite sempre o resultado. A IA não conhece os seus utilizadores; você conhece.
Os critérios de aceitação funcionam também como o seu plano de testes. Quando a história estiver construída, percorra você mesmo cada critério. O nosso guia sobre como testar a sua aplicação antes do lançamento baseia-se nisto.
Onde as histórias de utilizador encaixam com outros documentos
- Um documento de requisitos de produto descreve o produto inteiro: o problema, os utilizadores, o âmbito. As histórias de utilizador são as peças detalhadas dentro dele. Veja como escrever um PRD com IA.
- Um relatório de erro descreve algo que está partido em relação a uma história já construída. Veja como escrever um bom relatório de erro.
- Um MVP é o conjunto mais pequeno de histórias que entrega o valor central. Veja o que é um MVP.
Erros comuns
- “Como utilizador…” Demasiado vago. Indique o tipo real de utilizador.
- Omitir o “para que”. Sem o motivo, não consegue tomar decisões sensatas de compromisso.
- Escrever a solução em vez da necessidade. “Quero um menu de seleção” fixa um desenho antes de alguém ter pensado nele.
- Critérios que não se conseguem testar. “Fácil”, “rápido” e “intuitivo” são desejos, não critérios.
- Histórias que são na verdade épicos. “Gerir a minha conta” são dez histórias.
- Escrever todas as histórias logo no início. Escreva as próximas em detalhe; mantenha as restantes como uma linha até chegar a elas.
Histórias na Mythex
Na Mythex, o modo Plan é um bom sítio para transformar uma ideia em histórias: o agente discute a abordagem antes de editar seja o que for. Quando uma história estiver pronta, mude para Build e cole-a, uma história por mensagem. Depois de cada uma, /test pode percorrer a pré-visualização e verificar o fluxo, e pode reverter qualquer resposta com Reverter para este ponto se tiver corrido mal. Veja prompts eficazes na documentação, e o nosso guia sobre como escrever prompts para criadores de aplicações com IA.
Lista de verificação de histórias de utilizador
- Indica um tipo específico de utilizador
- Descreve uma necessidade, não um desenho
- Inclui um “para que” real
- Tem entre três e seis critérios de aceitação testáveis
- Cobre pelo menos um caso-limite ou erro
- Indica o que está fora do âmbito
- Pequena o suficiente para ser construída e testada de uma vez
- Critérios verificados depois da construção, um a um
Perguntas
Qual é o formato de uma história de utilizador?
O modelo comum é: Como [tipo de utilizador], quero [objetivo] para que [motivo]. Segue-se uma lista de critérios de aceitação, ou seja, condições curtas que têm de ser verdadeiras para que a história seja considerada concluída.
O que são critérios de aceitação?
Os critérios de aceitação são condições específicas e testáveis que definem quando uma história de utilizador está concluída. Costumam escrever-se no formato Dado / Quando / Então: dada uma situação inicial, quando o utilizador faz algo, então acontece um determinado resultado.
Qual deve ser a dimensão de uma história de utilizador?
Pequena o suficiente para ser construída e testada de uma só vez, mas ainda assim valiosa por si. Se uma história tiver mais de cinco ou seis critérios de aceitação ou abranger vários ecrãs, divida-a por tipo de utilizador, por passo do fluxo ou primeiro pelo caso simples, deixando os casos-limite para depois.
As histórias de utilizador são úteis quando se constrói com IA?
Sim. Uma história de utilizador com critérios de aceitação está muito próxima de um prompt ideal: diz para quem é a funcionalidade, do que essa pessoa precisa e exatamente como verificar que funciona. Enviar uma história por mensagem também mantém as alterações da IA pequenas e fáceis de testar.