Histórias de Usuário

1. Introdução

• Uma História de Usuário é uma breve declaração que descreve algo que o sistema deve fazer para as pessoas que irão utilizá-lo. 

• Histórias de Usuário é uma técnica proposta por profissionais da indústria de métodos ágeis para especificação de requisitos.

  • O uso de Histórias de Usuário foi introduzido como uma unidade de funcionalidade da Extreme Programming (XP). Nesta metodologia, o progresso é demonstrado pela entrega de código testado e integrado que implementa uma história de usuário. 

  • Na atualidade, a técnica é parte integrante de outras metodologias de gerência de projetos ágeis, como o Scrum, Kanban e Lean Development.

• Considerando a estrutura de tipos para classificação de requisitos apresentada, as Histórias de Usuário trabalham com requisitos funcionais, inicialmente, no nível de requisitos de usuário. 

2. Conceitos Principais

• Uma História de Usuário é composta por três partes, todas começando com a letra C de acordo com a equação:

História de Usuário = Cartão + Conversas + Confirmação

1. Cartão: escrito por clientes para escrever, na sua linguagem e em poucas sentenças, uma funcionalidade ou parte de uma funcionalidade que esperam ver implementada no sistema. Geralmente, tais cartões fazem parte de um quadro do produto, chamado product backlog, e seu papel no método de desenvolvimento vai variar de acordo com a metodologia adotada (Ex.: Kanban, Scrum, etc).

2. Conversas: entre clientes e equipe de desenvolvimento, por meio das quais clientes explicam e detalham o que escreveram em cada cartão. Especificações textuais e completas foram substituídas por comunicação verbal entre a equipe de desenvolvimento e clientes. Por isso, pelo menos uma pessoa cliente participa do time do projeto em tempo integral (esta pessoa é chamada de product owner).

3. Confirmação: um teste de alto nível especificado também pelo cliente para verificar se a história foi implementada conforme esperado. Não se trata de um teste automatizado, como um teste de unidades, mas a descrição dos cenários, possíveis exemplos e casos de teste que podem ser usados para confirmar a implementação da história. 

   • Estes testes são chamados de Testes de Aceitação de Histórias. Estes testes devem ser escritos o quanto antes, preferencialmente, no início de uma iteração, no verso dos cartões da história (ou em outra parte do cartão digital). 

   • Uma história de usuário se restringe a definir o escopo de uma tarefa do software sem entrar no detalhamento do passo a passo ou das regras de negócio que se aplicam à tarefa. Os detalhes do comportamento do sistema são elaborados por meio de interações entre a equipe de desenvolvimento e product owner(s) pela definição de um ou mais critérios de aceitação para teste. 

   • Testes de aceitação não podem mudar durante ou após a entrega da funcionalidade. 

   • Por ser especificado por clientes, evita-se que a equipe de desenvolvimento decida, por conta própria, a definição dos testes de aceitação ou a sofisticação de algumas histórias sem que isso tenha sido pedido pelos clientes (gold plating). 

• A criação de Histórias de Usuário ocorre durante todo o desenvolvimento do projeto.

• Ao especificar requisitos por meio de Histórias de Usuário, cria-se um ambiente de propriedade das partes interessadas, que estabelecem prioridades e alocam recursos de forma incremental e interativa.

• Não existem Histórias de Usuário para requisitos não-funcionais. Pode-se — e deve-se — escrever cartões/tarefas sobre requisitos não-funcionais, mas elas não vão para o backlog do produto. Em vez disso, elas são usadas nos testes para refinar os critérios de conclusão de histórias.

• Não existem Histórias de Usuário para estudo de novas tecnologias. Estudos podem ser tarefas necessárias para implementar uma determinada história, mas tarefas para aquisição de conhecimento são chamadas de spikes.

2.1. Composição dos Cartões de Histórias de Usuário

• Uma história de usuário é a menor unidade de trabalho do produto com base no cliente. Posteriormente, uma história de usuário pode ser mapeada para uma ou mais tarefas da equipe de desenvolvimento.

• As Histórias de Usuário devem ser escritas no espaço equivalente a um cartão; isso porque dessa forma limita-se a sua extensão, obrigando a produção de um texto claro e objetivo. 

• O primeiro passo para escrever Histórias de Usuário é listar os principais papéis de usuários (user roles) que vão interagir com o sistema, estes papéis são equivalentes aos Atores em Casos de Uso). Assim, evita-se que as histórias fiquem enviesadas e atendam às necessidades de apenas algumas pessoas.

2.1.1. FRENTE do Cartão

• As Histórias de Usuário possuem formato livre, entretanto, costumam responder a três perguntas:

  • Quem se beneficia? A resposta indica a parte interessada que se beneficia da história de usuário [papel de usuário].

  • O que se quer? A resposta deve descrever uma visão alto nível da funcionalidade para o usuário [realizar algo com o sistema].

  • Qual é o benefício? A resposta indica o valor de negócio que a história proporciona, o porquê dela existir [justificativa da funcionalidade] .

2.1.2. VERSO do Cartão

• O verso dos cartões de Histórias de Usuário possui formato livre, entretanto, costumam conter os Testes de Aceitação da História.

• Um teste de aceitação de história de usuário é uma técnica de teste no desenvolvimento de software que visa validar se uma determinada funcionalidade foi implementada corretamente. É uma etapa crucial para garantir que o software entregue atenda às necessidades e expectativas dos usuários finais.

