fev 042016
 

Uma História de Usuário (User Story) é a descrição de uma funcionalidade percebida com “valor” para o usuário ou para quem encomenda o software (ou sistema).

Uma História de Usuário é composta por 3 aspectos:

- a descrição escrita da História, utilizada para planejamento e como “lembrete” do que deve ser feito pelo time;

- diálogos a respeito da História, que servem para detalhamento e registro;

- testes, que transmitem e documentam os detalhes que serão utilizados para determinar quando uma História estará completa.

Os 3 componentes acima são, respectivamente, tratados como Card, Conversation e Confirmation na  conceituação original (em inglês) sobre Histórias de Usuário.

Um Card é uma representação dos requisitos (ao invés de ser uma “documentação” de requisitos). Portanto, enquanto o Card contém o título da História, o verdadeiro detalhamento ocorre nas Conversations e é registrado através da Confirmation.

 

Identificando e Detalhando Histórias

Histórias surgem, literalmente, ao questionar os Usuários e Stakeholders sobre o que eles querem fazer no/com o sistema; ou para que eles precisam do sistema.

Recomenda-se uma escrita padronizada, tanto pelo aspecto de comunicação quanto pela produtividade ganha através da uniformidade:

 

Como [usuário/papel], quero [meta] para que eu possa [motivo]

A título de exemplo, as duas histórias acima (H001 e H002) poderiam ser, respectivamente, desdobradas em:

H001 – Como Gerente de RH, quero cadastrar vagas para que eu possa entrevistar candidatos

H002 – Como Candidato a uma vaga, quero pesquisar vagas para enviar meu currículo

 

O próximo passo consiste em identificar e detalhar um ou mais critérios de aceitação para cada História de Usuário, de modo que fique claro para o time o que será testado, com visão de negócio

 

Boas Práticas

O termo INVEST é utilizado para apresentar seis diretrizes que representam algumas práticas recomendadas quando se trabalha com Histórias:

Princípio Detalhamento
Independent (independente) Buscar a Independência significa que boas Histórias de Usuário são independentes entre si. A existência de dependências entre Histórias pode levar a problemas de planejamento, estimativas e testes.
Negotiable (negociável) Mais do que um “contrato final”, cada História funciona como um lembrete e registro do que é valorizado e precisa ser feito; com esta mentalidade, toda História é negociável.
Valuable (valorizável ) Toda História de Usuário deve carregar consigo a percepção do valor que agrega para Usuários e/ou Stakeholders.

Evite Histórias que agregam valor apenas para os desenvolvedores. Por exemplo, ao invés de considerar uma História com foco na linguagem de programação a ser utilizada, enfoque o benefício (o valor) de uma determinada escolha de tecnologia e procure sempre maximizar Histórias que sensibilizem o Usuário/Stakeholder acerca das funcionalidades percebidas com importância para o negócio.

Estimable (estimável) Boas Histórias de Usuário contém as informações que sejam suficientes para uma estimativa de tamanho (em pontos) ou esforço (em horas); existe, portanto, um desafio: identificar qual o nível de detalhamento suficiente nas informações da História, porque da mesma forma que uma História muito superficial prejudica a estimativa, o mesmo pode ocorrer com uma História que tenha excesso de informações.
Small (sucinta) Sucinta (ou pequena): Histórias muito “grandes” são geralmente chamadas de Épicos, e a decomposição destes Épicos em Histórias menores favorece a compreensão e comunicação do time.

Sempre que necessário agrupe Histórias em Épicos (para efeito de organização) ou divida um Épico em suas Histórias menores (para efeito de entendimento, planejamento e priorização)

Testable (testável) Histórias devem ser escritas de tal forma que seja possível derivar os detalhes dos testes que devem ser planejados (para futura execução) e que irão, em última análise, servir para determinar se a História está pronta (ou não) para ser entregue.

 

Épicos, Temas e Histórias

 

Ao trabalhar com Histórias de Usuário, um dos desafios é definir a granularidade apropriada, que favoreça a compreensão, comunicação, planejamento, testes, implementação e validação.

Algumas Histórias de Usuário podem ser muito grandes, outras muito complexas, outras muito pequenas.

Histórias muito grandes são Épicos e a decomposição destes Épicos em Histórias menores favorece a compreensão e comunicação do time.

A diferença entre um Épico e uma História se da pela granularidade, enquanto  o Épico representa um processo composto por várias necessidades que precisam ser atendidas, a História é atômica, representa uma necessidade que compõe o Épico.

Um Tema, por outro lado, é um artifício de agrupamento de Histórias que se correlacionam, por exemplo, por tratarem de um mesmo assunto. A organização das Histórias por Temas facilida a contextualização das Features do sistema.

Portanto lembre sempre durante reuniões/workshops/entrevistas de verificar o melhor tratamento dado a cada História de Usuário para garantir que o tamanho, bem como o conteúdo da História, esteja adequado.

A decisão final em relação ao tamanho apropriado baseia-se no time, suas capacidades e a tecnologia em uso, porém é possível utilizar algumas técnicas e recomendações, tais como:

  • Identifique “Histórias Compostas” e divida-as em Histórias atômicas: uma “História Composta” geralmente é representação de “N” Histórias de tamanho menor, portanto deve ser dividida, dando origem a Histórias pequenas, porém ainda com valor.
  • Identifique “Histórias Complexas” e analise se a divisão em Histórias menores é o suficiente, ou se existe, por exemplo, uma “confusão” entre Histórias e Regras de Negócio, que indicam políticas, procedimentos, fórmulas, cálculos e condições definidas no processo de negócio (inúmeras vezes por razões regulatórias, alheias até ao desejo do usuário/stakeholder). Deste modo, quando uma História for complexa porque envolve regras de negócio, fatore o conteúdo, deixando a História sucinta e indicando a qual(is) regra(s) de negócio aquela História se relaciona.
  • Identifique variações e oposições da História e registre-as: tipicamente, durante reuniões/ workshops/entrevistas os usuários/clientes “lembram” do que é principal, mas podem se esquecer de debater variações no processo de negócio que precisem ser contempladas no sistema ou até mesmo situações que indicam o oposto do comportamento alcançado por uma funcionalidade principal.

 

 

 

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>