As histórias de utilizadores são ferramentas que tiveram origem na Programação Extrema e tornaram-se a forma de facto como as equipas Agile documentam e recolhem os seus requisitos. Há muito escrito em histórias de utilizadores (link, link, link), por isso vou apenas falar sobre o que considero importante na escrita de boas histórias, uma vez que hoje vejo um MUITO de más histórias por aí.
Para aqueles que não sabem, as histórias são um artefacto leve que nos permite tanto captar as necessidades do negócio como planear o trabalho. São tipicamente escritas em cartões de índice (sim…pequenos cartões 3×5 ou 4×6) na língua do negócio ou do cliente. Com histórias de utilizadores, só escrevemos o suficiente para captar as necessidades do utilizador e não mais. Tendemos a ver as histórias não como uma especificação completa dos requisitos, mas sim como suportes para conversas posteriores entre os criadores e a empresa.
Quando usadas correctamente, a falta de detalhes de uma história de utilizador fornece-nos uma grande utilidade – podemos usar o mesmo documento para falar de um requisito de alto nível, ampliar os detalhes de implementação e saltar para fora, tudo no decurso de algumas frases. Depois, uma vez terminada a conversa sobre requisitos, podemos considerar o risco, identificar dependências e criar um plano de projecto sem nunca ter de pousar o cartão de índice. Uau!! Não conheço outros artefactos de requisitos lá fora que nos permitam tal utilidade.
Todos os anos as pessoas que são realmente bem sucedidas com histórias têm-se estabelecido em alguns pontos comuns encontrados em todas as histórias:
- Papel: quem, ou o quê, vai utilizar esta funcionalidade?
- Funcionalidade (ou capacidade): o que é que a Equipa vai entregar, ou acrescentar, depois de terminarem o seu trabalho?
- Valor: porque é que o negócio quer sequer esta funcionalidade? Que impacto terá para o negócio?
- Critérios de Aceitação: como saberemos se esta funcionalidade é feita?
- Estimativa: quanto pensa a Equipa que esta funcionalidade irá custar?
IMO, para que uma história seja considerada completa tem de ter TODAS as características descritas acima. Descobri que quando as pessoas têm dificuldade em definir todas as características, as histórias não são o que eu chamo maduras, ou seja, não foram suficientemente bem pensadas para poderem ser utilizadas pela Equipa. Para além destas características, as histórias também devem seguir os critérios INVEST (este grande artigo de J.B. Rainsberger também fala sobre INVEST).
Mike Cohn escreveu um grande livro sobre histórias de utilizadores. Infelizmente, por toda a bondade do livro, as pessoas parecem ter-se concentrado no único pedaço de lixo do livro – o modelo de história de utilizador. No seu livro, Mike oferece um modelo que algumas equipas acharam útil para escrever histórias e a partir daí este modelo tem sido a fonte de tantas más histórias que já não lhe vou dar mais tinta (ou bocados). O que me oponho ao modelo é que ele faz com que as pessoas deixem de pensar, uma vez que preenchem mecanicamente o papel, a característica e o valor e omitem critérios de aceitação e estimativa (presumivelmente porque estão ausentes do modelo). Quando vejo as pessoas lutarem com histórias, é porque estão a tentar interferir com o seu negócio em algum modelo que ajudou alguma equipa sem nome (que provavelmente já nem sequer usa este modelo) há cinco ou seis anos e – surpresa – não se encaixa onde estão agora.
Há um processo de pensamento que precisa de ocorrer antes de se escrever uma única história. Os passos que tenho tendência para ver as pessoas que completam com sucesso a escrever histórias estão listados abaixo. Por favor tenha em mente, enquanto estes passos são lineares no meu posto, pode-se saltar para trás, para a frente e saltar à volta, pois faz sentido. O objectivo é ter respondido a estas perguntas quando tiver terminado a exploração da sua história de utilizador.
- Quais são os papéis (ou utilizadores) que irão utilizar o seu sistema?
- Quais são as suas necessidades? Como é que o produto os ajuda a conseguir isso?
- Que características (ou capacidades) pretende fornecer estes papéis?
- Porquê estas características são valiosas para o negócio? Que tipo de resultados comerciais podemos esperar destas características?
- Quais são as prioridades destas características? Fizemos já uma promessa de entregar algumas?
- como é que se sabe se estas características são feitas?
Finalmente, as pessoas têm tendência a querer escrever muitos detalhes na frente do cartão da história. Tenho duas sugestões para estas pessoas. Primeiro, utilizar cartões mais pequenos – na verdade. As histórias de utilizadores NÃO são documentos de especificações ou requisitos. São apenas cartões de índice que capturam as necessidades do utilizador e lembretes de que temos de capturar esses detalhes de implementação mais tarde. Se estiver a tentar colocar cada vez mais num cartão de índice, isso pode ser sinal de que pode precisar de especificações ou algum tipo de documentação de desenho, para além das histórias de utilizadores. Em segundo lugar, os tipos de detalhes que as pessoas estão a tentar anotar são, na realidade, critérios de aceitação. Empurrando esses detalhes para os casos de teste, mantemos a história na língua do negócio e mantemos o foco na característica e valor que a sua equipa está a fornecer.