Slide 1

Slide 1 text

| workshop Estrutura de Times + Arquitetura de Software Destravando a e fi cácia da sua empresa Photo by Sai Abhinivesh Burla on Unsplash

Slide 2

Slide 2 text

Eduardo Matos Pai da Duda e do João Líder em Tech há +7 anos Desenvolvedor há +17 JWT | R7.com | Creditas | GetNinjas | Nubank | Will Bank

Slide 3

Slide 3 text

O que vamos aprender em conjunto hoje?

Slide 4

Slide 4 text

Agenda 18h30 (10 min) - Introdução, quebra-gelo 🧊; 18h40 (20 min) - Módulo 1 - O Flow e a Carga Cognitiva; 19h00 (15 min) - Módulo 2 - O que é um Domínio; 19h15 (45 min) - Módulo 3 - Como mapear Domínios [🙌]; 20h (10 min) - Pausa 🚰; 20h10 (40 min) - Módulo 4 - Estrutura e Domínios [🙌]; 20h50 - Perguntas e Discussão; 21h - Encerrramento 👋. Photo by Glenn Carstens-Peters on Unsplash * [🙌] = mão na massa

Slide 5

Slide 5 text

⚠ Avisos Este workshop possui referências de várias pessoas autoras e todos os créditos serão postados no fi m do material. As partes “mão na massa” exigem a participação de todas as pessoas. Então, peço foco 100%, evitando multi-task (vamos manter o fl ow 😀). A aula será gravada e você poderá assisti-la depois. Todo o material será compartilhado com vocês, portanto não se preocupe em tirar prints - só se quiser!

Slide 6

Slide 6 text

Propósito do workshop Você não pode sair daqui sem saber • Esse workshop tem como objetivo explorarmos conhecimento sobre arquitetura de software 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

Slide 7

Slide 7 text

Bora começar?

Slide 8

Slide 8 text

Mihaly Csikszentmihalyi (Flow: The Psychology of Optimal Experience) | Flow “O estado mental altamente efetivo de uma pessoa completamente imersa em uma atividade”

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Você já se sentiu assim alguma vez? Pra quem trabalha desenvolvendo software, essa sensação acontece quando estamos tão imersas ou imersos no código que esquecemos a hora e a realização ao ver a conclusão de uma entrega (por exemplo, um endpoint de uma API funcionando como deveria, ou um trecho de código executando algo de forma perfeita) gera um grande prazer e alegria. Ver as coisas funcionando depois que você fez aquele código é uma sensação realmente diferente.

Slide 11

Slide 11 text

Em desenvolvimento de software, o flow causa: • Ambição coletiva; • Objetivos em comum; • Objetivos pessoais alinhados; • Comunicação aberta; • Segurança; • Compromisso mútuo; • Senso de unidade; • Senso de progresso conjunto; • Con fi ança mútua;

Slide 12

Slide 12 text

flow em desenvolvimento de software cada história fl ui da "ideia" ao entregável, software funcionando diretamente sem fi las, sem um inventário (trabalho em processo), distração, interrupção ou multitasking

Slide 13

Slide 13 text

O que impede o flow? • Fadiga • Requisitos perdidos • Troca de contexto e falta dele • Interrupções no fl uxo de trabalho • Distrações • Espera por clareza do trabalho • Barreiras de comunicação • Falta de conhecimento/skills • Reuniões desnecessárias • Dependências externas ou de outros times • Expectativas irreais ou não claras;

Slide 14

Slide 14 text

Nesse workshop vamos focar em apenas alguns 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;

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

🧠 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.

Slide 17

Slide 17 text

🧠 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;

Slide 18

Slide 18 text

Casos da vida real Já liderei times que tinham diversos domínios sob sua responsabilidade. Alguns desa fi os eram constantes, como a priorização de iniciativas, de fi nição dos objetivos, o entendimento do capacity dos times e o stress que o time tinha ao ter que buscar informações de fl uxos que nem sabiam que tinham responsabilidade.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

Mudando de contexto…

Slide 21

Slide 21 text

Vamos falar de domínios?

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

Qual Problema queremos resolver? Como resolvemos o Problema?

Slide 25

Slide 25 text

Pessoas Desenvolvedoras Experts no Domínio de Negócio Engenharia de Software Know-how do Domínio ? Michael Plöd, June, 2022

Slide 26

Slide 26 text

Michael Plöd, June, 2022

Slide 27

Slide 27 text

domain Domínio é uma área de interesse na qual uma pessoa que tem controle aplica a um programa (software)

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

domain Domínios devem ser o coração das estruturas organizacionais Pagamento de Boleto Agendamento de Boleto Estorno de Boleto Boleto para Depósito

Slide 30

Slide 30 text

Mas como descobrir e mapear esses domínios? 🤔

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

🙌 bora experimentar?

Slide 36

Slide 36 text

Estrutura Organizacional, Objetivos de Negócio e Software Como essa tríade tem relação com o fl ow e performance dos times?

Slide 37

Slide 37 text

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”

Slide 38

Slide 38 text

"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”

Slide 39

Slide 39 text

“ 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”

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

“De fi nições de time são os primeiros rascunhos da arquitetura” Michael Nygard Autor de “Release It"

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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;

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

Finalmente, unindo Domínios às Estruturas Agora que adquirimos os conceitos todos, podemos continuar o exercício prático. 👊

Slide 47

Slide 47 text

Perguntas e Discussão 🙋

Slide 48

Slide 48 text

Obrigado