6 min leitura • Guide 810 of 877
Metodologias Ágeis Híbridas
Nenhuma metodologia única serve para todos. O GitScrum suporta abordagens híbridas, permitindo que times combinem práticas de Scrum, Kanban e outros frameworks.
Entendendo Abordagens Híbridas
Por Que Híbrido
RAZÕES PARA METODOLOGIAS HÍBRIDAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCRUM PURO: │
│ ─────────── │
│ ✅ Bom para: Desenvolvimento de features, trabalho previsível│
│ ❌ Desafios: Trabalho de suporte, interrupções frequentes │
│ │
│ KANBAN PURO: │
│ ──────────── │
│ ✅ Bom para: Suporte, manutenção, fluxo contínuo │
│ ❌ Desafios: Planejamento de capacidade, compromissos sprint│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HÍBRIDO QUANDO: │
│ ────────────── │
│ │
│ TIPOS DE TRABALHO MISTOS: │
│ Features (planejadas) + Suporte (não planejado) │
│ Precisa estrutura E flexibilidade │
│ │
│ RESTRIÇÕES ORGANIZACIONAIS: │
│ Empresa usa sprints para planejamento │
│ Mas time precisa fluxo Kanban para execução │
│ │
│ TRANSITANDO: │
│ Movendo de waterfall para ágil │
│ Adoção gradual de práticas │
│ │
│ PREFERÊNCIA DO TIME: │
│ Time experimentou e encontrou o que funciona │
│ Mix de práticas entrega melhores resultados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ O OBJETIVO: │
│ ────────── │
│ Usar práticas que ajudam SEU time a entregar valor │
│ Não seguir um framework pelo bem do framework │
└─────────────────────────────────────────────────────────────┘
Scrumban
Combinando Scrum e Kanban
VISÃO GERAL DO SCRUMBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DO SCRUM: DO KANBAN: │
│ ───────── ────────── │
│ • Sprints (opcional) • Board visual │
│ • Sprint planning • Limites WIP │
│ • Retrospectivas • Sistema pull │
│ • Daily standup • Métricas de fluxo │
│ • Backlog • Melhoria contínua │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOARD SCRUMBAN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BACKLOG │PRONTO │ DEV (3) │REVIEW(2)│ QA (2) │ DONE ││
│ │ │ │ │ │ │ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │A │ │ │D │ │ │G │ │ │J │ │ │L │ │ │N │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │B │ │ │E │ │ │H │ │ │K │ │ │M │ │ │O │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ │ │ ││
│ │ │C │ │ │F │ │ │I │ │ │ │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ │ │ ││
│ │ │ │ LIMITE │ LIMITE │ LIMITE │ ││
│ │ │ │ WIP │ WIP │ WIP │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRÁTICAS CHAVE: │
│ ────────────── │
│ • Sprint planning para priorização │
│ • Board Kanban com limites WIP para execução │
│ • Puxar trabalho quando capacidade disponível │
│ • Métricas de fluxo para melhoria │
│ • Retros no fim da sprint │
└─────────────────────────────────────────────────────────────┘
Quando Usar Scrumban
CASOS DE USO DO SCRUMBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMES DE MANUTENÇÃO: │
│ ──────────────────── │
│ Mix de melhorias planejadas e correções reativas │
│ Sprint planning + fluxo contínuo │
│ │
│ SUPORTE + DESENVOLVIMENTO: │
│ ────────────────────────── │
│ Trabalho dedicado de features com interrupções de suporte │
│ Reserva de capacidade para trabalho não planejado │
│ │
│ TRANSITANDO DO SCRUM: │
│ ────────────────────── │
│ Manter estrutura familiar enquanto adiciona fluxo │
│ Gradualmente reduzir cerimônias se não agregam valor │
│ │
│ TIMES OPERACIONAIS: │
│ ─────────────────── │
│ DevOps, SRE, Platform │
│ Mistura de projetos e trabalho operacional │
└─────────────────────────────────────────────────────────────┘
Customizando Seu Framework
PROCESSO DE CUSTOMIZAÇÃO
PASSO 1: COMECE COM BASE
┌─────────────────────────────────────────────────────────────┐
│ Escolha Scrum ou Kanban como ponto de partida │
│ Pratique por 3-4 sprints sem mudanças │
│ Entenda a intenção por trás de cada prática │
└─────────────────────────────────────────────────────────────┘
PASSO 2: IDENTIFIQUE FRICÇÕES
┌─────────────────────────────────────────────────────────────┐
│ Use retrospectivas para encontrar o que não funciona │
│ Documente problemas específicos, não reclamações genéricas │
│ Pergunte "Por que isso não funciona para nós?" │
└─────────────────────────────────────────────────────────────┘
PASSO 3: EXPERIMENTE MUDANÇAS
┌─────────────────────────────────────────────────────────────┐
│ Uma mudança por vez │
│ Período de experimentação definido (4-6 semanas) │
│ Métricas claras de sucesso │
└─────────────────────────────────────────────────────────────┘
PASSO 4: AVALIE E ITERE
┌─────────────────────────────────────────────────────────────┐
│ A mudança melhorou o problema? │
│ Criou novos problemas? │
│ Manter, ajustar ou reverter? │
└─────────────────────────────────────────────────────────────┘
PASSO 5: DOCUMENTE
┌─────────────────────────────────────────────────────────────┐
│ Registre suas práticas customizadas │
│ Explique por que cada customização existe │
│ Revise periodicamente │
└─────────────────────────────────────────────────────────────┘
Métricas para Híbrido
MÉTRICAS DE SAÚDE DO PROCESSO
MÉTRICAS DE FLUXO (DO KANBAN):
┌─────────────────────────────────────────────────────────────┐
│ Lead Time: 5.2 dias (tempo total) │
│ Cycle Time: 2.8 dias (tempo ativo) │
│ Throughput: 12 itens/semana │
│ WIP médio: 8 itens │
└─────────────────────────────────────────────────────────────┘
MÉTRICAS DE SPRINT (DO SCRUM):
┌─────────────────────────────────────────────────────────────┐
│ Velocidade: 34 pontos/sprint │
│ Previsibilidade: 85% │
│ Compromisso cumprido: 90% │
└─────────────────────────────────────────────────────────────┘
MÉTRICAS DE QUALIDADE:
┌─────────────────────────────────────────────────────────────┐
│ Bugs em produção: 2/sprint │
│ Bugs escapados: 5% │
│ Tech debt ratio: 15% │
└─────────────────────────────────────────────────────────────┘