História de usuário
Uma História de Usuário é uma especificação concisa, escrita na linguagem do usuário final, que descreve o que um usuário faz ou precisa fazer como parte de sua função. Utilizada em metodologias ágeis de desenvolvimento de software, como a Extreme Programming (XP), ela serve como base para definir o escopo de um projeto, capturando o 'quem', 'o quê' e 'por quê' de um requisito de forma simples e direta. Geralmente, é limitada em detalhes e pode ser escrita em um pequeno cartão, funcionando como uma técnica eficaz de análise de requisitos.
Pontos-chave
- Histórias de Usuário são especificações concisas de requisitos, escritas na linguagem do usuário final.
- Elas servem como base para definir o escopo em metodologias ágeis de desenvolvimento de software.
- Capturam o 'quem', 'o quê' e 'por quê' de um requisito de forma simples e direta, muitas vezes em um pequeno cartão.
- Originadas na Extreme Programming (XP), evoluíram para uma técnica fundamental na gestão de produtos e ensino de Engenharia de Requisitos.
- A qualidade de uma História de Usuário pode ser verificada pela fórmula dos Três Cês: Cartão, Conversa e Confirmação.
As Histórias de Usuário surgiram com a Extreme Programming (XP), sendo mencionadas pela primeira vez em 1998 como uma forma de clientes definirem o escopo do projeto, comparáveis a casos de uso. Inicialmente, eram vistas como 'peças do jogo' no planejamento. Com o tempo, a literatura passou a diferenciá-las dos casos de uso, buscando uma abordagem mais prática para os requisitos em projetos ágeis. Essa evolução levou a uma explicação mais sofisticada da técnica, culminando na proposta de Ron Jeffries em 2001 dos 'Três Cês' (Card, Conversation, Confirmation) para avaliar a qualidade de uma História de Usuário.
Além de sua ampla adoção na indústria, as Histórias de Usuário são uma estratégia pedagógica eficaz no ensino de Engenharia de Requisitos. Elas aproximam os estudantes das práticas de mercado, facilitando a compreensão da elicitação, especificação e validação de requisitos. Sua simplicidade e foco na perspectiva do usuário tornam o aprendizado mais acessível em comparação com modelos de documentação tradicionais. Pesquisas em cursos de Computação mostram que, combinadas com metodologias ativas e métodos ágeis, promovem maior engajamento e melhor assimilação dos conceitos. A integração com critérios de aceitação reforça a validação e o alinhamento entre requisitos e testes. O uso de ferramentas colaborativas também impulsiona o trabalho em grupo, a comunicação e o desenvolvimento de soft skills essenciais.
Histórias de Usuário são criadas por ou para usuários e clientes de negócio para influenciar a funcionalidade do sistema. Desenvolvedores também podem escrevê-las para requisitos não funcionais (segurança, desempenho), mas a responsabilidade primária de capturá-las é do gerente de produto. O processo envolve um desenvolvedor e um representante do cliente (como um gerente de produto ou Product Owner em Scrum) que formula as histórias. O desenvolvedor pode fazer perguntas para entender os objetivos do cliente, mas deve evitar dominar a criação da ideia.
Formatos Comuns de Histórias de Usuário
O template tradicional, desenvolvido pela Connextra em 2001, é: 'Como um [tipo de usuário], eu quero [alguma meta] de modo que [alguma razão]'. Mike Cohn considera a cláusula 'de modo que' opcional. Chris Matts propôs uma alternativa focada no valor: 'Para [quem], que [o quê], o [nome da funcionalidade] [por quê]'. Outro modelo baseia-se nas Cinco Ws: 'Quem pode [fazer o quê] [quando] [onde] [por quê]'. Um modelo da Capital One (2004) foca na funcionalidade: 'Quando [condição], então [ação]'. Esses formatos ajudam a estruturar a captura dos requisitos de forma clara e concisa.
Em metodologias ágeis, especialmente XP, a importância dos testes é crucial, pois não há o extenso aparato documental dos processos guiados por planos. As Histórias de Usuário são o principal artefato, e os testes garantem o sucesso da metodologia, sendo as histórias descartadas após a validação. Dois exemplos práticos ilustram o uso de histórias: (1) 'Como consultor, se não terminei de entrar com a despesa, quero 'Guardar para mais tarde' para que os dados inseridos sejam mostrados em uma lista com o estado 'Incompleta'.' (2) 'Como consultor, se decidir limpar os dados e fechar o formulário, quero 'Cancelar e sair' para que os dados introduzidos não sejam salvos em parte alguma.'
