Saudações galerinha! 🤘

O Event Storming

Desenvolver sistemas complexos leva tempo e compreensão (grooming do scrum) do time como um todo. As vezes a demanda não é absolutamente clara nem para o solicitante.

Depois de 20 anos desenvolvendo e vendendo sistemas, essa foi até agora a maneira mais transparente, fácil e objetiva de mostrar a realidade dos contextos para todos envolvidos.

É uma forma simples e divertida de mapear profundamente o domínio da aplicação e depois de alguns workshops, sair com o DDD (Domain Driven Design) pronto para desenvolvimento, reduzindo a linguagem obíquoa entre os stakeholders e desenvolvedores.

O que é o Event Storming?

É um workshop criado por Alberto Brandolini. Ele visa facilitar a visualização de subdomínios e bounded contexts (contextos limitados), além de auxiliar no processo de estabelecimento da linguagem ubíqua (se chamar "Cliente" no evento, vai se chamar "Cliente" na programação, e "Cliente" no banco de dados e assim por diante).

"O event storming gera maior compreensão e produtividade, simplificando a abordagem e incluindo vários níveis de partes interessadas nos negócios. Com a ajuda de post-its e um grupo disposto, você pode revelar seus processos de negócios de forma mais eficiente e divertida."

Onde utilizar o Event Storming?

Utilizamos em qualquer projeto, seja para desenvolvimento de sistemas ou processos físicos não digitais. Por incrível que pareça, em projeto físicos também funcionaram as análises (adaptando realidades), pois todas engenharias de softwares se baseiam em comportamentos humanos (físicos e mentais) no final: "nada se cria, tudo se copia".

Já fizemos workshops para compreender o absoluto de um processo financeiro, de processos de RH e outros processos físicos, como armazenamento de produtos (estoque) ou expedição de pedidos.

Por que isso agora?

Podemos dizer: "P0rr*! Mais uma coisa pra aprender?!". Sim, o ambiente de aprendizado é a base de "errarmos" e "descobrirmos" de forma evolutiva e constante, não abstendo os fatos e dados para tomar excelentes decisões.

O workshop do Event Storming é um processo antes de sair criando ou desenvolvendo e deixa muito claro e, se não estiver claro, ainda não resolveu seu problema.

Já trabalhamos com Design Thinking para empatizar e idear com abstração e disrupção em busca de transcedência do negócio (as vezes até pivotar), com o Design Anthropology para observar a produção física como mera execução mecânica em busca de fatos e dados em campo entendendo cada contexto real e o Design Sprint (Google Design Sprint) para idear e testar sem custos (ou baixo custos) com alta velocidade e rápido aprendizado dos testes e erros em busca de redução de falhas na solução final.

Entretanto agora, incluindo o Evento Stoming em nossa rotina, conseguimos fechar um ciclo que parecia faltar em relação ao mapeamento detalhado do que é Evento de Domínio, o que Processo do Negócio, o que é Ator, o que é Comando, o que é Sistema Externo, o que é Modelo de Visão (tela), o que é Agregado e o que é Dúvida (coisas que sabemos que existe mas não sabemos como resolver).

A História do Event Storming

Alberto Brandolini é um cara bruto e bravo (espetacular). Inteligência normalmente reduz a tolerância do ser, sendo sempre definido como "rude" ou "arrogante". Entendo as críticas e nem queremos discutir isso aqui, todavia esse cara em 2013 já estava entendendo os problemas de forma clara e transformando em DDD (Domain Driven Design).

O Event Storming original foi feito para ser realizado fisicamente, com painel de papel, port-its coloridos e canetas.

Era um momento de ir para outro ambiente, ou mudar o ambiente de trabalho existente, retirando as mesas e cadeiras para todos ficarem de pé olho no olho e máximo de atenção no presente. Não utilizar celulares ou qualquer outra distração, respeitando algumas regra básicas, como 20 minutos de preparação, entre 6 e 10 pessoas, entre 3 e 6 horas de evento e com o máximo de dificuldade de intensidade dos participantes.

Com a pandemia do COVID19 Sr. Brandolini teve quase um infarto, pois o Event Storming foi feito para ser realizado fisicamente e agora isso não era mais possível.

