O que é uma história de usuário?
Uma história de usuário é uma descrição curta e simples de um recurso contada da perspectiva da pessoa que deseja o novo recurso, geralmente um usuário ou cliente do sistema. As histórias de usuários geralmente seguem um modelo simples:
Como um < tipo de usuário >, eu quero < algum objetivo > para que < algum motivo >
Histórias de usuários foram historicamente escritas em cartões de índice ou notas adesivas, armazenadas em uma caixa de sapatos e dispostas em paredes ou mesas para facilitar o planejamento e a discussão. Hoje em dia, eles podem facilmente ser armazenados em um problema do Jira.
As histórias de usuários são projetadas para mudar fortemente o foco de escrever sobre recursos para discuti-los. Na verdade, essas discussões são mais importantes do que qualquer texto escrito.
O que é uma boa história de usuário?
As histórias de usuários ágeis são compostas de três aspectos que Ron Jeffries nomeou em 2001 com a maravilhosa aliteração de cartão, conversa e confirmação:
1- Cartão: Descrição escrita da história, usada para planejamento e como lembrete
2- Conversa: Conversas sobre a história que servem para aprofundar os detalhes da história
3- Confirmação: Testes que transmitem e documentam detalhes que podem ser usados para determinar quando uma história está completa.
As histórias de usuário têm muitas vantagens, mas a mais importante pode ser que cada história de usuário é um espaço reservado para uma conversa futura.
Como escrever uma história de usuário
Escrever boas histórias de usuário no Scrum requer uma compreensão do modelo básico de história de usuário, foco no usuário ou cliente e uma visão clara da funcionalidade desejada. Modelo de História do Usuário Ao escrever uma história de usuário, lembre-se de que as histórias de usuário seguem um modelo padrão:
Como um < tipo de usuário >, eu quero < algum objetivo > para que < algum motivo >
Exemplos de histórias de usuários
Uma das melhores maneiras de aprender a escrever uma história de usuário em ágil é ver exemplos. Abaixo está um exemplo de história de usuário ou dois. Estes são alguns exemplos reais de histórias de usuários que descrevem a funcionalidade desejada em uma versão inicial do site da Scrum Alliance.
Como membro do site, posso preencher um formulário para me tornar um Certified Scrum Trainer para que eu possa ministrar cursos de CSM e CSPO e certificar outros. Como instrutor, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma delas, para que os participantes em potencial possam encontrar meus cursos. Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para acessar coisas que me lembro do passado ou que outras pessoas mencionaram para mim. Como visitante do site, posso ver uma lista de todos os “Cursos de Certificação” futuros e posso folheá-los se houver muitos, para que eu possa escolher o melhor curso para mim. Observe que você não vê nenhuma história de usuário, “Como proprietário do produto, desejo uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário/cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.
- Como membro do site, posso preencher um formulário para me tornar um Certified Scrum Trainer para que eu possa ministrar cursos de CSM e CSPO e certificar outros.
- Como instrutor, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma delas, para que os participantes em potencial possam encontrar meus cursos.
- Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para acessar coisas que me lembro do passado ou que outras pessoas mencionaram para mim. Como visitante do site, posso ver uma lista de todos os “Cursos de Certificação” futuros e posso folheá-los se houver muitos, para que eu possa escolher o melhor curso para mim.
Observe que você não vê nenhuma história de usuário, “Como proprietário do produto, desejo uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário/cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.
Quem escreve histórias de usuários?
Quem escreve histórias de usuários? Qualquer pessoa pode escrever histórias de usuários.
O proprietário do produto (product owner) escreve histórias de usuários?
É responsabilidade do proprietário do produto garantir a existência de um backlog de histórias de usuários ágeis, mas isso não significa que o proprietário do produto é quem as escreve. Ao longo de um bom projeto ágil, você deve contar com histórias de usuário escritas por cada membro da equipe.
Além disso, observe que quem escreve uma história de usuário é muito menos importante do que quem está envolvido nas discussões dela.
Quando as histórias de usuários são escritas?
As histórias do usuário são escritas ao longo do projeto ágil. Normalmente, um workshop de redação de histórias é realizado próximo ao início do projeto ágil. Todos na equipe participam com o objetivo de criar um product backlog que descreva completamente a funcionalidade a ser adicionada ao longo do projeto ou um ciclo de lançamento de três a seis meses dentro dele.
Algumas dessas histórias de usuários ágeis serão, sem dúvida, épicas. Os épicos serão posteriormente decompostos em histórias menores que se encaixam mais facilmente em uma única iteração. Além disso, novas histórias podem ser escritas e adicionadas ao backlog do produto a qualquer momento e por qualquer pessoa.
Você pode mostrar outros exemplos de histórias de usuários?
Como um exemplo mais genérico de escrever histórias de usuários no Scrum, estas são algumas histórias de usuários típicas para um anúncio de emprego e site de pesquisa:
- Um usuário pode postar seu currículo no site.
- Um usuário pode procurar empregos.
- Uma empresa pode publicar novas vagas de emprego.
- Um usuário pode limitar quem pode ver seu currículo.
Exemplos de Épicos
Um dos benefícios das histórias de usuários ágeis é que elas podem ser escritas em vários níveis de detalhes. Podemos escrever uma história de usuário para cobrir grandes quantidades de funcionalidade ou apenas um pequeno recurso distinto.
Grandes histórias de usuários são menos detalhadas e são geralmente conhecidas como Epics.
Aqui está um exemplo épico de história de usuário ágil de um produto de backup de desktop:
- Como usuário, posso fazer backup de todo o meu disco rígido.
Como um épico geralmente é muito grande para uma equipe ágil concluir em uma iteração, ele é dividido em várias histórias de usuários menores antes de ser trabalhado. O épico acima pode ser dividido em dezenas (ou possivelmente centenas), incluindo estes dois exemplos de histórias de usuários:
- Como usuário avançado, posso especificar arquivos ou pastas para backup com base no tamanho do arquivo, data de criação e data de modificação.
- Como usuário, posso indicar pastas para não fazer backup, para que minha unidade de backup não fique cheia de coisas que não preciso salvar.
Como os detalhes são adicionados às histórias do usuário?
Os detalhes podem ser adicionados às histórias do usuário de duas maneiras: Ao dividir uma história de usuário em várias histórias de usuário menores. Adicionando condições de satisfação (critérios de aceitação).
- Ao dividir uma história de usuário em várias histórias de usuário menores.
- Adicionando condições de satisfação (critérios de aceitação).
Quando uma história relativamente grande é dividida em várias histórias de usuários ágeis menores, é natural presumir que os detalhes foram adicionados. Afinal, mais foi escrito.
As condições de satisfação são simplesmente um teste de aceitação de alto nível que será verdadeiro após a conclusão da história do usuário ágil. Considere o seguinte como outro exemplo de história de usuário ágil:
Como vice-presidente de marketing, quero selecionar uma temporada de férias para ser usada ao revisar o desempenho de campanhas publicitárias anteriores para que eu possa identificar as lucrativas.
Detalhes podem ser adicionados a esse exemplo de história de usuário adicionando as seguintes condições de satisfação:
- Certifique-se de que funciona com os principais feriados de varejo: Natal, Páscoa, Dia do Presidente, Dia das Mães, Dia dos Pais, Dia do Trabalho, Dia de Ano Novo.
- Feriados de apoio que abrangem dois anos civis (nenhum abrange três).
- As temporadas de feriados podem ser definidas de um feriado para o outro (como o Dia de Ação de Graças ao Natal).
- As temporadas de feriados podem ser definidas para vários dias antes do feriado.
As histórias de usuários substituem um documento de requisitos?
Os projetos ágeis, principalmente os Scrum, utilizam um product backlog, que é uma lista priorizada das funcionalidades a serem desenvolvidas em um produto ou serviço. Embora os itens do backlog do produto possam ser o que a equipe desejar, as histórias de usuários surgiram como a melhor e mais popular forma de itens do backlog do produto.
Embora um product backlog possa ser pensado como um substituto para o documento de requisitos de um projeto tradicional, é importante lembrar que a parte escrita de uma história de usuário ágil (“Como usuário, eu quero…”) está incompleta até que as discussões sobre essa história ocorrer.
Muitas vezes, é melhor pensar na parte escrita como um indicador do requisito real. As histórias do usuário podem apontar para um diagrama representando um fluxo de trabalho, uma planilha mostrando como realizar um cálculo ou qualquer outro artefato que o proprietário do produto ou a equipe desejar.
