O que é uma história de usuário? Como (e por que) escrever uma
As histórias de usuário são uma ferramenta central na colaboração de equipes ágeis. Seu campo de aplicação é muito amplo e vai desde a satisfação de necessidades específicas do cliente até o suporte a equipes Scrum.
Mas o que exatamente é uma história de usuário e como ela é realizada? Neste artigo, vamos esclarecer esse conceito: mostraremos como uma história de usuário deve ser estruturada e como trabalhar com sucesso com essa ferramenta.
Descobrindo as histórias de usuários
História de usuário: definição
UserStory é um termo em inglês que pode ser traduzido literalmente como "história do usuário". No campo do gerenciamento ágil de projetos e do desenvolvimento de software, a User Story é uma ferramenta para descrever a funcionalidade de um determinado sistema a partir da perspectiva da experiência do usuário.
Para que ela é usada?
A função da história do usuário é atender às necessidades e expectativas específicas do usuário em relação a determinadas funcionalidades de um software ou solução proposta.
O objetivo da história do usuário é fazer com que o leitor compreenda o benefício do sistema em questão. Dessa forma, é possível obter um maior grau de conscientização dos benefícios do produto ou serviço apresentado.
Uma história de usuário serve, portanto, para aumentar a compreensão de um sistema e, assim, aumentar seu grau de sucesso entre os usuários.
História de Usuário vs. Caso de Uso
O Caso de Uso, ou caso de uso, pode ser considerado uma versão mais ampla da História do Usuário. Na verdade, ele é muito elaborado e detalhado, abrange um contexto mais amplo e, portanto, é mais abrangente do que uma história de usuário. Normalmente, ele inclui até mesmo várias User Stories.
O caso de uso normalmente é mais duradouro do que uma história de usuário. Na verdade, ele costuma ser mantido durante todo o desenvolvimento do sistema, enquanto a história de usuário desaparece após sua conclusão em um Sprint.
Como escrever uma história de usuário
Quem a escreve?
As histórias de usuário podem ser escritas por usuários ou para usuários.
Como são escritas?
Normalmente, a User Story é escrita por uma equipe que se dedica a escrevê-la e otimizá-la. Normalmente, a equipe se concentra, em primeiro lugar, no desenvolvimento de determinados critérios em torno dos quais desenvolverá sua história. Esses critérios podem ser, por exemplo, o grau de complexidade, o modelo a ser seguido, o layout das informações e assim por diante.
Portanto, desde o início, as propriedades estruturais que se deseja atribuir à história devem ser definidas. Se você estiver trabalhando em equipe, deverá dividir as tarefas dentro do grupo e fixar o prazo em que o trabalho deverá ser feito.
Para começar, é necessário estabelecer Story Points, ou seja, números arbitrários usados para estimar a quantidade de trabalho que a equipe é capaz de concluir em cada iteração.
Em seguida, os Sprints, ou seja, os ciclos de trabalho que duram de uma a quatro semanas, também devem ser definidos. O conjunto de Story Points e Sprints formam a base do Planejamento de Estórias de Usuário.
Nesse contexto, os Sprints foram mencionados no plural. No entanto, deve-se observar que apenas uma iteração ou Sprint é frequentemente necessária para a realização de uma história de usuário.
A próxima etapa é garantir que as tarefas sejam claramente expressas e atribuídas a diferentes membros da equipe. A organização e a coordenação são, de fato, cruciais para escrever uma história de usuário de qualidade.
No entanto, acontece de as histórias de usuários serem escritas sem uma análise detalhada das tarefas. O grau em que a história é estruturada é, na verdade, um fator arbitrário e sujeito à livre escolha da equipe. É claro que, quanto mais uma equipe tiver como objetivo garantir serviços excelentes, mais ela favorecerá o planejamento articulado da User Story.
O objetivo do planejamento da História de Usuário deve ser o benefício do usuário, e não a promoção da solução, do produto ou do serviço em questão.
Como proceder?
As histórias de usuários são gerenciadas no Backlog. É aqui que o conceito DEEP, desenvolvido por Roman Pichler, entra em ação. Ele criou esse modelo para operar um Backlog correto. DEEP é um acrônimo que significa as seguintes palavras:
- Detailed Appropriately ( Detalhado adequadamente): as histórias de usuário de alta prioridade devem ser formuladas com mais detalhes do que as de baixa prioridade.
- Estimado : os componentes da história de usuário devem ser estimados, especialmente em relação aos pontos da história. Conhecer, mesmo que aproximadamente, os elementos constituintes de uma história ajuda a priorizar e acompanhar o projeto de lançamento.
- Emergente : a História de Usuário tem um caráter dinâmico. De fato, ela evolui e seu conteúdo pode mudar com frequência. Novos elementos podem surgir com base nas classificações e no feedback dos leitores. Com base nisso, as histórias de usuários precisam ser modificadas, atualizadas e otimizadas.
- Priorização : os componentes da história ou as próprias histórias com alta prioridade devem ser implementados primeiro.
Que abordagem deve ser dada a uma história de usuário?
Quando estiver escrevendo uma história de usuário, é bom ter em mente uma estrutura básica recomendada :
Como x (função do escritor), eu gostaria de xy (referência à funcionalidade desejada), a fim de yy (objetivo).
Além desse modelo básico, existem outras alternativas. Outro modelo possível para uma história de usuário é, por exemplo:
Para yy (finalidade), como eu sou x (função), gostaria de xy (funcionalidade).
A função deve corresponder às suas Personas. Uma Persona é um representante típico de seu grupo-alvo.
As histórias de usuários, como todas as histórias, podem variar no grau de detalhes fornecidos. De fato, algumas histórias podem fornecer apenas um conteúdo muito superficial. Outras, por outro lado, podem apresentar um início genérico, para depois serem refinadas. Outras ainda podem ser detalhadas desde o início.
Seguir um modelo para formular uma história de usuário não é obrigatório, mas é prático. A experiência no campo de histórias de usuários mostrou que manter a estrutura básica recomendada não só ajuda na formulação, mas também facilita a compreensão do leitor.
Em que idioma deve ser escrita?
O idioma preferido para escrever uma história de usuário é o inglês. Essa pode ser uma escolha estranha, especialmente se você estiver atuando no cenário italiano. Entretanto, há muito tempo o inglês se tornou a língua franca em quase todos os países e agora é falado internacionalmente.
Além disso, esse idioma permite um alto grau de concisão, pois é extremamente conciso e direto.
É por isso que pode ser uma escolha sensata apresentar uma história de usuário em inglês.
Exemplos de histórias de usuários
Abaixo estão alguns exemplos de aplicação dos modelos de história de usuário propostos.
1. Como amante de romances históricos, gostaria de ser informado sobre o lançamento de livros relevantes, para poder encomendá-los a tempo na livraria.
2. Como amante de filmes de aventura, gostaria de saber quais filmes desse gênero foram lançados em seu cinema, para poder comprar ingressos on-line.
3. Como sou um amante do cinema, gostaria de saber quais promoções estão disponíveis em seu cinema para que eu possa encontrar uma assinatura acessível.
Dicas para uma história de usuário de qualidade
Como o objetivo da história do usuário é ser recebida e compreendida no menor tempo possível, é importante que ela
- Seja escrita com frases curtas e incisivas;
- Contenha vocabulário simples e não pesquisado;
- Evite detalhes técnicos: pessoas sem formação especializada precisam ser capazes de entender o que estão lendo;
- Concentre-se em fornecer respostas diretas às perguntas: quem quer o quê do sistema? Por que o usuário usa o sistema (para que benefício)?
Nas palavras de Mike Cohn, um dos principais colaboradores da invenção da metodologia de desenvolvimento de software Scrum, todas as histórias de usuário ágeis incluem apenas uma ou duas frases escritas de maneira simples e, o mais importante, uma série de conversas desencadeadas de acordo com a funcionalidade desejada.
Ferramentas de gerenciamento: critérios de aceitação
É possível ter certeza de que uma história de usuário foi totalmente implementada quando os critérios de aceitação forem comprovadamente atendidos. Mas o que são critérios de aceitação?
Por critérios de aceitação com referência a uma história de usuário, entendemos a definição dos parâmetros que demonstram que os principais resultados da história de usuário foram alcançados.
Os parâmetros a que estamos nos referindo são as perguntas W (Who? What? Why? When? Where? etc.).
Elas permitem entender se uma história de usuário é eficaz e responde a todas as possíveis necessidades cognitivas do leitor.
Os critérios de aceitação são, portanto, testes aplicados à história do usuário para verificar sua adequação de acordo com a finalidade de uso. Nesse contexto, deve-se dar atenção especial à identificação e ao aprimoramento das palavras-chave, ou seja, ao uso de verbos, adjetivos e substantivos relevantes.
O princípio INVEST
Uma maneira de testar a eficácia de sua história de usuário é usar o princípio formulado por William Wake. INVEST também é um acrônimo e significa:
- Independente: a história de usuário tem sua própria individualidade e é independente de outras histórias de usuário.
- Negociável: o conteúdo é implementável e continuamente melhorável. É desenvolvido por meio de uma colaboração entre o leitor e os criadores da história. Portanto, ela pode entrar em mais detalhes à medida que sua realização e testes progridem.
- Valiosa: a história do usuário deve ser valiosa para o cliente. Ela deve oferecer ao leitor uma vantagem ou um benefício e fornecer indicações sobre como alcançá-lo.
- Estimável: a capacidade de avaliação de uma história de usuário é o pré-requisito e a condição para que ela seja negociável. A capacidade de avaliação de uma história de usuário também depende de seu tamanho: quanto mais longa for uma história, mais difícil será avaliá-la. Além disso, esse critério também depende da experiência da equipe: um grupo de especialistas será capaz de avaliar uma história com mais habilidade e rapidez do que os novatos.
- Pequena: histórias de usuários de qualidade tendem a ser curtas. A propósito, quanto mais curta for uma história, mais avaliável ela será.
- Testável: a história do usuário tem critérios de aceitação e pode ser testada. Se uma história for dificilmente testável pelos usuários, isso pode significar que ela não é suficientemente clara ou que não oferece um benefício valioso ao leitor.
Em última análise, todos os pontos do princípio INVEST servem para avaliar a qualidade de uma história de usuário e também para orientar sua realização de modo que ela seja eficaz. Seguir os pontos propostos nesse modelo pode fazer toda a diferença para determinar o sucesso da sua história de usuário!
A hierarquia da história de usuário
Como o princípio INVEST deixa claro, as histórias de usuário devem ser independentes umas das outras. Entretanto, na prática, é comum que existam interdependências entre várias histórias de usuário. A dependência das histórias de usuário pode ser de diferentes tipos. Por exemplo, pode ser no nível de conteúdo, técnico, regulatório ou normativo, temporal e assim por diante.
A existência de interdependências entre as User Stories geralmente não é evidente, e é por isso que é útil usar o Mapeamento de User Stories para descobri-las e removê-las.
Histórias de usuário versus histórias épicas
Há uma diferenciação básica na macrocategoria de histórias de usuários. Na verdade, dependendo da extensão dos benefícios que proporcionam ao leitor, as histórias de usuário também podem ser chamadas de histórias épicas.
A diferenciação dessas duas categorias não é homogênea e é sempre a mesma. Isso significa que não há um padrão reconhecido segundo o qual uma história seja automaticamente classificada como User ou Epic.
De modo geral, no entanto, uma história épica pode ser definida como uma história de usuário que possui um alto grau de pungência técnica e especializada. As histórias épicas, de fato, normalmente descrevem a funcionalidade de forma absolutamente detalhada, técnica e específica.
Histórias de usuários: por que usá-las?
Uma User Story é uma ferramenta prática e barata em termos de custos e tempo a ser dedicado a ela. No entanto, há várias vantagens associadas a ela, tais como :
- Especialmente quando detalhada, uma história de usuário pode apoiar o desenvolvimento iterativo de um sistema;
- É fácil de entender e recebida imediatamente;
- Pode ser criada, modificada e substituída rapidamente.
Atualmente, as histórias de usuários são uma das ferramentas favoritas para formular e discutir a funcionalidade de um produto ou serviço. É por isso que conhecer seus mecanismos e aprender a dominá-los é fundamental para a implementação direcionada de qualquer sistema.
Artigo traduzido do italiano