O que uma história de usuário é e não é
As histórias de usuários surgiram como resultado da necessidade da Extreme Programming (XP), do Kanban e do Scrum de dividir projetos em segmentos menores e incrementais para sprints e iterações. Eles diferem dos casos de uso em que se concentram na menor unidade de trabalho possível. Os casos de uso, originalmente introduzidos por Ivar Jacobson, podem ser compostos por várias histórias baseadas em um tema comum. As histórias em si são narrativas simples que delineiam uma única expectativa ou meta de usuário. Você pode detalhar a criação de uma história de usuário em três estágios:
- Descreva a necessidade.
- Planeje a iteração.
- Implemente e teste a conclusão da história.
Em cada estágio, a história do usuário pode ser refinada à perfeição.
As histórias de usuários não contêm uma lista de requisitos ou instruções de codificação, mas estarão associadas a critérios ou testes de aceitação. O objetivo de uma história de usuário não é se concentrar em como construir, no entanto. Em vez disso, o foco está em quem quer o recurso, o que ele fará e por que é importante. As histórias trazem um elemento humano para características que eventualmente compõem a lista de tarefas da atividade de backlog.
Por que as histórias de usuários são importantes?
Mais do que apenas uma lista de recursos, as histórias trazem o usuário para a conversa. As histórias de usuários fornecem contexto para o desenvolvimento de software, concentrando-se no valor que o usuário experimentará. Este processo de colocar pessoas em primeiro lugar silencia a linguagem do método ágil, permitindo que quem não é desenvolvedor colabore e participe das conversas.
As histórias de usuários ajudam a facilitar o diálogo constante em todo o projeto de desenvolvimento de TI para ajudar em áreas como iteração/planejamento de sprint e priorizar o backlog para um lançamento. Por outro lado, o desenvolvimento tradicional Waterfall abraça o diálogo no início e no fim do processo de desenvolvimento.
Em seu livro User Stories Applied for Agile Software, Mike Cohn, da Mountain Goat Software, diz: "Tomamos decisões com base nas informações que temos na hora e fazemos isso com frequência. Em vez de tomar um conjunto abrangente de decisões no início de um projeto, espalhamos a tomada de decisões ao longo da duração do projeto. Para fazer isso, garantimos que tenhamos um processo que nos ofereça informações o mais cedo e com mais frequência possível. E é aí que entram as histórias de usuários."
Quem escreve a história do usuário?
Proprietários de produtos, partes interessadas, gerentes de produto e outros membros da equipe de negócios participam da redação de histórias de usuários. Muitos dirão, no entanto, que quem as escreve é menos importante do que quem participa das discussões e conversas que trazem as histórias à vida. Comece identificando quem usará o recurso (a persona), que pode ser tão detalhada quanto necessário. O usuário pode ser definido em termos de função ou descrição do trabalho, como estudante, passageiro frequente ou gerente de marketing.
Ter uma compreensão forte do usuário final limita os vieses ou suposições do desenvolvedor. Se os usuários estiverem disponíveis, eles podem participar, mas muitas vezes a equipe tem designers, gerentes, escritores e outros que atuam como representantes de clientes. Os participantes podem variar de acordo com o uso da história do usuário. Por exemplo:
- Criação de história de usuário: os participantes podem incluir clientes, gerenciamento de produtos, engenharia e outras partes interessadas, como RH, finanças e vendas.
- Manutenção da história do usuário: os participantes incluem o gerenciamento de produtos ou o proprietário de um produto.
- Aplicação e uso da história do usuário: os participantes incluem engenheiros/desenvolvedores, escritores técnicos e testadores de garantia de qualidade.
Como escrever histórias de usuários eficazes
As histórias de usuários são declarações de benefícios simples e resumidas com uma função valiosa. Antes de escrever a história do usuário, realize pesquisas de usuários e entrevistas para consultar o usuário sobre a funcionalidade necessária. Comece escrevendo uma jornada de cliente, declarada em histórias incrementais, em cartões de 3x5 polegadas ou notas Post-it. Esses cartões podem ser colocados imediatamente em produção ou fornecer contexto para o backlog.
No caso do mapeamento da história do usuário, você pode exibir notas Post-it ao longo de uma parede da sala de conferência para que toda a equipe possa vê-las e trabalhar no planejamento de longo alcance.
Existem algumas técnicas que você pode usar para ajudar a escrever as histórias de que você precisa. Uma técnica comum é a estrutura de RGB (Função-Recurso-Razão ou Benefício) que você constrói preenchendo os espaços em branco desta frase:
- Como um (usuário/persona/cliente), quero (fazer algo) para que eu (receba um benefício).
A técnica de adicionar à pergunta RGB é um método pioneiro de Ron Jeffries que destaca sua "abordagem de três C:"
- Cartão: escreva a resposta para o RGB (descrito acima) no cartão.
- Conversa: o detalhe limitado no cartão é a base de uma promessa cumprida pelo segundo C. Durante esta fase, a equipe discute os detalhes e estabelece uma definição de "concluído".
- Confirmação: este é o resultado do feedback que determina os critérios de teste ou aceitação. Este critério de aceitação é frequentemente escrito na parte de trás do cartão e é usado como lista de verificação inicial durante reuniões futuras para determinar a conclusão.
Introduzido pela primeira vez em um artigo de Bill Wake em 2003 e popularizado pelo livro de Mike Cohn, User Stories Applied for Agile Software Development, a sigla INVEST é um método para avaliar histórias de usuários. Os critérios INVEST são os seguintes:
- Independência para se desenvolver em qualquer sequência.
- Capacidade de Negociar a extensão da história a se desenvolver.
- Fornece Valor ao usuário ou à empresa.
- Pode ser Estimado para conclusão.
- É Pequeno o suficiente para projetar, codificar e testar em uma única iteração.
- E, finalmente, pode ser Testado.
Escrever histórias de usuários que seguem os métodos RGB e três Cs são bons pontos de partida. Avaliar a eficácia em relação às metas INVEST mantém as histórias pequenas, funcionais e testáveis.
Bennett Lauber, Chief Experience Officer with The Usability People, LLC, makes the following suggestions for someone preparing to write their first user story: “Make sure you do some research on your users and create personas. This will help the development team have empathy with the user.”
Modelo de história de usuário ágil
Pronto para escrever uma história de usuário? Baixe um modelo gratuito para ajudá-lo a definir claramente o recurso do ponto de vista do usuário final. O modelo inclui espaço para o tipo de usuário, o que ele quer e por que ele quer. Ao criar essas histórias curtas de usuários de uma frase, a equipe de desenvolvimento pode desenvolver um código que satisfaça os requisitos da história do usuário. Encontre outros modelos ágeis úteis que você pode baixar aqui.
Baixe o modelo simples de história de usuário ágil
Como escrever um caso de teste a partir de uma história de usuário
Uma história de usuário fornece a orientação para o desenvolvimento de testes ou critérios de aceitação. Esta lista de verificação ajuda os desenvolvedores a determinar quando o recurso está concluído. Como em todos os elementos das histórias do usuário, os critérios de aceitação também são escritos do ponto de vista do usuário. Os critérios de teste ou aceitação descrevem os elementos necessários para realizar com sucesso a função necessária.
Este critério deve incluir o seguinte:
- Os requisitos funcionais e não funcionais pretendidos
- Os cenários negativos da funcionalidade
- As diretrizes de desempenho
- O fluxo de trabalho adequado do usuário
- O impacto para outras funções
- A experiência do usuário
Thomas Stiehm, CTO at Coveros, writes test cases using Gherkin Language. “This is the given, when, then (GWT) format,” he says. “I use test automation in Cucumber and that consumes Gherkin for automated testing. In addition, involving an experienced tester helps create better stories. They can ask important functionality questions while the story is being developed, which in turn results in more usable functionality.”
Vamos usar um registro de conferência como exemplo de caso de teste: um usuário envia um formulário que inclui suas informações de contato, ele escolhe uma opção de pagamento e uma confirmação é exibida na tela e enviada por e-mail. Isso se torna parte da lista de aceitação. O caso de teste também considera a facilidade e o fluxo da experiência do usuário (UX). Como a própria história do usuário, a quantidade de detalhes testados reflete apenas o que é necessário para garantir que o recurso entregue valor.
Hernan Santiesteban, of Great Lakes Web, shares his advice. “One of the best ways to write a test case is to use the given, when, then template, which establishes test conditions, user actions, and expected outcome. For example: given an administrative user signs in successfully, when the admin opens the user dashboard, then the admin will be presented with user management functions.”
Os benefícios de escrever boas histórias de usuários
Para alguns gerentes de produto e membros da equipe de desenvolvimento, escrever histórias de usuários em vez de listas de requisitos pode parecer adicionar mais etapas ao processo ágil geral. No entanto, um dos principais benefícios das histórias de usuários é que elas são dependentes da colaboração e mantêm todos informados e na mesma página. As coisas podem mudar durante os processos de desenvolvimento por meio da descoberta e feedback das partes interessadas; como resultado, as histórias de usuários podem mudar ou se adaptar a essas circunstâncias.
Alguns dos benefícios mais comuns incluem o seguinte:
- Demonstrar progresso rapidamente dividindo o quadro geral em projetos menores.
- Motivar a equipe e manter o projeto avançando com sucessos rápidos.
- Colocar os usuários finais em primeiro lugar e, assim, promover maior aceitação e satisfação do usuário.
- Priorizar recursos de alto valor.
- Fornecer a plataforma para conversas colaborativas que permitam um planejamento criativo de soluções.
- Incentivar altos níveis de cooperação que mantêm a equipe focada em resultados que, por sua vez, criam produtos melhores em geral.
Como escrever uma boa história de usuário
Parece contraintuitivo que o desenvolvimento de grandes iniciativas de software tenha sucesso e eficiência ao utilizar um método antigo. Cartões 3x5 simples de cores variadas e um marcador permanente são a base da humildade na criação de histórias de usuários que trazem contexto a um processo de desenvolvimento ágil. Os cartões pequenos incentivam descrições básicas baseadas em benefícios que são descobertos por meio da colaboração em equipe.
Todas as histórias de usuário são exclusivas e devem ser complementadas por mapas de histórias, diagramas, storyboards e mockups, mas abaixo estão algumas práticas recomendadas que podem ajudá-lo a escrever uma história eficaz de usuário:
- Conheça seu usuário: defina e entenda sua persona de usuário.
- Inclua todas as partes interessadas: certifique-se de incluir todas as partes interessadas relevantes no processo de escrita da história do usuário. A equipe de teste pode até ser capaz de refinar a história.
- Concentre-se no usuário: discussões e conversas sob a perspectiva do usuário fornecem contexto e uma definição do que constitui "concluído".
- Mantenha a história curta e simples: descreva apenas uma funcionalidade em cada história de usuário. Se uma história é muito grande para ser desenvolvida em um curto período, divida-a em incrementos menores ou crie condições específicas que possam ser adicionadas que limitem a função. Uma boa regra é que uma história de usuário deve ser pequena o suficiente para que a equipe de desenvolvimento possa completá-la em uma iteração.
- Discuta e colabore: discussões sobre o tamanho do projeto, o Produto Viável Mínimo (MVP), quem o usará, o que ele fará e por que ele traz valor são de toda ajuda nas decisões sobre inclusão e escopo.
- Evite detalhes técnicos: não escreva tarefas técnicas ou declarações de "como construir" nas histórias do usuário, pois elas podem impedir a criatividade e a colaboração. Detalhes técnicos virão mais tarde no processo e serão incorporados por desenvolvedores, testadores e arquitetos de sistemas. Um modelo pode ajudar a orientar os detalhes técnicos.
- Concentre-se nestas 3 perguntas: quem vai usá-lo, o que é e por que é importante.
- Incentive a visualização: use quaisquer métodos (desenhos, mapeamento de histórias e impactos, storyboards e mockups ou protótipos) que sejam apropriados para visualizar o produto finalizado.
- Esclareça o valor e o benefício: certifique-se de que o propósito da história seja claro, a urgência seja notada e a história esteja concluída.
Desafios e armadilhas comuns de escrever histórias de usuários
Uma história de usuário responde a perguntas como quem usará o recurso, o que o recurso fará e por que o recurso é importante. Os detalhes da história fornecem o contexto comercial, o valor do usuário e impulsionam as discussões em equipe. Um desafio comum ao escrever histórias de usuários é garantir que a história seja abrangente o suficiente para articular valor, mas simples o suficiente para entregar em um curto período, como um sprint (que geralmente é entre uma e quatro semanas). A história não deve conter detalhes técnicos de como ela será construída ou instruções de codificação. Esses detalhes não são necessários neste momento do desenvolvimento.
Se uma história é muito grande ou muito ampla, ela pode ser dividida em pequenas partes.
Aqui está um bom exemplo:
- Como cliente do banco, quero poder ver meu saldo para que eu possa planejar pagamentos de contas.
Pode ser tentador adicionar mais detalhes ou outras funções, mas isso criará uma narrativa desordeira. Este tipo de história seria algo assim:
- Como gerente de vendas, quero obter meus relatórios de previsão, vendas e pessoal, para que eu possa definir meu orçamento para um ano inteiro.
Este exemplo tem vários componentes (gerar relatórios individuais: previsão, vendas e pessoal) que devem ser divididos em várias histórias de usuários menores.
Além disso, certifique-se de incluir critérios de aceitação, que identificam o que constitui "concluído". Como observado acima, os critérios de aceitação são frequentemente escritos como uma lista de verificação na parte de trás do cartão de história do usuário.
Desafios adicionais ao escrever critérios de aceitação incluem o seguinte:
- A tendência natural de se concentrar em como construir. No entanto, deixar este detalhe técnico fora do diálogo gera conversas mais significativas que levam a soluções criativas e também permite a inclusão de usuários e membros da equipe não técnica nas discussões.
- Diálogos e conversas podem ser demorados e muitas vezes são esquecidos, o que limita o impacto positivo das histórias de usuários.
- A falta de dados ou de uma compreensão real do usuário ou persona coloca em risco a aceitação da funcionalidade quando colocada nas mãos do usuário final.
- Limitar histórias ao menor incremento não é fácil, mas muitos detalhes tornam a história do usuário difícil.
- Deixar de fora informações essenciais, como critérios de aceitação ou benefícios do cliente, pode deixar perguntas sem resposta durante o processo de desenvolvimento.
O livro User Stories Applied for Agile Software, de Mike Cohn, identifica o principal problema no desenvolvimento de software com esta simples observação: "Os requisitos de software são um problema de comunicação."
A linguagem técnica associada ao desenvolvimento de software e metodologias ágeis pode ser um obstáculo para muitos. Ao longo do processo de desenvolvimento, escrever histórias de usuários incorpora diálogos e conversas abertas, divide tarefas para manter o ritmo fluindo e fornece fortes definições de conclusão. A construção de software é um processo demorado em larga escala com muitas partes interessadas e altas expectativas. No entanto, ao seguir algumas diretrizes simples e algumas técnicas antigas, os meandros da construção de software se tornam mais visíveis para uma equipe inteira e, no final, mais factíveis.
Melhore a escrita de histórias de usuários com o Smartsheet for Software Development
Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.