User Story

“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?

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:

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

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:

Como <tipo de usuário>, quero <alguma meta> para que eu possa <algum motivo>.

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

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.”

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.

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.

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:

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.

Critérios de aceitação:

- Ao abrir o relatório XYZ, vê-se ver um botão ao final da lista de resultados onde é possível fazer o download do relatório no formato CSV;

- Ao clicar no botão, o download começa automaticamente;

- O arquivo é exportado em formato UTF-8, para ser compatível com formatos atuais utilizados;