Nós construímos software para ajudar as pessoas - os usuários e os clientes - a alcançarem seus objetivos. Esta é a única maneira da sua organização conseguir o que almeja: faturamento para empresas ou um impacto mensurável para organizações sem fins lucrativos.

Para construir qualidade em software, empregamos uma variedade de práticas como Desenvolvimento Orientado a Testes (Test-Driven Development, TDD) e Integração Contínua (Continuous Integration). Essas práticas são ótimas para diminuir o número de defeitos no código mas, sozinhas, não garantem que o software desenvolvido contenha os conceitos do domínio do negócio tampouco que ajude as pessoas de forma efetiva a alcançarem seus objetivos. É muito fácil desenvolver o software errado.

É por isso que as metodologias Ágeis incluem práticas que melhoram a comunicação e a colaboração. Por exemplo, o Scrum tem eventos como o Daily Scrum, o Planejamento da Sprint (Sprint Planning) e a Retrospectiva da Sprint (Sprint Retrospective). O Extreme Programming tem o Time Coeso (Whole Team) e as Metáforas de Sistema (System Metaphor). Ambas as metodologias fazem uso do Desenvolvimento Iterativo, não apenas para entregar software funcional frequentemente, como também para provar a hipótese de valor do software entregue. Estas práticas são baseadas nos princípios do Manifesto Ágil de redução do risco de desenvolver o software errado.

Entregar software funcional que deixa as pessoas felizes não significa que o time está criando entendimento compartilhado como tampouco significa que o design do software tem os conceitos do domínio onde opera. E aqui vai uma crítica aos meus camaradas desenvolvedores, uma que escuto frequentemente: na correria para desenvolver uma funcionalidade solicitada, nós evitamos as conversas que ajudam a criar entendimento compartilhado do negócio em favor de discussões técnicas.

A crítica é benéfica porque mostra que as pessoas de negócio estão interessadas em criar este entendimento compartilhado, que elas estão incorporando os princípios do Manifesto Ágil. Mas estamos pulando direto para a implementação, perdendo uma oportunidade de aprender o domínio e de modelar o software com os conhecimentos do domínio. Eric Evans (2003) vai além:

(…) se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvido dessa maneira, mas o projeto nunca chegará em um ponto onde novas funcionalidades poderosas surgirão como corolárias de funcionalidades existentes (Evans, 2003)

Como motivar os desenvolvedores a se interessarem mais sobre o domínio do negócio? O Mapeamento de Estórias de Usuário pode ajudar.

Um mapa incipiente do Wikidu

Mapeamento de Estórias de Usuário

O Mapeamento de Estórias de Usuário (User Story Mapping) é um padrão descoberto por Jeff Patton que ajuda times a entenderem um produto ou funcionalidade completa, com o objetivo de construir um produto melhor:

Mapear estórias nos mantém focados nos usuários e na sua experiência, resultando em melhores conversas e, ultimamente, em um produto melhor. (Patton, 2014)

A excepcional documentação que Patton criou joga uma luz em como as estórias1 tem sido mal usadas, fazendo com que times caíssem em uma ou mais armadilhas, aos quais destaco duas:

  • O backlog plano: estórias permitem que times foquem em construir pequenas coisas, perdendo a visão do horizonte maior. Frequentemente resulta em produtos Frankenstein, onde o produto parece ter sido montado com partes que não se encaixam
  • Forma ao invés de substância: quando há foco apenas em escrever estórias ao invés de criar entendimento compartilhado

Eu incluo uma introdução rápida para explicar melhor como o padrão ajuda a motivar todos na criação de entendimento compartilhado. Você precisará de notas adesivas (post-its), canetas e uma mesa ou parede (ou um quadro branco).

A coluna backlog não mostra a visão desse produto

Introdução

Configure um timebox (10 minutos no máximo), e peça que as pessoas escrevam, em silêncio, as tarefas que os usuários farão na sua aplicação. Essas tarefas de usuário são coisas como “Solicitar uma corrida”, “Avaliar o livro”, “Adicionar produto ao carrinho”. Uma vez que todo mundo terminou, peça às pessoas que leiam cada nota e a coloquem em cima da mesa. Se houver tarefas duplicadas, elimine-as. Em resumo, os passos são: pense, escreva, explique e posicione.

