6 min leitura • Guide 669 of 877
Como Usar Colunas de Board Kanban e Limites WIP no GitScrum
Colunas Kanban bem projetadas e limites WIP transformam seu board de uma simples lista de tarefas em um sistema de otimização de fluxo. A configuração flexível de board do GitScrum ajuda times a visualizar seu workflow, limitar trabalho em progresso e melhorar continuamente seu processo.
Design de Colunas do Board
Board de Desenvolvimento Padrão
BOARD KANBAN DE DESENVOLVIMENTO BÁSICO:
┌─────────────────────────────────────────────────────────────┐
│ BACKLOG │ PRONTO │ EM PROGRESSO│ REVIEW │ DONE │
│ (s/ limite)│ (5) │ (4) │ (3) │ │
├───────────┼─────────┼─────────────┼─────────┼──────────────┤
│ │ │ │ │ │
│ □ Story 8 │ □ #125 │ ■ #122 │ ■ #118 │ ✓ #115 │
│ □ Story 9 │ □ #126 │ ■ #123 │ ■ #119 │ ✓ #116 │
│ □ Story 10│ □ #127 │ ■ #124 │ │ ✓ #117 │
│ □ Bug #46 │ │ │ │ │
│ □ Bug #47 │ │ WIP: 3/4 ✅ │ WIP:2/3 │ │
│ │ │ │ ✅ │ │
└───────────┴─────────┴─────────────┴─────────┴──────────────┘
PROPÓSITO DAS COLUNAS:
• Backlog: Todo trabalho ainda não pronto para iniciar
• Pronto: Refinado, priorizado, pode começar imediatamente
• Em Progresso: Sendo ativamente trabalhado
• Review: Code review e testes
• Done: Completado e deployado
Board Avançado com Sub-Colunas
BOARD AVANÇADO COM SUB-COLUNAS:
┌─────────────────────────────────────────────────────────────┐
│ BACKLOG │PRONTO │ EM PROGRESSO │ REVIEW │ DONE │
│ │ │ FAZENDO│ FEITO │ FAZENDO│ FEITO│ │
├─────────┼───────┼────────┼───────┼────────┼──────┼─────────┤
│ │ │ │ │ │ │ │
│ □ #130 │ □ #128│ ■ #122 │ ◆ #120│ ■ #118 │◆ #115│ ✓ #110 │
│ □ #131 │ □ #129│ ■ #123 │ │ ■ #119 │ │ ✓ #111 │
│ □ #132 │ │ │ │ │ │ ✓ #112 │
│ │ │ │ │ │ │ │
└─────────┴───────┴────────┴───────┴────────┴──────┴─────────┘
LEGENDA:
□ Não iniciado ■ Em progresso ◆ Feito (aguardando pull) ✓ Completo
POR QUE SUB-COLUNAS:
Sub-colunas "Feito" mostram trabalho aguardando próxima etapa.
Revela atrasos de handoff entre estágios do workflow.
Board Integrado com QA
BOARD DESENVOLVIMENTO + QA:
┌─────────────────────────────────────────────────────────────┐
│BACKLOG│PRONTO│DEV │CODE │TESTES │STAGING │DONE │
│ │ │ │REVIEW │QA │ │ │
├───────┼──────┼───────┼───────┼────────┼────────┼───────────┤
│ │ │ │ │ │ │ │
│ □ #140│□ #138│ ■ #135│ ■ #132│ ■ #128 │ ■ #125 │ ✓ #120 │
│ □ #141│□ #139│ ■ #136│ ■ #133│ ■ #129 │ │ ✓ #121 │
│ □ #142│ │ │ │ ■ #130 │ │ ✓ #122 │
│ │ │ │ │ │ │ │
│ │ (4) │ (3) │ (3) │ (4) │ (2) │ │
└───────┴──────┴───────┴───────┴────────┴────────┴───────────┘
LIMITES WIP POR COLUNA:
• Pronto: 4 (mantém trabalho fluindo sem acúmulo)
• Dev: 3 (foco em completar, não começar)
• Code Review: 3 (previne gargalo de review)
• Testes QA: 4 (permite testar em batches)
• Staging: 2 (limita trabalho não liberado)
Estratégia de Limites WIP
Definindo Limites WIP
GUIDELINES DE LIMITES WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FÓRMULA INICIAL: │
│ Limite WIP = (Membros do time para aquele estágio) × 1.5 │
│ │
│ EXEMPLO: │
│ Time: 4 desenvolvedores, 1 QA │
│ • Em Progresso WIP: 4 × 1.5 = 6 (arredondar para 6) │
│ • Code Review WIP: 4 × 0.5 = 2 (todos fazem review) │
│ • Testes QA WIP: 1 × 2 = 2 (buffer para QA) │
│ │
│ SINAIS DE AJUSTE: │
│ │
│ WIP MUITO ALTO: │
│ • Trabalho fica parado entre estágios │
│ • Context switching aumenta │
│ • Lead time crescendo │
│ → Diminua o limite │
│ │
│ WIP MUITO BAIXO: │
│ • Membros do time frequentemente ociosos │
│ • Trabalho bloqueado em itens únicos │
│ • Nenhum fluxo │
│ → Aumente o limite levemente │
└─────────────────────────────────────────────────────────────┘
Enforcement de Limites WIP
COMPORTAMENTOS DE LIMITES WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INDICADORES VISUAIS: │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ EM PROGRESSO [████░] 4/5 - OK │ │
│ │ EM PROGRESSO [█████] 5/5 - No limite │ │
│ │ EM PROGRESSO [██████] 6/5 - EXCEDIDO ⚠️ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ QUANDO LIMITE É ATINGIDO: │
│ • Visual: Coluna fica amarela/vermelha │
│ • Ação: Time deve ajudar a mover trabalho existente │
│ • Regra: Não começar novo trabalho até espaço abrir │
│ │
│ EXCEÇÕES PERMITIDAS: │
│ • Incidentes de produção (expedite lane) │
│ • Itens bloqueados (não contam contra WIP) │
│ • Aprovação do tech lead para casos especiais │
└─────────────────────────────────────────────────────────────┘
Otimização de Fluxo
MÉTRICAS DE FLUXO DO BOARD
MÉTRICAS A MONITORAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LEAD TIME: Tempo total do início ao fim │
│ Sprint 24: 5.2 dias (meta: < 5 dias) │
│ Tendência: ↗ Aumentando │
│ │
│ CYCLE TIME: Tempo em trabalho ativo │
│ Sprint 24: 2.8 dias (meta: < 3 dias) │
│ Tendência: → Estável │
│ │
│ THROUGHPUT: Itens completados por semana │
│ Sprint 24: 12 itens/semana │
│ Tendência: ↗ Melhorando │
│ │
│ WIP MÉDIO: Trabalho em progresso médio │
│ Sprint 24: 8.5 itens │
│ Tendência: → Estável │
└─────────────────────────────────────────────────────────────┘
IDENTIFICANDO GARGALOS:
┌─────────────────────────────────────────────────────────────┐
│ Se Code Review sempre cheio → Precisa mais reviewers │
│ Se QA sempre cheio → Precisa automação ou mais QA │
│ Se Pronto vazio frequente → Refinamento insuficiente │
│ Se Dev sempre cheio → Capacidade insuficiente │
└─────────────────────────────────────────────────────────────┘