Workshop: Ferramentas Essenciais para Lideranças Técnicas

Transcript

1. | workshop Ferramentas Essenciais para Lideranças Técnicas 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 | iFood
3. O que vamos aprender em conjunto hoje?
4. Agenda • Intro sobre a importância do uso de ferramentas (10 min); • RFC: Request for Comments (50 min); • ADR: Architecture Decisions Record (30 min); • Pausa para almoço (1 hora); • Priorização de Dívidas Técnicas (1 hora); • EventStorming: introdução (10 min); • EventStorming BigPicture - mão na massa (1h30); • Papo final (20 min); 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 ferramentas que podem te ajudar na jornada como liderança técnica. • Você vai poder experimentar todas as ferramentas e, através de casos hipotéticos, aplicar o uso delas. Photo by Colin Carter on Unsplash
7. Bora começar?
8. Antes de começar… vamos listar quais foram as últimas mudanças técnicas que seu time implementou no último semestre
9. | a importância das ferramentas Quando exercemos o papel de liderança técnica nas empresas e nos times, é muito importante que a gente desenvolva as soft skills. Mas ao mesmo tempo, precisamos evoluir nosso ferramental pra lidar com desa fi os técnicos.
10. Ter um "cinturão de ferramentas” ajuda a… • … saber lidar com desa fi os que surgem durante decisões técnicas; • … entender que tipo de abordagem utilizar quando você precisa resolver problemas; • … dar clareza nas decisões, diminuindo vieses e focando no necessário; • … aumentar a maturidade das pessoas e dos times em lidar com os desa fi os de tecnologia
11. É importante ressaltar - ferramentas são artefatos para te ajudar nos problemas do dia- a-dia, e não podem ser usadas como burocracias sem sentido - algumas ferramentas podem até atrapalhar a e fi ciência do seu time. Use com cuidado e maturidade.
12. Bora lá?
13. ADR: Architecture Decisions Record É um documento que descreve uma escolha que o time fez relacionada a um aspecto signi fi cante da arquitetura de software que estão planejando construir ou evoluir. A ADR é utilizada depois que uma decisão já foi tomada, então ela serve para registrar essas decisões, como um log.
14. Apesar de ser algo pra registro apenas, a ADR acaba servindo para melhorar as decisões dos times, evitando que essas decisões sejam feitas de forma enviesada, sem critérios mínimos, ou até mesmo sem considerar outras opções.
15. Uma boa ADR contém alguns elementos-chave, que fazem com que ela se torne útil pra quem consulta e pra quem escreve, que são: • Contexto e Descrição do Problema; • Motivadores da Decisão; • Opções Consideradas; • Decisão fi nal; • Prós e Contras. Essa é a essência de uma boa ADR.
16. Hoje nós vamos pegar alguns cenários hipotéticos para desenharmos ADRs que tenham esse formato. https://adr.github.io/
17. Cenário 1: Criação de um serviço de notificações A empresa começou a ter uma necessidade de centralizar as noti fi cações que são enviadas para os usuários, pois cada time estava adotando um provedor diferente, além de formatos e maneiras diferentes de enviar a mensagem. Isso começou a gerar gastos desnecessários, além de ine fi ciência da empresa como um todo. Um time resolveu criar uma solução para centralizar o envio dessas noti fi cações e disponibilizar uma API pra que todos os times da empresa usem. Como você descreveria uma decisão desse tipo?
18. RFC: Request for Comments Esse modelo de documento é super antigo, vem lá da década de 70, antes de surgir a internet. Era utilizado pra discutir padrões e propostas, procurando feedback e encorajando discussões técnicas antes de tomar decisões. RFC é muito utilizado em empresas que querem permitir a colaboração cross- times, ou até mesmo garantir que haja espaço para comentários, feedback, ou até mesmo objeções a determinadas propostas. É utilizado até para mudanças organizacionais e estruturais (ex: mudanças na estrutura de times, adoção de alguma prática de engenharia, etc.).
19. Uma RFC normalmente tem algumas elementos essenciais para ser e fi ciente: • Breve descrição da proposta; • Problemas e Dores; • A Proposta; • Impactos da Decisão; • Alternativas; • Questões em Aberto; • Matriz RACI (Responsible, Accountable, Consulted e Informed);
20. Cenário 1: Adoção de uma nova linguagem de programação Um time está super empolgado em utilizar uma nova linguagem de programação para adicionar às que a empresa já utiliza no dia-a-dia. Porém, eles não sabem, ou querem ouvir opiniões a respeito da adoção ou não dessa linguagem, os prós e contras, ou de repente experiências com essa stack nova. Com isso em mente, eles criam uma RFC para compartilhar com a empresa toda. Como seria a estrutura de uma RFC desse tipo?
21. Cenário 2: Mudança de arquitetura síncrona para assíncrona Com a evolução do ecossistema de serviços da empresa, e pelo constante número de incidentes com perda de dados e experiência negativa dos clientes, chegou a hora de adotar uma estratégia assíncrona no produto que um time trabalha. Porém, o time gostaria de ouvir feedback de outras pessoas, principalmente fora do próprio time, para entender se existe alguma opinião diferente de adotar assincronicidade nos fl uxos que trabalham e que acabam interagindo com esses outros times. Como seria a estrutura de uma RFC desse tipo?
22. Priorização de Dívida Técnica Quando trabalhamos com software, existe sempre a propensão a criarmos defeitos de qualidade que tornam mais difícil do que o necessário para modi fi car e evoluir o sistema no futuro. Dívida técnica é uma metáfora, criada por Ward Cunningham, que diz respeito a como lidar com esses defeitos de qualidade, pensando como se fosse uma dívida fi nanceira. O esforço adicional que leva para adicionar funcionalidades são os juros pagos nessa dívida.
23. Imagine que eu tenha uma estrutura de módulo confusa em meu code base. Preciso adicionar um novo recurso. Se a estrutura do módulo fosse clara, levaria quatro dias para adicionar o recurso, mas com esse defeito de qualidade, levaria seis dias. A diferença de dois dias são os juros da dívida.
24. Existem alguns sinais que as dívidas técnicas começam a se tornar um gargalo: Tempo de entrega de valor (ex: quanto tempo demora para adicionar novos fl uxos ou mudá-los), Impacto para o usuário fi nal (ex: a latência nos sistemas, o tempo de integração do cliente e os problemas de qualidade - os "atalhos técnicos" (gambiarras) podem ser a causa principal), Satisfação do desenvolvedor (ex: o quanto as pessoas sofrem ao lidar com aquele software ou parte dele), Capacidade de integrar novos desenvolvedores e Degradação em itens não funcionais (ex: custos de infraestrutura, desempenho e disponibilidade).
25. Para lidar com essas dívidas, nós precisamos entender se faz sentido gastar esforço ou não, e principalmente, priorizar quais dessas dívidas devemos focar para gerar mais e fi ciência na manutenção e evolução do software que lidamos - resumindo, reduzir os juros da dívida. Existem algumas maneiras de fazer essa priorização, e vamos entender algumas formas de como organizar essas dívidas e paga-las, antes que se tornem um pesadelo.
26. Vamos falar de domínios?
27. 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.
28. 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.
29. Qual Problema queremos resolver? Como resolvemos o Problema?
30. Pessoas Desenvolvedoras Experts no Domínio de Negócio Engenharia de Software Know-how do Domínio ? Michael Plöd, June, 2022
31. Michael Plöd, June, 2022
32. domain Domínio é uma área de interesse na qual uma pessoa que tem controle aplica a um programa (software)
34. domain Domínios devem ser o coração das estruturas organizacionais Pagamento de Boleto Agendamento de Boleto Estorno de Boleto Boleto para Depósito
35. Mas como descobrir e mapear esses domínios? 🤔
36. 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.
39. Narrativas As pessoas gostam de contar histórias, não apenas preencher diagramas ou templates. Encoraje as pessoas mais experientes a contar uma história, olhando para exemplos concretos.
40. Artefatos do EventStorming
41. Personas envolvidas nos Eventos de Domínio, Comandos ou Políticas. Atores
42. Um evento de domínio é algo interessante que aconteceu no negócio e que as pessoas se importam. São sempre escritos no verbo no passado (ex: “Pedido foi criado”). Eventos de Domínio
43. Um comando é uma decisão tomada por um usuário ou por um software. Por exemplo: Enviar pedido Publicar post Comandos
44. Políticas são as regras que reagem ou ditam como os eventos de domínio e os comandos devem funcionar. Elas podem ser automatizadas ou manuais. Políticas
45. Sistemas que fazem parte do fluxo de Eventos de Domínios ou Comandos. External Systems
46. O dado necessário para tomar alguma decisão. Read Model
47. São dúvidas, riscos, pontos para serem discutidos. Hot Spots
48. O Event Storming começa com um brainstorming dos eventos de domínio relacionados ao domínio de negócios que está sendo explorado. Nesse estágio inicial, não há necessidade de se preocupar em ordenar eventos ou mesmo em redundância. Esta etapa é toda sobre o brainstorming das possíveis coisas que podem acontecer no domínio do negócio. Como funciona?
49. Em seguida, as pessoas examinam os Eventos de Domínio gerados e tentam organizá-los cronologicamente na ordem em que esses eventos ocorrem no domínio de negócios. A ordenação dos eventos deve começar com o “cenário do caminho feliz”: o fluxo que descreve um cenário de negócios bem-sucedido. Como funciona?
50. Uma vez que o “caminho feliz” é feito, cenários alternativos podem ser adicionados — por exemplo, caminhos onde erros são encontrados ou diferentes decisões de negócios são tomadas. Nesta etapa também é a hora de corrigir eventos incorretos, remover duplicatas e, é claro, adicionar eventos ausentes, se algum for descoberto. Como funciona?
51. Exemplos
52. 🙌 bora experimentar?
53. Perguntas e Discussão 🙋
54. Obrigado