O que é mapeamento de histórias no Agile?

Mapeamento de Histórias: Pintando o Grande Quadro das Histórias de Usuários de Seu Produto

Você olha fixamente para seu notebook. Uma longa lista de histórias de usuários olha de volta para você.

Você embaralha algumas, tentando colocá-las em uma ordem sensata.

Você reordena constantemente a lista. Ou para ver todas as histórias relacionadas à funcionalidade A, ou para ver as histórias mais importantes em todas as funcionalidades. Se isso for mesmo possível.

De novo e de novo você se perde.

O que você precisa é de um Mapa de Histórias. Vamos ver como você cria um usando Mapeamento de Histórias, mas primeiro, vamos descobrir o que elas são.

Story Mapping in Agile

Mapeamento de Histórias em Agile

O que é Mapeamento de Histórias (de Usuários)?

Mapeamento de Histórias ou Mapeamento de Histórias de Usuários é uma técnica utilizada na descoberta do produto: esboçar um novo produto ou uma nova funcionalidade para um produto existente.

O resultado é um Mapa de Histórias: todas as histórias de usuários organizadas em grupos funcionais. Isto ajuda você a manter os olhos no panorama geral e ao mesmo tempo fornece todos os detalhes de toda a aplicação.

Qual é o Propósito do Mapeamento de Histórias?

O principal objetivo do Mapeamento de Histórias é facilitar a descoberta de produtos e a priorização do trabalho de desenvolvimento. Isto se consegue colocando as atividades e tarefas dos usuários em um mapa que serve para mantê-los em contexto.

O Mapa de Histórias sempre mostra como cada história individual se encaixa em toda a aplicação. E isto facilita a identificação de lacunas e a decisão da importância de uma sobre as outras.

Que valores e princípios Agile o mapeamento de histórias sustenta?

O Mapeamento de Histórias sustenta dois valores do Manifesto Agile. “Colaboração do cliente sobre negociação do contrato” e “Responder à mudança sobre seguir um plano”.

Você obtém os melhores resultados quando colabora com um (futuro) usuário ou com um especialista de domínio. Alguém que está intimamente familiarizado com o trabalho que sua aplicação deve suportar e com os problemas a serem resolvidos.

Usando o Story Mapeamento de Histórias, é fácil responder às mudanças. Porque quando você adiciona uma nova história de usuário, ou muda ou remove uma já existente, é fácil identificar o que mais precisa ser adicionado, alterado ou removido.

Quem Criou o Mapeamento de Histórias?

Jeff Patton descreveu pela primeira vez o Mapeamento de Histórias em seu artigo “It’s All in How You Slice it” em 2005, quando ele já o estava usando há alguns anos. Mas ele não o chamou de “Mapeamento de Histórias” na época. Ele cunhou esse termo em seu artigo “The New User Story Backlog Is a Map” de 2008. Ele também escreveu um livro sobre o assunto: “User Story Mapping: Discover the Whole Story, Build the Right Product”.

Por Que Usar o Mapeamento de Histórias?

Quais São os Problemas que o Mapeamento de Histórias Soluciona?

Quando você terminar a descoberta de seu produto, você provavelmente colocará as histórias dos usuários no backlog de um quadro de Scrum ou Kanban.

Isso é bom para impulsionar o esforço de desenvolvimento uma vez que você tenha decidido sobre a ordem de desenvolvimento.

Entretanto, a capacidade de gerenciamento do backlog destas ferramentas fica aquém da capacidade de gerenciamento de produtos e releases. Simplesmente porque o backlog é mostrado como uma lista longa e plana. A filtragem, etiquetagem e coloração que você pode fazer ajuda um pouco, mas você nunca obtém o retrato completo.

O Mapeamento de Histórias resolve isso organizando as histórias dos usuários em um layout simples e útil.

Quais (Outros) Benefícios Você Recebe do Mapeamento de Histórias?

O Mapeamento de Histórias lhe proporciona uma série de benefícios diretos e indiretos.

  • Todos podem compreender facilmente toda a aplicação — em geral, a parte mais difícil do desenvolvimento de software. O Mapa de Histórias conta a história do que sua aplicação resolve e como o faz para qualquer um que esteja interessado. Todos podem participar da criação do mesmo.
  • Você mantém o quadro geral de sua aplicação em visão completa — perder o panorama geral é uma reclamação comum em equipes Agile.
  • Reunir e ter um Mapa de Histórias visível encoraja o desenvolvimento iterativo e incremental.

