Vejamos como e por que podemos querer garantir a qualidade das histórias de usuários. Histórias de usuários ruins levam a reuniões desnecessárias, desperdício e retrabalho. Melhorar a história do usuário o mais cedo possível no ciclo de vida de desenvolvimento é uma forma eficaz de minimizar o desperdício e o retrabalho.
A garantia de qualidade é uma abordagem sistemática para determinar se um “produto” atende a critérios aceitáveis. Para o controle de qualidade das histórias de usuários, precisamos primeiro definir o que é bom? Qual é a diferença entre boas histórias de usuários (e conjunto de histórias de usuários) e baixa qualidade.
Para o desenvolvimento ágil de software, tendemos a usar a história do usuário como uma forma abreviada de um requisito de software. Alguns coaches ágeis podem contestar que as histórias de usuários sejam efetivamente requisitos, mas é o que a maioria das equipes realmente faz.
Hoje em dia, a maior parte da garantia de qualidade é parcialmente (ou totalmente) automatizada.
O que esperamos de uma boa User Story?
Mínimo
- Recomendamos um título sucinto e exclusivo
- Identificação clara do usuário (consistente em um conjunto de histórias de usuários).
- Declarações claras e sucintas das etapas funcionais necessárias para satisfazer um único requisito funcional do usuário.
Opcional, recomendado
- Uma declaração de beneficiar ou “para que”
- Uma declaração do evento desencadeador, quais circunstâncias do usuário fazem com que esse requisito entre em ação.
- Um ID de referência exclusivo, que não muda, mesmo que a história do usuário mude.
