Se você está envolvido no desenvolvimento de software, você já deve ter ouvido falar de histórias de usuários. Talvez você até as escreva como um gerente. Ou talvez você seja um cliente e seu desenvolvedor de software queira que você enquadre pedidos de funcionalidades como histórias de usuários.

Neste post, você encontrará tudo o que sempre quis saber sobre histórias de usuários.

O que é uma história de usuário em desenvolvimento de software?

Uma história de usuário é um formato para enquadrar funcionalidades e/ou requisitos de software. Como a parte “user story” sugere, as user stories são escritas no singular em primeira pessoa e descrevem uma funcionalidade como é percebida pelo usuário do aplicativo.

Uma típica user story segue esta estrutura (se estamos falando do processo de desenvolvimento Agile):

As a ,
I want ,
So que .

A primeira parte (como a….) especifica a função do usuário na aplicação, que normalmente é associada com o que é permitido fazer lá.

A segunda parte (a funcionalidade) aponta para a parte da funcionalidade que é usada neste caso.

A terceira parte (o resultado desejado) é o valor que o usuário quer obter da funcionalidade. Aqui estão alguns exemplos.

Exemplo 1

Como usuário registrado,
Quero ser notificado quando um amigo está indo a um evento próximo
Para que eu possa reagir às notícias ou me juntar a eles no evento.

Exemplo 2

Como piloto,
Quero obter um desconto de 10% em cada 10ª viagem,
Para que eu seja recompensado por gastar dinheiro consistentemente no serviço,

Existem boas razões para este tipo de estrutura. Quando os gerentes de produto/projeto lidam com requisitos de software que vêm de uma variedade de fontes, às vezes é difícil para eles atingirem uniformidade. Qual categoria de usuários o recurso abrange ou onde está o valor do negócio também pode não estar claro. O formato da história do usuário ajuda a capturar esses detalhes críticos.

Aplicações para a composição de histórias de usuários

As histórias de usuários podem ser escritas de várias maneiras, dependendo de quem vai trabalhar com elas.

O jeito Gherkin

Gherkin é uma linguagem de texto simples que descreve o comportamento sem especificar sua implementação. Aqui está um exemplo simples da sintaxe de Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Como você deve ter notado, o travessão define a estrutura em Gherkin. Os parâmetros básicos são Given/When/Then, e estes podem ser acrescentados por múltiplos And’s, se necessário. A sintaxe vai além desses parâmetros básicos, no entanto. Se você está realmente determinado a dominar Gherkin, aqui está um bom tutorial.

Embora Gherkin possa não ser a melhor escolha quando você estiver reunindo os requisitos iniciais para o projeto, ele pode ser benéfico (especialmente para a equipe de QA) ao desenvolver mais histórias de usuários. As histórias de usuários escritas em Gherkin são fáceis de converter para casos de teste.

The Agile Way

Muitas aplicações de gerenciamento de projetos ágeis oferecem uma funcionalidade para inserir histórias de usuários. Por exemplo, usamos a aplicação Taiga em alguns de nossos projetos internos. Ela ajuda a organizar o trabalho em torno de histórias de usuários que podem ser divididas em tarefas individuais no backlog.

Source: Taiga.io interface

Se você pensar nisso, faz todo o sentido ter histórias de usuários como itens de backlog e depois adicionar múltiplas tarefas a uma história de usuário. Por quê? Porque, digamos, você tem uma funcionalidade (= história de usuário) e três pessoas trabalhando nela; você vai precisar de tarefas separadas para essas pessoas. Você precisará de um designer para projetar a interface, um programador HTML/JavaScript para programar a interface, e o DevOps para liberar a interface em produção.

Outras ferramentas como o Pivotal Tracker (que introduz o conceito de “épicos” para agrupar histórias relacionadas) também permitem que você crie histórias que podem ser de diferentes tipos: Recursos, tarefas, bugs ou lançamentos.

Source: PivotalTracker.com

Parte das várias abordagens utilizadas por várias empresas, lembre-se que existe uma maneira simples e direta de escrever histórias de usuários – exemplos dos quais você viu no início deste post.

Quem deve escrever histórias de usuários?

Então, de quem é a responsabilidade de escrever histórias de usuários? Bem, depende. Se sua equipe concordou em capturar recursos na forma de histórias de usuários, é mais provável que eles venham dos acionistas através do Proprietário do Produto. Então, pode ser o PO que realmente os caneta para baixo.

Também pode ser um Gerente de Projeto ou um QA que também pode trabalhar com o cliente para discutir recursos e requisitos. Ou, talvez você seja um start-up de 15 pessoas e você é o CEO, CTO e CMO? Neste caso, você poderia definir um exemplo e começar a usar histórias de usuários para documentar as funcionalidades.

Muitos em TI também falam sobre “desenvolvimento de histórias de usuários”, que é o processo de registrar detalhes de alto nível primeiro (por exemplo, começando com uma simples lista de funcionalidades) e depois desenvolvê-los em histórias mais detalhadas adicionando tarefas, cenários, etc.

Em Conclusão

No final do dia, a formulação de funcionalidades na forma de histórias de usuários ajuda a manter o foco nos objetivos do negócio. Também o ajuda a completar os requisitos. E, como foi dito, o template/campo exato que você usa pode ser diferente, dependendo da situação.