Você descobrirá algumas coisas interessantes durante o processo:

  • A maioria das notas serão de frases verbais curtas
  • As pessoas irão organizar as tarefas intuitivamente num fluxo ordenado, com as tarefas que devem ocorrer primeiro no lado esquerdo com as conseguintes após elas
  • Algumas notas irão conter tarefas que acontecem ao mesmo tempo que outras tarefas. Essas são sub-tarefas. Numa aplicação de software, podem ser passos adicionais e/ou opcionais que o usuário dará

Agora que você identificou as tarefas do usuário, é hora de organizar seu mapa. Intuitivamente, parte desse trabalho já foi feito: tarefas que devem acontecer primeiro foram colocadas no lado esquerdo, com tarefas posteriores seguindo-as. Empilhe as sub-tarefas abaixo das tarefas principais.

Para validar se este fluxo está consistente, comece a contar a estória do seu mapa: aponte para a primeira tarefa dizendo “Primeiro o usuário faz isso” e, então, aponte para a próxima dizendo “e então ele faz isto” até a última tarefa.

Este é o “fluxo narrativo” como definido por Patton. Re-ordene a posição das tarefas se a narrativa parecer sem sentido. Você sempre irá encontrar ausência de detalhes porque o mapa o ajuda a ver o horizonte do produto, o todo. Preenche os detalhes que faltam enquanto completa o mapa.

Prove a consistência do seu mapa contando a estória dele

O próximo passo é o de destilar o mapa. Dê um passo para trás e preste atenção no fluxo narrativo. Você encontrará grupos de tarefas que são muito próximas. As tarefas de um usuário de e-commerce, “Adicionar ao carrinho”, “Estimar frete” e “Fazer checkout” poderiam ser agrupadas em uma atividade “Fazer pedido”. Em uma rede social, “Procurar por nome”, “Visitar o perfil da pessoa” e “Adicionar contato” poderiam ser agrupados em atividades como “Conectar” ou “Fazer amizade”.

Escreva o nome da atividade em uma nota e a coloque acima do grupo de tarefas correspondente. Valide se o fluxo narrativo ainda está consistente, lendo as atividades da mesma forma que você leu as tarefas. As atividades formam a coluna vertebral do mapa.

A coluna vertebral do mapa é formada pelas suas atividades

Adicionado contexto ao mapa

Uma mapa pode ter mais que tarefas e atividades de usuários. Você pode adicionar mais informações importantes ao mapa, ajudando a criar entendimento compartilhado:

  • Oportunidades e hipóteses. Por quê construí-lo? Que tipo de problema resolve?
  • Princípios do produto. Exemplos: divertido, fácil, acessível (isto deveria ser um princípio de qualquer produto!), amigável, rápido
  • Clientes e usuários. Quem são os usuários? Quais os diferentes papéis desses usuários? Por quê eles irão usar o produto? O que nós achamos deles? Quais tipos nós iremos priorizar agora?
  • Detalhes, opções, dúvidas. Mais detalhes sobre as tarefas e atividades podem ser adicionadas assim como alternativas. Notas com dúvidas podem ser adicionadas caso alguém não tenha certeza sobre como irá funcionar. Observações sobre como outros serviços - competidores ou não - resolveram o problema podem ser colocados no mapa.

Você pode usar notas adesivas de diferentes cores e colocar esta informação onde for mais útil para fins de contextualização.

Enriqueça sua conversa adicionando mais contexto no seu mapa

Criar entendimento compartilhado é a chave

O que realmente importa durante a criação do mapa é o entendimento compartilhado criado atráves de melhores conversas. Esta era a ideia do Kent Beck quando introduziu o conceito de estórias: para trocar o foco de documentos compartilhados por entendimento compartilhado.

Apenas escrever estórias como documentos compartilhados não ajuda a criar entendimento compartilhado porque quando alguém lê uma estória, pode interpretá-la de forma diferente do autor da estória. A única forma possível é externalizando nossas ideias. A estória escrita se torna então um meio, e não um fim.

Como isso pode motivar desenvolvedores que só pensam em tecnologia?

