Como escrever sua história de usuário perfeita

1. Introdução: Oi lá. Meu nome é Adam. Sou Gerente de Produto e gostaria de falar com você sobre como escrever sua história de usuário perfeita. Sim, isso mesmo. Seu estilo, sua personalidade, sua paixão e compromisso, sua equipe, suas partes interessadas, seu produto e sua história de usuário. Porque não existe um modelo universal que torne tudo perfeito e que se aplique em toda a linha. Se você acha que alcançou perfeição ao escrever suas histórias de usuários, você pode ter uma surpresa ao trocar de equipe por projetos. Com cada interação com cada novo recurso, sua abordagem mudará um pouco e tudo bem. Você é o único que precisa se ajustar para que a história certa, atinja o aspecto desejado em termos de clareza, granularidade e apelo. Então, o nível de compreensão de todos. A mesma história de usuário que você está escrevendo precisa falar o idioma da equipe de desenvolvimento tecnicamente experiente, mas também deve falar o idioma dos empresários que podem ou pode não ter formação técnica. Minha definição de uma história de usuário perfeita tem sua base na declaração a seguir. Se você pegar um estranho para modelar a rua e mostrar a história do usuário que você escreveu. Eles não deveriam ser capazes de entender isso. Deve ser bastante fácil para qualquer pessoa envolver a cabeça em torno do requisito, do contexto e da funcionalidade que nascerá como resultado da implementação dessa história de usuário em particular. Então, o que vamos falar sobre suas diretrizes, ponteiros, dicas e truques, e tudo o que você precisa saber para que você possa escrever sua história de usuário perfeita, independentemente da equipe, o projeto, ou a indústria para esse assunto. 2. Como escrever sua história perfeita: Oi lá. Meu nome é Adam. Sou Gerente de Produto e gostaria de falar com você sobre como escrever sua história de usuário perfeita. Sim, isso mesmo. Seu estilo, sua personalidade, sua paixão e compromisso, sua equipe, suas partes interessadas, seu produto e sua história de usuário. Porque não existe um modelo universal que torne tudo perfeito e que se aplique em toda a linha. Se você acha que alcançou perfeição ao escrever suas histórias de usuários, então você pode ter uma surpresa ao trocar de equipe por projetos. Com cada interação com cada novo recurso, sua abordagem mudará um pouco e tudo bem. Você é o único que precisa se ajustar para que a história certa, atinja o aspecto desejado em termos de clareza, granularidade e apelo. Então, o nível de compreensão de todos. A mesma história de usuário que você está escrevendo precisa falar o idioma da equipe de desenvolvimento tecnicamente experiente, mas também deve falar o idioma dos empresários que podem ou pode não ter formação técnica. Minha definição de uma história de usuário perfeita tem sua base na declaração a seguir. Se você pegar um estranho do modelo da rua e mostrar a história do usuário que você escreveu. Eles não devem ser capazes de entender isso. Deve ser bastante fácil para qualquer pessoa envolver a cabeça em torno do requisito, do contexto e da funcionalidade que nascerá como resultado da implementação dessa história de usuário em particular. Então, o que vamos falar sobre suas diretrizes, ponteiros, dicas e truques, e tudo o que você precisa saber para que você possa escrever sua história de usuário perfeita, independentemente do equipe, o projeto ou a indústria para esse assunto. Mas as primeiras coisas primeiro, o que é uma história de usuário? Uma história de usuário é uma representação clara de um requisito, ilustrando a perspectiva do usuário e articulando como uma determinada funcionalidade proporcionará um valor específico aos clientes. Ele é escrito como uma história usando um formato específico, mas em inglês simples. E em tal linguagem que qualquer humano pode facilmente ler e entender sem contextos anteriores ou informações adicionais. Quão granular é de fato uma história de usuário? Bem, você tem nível de projeto em grande nível, nível recurso e, em seguida, você tem histórias de usuários. Então, eles são basicamente a expressão mais granular da exigência. No entanto, por mais granular que seja, a história do usuário ainda precisa definir uma funcionalidade totalmente testável e entregável. Não importa quão pequeno. Por que usamos histórias de usuários? Nós os usamos para traduzir as necessidades dos negócios em funcionalidades focadas no usuário. Nós os usamos para criar uma compreensão comum do que queremos construir para que acabemos construindo a coisa certa e como ela será construída. Para que acabemos construindo certo? Nós os usamos para ter uma única fonte de verdade e uma maneira mais padronizada de estruturar e se comunicar com a equipe, mas também fora da equipe com nossas partes interessadas internas ou externas. E por último, mas não menos importante, nós os usamos para definir expectativas e criar hábitos. Quais são os benefícios de melhores histórias de usuários? Entrega mais rápida de maior satisfação do cliente, melhor curva de aprendizado, tomada de decisão mais rápida, menos desperdício. Então, construa a coisa certa e construa da maneira certa. Ou então surgirão perguntas e não o mocinho e o tipo ruim. Isso logo se traduzirá incerteza, falta de confiança, questionamento e empurrar para trás todas as coisas desagradáveis que prejudicarão gravemente seu relacionamento com a equipe de desenvolvimento. Sem mencionar os atrasos, as horas tardias nas noites de sexta-feira no final do sprint, a infinidade de insetos que inevitavelmente entrarão no produto que você deveria estar alimentando. E por último, mas não menos importante, mal resolvendo a necessidade e Carregue para saber a satisfação do cliente. Invista em boas histórias usuários porque as histórias de usuários precisam ser independentes para que possam ser trabalhadas sem qualquer tipo de dependência negociável, porque uma história de usuário não é um contrato para um recurso. Valioso, o que significa que deve agregar valor para os clientes, estimável a um nível razoável de aproximação, tamanho pequeno, de modo que se encaixe em uma iteração, depois testável para que as condições de sucesso podem ser testadas. Vamos falar um pouco sobre a anatomia de uma história de usuário. Você pode ter diferentes tipos de histórias de usuários. Você pode ter histórias de usuários regulares. Você pode ter histórias técnicas de usuários. Você pode ter picos, que são basicamente. Histórias de usuários de investigação e assim por diante. Agora, o que faz uma boa história de usuário? Bem, para começar, uma história de usuário tem um título. O título deve ser conciso, claro e intuitivo. Pense nas manchetes dos jornais. Isso é o que o título é para sua história de usuário. Então, é melhor fornecer um pouco de contexto sobre por que é que queremos implementar essa funcionalidade? Que valor ele traz para nossos clientes, e qual é a necessidade, são almas. O raciocínio por trás disso é que a equipe de desenvolvimento não pode trabalhar isoladamente. Eles não se sentam em uma bolha esperando alguém para alimentá-los com histórias de usuários. Sem eles entenderem o contexto completo e as implicações. Quanto melhor eles compreenderem o contexto dos requisitos, mais capaz haverá para criar uma solução técnica melhor com um feedback valioso para o negócio e assim por diante. Então, como expressamos esse contexto? Bem, como parte da anatomia de uma história de usuário, você começa com um famoso como um, eu quero. Então essa fórmula. Deixe-me dar um exemplo. Se o título da história do meu usuário for , o usuário pode realizar uma pesquisa no site, então a expressão do contexto, seria, por exemplo, como usuário do site, eu quero poder executar um pesquise no site para que eu possa encontrar o item que estou procurando. Então você tem a seção de critérios de aceitação. É aqui que você anota os requisitos reais porque o contexto não é o requisito. É uma descrição espelhada de alto nível do raciocínio por trás do requisito. Veja você anotará nesta seção, a equipe de desenvolvimento se transformará em realidade. Os desenvolvedores escreverão o código. Os testadores testarão a funcionalidade depois. E o proprietário do produto ou os analistas de negócios realizarão o teste de aceitação do usuário UAT com base nesses requisitos específicos. Então, como devem ser os critérios de aceitação? Bem, idealmente, você iria estruturá-lo em cenários. Por exemplo, cenário número um, cenário número dois e assim por diante. Cada um deles com um título e composição específicos. E é aqui que usamos a outra parte famosa do corpo de uma história de usuário, a dada quando então seqüência. O dado é o pré-requisito. Ele descreve o que você já precisa ter no lugar. No momento em que você chegar a esta etapa. O quando é o gatilho. Ele mostra o que precisa acontecer. Para determinar um comportamento específico. Então é o comportamento esperado. Ele ilustra o que deve acontecer como resultado de um gatilho específico. Seguindo nosso exemplo anterior, com o cliente que precisa ser capaz realizar uma pesquisa no site. Nosso primeiro cenário e os critérios de aceitação soariam assim. Cenário número um, o título seria a opção Pesquisar está disponível para o usuário. Então nós temos o dado quando então a sequência. Então, vamos ver. Dado que o usuário tem acesso ao site, quando a página do produto do site é exibida, o módulo de pesquisa estará disponível no canto superior direito da tela. Então, o que fizemos aqui? Primeiro, descrevemos o pré-requisito dado que o usuário já acessou o site. Por quê? Porque se o usuário não acessar o site , não há nenhuma funcionalidade para falar. Em seguida, especificamos o gatilho quando a página do produto do site é esta placa. Por quê? Porque a equipe de desenvolvimento precisa saber quando essa funcionalidade recém-implementada deve estar disponível para os usuários. Queremos a funcionalidade de pesquisa em todas as páginas do site? Não. Só queremos que ele esteja disponível quando acessarmos a página de produtos. Então, quando é o gatilho? Lembra disso? Só depois pedimos o comportamento esperado. Em seguida, o módulo de pesquisa está disponível no canto superior direito da tela. Por quê? Porque precisamos ilustrar o que deve acontecer. Se eu acessar o site e chegar na página de produtos. O comportamento esperado no nosso caso é que agora posso ver a caixa de pesquisa. Certo? Assim, podemos ver a caixa de pesquisa nessa página. Mas como fazemos isso funcionar? Bem, isso é bastante fácil. Podemos escrever outro cenário como parte dos critérios de aceitação. Então agora teremos o Cenário número dois com o seguinte título. O usuário pode procurar um produto específico por nome, seguindo a fórmula mágica dada quando então. Aqui está o que temos. Lembre-se. Neste ponto, só podemos ver a caixa de pesquisa. Ele ainda não faz nada. Então aqui vai. Dado que o usuário enviou critérios de pesquisa específicos usando a caixa de entrada de pesquisa. Quando o usuário clica na chamada à ação do CTA de pesquisa. Em seguida, a filtragem é realizada de acordo com os critérios especificados. E a lista de resultados da pesquisa é exibida contendo todos os produtos que correspondem aos critérios de pesquisa. Uma nota importante aqui, você pode ter vários pré-requisitos fornecidos são pré-condições. E você pode expressá-los usando o end. Por exemplo, dado que o usuário enviou critérios de pesquisa específicos usando a caixa de entrada de pesquisa e a caixa de entrada de pesquisa contém caracteres válidos. Você também pode ter vários comportamentos do que o esperado, como por exemplo, em nosso exemplo anterior. Em seguida, a filtragem é realizada acordo com os critérios especificados. E a lista de resultados da pesquisa é exibida contendo todos os produtos correspondem aos critérios de pesquisa. Mas só pode haver um quando o gatilho deve ser uma expressão singular, um único evento. Além disso, em termos de cenários, precisamos ter cuidado para especificar todos os casos possíveis. Cenários de casos felizes, casos de falha e cenários de caso de borda. E denotado para fazer isso corretamente, precisamos andar uma milha no lugar do cliente e sempre questionar cada ação e cada decisão. Essa é a única maneira de maximizar nossas chances descobrir todos os casos de uso possíveis. Então lá vai você. Muitas coisas precisam ser consideradas ao escrever histórias de usuários. E é um processo que não deve ser dado como garantido. Escrevendo histórias de usuários adequadas. Uma vez que a equipe de desenvolvimento pode facilmente entender e implementar aqueles que são claros, concisos e com a quantidade certa e informações de qualidade é um processo completo que pode tornar o seu vida mais fácil ou pode causar pesadelos e muitos problemas. Algumas dicas e truques para você considerar. Comece grande e decompõe-os conforme necessário. As histórias de usos devem ser refinadas. Não se concentre em fazer tudo de uma só vez. Pense nos fluxos do usuário e, em seguida, crie fatias verticais para suportá-los. Ou seja, use o mapeamento de histórias, certo? E revise-os como uma equipe. Porque isso cria um entendimento compartilhado. Este não é um homem único. Mostre-o como um esforço colaborativo. Concentre-se em subjacente à necessidade do cliente, não nas perceções e no estado. Não sue o formato. Existem muitas maneiras válidas de escrever uma história de usuário. Basta descobrir o que funciona melhor para a equipe e depois ser consistente. Histórias de usuários são as estruturas que iniciam e capturam a conversa em torno do recurso baseado em valor centrado em seus usuários. E lembre-se, você não é seu usuário. Por último, mas não menos importante, invista em suas histórias. E o mais importante, pergunte a quem, o quê e o porquê. Use todas essas informações como sua Northstar. Mesmo que provavelmente você não consiga criar usos perfeitos para alcançar e sempre. Mas a prática é perfeita. Então, mantenha o bom trabalho. Reconheceu a importância de escrever histórias de usuários adequadas e tornar sua vida mais fácil em seu trabalho mais agradável.