História de usuário

Em desenvolvimento de software e gerenciamento de produto, uma História de usuário (User Stories) é uma especificação de uma ou mais sentenças na linguagem de negócio ou cotidiana do usuário final ou usuário do sistema que captura o que um usuário faz ou necessita fazer como parte de sua função de trabalho. Histórias de usuário são usadas com metodologias ágeis de desenvolvimento de software como a base para definir o escopo de um projeto de software. É uma técnica de análise de requisitos. Ela captura o "quem", "o quê" e "por quê" de um requisito em uma forma concisa e simples, geralmente limitada em detalhes, de forma que possa ser escrita a mão em um pequeno cartão de notas de papel.

História

As Histórias de usuário originaram-se com a Extreme Programming (XP), cuja primeira descrição por escrito, em 1998, apenas alegou que os clientes definiam o escopo do projeto "com Histórias de usuários, que são como os casos de uso". Ao invés de ser oferecidas como uma prática distinta, elas foram descritas como uma das "peças do jogo" usadas no jogo de planejamento. No entanto, a maior parte da literatura impulsiona em torno de todas as maneiras, argumentando que as Histórias do usuário são "diferentes" dos casos de uso, na tentativa de responder de uma forma mais prática "como os requisitos são tratados" em XP e mais geralmente projetos ágeis. Isso conduz o surgimento, ao longo dos anos, de uma explicação mais sofisticada de Histórias de usuários.

Em 2001, Ron Jeffries propôs a fórmula bem conhecida dos Três Cês, ou seja, Card (cartão), Conversation (conversa), Confirmation (confirmação), para verificar a qualidade de uma Histórias de usuário:

• Um Cartão (ou muitas vezes uma nota de Post-it) é um símbolo físico dando forma tangível e durável para o que, de outra forma, seria apenas uma abstração. A ideia do cartão é garantir que a descrição da História seja sucinta, objetiva, direta.
• Uma Conversa está ocorrendo em tempo e lugares diferentes durante um projeto entre as várias partes interessadas relacionadas pelo recurso dado (clientes, usuários, desenvolvedores, testadores, etc.), o que é em grande parte verbal, mas na maioria das vezes complementado pela documentação;
• A Confirmação, o mais formal o melhor, garante que os objetivos que giravam em torno da conversa girava foram finalmente alcançados.

Criando Histórias de usuário

Histórias de usuário são escritas por ou para usuários ou clientes de negócio como uma maneira primária para influenciar a funcionalidade do sistema sendo desenvolvido. Histórias de usuário podem também ser escritas por desenvolvedores para expressar requisitos não funcionais (segurança, desempenho, qualidade, etc.), embora primariamente seja a tarefa de um gerente de produto garantir que as Histórias de usuário sejam capturadas.

Quando chega a hora de criar Histórias de usuário, um dos desenvolvedores se reúne com um representante do cliente, e.g. um gerente de produto (ou dono do produto em Scrum), que possui a responsabilidade de formular as Histórias de usuário. O desenvolvedor pode usar uma série de perguntas para obter a meta do representante do cliente, como perguntar sobre a conveniência de alguma funcionalidade em particular, mas deve tomar cuidado para não dominar o processo de criação da ideia.

Quando o representante do cliente concebe uma Histórias de usuário, ela é escrita em um cartão de nota (e.g. de 8x13 cm) com um nome e uma breve descrição. Se o desenvolvedor e o representante do cliente encontrar uma Histórias de usuário deficiente de alguma forma (muito grande, complicada, ou imprecisa), ela é reescrita até ficar satisfatória - muitas vezes utilizando as diretrizes INVEST. Comumente, as Histórias de usuário não são definitivas, uma vez que elas foram escritas e que os requisitos tendem a mudar ao longo do ciclo de desenvolvimento, os quais os processos ágeis manipulam não os tornando imutáveis.

Formato

Uma equipe da Connextra desenvolveu o template tradicional usuário-História em 2001:

"Como um <papel>, eu quero <meta/desejo> de modo que <benefício>"

Mike Cohn, um autor bem conhecido em Histórias de usuário, se refere à cláusula "de modo que" como opcional:

"Como um <papel>, eu quero <meta/desejo>

Chris Matts sugeriu que "caçar o valor" era o primeiro passo para garantir o êxito software, e propôs esta alternativa como parte de Injeção de Funcionalidade:

"A fim de <receber benefício> como um <papel>, eu quero <meta/desejo>"

Outro modelo baseado sobre o que a Five Ws especifica:

"Como <quem> <quando> <onde>, eu <o que>, porque <por que>."

Um modelo desenvolvido na Capital One, em 2004, durante a sua adoção inicial de métodos ágeis centra-se na funcionalidade e especifica:

"Como um <papel>, eu posso <ação com o sistema> para que <benefício externo>"

Exemplos

Busca por clientes

Como um usuário, eu quero procurar por meus clientes pelos seus primeiros e últimos nomes.

Modificar agendas

Como um usuário não administrativo, eu quero modificar minhas próprias agendas mas não as agendas dos outros usuários.

Executar testes

Como um testador de aplicações móveis, eu quero testar meus casos de teste e relatar os resultados para meu gerenciamento.

Os requisitos para metodologias de teste para processos ágeis não possuem grande diferenciação em relação processos guiados por planos. O que realmente difere é o grau de importância conferido aos testes em cada um dos processos. Nos processos guiados por planos, existe uma série extensa de artefatos documentais resultantes de uma análise profunda sobre o sistema a ser desenvolvido. Os testes são utilizados nesse caso apenas como mais um artefato produzido pelo processo visando garantir a detecção de erros antes da liberação da versão final. Nos processos ágeis, principalmente o XP, não existe todo esse aparato documental, apenas as histórias contadas pelos usuários. O papel dos testes nesse caso é de suma importância para o sucesso da metodologia ágil, visto que, após os testes, até mesmo as histórias são descartadas.

Iniciar aplicação com última edição

A aplicação começa trazendo o último documento com o qual o usuário estava trabalhando.

Ou

Como um usuário, eu quero iniciar uma aplicação com a última edição.

Fechar aplicação

Como um usuário fechando a aplicação, eu quero ser perguntado para salvar se eu tiver feito qualquer alteração em meus dados desde a última gravação.

Ou

Ao fechar a aplicação, o usuário é solicitado a salvar (quando QUALQUER COISA mudou nos dados desde a última gravação!).

Ou

Como um usuário fechando a aplicação, eu quero ser solicitado a salvar qualquer coisa que mudou desde a última gravação para que eu possa preservar um trabalho útil e descartar trabalho errôneo.

Entrar com as despesas

O consultor irá entrar as despesas despesas em um formulário de despesas. O consultor entrará com itens no formulário como tipo de despesa, descrição, quantidade, e quaisquer observações sobre a despesa. A qualquer momento, o consultor pode fazer qualquer uma das seguintes opções:

(1) Quando o consultor terminar de digitar a despesa, o consultor irá "Enviar". Se a despesa for menor que cinquenta (<50), a despesa irá diretamente para o sistema de processos.

(2) No caso em que o consultor não tenha terminado de entrar com a despesa, o consultor pode querer "Guardar para mais tarde". Os dados inseridos devem, então, ser mostrados em uma lista (fila) para o consultor com o estado de "Incompleta". (3) No caso em que o consultor decidir limpar os dados e fechar o formulário, o consultor irá "Cancelar e sair". Os dados introduzidos não serão salvos em parte alguma.