Como desenvolvedor, eu sei muitos dos motivos que fazem com que desenvolvedores fiquem menos preocupados com o negócio. Uma delas é a ausência de visão de produto, a falta de um horizonte. Roadmaps são constantemente criados para prover esse horizonte mas não são visuais o suficiente ou atualizados para comunicar claramente em que ponto da jornada o time está. E o backlog plano pode dar a impressão que o único trabalho dos desenvolvedores é o de processar novas estórias.

Isto os aliena dos objetivos de negócio, perdendo então o interesse sobre o domínio. E como desenvolvedores gostam de construir coisas, é fácil focar a atenção no lado tecnológico e resolver problemas de domínio com tecnologia (Evans, 2003).

Como ferramenta visual, um mapa pode claramente radiar informação sobre este horizonte. Pode ser usado para priorizar estórias a serem trabalhadas (Patton explica técnicas de priorização em seu livro). É um roadmap vivo. Os desenvolvedores podem entender o quê e o porquê do que estão trabalhando e como isso se encaixa no horizonte.

Pedir ajuda aos desenvolvedores para criar o mapa (acho que o primeiro mapa deve ser criado com a colaboração do time inteiro) pode ajudar não apenas com diferentes pontos de vista como também com ideias interessantes e valiosas (desenvolvedores tendem a ser early adopters de todo tipo de tecnologia, de aplicativos à wearables). Quando eles começarem a perguntar o porquê/o quê/como, não estarão apenas ajudando a criar entendimento compartilhado, como também exibindo disposição para aprender sobre o negócio.

Criar o mapa pode ajudar também a criar relacionamentos fortes entre os membros do time e a desenvolver valores como respeito e coragem. Se o time for além e tentar entender melhor os usuários/clientes e criar personas2, podem criar empatia pelos usuários nos desenvolvedores. Relacionamentos mais fortes entre os membros do time, mais consciência sobre os objetivos do negócio e mais empatia pelos usuários pode fazer emergir um dos três elementos da motivação: propósito (Pink, 2009). Propósito é o anseio de fazer o que fazemos por algo maior que nós mesmos. Pessoas que encontram o propósito no seu trabalho alcançam o último nível do jogo da motivação.

Mapeie para ajudar na sua adoção de DDD e para produzir uma Linguagem Ubíqua

O livro Domain-Driven Design (DDD) de Evans introduziu uma nova abordagem de desenvolvimento de software que baseia a implementação do design em um modelo do domínio. Pode ajudar a alcançar um nível onde o design é exatamente como o software funciona (Vernon, 2013), por meio de ferramentas estratégicas e táticas que ajudam a projetar software de alta qualidade e que satisfaz os objetivos do negócio (core business).

Como abordagem, DDD não é sobre tecnologia:

DDD é sobre discussões, escutar, entender, descobrir, valores de negócio, tudo no esforço de centralizar o conhecimento. Se você for capaz de entender o negócio sobre o qual a sua empresa opera, você pode no mínimo participar no processo de descoberta de modelagem de software para produzir uma Linguagem Ubíquia (Ubiquitous Language) (Vernon, 2013)

Para construir um modelo de domínio e efetivamente adotar DDD, é necessário processar conhecimento3. “Centralizar o conhecimento” é um sinônimo de “criar entendimento compartilhado”. Evans diz que modeladores de domínio são processadores de conhecimento e enfatiza que isto é uma atividade de time (e um requisito para a prática de DDD):

Processamento de conhecimento não é uma atividade solitária. Um time de desenvolvedores e especialistas no domínio colaboram, tipicamente liderados por desenvolvedores. Juntos eles obtêm informações e a processam em um formato útil. A matéria prima vem das mentes dos especialistas no domínio, dos usuários de sistemas existentes, da experiência prévia do time técnico com o sistema legado ou de outro projeto no mesmo domínio. Vem na forma de documentos escritos para o projeto ou usados no negócio, e de muitas e muitas conversas. Primeiras versões ou protótipos retroalimentam o time e mudam interpretações. (Evans, 2003)

Desse processamento de conhecimento, o time (desenvolvedores e especialistas no domíno) devem desenvolver uma Línguagem Ubíqua, que é uma linguagem compartilhada. O vocabulário dessa linguagem é centrado em como o negócio em si pensa e opera (Vernon, 2013) . Esta linguagem previne desendentimento entre as pessoas de negócio e os desenvolvedores ao remover a necessidade de traduções entre conceitos de negócio e as abstrações usadas no design do software.

