5 min lectura • Guide 403 of 877
Prácticas de Pair Programming
Pair programming significa dos desarrolladores trabajando juntos en una computadora. Buen pairing produce mejor código, comparte conocimiento, y construye relaciones de equipo. Mal pairing es frustrante e improductivo. Esta guía cubre prácticas de pairing efectivas.
Beneficios del Pairing
| Beneficio | Impacto |
|---|---|
| Calidad de código | Menos bugs, mejor diseño |
| Knowledge sharing | Sin puntos únicos de falla |
| Onboarding | Ramp-up más rápido |
| Foco | Menos distracción |
Roles en Pairing
ROLES DE PAIRING
════════════════
DRIVER:
┌─────────────────────────────────────────────────────────────┐
│ ├── Manos en el teclado │
│ ├── Escribe el código │
│ ├── Se enfoca en implementación │
│ ├── Piensa en sintaxis │
│ ├── Problema inmediato │
│ └── Táctico │
└─────────────────────────────────────────────────────────────┘
NAVIGATOR:
┌─────────────────────────────────────────────────────────────┐
│ ├── Observa y revisa │
│ ├── Piensa en panorama mayor │
│ ├── Detecta bugs e issues │
│ ├── Considera diseño │
│ ├── Mira hacia adelante │
│ ├── Sugiere mejoras │
│ └── Estratégico │
└─────────────────────────────────────────────────────────────┘
CAMBIO DE ROLES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Cada 15-30 minutos: │
│ ├── Driver → Navigator │
│ ├── Navigator → Driver │
│ │
│ Triggers para cambiar: │
│ ├── Timer suena │
│ ├── Completar una unidad de trabajo │
│ ├── Cuando uno tiene una idea │
│ └── Si driver está atascado │
│ │
└─────────────────────────────────────────────────────────────┘
Estilos de Pairing
ESTILOS COMUNES
═══════════════
DRIVER-NAVIGATOR (Clásico):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Driver escribe, Navigator dirige │
│ Rotación regular │
│ │
│ ✅ Mejor para: Mayoría de situaciones │
│ │
└─────────────────────────────────────────────────────────────┘
PING-PONG (con TDD):
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Dev A escribe test (falla) │
│ 2. Dev B escribe código (pasa) │
│ 3. Dev B escribe siguiente test (falla) │
│ 4. Dev A escribe código (pasa) │
│ 5. Repetir │
│ │
│ ✅ Mejor para: TDD, mantener engagement │
│ │
└─────────────────────────────────────────────────────────────┘
STRONG-STYLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "Para que una idea entre a la computadora, │
│ DEBE pasar por las manos de otra persona" │
│ │
│ Navigator tiene las ideas │
│ Driver solo implementa lo que Navigator dice │
│ │
│ ✅ Mejor para: Onboarding, enseñanza │
│ │
└─────────────────────────────────────────────────────────────┘
Estructura de Sesión
SESIÓN DE PAIRING TÍPICA
════════════════════════
INICIO (5 min):
┌─────────────────────────────────────────────────────────────┐
│ ├── Acordar objetivo de la sesión │
│ ├── Revisar contexto necesario │
│ ├── Setup técnico (IDE, branches, etc.) │
│ └── Decidir quién empieza como driver │
└─────────────────────────────────────────────────────────────┘
TRABAJO (45-50 min):
┌─────────────────────────────────────────────────────────────┐
│ ├── Coding con rotación │
│ ├── Discusión continua │
│ ├── Cambio de roles cada 15-30 min │
│ └── Mini-breaks si es necesario │
└─────────────────────────────────────────────────────────────┘
CIERRE (5-10 min):
┌─────────────────────────────────────────────────────────────┐
│ ├── ¿Qué logramos? │
│ ├── ¿Qué sigue? │
│ ├── ¿Documentar decisiones? │
│ └── ¿Cómo fue la sesión? │
└─────────────────────────────────────────────────────────────┘
DESPUÉS DE ~1 HORA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Break real (10-15 min) │
│ Levantarse, caminar, descansar ojos │
│ Pairing intensivo es cansador │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicación Efectiva
COMUNICACIÓN EN PAIRING
═══════════════════════
BUENAS PRÁCTICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ "¿Qué piensas de...?" │
│ ✅ "Estoy pensando en..." │
│ ✅ "¿Puedo sugerir algo?" │
│ ✅ "No entiendo, ¿puedes explicar?" │
│ ✅ "¿Tomamos un break?" │
│ │
└─────────────────────────────────────────────────────────────┘
EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ Tomar el teclado sin permiso │
│ ❌ "No, está mal" sin explicar │
│ ❌ Dominar toda la sesión │
│ ❌ Ignorar las ideas del par │
│ ❌ Revisar email/Slack durante sesión │
│ │
└─────────────────────────────────────────────────────────────┘
CUANDO HAY DESACUERDO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Escuchar completamente la otra perspectiva │
│ 2. Timeboxear discusión (2-3 min) │
│ 3. Si no hay consenso: probar una, evaluar después │
│ 4. "Try it and see" > debate largo │
│ │
└─────────────────────────────────────────────────────────────┘
Tracking en GitScrum
TAREAS DE PAIRING
═════════════════
LABELS:
┌─────────────────────────────────────────────────────────────┐
│ 👥 pair-programming │ Tarea recomendada para pair │
│ 👤 solo │ Mejor hacer individual │
│ 🎓 onboarding-pair │ Pairing para entrenamiento │
│ 🧠 complex │ Complejidad sugiere pair │
└─────────────────────────────────────────────────────────────┘
EN LA STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Story: Refactorizar módulo de pagos │
│ │
│ Complejidad: Alta │
│ Riesgo: Alto (código crítico) │
│ │
│ Recomendación: 👥 Pair programming │
│ Razón: Código crítico, reduce riesgo, knowledge sharing │
│ │
│ Asignados: Dev A + Dev B │
│ Estimación: 8h (pair hours) │
│ │
└─────────────────────────────────────────────────────────────┘