El Pair Programming consiste en que 2 desarrolladores trabajan, simultáneamente, en la programación de una funcionalidad.

Los ingredientes de esta receta son:

  • 2 personas.
  • 1 pantalla.
  • 1 ordenador.
  • 1 teclado.
  • 1 ratón o trackpad.
     

La clave está en que durante la sesión las 2 personas vayan intercambiándose el rol de escribir código. Uno pica y el otro mira…
 

¿Ya está?

¡Para nada! Durante la sesión se habla mucho, muchísimo. Quien escribe el código va comentando la jugada al que mira (reflexiona en voz alta, verbaliza el problema y la solución), y quien mira va opinando sobre lo que se escribe (errores tipográficos, de formato, de aplicación de patrones, otras maneras de abordar el problema, ideas de casos de uso, edge cases que cubrir…). Al final suceden un sinfín de interacciones positivas.

Yo lo he practicado y recomendado en varias ocasiones.

He visto cómo sólo en la primera hora (asumimos un cambio de rol cada media hora) las personas han intercambiado truquitos del IDE que desconocían y aprenden del compañero/a. O cómo 2 desarrolladores que inconscientemente competían por imponer su solución al problema (que incluso afectaba a su relación personal) llegan a un punto de encuentro e incrementa el respeto mútuo al día siguiente y, por ende, su relación.

Obviamente, el Pair Programming no es la panacea, pero los beneficios potenciales, en mi opinión, superan con creces los riesgos potenciales. Vamos a verlos!
 

Los beneficios

1. CALIDAD, CALIDAD, CALIDAD!

Y no me cansaré de decirlo. La calidad que nace en esta metodología es por:

  • 4 ojos ven mejor que 2.
  • 2 personas juntas piensan mejor que 1 y habitualmente se llega a mejores soluciones.

 

2. Traspaso de conocimiento

Tanto técnico como funcional. Se evitan silos de conocimiento: que sólo 1 persona sea la responsable de una parte concreta del proyecto.
 

3. Traspaso de habilidades

Siempre hay algo que aprender de la otra persona, trucos del IDE, estilo de código, nuevas maneras de atacar un problema…
 

4. Reducción de la gestión

¿Qué? ¿cómo? ¿Pero esto no va de picar código? Lo ejemplificaré con un daily. Un equipo de 10 personas haciendo 10 cosas diferentes van a tirarse un buen rato para intercambiar feedback (nota: un equipo de 10 roza el máximo que recomienda Agile). Sin embagro si el equipo practica 100% el Pair Programming (algo ideal y raro) estamos hablando de 5 focos que atender. Y aprovechando el ejemplo del daily, ¿no crees que 2 personas que trabajan codo con codo durante el día tienen menos posibilidades de sufrir bloqueos? Que es precisamente lo que busca resolver un daily.
 

5. Resiliencia

Dícese de la capacidad para adaptarse positivamente a situaciones adversas. ¿Cuantas veces nos pasa que la cabeza ya no nos da para más? Que estamos dando vueltas y vueltas sobre un problema aparentemente simple y no damos con la tecla. El Pair Programming es una metodología intensiva, no hay momentos para chats o un check rápido a Instagram, tienes a la otra persona picando para ti o pendiente de ti, ahora bien, la constante rotación del tipo de tarea le da aire a nuestra mente y tener el comodín de la llamada (al que no pica) justo al lado te puede sacar de un bloqueo y ganar, atención… VELOCIDAD!!! (quédate con esta palabra para más adelante)

 

El riesgo (o miedo)

Vale, vale, muy bonito… ¿pero voy a pagar 2 sueldos en 1 proyecto para que 2 programadores se intercambien truquitos y se hagan más amigos? Para eso que se vayan a tomar un café ¿no?

Este es el miedo número uno: LA PASTA.
 

Se han hecho algunos estudios empíricos, pero no hay nada concluyente que explique cuánto incrementa el coste el hecho de usar esta metodología. Ahora bien, no, no es el doble (si sale el doble es que se está haciendo mal).

Este miedo viene de una cultura que cree que el programador escribe líneas de código, si escribe más código en menos tiempo es más productivo, por tanto 2 programadores escribiendo un único código escriben la mitad que 2 y por tanto son menos productivos… CRASO ERROR. No hay que confundir rapidez (speed), cuán rápido vas, con velocidad (velocity), cuán lejos vas.

¿De qué sirve escribir código el doble de rápido (2 personas) si avanzas menos porque el número de errores, por persona se multiplica, precisamente por 2? (exgerando al nivel del que opine que 2 programadores producen doble de funcionalidad que 1) Y no estoy contando el tiempo de la tercera persona que encuentra el error y luego lo tiene que volver a validar.

  • ¿Cual es el coste de una calidad menor? Volver sobre el mismo código una y otra vez a resolver bugs.
     
  • ¿Cual es el beneficio de una aprendizaje más rápido? No sólo técnico si no funcional también.
     
  • ¿Qué precio pagamos por no compartir suficiente el conocimiento? Cuando el experto de turno cambia de proyecto o da un giro a su carrera profesional y deja a un equipo o proyecto en una situación más que comprometida.
     
  • ¿Qué cuesta una lucha de egos? ¿2 expertos rehaciendo el código del otro y avanzando cero en el roadmap?
     

No, no es nada fácil medir todo esto. Todas estas cosas pasan y el Pair Programming no las soluciona per se, pero ayuda a prevenirlas igual que lo hacen otras prácticas:

  • Test Driven Development: Calidad.
  • Dar o ir a una charla técnica: Aprendizaje rápido.
  • La documentación técnica y funcional (actualizada): Evita silos de conocimiento.
  • Ir al CineTIS*, los BirreTIS*, o los Juegos de mesa: Mejora la relación y respeto entre compañeros. 
* el CineTIS, BirreTIS y Juegos de mesa, son eventos que hacemos en BaseTIS para cohesionar nuestro equipo de personas y compartir aficiones.

En definitiva, cuantas más herramientas para convertirnos en mejores profesionales y realizar entregas de mayor calidad en nuestros proyectos, mejor para todos.

¿Qué piensas de este método? ¿Te atreverías a probarlo alguna vez? ¿Crees que es viable implantarlo en tu proyecto/servicio?
 

Linkografía

Foto de cabecera: Spooning by Bitbucket de Atlassian

desenvolupament,development,knowledge,Open,pair programming,Top post,