Construindo times e produtos com Team Topologies e DDD

Esse workshop tem como objetivo explorarmos conhecimento sobre DDD, Team Topologies e sua relação com as estruturas de times.

Transcript

1. | workshop Construindo times e produtos com Team Topologies e DDD Photo by Sai Abhinivesh Burla on Unsplash
2. Eduardo Matos Pai da Duda e do João Líder em Tech há +7 anos Team Topologies Advocate JWT | R7.com | Creditas | GetNinjas | Nubank | Will Bank
3. Felipe Dutra Ex-engenheiro de software Produteiro e Agilista Bradesco | Will Bank
4. O que vamos aprender em conjunto hoje?
5. Agenda 14h10 (5 min) - Introdução; 14h15 (15 min) - O Flow e a Carga Cognitiva; 14h30 (15 min) - O que é um Domínio; 14h45 (30 min) - Como mapear Domínios [🙌]; 15h15 (10 min) - Pausa 🚰; 15h25 (15 min) - Agrupamento dos Eventos de Domínios [🙌]; 15h40 (10 min) - Unindo Domínios e Estruturas [🙌]; 15h50 (20 min) - Perguntas e Discussão; 16h10 - Encerramento 👋. Photo by Glenn Carstens-Peters on Unsplash * [🙌] = mão na massa
6. ⚠ Avisos As partes “mão na massa” exigem a participação de todas as pessoas. O material será compartilhado com vocês, portanto não se preocupe em tirar fotos - só se quiser!
7. Propósito do workshop Você não pode sair daqui sem saber • Esse workshop tem como objetivo explorarmos conhecimento sobre DDD, Team Topologies e sua relação com as estruturas de times. • Além do conteúdo teórico, você vai poder experimentar uma ferramenta de mapeamento de domínios e, através de um caso hipotético, criar estruturas de times em volta desses domínios. Photo by Colin Carter on Unsplash
8. Bora começar?
9. Mihaly Csikszentmihalyi (Flow: The Psychology of Optimal Experience) | Flow “O estado mental altamente efetivo de uma pessoa completamente imersa em uma atividade”
10. Quando você está “no fl ow”… • há a uma sensação de "ecstasy" e clareza; • você sabe exatamente o que você quer fazer de um momento para outro; • o senso de tempo desaparece; • você esquece de você mesmo; • você se sente parte de algo maior. Photo by Mulyadi on Unsplash
11. Nesse workshop vamos focar em apenas alguns problemas no fl ow que estão relacionados às estruturas de times que são: • Troca de contexto e a falta dele; • Barreiras de comunicação; • Espera pela clareza do trabalho; • Dependências externas ou de outros times;
12. Carga Cognitiva Na psicologia cognitiva, carga cognitiva se refere à quantidade de recursos de memória de trabalho usada. A teoria é que uma informação só pode ser armazenada na memória de longo prazo depois de primeiro ser recebida e processada pela memória de trabalho. Mas, essa memória é extremamente limitada tanto em capacidade como em duração
13. 🧠 Carga Cognitiva Se a memória de trabalho é escassa e tem limitações, nós podemos pensar em maneiras de reduzir a quantidade dessas informações necessárias para o trabalho ser feito, tornando melhor o uso da nossa capacidade cognitiva. PS: deixando claro aqui que não estamos falando de multi-tarefas e sim, multi-contextos.
14. 🧠 Sobrecarga de Domínios Problemas resultantes da sobrecarga: • Conhecimento super fi cial do contexto de negócio; • Demora pra ganhar contexto novamente sobre o domínio, diminuindo a produtividade; • Baixo conhecimento sobre a arquitetura ou o ecossistema que o domínio abrange; • Aumento do tempo para corrigir e identi fi car problemas; • Alta demora na recuperação de incidentes (MTTR - mean time to recovery); • Sobrecarga de assuntos, o que pode levar à fadiga mental e stress; • Di fi culdade ao lembrar de detalhes importantes das jornadas; • Fadiga na tomada de decisão - tende-se a tomar decisões mais pobres por conta da quantidade de assuntos pra lidar; • Tempo de onboarding mais alto para novas pessoas no time;
15. Carga Cognitiva e Flow Flow tem uma relação próxima com carga cognitiva. Se as pessoas do time precisam parar pra ganhar contexto do trabalho, buscar informações para ter clareza do trabalho a ser feito, por conta da falta de contexto e das dependências não explícitas ou não declaradas, di fi cilmente vão conseguir encontrar o estado de Flow.
16. Mudando de contexto…
17. Vamos falar de domínios?
18. Domain-Driven Design O DDD é um modelo de design de software que tem como foco a modelagem de sistemas que sejam combinadas e voltadas para os domínios de negócio.
19. Domain-Driven Design Segundo o DDD, existem dois tipos de atores principais quando desenhamos algum software: software developers e business experts Ambos os papéis devem falar a mesma linguagem, e essa linguagem deve ser onipresente - todos devem usar os mesmos termos e os significados das coisas precisam ser compartilhados. Isso até para nomes de classes, métodos, variáveis.
20. Qual Problema queremos resolver? Como resolvemos o Problema?
21. Pessoas Desenvolvedoras Experts no Domínio de Negócio Engenharia de Software Know-how do Domínio ? Michael Plöd, June, 2022
22. Michael Plöd, June, 2022
23. domain Domínio é uma área de interesse na qual uma pessoa que tem controle aplica a um programa (software)
25. domain Domínios devem ser o coração das estruturas organizacionais Pagamento de Boleto Agendamento de Boleto Estorno de Boleto Boleto para Depósito
26. Mas como descobrir e mapear esses domínios? 🤔
27. EventStorming Essa é a técnica mais famosa quando falamos de mapeamento de domínios. O EventStorming vale um curso todo sobre, mas sendo resumido aqui, ela se baseia em como atores, modelos e sistemas se relacionam. O nome Event não é à toa: a ideia é que o mapeamento seja feito em torno de eventos entre esses modelos e sistemas.
30. Domain Event Nesse workshop, nós vamos utilizar apenas um dos artefatos do EventStorming, o Domain Event. Através dos Domain Events nós conseguimos mapear os domínios que serão necessários para as definições de estruturas de times. Esse tipo de EventStorming é chamado de "Big Picture", pois não entra nas nuances dos processos, é apenas uma discussão dos eventos que acontecem, num nível alto de abstração.
31. 🙌 bora experimentar?
32. 1. No fluxo de conta digital, considere essas jornadas: a) Abertura de Conta; b) Consulta de Saldo; c) Pagamento de Boleto; d) PIX; 2. Escreva os eventos que acontecem nessas jornadas; 3. Ordene ao longo do fluxo. Case - Banco SGRio 🏦
33. Estrutura Organizacional, Objetivos de Negócio e Software Como essa tríade tem relação com o fl ow e performance dos times?
34. McKinsey Em grandes empresas, problemas estruturais são o principal obstáculo para alcançar as metas digitais “As empresas esperam que grande parte de seu crescimento de curto prazo seja impulsionado pelo digital, mas o impacto continua elusivo. Além disso, faltam estruturas organizacionais e fi cazes, responsabilidade e métricas e incentivos signi fi cativos. À medida que os executivos se envolvem mais nos esforços digitais, eles devem trabalhar para garantir que suas estruturas e processos de negócios sejam con fi gurados para aproveitar ao máximo as oportunidades que os esforços digitais oferecem”
35. "Arquitetura de software e estrutura organizacional fracamente acopladas é um pilar chave da performance de entrega contínua e da capacidade de dimensionar a organização e aumentar o desempenho linearmente”
36. “ Uma Organização Exponencial (ExO) é aquela cujo impacto (ou resultado) é desproporcionalmente grande - pelo menos dez vezes maior - comparado com seus pares, devido ao uso de novas técnicas organizacionais que alavancam as tecnologias aceleradas” “Com muita pouca inércia interna (isto é, número de colaboradores ativos ou estruturas organizacionais), elas demonstram uma extraordinária fl exibilidade, o que é uma qualidade fundamental no mundo volátil de hoje”
37. conway’s law Qualquer organização que projeta um sistema (de fi nido de forma mais ampla aqui do que apenas sistemas de informação) inevitavelmente produzirá um desenho cuja estrutura é uma cópia da estrutura de comunicação da organização. “As organizações há alguns anos entendem essa ligação entre a estrutura organizacional e o software que criam e vêm adotando novas estruturas para alcançar o resultado que desejam.” Thoughtworks
38. “De fi nições de time são os primeiros rascunhos da arquitetura” Michael Nygard Autor de “Release It"
39. Team Topologies Team Topologies é uma abordagem para organizar equipes de negócios e tecnologia para fl uxo rápido, fornecendo um modelo prático, passo a passo e adaptável para design organizacional e interação de equipes.
40. Premissas para considerar ao estruturar times No máximo 6 pessoas por time Carga Cognitiva baixa (número enxuto de domínios) You build it, you run it
41. Classificação de Domínios Os autores do Team Topologies, um livro sobre estrutura de times e arquitetura de software, descrevem uma forma de classi fi car domínios por nível de complexidade, utilizando o Cyne fi n (um modelo pra classi fi car decisões e até dar sentido para certas situações). 1. Simples - a maioria do trabalho tem um caminho claro de ação; 2. Complicado - mudanças precisa ser analisadas e podem requerer algumas interações na solução até encontram um caminho; 3. Complexo - soluções requerem uma grande experimentação e descoberta; 4. Caótico - não há uma forma clara de como a solução ser resolvida;
42. Classificação de Domínios X Carga Cognitiva 1. Simples - pessoas do time já dominam o assunto, tem na palma da mão o contexto 2. Complicado - time ainda precisa estudar o ecossistema, entender como funciona a relação com outros componentes dos serviços. 3. Complexo - pessoas do time não têm total conhecimento dos fl uxos de negócio, nem das regras e políticas. Precisam fazer descoberta, muitas vezes abrindo vários projetos e precisando mapear as interconexões 4. Caótico - ninguém nunca lidou com aquele domínio de conhecimento, nem sabe como começar
43. 🙌 bora experimentar? 1. Fazer o agrupamento dos eventos de dominio; 2. Classificar cada agrupamento, usando a classificação de domínios.
44. Heurísticas + Carga Cognitiva Heurística 1: cada domínio deve pertencer a um time. Se o domínio for muito grande, ao invés de dividir responsabilidades de um domínio para vários times, tente dividir os domínios em sub-domínios, e associar cada sub-domínio a um time. Heurística 2: um único time deve ser capaz de acomodar de 2 a 3 domínios do tipo Simples. Como os domínios de tipo Simples são mais procedurais, o custo de troca de contexto entre domínios é mais tolerável. Se você manter 1 domínio Simples para 1 time, há o risco de desengajamento com o contexto do trabalho, que tende a ser mais de natureza rotineira. Heurística 3: um time responsável por 1 domínio Complexo, não deveria ter nenhum outro domínio sob sua responsabilidade. Resolver problemas complexos levam tempo e foco. A priorização sempre vai tender em resolver coisas do domínio Simples, por conta da facilidade do time em lidar com aquilo, do que mergulhar em resolver problemas que são complexos, porém importantes para o negócio. Heurística 4: evite que um time tenha que lidar com dois domínios Complicados. Isso pode parecer viável para um time grande, mas na prática, o time irá agira como se fossem dois, um pra cada domínio, e a carga cognitiva vai ser exigida como se todos precisasem saber de ambos. O ideal é dividir esse time em dois, pra que haja foco e autonomia em cada um dos domínios.
45. Finalmente, unindo Domínios às Estruturas Agora que adquirimos os conceitos todos, podemos fi nalizar o exercício prático. 👊
46. Heurísticas + Carga Cognitiva Heurística 1: cada domínio deve pertencer a um time. Heurística 2: um único time deve ser capaz de acomodar de 2 a 3 domínios do tipo Simples. Heurística 3: um time responsável por 1 domínio Complexo, não deveria ter nenhum outro domínio sob sua responsabilidade. Heurística 4: evite que um time tenha que lidar com dois domínios Complicados.
47. Perguntas e Discussão 🙋
48. Obrigado :) @eduj.matos @eduardojmatos @people-tech Clube People Tech contact@eduardomatos.me @felipe-dutra