Workshop Estrutura de Times + Arquitetura de Software

Transcript

1. | workshop Estrutura de Times + Arquitetura de Software Destravando a e fi cácia da sua empresa Photo by Sai Abhinivesh Burla on Unsplash
2. 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
3. O que vamos aprender em conjunto hoje?
4. 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
5. ⚠ 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!
6. 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
7. Bora começar?
8. Mihaly Csikszentmihalyi (Flow: The Psychology of Optimal Experience) | Flow “O estado mental altamente efetivo de uma pessoa completamente imersa em uma atividade”
9. 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
10. 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.
11. 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;
12. 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
13. 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;
14. 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;
15. 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
16. 🧠 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.
17. 🧠 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;
18. 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.
19. 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.
20. Mudando de contexto…
21. Vamos falar de domínios?
22. 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.
23. 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.
24. Qual Problema queremos resolver? Como resolvemos o Problema?
25. Pessoas Desenvolvedoras Experts no Domínio de Negócio Engenharia de Software Know-how do Domínio ? Michael Plöd, June, 2022
26. Michael Plöd, June, 2022
27. domain Domínio é uma área de interesse na qual uma pessoa que tem controle aplica a um programa (software)
29. domain Domínios devem ser o coração das estruturas organizacionais Pagamento de Boleto Agendamento de Boleto Estorno de Boleto Boleto para Depósito
30. Mas como descobrir e mapear esses domínios? 🤔
31. 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.
34. 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.
35. 🙌 bora experimentar?
36. Estrutura Organizacional, Objetivos de Negócio e Software Como essa tríade tem relação com o fl ow e performance dos times?
37. 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”
38. "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”
39. “ 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”
40. 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
41. “De fi nições de time são os primeiros rascunhos da arquitetura” Michael Nygard Autor de “Release It"
42. 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
43. 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;
44. 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
45. 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.
46. Finalmente, unindo Domínios às Estruturas Agora que adquirimos os conceitos todos, podemos continuar o exercício prático. 👊
47. Perguntas e Discussão 🙋
48. Obrigado