Mapeamento de Histórias de Usuário

O mapeamento de histórias do usuário (ver Figura 1) é uma ferramenta valiosa para o desenvolvimento de software. Com ela é possível trabalhar com histórias de usuários à medida que são usadas em processos ágeis, e ajudar a equipe a manter o foco nos usuários e em suas necessidades.

De acordo com Jeff Patton (2014), mapas de história são mutáveis e permitem que a equipe obtenha melhores conversas sobre o projeto durante todo o processo de desenvolvimento, além de auxiliar na construção de uma visão compartilhada sobre “o que” se quer construir e “por quê”.

Ao observar os valores do manifesto ágil, pode-se dizer que o mapeamento de histórias está diretamente, alinhado a dois deles, sendo:

• Colaboração do cliente mais do que negociação do contrato; e
• Responder à mudança mais do que seguir um plano.

Figura 1. Visão Geral do Mapa de Histórias de Usuários.

A seguir, apresenta-se um exemplo de um mapa de histórias de usuário que representa o backlog da construção de um software gerenciador de e-mails (Figura 2).

Figura 2. Exemplo de um Mapa de Histórias de Usuários.

Backlog de Produto ou Mapa de Histórias?

Segundo os criadores do Scrum, Ken Schwaber e Jeff Sutherland, existem três aspectos fundamentais de um backlog:

• O backlog do produto é uma lista ordenada e emergente do que é necessário para melhorar o produto;
• O backlog é a única fonte do trabalho realizado pelo time Scrum;
• O Product Owner é responsável pelo gerenciamento eficaz do backlog.

A partir desse entendimento, de maneira geral, no contexto ágil, ao se identificar um conjunto de histórias de usuários, elas são inseridas no Backlog do Produto, o qual pode se tornar uma lista longa e plana (JEFF PATTON, 2014).

De acordo com Patton (2014), no início de projetos ágeis são identificados os objetivos, contexto do cliente, etc., assim como as histórias de usuário. Para tanto, pode-se utilizar oficinas de Lean Inceptio, ou DesignSprint, por exemplo. Todos os itens são organizados como se fossem uma árvore onde, as raízes sustentam a estrutura, o tronco conecta os galhos, e os galhos possuem folhas. As folhas representariam as histórias de usuário. A partir disso, conforme interpretação de Patton (2014), as folhas são retiradas dos galhos e colocadas em um saco de histórias, perdendo toda a conexão identificada, inicialmente. A Figura 3, ilustra esse entendimento.

Figura 3. Construção de uma Lista de Itens a fazer.

Com o mapeamento de histórias é possível transformar o Backlog do Produto em uma grande imagem (mapa), ao invés de uma lista de coisas a fazer. Com isso, tem-se (Figura 4):

• Um mapa que mostra os caminhos a serem percorridos;
• O posicionamento de cada história dentro do contexto do produto;
• A interação entre as histórias;
• Uma ferramenta de auxílio na organização, planejamento e acompanhemento do escopo do produto em um layout simples e útil.

Figura 4. Interação entre as Histórias de Usuário, no Mapa.

Neste contexto, o projeto pode decidir por utilizar o mapa de histórias ao invés de um backlog padrão (lista).

Ressalta-se ainda que, dependendo do contexto do produto pode-se utilizar as duas ferramentas de maneira complementar, caso haja a possíbilidade, por exemplo, de isolar o desenvolvimento de módulos de um mesmo produto. Dessa maneira, o escopo do módulo mais prioritário, e que será desenvolvido primeiro, passa a ser estruturado em um mapa. Enquanto o escopo dos outros módulos permanece como uma lista. Finalizando o primeiro módulo, pega-se o escopo do segundo, estrutura-se no mapa, e assim, sucessivamente.

Quando Utilizar o Mapa de Histórias?

O mapeamento de histórias pode ser utilizado desde o início da definição de um produto onde, de maneira colaborativa todos os envolvidos (área de negócio, equipes técnicas, patrocinadores, usuários finais) podem construir juntos. Também é possível passar a utilizar o mapa de histórias em projetos que já estão em andamento. Neste caso, deve-se pegar todas as histórias que estejam presentes no backlog do projeto e organizá-las dentro da estrutura de um mapa de histórias. A partir disso, o mapa passa a ser a fonte de requisitos do projeto, o qual deve ser constantemente atualizado.

Benefícios da Utilização do Mapa de Histórias

• Permite planejanejar e acompanhar a execução do produto (acompanhamento do status, atribuição de responsabilidade, etc.)(ver Figura 5);
• É possível manter o quadro geral da aplicação de maneira mais “completa” (para o momento);
• Tanto a equipe, quanto demais envolvidos conseguem manter uma visualização geral do produto em um único local;
• Mostra onde cada história de usuário se encaixa no sistema (produto de software) em uma única visualização;
• Facilita a escolha das histórias, a partir de diferentes funcionalidades que, juntas poderão fornecer um valor significativo (MVP ou um release útil);
• Ajuda a equipe a não se perder em relação a seleção e desenvolvimento das histórias;
• Permite caminhar pelo mapa de histórias visando testar possíveis caso de falhas (vendo mais claramente, o que pode estar faltando);
• Permite tomar decisões de priorização levando em conta o contexto do produto;
• O mapa tende a se tornar um ponto focal para a colaboração dos envolvidos, além de ajudar na criação de uma visão compartilhada;
• O contexto fornecido pelo mapa pode ajudar a dimensionar mais rapidamente as histórias e suas relação entre si;
• Pode-se informações extras ou marcar histórias que fazem parte da iteração atual e para a próxima iteração.

Figura 5. Planejamento e Acompanhamento com o Mapa de Histórias.

Referências Bibliográficas

- PATTON, Jeff. User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly, 2014.

- DevMads Ltd., StoriesOnBoard. Story Mapping Playbook: 50 hints and 100+ user story examples.

- Mathew, Jimmy. Agile Requirements: Managing Requirements in Scrum Framework.

- Kamat, Jatin. The Practical Guide To Creating User Stories: How To RAPIDLY Capture Requirements and Deliver Software In SCRUM (Agile Project Management).