Ter o panorama geral na ponta de seus dedos

  • mostra onde uma história de usuário se encaixa em todo o sistema em um único relance.
  • ajuda você a decidir o que desenvolver primeiro. Um Mapa de Histórias facilita a escolha de histórias de usuários a partir de diferentes funcionalidades que, juntas, fornecerão um valor significativo. Isto significa que você pode determinar com confiança o escopo e construir um MVP ou um release útil.
  • significa que você pode mais facilmente evitar desenvolver algo que não funciona. Você não se perderá ou esquecerá peças importantes que efetivamente tornaria a aplicação inutilizável, como um carro sem freios. Por exemplo, porque você atrasou histórias de baixo valor das quais suas histórias de alto valor dependem.
  • permite que você caminhe pelo Mapa de Histórias para testá-lo em caso de falhas: ver mais facilmente onde algo está faltando.
  • permite que você tome decisões de priorização levando em conta o contexto de todo o sistema.
  • significa que você evitará ficar focado somente em uma única história de usuário.

Quando você cria um Mapa de Histórias físico, você obtém mais alguns benefícios.

  • O mapa se torna um ponto focal para a colaboração e ajuda na compreensão compartilhada.
  • O contexto completo fornecido pelo mapa ajuda a dimensionar rapidamente as histórias dos usuários em relação entre si.
  • Você pode adicionar adesivos menores aos cartões de histórias de usuários para adicionar informações extras ou marcar histórias para a iteração atual e para a próxima iteração.

Armadilhas e Erros

As armadilhas e erros mais importantes com o Mapeamento de Histórias são:

  • Trabalhar sem um cliente ou alguém intimamente familiarizado com seu trabalho

Você precisa colaborar com alguém que usa ou irá usar seu produto para auxiliar seu trabalho.

Sem a contribuição e perspectiva deles, você estará adivinhando o que é importante e o que lhe proporcionará valor real. Você estará jogando um jogo de acertos e erros e provavelmente desperdiçará esforços de desenvolvimento.

  • Sem objetivo, sem problemas a resolver

Trabalhando sem um problema a resolver, uma meta a alcançar, você não tem nada para orientar suas decisões e não terá nenhuma ideia quando estiver pronto. Levando ao desperdício de esforço, ou pelo menos a gastar esforço em algo na hora errada.

  • Não manter o mapa visível

Fora da vista, fora da mente. Sem o Mapa de Histórias servindo como um lembrete visível do grande panorama de sua aplicação, desviar o rumo é muito fácil. Assim como o perigo de se perder nas ervas daninhas: ficar preso aos detalhes de uma única história que são irrelevantes para o todo. Isto dói ainda mais quando esses detalhes exigiriam mais esforço do que o valor da história merece.

Embora um mapa físico da história seja preferível pelos benefícios extras que ele proporciona, com tantas equipes remotas hoje em dia, você nem sempre terá esse luxo. Mas você ainda pode mantê-lo altamente visível. Você pode, por exemplo, ter um monitor grande e dedicado mostrando o mapa em todos os locais onde você tem membros da equipe.

Como Criar um Mapa de Histórias em 6 Passos? (Com Exemplos)

1. Comece com as Grandes Rochas

Identificar as grandes histórias, as amplas atividades do usuário que sua aplicação precisa suportar. Elas são grandes histórias porque possuem muitas etapas. Estas etapas não precisam ter uma ordem ou fluxo de trabalho específico. Na verdade, muitas atividades do usuário têm etapas que um usuário fará em momentos diferentes e em horários diferentes.

Escreva cada atividade em um cartão. Organize-as em uma ordem que faça sentido para o usuário. Se alguém falar em fazer uma atividade e depois outra, organize-as nessa ordem. Se as atividades não forem feitas uma após a outra, simplesmente use a ordem que o usuário fala sobre elas. Isso ajudará a contar a história da aplicação para outros.

Digamos que você está construindo um site do Clube de Eventos Divertidos. Os visitantes podem procurar por eventos divertidos para participar. Os membros podem participar e sediar eventos. E a equipe por trás do site serve como moderadores e verifica se os novos eventos estão em conformidade com as diretrizes.

As grandes rochas deste site, as atividades dos usuários, poderiam então ficar assim.

story mapping

2. Quebre e Abra Suas Rochas

Divida a história de cada atividade do usuário em histórias menores, as tarefas do usuário. Coloque as tarefas do usuário sob a atividade a que pertencem e organize-as na mesma direção que as atividades e na ordem que faz sentido para o usuário.

Para o Clube de Eventos Divertidos, ficaria assim.

Agora você tem o que é chamado de espinha dorsal do seu Mapa de Histórias.

A maioria das tarefas do usuário possui etapas ou subtarefas independentes próprias. Você coloca essas subtarefas abaixo (se você estivesse indo horizontalmente) da tarefa do usuário à qual elas pertencem.

Isso ficaria assim.

user-activities

