Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Workshop: Ferramentas Essenciais para Liderança...

Workshop: Ferramentas Essenciais para Lideranças Técnicas

Eduardo Matos

August 25, 2023
Tweet

More Decks by Eduardo Matos

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. ⚠ 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!
  4. 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
  5. Antes de começar… vamos listar quais foram as últimas mudanças

    técnicas que seu time implementou no último semestre
  6. | 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.
  7. 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
  8. É 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.
  9. 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.
  10. 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.
  11. 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.
  12. Hoje nós vamos pegar alguns cenários hipotéticos para desenharmos ADRs

    que tenham esse formato. https://adr.github.io/
  13. 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?
  14. 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.).
  15. 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);
  16. 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?
  17. 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?
  18. 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.
  19. 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.
  20. 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).
  21. 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.
  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. 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. 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.
  27. 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.
  28. 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
  29. Um comando é uma decisão tomada por um usuário ou

    por um software. Por exemplo: Enviar pedido Publicar post Comandos
  30. 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
  31. 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?
  32. 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?
  33. 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?