Um dos maiores desafios na gestão do Backlog do Produto Ágil é como dividir uma História de Usuário. Enquanto uma das práticas importantes no Ágil é tornar uma História de Usuário pequena o suficiente para ser concluída dentro de um Sprint, muitas vezes ocorre que uma História de Usuário se torna maior que um Sprint, e você precisa dividi-la em tamanho de Sprint.
Humanizing Work, uma empresa de consultoria Ágil nos EUA, define nove padrões comuns para dividir uma História de Usuário. Esse padrão é amplamente reconhecido como a melhor prática e padrão para dividir efetivamente uma História de Usuário.
Divisão Vertical e Horizontal
Antes de discutir os nove padrões, preciso explicar a maneira básica Ágil de dividir, que é conhecida como divisão vertical. Esta abordagem envolve dividir uma História de Usuário em todas as camadas arquitetônicas, incluindo front-end, back-end e banco de dados e pode ser entregue de forma independente. Por outro lado, a divisão horizontal baseia-se em camadas arquitetônicas, como desenvolvimento de front-end ou back-end. A divisão vertical é mais orientada para o cliente e gerenciável do que a divisão horizontal.
Sigla INVEST
O framework INVEST é um conjunto de diretrizes que pode ajudar a garantir que as histórias de usuário sejam de alta qualidade. A sigla significa Independente, Negociável, Valioso, Estimável, Pequeno e Testável. Ao aderir a esses critérios, você pode minimizar o número de bugs, evitar requisitos desnecessários e fazer estimativas mais precisas.
Independente: Uma história de usuário deve ser independente para torná-la mais gerenciável e fácil de desenvolver. Dependências podem causar complexidade na programação, bem como na gestão.
Negociável: Uma história de usuário deve estar aberta à negociação, permitindo discussões e refinamento dos requisitos pela equipe de desenvolvimento. Se a estimativa ou escopo não for realista o suficiente, os desenvolvedores devem levantar alertas e consultar o proprietário do produto sobre como lidar com isso. Isso garantirá que os requisitos sejam claros e alcançáveis dentro do prazo dado.
Valioso: Uma história de usuário deve fornecer valor para os usuários, não apenas para o proprietário do produto, scrum master ou desenvolvedores. É importante discutir o valor da história de usuário dentro e fora da equipe de scrum e validá-lo por meio de feedback.
Estimável: Uma história de usuário deve ser facilmente estimável para permitir que a equipe do projeto planeje o sprint de forma eficaz.
Pequeno: Uma história de usuário precisa ser pequena o suficiente para ser concluída dentro de um único sprint. Isso porque a complexidade da programação aumenta exponencialmente, não linearmente, conforme a história de usuário fica maior. Se uma história de usuário for muito grande, pode causar bugs e levar a estimativas imprecisas. Portanto, é aconselhável dividir as histórias de usuário maiores em menores.
Testável: Uma história de usuário deve ser testável, o que é alcançado por meio de critérios de aceitação que servem tanto como requisitos quanto como casos de teste.
Critérios de Aceitação e Divisão
Os Critérios de Aceitação são requisitos detalhados que auxiliam uma História de Usuário e são usados para testes de aceitação. Escrever Critérios de Aceitação de forma clara é fundamental para dividir uma História de Usuário porque eles esclarecem quais funções (cenários) podem ser separadas como a imagem abaixo.
O Proprietário do Produto Profissional: Imagem da Divisão de uma História de Usuário
Por exemplo, quando você desenvolve uma página de login simples, os Critérios de Aceitação são como abaixo.
Cenário1: Login bem-sucedido
Dado: Um usuário já tem uma conta na plataforma.
Quando: Um usuário insere o email e a senha, então pressiona o botão “login”.
Então, Um usuário pode fazer login na plataforma.
Cenário2: Login bem-sucedido com desempenho
Dado: Um usuário já tem uma conta na plataforma.
Quando: Um usuário insere o email e a senha, então pressiona o botão “login”
.
Então, Um usuário pode fazer login na plataforma dentro de 1 segundo.
Com o exemplo acima, você pode dividir o cenário 2 em outra História de Usuário. Em muitos casos, o desempenho pode não ser necessário, e fornecer a função básica pode ser mais importante. Esse tipo de divisão é chamado de “adiar desempenho”, que é explicado mais tarde.
- Etapas do Fluxo de Trabalho
O primeiro padrão é as etapas do fluxo de trabalho. Vamos dizer que você está desenvolvendo um CMS (Sistema de Gerenciamento de Conteúdo), e agora precisa desenvolver um recurso de publicação. Parece simples. No entanto, você descobre que o artigo deve passar por revisões editoriais e legais. Nesse padrão, o início e o fim são geralmente as implementações mais importantes, e as etapas intermediárias podem ser adicionadas mais tarde.
Como gerente de conteúdo, eu posso publicar uma notícia no site corporativo. …
Eu posso publicar uma notícia diretamente no site corporativo. …
Eu posso publicar uma notícia com revisão do editor. …
Eu posso publicar uma notícia com revisão legal.
- Variações da Regra de Negócio
O segundo padrão são variações da regra de negócio. Por exemplo, uma função de pesquisa (regras de negócio) pode realizar vários tipos de pesquisas, como o abaixo.
Como usuário, eu posso pesquisar por voos com datas flexíveis. …
…como “n dias entre x e y.”
…como “um final de semana em dezembro.”
…como “± n dias de x e y.”
- Esforço Maior
O terceiro padrão é o esforço maior, que divide com base no esforço necessário. O exemplo abaixo descreve pagamentos com cartão de crédito. Você divide a História de Usuário com base no tipo de cartão de crédito. Outro exemplo comum é o SSO (Single-Sign-On) com plataformas de mídia social como Facebook, Twitter, Github, Google e Microsoft. Você pode dividir a História de Usuário com base na plataforma de terceiros.
Como usuário, eu posso pagar pelo meu voo com VISA, MasterCard, Diners Club ou American Express. …
Eu posso pagar com um tipo de cartão de crédito (de VISA, MC, DC, AMEX). …
Eu posso pagar com os quatro tipos de cartão de crédito (VISA, MC, DC, AMEX).
- Simples/Complexo
Durante uma reunião de planejamento da história, se a história começar a se tornar mais complicada com ideias adicionais sendo adicionadas, é sempre uma boa ideia pausar e perguntar à equipe, “Qual é a versão mais básica desta história?” Esta versão simples deve então ser capturada como uma história separada com critérios de aceitação definidos. A equipe pode então quebrar as outras complexidades e variações em histórias separadas.
Como usuário, eu posso pesquisar por voos entre dois destinos.
…especificando um número máximo de paradas.
…incluindo aeroportos próximos.
…usando datas flexíveis. …etc.
- Variações nos Dados
Variações nos dados dividem com base nos dados. Os dados podem ser idioma, área, país, cidade, tipo de pessoas, etc. Os exemplos abaixo mostram idioma em CRM (Sistema de Gerenciamento de Conteúdo) e áreas no sistema de reserva de hotéis.
Como gerente de conteúdo, eu posso criar notícias.
…em inglês.
…em japonês.
…em árabe.
…etc.
Como usuário, eu posso pesquisar hotéis.
…na América do Norte.
…na Ásia Oriental.
…na Europa.
- Métodos de Entrada de Dados
Em certos casos, a complexidade está na interface do usuário, em vez da funcionalidade. Para lidar com isso, é recomendado dividir a tarefa em partes gerenciáveis e construir uma UI simples primeiro antes de passar para uma mais sofisticada. Embora os dois sejam interdependentes, essa abordagem pode se mostrar útil na simplificação do processo geral.
Como usuário, eu posso pesquisar por voos entre dois destinos.
…usando entrada de data simples.
…com uma UI de calendário sofisticada.
- Ad
iar Desempenho
A História de Usuário pode ser dividida com base no desempenho. Embora o desempenho seja um fator crítico na melhoria da usabilidade, muitas vezes pode ser adiado quando a função básica precisa ser entregue mais cedo. Nesse caso, lidar com o desempenho é separado da História de Usuário original.
Como usuário, eu posso pesquisar por voos entre dois destinos.
…(lento — apenas faça, mostre uma animação de “pesquisando”).
…(em menos de 5 segundos).
- Operações (por exemplo, CRUD)
A operação, como CRUD (Criar, Ler, Atualizar, Deletar), é outro padrão de divisão. CRUD ocorre frequentemente em todo o sistema, então uma História de Usuário pode ser dividida com base nisso.
Como usuário, eu posso gerenciar minha conta. …
Eu posso me inscrever para uma conta…
Eu posso editar as configurações da minha conta. …
Eu posso cancelar minha conta.
- Separar um Spike
Spike é uma prática usada para investigar e esclarecer incertezas. Existem dois tipos de spikes: Spike de Negócios e Spike Técnico. Spike de Negócios é usado para investigar e coletar informações sobre requisitos de negócios, enquanto Spike Técnico é usado para pesquisar a viabilidade técnica e os riscos.
Como usuário, eu posso pagar com cartão de crédito.
Investigar o processamento de cartão de crédito.
Implementar o processamento de cartão de crédito (como uma ou mais histórias).
Leave a Comment