User Stories - Descrição de requisitos que humanos entendem

Atualizado em 30/01/2018!

Dentro da Engenharia de Software temos um sub-campo que é a Engenharia de Requisitos. A Engenharia de Requisitos é a “ciência” que estuda todas as formas de elicitar, analisar, validar, especificar e documentar requisitos, visando gerar insumos para a fase de projeto do software, coordenada por arquitetos de software ou analistas de sistemas, dependendo da empresa.

É nesta “fase de requisitos” que exploramos o quê, como e para quem iremos desenvolver as próximas funcionalidades do sistema. E no Scrum não é muito diferente disso, essa fase existe, embora distribuída em “pedaços”, no início de cada sprint, sendo executada durante a Sprint Planning. Isso acaba montando o chamado Product Backlog, que dou uma introdução no vídeo abaixo:

Mas como falo no vídeo, uma coisa que o Scrum não nos diz é: como organizar e/ou documentar as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com User Stories ou Histórias do Usuário: um artefato ágil para especificar requisitos citado na metodologia ágil Extreme Programming (XP).

Se preferir, você pode assistir ao vídeo abaixo ao invés de ler o artigo.

Histórias do Usuário

Vamos partir aqui de algumas premissas básicas: toda funcionalidade que vamos desenvolver vai impactar a vida de no mínimo uma pessoa. Se não impacta a vida de ninguém, não deveria existir. O impacto pode ser grande ou pequeno, desde um botão que vai economizar 15 minutos de tarefas repetitivas ou um formulário que vai atender a uma norma legal do governo que poderia fechar a empresa.

Então sempre começamos com um “quem”.

Toda user story, como o próprio nome sugere, começa com um usuário. Este usuário é o ator principal da história, uma persona que todos no time conhecem e entendem como pensa, como age, quais são as “dores”, etc. É importante mapear essas personas que serão utilizadas antes de escrever user stories com elas.

A descrição de uma persona, e isso não faz parte da user story em si, pode ser como abaixo (exemplo da Umbler):

“Luiz é um desenvolvedor e também um empreendedor. Ele cria diversos projetos usando tecnologias como ASP.NET e Node.js e gosta de publicá-los em ambientes confiáveis e com preços razoáveis. O Luiz ocasionalmente tem amigos que o ajudam nestes projetos e quase sempre bola maneiras de rentabilizar os projetos. O Luiz prefere fazer deploy via Git ao invés de FTP por ser mais rápido e confiável, além de gostar de pagar apenas pelos recursos que consome no servidor ao invés de um fixo mensal.”

Eu poderia continuar escrevendo sobre essa persona, mas acho que você já deve ter entendido a ideia.

Assim, quando uma user story começa com “Enquanto Luiz…”, todo o time, que já conhece aquela persona (os mesmos podem ser apresentados antes da leitura de cada história) e já entende as motivações dela, tornando mais fácil tomar decisões futuras. Sempre que o desenvolvedor que estiver implementando uma funcionalidade que é “para o Luiz” estiver em dúvida sobre algo, ele sempre deve se projetar (através de empatia, jovem gafanhoto!) e pensar “se eu fosse o Luiz, como eu gostaria que isso funcionasse?”.

Ponto de vista do usuário

Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o que será desenvolvido.

Note que quem escreve as histórias do usuário é quem gerencia o produto: o Product Owner. Como alguém não-técnico e centrado no produto, cabe ao P.O. especificar “o quê” deve ser feito e “para quem”, mas não “o como”. A funcionalidade deve ser descrita a nível de usuário e a nível de negócio, jamais a nível de programação.

Um bom exemplo seria:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web.”

Um mau exemplo seria:

“Enquanto Luiz, eu gostaria de ter um formulário em React para criação de banco MongoDB, com os campos nome do banco, usuário e senha, que quando preenchidos iniciassem uma tarefa de criação de instância no datacenter 03 da Umbler e me retornasse os dados de acesso por email quando estivesse pronto.”

Um dos “mandamentos” é que o time deve se auto-gerenciar, eles devem decidir como cada funcionalidade deve ser desenvolvida. O P.O. sabe que MongoDB é uma demanda do mercado e que devemos ter isso em nosso catálogo de produtos pois temos muitos “Luizes” como clientes, mas se isso deve ser implementado com React, se deve ser assíncrono, em qual datacenter vai ficar, etc é com a galera técnica.

Sendo assim, sua história de usuário deve ser:

1. sem detalhes de implementação;
2. focada no que o usuário quer fazer;
3. explicada do ponto de vista do usuário;
4. curta e objetiva;

A motivação

O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para quê ela vai servir exatamente (do ponto de vista de ‘entrega de valor’)? O que isso vai impactar na vida dele?

