Histórias de Usuários

Published in

GUMA-RS

7 min readSep 28, 2020

Muito se fala em histórias de usuários no desenvolvimento ágil de software. Diversos times vêm usando, ou tentando usar, essa prática como forma de desenvolver melhores requisitos de software sem o sucesso esperado. Neste texto, vamos discorrer sobre o conceito, histórico e características de boas histórias de usuário.

O que são histórias de usuário?

Histórias de usuário são representações de necessidades dos usuários que podem ser utilizadas para definir e organizar os requisitos de um sistema. Elas escrevem funcionalidades de maneira simples e curta, apenas com detalhes suficientes para fazer uma estimativa de risco razoavelmente baixo. Devem ser focadas nas necessidades e nos benefícios para o usuário, evitando descrever detalhes de tecnologia, banco de dados e algoritmos específicos. Além disso, elas servem de guia para a criação de testes de aceitação.

Elas surgiram na década de 80 com o Extreme Programming ( XP) e foram concebidas como uma forma de representar o desejo de um usuário por uma funcionalidade. Atualmente utilizamos histórias de usuários em diversos contextos e processos ágeis, sendo bem comum encontrar pessoas que acreditam que elas são uma prática do framework Scrum e não conhecem a origem delas no XP. Abaixo temos uma ilustração de como as histórias de usuário se relacionam com as demais atividades:

Em 2001, Ron Jeffries, escreveu um artigo onde descreveu os três aspectos das histórias de usuários: cartão, conversa e confirmação. Esse conceito ficou conhecido como 3Cs.

C - Cartão

Tangibiliza a história de usuário de forma sucinta e objetiva. Ele não contém todas as informações que constituem o requisito. Seu propósito é ter o texto suficiente para identificar o requisito e lembrar a todos qual é a história.

C - Conversa

Incentiva a comunicação fluída e as interações entre os indivíduos. O requisito é detalhado pelo cliente através de conversas com o time de desenvolvimento, onde podem ocorrer trocas de ideias e aprimoramentos. Apesar de ser bastante verbal, podem ser utilizados alguns documentos de apoio nesta conversa, sendo enfatizado que a melhor complementação é através de exemplos.

C - Confirmação

Promove a eficácia da comunicação, garantindo que os objetivos sejam atendidos. Mesmo que tenhamos documentação detalhada e diversas conversas a respeito do que precisa ser feito, uma confirmação através de testes de aceitação é necessária. Quem define como uma história será confirmada é o próprio cliente e é através deles que a equipe irá demonstrar que a história foi entregue corretamente.

No artigo, Ron Jeffries defende que, em equipes com menos experiência, outros artefatos como: casos de uso, planilhas, esboços, etc, são desejados e podem até ser úteis em alguns casos, porém ele salienta que, empiricamente, pouquíssimas vezes considerou esse tipo de documentação valiosa, sendo um forte defensor de confirmação por meio de exemplos, de preferência automatizados, mesmo em situações de alta complexidade. Em última instância, ele recomenda iniciar com o conceito de 3Cs e, caso necessário, adicionar outros documentos que se mostrem relevantes.

Uma história de usuário deve comunicar:

Para quem

É importantíssimo identificar o autor da ação, quem será o beneficiário da funcionalidade. Boas histórias de usuário focam no usuário e uma excelente forma de identificar esse papel é através de personas.

Personas são representações fictícias do usuário do produto, onde descrevemos seus comportamentos e suas principais características, dando atenção especial às suas necessidades, objetivos, preocupações e desafios. A partir dessas definições ficamos mais aptos a elaborar funcionalidades que atendam as reais necessidades dos nossos usuários.

O que

Qual funcionalidade deve ser desenvolvida para este usuário. É importante manter a perspectiva do que precisamos e não como isso deve ser realizado. O trabalho de determinar como a funcionalidade será desenvolvida deve ser determinado pelo time de desenvolvimento.

Há uma figura em vídeo sobre o as práticas utilizadas pelo Spotify que exemplifica claramente a importância sobre alinhamento e autonomia:

Reparem que, sem autonomia e sem alinhamento não há nem motivação, nem entregas. Porém, somente o alinhamento sem autonomia gera desmotivação e ainda nos faz perder oportunidades de resolver o problema de outras formas. Em contrapartida, autonomia sem alinhamento gera desperdício, onde as pessoas produzem sem saber se o que estão fazendo é realmente o necessário para resolver os problemas. O ideal é termos um equilíbrio entre autonomia e alinhamento, onde temos o direcionamento, mas podemos decidir o melhor caminho a ser seguido. Reparem que na imagem essa situação é representada no quadrante superior direito, onde a personagem do líder expressa a necessidade de “atravessar o rio” deixando a equipe decidir como fazer isso. Faço apenas um adendo a esta figura que poderia trazer ainda mais significado, se o líder trouxesse o motivo da necessidade. Ilustro isso de uma forma bem lúdica, imagem que o motivo de precisarmos atravessar o rio é porque necessitamos de uma pedra que está do outro lado, porém, alguém do time conhece bem este lado do rio e sabe que podemos encontrar essa pedra sem precisar construir nada pra chegar do outro lado.

