O que é uma História de Usuário?

O que é uma História de Usuário?

Uma história de usuário é uma anotação que captura o que um usuáriofaz ou precisa fazer como parte do seu trabalho. Cada história de usuário consiste em uma breve descrição escrita do ponto de vista do usuário, em linguagem natural. Diferentemente da captura tradicional de requisitos, a história de usuário foca no que o usuário precisa, em vez do que o sistema deveria entregar. Isso deixa espaço para discussões posteriores sobre soluções e resulta em um sistema que realmente se encaixa no fluxo de trabalho dos clientes, resolvendo seus problemas operacionais e, mais importante, agregando valor à organização.

Conceito dos 3C’s

Os 3C’s referem-se aos três aspectos críticos de boas histórias de usuário. O conceito foi sugerido por Ron Jeffries, co-inventor da prática de histórias de usuário. Hoje em dia, quando falamos sobre histórias de usuário, geralmente nos referimos ao tipo de histórias de usuário que são compostas por esses três aspectos.

1. Cartão – As histórias de usuário são escritas como cartões. Cada cartão de história de usuário contém uma frase curta com apenas o texto necessário para lembrar a todos do que se trata a história.
2. Conversa – Os requisitos são identificados e refinados por meio de conversas contínuas entre clientes e equipe de desenvolvimento durante todo o projeto de software. Ideias e decisões importantes serão descobertas e registradas durante as reuniões com os interessados.
   
3. Confirmação – ou também conhecido como critérios de aceitação da história de usuário. Durante a discussão de requisitos, os clientes informam ao analista não apenas o que desejam, mas também confirmam sob quais condições e critérios o software funcional será aceito ou rejeitado. Os casos definidos são escritos como confirmação. Observe que a confirmação foca em verificar a correção do trabalho da história de usuário correspondente. Não se trata de testes de integração.
   

Como identificar uma História de Usuário?

As histórias de usuário devem ser identificadas junto com os interessados, preferencialmente por meio de reuniões presenciais. A história de usuário é um processo de descoberta de requisitos, e não um processo de análise de requisitos prévio. Nos métodos tradicionais de captura de requisitos, o analista de sistemas tenta compreender as necessidades dos clientes e depois prepara uma especificação detalhada de requisitos para o sistema. Isso não é como funciona a abordagem de histórias de usuário. Em vez de um processo de documentação, a identificação da história de usuário é mais parecida com um processo de anotação. Através das discussões com os usuários, ouvimos e compreendemos seus problemas e necessidades, e então registramos suas necessidades como histórias de usuário ao mesmo tempo. Essas histórias de usuário se tornarão a fonte dos requisitos. Os detalhes podem ser preenchidos posteriormente, just-in-time, fornecendo à equipe uma referência de requisitos ‘justo o suficiente’ durante todo o processo de desenvolvimento do projeto.

Mapeamento de Processos de Negócio com Histórias de Usuário

BPMN é uma das ferramentas mais poderosas para análise e modelagem de negócios. Não apenas podemos usá-lo para realizar melhorias de processos, mas também podemos identificar histórias de usuário a partir desses processos que pretendem ser automatizados por meio dos seguintes passos:

1. Simplesmente modele o fluxo de trabalho do usuário com um diagrama de processo de negócios BPMN.
2. Passe pelo modelo de processo com os usuários.
3. E, analise as atividades de negócios do problema, e então identifique as histórias de usuário relacionadas ao processo que precisa ser automatizado, o que também é conhecido como mapeamento de processo de negócios para história de usuário.

Como escrever uma História de Usuário?

Ao escrever uma história de usuário, tente escrever na voz do usuário conforme o formato abaixo (ou, pelo menos, certifique-se de que o que você escreveu atende à seguinte afirmação):

Como um <papel>, quero <objetivo de negócios> para que <valor de negócios/motivo>.

Por exemplo, como um cliente, quero receber uma mensagem de texto quando o item chegar para que eu possa vá buscar.

onde:

1. <papel> representa a pessoa, sistema, sub-sistema ou qualquer outra entidade que irá interagir com o sistema a ser implementado para alcançar um objetivo. Ele ou ela obterá valores ao interagir com o sistema.
2. <objetivo de negócios> representa a expectativa do usuário que pode ser alcançada por meio da interação com o sistema.
3. <valor de negócios> representa o valor por trás da interação com o sistema.

Não é uma regra, mas uma orientação que ajuda você a pensar sobre uma história de usuário considerando o seguinte:

1. A história do usuário trará valor para alguém ou para uma parte específica (por exemplo, clientes).
2. A história do usuário está atendendo a uma necessidade do usuário (por exemplo, receber um SMS quando o item chegar)
3. Há uma razão para apoiar a implementação desta história do usuário (por exemplo, o cliente pode ir buscar o item que comprou)

Cada história do usuário deve trazer valor(s) para alguém. Mas às vezes, o valor é suficientemente evidente apenas ao ler o objetivo de negócios. Escrever o valor como parte da declaração é trabalhoso. Nesse caso, simplesmente o omitiremos. Aqui estão alguns exemplos:

Como cliente, quero efetuar o pagamento usando cartão de créditopara que eu possa usar meu cartão de crédito na compra online.

Como usuário, quero realizar uma busca digitando o nome do meu amigopara que eu possa encontrar meu amigo com base no seu nome.

