User Story — Teoria e prática

User Story — Teoria e prática

É comum existirem evoluções no ciclo de vida de um software. Essas evoluções podem ser pequenas, médias ou grandes, dependendo da solicitação do usuário. Saber lidar com elas nem sempre é uma tarefa fácil, é necessário ter habilidades que auxiliem a converter uma comunicação verbal ou escrita, em requisitos de sistema objetivos aptos a serem transformados em código.

Uma boa técnica utilizada em ambientes ágeis são as User Stories. Quando bem utilizadas, de forma simples e objetiva, elas podem auxiliar mesclando em um único artefato atributos úteis em todas etapas do processo de desenvolvimento. Martin Fowler escreve sobre o assunto em UserStory, citando o mnemônico INVEST, melhor descrito em INVEST in Good Stories, and SMART Tasks.

Em busca de unir a teoria com a prática, nesse texto apresento um exemplo de User Story aplicada em uma demanda de desenvolvimento comum encontrada no dia a dia de equipes de desenvolvimento.

Necessidade do usuário

O processo se inicia a partir da necessidade do usuário. O ator principal é o gerente de vendas, que gostaria de apresentar para o seu supervisor quais são os vendedores que mais geraram lucro no mês. Para esses vendedores, gostaria de ter mais detalhes sobre os dados de contato, para assim enviar bons feedbacks.

Por ser um relatório muito utilizado pela empresa, o gerente também gostaria de realizar algumas edições no resultado final do relatório. São em casos específicos, por exemplo: colocar algumas palavras em negrito; marcar em amarelo pontos importantes do relatório; em algumas circunstâncias, remover informações desnecessárias.

Após diversas conversas entre o analista de negócios e o gerente de vendas, ambos chegaram em algumas conclusões sobre a solicitação de evolução do sistema. São elas:

• Informar o vendedor responsável nas informações de cadastro da venda;
• Visualizar no relatório de análise de vendas: quem foi o vendedor responsável; e-mail; telefone; e número da venda;
• Gerar o relatório utilizando no formato DOC.

Em uma abordagem tradicional, toda a necessidade do cliente seria codificada, revisada, testada, validada e liberada de uma vez. Isso não é errado, porém é possível otimizar o processo, dando ao usuário final a opção de usufruir com antecedência de entregas parciais do resultado. Nesse sentido, uma opção é dividir a solicitação em histórias menores.

Quebra em histórias menores

Existe mais de uma opção para realizar a divisão em histórias menores, a escolhida foi em duas histórias como demonstrado a seguir:

1. Informar o vendedor responsável nas informações de cadastro da venda e visualizar no relatório de análise de vendas os dados: vendedor responsável; e-mail; telefone; e número da venda;
2. Gerar o relatório no formato DOC.

É possível também gerar três histórias, isso não foi feito pois existe uma leve dependência nos dois primeiros itens da solicitação.

Ciclo de desenvolvimento

Esta divisão permite que as demandas sejam independentes, o que possibilita que ambas avancem no processo sem que uma interfira na outra. Os quadros abaixo demonstram o fluxo de desenvolvimento das história. Um bom exemplo pode ser visto no quadro 5, a história 1 não passou nos testes tornando necessário realizar pequenos ajustes. Já no quadro 6, a história 2 foi entregue para o usuário final sem que o erro encontrado na primeira história interferisse em seu fluxo.

Conclusão

A divisão de uma solicitação em histórias menores pode ser feita de diversas maneiras. Não existe uma forma correta, sempre vai depender do cenário naquele momento. Em algumas ocasiões ter histórias pequenas é bom, porém em outros momentos pode gerar mais trabalho que o necessário. Neste exemplo, trabalhar com histórias menores permitiu explorar os itens Independent e Valuable do INVEST. O uso de histórias independentes gerou mais flexibilidade na tomada de decisão. Como pontos positivos, é possível citar:

• Revisão de código e teste de cada história pode ser feito em momentos diferentes;
• Revisão de código e teste de cada história pode ser feito por pessoas diferentes;
• O contexto de cada uma das histórias é menor, sendo assim possível um foco mais específico;
• Possibilidade de programar utilizando duas branches diferentes;
• Falhas e bugs em uma das história não geram impactos na outra;
• O usuário final pode receber antecipadamente entregas parciais da sua solicitação;
• Ao entregar em partes uma demanda é possível negociar prazos e prioridade junto ao cliente, o que permite satisfazer as principais dores mais rápido e negociar prazos maiores para entregas mais demoradas ou de menor maior;
• É mais fácil separar trabalho dentro de um time, pois histórias de uma mesma solicitação se tornaram independentes.