AR Road

Explorando a Documentação de Requisitos em Projetos Ágeis de Software

Conhecendo as Histórias de Usuário

A documentação de requisitos é uma parte fundamental do processo de desenvolvimento de software. Ela descreve as necessidades, funcionalidades e restrições do sistema que está sendo desenvolvido. No Scrum, a abordagem para documentar requisitos é um pouco diferente em comparação com metodologias tradicionais de desenvolvimento de software. Em vez de criar documentos extensivos e detalhados no início do projeto, o Scrum enfatiza a comunicação direta e colaborativa entre os membros da equipe ao longo do ciclo de desenvolvimento. 

 

 

Apesar de não existir uma documentação tradicional, existem algumas estratégias para documentar requisitos com clareza e simplicidade. 

Conduzimos uma pesquisa com profissionais do mercado de tecnologia para identificar quais são os artefatos mais gerados ao trabalhar com requisitos no contexto ágil. De acordo com os resultados, quase 90% dos participantes utiliza as histórias de usuário para documentar requisitos ágeis.

Artefatos gerados ao documentar requisitos ágeis

62 respostas

No Data Found

O que são histórias de usuário?

Uma história de usuário descreve uma funcionalidade ou um requisito do sistema de uma maneira simples e concisa, geralmente na perspectiva do usuário final. Essa técnica enfatiza a comunicação direta entre os membros da equipe de desenvolvimento e os stakeholders do projeto.

Uma história de usuário segue uma estrutura simples, composta por três elementos principais:

  1. Quem: Representa o papel do usuário ou cliente que se beneficiará da funcionalidade descrita na história.
  2. O que: Descreve a funcionalidade desejada ou o objetivo a ser alcançado pelo usuário.
  3. Por que: Explica o motivo pelo qual o usuário precisa dessa funcionalidade e qual é o valor ou benefício que ele espera obter dela.

 

As histórias do usuário em geral são escritas de forma simples e resumida, podendo seguir o seguinte modelo: 

“Como [persona], eu [quero], [para que].”

Esta estrutura não é obrigatória, mas é útil para auxiliar a escrever a definição de “pronto”, ou seja, definir os critérios de aceite. Quando essa persona pode obter seu valor desejado, então a história está completa e aquela tarefa/história pode ser considerada como aceita. 

As histórias de usuário são escritas em linguagem natural e são adaptadas de acordo com a necessidade das partes envolvidas, para o melhor entendimento e otimização do processo, na verdade as equipes podem e devem definir a sua própria estrutura.

 

Mas que tal um exemplo?

  • Como

    um analista de requisitos,

  • Eu quero

    adquirir conhecimento sobre as habilidades necessárias para praticar a engenharia de requisitos ágeis,

  • Para

    otimizar o processo de captura e documentação de requisitos, promovendo mais colaboração com a equipe e garantindo uma contínua entrega de valor ao cliente.

E agora quais seriam os critérios de aceitação para essa história de usuário?

  1. Deve ser possível acessar conteúdos educacionais que eduquem sobre o conhecimento necessário para a prática da engenharia de requisitos no contexto ágil através de um website.
  2. Os recursos educacionais devem ser organizados de forma clara e intuitiva, permitindo que os visitantes naveguem facilmente pelo conteúdo relevante.
  3. Os recursos educacionais devem ser facilmente compreensíveis e acessíveis para que os analistas de requisitos possam adquirir conhecimento de forma eficaz.

Que tal mais alguns exemplos de histórias de usuário dentro de um projeto?

Imagine que uma certa loja online procurou sua equipe para uma melhoria em seu site. 

Durante as reuniões de levantamento de requisitos você descobre que eles querem as seguintes mudanças:

  • Login com Conta Google: Facilita o acesso ao site, eliminando a necessidade de lembrar senhas adicionais e garantindo segurança através da autenticação do Google.
    Motivação: facilidade de uso.

  • Ajustar Funcionalidade de Recuperação de Senha: Ajustar alguns parâmetros da funcionalidade de acordo com boas práticas do mercado, para dar maior segurança aos clientes.
    Motivação: mitigar falhas de segurança.

  • Criar Funcionalidade de Abrir uma Reclamação no Site: Oferece aos clientes a possibilidade de registrar preocupações de forma transparente, demonstrando o comprometimento da empresa com a resolução ágil de problemas.
    Motivação: alguns clientes reclamaram que é muito difícil abrir reclamações pelo telefone.

  • Criar Lista de Desejos: Permite que os usuários organizem e acompanhem produtos desejados, facilitando e incentivando a compra.
    Motivação: funcionalidade desejável.

Você poderia colocar todos esses pedidos dentro de uma só história de usuário? Provavelmente sim, mas não é o certo.

O certo é dividir o trabalho em partes menores, para que cada funcionalidade tenha seus próprios critérios de aceite e que o trabalho consiga ser priorizado de acordo com as necessidades do cliente, de forma que cada história de usuário possa ser alocada e entregue dentro de um dos ciclos do Scrum.

No exemplo acima, considere que os pedidos possuem a seguinte prioridade:

  1. Ajustar funcionalidade de recuperação de senha: Possui o maior nível de prioridade pois resolve uma falha de segurança;
  2. Abertura de Reclamações Diretamente no Site: Possui esse nível de prioridade pois vai resolver uma falha no processo de atendimento;
  3. Login com Conta Google: Possui esse nível de prioridade pois é uma melhoria nos parâmetros de login, para acompanhar os padrões de ferramentas similares no mercado;
  4. Lista de Desejos Personalizada: Possui esse nível de prioridade pois é uma funcionalidade considerada desejável pelo cliente, que pode ser usada como estratégia para aumentar o número de vendas de produtos.


É claro que as histórias de usuário podem variar de acordo com definições técnicas específicas de cada empresa e com os recursos disponíveis, porém abaixo temos um exemplo de como elas poderiam ficar para esse projeto. 

Dê uma olhada!