Mais um termo utilizado pelos “agilistas”. São tantos termos relacionados à Agile, que está ficando difícil decidir por quais práticas utilizar, principalmente para quem está começando, pois as práticas ágeis, apesar de existir já há bastante tempo, vem sendo empregadas, mais massivamente, somente nos últimos anos, e ainda com diversas variantes. A princípio os resultados obtidos estão sendo bastante satisfatórios. Essas diversidades de práticas ágeis ocorrem por cauda de alguns motivos, como: A maioria das abordagens ágeis não são metodologias, ou seja, não tem uma receita de como fazer e sim o que fazer. Isto propicia a adaptabilidade dos processos ágeis. E outro motivo poderia ser a busca pelo aperfeiçoamento das práticas ágeis.
Dá-se a entender que o Story Mapping é um desses aperfeiçoamentos. É uma evolução do Product Backlog do Scrum e das User Storie do XP. Veja a definição dada por Patton a Story Mapping:
“Story Mapping é uma técnica colaborativa, que auxilia na priorização e planejamento de releases de produtos interativos.”
Para criar uma Story Mappin, primeiramente, faz-se necessário levantar os requisitos, que serão descritos no formato de User Stories. Essa técnica de escrever os requisitos como User Stories também é muito utilizada no Scrum para representar itens do Product Backlog. Lembrando que o Product Backlog é uma lista de funcionalidades que o sistema deve ter, essa lista é priorizada pelo Product Owner, sendo que os itens de maior importância, de maior valor para o negócio, estarão sempre no topo da lista. Bom, voltando ao Story Mapping, este além de priorizar as funcionalidades pelo seu valor de negócio, prioriza também o quão útil uma funcionalidade é para o usuário. Em certo ponto isso é interessante, pois, favorece o agrupamento lógico de funcionalidades, ou de atividades. Outro ponto positivo da Story Mapping é que após a organização das stories (alocadas nos eixos Necessidade X Sequencia de uso), dá para se ter uma visão ampla do produto, ou melhor, uma visão do todo. Assim fica bem visível o fluxo, as dependências e os itens de cada release do produto.
Com relação aos pontos negativos, observa-se que um produto que tem muitas funcionalidades pode tornar o controle manual ou visual (muito utilizado nos ambientes ágeis) um pouco difícil devido a sua alta extensibilidade. Outro aspecto está relacionado à definição do grau de uso de uma funcionalidade, fica difícil identificar o “quão útil” uma funcionalidade é para um determinado usuário, se, por exemplo, for um produto novo que não seja possível identificar ou medir a experiência do usuário. Esta definição dos releases, dá-se a entender que, deve-se levantar ou identificar todos os requisitos do sistema para poder priorizá-los e agrupá-los, em certa parte sim, mas o detalhamento das funcionalidades só ocorrerá conforme a Sprint em execução, ou conforme a necessidade.
Concluindo, a técnica de priorização de funcionalidades por Story Mapping é uma boa prática, cobre algumas falhas do Scrum na questão de priorização e organização dos requisitos, mas requer um entendimento maior. Scrum e XP já atendem boa parte das necessidades do gerenciamento de projetos ágeis. O grande desafio está em conhecer e saber quando utilizar cada técnica. Então temos que conhecer algumas práticas ágeis, mas não todas, então se você está indo bem com somente o Scrum, ou somente com o XP ou com ambos e mais alguma coisa, continue assim, não vá utilizando uma técnica sem estudos, só porque fulano de tal o “guru” do ágil disse que era bom. Então, antes de implementar uma nova técnica em seu processo de desenvolvimento, analise com calma e veja o que a comunidade ágil diz. Finalizando, penso que não devemos pesquisar todas as práticas ágeis existentes, porque são muitos termos e siglas, Scrum, Cristal, Learn, XP, FDD, TDD, DDD, XDD e YDD (estes dois últimos por minha conta, talvez até existam!). O que tornaria o aprendizado demasiadamente demorado e sem foco.
