Melhorando Performance do Time com Métricas
Use dados para impulsionar melhoria do time sem criar cultura tóxica de medição. Selecione métricas que importam e interprete-as sabiamente.
7 min de leitura
Métricas iluminam performance do time e guiam melhoria quando usadas com cuidado. GitScrum fornece analytics de time incluindo velocidade, tempo de ciclo e métricas de qualidade que ajudam times a identificar oportunidades de melhoria sem fomentar competição prejudicial.
Filosofia de Métricas
Cultura Saudável de Métricas
PRINCÍPIOS DE MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FAÇA: │
│ ✓ Use métricas para aprendizado e melhoria do time │
│ ✓ Foque em tendências ao longo do tempo, não absolutos │
│ ✓ Deixe times escolherem e serem donos de suas métricas │
│ ✓ Discuta métricas em retrospectivas │
│ ✓ Celebre melhorias │
│ ✓ Use múltiplas métricas (balanced scorecard) │
│ │
│ NÃO FAÇA: │
│ ✗ Compare indivíduos usando métricas │
│ ✗ Vincule métricas diretamente a compensação │
│ ✗ Use métricas punitivamente │
│ ✗ Otimize para métricas únicas │
│ ✗ Ignore contexto ao interpretar │
│ ✗ Estabeleça metas arbitrárias │
│ │
│ LEI DE GOODHART: │
│ "Quando uma medida se torna um alvo, ela deixa de ser │
│ uma boa medida." │
│ │
│ Exemplo: Se você mede linhas de código, pessoas vão │
│ escrever código mais verboso, não melhor código. │
└─────────────────────────────────────────────────────────────┘
Categorias de Métricas
FRAMEWORK DE MÉTRICAS BALANCEADAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ENTREGA: │
│ Quanto trabalho está sendo feito? │
│ • Velocidade (story points/sprint) │
│ • Throughput (itens/semana) │
│ • Taxa de conclusão de sprint │
│ │
│ VELOCIDADE: │
│ Quão rápido o trabalho flui? │
│ • Tempo de ciclo (início ao done) │
│ • Lead time (pedido ao done) │
│ • Turnaround de review │
│ │
│ QUALIDADE: │
│ Quão bom é o trabalho? │
│ • Taxa de defeitos (bugs por feature) │
│ • Defeitos escapados (bugs em produção) │
│ • Razão de dívida técnica │
│ │
│ SAÚDE DO TIME: │
│ Como o time está? │
│ • Pesquisas de satisfação do time │
│ • Taxa de turnover │
│ • Tempo de foco (horas ininterruptas) │
│ │
│ EQUILÍBRIO: Melhorar um não deve prejudicar outros │
│ Exemplo: Entrega mais rápida não deve aumentar defeitos │
└─────────────────────────────────────────────────────────────┘
Métricas Principais
Rastreamento de Velocidade
ANÁLISE DE VELOCIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TENDÊNCIA DE VELOCIDADE DO SPRINT: │
│ │
│ Sprint 20: ████████████████░░░░ 32 pts │
│ Sprint 21: █████████████████░░░ 34 pts │
│ Sprint 22: ███████████████░░░░░ 30 pts (feriados) │
│ Sprint 23: ██████████████████░░ 36 pts │
│ Sprint 24: ███████████████████░ 38 pts │
│ │
│ Média: 34 pts | Faixa: 30-38 | Tendência: Estável ↑ │
│ │
│ INTERPRETANDO VELOCIDADE: │
│ │
│ ✓ BOM USO: │
│ • Planejamento de capacidade para próximo sprint │
│ • Rastrear melhoria própria do time │
│ • Identificar sprints incomuns (investigar) │
│ │
│ ✗ MAU USO: │
│ • Comparar times (pontos não são universais) │
│ • Estabelecer metas de velocidade (gaming) │
│ • Julgar performance individual │
│ │
│ VARIAÇÃO É NORMAL: │
│ • Feriados, doenças, context switching │
│ • Mix de trabalho complexo vs simples │
│ • Mudanças na composição do time │
└─────────────────────────────────────────────────────────────┘
Tempo de Ciclo
ANÁLISE DE TEMPO DE CICLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BREAKDOWN DE TEMPO DE CICLO: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Desenvolvimento │ Code Review │ QA │ Deploy ││
│ │ 3 dias │ 1.5 dias │ 2 dias│ 0.5 dia ││
│ │ ████████████ │ █████ │ ██████│ ██ ││
│ └─────────────────────────────────────────────────────────┘│
│ Tempo Total de Ciclo: 7 dias │
│ │
│ ONDE ESTÁ O DESPERDÍCIO? │
│ • Tempo de espera entre estágios │
│ • Review demorado (item esperando por reviewers) │
│ • Filas de QA (muito trabalho, poucos testadores) │
│ │
│ MÉTRICAS DE TEMPO DE CICLO: │
│ • Média: 7.2 dias │
│ • Mediana: 6 dias │
│ • 85º percentil: 12 dias │
│ • Meta: < 5 dias para trabalho padrão │
│ │
│ AÇÕES: │
│ • Estabelecer SLAs de review (< 24 horas) │
│ • Aumentar capacidade de QA │
│ • Automatizar testes de regressão │
└─────────────────────────────────────────────────────────────┘
Dashboard de Métricas
Visualização de Performance do Time
DASHBOARD DE PERFORMANCE NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ HEALTH SCORE DO TIME │
│ ══════════════════ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Velocidade: 34 pts ████████████████░░░░ 85% │ │
│ │ Tempo Ciclo: 7d ██████████████░░░░░░ 70% │ │
│ │ Qualidade: 2.1 bugs ████████████████████ 95% │ │
│ │ Previsibilidade: 78% ███████████████░░░░░ 78% │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ TENDÊNCIAS (6 sprints) │
│ ═══════════════════════ │
│ Velocidade: ↑ +12% (melhorando) │
│ Tempo de Ciclo: → estável │
│ Qualidade: ↑ +25% (menos bugs) │
│ Previsibilidade: ↓ -5% (foco necessário) │
│ │
│ ÁREAS DE FOCO │
│ ═════════════════ │
│ 1. Tempo de code review aumentado 2 dias │
│ 2. Previsibilidade de sprint diminuiu │
│ 3. Um item de trabalho está bloqueado há 5 dias │
│ │
│ AÇÕES SUGERIDAS │
│ ══════════════════ │
│ • Estabelecer SLA de review de 24 horas │
│ • Melhorar refinement para melhor estimativa │
│ • Resolver item bloqueado urgentemente │
└─────────────────────────────────────────────────────────────┘
Melhoria Baseada em Métricas
Usando Métricas em Retrospectivas
RETROSPECTIVA ORIENTADA POR MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AGENDA DE RETRO: │
│ │
│ 1. REVISÃO DE MÉTRICAS (10 min) │
│ • Apresentar métricas do sprint │
│ • Comparar com sprints anteriores │
│ • Destacar mudanças significativas │
│ │
│ 2. DISCUSSÃO DE MÉTRICAS (15 min) │
│ "O que essas métricas nos dizem?" │
│ "O que causou essa mudança?" │
│ "Estamos medindo as coisas certas?" │
│ │
│ 3. CORRELACIONAR COM EXPERIÊNCIA (10 min) │
│ "Os dados correspondem à nossa percepção?" │
│ "O que os dados não capturam?" │
│ │
│ 4. ITENS DE AÇÃO (10 min) │
│ "O que podemos melhorar?" │
│ Escolher 1-2 experimentos para próximo sprint │
│ Definir como medir sucesso │
│ │
│ PRÓXIMO SPRINT: Revisar se experimentos melhoraram métricas │
└─────────────────────────────────────────────────────────────┘
Evitando Armadilhas de Métricas
| Armadilha | Sintoma | Solução |
|---|---|---|
| Gaming | Números sobem, valor desce | Múltiplas métricas |
| Vaidade | Boa aparência, sem impacto | Foco em resultados |
| Sobrecarga | Muito para rastrear | 3-5 métricas chave |
| Desconexão | Métricas ≠ realidade | Validar com time |
| Obsessão | Métricas sobre pessoas | Contexto primeiro |