Gerenciando Dependências Entre Times de Desenvolvimento

Projetos multi-time falham quando dependências não são gerenciadas corretamente. Um time espera enquanto outro termina, deadlines atrasam e a frustração cresce. GitScrum fornece rastreamento de dependências, visibilidade cross-team e ferramentas de coordenação que ajudam a identificar blockers cedo, planejar sequências de trabalho inteligentemente e manter velocidade mesmo com relacionamentos inter-time complexos.

O Problema de Dependências Cross-Team

Dependências não gerenciadas causam:

• Trabalho bloqueado — Times ociosos esperando outros times
• Gargalos ocultos — Dependências descobertas tarde demais
• Atrasos em cascata — Um atraso afeta múltiplos times
• Esforço duplicado — Times constroem soluções similares independentemente
• Pesadelos de integração — Implementações incompatíveis
• Jogo de culpa — Apontar dedos quando coisas dão errado

Gerenciamento de Dependências GitScrum

Ferramentas para coordenação cross-team:

Recursos de Dependências

Tipos de Dependências e Mapeamento

Entendendo Tipos de Dependências

Classificações de Dependências:

1. FINISH-TO-START (FS) - Mais Comum
   ──────────────────────────────────
   Time A deve TERMINAR antes que Time B possa COMEÇAR
   
   Exemplo:
   [Time API: Construir Endpoints Auth] ──FS──→ [Frontend: Implementar Login]
   
   Frontend não pode começar login até que endpoints API existam

2. START-TO-START (SS)
   ─────────────────────
   Time B pode COMEÇAR quando Time A COMEÇA
   
   Exemplo:
   [Backend: Começar Schema BD] ──SS──→ [Frontend: Começar Mockups]
   
   Ambos podem iniciar em paralelo uma vez requisitos claros

3. FINISH-TO-FINISH (FF)
   ──────────────────────
   Time B deve TERMINAR quando Time A TERMINA
   
   Exemplo:
   [Feature Dev: Completar Features] ──FF──→ [QA: Completar Testing]
   
   Testing termina quando todas features estão testadas

4. START-TO-FINISH (SF) - Raro
   ────────────────────────────
   Time B não pode TERMINAR até que Time A COMECE
   
   Exemplo:
   [Sistema Novo: Go Live] ──SF──→ [Sistema Antigo: Decomissionar]
   
   Não pode decomissionar antigo até que novo comece

Matriz de Dependências

Criando uma Matriz de Dependências:

Dependências de Time para Release Q4:
─────────────────────────────────────

          │ Platform │ API    │ Frontend │ Mobile  │ QA
──────────┼──────────┼────────┼──────────┼─────────┼────────
Platform  │    -     │ FS(2)  │ SS(1)    │ SS(1)   │ FF(0)
API       │    -     │   -    │ FS(3)    │ FS(3)   │ FS(1)
Frontend  │    -     │   -    │    -     │ SS(0)   │ FS(2)
Mobile    │    -     │   -    │    -     │    -    │ FS(2)
QA        │    -     │   -    │    -     │    -    │   -

Legenda:
├── FS(n) = Finish-to-Start, n dias de lag
├── SS(n) = Start-to-Start, n dias de lag
├── FF(n) = Finish-to-Finish, n dias de lag
└── - = Sem dependência

Leitura: Linha depende da Coluna
Exemplo: Linha API, Coluna Platform = FS(2)
         API depende de Platform terminar, 2 dias lag

Dependências Críticas (monitorar de perto):
├── Platform → API (2 dias lag)
├── API → Frontend (3 dias lag)
├── API → Mobile (3 dias lag)
└── Frontend → QA (2 dias lag)

Visibilidade Cross-Team

Dashboard Multi-Projeto

Dashboard de Dependências Cross-Team:

Resumo Status Sprint 15:
────────────────────────

Time Platform          Time API               Time Frontend
─────────────────      ──────────────         ─────────────────
[■■■■■■■■░░] 80%       [■■■■■■░░░░] 60%       [■■■■░░░░░░] 40%
                              │                      │
                              ├──────────────────────┘
                              ↓
                       Esperando API-234 ⚠️

Trabalho Bloqueado:
┌────────────────────────────────────────────────────────────┐
│ BLOCKERS (3 itens afetando 2 times)                        │
├────────────────────────────────────────────────────────────┤
│ 🔴 API-234: Auth token refresh                             │
│    └── Bloqueando: FE-156, FE-157, MOB-089                 │
│    └── Owner: @alice (Time API)                            │
│    └── Dias bloqueado: 3                                   │
│                                                            │
│ 🟡 PLAT-156: Migração banco de dados                       │
│    └── Bloqueando: API-240, API-241                        │
│    └── Owner: @bob (Time Platform)                         │
│    └── Dias bloqueado: 1                                   │
└────────────────────────────────────────────────────────────┘

Dependências Próximas (próximos 5 dias):
├── Dia 1: PLAT-160 necessário para API-245
├── Dia 2: API-238 necessário para FE-165
├── Dia 3: API-239 necessário para MOB-092
├── Dia 4: FE-168 necessário para QA-200
└── Dia 5: Specs design necessários para FE-170

Gerenciamento de Blockers

Workflow de Blockers

Ciclo de Vida do Blocker:

1. IDENTIFICAÇÃO
   ──────────────
   Desenvolvedor descobre dependência não pronta:
   ├── Marcar tarefa como "Bloqueada"
   ├── Vincular à tarefa bloqueadora
   ├── Adicionar label de blocker
   ├── Notificar time bloqueador
   └── Documentar nas notas da tarefa
   
   Auto-Ações GitScrum:
   ├── Card da tarefa fica vermelho/laranja
   ├── Blocker adicionado à view cross-team
   └── Notificação Slack para time bloqueador

