Aprenda a escrever histórias de usuários melhores
O que são histórias de usuários?
Uma história de usuário é um espaço reservado para uma conversa, uma frase ou algumas usadas pelas equipes de desenvolvimento de software ágil para descrever funcionalidades valiosas nas quais pretendem trabalhar.
A história do usuário é um meio de comunicação (e um gatilho para comunicação posterior).
As histórias de usuários são um meio de comunicar sucintamente as necessidades funcionais orientadas ao usuário de software. Eles são uma forma abreviada e de alto nível de descrever requisitos de software. Eles são usados no trabalho de software Agile e são projetados para servir de estímulo para uma conversa. Freqüentemente, são a única forma escrita dos requisitos.
As histórias de usuários devem ser escritas por alguém com uma “perspectiva do usuário” e não técnica. Eles devem descrever a funcionalidade e o valor que se espera que a equipe entregue ao usuário. Quando escrevemos uma história de usuário, estamos adquirindo e compartilhando conhecimento.
Requisitos e histórias de usuários – qual a diferença
Os requisitos de software são mais uma hierarquia do que um único conceito. Os requisitos de software começam com Resultados de Negócios (ou objetivos de negócios), que podem ser divididos em Capacidades (às vezes também chamados de requisitos de software de negócios, Epics ou conjuntos de recursos, podem ser considerados como aquilo que precisa ser entregue para fornecer valor de negócio). Estas, por sua vez, podem ser divididas em histórias de usuário mais granulares (ou requisitos funcionais do usuário). Finalmente, as histórias de usuários podem ser divididas em tarefas técnicas. Um bom conjunto de requisitos de software precisa de TODOS eles (exceto tarefas técnicas).
Outros
Requisitos não funcionais (NFRs),
Para alcançar os resultados comerciais declarados, é provável que algumas NFR também sejam importantes. Existem dezenas de tipos de NFR, muitas vezes chamados de funcionalidades de uma solução de software. Curiosamente, o “NFR” mais citado é a segurança e, ainda assim, os recursos de segurança são normalmente funcionais. As NFRs são particularmente difíceis de dimensionar.
Critérios de Aceitação
Os critérios de aceitação são uma qualificação detalhada da história do usuário OU NFR. Eles definem o que é aceitável e inaceitável com mais detalhes do que uma história de usuário típica. A história do usuário geralmente está no nível do objeto, enquanto os critérios de aceitação geralmente definem os limites no nível do atributo.
Restrições
Estas nem sempre são articuladas como tal em um projeto de software. Às vezes, eles são incorporados incorretamente em uma história de usuário. Elas podem ser consideradas restrições do projeto e muitas vezes determinam como o software pode ser entregue, e não o que é entregue.
Histórias de usuários são importantes
Nenhum projeto de software substancial será entregue dentro do prazo e do orçamento se omitir a produção de um conjunto de requisitos funcionais ou histórias de usuários. E estes devem ser de alta qualidade (mais sobre isso mais tarde). Além disso, cada palavra da história do usuário é importante.
Criando histórias de alta qualidade
As maravilhas da língua inglesa nos dão muitas maneiras de expressar a mesma coisa. Esta flexibilidade leva a potenciais diferenças na compreensão. Quando dois leitores de uma história de usuário conseguem chegar a uma compreensão diferente do que as palavras significam, temos um mal-entendido. E mal-entendidos provavelmente levarão a um defeito de software.
Quanto tempo eles deveriam durar?
Quanto mais curto geralmente é melhor. Vimos histórias com apenas duas palavras e até uma página de texto. Geralmente, quanto menor, melhor, mas tome cuidado para não perder funcionalidades críticas. Recomendamos de 5 a 50 palavras dependendo da complexidade (excluindo o para que declaração).
Quem escreve histórias de usuários
Idealmente, o autor das histórias de usuários é um proprietário do produto com vasta experiência na função de cliente ou usuário final. Às vezes isso não é prático e o autor é um representante do usuário final, normalmente um Analista de Negócios (BA). O BA cria a primeira edição da história, que posteriormente é discutida e refinada pela equipe. Uma vez que haja um entendimento comum do que isso realmente significa. Ele pode então seguir em frente para ser trabalhado. O desafio é chegar a um entendimento claro e comum rapidamente e com poucas palavras.
Histórias de usuários de maior qualidade evitarão bugs.
Muitas equipes de software não percebem o quão importante é trabalhar com requisitos de boa qualidade ou histórias de usuários. Geralmente, 20% ou mais, todos os problemas de qualidade de software são causados por problemas de requisitos.
Comece com o “Quem, Oque e porque"
A necessidade funcional e a justificativa comercial são os aspectos mais fundamentais de boas histórias de usuários. Com isso queremos dizer “Quem precisa fazer o quê e por quê”. Quem é o usuário (humano ou sistema conectado), o que os dados são manipulados e movidos, e por que é o que segue o “assim que” em uma história de usuário. Concentre-se neles e evite o como (exclua declarações de design).
Melhores histórias de usuários reduzirão o retrabalho
Para qualquer equipe de desenvolvimento, entrar em um sprint com uma história de usuário ruim pode ser ágil, mas certamente não é enxuto. Vale a pena gastar tempo fazendo com que as histórias de seus usuários sejam as melhores possíveis e tão claras quanto possível para minimizar mal-entendidos. Mal-entendidos levarão a retrabalhos dispendiosos.
Qual é a diferença entre histórias de usuários e casos de uso
Já falamos muito sobre histórias de usuários. A caso de uso é uma lista de ações ou etapas de eventos que normalmente definem as interações entre uma função (referida como ator) e o sistema. Histórias de usuários normalmente são um subconjunto de um caso de uso. Uma história de usuário normalmente descreve apenas uma das interações que podem ser descritas em um caso de uso.
Teste automatizado de histórias de usuários
A qualidade das histórias de usuários tem sido prejudicada pela automação. Na verdade, antes do lançamento do ScopeMaster®, não tínhamos conhecimento de quaisquer ferramentas que pudessem ajudá-lo a melhorar a qualidade das suas histórias de usuários. Existem alguns produtos no mercado que abordam algumas das funcionalidades do ScopeMaster, mas nenhum chega perto de oferecer uma análise automatizada tão abrangente e valiosa de histórias de usuários para controle de qualidade, estimativa e geração de testes.
Noções básicas funcionais versus critérios de aceitação
Lembre-se de que a descrição principal da funcionalidade do usuário precede os critérios de aceitação. Os critérios de aceitação são uma elaboração e dependem de um conjunto claro e funcional de declarações da perspectiva do usuário.
Testes de requisitos em tempo real e sugestões de melhorias
O ScopeMaster realiza análises, testes, correlação e dimensionamento em tempo real a partir do texto das histórias de usuários. O feedback fornecido pelo ScopeMaster irá ajudá-lo a melhorar o texto que você usa. Você alcançará requisitos mais claros, concisos, completos e consistentes. Concentre-se primeiro em Quem e O que. O ScopeMaster gera e executa testes estáticos e dinâmicos em cada história de usuário, que ajudarão a encontrar e avisar sobre possíveis problemas. Ele desempenha um nível de escrutínio automatizado de requisitos que até agora não estava disponível na indústria de software.
O ScopeMaster® não apenas examina e analisa a linguagem de cada história de usuário, mas também cruza referências de cada história com todas as outras dentro de um conjunto – ele detecta inconsistências, omissões e duplicatas. Isso ajuda você a refinar seus requisitos com muito mais rapidez. A interface inteligente do ScopeMaster identifica dinamicamente histórias faltantes e torna ainda mais fácil adicioná-las.
Lidando com possibilidades infinitas
O ScopeMaster supera a vasta gama de possíveis expressões de requisitos usando uma forma de Inteligência Artificial conhecida como Processamento de Linguagem Natural. Isso permite que você expresse suas histórias de usuários em termos específicos do seu setor; a ferramenta não requer treinamento prévio.
Crie histórias de usuários melhores com mais rapidez
O ScopeMaster verifica histórias de usuários (ou requisitos de software) em busca de uma linguagem apropriada que seja adequada aos requisitos de software e que o ajudará a escrever histórias mais claras, concisas, consistentes, completas e inequívocas.
Detecta possíveis defeitos
INVESTIR – é uma lista de verificação comumente usada para qualidade ágil de histórias de usuários.
- Independente *
- Negociável / Conciso *
- De valor
- Estimável *
- Tamanho *
- Testável *
*ScopeMaster ajuda o autor a encontrar e corrigir esses problemas (mais de 50% de todos os defeitos de requisitos).
Nossa lista de verificação preferida e mais abrangente para escrever melhores histórias de usr é esta:
- Inequívoco/claro *
- Mensurável/Funcional *
- Conciso *
- Orientado ao usuário *
- Testável *
- Consistente *
- Inteiro e completo *
- Exclusivo *
- Design Gratuito *
- Rastreável ao valor do negócio
O ScopeMaster ajuda até certo ponto 9 entre 10 destes critérios de qualidade e, no geral, irá ajudá-lo encontre mais de 50% de possíveis defeitos de requisitos, pré-codificação.
Em nossos próprios testes em mais de 250.000 histórias de usuários coletadas de mais de 100 fontes, descobrimos que o ScopeMaster expõe de 0,3 a 0,7 defeitos por CFP (excluindo inconsistências, que expomos, mas não podemos calcular), enquanto o típico observado na indústria é de pouco menos de 1 defeito por FP (Capers Jones). Aí estão dados reais mostrando que o ScopeMaster pode ajudá-lo a escrever melhores histórias de usuários.
Ao usar o ScopeMaster interativamente no início do seu projeto para melhorar suas histórias de usuários, você pode colocar seu trabalho de software em uma base de qualidade mais sólida desde o início – antes do início do design e da codificação. Você pode continuar refinando as histórias ou durante todo o processo de desenvolvimento, como parte do refinamento do backlog do produto. O melhor é que você terá evitado o retrabalho começando com uma base melhor para escrever histórias de usuários de maior qualidade.
Comunicar
Em primeiro lugar, uma história de usuário é um meio de comunicação. Precisa transferir conhecimento sobre alguns ou todos os seguintes itens: a necessidade, o requisito, a funcionalidade, o resultado, a finalidade do requisito. Se não fornecer uma intenção clara, isso levará a interpretações erradas que, por sua vez, podem levar a bugs.
Aprenda a escrever histórias de usuários que os desenvolvedores e testadores vão adorar
Deixe o ScopeMaster ajudá-lo a escrever histórias de usuários que sua equipe achará fáceis de construir. Essas histórias serão claras, suficientes, consistentes, completas, consideráveis e testáveis. Todos podem se tornar autores de ótimas histórias de usuários.
Alexander Cowan História de usuário refinada
Alexander propõe etapas para alcançar uma história de usuário de boa qualidade, propondo o seguinte como uma história de usuário “refinada”.
'Como gerente de RH, quero criar um questionário de triagem para ter certeza de que estou preparado para usá-lo ao entrevistar candidatos a empregos.'
Executamos isso isoladamente no ScopeMaster e ele detectou instantaneamente a intenção funcional primária e mediu o tamanho como 4 pontos de função cósmica.
Outra fonte útil para o definição de uma história de usuário.
Exemplo de cabra montesa
Também analisamos o conjunto de 238 histórias de usuários publicado por Mike Cohn
- Tempo gasto
- 64 segundos
- Avaliação de qualidade:
- 54% inequívoco, dimensionado em 629 CFP
- 46% ambíguo
- 233 omissões potenciais
- 28 possíveis duplicatas
- Mais de 20 inconsistências
- Dimensionamento / Estimativa
- Estimativa do tamanho total do 1161 CFP.
Foco na tarefa do usuário
Histórias de usuários ou requisitos focados no que o usuário precisa que o sistema faça para realizar uma tarefa serão mais úteis do que uma lista de recursos.
Arte ou Ciência
A arte é subjetiva enquanto a ciência é objetiva, a arte expressa conhecimento. A aplicação da ciência em cenários do mundo real é normalmente considerada engenharia.
Quando escrevemos uma história de usuário, estamos adquirindo e compartilhando conhecimento.
Por um lado, a história do usuário é uma aquisição de conhecimento do cliente/usuário/proprietário do produto e, por outro lado, é também uma expressão de conhecimento para a equipe compreender e trabalhar.
Comum à ciência e à engenharia é a medição, embora esta esteja quase sempre ausente nas obras de arte.