8 min leitura • Guide 825 of 877
Liderança Técnica em Ágil
Líderes técnicos habilitam equipes. O GitScrum ajuda tech leads a rastrear trabalho técnico, decisões arquiteturais e saúde técnica junto com entrega de features.
Papel do Tech Lead
Responsabilidades
RESPONSABILIDADES DO TECH LEAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DIREÇÃO TÉCNICA: │
│ ──────────────── │
│ • Definir visão arquitetural │
│ • Tomar decisões técnicas chave │
│ • Definir padrões e standards │
│ • Avaliar tecnologias │
│ │
│ QUALIDADE: │
│ ────────── │
│ • Code review (especialmente mudanças complexas) │
│ • Definir padrões de qualidade │
│ • Gestão de dívida técnica │
│ • Supervisão de performance e segurança │
│ │
│ HABILITAÇÃO: │
│ ──────────── │
│ • Mentorar e coaching de desenvolvedores │
│ • Remover bloqueios técnicos │
│ • Compartilhar conhecimento │
│ • Pair em problemas difíceis │
│ │
│ ENTREGA: │
│ ──────── │
│ • Input de viabilidade técnica │
│ • Guia de estimativa de esforço │
│ • Identificação de riscos │
│ • Planejamento técnico do sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ O QUE NÃO É: │
│ ──────────── │
│ ❌ Tomar todas as decisões │
│ ❌ Atribuir tarefas │
│ ❌ Fazer todo trabalho difícil │
│ ❌ Ser o único que entende o sistema │
│ ❌ Guardião do código │
│ │
│ MENTALIDADE: Habilitar a equipe a ter sucesso tecnicamente│
└─────────────────────────────────────────────────────────────┘
Atos de Equilíbrio
Alocação de Tempo
EQUILÍBRIO DE TEMPO DO TECH LEAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ALOCAÇÃO DE TEMPO (varia por tamanho/maturidade da equipe):│
│ │
│ EQUIPE PEQUENA (3-4 devs): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Coding: 50% █████████████████████████ ││
│ │ Code Review: 20% ██████████ ││
│ │ Mentoria: 15% ███████ ││
│ │ Planejamento:15% ███████ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EQUIPE MAIOR (6-8 devs): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Coding: 30% ███████████████ ││
│ │ Code Review: 25% ████████████ ││
│ │ Mentoria: 25% ████████████ ││
│ │ Planejamento:20% ██████████ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MANTER-SE HANDS-ON: │
│ ─────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CODAR ESTRATEGICAMENTE: ││
│ │ ││
│ │ ✅ FAÇA: ││
│ │ • Features complexas/arriscadas ││
│ │ • Código foundacional/reutilizável ││
│ │ • Caminhos críticos de performance ││
│ │ • Provas de conceito ││
│ │ • Estabelecer padrões para outros ││
│ │ ││
│ │ ❌ EVITE: ││
│ │ • Features rotineiras (deixe outros crescerem) ││
│ │ • Entregas time-sensitive (pode ser puxado) ││
│ │ • Tudo (você não é o único dev) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROPÓSITO: Manter conexão com codebase E crescer equipe │
└─────────────────────────────────────────────────────────────┘
Decisões Arquiteturais
Tomando Decisões
DECISÕES DE ARQUITETURA EM ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DECISÕES JUST-IN-TIME: │
│ ────────────────────── │
│ │
│ ❌ UPFRONT (evitar): │
│ "Vamos desenhar toda arquitetura antes de codar" │
│ │
│ ✅ JUST-IN-TIME: │
│ "Vamos decidir quando tivermos informação suficiente" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUANDO DECIDIR: │
│ ─────────────── │
│ │
│ CEDO DEMAIS: │
│ • Muita incerteza │
│ • Informação insuficiente │
│ • Decisão pode mudar │
│ │
│ TARDE DEMAIS: │
│ • Retrabalho significativo │
│ • Opções limitadas │
│ • Custos aumentados │
│ │
│ MOMENTO CERTO (Last Responsible Moment): │
│ • Informação suficiente para decidir │
│ • Ainda tem opções │
│ • Custo de reverter é aceitável │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DOCUMENTAR DECISÕES (ADRs): │
│ ─────────────────────────── │
│ │
│ # ADR-005: Usar Redis para Cache │
│ │
│ Status: Aceito │
│ Contexto: Precisamos de cache para API responses │
│ Decisão: Redis em cluster gerenciado │
│ Consequências: │
│ + Performance excelente │
│ + Equipe conhece │
│ - Custo de infraestrutura │
│ │
│ Alternativas: Memcached, in-memory │
└─────────────────────────────────────────────────────────────┘
Habilitando a Equipe
Multiplicando Impacto
MULTIPLICANDO SEU IMPACTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INDIVIDUAL: │
│ ─────────── │
│ Você escreve código = 1x output │
│ │
│ MULTIPLICADOR: │
│ ───────────── │
│ Você habilita 5 devs a serem 20% melhores │
│ = 1x output + 5 × 0.2 = 2x output │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMO MULTIPLICAR: │
│ │
│ MENTORIA: │
│ • Pair programming em problemas difíceis │
│ • Code reviews educativos (explique o porquê) │
│ • Compartilhe conhecimento proativamente │
│ • Crie oportunidades de stretch │
│ │
│ PADRÕES: │
│ • Documente boas práticas │
│ • Crie templates e boilerplate │
│ • Automatize verificações de qualidade │
│ • Escreva código exemplar │
│ │
│ DESBLOQUEIO: │
│ • Identifique bloqueios cedo │
│ • Resolva dependências de outras equipes │
│ • Tome decisões quando equipe está travada │
│ • Proteja equipe de interrupções │
│ │
│ AUTONOMIA: │
│ • Não microgerencie │
│ • Confie na equipe │
│ • Delegue ownership │
│ • Permita erros (dentro do aceitável) │
└─────────────────────────────────────────────────────────────┘
Mentoria Técnica
MENTORIA EFETIVA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EM CODE REVIEW: │
│ ─────────────── │
│ │
│ ❌ "Use um Map aqui" │
│ │
│ ✅ "Um Map funcionaria bem aqui porque precisamos de │
│ lookup O(1) por chave. Aqui está um exemplo de │
│ como isso melhoraria a performance: [link]" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EM PAIR PROGRAMMING: │
│ ──────────────────── │
│ │
│ • Deixe o mentee digitar │
│ • Faça perguntas ao invés de dar respostas │
│ • Pense em voz alta para modelar raciocínio │
│ • Celebre insights e progresso │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EM 1:1s TÉCNICOS: │
│ ───────────────── │
│ │
│ • Quais desafios técnicos você está enfrentando? │
│ • O que você gostaria de aprender? │
│ • Onde você quer crescer? │
│ • Como posso ajudar a desbloquear? │
└─────────────────────────────────────────────────────────────┘
Saúde Técnica
Monitorando Saúde
MÉTRICAS DE SAÚDE TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CÓDIGO: │
│ ─────── │
│ • Cobertura de testes: > 70% para paths críticos │
│ • Complexidade: Mantendo estável ou diminuindo │
│ • Code smells: Tendência decrescente │
│ │
│ ENTREGA: │
│ ──────── │
│ • Lead time: Tempo do commit ao deploy │
│ • Frequência de deploy: Aumentando │
│ • Taxa de falha: < 10% dos deploys │
│ • MTTR: Tempo para recuperar de incidentes │
│ │
│ DÍVIDA: │
│ ─────── │
│ • Itens de tech debt: Tendência estável ou caindo │
│ • % do sprint em debt: 15-20% │
│ • Idade média da dívida: < 6 meses │
│ │
│ EQUIPE: │
│ ─────── │
│ • PRs travados: < 24h para primeira review │
│ • Knowledge silos: Todo código tem 2+ conhecedores │
│ • Satisfação técnica: Survey periódico │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DASHBOARD NO GITSCRUM: │
│ │
│ Crie Epic "Saúde Técnica" com tarefas recorrentes: │
│ • Atualizar métricas (quinzenal) │
│ • Revisar tech debt (mensal) │
│ • Health check da equipe (trimestral) │
└─────────────────────────────────────────────────────────────┘
Comunicação
Comunicando para Stakeholders
TRADUZINDO TÉCNICO PARA NEGÓCIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROBLEMA TÉCNICO → IMPACTO DE NEGÓCIO │
│ │
│ "Monolito difícil de escalar" │
│ ↓ │
│ "Com crescimento atual, teremos lentidão em 6 meses │
│ e não conseguiremos suportar black friday" │
│ │
│ "Precisamos atualizar o framework" │
│ ↓ │
│ "Versão atual não recebe patches de segurança. │
│ Investimento agora evita incidente depois" │
│ │
│ "Cobertura de testes baixa" │
│ ↓ │
│ "Cada release tem 30% de chance de causar regressão. │
│ Testes reduziriam bugs em produção em 50%" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTRUTURA DE UPDATE: │
│ │
│ 1. Status geral (on track / at risk / blocked) │
│ 2. Progresso técnico chave │
│ 3. Riscos e mitigações │
│ 4. Decisões necessárias │
│ 5. Próximos marcos │
└─────────────────────────────────────────────────────────────┘