• Quando uma história de usuário é escrita durante a fase de planejamento ágil ou desenvolvimento iterativo, ela descreve uma funcionalidade específica que o sistema deve fornecer para satisfazer as necessidades do usuário. O teste de aceitação é elaborado com base nessa história e tem como objetivo verificar se a funcionalidade implementada está de acordo com o que foi solicitado pelo usuário.

• Os testes de aceitação servem como critérios para determinar quando uma história de usuário está pronta para ser considerada concluída. Eles são escritos antes ou durante o desenvolvimento da funcionalidade e são usados tanto pelos desenvolvedores para implementar corretamente a funcionalidade quanto pelos testadores para verificar se a funcionalidade foi entregue conforme o esperado.

• Os testes de aceitação geralmente são escritos em linguagem natural e usam uma abordagem chamada "Dado Quando Então" (Given When Then). 

  • Dado: Descreve o cenário inicial ou pré-condição em que o teste ocorrerá. Essa parte estabelece o contexto necessário para executar o teste [cenário].

  • Quando: Descreve a ação ou evento que será executado pelo usuário ou sistema durante o teste. Essa ação geralmente está relacionada com o comportamento que está sendo testado [ação ou evento].

  • Então: Descreve os resultados esperados após a execução da ação descrita na seção "Quando". São as verificações ou validações que permitem confirmar se o comportamento do sistema está de acordo com o esperado [resultados esperados].

Dado [cenário], quando [ação ou evento]*, então [resultados esperados] 

*opcional

2.2. Outros conceitos

Workshop de Escrita de Histórias

• Um Workshop de Escrita de Histórias é uma boa técnica para a elicitação e especificação de requisitos no formato de histórias. 

• Tal workshop reúne em uma sala representantes de todas as partes interessadas e representantes de cada papel de usuário do sistema para discutir os objetivos do sistema, suas principais funcionalidades e realizar a elaboração das histórias. 

Features

• As features são como são chamados os requisitos funcionais, uma vez que um requisito funcional pode ser mapeado para uma ou mais histórias.

• Assim, uma feature é responsável por agrupar um conjunto de histórias de usuário para expressar uma função do produto.  As regras de negócio de uma funcionalidade podem ser descritas juntamente com os cartões de uma feature.

Épicos

• Um épico (epic) é uma história de usuário que ainda não foi detalhada por ser muito grande ou, por ainda haver muita incerteza sobre ela.  Posteriormente, o épico será dividido em histórias de usuário menores.

• Épicos ficam posicionados no final do backlog do produto, o que significa que ainda não ter previsão de quando elas serão implementadas. Por outro lado, as histórias do topo do backlog do produto e que, portanto, são implementadas primeiro, devem ser sucintas e pequenas, para facilitar o entendimento e estimativa das mesmas.

• Um exemplo de épico poderia ser: "Como pessoa com deficiência visual, eu desejo que meu ambiente de trabalho seja o mais acessível possível para que eu não dependa de outras pessoas e tecnologias."

3. Características das Histórias

• As Histórias de Usuário são compatíveis com os princípios do Manifesto Ágil descritos a seguir:

(1) indivíduos e interações, mais do que processos e ferramentas

(2) software em funcionamento, mais do que documentação abrangente

(3) colaboração com o cliente, mais do que negociação de contratos

(4) resposta a mudanças, mais do que seguir um plano

• Boas histórias devem possuir as seguintes características (cujas iniciais em inglês dão origem ao acrônimo INVEST):

1. Histórias devem ser independentes: dadas duas histórias X e Y, deve ser possível implementá-las em qualquer ordem. Para isso, idealmente, não devem existir dependências entre elas.

2. Histórias devem ser abertas para negociação. A equipe de desenvolvimento deve estar aberta para implementar detalhes que não estão expressos ou que não cabem nos cartões da história até a Confirmação. Clientes também devem aceitar argumentos técnicos vindos da equipe de desenvolvimento, por exemplo, sobre a inviabilidade de implementar algum detalhe da história conforme vislumbrado inicialmente.

3. Histórias devem agregar valor para o negócio. Histórias são propostas, escritas e priorizadas por clientes e de acordo com o valor que estas histórias agregam ao negócio. Por isso, não existe uma história técnica, como a seguinte: "o sistema deve ser implementado em JavaScript, usando React no front-end e Node.js no backend".

4. Deve ser viável estimar o tamanho de uma história. Por exemplo, quantos dias serão necessários para implementá-la. Normalmente, isso requer que a história seja pequena e que a equipe de desenvolvimento tenha experiência na área do sistema.

5. Histórias devem ser sucintas. Na verdade, até se admite histórias complexas e grandes, as quais são chamadas de épicos. 

6. Histórias devem ser testáveis, isto é, elas devem ter critérios de aceitação objetivos. 

4. Ferramentas

O quadro abaixo apresenta alguns dos nomes utilizados pelas ferramentas mais conhecidas no mercado: Scrum Half, Microsoft Azure Boards (Antigo Team Foundation Service – TFS), Rally (antigo C.A. Agile Central), Atlassian Jira, IBM Rational Team Concert (RTC), Trello e VersionOne. Na imagem, é possível observar que NÃO há uma padronização e isso acaba gerando uma certa confusão nas pessoas.

• Atualmente, a ferramenta Trello é a mais popular para a elaboração de um product backlog gratuitamente (com limitações).

• Histórias de Usuário e outras documentações como diagramas da UML podem coexistir.