Vejamos como isso fica com a nossa história do usuário original: a equipe realiza uma sessão de refinamento de lista de pendências e analisa a história do usuário do recurso de status de voo.

Desenvolvimento de Requisitos Ágeis
Os requisitos ágeis são desenvolvidos por meio de um processo colaborativo e iterativo que envolve
várias técnicas para capturar, priorizar e validar as necessidades do usuário e os recursos do produto.

Vejamos essas técnicas, então:

Histórias de usuário: uma história de usuário é uma declaração breve e simples que
descreve a necessidade ou o recurso de um usuário a partir de sua perspectiva. A
história é normalmente escrita em uma linguagem amigável, fácil de entender e com
critérios de aceitação específicos. As histórias de usuários são um bloco de construção
fundamental dos requisitos ágeis e ajudam a garantir que a equipe esteja focada na
entrega de valor aos usuários finais. Exemplo de um padrão aceito para história do
usuário: “Como viajante frequente, quero poder ver o status do voo da minha próxima
viagem para que eu possa planejar meu dia”;

Critérios de aceitação: os critérios de aceitação são um conjunto de condições que um
produto ou recurso deve atender para ser considerado completo e aceitável. Os
critérios de aceitação ajudam a garantir que a equipe entenda o que é esperado e quais
são as necessidades do usuário. Aqui vai um exemplo seguindo a história do usuário do
exemplo anterior para dar continuidade: “O status do voo deve incluir atualizações em
tempo real sobre os horários de partida e chegada, quaisquer alterações no portão de
embarque e quaisquer atrasos ou cancelamentos”;

Prototipagem: envolve a criação de um modelo simples e de baixa fidelidade do
produto ou recurso para testar e validar com os usuários. A criação de protótipos pode
ajudar a identificar problemas de design logo no início e ajudar a garantir que a equipe
esteja criando o produto certo. Vejamos um exemplo utilizando a história do usuário
usada acima: a equipe cria um protótipo do recurso de status de voo com uma interface
simples e que permite aos usuários visualizar atualizações em tempo real de seus
próximos voos. Depois a equipe testa o protótipo com um pequeno grupo de usuários e
coleta feedback para refinar o design;

Modelagem Ágil: a modelagem ágil envolve a criação de diagramas ou modelos para
ajudar a comunicar requisitos e decisões de projeto. A modelagem ágil pode ajudar a
garantir que a equipe esteja alinhada com a visão e o design do produto. Utilizando a
mesma história do usuário, aqui vai mais um exemplo: a equipe cria um diagrama de
caso de uso de alto nível para ilustrar como o recurso de status de voo interagirá com
outras partes do produto. O diagrama inclui o usuário, o recurso de status de voo e os
outros componentes do produto;

Refinamento de backlog: envolve revisar e priorizar regularmente o backlog do produto
para garantir que ele esteja atualizado e que a equipe esteja focada em fornecer os
recursos mais valiosos primeiro. Vejamos como isso fica com a nossa história do usuário
original: a equipe realiza uma sessão de refinamento de lista de pendências e analisa a
história do usuário do recurso de status de voo. Eles refinam os critérios de aceitação e
adicionam detalhes adicionais para garantir que a história seja clara e acionável.

Roman Pichler, um especialista em gestão de produtos ágeis, aplicou esse conceito de
“Refinamento” ao backlog (repositório de requisitos dentro do framework Scrum), criando uma
espécie de modelo, que é apresentado na figura logo acima. São apresentadas 3 áreas: a primeira,
em tons de azul, é onde estão as histórias dos usuários (Story Area); a segunda, em tons de verde, é a
área das restrições e de design da interface do usuário (Constraint Area); por fim, em tons de laranja,
está a área onde modelamos a solução para que seja produzido o código (Model Area).