6 min lectura • Guide 298 of 877
Estrategias de Colaboración Entre Equipos
Cuando las features abarcan múltiples equipos, la coordinación se vuelve crítica. Sin buenas prácticas, el trabajo entre equipos lleva a retrasos, malentendidos y problemas de integración. Esta guía cubre estrategias para colaboración multi-equipo efectiva.
Desafíos Entre Equipos
| Desafío | Impacto | Solución |
|---|---|---|
| Espera por dependencias | Retrasos | Identificación temprana |
| Diferentes prioridades | Conflicto | Planificación alineada |
| Problemas de integración | Retrabajo | Desarrollo contract-first |
| Brechas de comunicación | Malentendidos | Sync regular |
Modelos de Coordinación
MODELOS DE COORDINACIÓN ENTRE EQUIPOS
═════════════════════════════════════
MODELO 1: SCRUM DE SCRUMS
┌─────────────────────────────────────────────────────────────┐
│ │
│ Representantes de cada equipo se reúnen regularmente │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Team A │ │ Team B │ │ Team C │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ └───────────┼───────────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Scrum de │ Frecuencia: 2-3x semana │
│ │ Scrums │ Duración: 15-30 min │
│ └──────────────┘ │
│ │
│ Discuten: Dependencias, bloqueos, alineación │
│ │
└─────────────────────────────────────────────────────────────┘
MODELO 2: SYNC DE LÍDERES
┌─────────────────────────────────────────────────────────────┐
│ │
│ Tech leads y PMs se sincronizan │
│ │
│ Team A Lead ←→ Team B Lead ←→ Team C Lead │
│ │
│ Frecuencia: Semanal │
│ Foco: Roadmap, dependencias grandes, escalaciones │
│ │
└─────────────────────────────────────────────────────────────┘
MODELO 3: GUILDS/COMUNIDADES
┌─────────────────────────────────────────────────────────────┐
│ │
│ Personas con rol similar se reúnen │
│ │
│ Guild Frontend: Devs frontend de todos los equipos │
│ Guild QA: Testers de todos los equipos │
│ Guild Architecture: Tech leads │
│ │
│ Foco: Estándares, mejores prácticas, compartir learning │
│ │
└─────────────────────────────────────────────────────────────┘
Gestión de Dependencias
IDENTIFICANDO DEPENDENCIAS
══════════════════════════
EN PLANIFICACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Para cada feature grande, preguntar: │
│ │
│ ☐ ¿Qué otros equipos necesitamos? │
│ ☐ ¿Qué necesitamos de ellos? (API, componente, etc.) │
│ ☐ ¿Para cuándo lo necesitamos? │
│ ☐ ¿Tienen capacidad en su roadmap? │
│ ☐ ¿Quién es el contacto? │
│ │
└─────────────────────────────────────────────────────────────┘
TRACKING DE DEPENDENCIAS EN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TASK: [TEAM-A-123] Implementar checkout │
│ │ │
│ ├── Depende de: │
│ │ ├── [TEAM-B-456] API de pagos (🟡 En Progreso) │
│ │ └── [TEAM-C-789] Componente de dirección (✅ Done) │
│ │ │
│ └── Bloquea: │
│ └── [TEAM-D-012] Integración móvil (⏳ Esperando) │
│ │
└─────────────────────────────────────────────────────────────┘
Desarrollo Paralelo
ESTRATEGIAS PARA DESARROLLO PARALELO
════════════════════════════════════
OPCIÓN 1: CONTRACT-FIRST
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Acordar contrato de API primero │
│ 2. Documentar endpoints, payloads, errores │
│ 3. Ambos equipos desarrollan contra el contrato │
│ 4. Integrar al final │
│ │
│ BENEFICIO: Desarrollo independiente │
│ RIESGO: Contrato puede necesitar cambios │
│ │
└─────────────────────────────────────────────────────────────┘
OPCIÓN 2: MOCK APIS
┌─────────────────────────────────────────────────────────────┐
│ │
│ Team A necesita API de Team B │
│ │
│ Mientras Team B desarrolla: │
│ ├── Team A usa mock server │
│ ├── Mock responde según contrato acordado │
│ └── Team A avanza sin bloqueo │
│ │
│ Cuando API real está lista: │
│ └── Switch de mock a real + integration test │
│ │
└─────────────────────────────────────────────────────────────┘
OPCIÓN 3: FEATURE FLAGS
┌─────────────────────────────────────────────────────────────┐
│ │
│ Integrar código incompleto pero deshabilitado │
│ │
│ 1. Team A integra con flag apagado │
│ 2. Team B completa su parte │
│ 3. Habilitar flag cuando todo listo │
│ 4. Rollback fácil si hay problemas │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicación Entre Equipos
CANALES DE COMUNICACIÓN
═══════════════════════
PARA CADA DEPENDENCIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Contacto primario: [nombre + slack handle] │
│ Contacto backup: [nombre + slack handle] │
│ Canal Slack: #proyecto-x-integracion │
│ Doc de diseño: [link] │
│ Timeline acordado: [fechas] │
│ │
└─────────────────────────────────────────────────────────────┘
FRECUENCIA DE UPDATES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Normal: Update semanal en canal │
│ Riesgo: Update diario │
│ Bloqueado: Escalación inmediata │
│ │
└─────────────────────────────────────────────────────────────┘
TEMPLATE DE UPDATE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 📊 Status: 🟢 On Track / 🟡 At Risk / 🔴 Blocked │
│ 📅 ETA: [fecha] │
│ ✅ Completado: [qué avanzamos] │
│ 🔜 Siguiente: [próximos pasos] │
│ ⚠️ Riesgos: [si hay] │
│ │
└─────────────────────────────────────────────────────────────┘
Escalación
RUTA DE ESCALACIÓN
══════════════════
NIVEL 1: ENTRE EQUIPOS
┌─────────────────────────────────────────────────────────────┐
│ Contacto directo entre team leads │
│ Intentar resolver en 24-48h │
└─────────────────────────────────────────────────────────────┘
│ Si no se resuelve
▼
NIVEL 2: MANAGERS
┌─────────────────────────────────────────────────────────────┐
│ Engineering managers de ambos equipos │
│ Intentar resolver en 24h │
└─────────────────────────────────────────────────────────────┘
│ Si no se resuelve
▼
NIVEL 3: LIDERAZGO
┌─────────────────────────────────────────────────────────────┐
│ Director/VP de Engineering │
│ Decisión final │
└─────────────────────────────────────────────────────────────┘
CUÁNDO ESCALAR:
┌─────────────────────────────────────────────────────────────┐
│ ✅ Bloqueo > 48h sin resolución │
│ ✅ Conflicto de prioridades sin consenso │
│ ✅ Cambio de scope que afecta timeline │
│ ✅ Riesgo de no cumplir deadline de negocio │
└─────────────────────────────────────────────────────────────┘
Visibilidad en GitScrum
CONFIGURACIÓN CROSS-TEAM EN GITSCRUM
════════════════════════════════════
BOARD DE DEPENDENCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Vista consolidada de trabajo entre equipos │
│ │
│ Filtro: Label "cross-team" │
│ │
│ Columnas: │
│ Solicitado │ En Progreso │ Listo │ Integrado │
│ │
│ Swimlanes por equipo dueño │
│ │
└─────────────────────────────────────────────────────────────┘
LABELS ÚTILES:
┌─────────────────────────────────────────────────────────────┐
│ 🔗 dependency │ Es una dependencia │
│ 🚫 blocked-by-ext │ Bloqueado por otro equipo │
│ ⏳ waiting-for │ Esperando entrega externa │
│ 🤝 cross-team │ Trabajo conjunto │
└─────────────────────────────────────────────────────────────┘