Escrevendo boas histórias de usuário

em Metodologias Ágeis.

O que é e para que servem histórias de usuário foi explicado em um post anterior. Mas faltou comentar sobre como se escreve uma boa história. Segundo Mike Cohn, autor de User Stories Applied, uma história bem escrita obedece as características do acrônimo INVEST – Independente, Negociável, Valiosa para o cliente ou usuário, Estimável, Pequena (Small em inglês) e Testável.

Independente

  • Um usuário da loja virtual consulta um produto por palavra-chave.
  • Um usuário da loja virtual consulta um produto por categoria.

Essas histórias podem apresentar um problema no momento da estimativa. Ambas provavelmente usam a mesma infra-estrutura da aplicação (o código que faz uma busca no banco de dados, por exemplo), tendo como única diferença o critério da busca. Dessa forma os desenvolvedores vão dizer que a estimativa vai mudar dependendo da ordem em que as histórias serão implementadas, ou seja, depois de implementada a primeira busca, a segunda será mais fácil. Esse tipo de situação prejudica bastante o planejamento e o desenvolvimento dos sprints, já que passa a haver a necessidade de se controlar essas dependências.

Seria melhor se essas histórias fossem combinadas ou se a parte comum entre elas fosse colocada em outra história. Nesse caso os desenvolvedores poderiam alegar que feita a busca por um critério a outra seria tão fácil que nem compensaria manter duas histórias separadas:

  • Um usuário da loja virtual consulta um produto por palavra-chave ou por categoria.

Ou então, caso eles considerassem que vale a pena ter duas histórias, elas poderiam ser:

  • Um usuário da loja virtual consulta um produto por um critério qualquer (palavra-chave ou categoria).
  • Um usuário da loja virtual consulta um produto por um segundo critério (palavra-chave ou categoria).

Negociável

  • Um usuário da loja virtual opta por embrulhar um ou mais dos itens comprados para presente, escolhendo se o papel é azul ou vermelho. Ele também opta por enviar um cartão, que pode ter uma mensagem padrão ou personalizada, sendo que ele paga R$ 0,10 a mais nesse caso.

Essa é uma história com detalhes demais. Um dos problemas de se ter um excesso de detalhes na história é que ela não é uma especificação de requisitos, mas sim uma promessa de conversa futura entre desenvolvedores e clientes. Aí existe o risco de os desenvolvedores acharem que têm todas as informações de que necessitam e não conversar com o cliente. Além disso, parece que essa história pode ser dividida.

Mas o maior problema desse nível de detalhe é que a história deixa de ser negociável, o que é importante para se garantir que a equipe sempre entregue algo de valor para o cliente ao final de um sprint. O ideal é que histórias tenham escopo variável, para que, conversando, cliente e equipe cheguem a um acordo do quão “profundamente” ela será implementada. Assim, a história poderia ser melhor escrita:

  • Um usuário da loja virtual opta por embrulhar itens comprados para presente, escolhendo o papel e a mensagem do cartão.
  • Um usuário da loja virtual que opte por enviar um cartão com mensagem personalizada paga um adicional por isso.

Assim, caso os desenvolvedores percebam que não vão conseguir entregar a história completa, podem sugerir para o cliente que a escolha de mensagens personalizadas não seja implementada. Nesse caso, o cliente cria outra história para o futuro:

  • Um usuário da loja virtual escolhe entre a mensagem padrão ou uma mensagem personalizada quando decidir embrulhar um item para presente.

Valiosa para o cliente ou usuário

  • O sistema suporta no máximo 50 conexões simultâneas com o banco de dados.

O problema que essa história apresenta é o de não ter valor para o cliente, já que ele não tem como priorizá-la com relação às outras – tente imaginar a dificuldade que ele teria ao tentar comparar essa com as apresentadas nos tópicos anteriores. Ela poderia ser re-escrita de forma que ele possa entender melhor do que ela se trata e quais as conseqüências para o seu negócio:

  • 50 usuários fazem compras na loja virtual simultaneamente.

Um outro item a considerar é que histórias podem ser valiosas tanto para o cliente quanto para o usuário final. O último exemplo tem valor para o cliente, que é quem paga pelo projeto e que quer que muitos usuários consigam utilizar o seu site simultaneamente, pois isso significa um lucro maior para ele. Mas as outras histórias citadas nesse post, começadas por “Um usuário …”, possuem valor direto para o comprador de produtos pelo site.

Estimável

  • Um usuário da loja virtual recebe um e-mail caso a operadora de cartão crédito recuse o pagamento.
  • Um usuário da loja virtual vê no máximo 10 resultados de uma consulta por página.

Fazer a estimativa para o primeiro caso é fácil: se os desenvolvedores não sabem como operadoras de cartão crédito funcionam, ou seja, não entendem do domínio, eles simplesmente perguntam para o cliente, que deve estar presente na reunião de planejamento e deve saber responder à pergunta.

Já o segundo caso é mais complicado: se nenhum dos desenvolvedores implementou paginação em uma aplicação web eles não têm como estimar e também não têm para quem perguntar. Nesse caso a história não deve entrar no sprint sendo planejado, mas sim uma outra que representa o que Extreme Programming chama de spike: uma mistura de estudo e testes com a tecnologia para entender como se faz alguma coisa. Com esse conhecimento será possível estimar melhor a história para o sprint seguinte.

Um outro motivo que pode dificultar o processo de estimar uma história é o seu tamanho, o que está relacionado ao próximo tópico.

Pequenas (Small, em inglês)

  • Um usuário da loja virtual compra produtos.

O exemplo acima é o que se costuma chamar de épico, que nada mais que uma história grande demais. Histórias assim dificultam muito o processo todo, desde as estimativas até a criação de tarefas para a sua implementação. Em um caso como esse não há muita opção que não dividir a história em outras.

Normalmente uma história é considerada grande por ter trabalho demais envolvido. Nesse caso, o próprio cliente ajuda a equipe a dividir a história. A história acima poderia ser transformada em:

  • Um usuário da loja virtual adiciona itens ao carrinho de compras.
  • Um usuário da loja virtual fecha o pedido.
  • Um usuário da loja virtual calcula o frete da sua compra.
  • Um usuário da loja virtual escolhe a opção de pagamento.
  • Um usuário da loja virtual adiciona os seus dados cadastrais ao site.
  • etc.

Raramente uma história é considerada pequena demais, mas isso pode ocorrer. Nesses casos, é uma boa idéia agrupar várias dessas histórias em uma única. Um exemplo de situação em que isso pode ocorrer é um grupo de melhorias relativas a texto e cores em algumas páginas do site.

Testável

  • Um usuário da loja virtual espera muito pouco para ir de uma página a outra.

Essa é uma história que não tem como ser testada e, portanto, o cliente não tem como dizer se a solução dada pelos desenvolvedores é satisfatória. Além disso, testes automatizados são importantíssimos. Se a história for escrita dessa forma isso nunca acontecerá. Dessa forma, ela precisa ser mais objetiva:

  • Um usuário da loja virtual espera no máximo 7 segundos para ver uma página após tomar uma ação no site.

Essas são características que quando presentes nas histórias tornam muito mais simples as estimativas e o planejamento. Mas para funcionar de fato, tanto desenvolvedores quanto cliente devem conhecê-las e se preocupar com elas. Para isso, uma sugestão: uma apresentação rápida para todos os envolvidos antes de começar um projeto mostrando o que é necessário para se escrever boas histórias.

Você também pode gostar