Histórias do Usuário: O que são e como funcionam?

Histórias do Usuário, do inglês User Story, é um conceito que tem sua origem a partir da necessidade de identificar e apresentar as demandas do usuário em uma linguagem mais acessível e de fácil compreensão. Através de uma apresentação textual objetiva, e atuando como alternativa para as limitações encontradas pelos usuários em expressar e comunicar suas dificuldades na utilização de um determinado produto ou sistema.

As histórias de usuários são criadas, a partir, do reconhecimento das dores e demandas do usuário, e através da atuação da equipe de desenvolvimento do produto, que irá garantir que as soluções apresentadas paras suprir as necessidades do usuário sejam ágeis e criativas.

Dessa forma, uma história de usuário, é uma representação descomplicada e informal de uma necessidade de um usuário em potencial e tem como objetivo expressar sucintamente, as dores e necessidades desse usuário, para que a equipe, posteriormente, proponha critérios mínimos para aceitação e defina a viabilidade da história. Além, de apresentar o valor de negócio agregado ao produto de uma forma simples e leve.

Com base na metodologia Agile, que tem com princípios, a otimização do tempo, e a execução das tarefas que são realmente importantes, e como já dito anteriormente, uma história de usuário será uma descrição breve, informal e em linguagem compreensível, das ações que um usuário gostaria de realizar diante de um determinado produto, ou ações que ele precisa realizar dentro de um produto de software, para obter algo que para o usuário é considerado valioso.

Uma das definições mais sucintas utilizadas para Histórias de Usuários foi publicada no Scrum Guide, e afirma: “… uma descrição concisa de uma necessidade do usuário do produto sob o ponto de vista deste usuário.”

Normalmente, as histórias de usuários costumam seguir um modelo conhecido como:  
PAPEL -> FUNÇÃO ->BENEFÍCIO.

Que podem ser aplicadas através de alguns padrões:

• Eu, enquanto (QUEM?)

• Quero (O QUÊ?)

• Para (POR QUE?)

EX: Eu, como cliente da empresa CSP Tecnologia, quero efetuar o login na intranet desenvolvida pela empresa, para acessar as funcionalidades da plataforma.

(VERIFICAR SE O EXEMPLO ESTÁ ALINHADO COM OS SERVIÇO OFERECIDO PELA CSP, OU SUBSTITUIR POR OUTRO SERVIÇO)

Outro padrão bastante utilizado é:

• COMO um (TIPO DE USUÁRIO OU PERSONA)

• Eu QUERO (AÇÃO A SER REALIZADA)

• PARA QUE (BENEFÍCIO/VALOR ADQUIRIDO)

Esse padrão costuma seguir uma estrutura composta por 3 pontos:

1. INFORMAÇÕES GERAIS: espaço onde são inseridas informações identificação e rastreamento no backlog, tais como:
2. Número identificador
3. Projeto
4. Título da história

• DESCRIÇÃO: espaço onde o modelo papel-função-benefício é descrito e onde outras questões podem ser levantadas e respondidas, por exemplo:
  
• Como + Persona: Para quem está sendo criando este produto? Qual o perfil deste usuário? Nessa etapa podem ser incluídas informações da persona como: perfil, nome ou cargo.
  
• Eu quero + Ação a ser realizada: qual a necessidade desse usuário? Qual dor o produto apresentado está solucionando? Nesse momento, é aconselhável não se ater ao tratamento de implementação técnica, mas sim em necessidades concretas do mundo do usuário.
  
• Para que + valor de negócio adquirido/ benefício: qual a contribuição desta história para meu usuário? Qual benefício será agregado? As respostas para essas questões devem estar totalmente alinhadas com a etapa descrita acima.

• CRITÉRIOS DE ACEITE: esses critérios expressam as condições mínimas necessárias para o funcionamento do produto e devem sinalizar aspectos como:
  
• Condições
  
• Restrições
  
• Regras de negócio

Assim como nas etapas anteriores, as informações levantas devem estar de acordo com as Informações Gerais, Descrição e demais características já apresentadas anteriormente.

Em empresas ou projetos que utilizam a metodologia Agile, as histórias de usuários são consideradas a menor unidade de trabalho, e uma ferramenta essencial para o desenvolvimento incremental de um produto ou sistema.

De forma sintética, História de Usuários são uma descrição simples e sucinta de uma necessidade do usuário em relação a um produto, e é utilizada como ferramenta, não apenas para o desenvolvimento de um produto, mas também para o aperfeiçoamento do mesmo.

Outra questão que surge com frequência nas equipes é: POR QUE UTILIZAR HISTÓRIAS DE USUÁRIOS?

