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!
• 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
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.
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
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.
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.
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.
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.
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?
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.).
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);
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?
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?
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.
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.
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).
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.
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.
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.
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?
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?
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?
eduardojmatos
kkamegawa
blueswen
tonkotsuboy_com
broadleaf
k1mu21
mom0tomo
mototakatsu
o0h
yukukotani
simotin13
manfredsteyer
akihisaikeda
rmw
reverentgeek
denniskardys
rkaga
holman
addyosmani
mfonobong
sstephenson
danielanewman
takai
raygrieselhuber
tamaranovitovic
