Dicas para escrita de histórias de usuário

No post anterior eu falei um pouco sobre a história das histórias de usuário, seu template e sua finalidade. Hoje falo um pouco sobre algumas dicas que juntei por aí sobre como escrever boas histórias.

Ao iniciar o seu backlog, escrevendo as suas primeiras histórias, comece com histórias que tenham alguma meta envolvida, algo que realmente entregue valor para o cliente. É muito interessante vermos como as coisas são nas universidades. No meu tempo (idoso mode: ON) quase que invariavelmente se ensinava a fazer um sistema de locadoras. Com poucas variações, a grande maioria das faculdades naqueles tempos faziam o mesmo. Nós, como inocentes aprendizes íamos ali, criando novos softwares começando, quase sempre, pelos cadastros, quando o que realmente entrega valor numa locadora é a função de locar. Cadastrar os clientes, as mídias, todo o resto é acessório para o ato de locar. Vejam o quanto isso é a inversão desse valor, o quanto estamos acostumados a entregar o que nos parece mais confortável do nosso ponto de vista. Para o cliente, o meu cliente como desenvolvedor, ter todos os dados daquele blue-ray é importante, mas o mais importante é a locação. Com isso, nasciam cadastros com campos sem necessidade, mesmo cadastros inteiros sem necessidade aparente. Começar pelas histórias que são importantes te dá a possibilidade de validar os acessórios.

Ao dividir as suas histórias, lembre-se que uma história é uma entrega de valor. Para que uma história atenda a isso, ela não pode ser algo que vai entregar somente uma camada do sistema. Histórias que alteram somente o visual, somente o banco, ou somente a regra de negócio devem ser observadas com muita atenção, buscando sempre a entrega de valor. Embora existam situações nas quais realmente uma mudança de design entregue valor por si só, muitas vezes já vi pessoas criando histórias somente para adicionar campos novos no banco de dados, sem uma explicação do porquê. Pense nas histórias como uma fatia de bolo e não como uma camada dele. Uma boa história de usuário vai entregar um pedaço de cada camada do bolo, tal qual uma fatia.

Outra dica muito importante é colocar os critérios de aceitação no cartão da história. Isso ajuda ao cliente a entender os limites da tarefa e ajuda o desenvolvedor a entender quando ele realmente a completou. Eles devem ser claros o bastante para que sejam entendidos pelos envolvidos. Os testes podem ser escritos em qualquer formato que os leitores concordem como sendo conveniente, cenários, tabelas-verdade, o que for interessante. O fundamental nesse momento é que os critérios nesse momento sejam testáveis, sejam validáveis de maneira simples. No fim das contas eles certificam que as história implementadas correspondem ao que o cliente necessita. Sempre que possível, automatize o processo de validação das histórias. Utilizando uma combinação de integração contínua e testes funcionais, algo como Jenkins e JUnit (para Java), os resultados podem ser realmente potencializados.

Embora todo o time, até mesmo o cliente possam escrever histórias e ajudar na formação do backlog, a responsabilidade por escrever as histórias, por gerenciar o backlog completo é o Product Owner, quando estamos falando de Scrum. Observe que o uso de Histórias de Usuário não é algo de uma única metodologia, mesmo quem costuma usá-las.

São trabalhadas e amadurecem à medida que a análise progride. Não se deve ter todo o backlog escrito no início do trabalho. Isso seria considerado um desperdício. Uma metodologia ágil, ao menos a maioria, prega que isso seria um desperdício, pois seria como tentar adivinhar tudo o que o software teria logo no início na coleta de requisitos. Ter um ou dois sprints ou ainda uma ou duas semanas bem detalhadas já é o suficiente para um bom andamento do ciclo de trabalho

Para finalizar, o que acontece com as histórias após terem sido feitas e validadas pelo cliente? Bom, caso você queira manter alguma rastreabilidade, para fins de nostalgia ou ajudar a se lembrar do que foi entregue pode manter uma cópia das histórias. Mas elas não foram pensadas para isso. Foram pensadas como uma ferramenta para execução do trabalho e não com fins de registro ou documentação. Assim, após a sua validação podem ser descartadas.

Bom, isso era um pouco do que eu tinha para falar sobre Histórias de Usuário/User Stories. Até o próximo post.

Referências:

Posted on: 26 de fevereiro de 2015, by : juliano

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *