Escolhendo a Metodologia de Gerenciamento de Projetos Certa

Nenhuma metodologia única funciona para todas as equipes. A escolha certa depende do tamanho da equipe, tipo de projeto, necessidades do cliente e cultura. GitScrum suporta múltiplas metodologias, permitindo escolher o que funciona e adaptar conforme cresce.

Visão Geral da Metodologia

Mergulho Profundo no Scrum

Quando Usar Scrum

SCRUM SE ADEQUA QUANDO:
═══════════════════════

✓ Equipe de 3-9 membros
✓ Equipe dedicada (não fracionada)
✓ Trabalho de desenvolvimento de produto
✓ Precisa de entrega previsível
✓ Stakeholders querem demos regulares
✓ Requisitos complexos, evoluindo
✓ Equipe cross-functional
✓ Pode se comprometer com ciclos de 2-4 semanas

Estrutura Scrum

FRAMEWORK SCRUM
═══════════════

PAPÉIS:
├── Product Owner (o que construir)
├── Scrum Master (como trabalhar)
└── Equipe de Desenvolvimento (construir)

EVENTOS:
├── Planejamento de Sprint (início do sprint)
├── Standup Diário (todo dia)
├── Revisão de Sprint (fim do sprint)
└── Retrospectiva (fim do sprint)

ARTEFATOS:
├── Product Backlog (lista priorizada)
├── Sprint Backlog (compromisso do sprint)
└── Incremento (software funcionando)

CICLO DE SPRINT:
┌────────────────────────────────────┐
│ Planning → Trabalho → Revisão → Retro │
│    ↑                           ↓   │
│    └───────────────────────────┘   │
│         (Repetir a cada 2 semanas) │
└────────────────────────────────────┘

Scrum no GitScrum

CONFIGURAÇÃO SCRUM GITSCRUM
═══════════════════════════

SPRINTS:
├── Criar sprint com datas
├── Puxar itens do backlog
├── Definir meta do sprint
└── Rastrear com burndown

COLUNAS DO QUADRO:
├── A Fazer
├── Em Progresso
├── Em Revisão
└── Concluído

MÉTRICAS:
├── Rastreamento de velocidade
├── Gráfico burndown
├── Relatórios de sprint
└── Notas de retrospectiva

Mergulho Profundo no Kanban

Quando Usar Kanban

KANBAN SE ADEQUA QUANDO:
════════════════════════

✓ Trabalho chega continuamente
✓ Prioridades mudam frequentemente
✓ Foco em suporte/manutenção
✓ Membros da equipe compartilhados entre projetos
✓ Sem datas de entrega fixas
✓ Precisa reduzir WIP
✓ Visualizar fluxo de trabalho é prioridade
✓ Melhorias devem ser contínuas

Estrutura Kanban

FRAMEWORK KANBAN
════════════════

PRINCÍPIOS:
├── Visualizar trabalho
├── Limitar trabalho em progresso (WIP)
├── Gerenciar fluxo
├── Tornar políticas explícitas
├── Implementar loops de feedback
└── Melhorar colaborativamente

SEM PAPÉIS:
├── Sem papéis prescritos
├── Papéis existentes continuam
└── Adicionar papéis conforme necessário

SEM EVENTOS:
├── Sem reuniões obrigatórias
├── Adicionar cadências conforme útil
└── Focar no fluxo

EXEMPLO DE QUADRO:
┌─────────┬─────────┬─────────┬───────┐
│ Backlog │ Fazendo │ Revisão │ Feito │
│   (∞)   │  (3)    │   (2)   │  (∞)  │
├─────────┼─────────┼─────────┼───────┤
│ Tarefa A│ Tarefa D│ Tarefa G│ Tarefa H│
│ Tarefa B│ Tarefa E│         │ Tarefa I│
│ Tarefa C│ Tarefa F│         │       │
└─────────┴─────────┴─────────┴───────┘
            Limites WIP entre parênteses

Kanban no GitScrum

CONFIGURAÇÃO KANBAN GITSCRUM
════════════════════════════

QUADRO:
├── Colunas personalizadas
├── Limites WIP por coluna
├── Swimlanes opcionais
└── Fluxo contínuo

FLUXO DE TRABALHO:
├── Sistema pull (não push)
├── Item mais antigo primeiro
├── Respeitar limites
└── Melhorar gargalos

MÉTRICAS:
├── Tempo de ciclo
├── Tempo de lead
├── Throughput
├── Fluxo cumulativo
└── Envelhecimento WIP

Mergulho Profundo no Scrumban

Quando Usar Scrumban

SCRUMBAN SE ADEQUA QUANDO:
══════════════════════════

✓ Migrando de Scrum para Kanban
✓ Precisa de alguma cadência de planejamento
✓ Quer limites WIP + sprints
✓ Tipos de trabalho mistos
✓ Equipe em maturidade variada
✓ Precisa de flexibilidade dentro da estrutura

Estrutura Scrumban

FRAMEWORK SCRUMBAN
══════════════════

DO SCRUM:
├── Cadência de sprint (opcional)
├── Grooming de backlog
├── Retrospectivas
└── Planejamento de sprint (mais leve)

DO KANBAN:
├── Limites WIP
├── Sistema pull
├── Fluxo contínuo
├── Quadro visual
└── Foco em tempo de ciclo

CONFIGURAÇÃO TÍPICA:
├── Ciclos de planejamento de 2 semanas
├── Mas sem compromisso de sprint
├── Trabalho flui continuamente
├── Limites WIP aplicados
├── Retros em intervalo regular
└── Sem burndown de sprint

Guia de Decisão

Seleção de Metodologia

ÁRVORE DE DECISÃO
═════════════════

COMECE AQUI:
    │
    ▼
Você tem escopo/prazos fixos?
    │
    ├──SIM──→ Considere Waterfall
    │         ou Scrum de escopo fixo
    │
    ▼ NÃO
    │
Trabalho é contínuo ou baseado em projeto?
    │
    ├──CONTÍNUO──→ Considere Kanban
    │
    ▼ BASEADO EM PROJETO
    │
Equipe pode se comprometer com ciclos de 2 semanas?
    │
    ├──SIM──→ Considere Scrum
    │
    ▼ NÃO
    │
Precisa de alguma cadência?
    │
    ├──SIM──→ Considere Scrumban
    │
    ▼ NÃO
    │
Comece com Kanban simples

Considerações de Tamanho da Equipe

METODOLOGIA POR TAMANHO DA EQUIPE
═════════════════════════════════

SOLO:
├── Kanban simples
├── Quadro pessoal
└── Sem cerimônias necessárias

2-3 PESSOAS:
├── Kanban leve
├── Sinc semanal
└── Quadro simples

4-9 PESSOAS:
├── Scrum ou Kanban
├── Cerimônias completas (Scrum)
├── Ou focado em WIP (Kanban)
└── Maior flexibilidade

10+ PESSOAS:
├── Múltiplas equipes
├── Abordagem escalada
├── Cada equipe escolhe método
└── Camada de coordenação

Adaptando ao Longo do Tempo

Caminho de Evolução

EVOLUÇÃO TÍPICA
═══════════════

COMEÇANDO:
Kanban simples → Aprender básicos

CRESCENDO:
Kanban → Adicionar limites WIP → Adicionar cadências

ESCALANDO:
Escolher Scrum ou ficar Kanban baseado no fit

MADURECENDO:
Personalizar → Pegar o que funciona de cada

NÃO:
├── Escolher complexidade cedo demais
├── Seguir dogma cegamente
├── Mudar métodos constantemente
└── Ignorar o que está funcionando

Melhores Práticas

Para Seleção de Metodologia

1. Comece simples — Adicione complexidade conforme necessário
2. Experimente antes de se comprometer — Pilote por 2-3 meses
3. Envolva a equipe — Eles sabem o que se adequa
4. Esteja disposto a adaptar — Nenhuma metodologia é perfeita
5. Foque nos resultados — Não conformidade com cerimônia

Anti-Padrões

ERROS DE METODOLOGIA:
✗ Escolhendo baseado em buzzwords
✗ Implementando todas cerimônias no dia um
✗ Ignorando entrada da equipe
✗ Seguindo regras rigidamente
✗ Mudando metodologia mensalmente
✗ Culpando metodologia por problemas de pessoas
✗ Uma-tamanho-serve-para-todos para todas equipes

Soluções Relacionadas

• Implementando Scrum com GitScrum
• Kanban para equipes de desenvolvimento de software
• Gerenciamento de projetos ágil para desenvolvedores