2. ESCALAÇÃO (se não resolvido >24h)
   ──────────────────────────────────
   ├── Auto-escalar para líderes de time
   ├── Adicionar à agenda do standup diário
   ├── Disparar workflow de escalação
   └── Criar reunião de resolução de dependências se necessário

3. RESOLUÇÃO
   ──────────
   Time bloqueador completa trabalho:
   ├── Marcar tarefa bloqueadora como completa
   ├── GitScrum auto-notifica tarefas bloqueadas
   ├── Time bloqueado puxa tarefa do backlog
   └── Métricas rastreiam tempo de resolução

4. REVISÃO
   ────────
   Revisão semanal de dependências:
   ├── Analisar blockers resolvidos
   ├── Identificar padrões
   ├── Melhorar processos
   └── Atualizar mapas de dependências

Dashboard de Métricas de Blockers:
──────────────────────────────────

Este Sprint:
├── Total Blockers Criados: 12
├── Blockers Resolvidos: 9
├── Tempo Médio Resolução: 1.8 dias
├── Tarefas Atualmente Bloqueadas: 3
└── Times Mais Afetados: Frontend (5), Mobile (4)

Padrões de Coordenação

Protocolos de Handoff

Processo de Handoff Time-para-Time:

CHECKLIST DE HANDOFF
────────────────────

Time que Provê (ex., Time API):
├── □ Trabalho completado e testado
├── □ Documentação atualizada
│   ├── Documentação API
│   ├── Exemplos de uso
│   └── Limitações conhecidas
├── □ Ambiente pronto
│   ├── Deployed em staging
│   ├── Feature flags configurados
│   └── Dados de teste disponíveis
├── □ Comunicação
│   ├── Notificar time receptor
│   ├── Agendar sync se necessário
│   └── Atualizar status da tarefa no GitScrum
└── □ Compromisso de suporte
    ├── Disponível para perguntas
    ├── Tempo de resposta rápido acordado
    └── Caminho de escalação documentado

Time que Recebe (ex., Time Frontend):
├── □ Verificar handoff completo
├── □ Testar integração
│   ├── Smoke test endpoints API
│   ├── Verificar formatos de dados
│   └── Checar tratamento de erros
├── □ Começar trabalho dependente
├── □ Fornecer feedback
│   ├── Issues encontrados
│   ├── Itens faltantes
│   └── Sugestões
└── □ Atualizar links de tarefas no GitScrum

Sincronização de Milestones

Milestones Alinhados

Planejamento de Milestones Cross-Team:

Mapa de Milestones Release Q1:
──────────────────────────────

Semana 1 (Jan 1-5)
├── Platform: Schema BD finalizado
├── Design: Todos mockups entregues
└── Dependências: Nenhuma (início paralelo)

Semana 2 (Jan 8-12)
├── API: Endpoints core prontos
├── Platform: Infraestrutura completa
└── Dependências: Platform → API

Semana 3 (Jan 15-19)
├── Frontend: Componentes UI core
├── Mobile: Telas core
└── Dependências: API → Frontend, API → Mobile

Semana 4 (Jan 22-26)
├── Frontend: Integração completa
├── Mobile: Integração completa
└── Dependências: Frontend ∥ Mobile (paralelo)

Semana 5 (Jan 29 - Feb 2)
├── QA: Testing completo
├── Todos: Correção de bugs
└── Dependências: Frontend → QA, Mobile → QA

Semana 6 (Feb 5-9)
├── Todos: Prep de release
└── Data release: Feb 9

Workflows de Comunicação

Standup Cross-Team

Formato Standup Multi-Time:

Quando: Terça/Quinta, 15 minutos
Quem: Um representante de cada time
Meta: Surfacear dependências e blockers cross-team

Formato:
────────

1. Rodada Robin (8 min)
   Cada rep responde:
   ├── "Estamos provendo [X] para [Time] até [data]"
   ├── "Estamos esperando [Y] de [Time]"
   └── "Temos [blockers/sem blockers] para reportar"

2. Deep-Dive de Blockers (5 min)
   ├── Top 2-3 blockers por impacto
   ├── Owner se compromete com data de resolução
   └── Escalação se necessária

3. Olhar para Frente (2 min)
   ├── Dependências devidas nos próximos 3 dias
   └── Aviso prévio sobre necessidades próximas

Melhores Práticas

Para Contribuidores Individuais

1. Vincular cedo — Adicionar dependências ao criar tarefas
2. Comunicar proativamente — Alertar blockers antes de ficarem críticos
3. Documentar handoffs — Fazer transições suaves
4. Participar do sync cross-team — Manter-se informado
5. Atualizar status diariamente — Manter info de dependências atual

Para Líderes de Time

1. Mapear dependências semanalmente — Manter view atual
2. Buffer para incerteza — Planejar folga nos calendários
3. Escalar cedo — Não deixar blockers apodrecerem
4. Construir relacionamentos — Confiança cross-team acelera resolução
5. Revisar padrões — Identificar issues de dependências recorrentes

Para Program Managers

1. Criar cultura de dependências — Fazer rastreamento ser normal
2. Fornecer ferramentas — Garantir que GitScrum esteja configurado corretamente
3. Executar cerimônias cross-team — Facilitar coordenação
4. Rastrear métricas — Medir saúde de dependências
5. Remover blockers sistêmicos — Endereçar issues organizacionais

Soluções Relacionadas

• Configurando visibilidade cross-projeto no GitScrum
• Gerenciando dependências de milestones
• Coordenando times de desenvolvimento frontend e backend