Pair programming efectivo
¿Qué es el pair programming? Primero establezcamos qué es: Dos personas trabajando juntas en el mismo problema al mismo tiempo.
No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.
Cada persona tendrá un rol:
- Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
- Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.
La pareja podría –y debería– intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.
El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.
Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.
Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando feedback rápido al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.
Se trata del bucle de feedback corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.
Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.
Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.
¿Cómo puedes practicar pair programming?
El pair programming puede hacerse de diferentes maneras:
- Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
- Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.
Depende del equipo –y la tarea en contexto– decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.
Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.
El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.
Patrones Comunes
Diferentes estrategias para pairing efectivo
- Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
- Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
- Backseat driver: El navegador se involucra activamente con el conductor.
- Tourist guide: El navegador aprende pasivamente con el conductor.
Anti-patrones mientras haces pairing
- The silent partner: El navegador no participa, está en silencio.
- The solo act: El conductor ignora todas las aportaciones del navegador.
- Distracted pair: La pareja no se enfoca en el problema a resolver.
- The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
- Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
- The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.
¿Quieres más? Mira esto: Learning Through KATAS
Gracias a mi amigo Manu, quien me ayudó con este post. Incluso compartimos un taller sobre este tema.
Posts relacionados
- Test-Driven (Development) ¿Qué tiene de desafiante?
- El camino a la seniority en software ¿Cómo convertirse en un Desarrollador de Software Senior?
- Entendiendo a las personas Malentendidos, comunicación efectiva y autorreflexión
Lecturas relacionadas
- The Clean Coder por Robert C. Martin
- Extreme Programming Explained por Kent Beck
- Object Design Style Guide por Matthias Noback
- Advanced Web Application Architecture por Matthias Noback