User Story
Uma user story é uma definição muito genérica de um requisito, contendo apenas informação suficiente para que os developers possam entender razoavelmente o esforço a despender para conseguirem realizar o requisito.
As user stories incluem, desse modo, uma frase curta que explica o que o utilizador faz ou precisa de fazer, numa linguagem simples e comum. A equipa pode complementar a user story com informação sobre o requisito e os critérios de aceitação.
Uma das grandes particularidades da user story, é, desse modo, que esta se foca no que o utilizador precisa de fazer e não na funcionalidade que o produto ou serviço deve ter. Dessa forma, existe espaço para que a equipa discuta a solução e como esta pode adicionar valor para o cliente e para a organização.
As user stories normalmente seguem o seguinte formato:
“O utilizado X, quer ser capaz de fazer Y, porque Z”
X refere-se ao utilizador, Y ao que ele quer fazer, Z é o motivo porque quer Y.
Existem vários vantagens em usar user stories, como, por exemplo:
- Focar no utilizador – Quando se está a desenvolver um produto é normal ouvir todas as pessoas. Contudo, estas pessoas poderão contribui com requisitos que podem ou não ter real valor. Dessa forma, se nos focarmos no utilizador e não nos gostos da equipa e stakeholders conseguimos definir requisitos que satisfaçam as necessidades de quem realmente usa o produto.
- Focar na necessidade – Os produtos são desenvolvidos para satisfazer necessidades. A use story descreve claramente a necessidade. Dessa forma, conseguimos melhores resultados e uma maior satisfação do cliente.
- Ser flexível – As user stories exigem pouco trabalho de documentação de requisitos. Dessa forma, esta abordagem leve convive bem com ambientes complexos e incertos onde a mudança é constante.
Características da User Story
O co-inventor da prática, Ron Jeffries, sugeriu um conceito para o desenvolvimento das user stories. Dessa forma, esse conceito diz que:
- Usar cartões – A user story é apenas uma frase curta, escrita num cartão para lembrar a todos a história.
- Conversar – Os requisitos são refinados em reunião entre o cliente e os developers ao longo de todo o projecto. É durante estas reuniões, entre a equipa e os stakeholders, que se apuram e, assim, se registam as decisões e ideias.
- Registar critérios de aceitação – A equipa deve registar os critérios de aceitação da história para, desse modo, facilitar o seu desenvolvimento e validação.
Como Construir uma User Story
Como já referimos uma user story deve, desse modo, contar uma história simples de um problema que um utilizador tem. Em suma, esta procura explicar de forma muito resumida e aberta, que problema o utilizador está a tentar resolver com o nosso produto. Desse modo, como já vimos a user story utiliza a seguinte formula:
“O utilizado X, quer ser capaz de fazer Y, porque Z.”
Vamos explorar a fórmula em maior detalhe?
O utilizador X é quem irá usar o produto. Ou seja, é ele que tem o problema que queremos resolver ao construirmos o nosso produto. Caso existam várias personas de utilizadores diferentes, a equipa deve escrever uma user story para cada um, mesmo que estas sejam muito similares.
O Y é o que o utilizador X espera fazer com o nosso produto, ou seja o seu objectivo. Nesse momento, o foco deve ser o objectivo do utilizador, ou seja, perceber bem o que ele pretende e só depois, como é o que nosso produto o poderá ajudar a alcançar esse objectivo.
O Z é o motivo por detrás do objectivo Y. De uma forma macro temos a razão, a descrição do problema que levou o utilizador a ter um objectivo. Ou seja, é aqui que está a causa que nos irá levar a criar ou mudar o nosso produto.
Por exemplo uma user story real poderia ser:
O João, quer uma ciclovia perto de casa dele, para poder ir trabalhar.
Neste caso o utilizador é, assim, o João. O que ele pretende, ou seja, o seu objectivo é uma ciclovia. E o seu problema é, desse modo, que precisa de uma solução para ir trabalhar de bicicleta.
User Story vs Use Case
Ainda que muitas pessoas possam confundir as user stories e os use cases não são a mesma coisa. Claro que normalmente começam da mesma forma, e estão fixadas num objectivo, são escritas na perspectiva do utilizador, de forma simples e não contam a história todas. Contudo, as user stories focam-se no problema a resolver, no resultado e nos beneficios que iremos obter. Por outro lado, os use cases focam-se em como o sistema irá funcionar.
Ambas contêm, desse modo, o papel do utilizador, objectivo e critérios de aceitação. Contudo, as user stories deixam de fora muitos detalhes para que a discussão de como resolver o problema com os stakeholders seja mais flexível. Por outro lado, os use cases procuram definir os requisitos de forma mas detalhada e firme.