Em 2021 com toda respeitável resiliência, Sr. Brandolini redefiniu e adaptou para ser realizado online, com outras regras e definições como desligar celulares e outras redes sociais, manter a câmera aberta na sala e estar presente de corpo e alma para interferir nas regras de negócio do domínio.

Hoje temos o Miro para realizar os workshops e funciona perfeitamente, seguindo as regras, podemos realizar online ou fisicamente. 😉

Ao criar o Event Storming, utilizou o Princípio de pareto o famoso termo 80/20 (80% de ganho com 20% de esforço), o conteúdo atual de seu livro é suficiente para ter a ideia e realizar a técnica. Além disso, Mariusz Gil publicou um excelente repositório para aprendermos mais. Este repositório do Git tem um grande material sobre Event Storming.

Outro link que vou deixar aqui, é do Miro com um boad especial do mesmo tema.

História

Aqui está o link da referência.

O rolê do Event Storming na prática!

Para realizar esse troço, precisamos respeitar algumas regras, agora isso parece não fazer sentido, mas quando fizer você vai entender.

20 minuto de preparação (expicar que m3rd* estamos fazendo aqui)
de 3 a 6 horas de agenda de cada membro (intensidade)
de 6 a 10 cidadões importantes (stakeholders, mas já fiz sozinho e funcionou)
Modo do jogo: HARD!
Tenha um "Juiz" do jogo, um locutor do evento.

Agora, bora colocar a mão da massa👌🏼

Primeiro, bora entender as cores dos objetos, esse é a parte mais "delicinha" como dis o Sr. Deschamps.

Cada cor representa um objeto específico do domínio, sempre respeitando a base da pesquisa e desenvolvimento (DDD).

Fizemos algumas adaptações de cores (particularmente), para destacar as dúvidas com o Post-it preto, assim quando abre o evento, conseguimos mapear as dúvidas claramente que estão por ser finalizadas. Coloquei como "Polli Way" por que o Sr. Matheus Polli que me ensinou isso, e ele faz desse jeito

Indices

1) Colete os Eventos de domínios (Big Picture)

Sem medo de ser feliz, de forma simples e prática, pergunte sobre os passos do evento que acontece no processo como um todo para mapear e entender quais são os eventos do domínio.

Processo 1

2) Refine os Eventos de domínios (Big Picture)

Faça perguntas inteligentes para estimular os participantes a entender e depois explicar o que cada evento significa, isso ajuda a reduzir as dúvidas entre eles mesmos. Aqui é melhor ouvir do que interferir.

Processo 2

3) Mapeie os Casos (Modelando Processos)

Neste passo vamos entender o mapear os casos de cada ator, respondendo a pergunta: De onde vem os eventos?

Então vamos extrair daqui os Comandos, Usuários/Atores, Modelos de Visões ou telas, Sistemas Externos e Processos de negócios.

Lembrando que existe uma ordem de chamada, assim cosneguimos separa cada parte do processo diferentemente já entendendo o DDD da aplicação.

Esse ponto é importante perguntar: Quais são os gatinhos dos eventos?

Processo 3

4) Reorganize e resolva (Modelando o Software)

Aqui nesse passo conseguimos agrupar cada sistema por sí em seu domínio de negócio. Colocamos em uma linha do tempo o passo a passo que cada ator realizará para seu sucesso.

O que envoca o Comando?
Quem se relaciona o Evento do Domínio?
Quem envoca o Sistema Externo?

Quando agrupar por sistemas, será claro cada parte do domínio de negócio a ser implementado no nosso amado DDD.

Processo 3

Conclusão

Depois de passar um tempo estudando o domínio do negócio antes de desenvolver qualquer coisa, conseguimos explicar para o CEO da empresa e para o time de Engenharia a mesma coisa, falando a mesma língua e sem dúvidas do que o negócio faz do começo ao fim. Quando o dev lá na ponta vai desenvolver, ele sabe exatamente como separar cada contexto, cada termo em relação ao negócio. Isso reduz atrito de comunicação e entendimento da solução como um todo.