8 min leitura • Guide 671 of 877
Implementando Kanban para Equipes de Desenvolvimento
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 │
└─────────────────────────────────────────────────────────────┘