Documentos de requisitos tradicionais possuem, muitas
vezes, centenas de páginas e podem levar muito tempo
para ficarem prontos. Os profissionais da indústria que
apresentaram métodos ágeis perceberam — ou sofreram com — tais problemas e propuseram uma técnica
pragmática para solucioná-los que ficou conhecida
pelo nome de Histórias de Usuários. Quando usamos
histórias de usuários, atividades de Engenharia de
Requisitos ocorrem ao longo de todo o desenvolvimento, em praticamente todos os dias de uma iteração.
Consequentemente, troca-se um documento de requisitos com centenas de páginas por conversas frequentes,
nas quais o representante dos clientes explica os requisitos para os desenvolvedores da equipe. Assim, histórias
de usuários favorecem comunicação verbal, em vez de
comunicação escrita.
Considere as seguintes afirmações.
I - Histórias não devem ser abertas para negociação.
Uma vez definidas, não se pode usar histórias nas
conversas entre clientes e desenvolvedores
durante um sprint.
II - Histórias devem ser testáveis, isto é, elas devem
ter critérios de aceitação objetivos.
III - Histórias devem ser independentes: dadas duas
histórias, deve ser possível implementá-las em
qualquer ordem. Para isso, idealmente, não devem
existir dependências entre elas.
Quais caracterizam corretamente Histórias de Usuários?