1 Usuários Vêm em Primeiro lugar

Como o próprio nome sugere, uma história de usuário descreve como um cliente ou usuário utiliza o produto; ele é contada a partir da perspectiva do usuário. Além disso, as histórias de usuário são particularmente úteis para capturar uma funcionalidade específica, como, procurar um produto ou fazer uma reserva. A figura seguinte ilustra a relação entre o usuário, a história e a funcionalidade do produto (simbolizada pelo círculo).,

Se você não sabe quem são os usuários e clientes e por que eles querem usar o produto, então você não deve escrever nenhuma história de usuário. Realizar a investigação necessária do utilizador em primeiro lugar, por exemplo, observando e entrevistando os utilizadores. Caso contrário, você corre o risco de escrever histórias especulativas que são baseadas em crenças e ideias—mas não em dados e evidências empíricas.

2 Use Personas para descobrir as histórias certas

uma grande técnica para capturar suas ideias sobre os usuários e clientes está trabalhando com personas., Personas são personagens fictícios que são baseados no conhecimento em primeira mão do grupo-alvo. Eles geralmente consistem de um nome e uma imagem; características relevantes, comportamentos e atitudes; e um objetivo. O objetivo é o benefício que a persona quer alcançar, ou o problema que o personagem quer ver resolvido usando o produto.

mas há mais: os objetivos da persona ajudam você a descobrir as histórias certas: pergunte a si mesmo que funcionalidade o produto deve fornecer para cumprir os objetivos das personas, como eu explico no meu post de Personas para histórias do Usuário., Você pode baixar um modelo prático para descrever suas personagens de romanpichler.com/tools/persona-template.

3 Criar Histórias de forma colaborativa

as histórias de usuários são destinadas como uma técnica leve que permite que você se mova rápido. Não são uma especificação, mas uma ferramenta de colaboração. As histórias nunca devem ser entregues a uma equipa de desenvolvimento. Em vez disso, eles devem ser incorporados em uma conversa: o proprietário do produto e a equipe devem discutir as histórias juntos. Isso permite que você capture apenas a quantidade mínima de informação, reduzir despesas gerais e acelerar a entrega.,

Você pode levar esta abordagem mais longe e escrever histórias de forma colaborativa como parte do processo de preparação de backlog do seu produto. Isso alavanca a criatividade e o conhecimento da equipe e resulta em melhores histórias de usuários.

Se você não pode envolver a equipe de desenvolvimento no trabalho de história do usuário, então você deve considerar usar outra técnica mais formal para capturar a funcionalidade do produto, tais como, casos de uso.

4 Mantenha as suas histórias simples e concisas

escreva as suas histórias para que sejam fáceis de entender. Mantenha-os simples e concisos., Evite termos confusos e ambíguos, e use voz ativa. Concentra-te no que é importante e deixa de fora o resto. O modelo abaixo coloca o usuário ou cliente modelado como uma persona na história e torna seu benefício explícito. É baseado no modelo popular de Rachel Davies, mas eu substituí o papel do usuário pelo nome persona para conectar a história com a persona relevante.

<persona>
quero <o que?>
so that <why?>.,

Use o modelo quando é útil, mas não se sinta obrigado a aplicá-lo sempre. Experimente diferentes maneiras de escrever suas histórias para entender o que funciona melhor para você e sua equipe.

5 Início com épicos

um épico é uma história grande, superficial, grosseira. É tipicamente dividido em várias histórias de usuários ao longo do tempo—alavancando o feedback do usuário sobre os primeiros protótipos e incrementos de produto. Você pode pensar nisso como uma manchete e um substituto para histórias mais detalhadas.

começando com os Epic permite esboçar a funcionalidade do produto sem se comprometer com os detalhes., Isso é particularmente útil para descrever novos produtos e recursos: ele permite que você capture o escopo áspero, e lhe dá tempo para aprender mais sobre como melhor atender as necessidades dos usuários.também reduz o tempo e o esforço necessários para integrar novos insights. Se você tem muitas histórias detalhadas no Backlog do produto, então é muitas vezes complicado e demorado para relacionar feedback com os itens apropriados e acarreta o risco de introduzir inconsistências.,

6 Refine as histórias até que elas estejam prontas

quebre seus épicos em histórias menores e detalhadas até que elas estejam prontas: claras, viáveis e testáveis. Todos os membros da equipe de desenvolvimento devem ter uma compreensão compartilhada do significado da história; a história não deve ser muito grande e confortável em um sprint; e tem que haver uma maneira eficaz de determinar se a história é feita.

7 Adicione critérios de aceitação

à medida que divide os épicos em histórias mais pequenas, lembre-se de adicionar critérios de aceitação., Os critérios de aceitação complementam a narrativa: eles permitem descrever as condições que têm de ser cumpridas para que a história seja feita. Os critérios enriquecem a história, tornam-na testável, e garantem que a história pode ser desmoada ou divulgada aos usuários e outras partes interessadas. Como regra geral, eu gosto de usar três a cinco critérios de aceitação para histórias detalhadas.

8 usar cartões de papel

histórias de usuário emergiram em programação extrema (XP), e a literatura XP inicial fala sobre cartões de história ao invés de histórias de usuários., Há uma razão simples: histórias de Usuários foram capturados em cartões de papel. Esta abordagem proporciona três benefícios: em primeiro lugar, os cartões de papel são baratos e fáceis de usar. Em segundo lugar, eles facilitam a colaboração: cada um pode pegar um cartão e anotar uma idéia. Em terceiro lugar, os cartões podem ser facilmente agrupados na tabela ou parede para verificar a consistência e completude e visualizar dependências. Mesmo que suas histórias sejam armazenadas eletronicamente, vale a pena usar cartões de papel quando você escreve novas histórias.

9 mantenha as suas histórias visíveis e acessíveis

As histórias querem comunicar informações., Portanto, não os esconda em uma unidade de rede, a selva de intranet corporativa, ou uma ferramenta licenciada. Torná-los visíveis, por exemplo, colocando-os na parede. Isso fomenta a colaboração, cria transparência, e torna óbvio quando você adiciona muitas histórias muito rapidamente, como você vai começar a ficar sem espaço nas paredes. Uma ferramenta útil para descobrir, visualizar e gerenciar suas histórias é a minha tela de produto mostrada abaixo.

10 não confie apenas em histórias de usuário

criar uma grande experiência de usuário (UX) requer mais do que histórias de usuário., As histórias do usuário são úteis para capturar a funcionalidade do produto, mas não são adequadas para descrever as viagens do Usuário e o design visual. Portanto, complementam histórias de usuários com outras técnicas, tais como, mapas de histórias, diagramas de fluxo de trabalho, storyboards, esboços e mockups.além disso, as histórias dos utilizadores não são boas para captar os requisitos técnicos. Se você precisa se comunicar o que um elemento arquitetônico como um componente ou serviço deve fazer, em seguida, escrever histórias técnicas ou—que é a minha preferência—usar uma linguagem de modelagem como UML.,

finalmente, escrever histórias de usuário vale a pena quando você desenvolve software que provavelmente será reutilizado. Mas se você quiser rapidamente criar um protótipo descartável ou maquete para validar uma ideia, então escrever histórias pode não ser necessário. Lembre – se: histórias de usuários não são sobre documentar requisitos; eles querem permitir que você se mova rápido e desenvolver software o mais rápido possível—não para impor qualquer sobrecarga.