9 min leitura • Guide 792 of 877
Limites de WIP e Gestão de Fluxo
Menos trabalho em progresso significa entrega mais rápida. O GitScrum suporta limites de WIP para ajudar equipes a terminar trabalho antes de começar trabalho novo.
Entendendo WIP
O Problema de Fluxo
POR QUE LIMITES DE WIP IMPORTAM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEM LIMITES DE WIP: │
│ ─────────────────── │
│ │
│ TO DO EM PROGRESSO TESTING DONE │
│ ────── ──────────── ─────── ──── │
│ ┌────┐ ┌────┐ │
│ ┌────┐ │ │ │ │ ┌────┐ ┌────┐ │
│ │ │ │ │ │ │ │ 🕐 │ │ ✅ │ │
│ └────┘ │ │ │ │ │ │ │ │ │
│ ┌────┐ └────┘ └────┘ └────┘ └────┘ │
│ │ │ ┌────┐ ┌────┐ │
│ └────┘ │ │ │ │ │
│ ┌────┐ │ │ │ │ ← 6 em progresso │
│ │ │ └────┘ └────┘ ← 1 bloqueado em teste │
│ └────┘ ┌────┐ ┌────┐ ← Muito pouco feito │
│ │ │ │ │ │
│ └────┘ └────┘ │
│ │
│ PROBLEMAS: │
│ • Todos ocupados, pouco terminando │
│ • Troca de contexto entre tarefas │
│ • Teste acumulando │
│ • Gargalo escondido │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COM LIMITES DE WIP: │
│ ───────────────── │
│ │
│ TO DO EM PROGRESSO (3) TESTING (2) DONE │
│ ────── ──────────────── ─────────── ──── │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ ┌────┐ │ │ │ │ │ │ │ │ ┌────┐ │
│ │ │ │ │ │ │ │ │ │ │ │ ✅ │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ │ │ │
│ ┌────┐ ┌────┐ └────┘ │
│ │ │ │ │ 🛑 ┌────┐ │
│ └────┘ └────┘ PARE! │ ✅ │ │
│ ┌────┐ Limite atingido │ │ │
│ │ │ Ajude no teste! └────┘ │
│ └────┘ ┌────┐ │
│ │ ✅ │ │
│ └────┘ │
│ │
│ BENEFÍCIOS: │
│ • Gargalo visível (teste) │
│ • Time se une para ajudar │
│ • Mais terminando, menos começando │
│ • Cycle time mais rápido │
└─────────────────────────────────────────────────────────────┘
Definindo Limites de WIP
Limites Iniciais
DEFININDO LIMITES DE WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PONTO DE PARTIDA: │
│ ─────────────── │
│ │
│ Regra geral: # de pessoas que trabalham naquele estágio │
│ │
│ EXEMPLO (Time de 5): │
│ • 3 desenvolvedores → Limite Em Progresso = 3 │
│ • 1 QA → Limite de Teste = 1 ou 2 │
│ • Code Review → 2-3 itens │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOARD COM LIMITES: │
│ │
│ TO DO EM PROGRESSO CODE REVIEW TESTING DONE │
│ ────── [Limite: 4] [Limite: 3] [Limite: 2] ──── │
│ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ │ │ 1 │ │ 2 │ │ 1 │ │ 1 │ │ ✅ │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ │ │ 3 │ │ 4 │ │ 2 │ │ 2 │ │ ✅ │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ ┌────┐ ┌────┐ ⬆️ CHEIO │
│ │ │ │ 3 │ │
│ └────┘ ⬆️ CHEIO └────┘ │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AJUSTANDO: │
│ │
│ LIMITE MUITO BAIXO: │
│ • Pessoas ociosas │
│ • Trabalho esperando para entrar │
│ → Aumente o limite │
│ │
│ LIMITE MUITO ALTO: │
│ • Ainda tem troca de contexto │
│ • Gargalos não visíveis │
│ → Diminua o limite │
│ │
│ CORRETO: │
│ • Bloqueio ocasional (esperado) │
│ • Time colabora em gargalos │
│ • Fluxo suave na maioria do tempo │
└─────────────────────────────────────────────────────────────┘
Limites por Tipo de Trabalho
WIP POR CATEGORIA
═════════════════
FEATURES:
─────────────────────────────────────
Limite: 2-3 por desenvolvedor
├── Features são maiores
├── Precisam de foco
├── Troca de contexto caro
└── Menos é melhor
BUGS:
─────────────────────────────────────
Limite: 1-2 em progresso
├── Bugs são menores
├── Resolver rápido
├── Não acumular
└── Prioridade sobre features às vezes
TECH DEBT:
─────────────────────────────────────
Limite: 1 item ativo
├── Trabalho contínuo de fundo
├── Não dominar sprint
├── Progresso constante
└── 10-20% da capacidade
SWIMLANES COM LIMITES:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ TO DO DOING (WIP) DONE │
│ ─────────────────────────────────────────────────────── │
│ FEATURES ┌────┐ ┌────┐ [2] ┌────┐ │
│ [2] │ │ │ 1 │ │ ✅ │ │
│ └────┘ └────┘ └────┘ │
│ ─────────────────────────────────────────────────────── │
│ BUGS ┌────┐ ┌────┐ [1] ┌────┐ ┌────┐ │
│ [1] │ 🐛 │ │ 🐛 │ │ 🐛 │ │ 🐛 │ │
│ └────┘ └────┘ └────┘ └────┘ │
│ ─────────────────────────────────────────────────────── │
│ DEBT ┌────┐ [1] │
│ [1] │ 🔧 │ │
│ └────┘ │
└─────────────────────────────────────────────────────────┘
Gestão de Fluxo
Visualizando Fluxo
CUMULATIVE FLOW DIAGRAM
═══════════════════════
O QUE MOSTRA:
─────────────────────────────────────
Áreas empilhadas ao longo do tempo:
├── Trabalho em cada estágio
├── Acúmulo em filas
├── Taxa de chegada vs conclusão
└── Tendências de fluxo
EXEMPLO:
─────────────────────────────────────
Itens
40│ ████████████████████ Done
│ ████████████████░░░░░░░░
35│ ████████████░░░░░░░░░░░░░░░░░ Testing
│████████░░░░░░░░░░░░░░░░░░░░░░░
30│░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ In Progress
│░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
25│░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ To Do
│░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
└────────────────────────────────→
Semana 1 2 3 4 5
INTERPRETAÇÃO:
─────────────────────────────────────
Banda larga = Muito WIP naquele estágio
Banda estreitando = Gargalo
Bandas paralelas = Fluxo saudável
Área crescendo = Trabalho acumulando
Métricas de Fluxo
MÉTRICAS CHAVE
══════════════
LEAD TIME:
─────────────────────────────────────
Tempo de criação até conclusão
├── Inclui tempo de espera
├── Perspectiva do cliente
├── Alvo: Reduzir continuamente
└── Menor = Melhor
CYCLE TIME:
─────────────────────────────────────
Tempo de início do trabalho até conclusão
├── Tempo "ativo"
├── Perspectiva do time
├── Mais controlável
└── Menor = Mais eficiente
THROUGHPUT:
─────────────────────────────────────
Itens completados por período
├── Por semana ou sprint
├── Capacidade do sistema
├── Previsibilidade
└── Tendência mais importante que valor
WORK ITEM AGE:
─────────────────────────────────────
Quanto tempo item está em progresso
├── Alerta para itens envelhecendo
├── Identificar bloqueios
├── SLA interno
└── Agir se passar do limite
Implementação no GitScrum
Configurando WIP Limits
CONFIGURAÇÃO NO GITSCRUM
════════════════════════
HABILITANDO WIP LIMITS:
─────────────────────────────────────
Board Settings → Columns:
├── Selecionar coluna
├── Definir "WIP Limit"
├── Salvar
COMPORTAMENTO:
─────────────────────────────────────
Quando limite atingido:
├── Coluna muda de cor (vermelho/amarelo)
├── Aviso ao arrastar item
├── Opção de forçar (com motivo)
├── Registro de violações
└── Alerta para time
VISUALIZAÇÃO:
─────────────────────────────────────
┌────────────────────────────────────┐
│ EM PROGRESSO [4/3] ⚠️ EXCEDIDO │
├────────────────────────────────────┤
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │
│ └────┘ └────┘ └────┘ └────┘ │
└────────────────────────────────────┘
RELATÓRIOS DE WIP:
─────────────────────────────────────
├── WIP médio por coluna
├── Frequência de violações
├── Correlação WIP vs lead time
├── Tendências ao longo do tempo
└── Recomendações de ajuste
Regras de Fluxo
POLÍTICAS DE FLUXO
══════════════════
POLICY: PUXAR, NÃO EMPURRAR
─────────────────────────────────────
Não empurre trabalho para frente.
Puxe quando tiver capacidade.
Certo:
├── "Terminei, vou puxar próximo item"
├── "Testing está vazio, posso ajudar"
└── "Vou esperar abrir vaga antes de começar novo"
Errado:
├── "Vou começar mais um enquanto espero"
├── "Joga pra review, depois vejo"
└── "Começa logo, depois a gente termina"
POLICY: SWARMING EM GARGALOS
─────────────────────────────────────
Quando coluna atinge limite:
├── Pare de iniciar novo trabalho
├── Ajude a desbloquear gargalo
├── Todo time foca em mover trabalho
└── Só puxe novo quando fluir
POLICY: IDADE MÁXIMA
─────────────────────────────────────
Item em progresso > X dias:
├── Alerta automático
├── Discussão na daily
├── Ação para desbloquear
├── Considerar split ou pausa
└── Evitar itens "mortos" no board
Boas Práticas
O Que Fazer e Não Fazer
BOAS PRÁTICAS DE WIP
════════════════════
FAÇA:
─────────────────────────────────────
✓ Comece com limites conservadores
✓ Ajuste baseado em dados
✓ Respeite os limites (não ignore)
✓ Investigue violações
✓ Use WIP para expor problemas
✓ Ajude colegas quando bloqueado
✓ Celebre fluxo melhorado
NÃO FAÇA:
─────────────────────────────────────
✗ Definir limites muito altos (inútil)
✗ Ignorar limites consistentemente
✗ Forçar sem investigar causa
✗ Culpar indivíduos por gargalos
✗ Mudar limites sem observar
✗ Ter WIP limits só no papel
✗ Esquecer de medir impacto
SINAIS DE SUCESSO:
─────────────────────────────────────
├── Lead time diminuindo
├── Menos contexto switching
├── Mais trabalho terminado
├── Gargalos identificados e tratados
├── Time colaborando mais
└── Previsibilidade melhorando
Resistência Comum
LIDANDO COM OBJEÇÕES
════════════════════
"MAS VOU FICAR OCIOSO!"
─────────────────────────────────────
Respostas:
├── Ajude em outra área (teste, review)
├── Trabalhe na documentação
├── Faça pair programming
├── Reduza tech debt
├── Aprenda algo novo
└── Idle time < tempo perdido em switching
"PRECISO COMEÇAR MAIS PARA ENTREGAR MAIS"
─────────────────────────────────────
Paradoxo:
├── Começar mais ≠ terminar mais
├── Alto WIP = tempo em filas
├── Foco = terminar rápido
├── Terminar 1 antes de começar outro
└── Dados provam: menos WIP = mais throughput
"ISSO VAI NOS DEIXAR MAIS LENTOS"
─────────────────────────────────────
Realidade:
├── Parece mais lento no início
├── Expõe problemas escondidos
├── Melhoria requer mudança
├── Resultados em 2-4 semanas
└── Meça antes/depois para provar