8 min leitura • Guide 835 of 877
Práticas de Mob Programming
Um teclado, time inteiro. GitScrum ajuda a coordenar sessões de mob e rastrear seu impacto na qualidade e capacidade do time.
Fundamentos de Mob Programming
Como Funciona
MOB PROGRAMMING EXPLICADO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O SETUP: │
│ ──────── │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ │ │
│ │ TELA GRANDE │ │
│ │ │ │
│ └───────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌────┐ ┌────┴────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑💻 │ │ 🧑 │ │
│ │ │ │ DRIVER │ │ │ │
│ └────┘ └─────────┘ └────┘ │
│ Navegador Só digita Navegador │
│ │
│ ┌────┐ ┌────┐ │
│ │ 🧑 │ │ 🧑 │ │
│ │ │ │ │ │
│ └────┘ └────┘ │
│ Navegador Navegador │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PAPÉIS: │
│ ─────── │
│ DRIVER: Digita código, não decide o que digitar │
│ NAVEGADORES: Direcionam o driver, discutem soluções │
│ │
│ "Para uma ideia entrar no computador, ela deve passar │
│ pelas mãos de outra pessoa." │
└─────────────────────────────────────────────────────────────┘
Estrutura da Sessão
Executando um Mob
FLUXO DA SESSÃO DE MOB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA DA SESSÃO (2 horas): │
│ ────────────────────────────── │
│ │
│ 0:00 - 0:05 SETUP │
│ • Definir objetivo da sessão │
│ • Garantir que todos veem a tela │
│ • Primeiro driver no teclado │
│ │
│ 0:05 - 0:50 TRABALHO MOB (Bloco 1) │
│ • Rotacionar driver a cada 10-15 min │
│ • 3-4 rotações │
│ • Navegadores guiam trabalho │
│ │
│ 0:50 - 1:00 PAUSA │
│ • Levantar, alongar, banheiro │
│ • Sync rápido de progresso │
│ │
│ 1:00 - 1:50 TRABALHO MOB (Bloco 2) │
│ • Continuar rotacionando │
│ • Mais 3-4 rotações │
│ │
│ 1:50 - 2:00 ENCERRAMENTO │
│ • O que conseguimos? │
│ • O que falta? │
│ • Como foi a sessão? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIMER: │
│ ────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🕐 Rotação de driver: 12:00 ││
│ │ ││
│ │ Driver atual: Ana ││
│ │ Próximo: Carlos ││
│ │ ││
│ │ [Timer visível para todos] ││
│ │ [Rotação estrita, sem exceções] ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Quando Usar Mob
Melhores Casos de Uso
QUANDO MOB PROGRAMMING BRILHA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ CASOS DE ALTO VALOR: │
│ ────────────────────── │
│ │
│ PROBLEMAS COMPLEXOS: │
│ "Isso é muito difícil para uma pessoa" │
│ → Múltiplas perspectivas encontram soluções melhores │
│ │
│ TRANSFERÊNCIA DE CONHECIMENTO: │
│ "Só o João sabe como isso funciona" │
│ → Todos aprendem fazendo juntos │
│ │
│ ONBOARDING: │
│ "Pessoa nova no time" │
│ → Absorve cultura, padrões, conhecimento rapidamente │
│ │
│ CÓDIGO DE ALTO RISCO: │
│ "Se der errado, impacto grande" │
│ → Múltiplos olhos, menos chance de erro │
│ │
│ DECISÕES DE ARQUITETURA: │
│ "Precisamos decidir a abordagem" │
│ → Consenso construído em tempo real │
│ │
│ ❌ EVITAR PARA: │
│ ────────────── │
│ • Tarefas rotineiras e simples │
│ • Trabalho que uma pessoa faz facilmente │
│ • Quando time não está disponível junto │
│ • Documentação simples │
│ │
└─────────────────────────────────────────────────────────────┘
Dinâmicas de Mob
Navegação Efetiva
NÍVEIS DE NAVEGAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRÊS NÍVEIS DE DIREÇÃO: │
│ ──────────────────────── │
│ │
│ NÍVEL 1: INTENÇÃO (para experts) │
│ ───────────────────────────────── │
│ "Implemente validação do formulário" │
│ Driver sabe como fazer, só precisa direção │
│ │
│ NÍVEL 2: LOCALIZAÇÃO (médio) │
│ ───────────────────────────────── │
│ "Abra o arquivo validation.js, função validateForm" │
│ Driver precisa saber onde, mas sabe fazer │
│ │
│ NÍVEL 3: SINTAXE (para aprendizes) │
│ ───────────────────────────────── │
│ "Digite: if (email.includes('@')) { return true; }" │
│ Driver é guiado caractere por caractere │
│ │
│ ESCOLHA BASEADA NO DRIVER: │
│ ────────────────────────── │
│ • Driver experiente → Nível 1 │
│ • Driver médio → Nível 2 │
│ • Driver aprendiz → Nível 3 │
│ • Adapte em tempo real │
│ │
└─────────────────────────────────────────────────────────────┘
Regras do Mob
REGRAS FUNDAMENTAIS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGRAS DE PARTICIPAÇÃO: │
│ ──────────────────────── │
│ │
│ 1. DRIVER NÃO DECIDE │
│ Driver executa, não pensa │
│ Se driver começa a decidir sozinho → navegadores falam │
│ │
│ 2. TODOS PARTICIPAM │
│ Silêncio não é permitido │
│ Se não tem opinião, faça perguntas │
│ │
│ 3. ROTAÇÃO ESTRITA │
│ Timer terminou → troca │
│ Não importa se "quase terminou" │
│ │
│ 4. RESPEITE IDEIAS │
│ "Sim, e..." em vez de "Não, mas..." │
│ Experimente antes de criticar │
│ │
│ 5. UMA CONVERSA │
│ Não há discussões paralelas │
│ Todos ouvem, todos contribuem │
│ │
│ ANTI-PADRÕES: │
│ ────────────── │
│ ❌ Driver codando sozinho │
│ ❌ Uma pessoa dominando discussão │
│ ❌ Pular rotação │
│ ❌ Conversas paralelas │
│ ❌ Criticar sem propor alternativa │
│ │
└─────────────────────────────────────────────────────────────┘
Mob Remoto
Mob Programming Distribuído
MOB REMOTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FERRAMENTAS: │
│ ─────────── │
│ │
│ COMPARTILHAMENTO DE TELA: │
│ ├── VS Code Live Share (preferido) │
│ ├── Screen share com controle remoto │
│ ├── Tuple, Pop, CoScreen │
│ └── Qualquer IDE colaborativo │
│ │
│ VIDEO CONFERÊNCIA: │
│ ├── Zoom, Teams, Google Meet │
│ ├── Câmeras ligadas (importante!) │
│ └── Audio claro para todos │
│ │
│ TIMER: │
│ ├── Mob Timer app (mobti.me) │
│ ├── Timer compartilhado visível │
│ └── Alarme audível para todos │
│ │
│ DESAFIOS REMOTOS: │
│ ───────────────── │
│ • Latência → Rotações mais longas (15-20 min) │
│ • Energia → Pausas mais frequentes │
│ • Comunicação → Mais verbal, menos visual │
│ • Foco → Eliminar distrações, full-screen │
│ │
└─────────────────────────────────────────────────────────────┘
Medindo Impacto
Métricas de Mob
MÉTRICAS DE MOB PROGRAMMING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUALIDADE: │
│ ────────── │
│ • Bugs em código "mobbado" vs solo │
│ • Code review feedback (deve ser mínimo) │
│ • Rework necessário │
│ │
│ CONHECIMENTO: │
│ ───────────── │
│ • Pessoas que podem manter o código │
│ • Bus factor antes/depois │
│ • Confiança em áreas do codebase │
│ │
│ SATISFAÇÃO: │
│ ───────────── │
│ • Survey pós-sessão (1-5) │
│ • Engajamento durante sessões │
│ • Pedidos para mais mob │
│ │
│ EFICIÊNCIA: │
│ ──────────── │
│ • Tempo até produção para código mobbado │
│ • Comparar com solo (considerando reviews) │
│ • Não é "5 pessoas = 5x mais lento" │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE MOB PROGRAMMING
════════════════════════════
PREPARAÇÃO:
☐ Objetivo claro definido
☐ Ambiente de mob configurado
☐ Timer visível para todos
☐ Ordem de rotação definida
DURANTE:
☐ Rotações estritas respeitadas
☐ Todos participando ativamente
☐ Driver não decide sozinho
☐ Pausas regulares
FACILITAÇÃO:
☐ Alguém facilita (não é driver fixo)
☐ Interrompe anti-padrões gentilmente
☐ Garante que todos falem
☐ Gerencia energia do grupo
PÓS-SESSÃO:
☐ Retrospectiva rápida (5 min)
☐ Próximos passos definidos
☐ Aprendizados documentados
☐ Impacto rastreado
Mob programming não é sobre velocidade individual—é sobre qualidade coletiva e conhecimento compartilhado que tornam o time mais forte.