As histórias de usuários, são uma das melhores metodologias para entender as reais necessidades, limitações e aspirações dos usuários, pois, com ela, os usuários são colocados no centro da construção e desenvolvimento de um produto ou software.

Com essas histórias, é possível entregar para a equipe de desenvolvimento o contexto geral do produto e o porquê de o produto estar sendo desenvolvido. Essa atitude que por muitas vezes parece simples, proporciona uma mudança de perspectiva que permite que as equipes entendam como estão fornecendo valor para o negócio e a manter o usuário no centro das atenções.

As histórias de usuários possibilitam um entendimento maior sobre a necessidades dos usuários e como agir para que a centralidade deles permaneça por todo o projeto e até mesmo, após o lançamento do produto.

Além disso, proporciona vantagens como:

1. Melhor visualização do Valor de Negócio agregado ao usuário;
   
2. Permite a aquisição de conhecimento vindo diretamente dos usuários do produto;
   
3. É um mecanismo ágil que possibilita uma linguagem mais simples de comunicação do usuário em relação ao produto;
   
4. Possibilita maior conhecimento sobre e para a criação de Personas e identificação de suas necessidades;

• Por não possuir uma gama de requisitos pré-definidos, oportuniza que as equipes de desenvolvimento tenham maior flexibilidade e liberdade criativa na elaboração do produto;

• A partir de uma linguagem de fácil de entendimento, permite que todas as partes interessadas compreendam e estejam alinhadas;

• Maior rapidez e agilidade nos processos de refinamento.

• Possibilita a equipe de desenvolvimento de um produto uma grande flexibilidade no aperfeiçoamento do mesmo;

• A linguagem simples propicia um melhor entendimento por todas as partes envolvidas no desenvolvimento de um software.

Devido à brevidade das histórias de usuários, e a ausência de requisitos intermináveis, essa metodologia permite que as equipes mudem de ideia e recalculem a rota, sem desperdiçar muito tempo e esforço para isso.  Colocando em prática o segundo princípio do Manifesto Agile que diz:

“Esteja aberto a mudar os requisitos, mesmo tarde no desenvolvimento. Os processos ágeis alavancam alterações para a vantagem competitiva proporcionada aos clientes”.

A natureza sucinta e com centralidade no usuário das histórias de usuários, também, auxiliam nos processos de divisão de profissionais, separando quem lida com o que será desenvolvido, como cliente ou gerente de produto, de quem atua com a forma que o produto será desenvolvido, como, por exemplo, os desenvolvedores.

6 características fundamentais de boas histórias do usuário

Para a criação de uma boa história do usuário, podemos destacar 6 características essências. Com elas, uma história de usuário, estará cumprindo seu papel metodológico e funcional.

Para a elaboração dessa lista, nos inspiramos na técnica INVEST, um acrônico criado pelo programador Bill Wake em 2003, e publicado em seu livro Extreme Programming Explore, que consiste possuem as seguintes características:

I – Independente

N – Negociável

V – Valiosa

E – Estimável

S – Small (pequena)

T – Testável

Dessa forma:

1. INDEPENDENTE: as histórias de usuários devem ser independentes de outras histórias, para que seja possível, movimentá-las conforme as mudanças de prioridades e para ter liberdade para retornar ao backlog caso não seja a prioridade do momento.

• NEGOCIAVEL: as características e detalhes de uma história de usuário devem ser construídos de forma colaborativa pelo cliente e pela equipe que irá implementá-la. E para isso, é necessário a negociação do escopo, que é o momento em que será definido o que será incluído, ou não, na implementação.

• VALIOSA: uma boa história de usuário, precisa, necessariamente, possuir valor para o cliente, pois, sem esse valor não há motivos para implementá-la, visto que um dos objetivos da criação de histórias é a centralidade do usuário.

• ESTIMÁVEL: uma boa história de usuários precisa poder ser estimada. As estimativas não precisam ser exatas, porém, quanto mais precisa ela for, maior será o poder de negociação da equipe com o cliente. Além, de contribuir diretamente para a identificação de histórias de maior e menor valor, assim como, de baixo ou alto esforço.  Podendo assim, dar prioridade para histórias de maior valor e de baixo esforço. Uma boa história, é uma história que pode ser testada, e se a sua equipe, em conjunto com o cliente, não sabe informar como verificar a história, é porque ela ainda não está suficientemente compreensível. Para que isso não ocorra, recomenda-se, que os critérios de aceitação/especificações sejam construídos antes de a história de usuário ser implementada.

