Implementando Kanban para Equipes de Desenvolvimento
Transforme o fluxo de trabalho da sua equipe com princípios Kanban. Visualize o trabalho, limite o trabalho em progresso e otimize o fluxo para entrega contínua.
8 min de leitura
Kanban fornece uma estrutura flexível para gerenciar trabalho de desenvolvimento com sobrecarga mínima de processo. Os quadros Kanban do GitScrum ajudam equipes a visualizar seu fluxo de trabalho, identificar gargalos e melhorar continuamente seu processo através da otimização de fluxo.
Fundamentos do Kanban
Princípios Fundamentais
PRINCÍPIOS DO KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. VISUALIZAR TRABALHO │
│ Torne todo trabalho visível no quadro │
│ Inclua tipo de trabalho, status, bloqueadores │
│ │
│ 2. LIMITAR TRABALHO EM PROGRESSO (WIP) │
│ Foque em finalizar, não em iniciar │
│ Limites WIP criam fluxo │
│ │
│ 3. GERENCIAR FLUXO │
│ Otimize para entrega suave e previsível │
│ Meça e melhore tempo de ciclo │
│ │
│ 4. TORNAR POLÍTICAS EXPLÍCITAS │
│ Documente como trabalho se move através de colunas │
│ Defina "pronto" e "feito" para cada estágio │
│ │
│ 5. IMPLEMENTAR LOOPS DE FEEDBACK │
│ Revisões regulares de trabalho e processo │
│ Adapte baseado em métricas e experiência │
│ │
│ 6. MELHORAR COLABORATIVAMENTE │
│ Equipe possui o processo │
│ Mudança contínua e evolucionária │
└─────────────────────────────────────────────────────────────┘
Kanban vs Scrum
CARACTERÍSTICAS DO KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ KANBAN: SCRUM: │
│ • Fluxo contínuo • Sprints com tempo definido │
│ • Limites WIP • Compromisso de sprint │
│ • Baseado em pull • Push no planejamento │
│ • Mudança a qualquer momento • Mudança no limite do sprint│
│ • Papéis opcionais • Papéis definidos │
│ • Métricas: tempo de ciclo • Métricas: velocidade │
│ │
│ ESCOLHA KANBAN QUANDO: │
│ • Trabalho é imprevisível (suporte, ops) │
│ • Implantação contínua necessária │
│ • Equipe lida com tipos variados de trabalho │
│ • Mudanças frequentes de prioridade │
│ • Sobrecarga mínima de processo preferida │
│ │
│ ESCOLHA SCRUM QUANDO: │
│ • Trabalho é planejável │
│ • Equipe precisa de estrutura │
│ • Stakeholders querem compromissos previsíveis │
│ • Construindo features complexas iterativamente │
└─────────────────────────────────────────────────────────────┘
Etapas de Implementação
Etapa 1: Mapear Seu Fluxo de Trabalho
MAPEAMENTO DE FLUXO DE TRABALHO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DESCOBRA SEU PROCESSO REAL: │
│ │
│ Pergunte: "Quais estados o trabalho atravessa?" │
│ │
│ Exemplo de descoberta: │
│ 1. Alguém solicita trabalho │
│ 2. Produto revisa e prioriza │
│ 3. Trabalho espera disponibilidade │
│ 4. Desenvolvedor pega │
│ 5. Desenvolvedor completa codificação │
│ 6. Trabalho vai para revisão de código │
│ 7. Comentários de revisão endereçados │
│ 8. QA testa o trabalho │
│ 9. Trabalho implantado em staging │
│ 10. Trabalho liberado para produção │
│ │
│ MAPEAR PARA COLUNAS: │
│ Backlog → Pronto → Em Progresso → Revisão → QA → Feito │
│ │
│ DICAS: Comece simples, adicione colunas conforme necessário│
└─────────────────────────────────────────────────────────────┘
Etapa 2: Definir Limites WIP Iniciais
LIMITES WIP INICIAIS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAMANHO DA EQUIPE: 5 desenvolvedores + 1 QA │
│ │
│ COLUNA │ WIP INICIAL │ RAZÃO │
│─────────────────┼─────────────┼────────────────────────────│
│ Backlog │ Nenhum │ Fila priorizada │
│ Pronto │ 8 │ Buffer para planejamento │
│ Em Progresso │ 5 │ Máximo um por desenvolvedor│
│ Revisão Código │ 4 │ Incentiva finalizar │
│ Teste QA │ 3 │ Capacidade QA │
│ Feito │ Nenhum │ Trabalho completado │
│ │
│ WIP TOTAL DO SISTEMA: ~20 itens │
│ │
│ AJUSTE APÓS 2-4 SEMANAS: │
│ Muito fácil? Baixe limites. │
│ Constantemente bloqueado? Aumente ligeiramente. │
└─────────────────────────────────────────────────────────────┘
Etapa 3: Estabelecer Políticas
POLÍTICAS EXPLÍCITAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COLUNA: PRONTO │
│ Critérios de entrada: │
│ • História de usuário com critérios de aceitação │
│ • Design aprovado (se necessário) │
│ • Dependências identificadas │
│ Critérios de saída: │
│ • Desenvolvedor puxa quando capacidade disponível │
│ │
│ COLUNA: EM PROGRESSO │
│ Critérios de entrada: │
│ • Puxado do Pronto │
│ • Desenvolvedor atribuído │
│ Critérios de saída: │
│ • Código completo com testes │
│ • PR criado │
│ │
│ COLUNA: REVISÃO CÓDIGO │
│ Critérios de entrada: │
│ • PR criado com descrição │
│ • CI passando │
│ Critérios de saída: │
│ • Aprovado pelo revisor │
│ • Comentários endereçados │
│ │
│ PRIORIZAÇÃO: │
│ • Finalize trabalho em progresso antes de iniciar novo │
│ • Ajude a desbloquear outros antes de iniciar próprio │
│ • Bugs críticos podem contornar fila normal │
└─────────────────────────────────────────────────────────────┘
Operações Diárias
Daily Standup
STANDUP KANBAN (15 min):
┌─────────────────────────────────────────────────────────────┐
│ │
│ FOCO: Caminhe pelo quadro da direita para esquerda │
│ │
│ 1. Comece do FEITO, mova para esquerda │
│ "O que moveu para feito desde ontem?" │
│ │
│ 2. Revise itens próximos do FEITO primeiro │
│ "O que está bloqueando estes de finalizar?" │
│ │
│ 3. Verifique limites WIP │
│ "Estamos no limite ou acima de algum?" │
│ │
│ 4. Enderece bloqueadores │
│ "Quem pode ajudar a desbloquear isso?" │
│ │
│ 5. Puxe novo trabalho apenas se capacidade │
│ "Temos espaço para iniciar algo novo?" │
│ │
│ POR QUE DIREITA PARA ESQUERDA: │
│ Prioriza finalizar sobre iniciar │
│ Itens mais próximos do feito = mais investimento │
│ Revela bloqueadores em estágios posteriores │
└─────────────────────────────────────────────────────────────┘
Tratando Tipos de Trabalho
GERENCIAMENTO DE TIPOS DE TRABALHO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SWIMLANES POR TIPO DE TRABALHO: │
│ │
│ URGENTE │ ■ Bug crítico │
│ (expedite) │ │
│──────────────┼──────────────────────────────────────────────
│ FEATURES │ □ #125 ■ #123 ■ #120 │
│ │ □ #126 ■ #124 │
│──────────────┼──────────────────────────────────────────────
│ BUGS │ □ #45 ■ #43 │
│ │ │
│──────────────┼──────────────────────────────────────────────
│ TECH DEBT │ □ #TD-12 │
│ │ │
└──────────────┴──────────────────────────────────────────────┘
ALOCAÇÃO DE CAPACIDADE:
• Features: 60%
• Bugs: 20%
• Tech Debt: 20%
Rastreie cada lane separadamente, mantenha proporções
Métricas e Melhoria
Métricas de Fluxo
MÉTRICAS-CHAVE DO KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEMPO DE CICLO (métrica primária): │
│ Tempo de "Em Progresso" para "Feito" │
│ Atual médio: 3.2 dias │
│ Meta: <3 dias │
│ │
│ TEMPO DE LEAD: │
│ Tempo de "Pronto" para "Feito" │
│ Atual médio: 5.1 dias │
│ Mostra tempo total incluindo espera │
│ │
│ THROUGHPUT: │
│ Itens completados por período de tempo │
│ Atual: 14 itens/semana │
│ Tendência: Estável │
│ │
│ IDADE WIP: │
│ Há quanto tempo itens estão em progresso │
│ Alerta se item > 2x tempo médio de ciclo │
│ │
│ DIAGRAMA DE FLUXO CUMULATIVO: │
│ Mostra volume de trabalho em cada estado ao longo do tempo │
│ Bandas se alargando = gargalos │
└─────────────────────────────────────────────────────────────┘
Melhoria Contínua
CICLO DE MELHORIA DO KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEMANAL: Revisão do Quadro (15 min) │
│ • Verifique métricas │
│ • Identifique itens travados │
│ • Anote padrões │
│ │
│ BI-SEMANAL: Revisão de Processo (30 min) │
│ • Revise métricas de fluxo │
│ • Discuta gargalos │
│ • Ajuste limites WIP se necessário │
│ • Atualize políticas │
│ │
│ EXPERIMENTOS DE MELHORIA: │
│ │
│ "Hipótese: Baixar WIP de Revisão de 4 para 3 │
│ reduzirá tempo de espera de revisão." │
│ │
│ Tente por: 2 semanas │
│ Meça: Tempo de ciclo do estágio de revisão │
│ Decida: Mantenha, ajuste ou reverta │
└─────────────────────────────────────────────────────────────┘