Histórias de Usuário: "In order to… As a… I want…"

em Metodologias Ágeis.

David Chelimsky no Rails Summit Latin America e David Anderson no Falando em Agile 2008 apresentaram um formato de história ligeiramente diferente do formato clássico proposto por Mike Cohn.

O formato clássico,

As a <type of user>
I want <some goal>
So that <some reason>

ou em uma tradução livre,

Como um <tipo de usuário>
Eu quero <uma história>
Para que <razão>

tem suas grandes vantagens:

  • A primeira parte do texto, “Como um <tipo de usuário>”, deixa bastante claro quem é o principal beneficiário da história;
  • A segunda parte, “Eu quero <uma história>”, é a história em si, o que deve ser desenvolvido;
  • A terceira parte, “Para que <razão>”, mostra o valor da história, seu objetivo, o porquê dessa história ser feita e qual sua importância no projeto.

Na Locaweb, inicialmente trabalhávamos com um formato mais livre, onde cada PO definia seu formato ideal. Logo depois vimos alguns problemas surgirem nos planejamentos, especialmente quando a história era muito direta e pouco explicativa (“Cliente está com problema X; resolver”, “Corrigir problema Y”), com textos normalmente iniciando por verbos assertivos. Quando começamos a trabalhar com o formato clássico “As a… I want… So that…”, imediatamente vimos o valor disso, e as histórias passaram a ficar mais claras para as equipes.

Contudo, ainda vimos um problema: Em alguns casos o objetivo da história, o “Para que”, não ficava muito claro. Algumas vezes o texto era um pouco genérico, outras vezes era até omitido (“Como um cliente eu quero que o problema X seja resolvido”).

A sugestão de Chelimsky e Anderson é a melhor solução para isso. Com uma simples mudança na ordem da frase, passamos a focar mais no valor da história do que antes:

In order to <achieve some value>
As a <persona>
I want <some feature>

Ou em uma tradução livre:

Para que <um valor seja obtido>,
Como uma <persona>
Eu quero <uma história>

Nesse formato identificamos três grandes vantagens:

  • Valor – O valor da história passa a ficar ainda mais claro do que no formato clássico. Primeiro identificamos o porquê dessa história, depois seu beneficiário e por fim a história em si. Além disso, o objetivo naturalmente passa a ser obrigatório no texto, sem o risco de ser omitido.
  • Agrupamento Funcional – A leitura das histórias passa a ser mais funcional. Se o backlog contiver histórias começando com “Como um Cliente do sistema X, eu quero etc” e outras “Como um Analista Interno do sistema X, eu quero”, é fácil identificar um agrupamento natural de beneficiários – histórias de Clientes e de Analistas Internos. No novo formato, histórias como “Para que eu não precise abrir um chamado, eu como um Cliente quero etc” e “Para agilizar meu trabalho no atendimento a um Cliente, eu como um Analista Interno quero etc”, a leitura passa a ser mais funcional, focando nos objetivos das histórias, facilitando até o planejamento de sprints e releases. No último exemplo, em uma leitura rápida podemos definir um sprint focando nas histórias de diminuição de incidentes, e no seguinte em diminuição de tempo de atendimento.
  • Personas – O uso de personas ajuda ainda mais a identificar o beneficiário da história, ao usar personagens fictícios como usuários. Para mais detalhes sobre as vantagens de se usar personas, vale ler o artigo na Wikipedia sobre o assunto.

Chelimsky sugeriu também uma variação no formato, para separar quem quer a funcionalidade de quem vai usá-la:

In order to <deliver some value>,
as a <role>,
I want that <some other role>
can <some feature>

Ou em uma tradução livre:

Para que <um valor seja obtido>,
como um <tipo de usuário>,
eu quero que <um outro tipo de usuário>
possa <ter algum benefício>

Pretendemos adotar essas idéias a partir de agora, em breve saberemos resultados.

Você também pode gostar