8 min leitura • Guide 795 of 877
Sessões de Mob Programming
Mob programming traz o time inteiro junto em problemas complexos. GitScrum ajuda a coordenar sessões de mob e rastrear seus resultados.
Fundamentos de Mob Programming
O que é Mobbing
CONCEITO DE MOB PROGRAMMING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DESENVOLVIMENTO TRADICIONAL: │
│ ───────────────────────────── │
│ 4 desenvolvedores → 4 tarefas diferentes → merge → review │
│ → conflitos → bugs → retrabalho │
│ │
│ MOB PROGRAMMING: │
│ ───────────────── │
│ 4 desenvolvedores → 1 tarefa juntos → feito certo 1ª vez │
│ → sem review necessário → sem silos de conhecimento │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ O MOB: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 👤 👤 👤 👤 ← Navegadores (pensando, guiando) ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────┐ ││
│ │ │ ⌨️ │ ← Driver (só digita) ││
│ │ └───────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────────────────────────────────────┐ ││
│ │ │ TELA GRANDE │ ││
│ │ │ (todos veem) │ ││
│ │ └───────────────────────────────────────┘ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DRIVER: Digita o que navegadores dizem │
│ NAVEGADORES: Pensam, discutem, direcionam o driver │
│ ROTAÇÃO: Driver muda a cada 5-10 minutos │
└─────────────────────────────────────────────────────────────┘
Quando Usar Mob
BONS USOS PARA MOBBING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MELHOR PARA: │
│ ──────────── │
│ │
│ DECISÕES DE DESIGN COMPLEXAS: │
│ "Como devemos arquitetar essa feature?" │
│ Time chega a consenso enquanto coda │
│ │
│ BUGS DIFÍCEIS: │
│ "Ninguém consegue resolver sozinho" │
│ Múltiplas perspectivas ajudam │
│ │
│ ESTABELECENDO PADRÕES: │
│ "Como vamos fazer X em todo o codebase?" │
│ Todos aprendem o padrão juntos │
│ │
│ ONBOARDING: │
│ "Pessoa nova precisa aprender nosso codebase" │
│ Observa e participa │
│ │
│ CÓDIGO DE ALTO RISCO: │
│ "Isso é crítico e arriscado" │
│ Propriedade coletiva e review │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NÃO BOM PARA: │
│ ───────────── │
│ ❌ Tarefas simples e rotineiras │
│ ❌ Pesquisa independente │
│ ❌ Quando time é muito grande (máx 5-6) │
│ ❌ O dia todo todo dia (exaustivo) │
│ ❌ Quando loops de feedback rápido já existem │
└─────────────────────────────────────────────────────────────┘
Executando uma Sessão de Mob
Estrutura da Sessão
ESTRUTURA DA SESSÃO DE MOB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES (5-10 min): │
│ ────────────────── │
│ • Declaração clara do problema │
│ • Contexto relevante compartilhado │
│ • Ambiente pronto │
│ • Tela grande / projetor / tela compartilhada │
│ │
│ DURANTE: │
│ ──────── │
│ • Rotacionar driver a cada 5-10 minutos │
│ • Navegadores discutem abordagem │
│ • Driver digita o que mob concorda │
│ • Pausas a cada 50-60 minutos │
│ │
│ DEPOIS (5-10 min): │
│ ────────────────── │
│ • Retrospectiva rápida │
│ • Documentar decisões tomadas │
│ • Identificar trabalho de follow-up │
│ │
│ TIMELINE TÍPICA (2 horas): │
│ ────────────────────────── │
│ │
│ 00:00 - 00:10 Setup e contexto │
│ 00:10 - 00:50 Bloco de trabalho 1 │
│ 00:50 - 01:00 Pausa │
│ 01:00 - 01:50 Bloco de trabalho 2 │
│ 01:50 - 02:00 Wrap-up e retro │
│ │
└─────────────────────────────────────────────────────────────┘
Rotação de Papéis
GESTÃO DE ROTAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMER VISÍVEL: │
│ ────────────── │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Próxima rotação: 7:23 │ │
│ │ │ │
│ │ Driver atual: Maria │ │
│ │ Próximo: João │ │
│ │ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ REGRAS DE ROTAÇÃO: │
│ ────────────────── │
│ • Timer termina → rotação imediata │
│ • Não "deixa eu só terminar isso..." │
│ • Próximo driver continua de onde parou │
│ • Força transferência de contexto │
│ │
│ ORDEM DE ROTAÇÃO: │
│ ────────────────── │
│ Opção 1: Círculo fixo (A → B → C → D → A...) │
│ Opção 2: Voluntário próximo │
│ Opção 3: Menos experiente primeiro (para onboarding) │
│ │
└─────────────────────────────────────────────────────────────┘
Navegação Efetiva
Níveis de Direção
TIPOS DE NAVEGAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÍVEL 1 - INTENÇÃO (alto nível): │
│ ───────────────────────────────── │
│ "Vamos extrair essa lógica para uma função" │
│ Driver experiente sabe como fazer │
│ │
│ NÍVEL 2 - LOCALIZAÇÃO (médio): │
│ ─────────────────────────────── │
│ "Abre o arquivo utils.js, função validateEmail" │
│ Driver precisa direção de onde │
│ │
│ NÍVEL 3 - SINTAXE (detalhado): │
│ ─────────────────────────────── │
│ "Digita const isValid = email.includes('@')" │
│ Driver sendo guiado caractere por caractere │
│ │
│ AJUSTE EM TEMPO REAL: │
│ ───────────────────── │
│ • Driver experiente na área → Nível 1 │
│ • Driver médio → Nível 2 │
│ • Driver aprendendo → Nível 3 │
│ • Observe se driver está perdido → desça nível │
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Gerenciando Sessões de Mob
TAREFAS DE MOB NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE MOB: │
│ ─────────────── │
│ │
│ Título: [MOB] Arquitetura de autenticação │
│ │
│ Descrição: │
│ Sessão de mob para definir e implementar │
│ arquitetura de autenticação do novo sistema. │
│ │
│ Objetivo: │
│ Código base de auth implementado com consenso │
│ │
│ Participantes: │
│ @ana, @carlos, @maria, @pedro │
│ │
│ Duração estimada: 2 horas │
│ │
│ Labels: mob-session, architecture, auth │
│ │
│ APÓS SESSÃO (atualizar): │
│ ────────────────────────── │
│ Decisões: │
│ - JWT para tokens de sessão │
│ - Refresh token com 7 dias │
│ - Redis para blacklist de tokens │
│ │
│ Código produzido: │
│ - auth/service.js - básico implementado │
│ - auth/middleware.js - 80% completo │
│ │
│ Follow-up: │
│ - [ ] Completar testes unitários │
│ - [ ] Documentar API de auth │
│ │
└─────────────────────────────────────────────────────────────┘
Mob Remoto
Configuração Distribuída
MOB REMOTO EFETIVO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FERRAMENTAS ESSENCIAIS: │
│ ──────────────────────── │
│ │
│ COLABORAÇÃO DE CÓDIGO: │
│ ├── VS Code Live Share (preferido) │
│ ├── JetBrains Code With Me │
│ ├── Tuple / Pop / CoScreen │
│ └── Todos podem editar, driver controla │
│ │
│ VIDEO: │
│ ├── Câmeras ligadas (importante!) │
│ ├── Zoom / Teams / Meet │
│ └── Ver rostos ajuda comunicação │
│ │
│ TIMER: │
│ ├── mob.sh (timer de terminal) │
│ ├── mobti.me (web) │
│ └── Alarme audível para todos │
│ │
│ AJUSTES PARA REMOTO: │
│ ────────────────────── │
│ • Rotações mais longas (10-15 min) │
│ • Mais verbalização de pensamento │
│ • Pausas mais frequentes │
│ • "Desligar para pausa" OK │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE SESSÃO DE MOB
══════════════════════════
PRÉ-SESSÃO:
☐ Problema claramente definido
☐ Participantes confirmados (max 5-6)
☐ Ambiente configurado
☐ Timer pronto
DURANTE:
☐ Rotações estritas respeitadas
☐ Todos participando
☐ Pausas regulares
☐ Decisões documentadas em tempo real
PÓS-SESSÃO:
☐ Retrospectiva rápida (5 min)
☐ Tarefa atualizada com resultados
☐ Follow-ups criados
☐ Próxima sessão agendada (se necessário)
MÉTRICAS:
☐ Satisfação dos participantes
☐ Código produzido
☐ Bugs encontrados depois
☐ Conhecimento distribuído
Mob programming transforma problemas complexos em oportunidades de crescimento coletivo do time.