1. Blog
  2. Processo
  3. Como escrever boas histórias de usuários?

Processo

Como escrever boas histórias de usuários?

Por: Camila Capellão

8 minutos de leitura

O universo do desenvolvimento de produtos é complexo e está em constante mudança, por isso, compreender o que os usuários desejam   é fundamental para que se tenha entregas de alto valor. É aí que entram as histórias de usuário. Elas são como uma ferramenta chave que ajudam as equipes de desenvolvimento a criar produtos que realmente fazem sentido e causam impacto. 

Nesse artigo vamos explorar o que são essas histórias de usuário, porque elas são tão importantes e como elas ajudam a conectar os criadores dos produtos com as pessoas que vão usá-los!

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 estão relacionadas aos requisitos funcionais de negócio, ou seja, não devem ser escritas para um sistema e sim para o usuário.

Em outras palavras, as histórias de usuário são uma maneira eficaz de transformar requisitos funcionais abstratos em descrições concretas e centradas no usuário, o que ajuda a criar um software mais alinhado às necessidades dos usuários finais. Ela é a representação de uma necessidade do usuário e contribui para a definição dos requisitos das funcionalidades de um sistema. Por isso, precisam ser simples e enxutas. 

E por que as Histórias de Usuário são importantes?

As histórias de usuário são uma ferramenta vital no apoio ao desenvolvimento de software centrado no usuário, eficiente, flexível e alinhado com as expectativas. Elas promovem uma abordagem colaborativa e orientada a valor, contribuindo para a entrega de produtos de alta qualidade.

Elas tiveram sua origem nos anos 80, dentro do cenário do Extreme Programming (XP), e foram desenvolvidas com o propósito de expressar os anseios dos usuários por determinadas funcionalidades. Entretanto, no contexto atual, as histórias de usuários são empregadas em várias situações e metodologias ágeis, sendo frequente encontrar indivíduos que erroneamente associam essa prática exclusivamente ao framework Scrum, desconhecendo sua raiz no XP. Abaixo temos uma ilustração de como as histórias de usuário se relacionam com as demais atividades:

Passos para escrever boas Histórias de Usuário

Escrever boas histórias de usuário envolve compreender as necessidades dos usuários, manter as informações sucintas, focar no valor que elas proporcionam, estabelecer uma comunicação fluida, definir critérios de aceitação claros e garantir que as histórias sejam testáveis e priorizadas adequadamente. Esses elementos ajudam a equipe a manter o foco nas necessidades dos usuários, aprimorar a colaboração e entregar produtos de alta qualidade.

O conceito dos 3Cs

No ano de 2001, Ron Jeffries, escreveu um artigo onde abordou os três elementos fundamentais das histórias de usuários: cartão, conversa e confirmação. Essa ideia ficou reconhecida 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 fluida 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.

Juntos, esses três aspectos ajudam a equipe de desenvolvimento a ter uma compreensão sólida dos requisitos, a construir a funcionalidade desejada de maneira colaborativa e a garantir que as expectativas do cliente ou usuário sejam atendidas. O conceito dos 3Cs é uma ferramenta valiosa para melhorar a comunicação, a colaboração e a qualidade no processo de desenvolvimento de software.

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 às 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 o 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. Por exemplo, se a necessidade é atravessar o rio é porque necessitamos de uma pedra que está do outro lado, talvez conversando com o líder alguém do time pudesse conhecer bem este lado do rio e ter o conhecimento que poderíamos encontrar essa pedra sem precisar pensar em como atravessar o rio”.

Por quê

Aqui é o momento de focar no objetivo, deixando claro quais problemas a funcionalidade resolverá, por que 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.

Modelos de Histórias de Usuário

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.

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í-lo 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.

Histórias de Usuário: O que é o INVEST?

O acrônimo INVEST, foi introduzido e popularizado por Mike Cohn em seu livro “User Stories Applied”, ou em português, “Histórias de usuário aplicadas”. O modelo proposto por Cohn permite a flexibilidade de adicionar ou não a cláusula “Por quê” em suas histórias de usuário. E, embora ele reconheça que em algumas situações o motivo seja evidente e dispensável, sua preferência é frequentemente incluir o objetivo na descrição das histórias.

 No entanto, o conceito de “investir” em histórias de usuário foi apresentado por Bill Wake em 2003. Bill propõe que uma narrativa de qualidade deve aderir a certos princípios:

I – Independente

Cada narrativa não deve se entrelaçar com outras, o que viabiliza a implementação em qualquer sequência. Compreensivelmente, a completa independência nem sempre é viável, mas quanto mais isolada uma narrativa for, mais fácil será determinar sua prioridade.

N – Negociável

As narrativas devem ser construídas em colaboração entre o cliente e a equipe de desenvolvimento, permitindo ajustes à medida que as circunstâncias mudam.

V – Valiosa

É imperativo que a narrativa agregue valor ao cliente, abrangendo até mesmo os elementos técnicos, que devem ser apresentados de maneira que o cliente perceba seu valor.

E – Estimável

A equipe deve ser capaz de estimar a narrativa, para isso, uma compreensão plena é essencial.

S – Pequena (Small):

As melhores narrativas costumam ser concisas, minimizando incertezas e facilitando a avaliação de esforço.

T – Testável

A narrativa deve ser verificável e, para tal, critérios de aceitação são empregados.

Esse conjunto de características contribuem para que uma história de usuário seja mais clara, gerenciável e, portanto, mais propensa a ser aceita com sucesso nos critérios de aceitação.

Histórias de Usuário: O que são critérios de aceitação?

Quando falamos em critérios de aceitação estamos nos referindo aos requisitos que devem ser satisfeitos a fim de que a história de usuário seja considerada aceita. Dentro desses critérios estão inclusas as informações indispensáveis para a concepção e a operacionalização do sistema, tais como diretrizes de negócios, limitações de acesso e mensagens. 

Eles simplificam a compreensão do modo como a funcionalidade será utilizada pelo usuário e eliminam possíveis ambiguidades, promovendo maior clareza aos requisitos. 

Esses critérios precisam ser formulados com uma linguagem suficientemente clara para ser entendida por todos e devem ser desvinculados da implementação. Os critérios de aceitação estabelecem o que deve ser feito, 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. No entanto, outros pontos de vista, defendem 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.

Se você gostou desse conteúdo e deseja se aprofundar ainda mais sobre as histórias de usuários, não deixe de conferir os demais artigos sobre o tema disponíveis aqui no Hub. 

Referências:

Outras publicações

Confira todos os conteúdos