Cartão de História – Invest

Oi pessoal, eu vou escrever sobre Cartões de História e a sua estruturação com conceito INVEST. Existe na web vários post sobre este assunto, também temos este assunto muito bem tratado no livro de Cartão de História de Mike Cohn (Eu recomendo a leitura deste livro).

INVEST é igual a:
Independent | Independente
Negotiable | Negociável
Valuable | Avaliável
Estimatable | Estimável
Sized Appropriately | Dimensionada apropriadamente
Testable | Testável

No processo de analise de sistemas, quando estamos levantando as informações referentes “ao que tem que ser feito” no sistema, estamos identificando os requisitos necessários para a completude do nosso projeto.

Estes requisitos identificados podem ter dentro de si, uma quantidade de outros requisitos implícitos. Também podemos ter requisitos pequenos, que já permite um entendimento e estimativa do mesmo.

Estas discrepâncias entre os requisitos podem ser normalizadas com a técnica de INVEST. Mas normalizar não é a única responsabilidade do INVEST, ele nos ajudar a entender melhor os requisitos, a realizar estimativas mais assertivas, definir critérios de aceite, definir o valor agregado do requisito ao negócio e priorizar o que realmente deve ser entregue ao nosso cliente.

Vamos agora utilizar o termo História. História é como vamos organizar o nosso requisito, onde ela permite identificar quem está realizando a ação, a funcionalidade desejada e o valor de negocio que se espera com a execução desta funcionalidade. O termo História vêm do convite que esta estrutura nos leva ao dialogo, o que permite o nosso trabalho de analise de sistemas.

Como um [usuário], gostaria de [funcionalidade] para [valor do negócio].

Quem? O que? Por que?

Independente

Devemos buscar a independência entre as Histórias, isto é, não termos correlação direta entre eles. Fica mais fácil realizar a estimativa focada a uma História do que realizar uma estimativa em um conjunto de Histórias. O nosso erro vai ser maior quando temos que estimar um grupo de Histórias correlacionadas.

Também fica difícil priorizarmos Histórias correlacionadas, um dos itens que fazem parte deste grupo de História necessariamente não tem que ser entregue junto com a História mais importante para o nosso cliente, mas como existe um acoplamento forte entre as Histórias, não temos (ou fica muito difícil) entregar apenas uma parte do que deve ser feito.

Um exemplo é forma de pagamento de uma compra. Podemos pagar com cartão de credito, boleto bancário, dinheiro, cheque, com uma composição de meios de pagamento (dinheiro + cheque) e assim por diante.

Está História esta muito grande e possui dentro dela varias outras Histórias. Podemos refinar colocando as Histórias assim:
Pagamento com Cartão de Credito
Pagamento com Dinheiro
Pagamento com Cheque
Pagamento em Boleto Bancário

Mas ainda temos uma quantidade grande de tipos de Cartão de Credito, vamos melhorar mais um pouco...
Pagamento com Cartão de Credito Visa
Pagamento com Cartão de Credito Master

Agora a História de pagamento de uma compra chegou no nível de independência. Eu posso priorizar qual a forma de pagamento mais importante para o meu cliente na minha próxima entrega de produto. Devemos repetir este processo de refinamento para as demais formas de pagamento que o nosso cliente deseja.

Negociável

Uma Historia no seu processo de entendimento (analise de sistemas) gera um conjunto de conversas, conversas são anotações que realizamos na História para saber “o que temos que fazer” para deixar a História aderente as necessidades do cliente.

Estás conversas anotadas geram software, isto é, funcionalidades necessárias a serem implementadas no nosso sistema. Mas nem todas as necessidades (funcionalidades) tem que ser realizadas ao mesmo tempo, permitindo uma negociação com o cliente, onde esta negociação determina o que vai ser entregue e o que pode ser realizado em outro momento do projeto.

Um exemplo é a nossa tela de login. A nossa tela tem que ter o campo para a entrada do username e a entrada da senha. Mas no processo de entendimento da História passamos a buscar a completude da História, com informações de quantas vezes o usuário pode tentar se logar no sistema, se existe uma funcionalidade de recuperar a senha, algum tipo de notificação por e-mail, mensagens de erro, dispositivos de ações, como um botão para confirmar o usuário e senha, e assim por diante.

Passamos a realizar o entendimento da História junto ao nosso cliente, anotamos todas as suas necessidades e expectativas, estas anotações vão ser transformadas em funcionalidades implementadas e passamos a negociar quais destas funcionalidades devem ser implementadas.

Valiosa

Histórias devem gerar valor ao cliente, uma boa técnica de buscarmos este valor é o próprio cliente escrevendo as suas Histórias. Nem sempre é possível o cliente escrever as suas próprias Histórias, não importando no momento o que leva a está impossibilidade.
Mas valor é visto nos olhos de quem paga para usar e devemos se necessário colocar óculos no cliente, para que ele possa enxergar o valor de retorno das Histórias que ele está solicitando.

É um processo demorado, mas o retorno vale a pena, ensinarmos nossos clientes a escrevem suas Histórias. Lembrando sempre que podemos ajudá-lo a escrever.

Estimável

Quando chegamos no ponto de realizar uma estimativa é importante que as nossas Histórias já estejam independentes e negociadas. Se eu não tenho mais dependência entre Histórias minha estimativa vai ser mais assertiva e sem as funcionalidades desnecessárias para a entrega facilita e melhora cada vez mais a estimativa.

Estamos estimando Histórias com suas funcionalidades que realmente agregam valor aos “Olhos” do nosso cliente.

Pequena

Não existe uma formula mágica para determinar o tamanho que as nossas Histórias devem ter, mas este tamanho se normaliza com o processo de levantamento de Historias e analise das mesmas.

Um tamanho determinado em um projeto, necessariamente não vai ser o mesmo em outro projeto.
Devemos tomar cuidado em não confundir Histórias com uma funcionalidade a ser implementada, um exemplo é uma mensagem de erro do sistema, que faz parte de uma História.

Testável

Uma boa técnica de descobrir como a nossa História deve se comportar é realizar testes de validação da História.

Conversas mais Testes de Aceitação fecham um ciclo de entendimento da História. Qualquer implementação a mais nesta História, que não foi identificada nas conversas ou testes não deveria ser realizada.

Exemplo:
[Cartão de História]
Como um cliente, quero que o sistema mostre o valor da postagem, para que eu possa saber quanto vai ser a taxa de entrega.

[Testes] - Template: [ação] [resultado] [objeto]
Mostrar valor da postagem de correio para vendas realizadas na mesma cidade
Mostrar valor da postagem de correio para vendas realizadas no mesmo estado
Mostrar valor da postagem de correio para vendas realizadas em estados diferentes
Mostrar valor da postagem de correio para vendas internacionais
Mostrar valor da postagem de correio para vendas isentas de taxa de entrega
Calcular valor da postagem de correio para cada produto existente no carrinho de compras
Mostrar mensagem de erro para cep´s inválidos
Mostrar mensagem de erro para cep´s vazio



Abraço a todos,

Abu