Sua história é uma hipótese… e ai?

Por Anselmo Eduardo Martelini Junior

---

Algo que recentemente tem ficado claro para mim é que as abordagens padronizadas de desenvolvimento de software ágil parecem partir do princípio que o PO, ou o representante do cliente, tem conhecimento do mercado suficiente para priorizar as histórias e direcionar o desenvolvimento.

Em decorrência disso, as histórias são escritas de forma a atender somente o desenvolvimento, ou seja, elas não apoiam o aprendizado validado real e, por consequência, não propiciam a retroalimentação do backlog com as lições aprendidas.

Com a popularização das abordagens de aprendizado rápido, principalmente influenciadas pelo famoso livro Lean Startup, de Eric Ries, o PO onisciente parece, para mim, muito longe da realidade.

Abaixo descrevo como as histórias são escritas comumente e, na sequência, como poderiam ser descritas para direcionar a validação do real sucesso (ou não), potencializando o aprendizado.

A escrita das histórias

Existem muitas formas de se escrever os requisitos de um sistema, mas nos times de desenvolvimento que adotam Agile ou Lean é muito comum o uso de histórias.

Histórias são uma forma simples de expressar o que o solicitante deseja do sistema, e normalmente têm a perspectiva de quem vai utilizar aquela funcionalidade. Usando o clássico exemplo:

Como <tipo de usuário>,
Quero <objetivo>
Para <esta razão>

Temos como exemplo:

Como analista de crédito,
Quero ter acesso ao cadastro de um cliente no Serasa,
Para poder avaliar se o cliente é um bom pagador

O objetivo principal de uma história é servir como o ponto inicial de discussão [um convite à conversa] entre os envolvidos. Sendo “suficientemente incompleta” a história faz com que haja comunicação constante entre negócio e desenvolvimento com objetivo de concluí-la com êxito. Não busca, todavia, ser completa e ter todos os requisitos mapeados e detalhados desde o início.

Uma história também pode conter critérios de aceite, que detalham alguns comportamentos esperados que o solicitante deseja para a funcionalidade, como:

• Garantir o mesmo comportamento no IE e no Safari
• Abrir o calendário sempre no formato americano
• Exibir o gingerbread zumbi como easter egg 🙂

Algumas equipes vão além e capturam nos critérios de aceite o comportamento esperado para o sistema de uma forma que é facilmente transportado para ferramentas de testes automatizados, criando uma comunicação direta e consistente entre negócio e time (BDD):

Critério: Navega para a página de concursos culturais
Dado que a mensagem de limite de cupons excedido é exibida
Quando o usuário tenta navegar para a página de concursos culturais
Então ele é direcionado para a página de concursos culturais

Todos esses critérios e detalhes apresentados acima, entretanto, levam uma história somente ao estado em que está pronta para ser lançada, mas faltaria verificar ainda se as hipóteses que levaram ao seu desenvolvimento foram validadas, e se o critério de sucesso foi atingido.

Validando as hipóteses das histórias

Cada história carrega consigo um conjunto de hipóteses, muito mais que certezas, e por isso cada uma deve ser encarada como uma oportunidade única de aprendizado e validação de conceitos. Desta forma, creio que a própria escrita deva ser revista, deixando claro quais as hipóteses por detrás e quais os critérios de sucesso.

Pesquisando na internet encontrei um ótimo exemplo de como escrever histórias com este objetivo em mente:

Nós acreditamos que:
construindo a funcionalidade <nome da funcionalidade>
para o público <público alvo proposto>
atingiremos <resultados esperados>

Saberemos que fomos bem sucedidos quando tivermos <sinal do mercado esperado>

Este exemplo foi escrito por Jeff Gothelf, autor do muito aguardado e recém lançado Lean UX: Applying Lean Principles to Improve User Experience.

Obviamente mudar a escrita da história, por sí só, não altera a forma de pensar e trabalhar de uma equipe, mas esta maneira de escrita abre muitas possibilidades para que todo o time de desenvolvimento participe ativamente e profundamente do processo de entendimento do negócio. O foco se afasta do desenvolvimento de histórias para o desenvolvimento de um produto, e PO se força a pensar em cada história não apenas como uma nova funcionalidade.

Como ainda não li o livro, paro por aqui, e espero em breve poder escrever mais sobre o assunto.

E no seu time, como os requisitos são passados para o desenvolvimento? Você acredita que todas as histórias são oportunidades de aprendizado e validação de hipóteses?