Princípio INVEST para criar histórias de usuários
Além de um formato padronizado e elementos completos, uma boa história de usuário também deve seguir os princípios INVEST : 1. Eu dependente; 2. Negociável ; 3. Valioso ; 4. Estimativa ; 5. Shopping S ; 6. Testável .
1. Independente – É importante tornar uma história de usuário o mais independente possível das outras histórias de usuário. Manter a independência entre as histórias de usuário não apenas facilita a priorização e o alinhamento, facilita o planejamento de lançamento e iteração, facilita a compreensão independente, o rastreamento, a implementação, o teste e a entrega frequente, mas também torna o escopo da estimativa do tamanho da história do usuário mais claro e, portanto, o viés de estimativa menor.
2. Negociável – O conteúdo de uma história de usuário é negociável; uma história de usuário não é um contrato. Uma história do usuário é apenas uma breve descrição da história do usuário sem muitos detalhes; detalhes específicos são produzidos durante a fase de comunicação. Uma história de usuário com muitos detalhes na verdade limita o usuário, as ideias da equipe e a comunicação.
3. Valioso – Cada história deve ser valiosa para o cliente (seja um usuário, um comprador ou uma função interna da empresa). As histórias de usuário são valiosas para o usuário final, portanto, devem ser escritas da perspectiva do usuário, descrevendo um RECURSO em vez de uma TAREFA.
Esse recurso facilita a mudança do estilo de trabalho tradicional baseado em diretivas para um estilo de trabalho autodirigido e orientado a valores para os membros de desenvolvimento e teste da equipe, para que todos na equipe saibam o valor do trabalho que realizam todos os dias.
4. Estimável (pode ser avaliado) – Uma parte muito importante dentro da reunião de planejamento é a estimativa dos pontos da história. Na verdade, é uma estimativa grosseira da história de usuário a ser desenvolvida para que a equipe possa conhecer a complexidade (carga de trabalho) dessa história de usuário.
O foco está em saber se a história do usuário pode ser concluída na iteração atual de acordo com as condições de recepção dessa história do usuário e o DoD (critérios de conclusão) definido pela equipe, e se não puder ser concluída, o motivo é informado e o PO decide se divide ou redesenha a história do usuário.
Os problemas que dificultam para os desenvolvedores estimar a história vêm de: falta de conhecimento do domínio (nesse caso, mais comunicação é necessária) ou a história é muito grande (nesse caso, ela precisa ser cortada em pedaços menores).
5. Pequena – Uma boa história deve ser a mais curta possível em termos de carga de trabalho, de preferência não mais que 10 pessoas/dia ideais, pelo menos para garantir que seja concluída em uma iteração. Quanto maior a história do usuário, maior o risco no agendamento, estimativa de carga de trabalho, etc.
6. Testável (testável) – Uma história de usuário deve ser testável para confirmar que pode ser concluída. Se uma história de usuário não for testável, você não poderá saber quando ela será concluída. Um exemplo de história de usuário não testável: o software deve ser fácil de usar.
Três Diretrizes
Uma história de usuário é basicamente uma boa história de usuário quando os princípios INVEST são seguidos. Em seguida, nos concentramos em três diretrizes para ajudar a cumprir melhor os princípios ao produzir histórias de usuários.
As três diretrizes são: um usuário, valor completo e nenhuma dependência.
1. Um tipo de usuário – Inclua apenas um tipo de usuário, pois vários usuários geralmente têm nuances. Geralmente é um usuário típico, muitas vezes com uma necessidade comum de algum tipo.
2. Valor Completo – Entregue um valor ao cliente em sua totalidade. Uma história de usuário completa significa que, quando essa história estiver completa, o usuário poderá atingir uma meta clara e significativa.
3. Não dependência – Os três tipos comuns de dependência são: sobreposição, sequência e contenção.
Em geral, pontos funcionais sobrepostos entre as histórias devem ser evitados; relações sequenciais são uma realidade e podem ser resolvidas por alguns meios na maioria dos casos; e relacionamentos de inclusão são úteis para sistemas complexos, com implicações para agendamento de releases e planos de iteração que precisam de atenção.
Dependências sobrepostas
As dependências sobrepostas são a forma de dependência que causa mais problemas, especialmente quando várias histórias de usuário contêm várias partes sobrepostas diferentes. É difícil encontrar um conjunto de histórias de usuários que possa representar o conjunto de recursos para aquele produto mínimo viável, que deve conter e conter apenas os recursos necessários uma vez.
Solução
Remova as partes sobrepostas como histórias de usuário separadas.
Divisão racional de histórias de usuário e manutenção das sobreposições em apenas uma das histórias de usuário mais coesas.
Use o modelo de desenvolvimento Scrum.
Dependências Sequenciais
A dependência sequencial significa que, para que uma história de usuário seja concluída, uma ou mais outras histórias de usuário devem ser concluídas antes dela. As dependências sequenciais geralmente são inofensivas e existem maneiras de mitigar essas dependências.
De uma perspectiva de desenvolvimento ágil, todo o sistema evolui gradualmente de um produto inicial mínimo viável para um produto robusto, com cada etapa posterior se baseando nas anteriores.
Mas de outra perspectiva, dependências sequenciais desnecessárias tornam mais difícil classificar e priorizar, o que, por sua vez, afeta o desenvolvimento de planos de lançamento e iteração e torna mais difícil estimar o tamanho das histórias de usuários.
Solução
Torne as histórias de usuário em uma iteração o mais livre possível de dependências intrínsecas.
Mantendo apenas dependências unidirecionais entre iterações, com apenas dependências unidirecionais no tempo de histórias em iterações posteriores para histórias em iterações anteriores (dependências diretas).
Eliminar as dependências principais como histórias separadas e não misturar requisitos dependentes e não dependentes em uma história.
Inclusão de dependências
Dependências contidas referem-se ao uso de gerenciamento hierárquico na organização de histórias de usuários, como o gerenciamento comum de histórias de recursos de dois níveis, em que um recurso contém várias histórias de usuários, constituindo assim uma dependência contida do recurso em suas histórias subordinadas.
Solução
O nível de história do usuário é usado para planejamento de iteração, evitando planejamento de iteração grosseiro com o nível de recurso, que pode ser usado para planejamento de liberação.
O nível de recurso também pode ser dividido até que esteja no nível de um recurso comercializável mínimo, e as histórias de usuário que ele contém podem ser agrupadas separadamente nos recursos recém-divididos.
Seguindo o conceito de produto mínimo viável, um recurso é implementado em várias iterações de várias histórias de usuários, cada uma das quais pode resultar em uma entrega potencial ou fornecer feedback interno ou externo.
Referências
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский