Gestionando Dependencias Entre Equipos de Desarrollo

Los proyectos multi-equipo fallan cuando las dependencias no se gestionan correctamente. Un equipo espera mientras otro termina, deadlines se retrasan y la frustración crece. GitScrum proporciona seguimiento de dependencias, visibilidad cross-team y herramientas de coordinación que ayudan a identificar blockers temprano, planificar secuencias de trabajo inteligentemente y mantener velocidad incluso con relaciones inter-equipo complejas.

El Problema de Dependencias Cross-Team

Dependencias no gestionadas causan:

• Trabajo bloqueado — Equipos ociosos esperando a otros equipos
• Cuellos de botella ocultos — Dependencias descubiertas muy tarde
• Retrasos en cascada — Un retraso afecta múltiples equipos
• Esfuerzo duplicado — Equipos construyen soluciones similares independientemente
• Pesadillas de integración — Implementaciones incompatibles
• Juegos de culpa — Señalar con el dedo cuando las cosas van mal

Gestión de Dependencias GitScrum

Herramientas para coordinación cross-team:

Características de Dependencias

Tipos de Dependencias y Mapeo

Entendiendo Tipos de Dependencias

Clasificaciones de Dependencias:

1. FINISH-TO-START (FS) - Más Común
   ─────────────────────────────────
   Equipo A debe TERMINAR antes que Equipo B pueda EMPEZAR
   
   Ejemplo:
   [Equipo API: Construir Endpoints Auth] ──FS──→ [Frontend: Implementar Login]
   
   Frontend no puede empezar login hasta que endpoints API existan

2. START-TO-START (SS)
   ─────────────────────
   Equipo B puede EMPEZAR cuando Equipo A EMPIEZA
   
   Ejemplo:
   [Backend: Empezar Schema BD] ──SS──→ [Frontend: Empezar Mockups]
   
   Ambos pueden comenzar en paralelo una vez requisitos claros

3. FINISH-TO-FINISH (FF)
   ──────────────────────
   Equipo B debe TERMINAR cuando Equipo A TERMINA
   
   Ejemplo:
   [Feature Dev: Completar Features] ──FF──→ [QA: Completar Testing]
   
   Testing termina cuando todas las features están probadas

4. START-TO-FINISH (SF) - Raro
   ────────────────────────────
   Equipo B no puede TERMINAR hasta que Equipo A EMPIECE
   
   Ejemplo:
   [Sistema Nuevo: Go Live] ──SF──→ [Sistema Viejo: Decomisionar]
   
   No se puede decomisionar viejo hasta que nuevo empiece

Matriz de Dependencias

Creando una Matriz de Dependencias:

Dependencias de Equipo 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        │    -     │   -    │    -     │    -    │   -

Leyenda:
├── FS(n) = Finish-to-Start, n días de lag
├── SS(n) = Start-to-Start, n días de lag
├── FF(n) = Finish-to-Finish, n días de lag
└── - = Sin dependencia

Lectura: Fila depende de Columna
Ejemplo: Fila API, Columna Platform = FS(2)
         API depende de que Platform termine, 2 días lag

Dependencias Críticas (monitorear de cerca):
├── Platform → API (2 días lag)
├── API → Frontend (3 días lag)
├── API → Mobile (3 días lag)
└── Frontend → QA (2 días lag)

Visibilidad Cross-Team

Dashboard Multi-Proyecto

Dashboard de Dependencias Cross-Team:

Resumen Estado Sprint 15:
─────────────────────────

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

Trabajo Bloqueado:
┌────────────────────────────────────────────────────────────┐
│ BLOCKERS (3 items afectando 2 equipos)                     │
├────────────────────────────────────────────────────────────┤
│ 🔴 API-234: Auth token refresh                             │
│    └── Bloqueando: FE-156, FE-157, MOB-089                 │
│    └── Owner: @alice (Equipo API)                          │
│    └── Días bloqueado: 3                                   │
│                                                            │
│ 🟡 PLAT-156: Migración base de datos                       │
│    └── Bloqueando: API-240, API-241                        │
│    └── Owner: @bob (Equipo Platform)                       │
│    └── Días bloqueado: 1                                   │
└────────────────────────────────────────────────────────────┘

Dependencias Próximas (siguientes 5 días):
├── Día 1: PLAT-160 necesitado por API-245
├── Día 2: API-238 necesitado por FE-165
├── Día 3: API-239 necesitado por MOB-092
├── Día 4: FE-168 necesitado por QA-200
└── Día 5: Specs diseño necesitados por FE-170

Gestión de Blockers

Workflow de Blockers

Ciclo de Vida del Blocker:

1. IDENTIFICACIÓN
   ───────────────
   Desarrollador descubre dependencia no lista:
   ├── Marcar tarea como "Bloqueada"
   ├── Vincular a tarea bloqueadora
   ├── Agregar label de blocker
   ├── Notificar equipo bloqueador
   └── Documentar en notas de tarea
   
   Auto-Acciones GitScrum:
   ├── Tarjeta de tarea se vuelve roja/naranja
   ├── Blocker agregado a vista cross-team
   └── Notificación Slack a equipo bloqueador

2. ESCALACIÓN (si no resuelto >24h)
   ─────────────────────────────────
   ├── Auto-escalar a líderes de equipo
   ├── Agregar a agenda de standup diario
   ├── Disparar workflow de escalación
   └── Crear reunión de resolución de dependencias si necesario