A Linguagem Ubíqua é um dos pilares do DDD ao lado dos Contextos Delimitados (Bounded Context) (Vernon, 2013) . Seu vocabulário inclue nome de classes e operações proeminentes, sendo o principal portador dos aspectos do design que não aparecem no código (Evans, 2003).

É aqui que o Mapeamento de Estórias pode ajudar na sua adoção de DDD. É uma técnica incrível para começar o processamento de conhecimento e produzir o glossário inicial da Linguagem Ubíqua. Faça esse esforço de forma colaborativa: irá ajudar a formar o seu time e irá motivá-los a terem as conversas necessárias.

Mapeie para avaliar a complexidade do seu domínio

No Implementing Domain-Driven Design, Vernon apresenta um scorecard4 para ajudar times a determinarem se vale a pena adotar DDD em um projeto. Se você tiver uma pontuação maior ou igual a sete, considere a adoção de DDD.

Se o seu projeto Pontos Considerações de apoio
Se sua aplicação é completamente centrada em dados e qualifica-se para uma solução CRUD pura, onde cada operação é basicamente uma simples consulta no banco de dados para Criar, Ler, Atualizar ou Apagar, você não precisa de DDD. Seu time precisa apenas colocar uma cara bonita em cima de um editor de tabelas de banco de dados. Em outras palavras, você pode confiar nos seus usuários inserindo dados diretamente em uma tabela, atualizá-los, e de vez em quando apagá-los, você pode nem precisar de uma interface. Isto não é realista, mas conceituamente relevante. Você poderia até usar uma simples ferramenta de desenvolvimento de banco de dados para criar uma solução, não gaste o tempo e dinheiro da sua empresa com DDD. 0 Isto parece simples, mas geralmente não é fácil determinar o simples versus o complexo. Não é como se cada aplicação que não é um CRUD puro merecesse o tempo e esforço de adotar DDD. Então talvez pudéssemos ter outras métricas úteis para delinear o que é complexo e o que não é…
Se o seu sistema requer apenas 30 ou menos operações de negócio, provavelmente é muito simples. Isto significaria que sua aplicação teria não mais que 30 estórias de usuário or fluxos de caso de uso, cada um desses fluxos tendo lógica mínima de negócio. Se você puder rapidamente e facilmente desenvolver tal aplicação usando Ruby on Rails ou Groovy and Grails e não sentir a dor da falta de poder e controle sobre complexidade e mudança, seu sistema provavelmente não precisa de DDD. 1 Pra ser claro, eu estou falando de 25-30 métodos de negócio únicos, não 25-30 interfaces completas de serviços, cada qual com múltiplos métodos. O último pode ser complexo
Vamos dizer que em algum lugar no intervalo de 30 a 40 estórias de usuário ou fluxos de caso de uso poderia indicar complexidade. Seu sistema pode estar entrando no território do DDD. 2 Atenção: frequentemente complexidade não é reconhecida cedo o suficiente. Nós desenvolvedores de software somos, de fato, bons em subestimar complexidade e esforço. Apenas porque possamos querer codificar uma aplicação usando Ruby ou Grails não significa que devemos. No longo prazo, isto pode mais atrapalhar que ajudar
Mesmo que a aplicação não vá ser complexa agora, a complexidade irá aumentar? Você pode não saber com certeza até que os usuários reais comecem a usá-la, mas há um passo em Considerações de apoio que pode ajudar a descobrir a situação real.

Tenha cuidado. Se há alguma dica de que a aplicação tem até mesmo complexidade moderada - esta é uma boa hora pra ser paranóico - pode ser um indicador suficiente que irá ser realmente mais do que moderadamente complexa. Considere DDD.		 3 Aqui vale a pena revisar os cenários de uso mais complexos com especialistas no domínio e ver onde isto leva. Os especialistas de domínio…

(1) já pediram funcionalidades mais complexas? Se sim, é um indicador suficiente que a aplicação já é ou em breve se tornará muito complexa para usar uma abordagem CRUD.

