Todos los artículos
Pair Programming Efectivo

Pair Programming Efectivo

Primero establezcamos qué es el pair programming: 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.

blog-cover

¿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 retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación 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.

cover

¿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.

cover

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.

cover

¿Quieres más? Mira esto: Learning Through KATAS

cover

Gracias a mi amigo Manu, quien me ayudó con este post. Incluso compartimos un taller sobre este tema.

hjklmove /search yyank dtheme ilang ttoc mmark nnote ?help

Atajos de Teclado

Movimiento vim hjkl

hArtículo anterior← left
jBajar↓ down
kSubir↑ up
lArtículo siguiente→ right
ggIr arriba
GIr al final
nSiguiente secciónnext heading
NSección anteriorprevious heading

Ir a g = go

ghIniciogo home
gbBloggo blog
grLecturasgo readings
gpTemasgo topics
geServiciosgo services
gaCharlasgo talks

Acciones

/Buscarvim search
yCopiar URLvim yank
dCambiar temadark mode
tMostrar/ocultar índicetable of contents
iCambiar idiomai18n
fSeguir enlacefollow link
mAlternar resaltadomark text

General

?Mostrar ayuda
ShiftMantener para mostrar atajos
EscCerrar
:Terminalvim command mode