Por quê

Aqui é o momento de focar no objetivo, deixando claro quais problemas a funcionalidade resolverá, por quê a persona precisa desta funcionalidade. Ao mantermos esse motivo sempre a vista incentivamos a inovação e aumentamos a eficácia e a transparência ao priorizar histórias de usuários.

Como podemos escrevê-las?

Existem alguns modelos para escrevermos histórias de usuários. Eu particularmente prefiro o desenvolvido pela Connextra, porém é sempre interessante salientar que há outros formatos que podem ser utilizados de maneira eficiente.

Modelo (Connextra)

Como um… (Quem?)

Quero… (O quê?)

Para… (Por quê?)

Modelo (Chris Matts)

Para… (Por quê?)

Como um ...(Quem?)

Quero… (O quê?)

Modelo (Mike Cohn)

Como um… (Quem?)

Quero… (O quê?)

Porque… (Por quê?) — opcional

Modelo (5 Ws)

Como… (Quem? Quando? Onde?)

Quero… (O quê?)

Porque… (Por quê?)

Vale ainda destacar que o modelo defendido pelo Mike Cohn considera o uso da cláusula “Por quê” como opcional. No entanto, apesar dele admitir que por vezes, o motivo é óbvio e não precisaria ser declarado, ele afirma que na maioria das vezes prefere descrever o objetivo em suas histórias de usuário.

Inclusive foi o Mike Cohn que popularizou o acrônimo INVEST ao incluí-o em seu livro User Stories Applied. Todavia, foi Bill Wake, em 2003, que nos apresentou o conceito de “investir” em nossas histórias de usuário.

Para Bill, uma boa história deve ser:

I - Independente

Não se sobrepor a outra, sendo possível desenvolvê-las em qualquer ordem. Obviamente nem sempre isso é possível, mas quanto mais independente uma história for, mais fácil será priorizá-la

N - Negociável

Devem ser co-criadas pelo cliente e o time de desenvolvimento, sendo aptas a responder às mudanças quando necessário

V - Valiosa

Precisa entregar valor para o cliente, sendo que inclusive os aspectos técnicos precisam ser apresentados de forma que o cliente os considere importantes

E - Estimável

A equipe precisa conseguir estima-la e para isso precisa entendê-la

S - Pequena (Small)

Boas histórias tendem a serem pequenas, reduzindo incertezas e facilitando as estimativas

T - Testável

Permite ser validada e, para isso, utilizamos critérios de aceitação

O que são critérios de aceitação?

São os itens que precisam ser atendidos para que a história de usuário seja aceita. Nos critérios há as informações necessárias para a construção e o funcionamento do sistema, tais como, regras de negócio, restrições de acesso e mensagens. Eles facilitam o entendimento de como a funcionalidade será executada pelo usuário e eliminam ambiguidades, trazendo mais clareza aos requisitos. Além disso, delimitam fronteiras para a história de usuário. Devem ser escritos com linguagem clara o suficiente para serem entendidos por todos e serem independentes de implementação. Critérios de aceitação definem o que fazer e não como fazer.

Considerações finais

Em muitos momentos neste texto declaramos a importância de uma história de usuário ser sucinta e objetiva, não contendo todos os detalhes para implementação, pois estes serão discutidos entre cliente e equipe de desenvolvimento. Mas, certa vez, ouvi numa palestra realizada por meus colegas Ernesto Barbosa e Marcelo Lora, que requisitos de software bem escritos habilitam o time de desenvolvimento a trabalhar sem precisar de alinhamentos frequentes com as áreas de negócio. Num primeiro olhar essa frase parece contradizer o conceito da conversa amparado por Ron Jeffries em seu artigo sobre os 3Cs, porém num olhar um pouco mais profundo, verão que isso faz todo o sentido. Como agilista, defendo que pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto, mas entendo que esse trabalho precisa ser apoiado por um processo que não gere interrupções desnecessárias que tirem o foco do time. A chave que conecta bons requisitos com boas histórias de usuários está justamente no alinhamento e na autonomia. Boas histórias de usuário precisam prover alinhamento enquanto resguardam a autonomia do time.

Referências

Originally published at http://camilacapellao.com on September 28, 2020.

Histórias de Usuários

Written by Camila Capellão