Estas e outras perguntas devem ser respondidas na motivação, que é a terceira e última parte da user story.

Muitas vezes quando estamos desenvolvendo não entendemos porque estamos desenvolvendo aquela feature. E quando isso acontece, geralmente não tomamos as melhores decisões sobre dúvidas que temos. Esta listagem deve ter uma busca no topo ou uma paginação? Esta tarefa deve ser síncrona ou assíncrona? Essa informação será buscada com texto-livre ou através de opções fixas?

A motivação costuma deixar isso tudo muito mais claro e ajudar a criar features que realmente entregam valor ao usuário. Como no exemplo abaixo:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web porque usando serviços de terceiros sai mais caro e a latência é alta.”

Aqui deixamos explícito que o usuário quer ‘MongoDB na Umbler’ porque isso seria mais barato e mais rápido para seus projetos web. Sendo assim, no momento da implementação desta funcionalidade (que confesso pode ser quebrada em tarefas menores, mas é apenas um exemplo), podemos inferir que nossa solução:

1. não pode ser resolvida através de integrações (add-ons);
2. tem de ter uma baixa latência (no mesmo datacenter que o projeto dele);
3. deve ser cobrado na mesma moeda do país dele (as soluções atuais são em dólar);

Essa informação ajuda a nortear as decisões, bem como se aliarmos às informações da persona do Luiz, veremos que se ele gosta de Git, é provável que goste de fazer deploy do seu banco MongoDB via linha de comando também.

Alguns autores defendem que a motivação, o “por quê” da user story, é opcional. Embora eu entenda que em alguns casos até possa ser verdade, eu encorajo a você sempre tentar deixar isso o mais explícito possível, usando aquela “máxima” de “o óbvio sempre precisa ser dito”.

Critérios de Aceitação

Quando a User Story possui regras de negócio ou requisitos não-funcionais específicos, vale definir os critérios de aceitação da mesma. Basicamente os critérios de aceitação são um checklist de requisitos que esta história em particular deve atender para que a mesma possa ser dada como pronta (DONE) pelo Product Owner.

Usando a mesma história que vínhamos criando, podemos ter os seguintes critérios de aceitação:

• a senha do banco MongoDB criada deve ter no mínimo 10 caracteres alfanuméricos;
• a tela deve ser desenvolvida conforme layout criado pelo time de UX;
• o nome do banco MongoDB criado pelo usuário não pode ser igual a outro já existente;

Se você estiver usando cards ou post its grandes para escrever suas user stories, você pode usar o verso do card para os critérios de aceitação. Caso contrário terá de documentá-los em outro local. Onde trabalho atualmente usamos o Visual Studio Online para Task Management, e nesta ferramenta temos um campo para Acceptance Criteria dentro do cadastro das User Stories. Eu escrevi um post esses dias de como usar a ferramenta pra gestão de backlog, é uma ferramenta bem bacana.

User Stories na prática

O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em post its, uma por post it. Algumas equipes costumam imprimir cards já com o esqueleto da user story nele, para não esquecerem nenhuma das três informações centrais e até mesmo com outros campos como o número de pontos daquela tarefa, os critérios de aceitação, etc.

Segue um exemplo bem elaborado, que pode servir de inspiração:

Esses cards são muito práticos e podem facilmente ser combinados com técnicas como Kanban (incluindo com Trello), para organizá-los (tanto virtual quanto físico) e Planning Poker, para estimá-los (Story Points). Uma ressalva aqui é quanto ao “tamanho” da história.

Algumas histórias ficam tão abrangentes que costumamos chamá-las de épicos. Devemos sempre quebrar épicos em histórias de maneiras que elas possam ser “digeridas” pelo time que vai implementá-la. Não existe uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda bastante. Algumas dicas nesse sentido são:

• se não cabe em uma sprint, é um épico;
• se consigo quebrar em dois ou mais story cards, é um épico;
• se no Planning Poker gerou muita divergência de pontuações é um épico;

A ferramenta que geralmente uso para gerenciar as User Stories em meus projetos é o Visual Studio Online, que ensino a usar neste post.

E um último ponto digno de nota é: não subestime a utilidade de artefatos mais tradicionais da engenharia de requisitos. Vão ter projetos, em que um story card não vai ser o suficiente e você terá de ter um artefato de apoio como um mockup, um diagrama UML ou até um caso de uso.

Enquanto que para muitos times e projetos user stories se encaixam como uma luva, para outros, você precisará de técnicas complementares ou até substituir essa técnica por uma mais tradicional. Então fique atento, Scrum não é bala de prata!

Neste outro post, dou várias dicas de como manter uma boa qualidade no backlog, nas histórias e nas tarefas: Backlog DEEP, Histórias INVEST e Tarefas SMART.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!