Tanto as tarefas quanto as subtarefas do usuário se tornam as histórias de usuário que você implementará. Afinal, um usuário ainda precisa selecionar um evento de uma lista para ver seus detalhes ou juntar-se a ele imediatamente.

3. Encontre As Pedrinhas Que Escaparam

Percorra o mapa do começo ao fim com outra pessoa ao seu lado. Este pode ser um usuário, um desenvolvedor, um testador ou outra pessoa com um interesse na aplicação.

Fale sobre os (tipos de) usuários de sua aplicação e como eles estão usando sua aplicação. É uma espécie de debug com pato de borracha para seu Mapa de Histórias. E, muito naturalmente, vai trazer à tona coisas que você perdeu. Ou por você mesmo pensar nelas, ou porque seu companheiro indica.

Acontece que, para o Clube de Eventos Divertidos, faltaram algumas.

Break down the story

Quando você estiver percorrendo o mapa com alguém, aproveite a oportunidade para fazer anotações no Mapa de Histórias com outras informações que você ouvir. Pain points no sistema atual, oportunidades pelas quais um usuário tem esperado. Casos de limite e restrições que você precisa levar em conta. Escreva-os em um adesivo e coloque-os no cartão relevante.

4. Organize Suas Pedrinhas em Linha

Há pouco sentido em priorizar as atividades do usuário. Além das atividades que não serão usadas diariamente, é altamente provável que algo de cada atividade seja necessário para criar um conjunto de trabalho.

Portanto, concentre-se na priorização das tarefas e subtarefas do usuário dentro de cada atividade. A vantagem adicional é que você não precisa pensar sobre a importância relativa das tarefas pertencentes a diferentes atividades.

Em nosso exemplo do Clube de Eventos Divertidos, as subtarefas já estão em ordem de importância. Um pouco de otimização prematura por parte de seu autor.

5. Esculpa uma Valiosa Primeira Rocha de suas Pilhas de Pedrinhas

Selecione as tarefas de cada atividade que são essenciais para criar uma primeira versão que funcione de ponta a ponta, mesmo que ainda seja de uma forma muito rudimentar. Esse é o seu MVP, seu Minimum Viable Product (Produto Mínimo Viável).

Story Mapping Board

6. Continue Esculpindo

Planeje seus releases posteriores priorizando as tarefas restantes. Depende inteiramente de como você quer avançar.

Você pode optar por priorizar as histórias de maior valor de várias ou mesmo de todas as atividades do usuário. Você também pode optar por se concentrar em uma única atividade e priorizar todas as histórias de maior valor, exceto as de menor valor. E talvez os executivos de sua empresa queiram levar outros aspectos em consideração. Eles estão na melhor posição para decidir quais funcionalidades e histórias fazem um bom release.

Em vez de traçar linhas entre as histórias para marcar quais vão para lançamentos posteriores, você também pode reorganizar o mapa para mostrar lançamentos como intervalos horizontais de histórias.

Story Mapping Roadmap

Usando o Mapeamento de Histórias com Aplicações Existentes

O Mapeamento de Histórias não é apenas para novas aplicações. Você pode usá-lo também para aplicações existentes.

Para ajudá-lo a entender o que uma aplicação faz e recriar seu grande panorama para que você possa tirar proveito disso ao seguir em frente.

E, claro, para mapear novas características e colocá-las em contexto com a aplicação existente.

Se você não puder (não for permitido) construir primeiro um Mapa de Histórias completo da aplicação existente, ao menos coloque todas as atividades existentes do usuário em prática.

Isto lhe dará o contexto para novas funcionalidades.

E também lhe dará um lugar para colocar as tarefas que você precisa adicionar ou alterar nas atividades existentes do usuário. Por exemplo, quando você cria um novo recurso para enviar e-mails direcionados. Você precisará adicionar a seleção de múltiplos contatos na lista de contatos existentes. E você provavelmente precisará adicionar alguns recursos extras de filtragem também.

Se Torne um Contador de Histórias

story-telling

Lembra-se da dor de ter que priorizar as histórias em um extenso e plano backlog?

E quão difícil era explicar a aplicação a outras pessoas?

Agora você sabe como o Mapeamento de Histórias pode lhe ajudar. Priorizar as histórias e preparar releases que forneçam valor significativo. E para contar a história de sua aplicação, de como os usuários irão usá-la. Simplesmente percorrendo o Mapa de Histórias.

Então, faça o futuro você feliz e beneficie-se do Mapeamento de Histórias. Em uma parede, ou com uma ferramenta digital. Por exemplo, com o Mapeamento de Histórias da Digité.

Mapeamento de Histórias: Pintando o Grande Quadro das Histórias de Usuários de Seu Produto

A vida é boa quando suas equipes Agile estão sincronizadas!

Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.

Solicitar Demonstração