10 min leitura • Guide 827 of 877
Otimização de Value Stream
O valor flui quando o desperdício é removido. O GitScrum ajuda equipes a visualizar e medir seu value stream, identificando gargalos e oportunidades de melhoria.
Fundamentos do Value Stream
Entendendo o Fluxo
CONCEITO DE VALUE STREAM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VALUE STREAM = Ideia → Produção │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ [Ideia] → [Design] → [Desenvolver] → [Testar] → [Deploy]│
│ │ ││
│ │ Cada caixa = Etapa que adiciona valor ││
│ │ Cada seta = Handoff (potencial atraso) ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DOIS TIPOS DE TEMPO: │
│ ────────────────── │
│ │
│ TEMPO DE PROCESSO: │
│ Tempo real gasto trabalhando (agrega valor) │
│ │
│ TEMPO DE ESPERA: │
│ Tempo esperando (não agrega valor) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BREAKDOWN TÍPICO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ LEAD TIME: 10 dias total ││
│ │ ││
│ │ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████ ││
│ │ ◄─────────── Tempo espera: 9 dias ───────────►◄Trab► ││
│ │ 1 dia ││
│ │ ││
│ │ EFICIÊNCIA DO PROCESSO: 1/10 = 10% ││
│ │ ││
│ │ 90% do tempo = Desperdício (esperando) ││
│ │ 10% do tempo = Realmente trabalhando ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJETIVO: Aumentar eficiência reduzindo tempo de espera │
└─────────────────────────────────────────────────────────────┘
Mapeamento de Value Stream
Criando o Mapa
MAPA DE VALUE STREAM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXEMPLO: Value Stream de Desenvolvimento de Feature │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ││
│ │ │REFINAR │ │ SPRINT │ │DESENVOL│ │ CODE │ ││
│ │ │ │──►│ PLAN │──►│ │──►│ REVIEW │ ││
│ │ └────────┘ └────────┘ └────────┘ └────────┘ ││
│ │ TP: 1h TP: 30m TP: 16h TP: 1h ││
│ │ TE: 5d TE: 0 TE: 0 TE: 1d ││
│ │ ││
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ││
│ │ │ TESTE │ │ UAT │ │ DEPLOY │ ││
│ │ │ QA │──►│ │──►│ │ ││
│ │ └────────┘ └────────┘ └────────┘ ││
│ │ TP: 2h TP: 30m TP: 15m ││
│ │ TE: 1d TE: 3d TE: 2d ││
│ │ ││
│ │ TP = Tempo de Processo (trabalhando) ││
│ │ TE = Tempo de Espera (em fila, bloqueado) ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TOTAIS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TEMPO TOTAL DE PROCESSO: ~21 horas (2.6 dias) ││
│ │ TEMPO TOTAL DE ESPERA: ~12 dias ││
│ │ LEAD TIME TOTAL: ~14.6 dias ││
│ │ ││
│ │ EFICIÊNCIA DO PROCESSO: 2.6 / 14.6 = 18% ││
│ │ ││
│ │ 82% do tempo, trabalho está esperando, não sendo feito!││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MAIORES TEMPOS DE ESPERA: Refinamento (5d), UAT (3d) │
│ → Esses são os gargalos a endereçar │
└─────────────────────────────────────────────────────────────┘
Identificando Desperdício
Tipos de Desperdício
SETE DESPERDÍCIOS EM SOFTWARE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. ESPERA: │
│ ├── Aguardando aprovação │
│ ├── Aguardando review │
│ ├── Aguardando deploy │
│ ├── Aguardando especificação │
│ └── Qualquer tempo em fila │
│ │
│ 2. TRANSPORTE (HANDOFFS): │
│ ├── Passar trabalho entre equipes │
│ ├── Muitos níveis de aprovação │
│ ├── Contexto perdido em transferências │
│ └── Comunicação entre silos │
│ │
│ 3. MOVIMENTAÇÃO (TROCA DE CONTEXTO): │
│ ├── Alternar entre projetos │
│ ├── Interrupções frequentes │
│ ├── Ferramentas fragmentadas │
│ └── Reuniões espalhadas │
│ │
│ 4. INVENTÁRIO (WORK IN PROGRESS): │
│ ├── Código não mergeado │
│ ├── Features não lançadas │
│ ├── Branches long-lived │
│ └── Backlog muito grande │
│ │
│ 5. SUPERPRODUÇÃO: │
│ ├── Features que ninguém usa │
│ ├── Código "just in case" │
│ ├── Documentação excessiva │
│ └── Gold plating (polir demais) │
│ │
│ 6. SUPERPROCESSAMENTO: │
│ ├── Reuniões desnecessárias │
│ ├── Aprovações redundantes │
│ ├── Testes duplicados │
│ └── Processos burocráticos │
│ │
│ 7. DEFEITOS (RETRABALHO): │
│ ├── Bugs encontrados tarde │
│ ├── Requisitos mal entendidos │
│ ├── Refatoração forçada │
│ └── Rollbacks de produção │
│ │
└─────────────────────────────────────────────────────────────┘
Quantificando Desperdício
MEDINDO DESPERDÍCIO
═══════════════════
CÁLCULO POR TIPO:
─────────────────────────────────────
Para cada etapa do value stream:
├── Tempo de espera = Desperdício
├── Retrabalho = Desperdício
├── Handoffs desnecessários = Desperdício
└── Some todos
EXEMPLO DE ANÁLISE:
─────────────────────────────────────
Feature típica: 14.6 dias lead time
Breakdown do desperdício:
├── Espera em refinamento: 5 dias
├── Espera em code review: 1 dia
├── Espera em QA: 1 dia
├── Espera em UAT: 3 dias
├── Espera em deploy: 2 dias
├── Retrabalho (média): 0.5 dias
└── TOTAL DESPERDÍCIO: 12.5 dias
Trabalho real: 2.1 dias
Desperdício: 12.5 dias (86%!)
PRIORIZAÇÃO:
─────────────────────────────────────
Maior desperdício → Maior oportunidade
Top 3 para endereçar:
1. Espera em refinamento (5d) → 34%
2. Espera em UAT (3d) → 24%
3. Espera em deploy (2d) → 16%
Focando nesses 3 = 74% do desperdício
Estratégias de Otimização
Reduzindo Tempo de Espera
TÁTICAS PARA CADA ETAPA
═══════════════════════
REFINAMENTO:
─────────────────────────────────────
Problema: 5 dias de espera
Causas:
├── Refinamento semanal em lote
├── Dependência de stakeholders
└── Backlog muito grande
Soluções:
├── Refinamento contínuo (não em lote)
├── Representante de negócio disponível
├── Limitar tamanho do backlog
├── Just-in-time refinement
└── Alvo: <2 dias de espera
CODE REVIEW:
─────────────────────────────────────
Problema: 1 dia de espera
Causas:
├── Reviewers sobrecarregados
├── PRs muito grandes
└── Timezone differences
Soluções:
├── PRs pequenos (<200 linhas)
├── Pair programming (review built-in)
├── SLA de review (4h resposta)
├── Rotação de review
└── Alvo: <4 horas de espera
QA:
─────────────────────────────────────
Problema: 1 dia de espera
Causas:
├── Teste manual
├── Ambiente compartilhado
└── QA como fase separada
Soluções:
├── Testes automatizados
├── Ambiente por PR
├── QA integrado na squad
├── Shift-left testing
└── Alvo: <2 horas de espera
UAT:
─────────────────────────────────────
Problema: 3 dias de espera
Causas:
├── Usuário não disponível
├── Agendar sessões difícil
└── Acumular para UAT em lote
Soluções:
├── Product owner faz UAT
├── Feature flags (UAT em prod)
├── UAT contínuo
├── Self-service demo environments
└── Alvo: <1 dia de espera
DEPLOY:
─────────────────────────────────────
Problema: 2 dias de espera
Causas:
├── Janela de deploy semanal
├── Aprovações manuais
└── Medo de breaking changes
Soluções:
├── CI/CD automatizado
├── Deploy contínuo
├── Feature flags
├── Rollback automatizado
└── Alvo: Deploy on merge
Eliminando Handoffs
REDUZINDO TRANSFERÊNCIAS
════════════════════════
MODELO TRADICIONAL (MUITOS HANDOFFS):
─────────────────────────────────────
[PO] → [Analyst] → [Dev] → [QA] → [Ops]
└──────┴─────────┴──────┴──────┘
Handoffs = Perda de contexto
Cada handoff:
├── Informação perdida
├── Tempo de espera
├── Reinterpretação
└── Oportunidade de erro
MODELO OTIMIZADO (CROSS-FUNCTIONAL):
─────────────────────────────────────
┌────────────────────────┐
│ Squad Autônoma │
│ ┌──────────────────┐ │
│ │ PO + Dev + QA │ │
│ │ + Designer + Ops │ │
│ └──────────────────┘ │
│ Colaboração contínua │
└────────────────────────┘
Benefícios:
├── Contexto compartilhado
├── Decisões imediatas
├── Ownership end-to-end
├── Feedback loop rápido
└── Menos espera
IMPLEMENTANDO:
─────────────────────────────────────
1. Formar squads cross-funcionais
2. PO dedicado por squad
3. QA embedded (não separado)
4. DevOps capability na squad
5. Autonomia para deploy
Implementação no GitScrum
Visualizando Value Stream
CONFIGURAÇÃO NO GITSCRUM
════════════════════════
COLUNAS COMO ETAPAS:
─────────────────────────────────────
Configurar board representando value stream:
Backlog → Refinando → Pronto → Em Dev →
Code Review → Em QA → UAT → Done → Prod
Cada coluna = Etapa do processo
Movimento = Fluxo visível
MEDINDO TEMPO POR ETAPA:
─────────────────────────────────────
GitScrum rastreia automaticamente:
├── Data de entrada em cada coluna
├── Data de saída de cada coluna
├── Tempo total na coluna
└── Histórico de movimentação
RELATÓRIO DE CYCLE TIME:
─────────────────────────────────────
Dashboard mostra:
├── Tempo médio por etapa
├── Etapas com maior tempo
├── Tendências ao longo do tempo
├── Comparação por tipo de item
└── Identificação de gargalos
Métricas de Fluxo
MÉTRICAS CHAVE NO GITSCRUM
══════════════════════════
LEAD TIME:
─────────────────────────────────────
Criação → Produção (tempo total)
├── Inclui todo tempo de espera
├── Perspectiva do cliente
├── Alvo: Reduzir continuamente
└── GitScrum: Card age + transitions
CYCLE TIME:
─────────────────────────────────────
Início do trabalho → Produção
├── Tempo "em progresso"
├── Perspectiva do time
├── Controle mais direto
└── GitScrum: First "In Dev" → Done
THROUGHPUT:
─────────────────────────────────────
Items completados por período
├── Semanal ou por sprint
├── Indicador de capacidade
├── Tendência mais que valor absoluto
└── GitScrum: Cards done/week
WIP (WORK IN PROGRESS):
─────────────────────────────────────
Items em andamento agora
├── Limitadores habilitados
├── Correlação com lead time
├── Menor WIP = Menor lead time
└── GitScrum: Column WIP limits
FLOW EFFICIENCY:
─────────────────────────────────────
Tempo ativo / Lead time × 100
├── Quanto é trabalho vs espera
├── Benchmark: 15-40%
├── World-class: >40%
└── Calcular: Sum(active) / Lead time
Melhoria Contínua
Kaizen Events
WORKSHOPS DE OTIMIZAÇÃO
═══════════════════════
PREPARAÇÃO:
─────────────────────────────────────
1. Coletar dados do GitScrum
├── Lead time últimos 3 meses
├── Cycle time por etapa
├── Items bloqueados
└── Padrões de retrabalho
2. Criar mapa atual
├── Todas as etapas
├── Tempos médios
├── Pessoas envolvidas
└── Problemas conhecidos
WORKSHOP (2-4 horas):
─────────────────────────────────────
Participantes: Todo o squad + stakeholders
Agenda:
├── 30 min: Revisar dados e mapa atual
├── 45 min: Identificar desperdícios
├── 45 min: Brainstorm soluções
├── 30 min: Priorizar ações
├── 30 min: Planejar implementação
└── Buffer para discussão
SAÍDAS:
─────────────────────────────────────
├── Mapa de estado futuro (alvo)
├── Top 3 melhorias a implementar
├── Responsáveis e datas
├── Métricas para medir sucesso
└── Data do próximo review
Ciclo PDCA
PLAN-DO-CHECK-ACT
═════════════════
PLAN:
─────────────────────────────────────
Identificar oportunidade:
├── Maior tempo de espera: UAT (3d)
├── Hipótese: PO pode fazer UAT
├── Métrica: Tempo UAT < 1 dia
└── Timeline: 1 sprint
DO:
─────────────────────────────────────
Implementar mudança:
├── PO treinado em UAT
├── Critérios claros definidos
├── Processo documentado
├── Piloto com próximas 5 features
└── Coletar dados
CHECK:
─────────────────────────────────────
Medir resultados:
├── Tempo UAT: 3d → 0.5d ✓
├── Qualidade mantida? ✓
├── PO sobrecarregado? Não
├── Feedback do time? Positivo
└── Conclusão: Sucesso!
ACT:
─────────────────────────────────────
Padronizar ou ajustar:
├── Sucesso → Padronizar processo
├── Documentar novo processo
├── Treinar outros POs
├── Próximo ciclo: Atacar deploy time
└── Repetir PDCA continuamente