Você já utilizou Histórias de Usuário?

Olá, seja bem-vindo.

Nesse artigo iremos falar sobre História de Usuário, que é a técnica mais utilizada para descrever requisitos quando estamos trabalhando com métodos ágeis.

Uma história de usuário consiste em uma breve descrição de uma funcionalidade a ser desenvolvida para atender à necessidade de uma pessoa, que pode ser um cliente, um usuário do sistema, um stakeholder, entre outros.

Os 3 C’s — Cartão, Conversação e Confirmação

Jeffries (2001) nos ensinou que as histórias são compostas por três aspectos críticos, também conhecidos como 3 C’s:

Cartão

A história de usuário é descrita em um cartão, e consiste em um pequeno texto que identifica o requisito a ser desenvolvido. É importante destacar que a história de usuário não contém todos os detalhes de um requisito, e visa apenas lembrar ao time que é necessário discutir sobre o assunto.

Conversação

O Dono do Produto irá apresentar os detalhes de uma história de usuário para o Time de Desenvolvimento através de uma conversa, onde todos podem expor as suas opiniões e sentimentos.

Tenha em mente que podem ocorrer várias conversas referentes a uma história de usuário, pois, conforme os requisitos forem melhor compreendidos, eles serão mais detalhados.

Por exemplo, uma mesma história pode ser discutida nos seguintes momentos:

  • Durante sua criação.
  • No refinamento dos requisitos.
  • No planejamento da Sprint.
  • Ao longo do andamento de uma Sprint.

Jeffries nos deixa claro que, caso necessário, as conversas podem ser complementadas com um documento. Vamos supor que a história tenha uma regra de negócio com um cálculo complexo. Nessa situação, é pertinente escrever um documento descrevendo as regras e fórmulas para a realização desse cálculo.

Confirmação

Para finalizar, são definidos alguns critérios que permitem a confirmação de uma história de usuário. Esses critérios são conhecidos como testes de aceitação, e costumam ser descritos na parte de trás do cartão. O desenvolvimento de uma história de usuário somente será considerado finalizado quando todos os testes de aceitação tiverem sido executados com sucesso.

Características fundamentais de uma História de Usuário

Quando estamos desenvolvendo uma história de usuário, a fim de que a mesma tenha qualidade, ela deve possuir as seguintes características, que são representadas pelo acrônimo INVEST:

  • Independente — Sempre que possível, as histórias de usuário devem ser independentes umas das outras, a fim de que o Dono do Produto possa ordená-las, planejá-las e implementá-las conforme o valor que cada uma possui para o negócio.
  • Negociável — Conforme foi dito anteriormente, a história de usuário não contém todos os detalhes de um requisito. Sendo assim, ela deve ser descrita em um nível que permita ao Time Scrum e Stakeholders realizarem conversas a fim negociar o detalhamento desses requisitos. Uma história de usuário não é um contrato a ser seguido, e sim um lembrete a todos que deve ser realizada uma conversa a fim de detalhar os requisitos.
  • Valorosa — No artigo referente às características de um Backlog do Produto, dissemos que, a fim de evitar desperdício de tempo e de recursos, o Dono do Produto deve priorizar o desenvolvimento dos 20% dos itens do Backlog do Produto que irão agregar o maior valor para o negócio. Os 80% dos itens restantes devem ficar para depois ou, caso não sejam efetivamente necessários, devem ser descartados. Dessa forma, as histórias do usuário devem gerar valor para o negócio.
  • Estimável — É muito importante que uma história de usuário possa ser estimada pelo Time de Desenvolvimento, mesmo que o nível de precisão não seja alto, uma vez que a estimativa possibilita ao Dono do Produto priorizar o Backlog do Produto, estimar custos, planejar releases, etc. Quando o Time de Desenvolvimento não consegue estimar uma História de Usuário, isso pode significar que o seu tamanho é muito grande, que as informações são insuficientes, que o seu conteúdo está muito ambíguo, ou até mesmo que o Time não possui conhecimento sobre a tecnologia a ser utilizada.
  • “Small” (Pequena) As Histórias de Usuário devem ser pequenas, ou seja, necessitam possuir um tamanho máximo que as permitam serem desenvolvidas dentro de uma única Sprint.
  • Testável — É muito importante que as Histórias de Usuário possam ser testadas, a fim de que seja possível assegurar que o produto obtido ao final do desenvolvimento esteja de acordo com o que foi definido e sem a existência de erros.

Temas

As histórias de usuário podem ser agrupadas por Temas relacionados. Por exemplo, ao construir um novo site de comércio eletrônico, as histórias poderiam ser agrupadas nos seguintes temas: Produtos, Clientes, Fornecedores, Pagamento, Recebimento, Vendas, Relatórios, entre outros.

Construindo Histórias de Usuário