3. RESOLUCIÓN
   ───────────
   Equipo bloqueador completa trabajo:
   ├── Marcar tarea bloqueadora como completa
   ├── GitScrum auto-notifica tareas bloqueadas
   ├── Equipo bloqueado toma tarea del backlog
   └── Métricas rastrean tiempo de resolución

4. REVISIÓN
   ─────────
   Revisión semanal de dependencias:
   ├── Analizar blockers resueltos
   ├── Identificar patrones
   ├── Mejorar procesos
   └── Actualizar mapas de dependencias

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

Este Sprint:
├── Total Blockers Creados: 12
├── Blockers Resueltos: 9
├── Tiempo Promedio Resolución: 1.8 días
├── Tareas Actualmente Bloqueadas: 3
└── Equipos Más Afectados: Frontend (5), Mobile (4)

Patrones de Coordinación

Protocolos de Handoff

Proceso de Handoff Equipo-a-Equipo:

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

Equipo que Provee (ej., Equipo API):
├── □ Trabajo completado y probado
├── □ Documentación actualizada
│   ├── Documentación API
│   ├── Ejemplos de uso
│   └── Limitaciones conocidas
├── □ Ambiente listo
│   ├── Desplegado en staging
│   ├── Feature flags configurados
│   └── Datos de prueba disponibles
├── □ Comunicación
│   ├── Notificar equipo receptor
│   ├── Programar sync si necesario
│   └── Actualizar estado de tarea en GitScrum
└── □ Compromiso de soporte
    ├── Disponible para preguntas
    ├── Tiempo de respuesta rápido acordado
    └── Ruta de escalación documentada

Equipo que Recibe (ej., Equipo Frontend):
├── □ Verificar handoff completo
├── □ Probar integración
│   ├── Smoke test endpoints API
│   ├── Verificar formatos de datos
│   └── Revisar manejo de errores
├── □ Comenzar trabajo dependiente
├── □ Proporcionar feedback
│   ├── Issues encontrados
│   ├── Items faltantes
│   └── Sugerencias
└── □ Actualizar vínculos de tareas en GitScrum

Sincronización de Milestones

Milestones Alineados

Planificación de Milestones Cross-Team:

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

Semana 1 (Ene 1-5)
├── Platform: Schema BD finalizado
├── Diseño: Todos mockups entregados
└── Dependencias: Ninguna (inicio paralelo)

Semana 2 (Ene 8-12)
├── API: Endpoints core listos
├── Platform: Infraestructura completa
└── Dependencias: Platform → API

Semana 3 (Ene 15-19)
├── Frontend: Componentes UI core
├── Mobile: Pantallas core
└── Dependencias: API → Frontend, API → Mobile

Semana 4 (Ene 22-26)
├── Frontend: Integración completa
├── Mobile: Integración completa
└── Dependencias: Frontend ∥ Mobile (paralelo)

Semana 5 (Ene 29 - Feb 2)
├── QA: Testing completo
├── Todos: Corrección de bugs
└── Dependencias: Frontend → QA, Mobile → QA

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

Workflows de Comunicación

Standup Cross-Team

Formato Standup Multi-Equipo:

Cuándo: Martes/Jueves, 15 minutos
Quién: Un representante de cada equipo
Meta: Surfacear dependencias y blockers cross-team

Formato:
────────

1. Ronda Robin (8 min)
   Cada rep responde:
   ├── "Estamos proveyendo [X] a [Equipo] para [fecha]"
   ├── "Estamos esperando [Y] de [Equipo]"
   └── "Tenemos [blockers/no blockers] que reportar"

2. Deep-Dive de Blockers (5 min)
   ├── Top 2-3 blockers por impacto
   ├── Owner se compromete a fecha de resolución
   └── Escalación si necesaria

3. Mirada al Futuro (2 min)
   ├── Dependencias debidas en próximos 3 días
   └── Aviso previo sobre necesidades próximas

Mejores Prácticas

Para Contribuidores Individuales

1. Vincular temprano — Agregar dependencias al crear tareas
2. Comunicar proactivamente — Alertar blockers antes de que sean críticos
3. Documentar handoffs — Hacer transiciones suaves
4. Asistir a sync cross-team — Mantenerse informado
5. Actualizar estado diariamente — Mantener info de dependencias actual

Para Líderes de Equipo

1. Mapear dependencias semanalmente — Mantener vista actual
2. Buffer para incertidumbre — Planificar holgura en calendarios
3. Escalar temprano — No dejar que blockers se enconicen
4. Construir relaciones — Confianza cross-team acelera resolución
5. Revisar patrones — Identificar issues de dependencias recurrentes

Para Program Managers

1. Crear cultura de dependencias — Hacer seguimiento normal
2. Proporcionar herramientas — Asegurar que GitScrum esté configurado correctamente
3. Ejecutar ceremonias cross-team — Facilitar coordinación
4. Rastrear métricas — Medir salud de dependencias
5. Remover blockers sistémicos — Abordar issues organizacionales

Soluciones Relacionadas

• Configurando visibilidad cross-proyecto en GitScrum
• Gestionando dependencias de milestones
• Coordinando equipos de desarrollo frontend y backend