(2) estão tão entediados com as funcionalidades que dificilmente suportam discutí-las? Provavelmente não é complexo.
As funcionalidades da aplicação irão mudar frequentemente ao longo dos anos, e você não pode antecipar que tipos de mudanças serão simples 4 DDD pode ajudar você a gerenciar a complexidade da refatoração do seu modelo ao longo do tempo.
Você não entende o Domínio porque ele é novo. Tão longe quanto você e seu time sabe, ninguém fez isto antes. Isto provavelmente significa que é complexo, ou ao menos merece a diligência devida com escrutínio analítico para determinar o nível de complexidade 5 Você precisará trabalhar com especialistas no domínio e experimentar com modelos para conseguir fazer certo. Você provavelmente pontuou em ou ou mais dos itens anteriores, então use DDD.

Após concluir o seu mapa, você verá o horizonte do produto que você quer construir. Você se lembra das tarefas de usuário? Elas são as estórias que o seu time precisará desenvolver. Cada uma pode ter n sub-tarefas ou fluxos alternativos. Conte-as e você saberá se o você pontuou no segundo ou terceiro caso. Outros indicadores de complexidade são a densidade visual do mapa e a quantidade de papéis de usuário (e a forma como eles influenciam as tarefas).

Obviamente o mapa sozinho pode não ser suficiente para avaliar a complexidade do seu projeto. Por exemplo, muitas startups exploram oportunidade de negócio que se encaixam no último caso. E quando uma startup depende de uma aplicação de software para o seu negócio, você deve esperar que suas funcionalidades irão mudar ao longo do tempo para melhor suportar seu crescimento e sua continuidade. Use o mapa como uma matéria-prima para sua avaliação.

Conclusões

Mapeamento de Estórias de Usuário é um padrão simples mas intuitivo que resgata a ideia original das estórias do Kent Beck: de ter uma boa conversa para o bem do entendimento compartilhado. Como uma tarefa colaborativa, ajuda na formação e motivação do time.

Alguns praticantes ágeis podem temer que o mapeamento de estórias seja muito planejamento. Não é para ser. Construa o primeiro mapa para descobrir a narrativa e então o use para priorizar as estórias a serem desenvolvidas. Quando estiverem próximas a serem priorizadas para serem desenvolvidas, inicie o processamento de conhecimento para identificar o que você precisa aprender.

Mantenha-o como um documento vivo e o atualize cada vez que você descobrir algo novo. Atualize o fluxo narrativo enquanto você valida a sua hipótese de valor. Use o mapa como seu backlog, sem perder a visão de horizonte!

Curiosamente, alguns desenvolvedores acostumados a desenvolvimento Ágil temem que DDD podem levá-los a fazer design prematuro. Minha crença pessoal é que esta impressão é causada pela ênfase nas conversas e nos diagramas encontrada na literatura. Você precisa discutir porque precisa aprender os princípios do negócio por trás da estória. Os diagramas são apenas abstrações, eles não necessariamente refletem o design futuro: muito será deixado para ser descoberto e é aqui que TDD brilha.

Por último mas não menos importante, Mapeamento de Estórias pode ser valioso na sua avaliação da adoção de DDD. Se seu projeto é complexo e você adotar a abordagem DDD para desenvolvimento de software, o mapa pode ajudar a iniciar o processamento de conhecimento e na produção inicial do glossário da Linguagem Ubíqua.

Agradecimentos

Obrigado ao Nelson Senna e Fernando Ike pela revisão e pro Vaughn Vernon pelo feedback positivo.

Referências

  1. Eu uso o substantivo estória ao invés de estória de usuário por conveniência. Estórias são amplamente usadas em metodologias Ágeis para propósitos de planejamento. Introduzidas por Kent Beck, estórias encorajam conversas informais para a criação de conhecimento compartilhado. ↩

  2. Uma persona é uma representação escrita de um usuário específico ao qual pode ser usada para tomar decisões sobre funcionalidade do software. Patton descreve uma forma pragmática de criar personas. ↩

  3. Como no restante desse texto, a tradução é livre. Uma tradução literal seria triturar conhecimento (to crunch knowledge). ↩

  4. Uma explicação completa do scorecard do DDD também está disponível no site do InformIT ↩