Não importa como você escrever uma história do usuário, há duas coisas que você deve ter em mente. Primeiro, uma história do usuário deve ser escrita do ponto de vista do usuário. Segundo, mantenha a descrição ‘apenas o suficiente’. Evite adicionar muitos detalhes no início de um projeto de software. Mais tarde, você terá a oportunidade de aprimorar e detalhar a história do usuário para que ela se torne algo que possa ser usado pelos desenvolvedores na concepção e implementação.

Ciclo de vida de uma história do usuário

Em sentido amplo, existem seis estados principais para cada história do usuário ao longo de um projeto de software:

1. Pendente – Por meio da comunicação entre o usuário e a equipe do projeto, as histórias do usuário são identificadas. Neste estado, as histórias do usuário têm apenas uma breve descrição da necessidade do usuário. Ainda não houve discussão detalhada sobre requisitos, lógica do sistema ou design de tela. Na verdade, o único propósito da história do usuário, por enquanto, é lembrar todas as partes sobre uma futura discussão sobre o pedido do usuário escrito nesta história (cartão). É possível que a história do usuário seja descartada no futuro.
2. Para fazer – Por meio de uma discussão entre diferentes partes interessadas, as histórias do usuário a serem abordadas nas próximas semanas são definidas e inseridas em um período limitado chamado sprint. Essas histórias do usuário são consideradas no estado ‘Para fazer’. Neste estado, ainda não houve discussão detalhada.
3. Em discussão – Quando uma história do usuário está no estado de Discussão, o usuário final se comunicará com a equipe de desenvolvimento para confirmar os requisitos e definir os critérios de aceitação. A equipe de desenvolvimento anotará os requisitos ou quaisquer decisões como notas de conversa. O especialista em UX pode criar wireframes ou storyboards para permitir que o usuário visualize as funcionalidades propostas em protótipos visuais e as experimente. Esse processo é conhecido como design de experiência do usuário (UX design).
   
4. Em desenvolvimento – Após os requisitos forem esclarecidos, a equipe de desenvolvimento irá projetar e implementar os recursos para atender às solicitações do usuário.
5. Confirmando – Após a equipe de desenvolvimento ter implementado uma história de usuário, a história de usuário será confirmada pelo usuário final. Ele/ela terá acesso ao ambiente de testes ou a um produto de software parcialmente completo (às vezes conhecido como versão alpha) para confirmar o recurso. A confirmação será realizada com base nos itens de confirmação escritos ao detalhar a história de usuário. Até que a confirmação seja concluída, a história de usuário é considerada no estado de Confirmando.
6. Concluído – Finalmente, o recurso é confirmado como concluído, e a história de usuário é considerada no estado Concluído. Normalmente, este é o fim da história de usuário. Se o usuário tiver uma nova exigência, seja sobre um novo recurso ou uma melhoria da história de usuário concluída, a equipe criará uma nova história de usuário para a próxima iteração.

Detalhamento da História de Usuário – Quando e Porquê?

Uma característica fundamental que diferencia a história de usuário das abordagens tradicionais de captura de requisitos é que a abordagem de histórias de usuário divide a identificação do problema e da solução em duas etapas, realizadas em estágios diferentes de um projeto de software. Enquanto os problemas e uma compreensão breve das solicitações do usuário são identificados no início do projeto de software, os detalhes dos requisitos do sistema são definidos apenas antes do início do projeto e da implementação. Aqui estão algumas vantagens dessa abordagem:

1. Capaz de responder às necessidades mais recentes do usuário, pois os requisitos são detalhados logo antes da implementação, em vez de tudo ser concluído no início.
2. Capaz de identificar os requisitos corretos mais facilmente, pois tanto os problemas quanto as soluções serão objeto de discussões detalhadas. Nas abordagens tradicionais, como os detalhes de todos os requisitos são necessários para serem encontrados no início do projeto, os requisitos “pré-definidos” poderiam ter mudado ao longo do tempo, resultando em grande desperdício de esforços de análise.
3. – Por outro lado, as histórias de usuário que forem consideradas inválidas podem ser descartadas facilmente. Você não perde muito tempo em estudos e documentação anteriores

Como Usar a História de Usuário de Forma Eficiente?

Assim como muitas outras metodologias de desenvolvimento de software, se você aplicar corretamente a história de usuário em seu projeto de software, será capaz de produzir um sistema de software de qualidade, além de conquistar a confiança e a satisfação dos clientes. Aqui estão alguns pontos que você precisa ter em mente ao usar a história de usuário:

1. Mantenha a descrição da história de usuário curta.
2. Pense do ponto de vista do usuário final ao escrever uma história de usuário.
3. Um (UML) caso de uso representa um objetivo de negócios. A capacidade de agrupar histórias de usuário sob casos de uso permite garantir que uma história de usuário esteja atendendo a um objetivo de negócios, ou seja, que compartilhem o mesmo objetivo do sistema. Serve como um espaço reservado para você gerenciar, agendar e priorizar histórias de usuário de forma mais prática.
4. Os itens de confirmação devem ser definidos antes de iniciar o desenvolvimento
5. Estime a história de usuário antes da implementação para garantir que a carga de trabalho da sua equipe esteja sob controle.
6. Os requisitos são definidos com os usuários finais, não pelo usuário final ou apenas pela equipe de desenvolvimento. Manter um bom relacionamento com os usuários finais será uma situação de ganha-ganha para ambas as partes.
7. A comunicação é sempre importante para entender o que o usuário final deseja.

Visual Paradigm fornece todas as ferramentas de que você precisa em desenvolvimento ágil de software, que inclui ferramenta de diagrama de casos de uso UML, (ágil) história de usuário, sprint, quadro de história e wireframes para design de UX, ferramenta de gerenciamento de tarefas, etc.