Como utilizamos o EventStorming para tornar os nossos processos claros

Como qualquer outra empresa, temos muitos processos no Easy LMS. Por exemplo, como lidamos com tickets de suporte ou desenvolvemos novos recursos. Utilizamos o Improvement Kata para otimizar os nossos processos. Um dos primeiros passos é especificar a situação atual. No entanto, acontece que cada um tem a sua própria visão sobre o que é a situação atual. EventStorming é uma técnica que utilizamos para definir os nossos processos de forma inequívoca.

Imagine que é um novo funcionário a entrar numa empresa. É colocado em contacto com um membro da equipa mais experiente e passa por todos os processos empresariais, na sua maioria não documentados. Cria um modelo mental do processo fazendo perguntas e lendo a documentação. Quanto mais experiência ganhar, menos perguntas terá de fazer e menos documentação terá de ler. A maior parte das coisas é feita de forma (semi-)automática.

Uma documentação menos actualizada sobre um processo conduzirá a uma maior variação nos modelos mentais que os funcionários têm desse processo.

Depois, se comparar a forma como lida com o processo com outro membro da equipa, verá que faz algumas coisas de forma bastante diferente. Isto acontece porque os vossos modelos mentais são diferentes.

Quando se optimiza um processo utilizando o Kata de Melhoria, pode ser difícil descrever a situação atual quando os modelos mentais diferem significativamente. Se ao menos tivéssemos uma forma de transformar estes modelos mentais em documentação.

Como chegámos à EventStorming

No início de 2020, participei da conferência Domain-Driven Design Europ para aprender mais sobre como modelar melhor nosso software. Um workshop que eu queria participar era sobre EventStorming. Já tinha lido sobre o assunto e pensei que poderia ajudar-nos a tirar o conhecimento específico do domínio da cabeça dos nossos especialistas de uma forma que fosse fácil de partilhar com os programadores. O que significa que poderíamos criar um software melhor. Descobri que o EventStorming é muito útil para modelar software, mas também para modelar processos empresariais!

Infelizmente, a pandemia chegou. Fechámos o nosso escritório e começámos a trabalhar remotamente. O EventStorming gira em torno de ter um grupo de especialistas numa sala a trabalhar numa grande superfície partilhada. Isto já não era possível de organizar. Felizmente, Alberto Brandolini, o fundador do EventStorming, também se apercebeu disso e organizou outro workshop para resolver este problema: Remote EventStorming. Participei nele e depois esperei por uma oportunidade para experimentar o EventStorming.

Modelação do nosso processo de desenvolvimento com o EventStorming

Nos últimos meses, temos vindo a alterar muito o nosso processo de desenvolvimento. Por vezes, o processo falhava e tornava-se evidente que já ninguém tinha uma visão global do processo. O processo candidato perfeito para experimentar o EventStorming!

Digo à equipa que quero experimentar o EventStorming. Estou confiante de que podemos obter uma boa visão geral do processo de desenvolvimento atual ao fazer isto. Convido um par de programadores interessados de ambas as equipas e crio um quadro branco remoto partilhado utilizando o Miro. Seguimos os passos predefinidos do EventStorming:

1. Exploração caótica: crie notas adesivas para todos os eventos que você pode pensar que acontecem no processo.

2. Faça a linha do tempo: ordene os eventos do início do processo até o final.

3. Enriquecendo os eventos: adicione meta informações a cada evento. O comando (ação) que dispara o evento, os dados necessários, o sistema que actua e a política que diz o que fazer a seguir.

Exploração caótica

No início, parece um pouco estranho. Mas assim que aparecem as primeiras notas autocolantes, o ritmo acelera e toda a gente se envolve.

Começamos por dar a todos os participantes o seu próprio pedaço de quadro branco e uma cor (mas não laranja, mais tarde falaremos sobre isso). Têm 25 minutos para criar notas autocolantes para todos os eventos de que se lembrem e que ocorram durante o processo. Um evento é algo que aconteceu no passado e que já não pode ser alterado. É por isso que os escrevem no pretérito perfeito. Por exemplo: "Repositório de código criado" ou "Código implementado no ambiente de produção".

Encorajo-os a "fazer batota" e a olhar para os eventos que os outros participantes escrevem, porque isso pode abrir uma parte totalmente nova do processo em que não pensaram antes. Não há problema nenhum em acrescentar eventos que outros participantes também tenham.

Aplicação do calendário

Depois de verificar que não aparecem novas notas autocolantes no quadro, passamos à etapa seguinte. Desenho uma linha no quadro branco. Depois, peço a todos que escolham a sua nota autocolante sobre o evento que acontece primeiro no processo de desenvolvimento e que a coloquem por cima da linha do tempo. Em breve, discutimos qual o evento que é realmente o primeiro e colocamo-lo no início da linha de tempo. Para significar que todos concordamos com este evento e com o seu lugar na linha do tempo, mudamos a cor da nota adesiva para laranja (é por isso que não havia notas adesivas desta cor antes?). Depois, passamos para o evento seguinte.

Entramos numa discussão mais alargada sobre um acontecimento. Para manter o fluxo, crio um tipo especial de nota adesiva chamada hotspot. Nela, descrevo o problema e depois avançamos. Voltaremos aos hotspots mais tarde. Encontramos um evento que foi criado por vários participantes. Mantemos aquele que descreve melhor o evento e removemos os outros. Também adicionamos ramos para eventos condicionais. Colocamo-los acima ou abaixo da linha de tempo do processo principal.

Após duas horas e meia, paramos. A linha de tempo está concluída e todos os pontos críticos estão resolvidos. Toda a gente está energizada e planeamos imediatamente a próxima reunião para tornar o processo mais claro, enriquecendo os eventos com metadados.

Enriquecer os eventos com metadados

Para explicar este passo, é melhor usar uma imagem:

No início do nosso (sub)processo (nota autocolante preta grande), temos de tomar medidas (nota autocolante azul) para dividir o trabalho. Para isso, precisamos de informação (nota adesiva verde) sob a forma da história do utilizador em que vamos trabalhar. O Jira é o sistema (nota autocolante rosa grande) que utilizamos para o efeito. Quando terminarmos, dividimos a história do utilizador nas chamadas sub-tarefas. Trata-se de um evento (sticky note cor de laranja). A política de desenvolvimento (sticky note roxo grande) indica-nos então a nossa ação seguinte: colocar uma subtarefa em progresso no Jira.

Seguimos a cronologia e enriquecemos todos os eventos. Se não tivermos a certeza de como enriquecer um evento com metadados, criamos um ponto de acesso e seguimos em frente. Mais tarde, voltamos a analisar todos os pontos de acesso. Alguns pontos de acesso não podem ser corrigidos. Por exemplo, quando fazemos a demonstração da história, porque isso depende do planeamento das partes interessadas. Ou quando criamos documentação para a história porque isso ainda não faz parte do nosso processo. Não faz mal; estamos apenas a descrever a situação atual do nosso processo. Mas é algo que podemos melhorar!

Experiência concluída com êxito

Toda a gente está entusiasmada com o EventStorming e com os resultados que obtivemos com ele.

Estava confiante de que poderíamos obter uma boa visão geral do atual processo de desenvolvimento através da realização de um EventStorm. No final, temos de facto uma imagem clara do nosso processo de desenvolvimento:

Agora é fácil explicar aos outros qual é o nosso processo de desenvolvimento atual. Também sabemos que faltam algumas partes essenciais no nosso processo atual.

Mal posso esperar para começar a modelar os nossos outros processos empresariais!