A partir deste momento, iremos apresentar-lhe o formato mais utilizado para se criar uma boa história de usuário.

As histórias de usuário costumam ser descritas em um pequeno cartão, e o seu formato mais comum é:

Formato de uma História de Usuário

Vamos supor que estamos desenvolvendo um site de comércio eletrônico, e o Dono do Produto irá descrever as formas de pagamento disponíveis para o Cliente. Sendo assim, a história de usuário poderia ser:

Exemplo de Épico (História de usuário muito grande).

Agora irei fazer um questionamento. Em sua opinião, essa história está atendendo a todos os critérios do acrônimo INVEST?

O Time de Desenvolvimento, ao analisar a história, ficará com muitas dúvidas, tais como:

  • Quais formas de pagamento serão disponibilizadas? Boleto, Cartão, Depósito, Dinheiro?
  • Se for Cartão, seria Débito, Crédito ou ambos?
  • Se for Débito, de quais Bancos iremos aceitar?
  • Se for crédito, quais bandeiras? Visa, MasterCard, AMEX?
  • Podemos aceitar compras parceladas?
  • Entre outras dúvidas.

Conforme podemos constatar, a história está muito grande e sem muito detalhamento. Dessa maneira, fica difícil estima-la e entender o requisito. Essas histórias muito grandes são chamadas de Épicos, e as mesmas ficam no final do Backlog do Produto, pois, elas irão demorar para serem selecionadas para uma Sprint.

Porém, quando chegar o momento de adicionar esse épico ao topo do Backlog do Produto, prestes a entrar em uma Sprint, o Dono do Produto necessita realizar o seu refinamento. Nesse momento, o épico será quebrado em histórias menores, com mais detalhes, conforme imagem abaixo.

Épico desmembrado em várias histórias de usuário menores

O épico foi quebrado em seis histórias menores, que agora atendem a praticamente todos os critérios do INVEST: São independentes, negociáveis, valorosas, estimáveis e pequenas.

Porém, podemos considerá-las testáveis? Quais testes serão realizados pelo Dono do Produto a fim de considerar essas histórias prontas?

Como você pode perceber, ainda não é possível identificar quais critérios de aceite serão considerados pelo Dono do Produto a fim de assegurar que a história foi desenvolvida com sucesso ao final de uma iteração.

O mais comum é que o critério de aceite seja descrito no verso do cartão, conforme exemplo abaixo.

História de usuário com critérios de aceites

A partir do momento em que ocorre a definição do critério de aceite, o Time de Desenvolvimento sabe o que deverá construir e como o Dono do Produto irá validar se a história foi finalizada com sucesso, ou não.

Além disso, perceba que o critério de aceite ajuda a detalhar os requisitos. A História refere-se à utilização da forma de pagamento Cartão de Crédito da Bandeira A. Os critérios de aceite estão complementando os requisitos com as validações que devem ser realizadas quando se utiliza essa forma de pagamento. É comum que o Time de Desenvolvimento automatize a execução dos testes de aceite.

Para finalizar, tenha em mente que, em caso de necessidade, o Dono do Produto pode adicionar a referência de um ou mais documentos à história, com o intuito de detalhar melhor algum requisito importante. Por exemplo, na história “Pagamento — Cartão de Crédito — Bandeira A”, o Dono do Produto pode adicionar referência a um documento adicional que irá conter as regras a serem utilizadas para validar o número do cartão de crédito e identificar a sua bandeira.

Conclusão

A História de Usuário é uma excelente técnica para descrever os requisitos de um produto, porém, nem sempre é recomendável a sua utilização. Por exemplo, quando um item do Backlog do Produto descrever um defeito ou débito técnico, não faz muito sentido que esse item seja escrito no formato de uma história de usuário. Nessa situação, provavelmente é melhor que o item contenha apenas um apontamento para o local onde o defeito ou o débito técnico foi detalhado.

Referências Bibliográficas

Cohn, Mike. User Stories Applied (Addison-Wesley Signature Series). Pearson Education.

Jeffries, Ron. 2001. “Essential XP: Card, Conversation, Confirmation.” http://xprogramming.com/articles/expcardconversationconfirmation/.

S. Rubin, Kenneth. Scrum Essencial: Um guia prático para o mais popular processo ágil. Alta Books.

Wake, William C. 2003. “INVEST in Good Stories, and SMART Tasks.” www.xp123.com.

Wildt, Daniel; Moura, Dionatan; Lacerda, Guilherme; Helm, Rafael. eXtreme Programming – Práticas para o dia a dia no desenvolvimento ágil de software. Casa do Código.

Treinamento Formação em Scrum - Preparatório PSM-I.

Formação em Scrum – Preparatório para a Certificação PSM-I. 
Apenas R$ 19,99. Aproveite!