• SMALL (PEQUENA): em tempos em que a maior parte das empresas utilizam metodologias ágeis, o que toda equipe quer, é que uma história de usuário seja pequena. Possibilitando que ela seja criada em poucos dias e de maneira objetiva. Através de histórias pequenas, as possibilidades para estimar são mais fáceis, visto que histórias grandes são mais difíceis de estimar, por isso, menos negociáveis.

• TESTÁVEL: uma história deve poder ser testada em toda a sua plenitude, e as condições necessárias para realizar a sua validação, na maior parte dos casos, já foram apresentadas nos critérios de aceitação. Para que o processo de testagem seja completo é necessário que se ocorram testes individuais das soluções e funcionalidades entregues pela história.

História de usuário não é:

É muito comum acontecerem confusões entre o que é e o que não história de usuário, por isso, é importante tomar bastante cuidado para não ocorram equívocos e para que os conceitos de outras técnicas não sejam misturados.

Dessa forma, apresentaremos o que NÃO É HISTÓRIA DE USUÁRIO:

• Especificação de requisitos: uma história de usuário pode e deve conter artefatos de requisitos vinculados a si, porém uma história de usuário não é o detalhamento do próprio requisito.

• Casos de uso: assim como, as histórias de usuário não são especificações de requisitos, também não são casos de uso.

• Casos de uso: apesar de existirem controvérsias sobre esse ponto, no cerne do conceito, histórias de usuário não são, ou não deveriam ser, a documentação oficial de um produto, pois o objetivo e finalidade da sua criação não é esse.

Além disso, é preciso ressaltar que a “linguagem técnica” utilizada para criação de uma história deve ser de fácil compreensão e informal.

5 erros comuns na criação de histórias de usuário

Para você nunca mais cometer e criar excelentes histórias!

Existem alguns erros que são muito comuns a quem trabalha com histórias de usuários. Nós listamos os 5 principais para te ajudar a identifica-los e nunca mais cometê-los, assim, você poderá criar histórias cada vez melhores e não cair nessas armadilhas.

Os 5 erros mais comuns de quem trabalha com histórias de usuários são:

1. STORY MANIA: ou Mania de história, é aquele comportamento, que muitas equipes acabam desenvolvendo, de escrever tudo em formato de histórias. Esse comportamento é um erro e acaba resultando histórias estranhas ou complexas demais. Quando tudo é transformado em histórias, diversos conceitos como:épico, requisitos, cenário, entre outros, se confundem. E assim, norteadores importantes como centralidade do usuário e objetividade se perdem no processo.

• USUÁRIO ANÔNIMO: alguns times optam, por diversos motivos, em iniciar a criação das histórias sem especificar um usuário ou persona, o que acaba resultando na falta de clareza sobre questões importantes como: para quem se destina o benefício da história? Essa história vai conseguir realmente resolver algum problema?

• FALTA DE CLAREZA SOBRE CRITÉRIOS: no campo dos critérios, muitas histórias são escritas sem critérios de aceitação ou com critérios confusos. A falta de clareza sobre esses critérios gera muito desperdício de tempo e energia. O conceito norteador por trás dos critérios de aceitação é bastante simples e não deve ser esquecido: os critérios devem descrever as condições que a serem cumpridas para que a história seja concluída, e para que possa ser apresentada aos usuários e as demais partes interessadas.

• DETALHES DESASTROSOS: os detalhes podem ser os responsáveis pela ruína de diversas histórias de usuário. Seja, por adicionar detalhes e requisitos muito cedo, não adicionar nenhum detalhe e deixar a histórias muito abstratas, ou por escrever histórias grandes e com muitos detalhes. Os detalhes devem ser incluídos no tempo certo e a orientação é que se inicie por um Épico, pois assim, será possível capturar uma ideia sem muitos detalhes. Para, posteriormente, os detalhes serem adicionados a cada história que faz parte do épico. Histórias que estão próximas dos processos de implementação necessitam de maior nível de detalhes e clareza. Histórias em etapas iniciais costumas precisar de menos detalhes.

• FALTA DE COMUNICAÇÃO: a falta de comunicação é um problema comum e diversos âmbitos e na escrita de histórias de usuário, não é diferente. Não conversar sobre a história com todos os envolvidos no processo, desde clientes, usuários, desenvolvedores, testadores, até profissionais de negócios, antes de iniciar a implementação de uma história é um grande erro. Pois, a comunicação entre todos, é fundamental para incluir de forma colaborativa os detalhes e os critérios de aceitação. Correndo o alto risco de retrabalho e desperdício de tempo. Além disso, a comunicação e troca entre os interessados, permite debater melhor sobre o problema e garantir o entendimento da melhor solução.

Para não perder nenhum dos nossos conteúdos Assine nossa Newsletter e fique por dentro de tudo sobre Tecnologia para sua empresa.