[ad_1]
Há muita informação por aí como escrever histórias de usuários e porque é importante. E, no entanto, muitos de nós cometemos erros que nos custam muito.
Há muitos que até preferem um método alternativo. (Aqui está mais um.) E geralmente é porque estão frustrados com histórias de usuários mal escritas.
Por mais que seja importante saber escrever boas histórias de usuários, é igualmente importante saber NÃO escrever uma.
Hoje, muitas equipes de software desejam adotar processos ágeis. Eles querem colocar o usuário no centro de seu processo de desenvolvimento de produtos enquanto constroem produtos. E isso faz todo o sentido. Afinal, você está construindo o produto para seus usuários, certo?
Muitas vezes, ao escrever histórias de usuários, pensamos que estamos escrevendo da perspectiva do usuário, mas acabamos distorcendo-a com nossos preconceitos e conhecimentos. E muitas vezes, esses erros estão interligados e só pioram com o tempo.
Neste artigo, falarei sobre alguns dos erros comuns que as equipes cometem ao escrever histórias de usuários.
Histórias de usuários muito amplas
Quando as histórias de usuários são muito amplas, informações cruciais sobre a ação esperada e a necessidade podem ser perdidas. Se houver muitos “ands“Ou”ors“Ou”isso é“nas histórias de usuários de sua equipe, é uma boa indicação de que é muito amplo e você deve reescrevê-lo.
Além disso, há uma chance muito boa de que sua história de usuário muito ampla seja realmente uma épico.
Um exemplo de uma história de usuário ampla pode ser assim:
“Como usuário, gostaria de continuar lendo o artigo mais tarde, quando estiver voltando para casa, sem precisar me inscrever e encontrar o local exato de onde parei.“
Nesse caso, você pode ver que a história do usuário está tentando realizar duas coisas – não precisa se inscrever e não precisa descobrir onde parou de ler. Em vez de tentar agrupar tudo em uma única história de usuário, considere dividi-la em várias histórias de usuário.
Veja como ele pode parecer depois de ser dividido:
“Como usuário, eu gostaria de continuar lendo o artigo mais tarde, sem precisar me inscrever“
“Como usuário, quero continuar lendo de onde parei, para não precisar encontrar o último parágrafo que terminei de ler“
Histórias de usuários muito boas
Quando as histórias de usuários são divididas em muitos detalhes, você começa a falar sobre como implementá-las. Isso remove o foco do usuário e leva a uma comunicação deficiente das expectativas dentro da equipe.
Aqui está um exemplo de uma história de usuário definida muito bem para falar sobre detalhes de implementação.
“Defina uma estrutura de banco de dados relacional e escalonável para que eu possa usá-la para implementar qualquer possível caso de uso futuro.“
Qual é o valor comercial de um ótimo banco de dados relacional se o usuário final não puder usá-lo? Além disso, essa história de usuário é escrita da perspectiva dos negócios e não da perspectiva do usuário. Quando você começa a incluir os detalhes da implementação, as histórias do usuário não são mais gravadas da perspectiva do usuário.
Histórias de usuários que não são negociáveis
As histórias de usuário não devem ser descrições específicas e precisas de um recurso. E, portanto, eles não devem ser fixados em pedra.
Aqui está um exemplo de uma história de usuário não negociável: “Como usuário, quero ter um botão Limpar tudo na guia de notificações, para remover as notificações antigas.“
Você pode ver claramente que o usuário deseja remover as notificações antigas. Embora ter um botão “limpar tudo” seja uma solução, você ainda pode limpar automaticamente a notificação depois que ela for lida!
Este é um cenário clássico para ajudar você a identificar se suas histórias de usuário são muito rígidas:
Às vezes, uma história de usuário pode ter sido escrita de uma maneira específica e sua equipe acha difícil de implementar porque há uma alternativa mais fácil.
Em casos como esses, a equipe deve estar comprometida com a abordagem, desde que não prejudique o valor que um usuário obtém.
Histórias de usuários que são reiteradas nos critérios de aceitação
Muitas vezes, percebo os critérios de aceitação que repetem a história do usuário, apenas em palavras diferentes.
Veja como fica:
História do usuário: “Como usuário, quero adicionar formulários pop-up ao meu blog, para que eu possa capturar o ID de email do visitante antes que ele saia do site“
Critérios de aceitação: “Dado que um leitor visita um blog, quando tenta sair, o formulário pop-up deve solicitar que se inscreva no blog“
Os critérios de aceitação devem comunicar as condições que precisam ser atendidas para que a história seja marcada como concluída. Isso garante que você obtenha feedback, ajude a equipe a planejar e acompanhar o trabalho deles. Torna a história do usuário mais rica, mais precisa e mais facilmente testável. E, mais importante, alinha sua equipe com o que eles devem entregar.
Aqui está um exemplo melhor:
Para a história do usuário: “Como usuário, desejo receber notificações quando outras pessoas adicionarem comentários para que eu esteja atualizado.“
Critérios de aceitação: “Como eu tenho o aplicativo aberto quando estou escrevendo no documento, o ícone da campainha deve ser atualizado para mostrar notificações não lidas com contagem“
Histórias de usuários que têm um usuário indefinido
Pode parecer bobagem mencionar a persona do usuário em todas as histórias de usuários repetidamente. No entanto, pode adicionar uma quantidade enorme de valor em termos de resultado.
Isso é particularmente importante se o seu produto tiver mais de uma persona de usuário. Obviamente, haverá recursos que serão criados especificamente para diferentes personas. Se você deseja que sua equipe esteja mais alinhada com o resultado esperado, eles precisam saber quem são os usuários finais e quais benefícios eles obterão com o recurso.
Se você está procurando um exemplo disso, quase todos os exemplos que forneci acima são ótimos exemplos de como não fazer. Não se preocupe, foi intencional para que eu possa falar sobre isso. 🙂
Sempre que você escreve uma história de usuário que começa com “Como usuário …“ou”Como visitante …“ou”Como leitor …“, você está deixando espaço para ambiguidade. A definição clara de quem é essa pessoa ajudará muito a dar à sua equipe o contexto necessário.
At Zepel, recomendamos escrever a persona em vez de usuário / visitante / leitor. Isso significa que sua história de usuário será assim:
“Como escritor, quero receber uma notificação quando outras pessoas adicionam comentários no aplicativo Google Docs. Portanto, não preciso atualizar a página de vez em quando“
Histórias de usuários com mau contexto
Muitas vezes, acabamos escrevendo histórias de usuários apenas por isso. Após um certo ponto, quase toda história de usuário começa a ter a mesma aparência.
Aqui está um exemplo: “Como gerente de conteúdo, quero um editor de texto para poder editar o texto.“
Tudo isso diz à sua equipe que você deseja que ela construa um editor de texto e nada mais. Se você escreve várias histórias de usuários há um tempo, é melhor fazer uma pausa e revisitá-la com uma nova perspectiva.
Às vezes, mesmo depois de um intervalo, você pode não conseguir algo mais significativo. Esse pode ser um bom indicador de que você precisa conversar mais com seus usuários e entender melhor as necessidades deles. Não há realmente nenhum sentido em tentar extraí-lo do seu cérebro.
Conclusão
Embora o uso de um modelo de história do usuário possa ser útil, nunca é tão simples como preencher um formulário de preenchimento de lacunas em sua ferramenta ágil.
Porque um erro ao escrever histórias de usuário geralmente leva a uma série de outros erros como subproduto. E mesmo que você consiga escrever histórias de usuários corretamente, é apenas o começo. Você ainda deve permitir que sua equipe analise as histórias – do ponto de vista técnico – para ajudá-las a estimar e criar as próximas etapas necessárias.
[ad_2]
Fonte
