Skip to main content

User Story

image-1612111661189.png

“Por trás de todo problema tem uma pessoa que sofre”

Para GDEV o entendimento do problema vem acima de tudo, e toda solução deve ser pensada em quem vai utilizar. A utilização de user story na construção de demandas permite que qualquer pessoa que realizar a leitura possa identificar para “quem é”, o que precisa ser feito e por que deve ser feito. A linguagem utilizada tem o intuito de simular uma conversa com a própria pessoa que está com problema. Reforçando o propósito de quem vai produzir a solução.

 

Conteúdo retirado do site: https://medium.com/produto-di%C3%A1rio/o-que-%C3%A9-uma-user-story-13d9ec681f7f.

O que é uma User Story?

Ah, histórias de uso! Sem dúvida um dos principais pilares do desenvolvimento ágil e uma ferramenta essencial para o Product Owner.

Uma das consequências do desenvolvimento ágil é a ideia de dividir grandes desenvolvimentos em pedaços menores, chamados histórias. Em seu caminho para se tornar um mestre ninja Product Owner e trazer valor aos seus clientes através de seu produto você deverá cuidar de um backlog e de várias histórias dentro dele.

Mas o que é afinal uma história de usuário ou user story?

Para responder essa pergunta, vamos quebrar o significado em partes:

  • Uma história, nesse contexto é uma “narrativa de ficção, oral ou escrita”.
  • Um usuário ou utilizador é quem possui ou frui de alguma coisa por direito ou uma pessoa que faz uso de um computador, de programas, sistemas ou serviços informáticos.

Podemos dizer então que uma história de uso é uma narrativa escrita sobre a utilização de um sistema.

Image for post
Image for post
“Uma história comum na vida de um PO :)”

Quando falamos de metodologias ágeis de desenvolvimento, a história de uso é uma ferramenta que auxilia na mudança de foco de detalhar requerimentos de sistema para conversar sobre eles.

Isso geralmente é feito utilizando sentenças narrando a utilização do requerimento, como o exemplo:

Que tal alguns exemplos de histórias simples para ilustrar?

  • Como gerente de marketing, quero saber a origem e meio do tráfego que levou a uma compra em nosso site, para que eu possa entender quais são os melhores canais de comunicação para o nosso produto.
  • Como CEO, quero saber qual a rentabilidade média por produto, para que eu possa decidir em quais produtos investir mais ou menos.

Uma das vantagens em seguir esse modelo é que o autor da história é obrigado a focar no “O QUÊ” ao invés do “COMO” — esse último é de responsabilidade do time de desenvolvimento.

Ao criar uma nova história, o autor deve focar sempre em descrever suas necessidades e o objetivo que está tentando alcançar com ela. Com isso, a equipe ao ouvir a história e sem estar limitada por uma tentativa de solução já proposta, tem liberdade para criar ou propor a melhor alternativa para a resolução do problema.

Quem são os atores ou personas das histórias?

Esses são os usuários finais das histórias. Muitas vezes são de fato os usuários que escrevem ou solicitam as histórias.

No exemplos acima usamos o Gerente de Marketing e o CEO da empresa como atores, porém os atores podem ser qualquer um dos envolvidos com seu produto, o cliente final, um usuário interno, um usuário externo, o próprio PO, etc.

O Product Owner é o único que deve escrever histórias?

Definitivamente não. O P.O. age como parte do time de produto e serve como centralizador de histórias que podem vir do cliente, de outros stakeholders (interessados do projeto) ou até mesmo do próprio time.

A tarefa do P.O. no entanto é assegurar que as histórias estejam bem descritas e contenham informações suficientes para que sejam facilmente entendidas pelo time. É com base na história que o time irá planejar seu trabalho e estimar sua complexidade.

Péssimas histórias de uso

Para ajudar a entender o conceito, que tal olharmos alguns exemplos de histórias de uso mal escritas?

  • A) “Falta um botão de download.”
  • B) “Gostaria que a tela anexada exibisse mais informações do produto.”
  • C) “Incluir mais imagens.”
Image for post
Image for post

Uma maneira de transformar histórias terríveis em algo útil é utilizar o método dos 5 Whys (ou 5 Por quês). Isso também ajuda ao autor a estar mais preparado e a detalhar corretamente sua próxima história.

Hipoteticamente, vamos imaginar que eu usei esse processo com a primeira história (A) dos exemplos acima.

  • O problema: “Falta um botão de download.”
  • 1o. Por quê?: — “Para que eu possa baixar os relatórios.”
  • 2o. Por quê?: — “Para que eu consiga utilizar os dados no excel.”
  • 3o. Por quê?: — “Para que eu cruze as informações com dados de outras fontes.”
  • 4o. Por quê?: — “Para que eu possa fornecer um relatório completo com informações de vendas e receitas.”
  • 5o. Por quê?: — “A diretoria precisa de informações acuradas sobre vendas e receitas para tomar decisões importantes de investimento para a empresa.”

Com essas informações, já seria possível melhorar a história inicial, por exemplo:

  • Como analista de BI;
  • Quero exportar os dados do relatório XYZ no formato CSV;
  • Para que possa fornecer informações acuradas sobre vendas e receitas de nossos produtos à diretoria da empresa.
Image for post
Image for post
Digna de um nobel

Critérios de aceitação

Não podemos esquecer que uma boa história de usuário também contém critérios de aceitação muito bem definidos.

Os critérios de aceitação, como o próprio nome já diz, são os critérios para a história ser aceita e ser dada como entregue.

Eles são um conjunto de instruções, cada uma com um resultado claro de aprovação ou reprovação — como um checklist, que especifica requisitos funcionais e não funcionais.

Os critérios de aceitação acabam por constituir a “Definição de Feito” e, por assim dizer, bem feito.

Uma dica para escrever bons critérios de aceitação é pensar em como será realizada a demonstração da funcionalidade quando ela estiver pronta. Como ela vai funcionar? Quais os passos necessários?

Usando essa ideia e novamente nossa história modelo, poderíamos definir alguns critérios de aceitação: