histórias de usuário são simples, mas extremamente poderosas construções: eles descrevem peças de funcionalidade do ponto de vista de um usuário, expresso de uma forma sólida e compacta. Eles refletem o que uma classe particular de usuário precisa e o valor a ser ganho. O formato é muito simples e fácil de usar. Existem várias variações, incluindo:
Por Que histórias de Usuários?
As histórias do utilizador proporcionam uma excelente forma de definir o seu produto com clareza., Um conjunto de histórias de usuário bem definidas e priorizadas pode ajudá — lo a articular a funcionalidade do seu produto usando ‘Inglês claro’ – sem detalhes técnicos e de implementação.a abordagem “história do utilizador” permite discussões significativas sobre os produtos, tanto dentro da equipa de desenvolvimento do produto como com partes interessadas externas.
histórias de usuários devidamente escritas fornecem uma base sólida para a comunicação e colaboração — focando no que mais importa para o usuário., Em comparação com outros meios de capturar e documentar os requisitos do Usuário e as especificações do produto, eles têm pelo menos as seguintes vantagens:
- histórias de usuário ajudam a obter clareza entre as equipes sobre o que construir, para quem, porquê e quando. Uma vez que são fáceis de definir, entender e revisar, eles podem se tornar a maneira padrão de comunicar e resumir a funcionalidade do produto tanto por membros técnicos quanto não técnicos. Eles são extremamente úteis para discussões sobre a definição do produto ou como pontos de entrada para mergulhos técnicos profundos. São elementos-chave da engenharia ágil.,as histórias dos utilizadores encorajam a participação de membros não técnicos. Projetos de software modernos são tipicamente complexos, envolvendo uma ampla gama de tecnologias, acrônimos e opções de implementação. Em muitos casos, a terminologia ou a linguagem técnica não é geralmente entendida — mesmo dentro de uma única equipa — introduzindo assim “ruído” e riscos para o projecto. Histórias de usuário removem esta dimensão técnica, para que qualquer membro da equipe possa contribuir, simplesmente pensando “como um usuário”., A equipe pode usar linguagem não técnica e colaborar efetivamente na definição, desafio ou priorização de histórias de usuários. O impacto na colaboração e dinâmica de equipe pode ser significativo.eles ajudam a definir todo o produto-como um conjunto de histórias sólidas e sabiamente priorizadas. A equipe de desenvolvimento do produto pode pensar em grande, definir o super-conjunto de histórias de usuário, e então atribuir prioridades (que refletem o valor esperado para o usuário, complexidade, dependências e outras prioridades de negócios). Você não tem que tomar decisões difíceis e marcar itens como “fora do escopo”., Em vez disso, você pode atribuir uma prioridade menor a essas idéias ‘loucas’, ao mover acima as histórias do Usuário refletindo a funcionalidade principal de seu produto. Definir as “linhas de corte” que determinam o escopo de cada iteração, fase ou versão, é então uma questão dos recursos disponíveis e da velocidade da equipe.
escrevendo grandes histórias de Usuários
o formato é direto, e escrever histórias é fácil. Mas escrever grandes pode ser um pouco complicado. Aqui estão algumas diretrizes a considerar:
histórias de usuário ≠ tarefas
histórias de usuário não são tarefas., Na verdade, uma única história pode precisar de centenas de tarefas individuais para ser entregue com sucesso. As tarefas são sobre implementação; histórias de usuários são sobre definição.
ao compilar as suas histórias, concentre — se em fornecer clareza sobre as características do seu Produto-O quê, não o como.
manter um nível elevado
tem de ser elevado, mas também preciso e preciso. As histórias devem ser simples e sólidas. Isso ajudará os membros da equipe e os stakeholders a compreender profundamente as necessidades do Usuário, e evitará gastar tempo esclarecendo buzzwords, terminologia e acrônimos. Basta usar uma linguagem simples e precisa.,
compreenda os utilizadores
você precisa de descobrir e estudar os utilizadores reais do seu produto — capture os seus perfis, pontos de vista, expectativas e os pontos de dor associados.’A pesquisa de usuário e outras técnicas podem gerar insights para ajudá-lo a entender melhor os usuários e suas necessidades.
não importa as técnicas, você precisa do conjunto de Usuários chave — idealmente na forma de personas — antes de começar a compilar histórias de usuários.,
Pense como um usuário
<como uma classe particular de usuário/ persona /função> parte de uma história de usuário, define o ângulo, perspectiva — como o determinado usuário percebe a funcionalidade resumidos na história.isso é de importância crítica — o proprietário do produto e toda a equipe precisam pensar do ponto de vista do Usuário e entender as necessidades subjacentes e o valor esperado.,
Pense grande
ao descrever um produto como um backlog de histórias de usuário, não há nenhuma boa razão para restringir o seu pensamento pelo orçamento, tempo, Viabilidade ou custo.
uma boa prática é pensar em grande e deixar as histórias do Usuário’ louco ‘ entrar no backlog. A sobrecarga administrativa da manutenção de um atraso prolongado no produto é pequena; o valor que dele deriva — em termos de clareza do produto, Visão e oportunidades — é enorme.,
usar os épicos
os épicos podem assumir a forma de histórias de alto nível, que descrevem grandes peças de funcionalidade-eles tipicamente requerem uma quantidade significativa de trabalho, através de múltiplas imagens. Outra maneira de pensar em épicos é como agrupamentos / contêineres de histórias relacionadas, menores, todos servindo a um objetivo comum. Os épicos são bons para organizar suas histórias e fornecer o quadro geral.,
não descartar-priorizar em vez de
dado um processo de priorização eficaz, é boa prática continuar enriquecendo o seu produto com novas histórias de usuário, descrevendo novos cenários de interação do Usuário,’ ideias aleatórias’, ou a saída de atividades de inovação do produto.
para gerenciar o ruído potencial, você precisa agrupar corretamente e priorizar as novas entradas. Em qualquer caso, não filtre/elimine itens do seu backlog: itens des-escopados são geralmente esquecidos, enquanto itens des-priorizados permanecem descobríveis e podem se tornar relevantes sob as condições certas.,
dependendo do contexto, priorizar histórias de usuários pode ser um processo complicado. Você precisa estimar o valor de cada história, para o Usuário e para o negócio. Você precisa dimensionar a complexidade, estimar a viabilidade e o custo/esforço necessários para construir e liberar o recurso. Você precisa identificar dependências cruzadas em sua ordenação específica de execução de backlog entre certas entradas.
configuração para o sucesso — não apenas aceitação
equipes muitas vezes definem testes de aceitação do Usuário e critérios de aceitação relacionados. A aceitação, porém, não é suficiente — você precisa se estabelecer para o sucesso., Como gerente de produtos, você precisa mais do que uma confirmação de que “ele funciona como deveria” ou ” de acordo com as especificações.’
Você precisa de métricas que também estão ligadas ao feedback direto do Usuário, capturando o quão felizes e engajados são seus usuários reais. Embora a aceitação seja boa para controlar o ciclo de vida de desenvolvimento do recurso, o sucesso é sobre impacto a médio/longo prazo e valor criado para os usuários reais do seu produto. Você precisa definir ambos-no nível de produto e/ou epic e / ou história.
histórias de etiquetas, adicionar metadados
produtos complexos requerem centenas de histórias de utilizadores., Para facilitar a navegação e Administração, você precisa efetivamente nomear, categorizar e marcar suas histórias. Após as primeiras revisões de uma história, você deve evitar renomear ou alterar drasticamente a sua descrição, pois isso pode introduzir confusão e lacunas na equipe.
gerenciando corretamente os metadados de suas histórias-status, progresso, links, prioridades, recursos, etc. – ajuda a explorar, monitorar e entender seu backlog.
não fique preso a notas pegajosas!,
sim, uma parede cheia de notas pegajosas coloridas parece chique e ajuda sua equipe a parecer ocupada e produtiva:) mas você precisa de um sistema sério e ferramentas especiais para ajudá-lo a gerenciar, enriquecer, priorizar e compartilhar histórias.,
Em casos especiais, tais como o brainstorming ou ideação sessão, é tudo para capturar o primeiro conjunto de histórias de usuário usando notas auto-adesivas—desde que você, em seguida, documento todo em um produto adequado sistema de gestão. Se você não o fizer, e você apenas manter suas histórias em notas pegajosas, as chances são de que você vai perder oportunidades em termos de clareza, inovação, eficiência e colaboração.,
você ainda precisa de specs
ter um conjunto priorizado de histórias de usuário bem definidas é ótimo, mas é apenas o começo. A equipe precisa analisar as histórias — de um ponto de vista técnico — e criar os artefatos técnicos necessários.idealmente, as histórias são mapeadas para documentação específica que fornece todos os detalhes técnicos necessários a partir de uma perspectiva de engenharia de software. Eles fornecem os pontos de entrada para documentos detalhados de especificações técnicas e outros artefatos detalhados.,
a visualização ajuda
uma visualização sempre on (digital) das histórias de usuário de primeira prioridade por categoria, tema ou epic pode ser extremamente útil para a colaboração e alinhamento entre equipes e stakeholders. Junto com estatísticas, questões, bloqueadores e indicadores de progresso, um mapa de história pode ser servido através de telas interativas no espaço de colaboração.
As histórias de usuários fornecem uma ótima maneira de descrever rápida e precisamente a funcionalidade de um produto de software ou sistema., Eles também são muito eficazes na captura das saídas de sessões de brainstorming, sprints de design, hackathons e outros processos liderados pela inovação-onde um fluxo de ideias deve ser capturado de uma forma compacta e estruturada.