BT

Quem quer esta User Story?

por Dan Puckett , traduzido por Lucas Souza em 03 Nov 2010 |

O formato padrão de user story é, "Como beneficiado, Eu quero objetivo". Para algumas user stories, entretanto, este modelo simples dá errado quando se trata de descobrir quem deve ser indicado no campo beneficiado.

Por exemplo, em uma thread recente no mailing list do Scrum Development, Kevin Krac foi perguntado sobre a seguinte user story:

O Product Owner tinha um pensamento sobre uma história que se tratava de mudar o número do telefone onde o cliente poderia ligar depois de fazer uma compra. Agora, o número de telefone do departamento de Marketing está listado no e-mail enviado para o cliente, mas o Product Owner pensou que seria mais sensato colocar lá um número de telefone de um representante de vendas em seu lugar.

Quem deveria ser o campo beneficiado nesta user story em particular? O P.O.? Um membro do departamento de marketing? Um representante de vendas? Ou outra pessoa?

Por que incluir um campo beneficiado nas user stories? Don MacIntyre me deu uma razão: "Eu descobri que identificar claramente o papel do beneficiário ajuda o P.O a chegar a uma proposta com valor mais claro - isso o ajuda a priorizar melhor a story." Nesta story, entretanto, não está claro quem é o beneficiado quando o time de desenvolvimento finalizar o trabalho.

Ron Jeffries vê pouco valor em aderir ao formato de story padrão:

O que está no cartão é pouco relevante em tudo: eu seria a favor de algo como "Substituir o número de telefone do marketing para o cliente, pelo número do representantes de vendas.

[...]

Pensar é importante. Escolher as histórias mais valiosas é importante. Explicar para a equipe que está finalmente decidido é importante. Ter testes concretos para ter certeza que aquilo funciona é importante.

O que está escrito no cartão é menos importante do que qualquer uma delas.

Mike Cohn, entretanto, vê algumas vantagens no formato padrão de user stories. As vantagens que ele vê são:

  • Colocar histórias de usuários na primeira pessoa ("Como ... Eu quero ...") ajuda os desenvolvedores e outras pessoas do time identificar-se com os beneficiários do trabalho que estão fazendo.
  • Estruturar todas as histórias da mesma forma ajuda o P.O. priorizar sem a necessidade de analisar mentalmente o texto de cada user story.

Para que o formato padrão funcione para stories não padronizadas, Mike Cohn tem um conjunto de dicas:

Uma boa user story pode ser sobre qualquer skateholder do sistema. E a história pode, facilmente, ser algo diferente de "querer" como em "Como um comprador, tenho mostrado produtos complementares quando eu começar a fazer check-out." Ou, "Como um usuário, sou forçado a alterar a minha senha a cada 90 dias." Assim, nem todas as histórias precisam ter a palavra "querer" neles.

Preencher lacunas em um modelo de user story, por mais excelente que esse modelo seja, não vai fazer o trabalho duro que precisa ser feito. As chaves para o sucesso de uma user story são, como Ron Jeffries coloca, "Cartão de Confirmação, conversação". Ou seja, fazer um cartão com o texto apenas o suficiente para identificar o requisito (a "história de usuário"), que tenha apenas a comunicação suficiente entre o cliente e os programadores, capaz de torná-los aptos a codificar essa tarefa com êxito, e confirmar o resultado do trabalho realizado por meio de um teste de aceitação.

E você leitor? Qual tipo de user story você escreve?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

"Quem" é importante by Luiz Fernando Oliveira Corte R...

Eu, particularmente, sou a favor do formato padrão, com ênfase na motivação da história:




Para... fazer alguma coisa
Como... Fulano
Quero... uma funcionalidade


Vejo a parte do "Para..." como um estímulo a pensar melhor na história. Quando a gente escreve o "Para...", acaba entendendo melhor o que a gente precisa e os desenvolvedores e o P.O. também. Às vezes já nessa parte os desenvolvedores ou o P.O. podem sugerir modos diferentes de resolver o problema. Agora, uma vez pronta a especificação da história, não acho que essa parte seja muito relevante.



Acho que a parte do "Como... Fulano" é a mais importante do formato padrão. Se os desenvolvedores e o P.O. sabem quem é o beneficiado pela história, fica mais fácil tirar dúvidas sobre a história, sugerir melhorias e validar o resultado. Em suma, a comunicação fica melhor.



Acho que a parte do "Quero..." também é importante, mas não tanto. É bom para ter uma ideia do que realmente tem que ser feito, mas acho que os detalhes da história têm que sempre serem revistos com o beneficiado.



Em suma, acho que esse formato até pode ser enxugado na hora de escrever a história, mas ele contém elementos essenciais para especificar bem uma história. Algo do tipo "Substituir o número de telefone do marketing para o cliente, pelo número do representantes de vendas." apenas dá uma ideia do que precisa ser feito; falta informação.



Também acho que trocar o "Quero" por outra coisa, pelo menos nos exemplos dados, não deixa clara a ideia do que precisa ser feito. Mostra um problema, mas não a solução desejada.

Quem quer esta user story? by Paulo Rebelo

As user stories são apenas um lembrete para um determinado requisito, pois o que importa mesmo é que o time pratique o conceito dos 3C's, ou seja: "card", "conversation" and "confirmation". Resume-se em comunicação transparente, franca e aberta, entre todos os envolvidos na criação e crescimento do produto. Mas, se mesmo assim, você quer escrever uma boa user story, adote o conceito de INVEST (acrônimo de algumas palavras em inglês):
Independent: evitar dependências, permite uma melhor execução de trabalho nos sprints.
Negotiable: não estamos falando de contratos, apesar de algumas restrições serem fixas.
Valuable: qual a relevância para o cliente final? Que base do meu público vou atingir?
Estimable: detalhes suficientes para estimar o trabalho.
Sized right: devem ser pequenas o suficiente para serem feitas em um sprint.
Testable: se não há critérios de aceite aparentes, não pode-se iniciar o trabalho.

Comunicação é o mais importante by Elderclei Reami

Concordo com Ron Jeffries - o essencial de uma user story é que ela comunique a intenção do PO e que isso sirva como ponto de comunicação com o time.

O modelo de user story é MUITO ÚTIL, mas não deve tornar-se uma prática ditatorial.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT