Índice e Highlights
Certamente você já deve ter ouvido falar sobre Event Storming ou tenha participado, pois bem, nos últimos anos facilitei diversas vezes esse workshop, criado por Alberto Brandonili.
Nessa série sobre Event Storming irei compartilhar algumas opiniões, dicas, templates, experiências e espero que os ajude a organizar e facilitar um no futuro.
1. Evento Storming, Em poucas palavras, o que é isso?
É um workshop com o objetivo de promover o compartilhamento e descoberta de conhecimento de um domínio através de uma espécie de brainstorm, usando post-its de maneira simples, divertida e coesa.
2. Por que fazer Event Storming?
Para respondermos a pergunta do porque fazer Event Storming precisamos entender a sua essência. Para mim a ideia é sensacional, os envolvidos se posicionam em frente a uma grande cartolina na parede que representa o tempo espaço e todos os post-its que forem colados nela, estarão relacionados através de uma linha do tempo.
Vou dar um exemplo de quão simples e poderosa fica a leitura desse layout:
Dado um post-it colado nessa cartolina,
Quando olhamos para ele,
Então podemos entender que:
Os post-its colados a sua esquerda são eventos que aconteceram antes,
E os post-its a sua direita são eventos que aconteceram depois delePara prosseguir com a explicação, vou propor um desafio:
Vamos descrever o processo de fazer um misto quente?
Passo 1: Usando post-its, vamos tentar representar a criação do misto quente sem utilizar uma linha do tempo. (Como um simples diagrama de passos e setas)
Passo 2: Vamos refazer/reposicionar os posts-its utilizando a linha do tempo como apoio.
Vamos lá, mãos a massa:
1. Comecei escrevendo em post-its os passos para fazer um misto quente ( o meu misto quente ), e ele ficou mais ou menos assim:
2. Agora passo 2, organizando a sequência e utilizando a técnica da linha do tempo proposta por Brandolini:
Podemos notar que na segunda versão não precisei mais das setas, ficou muito mais limpo e claro de ler. Comparado com a versão do passo 1, ficou muito mais claro e coeso não concorda?
Pois bem, algumas pessoas nesse ponto se perguntam, tá, mas o quão importante ou quanto valor tem um desenho?
Para responder essa pergunta, separei um post especial para explicar o problema no qual chamei de "Modelos Mentais Privados", que acredito estar relacionado com qualquer dinâmica que propõem dinâmicas de desenho ou post-its.
E para responder o porque realizar Event Storming, é simples:
Podemos fazer engenharia reversa sobre um software
Podemos promover o compartilhamento de conhecimento sobre um determinado domínio
Podemos compartilhar e aprender com outras pessoas envolvidas no domínio
Podemos em poucas horas produzir um material muito rico sobre o domínio
Facilita o onboarding de pessoas em domínios complexos
Pode ajudar a detectar falhar e delays
Pode ajudar a inovar e rever processos
Promove uma colaboração rápida e produtiva
A lista de benefícios do porque é muito bonita, mas separei um desafio que considero um dos maiores motivadores de se realizar essa técnica e dediquei uma sessão só para ele, o que chamei de distanciamento acidental da solução que parece estar ligado com a cultura do imediatismo ou vortex do "fasejamento", mas é só uma minha opinião.
2.1 Entendendo os Desafios: Distanciamento Acidental da Solução
Vou começar com um ditado popular, colocando um pouco de água nesse suco (citando alguns pontos que atrapalham e dificultam o patrocínio de dinâmicas assim).
Poucas pessoas percebem a importância de um papel ativo dos times de tecnologia no contexto de uma solução de software focada em entrega de valor, ou entrega de produtos. E umas das discussões mais interessantes que tive nos últimos anos, está ligado com a reflexão abaixo:
- Cada dia o desenvolvedor é menos codificador, e cada dia o dono do produto é menos dono do produto. - Cada dia o desenvolvedor é mais dono do produto, e cada dia o dono do produto é mais codificador. Essas frases foram ditas em uma reunião pelo seguinte contexto: Um desenvoldedor na era digital, estuda o seu segmento, é uma pessoa que ajuda o cliente e a empresa a chegar na melhor solução para o produto e para o serviço, e utiliza a tecnologia como uma ferramenta e não como principal entregável. Ao mesmo tempo os donos do produto estão buscando conhecer cada vez mais as possibilidades sobre as tecnologias, e o quanto elas podem modificar, otimizar ou e inovar o seus segmentos.
Para entender melhor, vou começar falando sobre o contrário disso, os times envolvidos em uma solução de software, na maioria das vezes são heterogêneos e vivem rotinas bem distintas, vou dar alguns exemplos dos mais comuns:
Rotinas que causam o distanciamento entre as pessoas e o descaso (falta de capricho) com o design da solução:
Um desenvolver vai viver uma rotina bem diferente, apesar de entender o problema que o software vai resolver, ele está mais preocupado com as diretrizes técnicas da sua solução, e isso faz ele consumir outras fontes de informação. Em poucas palavras, ele está mais preocupado em fazer o seu pipeline rodar, do que discutir o domínio em que seu software se encontra ou design da solução.
Em nenhum momento eles sentam para discutir e colaborar sobre o desenho da solução do seu produto/serviço, para o presente e para futuro, as consequências disso incluem: uma grande pilha de código, desenhos gigantes de arquitetura, um cliente cheio de desejos e um time cheio de débitos técnicos.
O time só consegue resolver o problema do alto acoplamento de uma única maneira: Entendendo o negócio, segmento e sua solução!
Uma falácia comum: Temos uma arquitetura robusta, SOA, Microservices, temos APIs pra todo lado e pra tudo, com muito reuso! Mas a startup vizinha sempre é mais rápida e adicionar novas features é cada vez mais difícil. 🤨 |
|
Sem mais delongas, podemos imaginar diversas situações onde esses dois perfis raramente se encontram para discutir em um único dialeto os problemas dos seus clientes e como estão resolvendo isso através das funcionalidades, com o melhor trade-off sobre o design.
Alguns sintomas desse desalinhamento:
Alto custo de manutenção.
Acoplamento pesado entre os módulos do software.
Só o Techlead entrega no prazo.
Refinement no estilo TED TALK, o techlead fala por 30 minutos ininterruptos.
Só uma pessoa específica consegue alterar o módulo X ( E se a sprint tiver só cartões no módulo X? velocity foi pro brejo)
Dailys de 30 ~ 60 minutos ou mais...
Muitos testes unitários, alto percentual de cobertura e bugs em produção...
Refinements, Plannings, ou qualquer outros ritos do time cansativos e sem objetivos.
Cartões pobres de especificação, às vezes, só com título, vulgo cartões shurg 🤷🏽♂️, termo originado em tickets de support, mas parece estar dando fit em histórias de usuário também.
Plataforma de serviços homérica, estilo estrela da morte sendo apresentada como algo bom. (Escala não é complexidade)
Escala não é complexidade! Uma história, no final do ano de 2019 prestei serviço para uma startup que havia recebido investimento de 200M, mas sua arquitetura era inexistente e possuiam muito acoplamento. Um detalhe que me chamou atenção e me deixou inquieto por alguns dias: eram sete desenvolvedores com 1 milhões de clientes. - Não usavam nada robusto, como kubernetes etc, nem containers, eram VMs com runtimes subidos na mão com python para todo lado. Será que microservices, k8s por sí só, são overengineering? Se usados sem design, com certeza!
O preço do acoplamento funcional:
Em poucas palavras: quando para construir ou alterar uma funcionalidade é preciso coordenar a modificação de n serviços, de n backlogs, de n times e até que se teste tudo, cada parte seja entregue e integrada, você terá n deploys. Resumindo essa fórmula matemática doida: Teremos n times esperando n times só para poder entregar, testar ou até mesmo iniciar o desenvolvimento de uma ou mais funcionalidades.
Por mais que sejam squads separadas, autônomas, isso é chamado de acoplamento funcional.
2.2 Discutindo sobre ideias de solução: O Event Storming!
Como podemos remover esse hiato entre os diferentes perfis, aproximar as pessoas ao domínio de negócio, e sermos simples ( sem gerar toneladas de documentações ou uma série da Netflix de reuniões gravadas )?
Como esses perfis continuam performando suas atividades e adicionalmente mantêm esse alinhamento?
Tom Wujec, nos mostrou que somos ótimos ao colaborar através de desenhos através de nós e do relacionados entre esses nós, saiba mais no post: "Modelos Mentais Privados".
Alberto Brandolini nos presenteou com uma técnica que pode ser usada em qualquer contexto, e nos traz regras de como representar e construir esses modelos: Event Storming.
Aprendemos até aqui que todos criamos modelos mentais "privados" sobre qualquer coisa, e criar um mecanismo de colaboração através de desenhos é chave para um design colaborativo e refinado, e que não precisamos reinventar a roda. Leia o post: Modelo Mental Privado.
Vamos falar de Event Storming, diferente desse post filosófico e historiográfico, os próximos posts dessa serie serão para falar da taxonomia, organizar e facilitar um Event Storming 💪🏾.
Espero terem curtido a leitura até aqui. Aquele abraço!
👏👏👏👏
Esperando ansiosamente para os próximos capítulos!!!