Tendo examinado e analisado mais de 10.000 histórias de usuários de diferentes fontes, construímos alguns insights sobre o que representa uma boa história de usuário. Se você gostaria de aprenda a escrever melhores histórias de usuários, você deve achar este artigo útil.
O que é uma história de usuário?
Antes de começarmos as 10 etapas, vamos revisitar a questão do que é uma história de usuário. Uma história de usuário normalmente é descrita como um espaço reservado para uma conversa sobre a necessidade do usuário. Normalmente nos referimos aos três C's: Cartão, Conversação e Colaboração. Em muitas organizações, entretanto, as histórias de usuários SÃO a lista de requisitos.
Puristas e coaches ágeis normalmente dirão que a história do usuário não deve ser considerada um substituto para requisitos escritos, pois isso prejudica a promoção da colaboração entre os membros da equipe. No entanto, na maioria dos casos na maioria das organizações, a lista de histórias de usuários é a lista de requisitos.
E agora, vamos abordar 10 etapas para escrever melhores histórias de usuários:
1. Concentre-se nas necessidades funcionais
A funcionalidade deve ser escrita da seguinte forma, sempre que possível: Como __ eu preciso __ . Em cada história, inclua todas as funcionalidades que a tornam completa. Incluir movimentações de dados entre sistemas (desde que seu escopo seja adicionar, editar ou excluir tal funcionalidade). Uma história de usuário que começa com “Quando” em vez de “Como” é adequada, desde que descreva um evento funcional incluindo um usuário, um objeto e uma ação. por exemplo, “quando o sensor de temperatura detecta 100 graus, ele envia um sinal para desativar a fonte de calor”
Exclua tarefas de equipe e qualquer trabalho de configuração que não esteja diretamente relacionado ao fornecimento de funcionalidades novas, alteradas ou excluídas.
2. Claro e inequívoco
Se uma história de usuário não estiver clara, isso levará a bugs. Isso é absolutamente crucial para resolver e resolver antecipadamente. Deve ser inequívoco para o público-alvo (pelo menos: usuários, desenvolvedor, testador, analista, designer). O teste fácil para a ambiguidade é garantir que quaisquer dois leitores do mesmo texto cheguem ao mesmo entendimento sobre qual funcionalidade precisa ser fornecida – em caso de dúvida, pergunte-lhes.
Use verbos relacionados a dados, como atualizar, enviar ou salvar. Evite verbos como: considerar, fornecer, querer, decidir, apoiar e avaliar . É provável que estes induzam ao erro do leitor.
3. Valioso e rastreável até os resultados do negócio
Este é, em muitos aspectos, o atributo mais importante de uma história de usuário. Se a história não for útil para o negócio, ela deverá ser excluída. Idealmente, o valor da história pode estar diretamente ligado a Capacidades e Resultados que são mensuráveis. ou seja, há uma rastreabilidade clara entre a funcionalidade da história do usuário e a capacidade necessária para alcançar o negócio mensurável resultado.
4. Da perspectiva do usuário
Concentre-se na experiência do usuário específico do aplicativo. Tente também ser específico sobre o tipo e contexto do usuário. Por exemplo, em vez de “como usuário”, tente contextualizar seus nomes de usuário, por exemplo: cliente_logado, agente_de_marketing_logado. logado_adminstrator. Isso é informativo sobre o contexto sem ser prolixo.
5. Conciso
Histórias de usuários excessivamente detalhadas que incluem muitos detalhes de necessidades funcionais, declarações de design e critérios de teste levarão à confusão. Guarde suas histórias curto, simples e preciso. É melhor ser breve e claro do que superespecificado.
Tente manter suas histórias de usuários pequenas e simples, mas suficientemente abrangentes para evitar a proliferação de histórias. Duas dicas específicas são referir-se a objetos e não a tipos de objetos (muito grandes) ou atributos de objetos (muito detalhados). Por exemplo "como login_customer posso atualizar meu perfil” é melhor que "como login_customer posso atualizar quaisquer dados” ou “como login_customer posso atualizar meu número de telefone”
6. Consistente
Seja consistente com o seu nomes de usuário e nomes de objetos.
Com os dados mantidos no sistema, sejam consistentes com os nomes que você usa, tente referir-se apenas a objetos e tipos de objetos, tanto quanto possível, evite atributos de objetos nas histórias. por exemplo perfil de usuário (que inclui um atributo para data de nascimento) é melhor que data de nascimento.
7. Completo em si mesmo
Se uma história de usuário exigir várias etapas funcionais, inclua todas elas. por exemplo
Antes: Como usuário, quero atualizar os detalhes da loja.
Depois: Como logado_in_administrador, preciso verificar minha permissão [para atualizar o store_record]. Posso então atualizar o store_record
As duas instruções funcionais indicam que as permissões precisam ser verificadas antes que uma atualização possa ser executada.
8. CRUD completo e não duplicado em um conjunto
Se estivermos atualizando guardar informação no exemplo acima, existe também uma história de usuário semelhante que nos permite criar uma loja? Outra história para excluir uma loja? E outra história para expor uma loja? Histórias perdidas são a causa do aumento do escopo, o que muitas vezes faz com que os projetos ultrapassem o cronograma original.
Da mesma forma, tome cuidado com histórias de usuários duplicadas. Requisitos duplicados são menos comuns, mas ocorrem, portanto, verifique se você não duplicou a funcionalidade.
9. Testável
Se um leitor não conseguir entender prontamente como testar a história do usuário, ela não será testável. Estamos nos referindo aqui aos testes do ponto de vista funcional. Quaisquer restrições devem ser incluídas e quaisquer restrições escalares devem ser quantificadas.
10. Não contém design
As histórias de usuários não devem conter declarações de design.
Conclusão
Estas são 10 das minhas dicas favoritas para escrever melhores histórias de usuários. Garanto que se você seguir essas dicas você escreverá histórias de usuários melhores, e isso levará à escrita melhor software.
E se minhas histórias de usuário não forem boas? Isso importa, desde que eu tenha a essência da história? Sim. Apenas uma ambigüidade levará à perda de tempo e esforço na interpretação, má interpretação e algum grau de retrabalho. Uma omissão pode exigir uma grande revisão do projeto (ou introduzir dívida técnica se for tarde demais para alterar o projeto). Então, sim, é necessário muito cuidado ao escrever histórias de usuários ou requisitos. Bons requisitos podem levar a uma entrega dentro do prazo. Requisitos inadequados certamente custarão mais e levarão mais tempo.
Preciso de mais
Confira este excelente exemplo trabalhado de melhorando uma história de usuário.
