Pair Programming, lo has escuchado antes, sabes que está de moda pero, ¿has profundizado alguna vez? Te lo contamos.

¿Qué es el Pair Programming?

Se trata de una técnica de desarrollo ágil de software que actualmente valoran mucho las empresas y consiste en dos personas que desarrollan conjuntamente desempeñando un rol distinto.

Los dos roles del Pair Programming son el de conductor o driver, que es el que pica el código, y el del copiloto o navigator, que es el encargado de observar y de guiar al conductor.

Tal y como contamos más adelante, los roles no solo se intercambian, sino que es transcendental que esto ocurra.

Es importante señalar que la comunicación entre los dos desarrolladores es determinante para el éxito de esta técnica de desarrollo.

 

Punto clave del Pair Programming

-Rotación, Pair Programming sin rotación no debería concebirse ya que no deberías “casarte” con nadie al entrar a un proyecto.

Esta rotación elimina silos de conocimiento, dispone a todo el equipo de un contexto de los productos que se están desarrollando, y sobre todo, la temida pérdida de un ingeniero experimentado no impacta tan drásticamente en el equipo, ya que todos poseen el conocimiento transversal.

Cuando hay más equipos en el proyecto, permite rotar entre proyectos y distribuir aún más si cabe el conocimiento.

Por si fuera poco, la rotación permite balancear equipos o crear nuevos equipos separando los antiguos.

 

Ventajas del Pair Programming

–Alta capacidad de aprendizaje. Compartes el conocimiento con tu compañero.

–Calidad del código. Dos personas trabajando sobre lo mismo implica un code review permanente, genera una discusión entre pares que promueve mejores soluciones, más eficientes y legibles, sumando a todo esto la reducción de errores, lo que genera un código muchísimo más mantenible y escalable de cara a un futuro.

–Menor procrastinación. Aumenta el foco de trabajo.

–Interrupciones exteriores inferiores cuando hay dos personas trabajando que cuando lo hace solo una.

–Onboarding inmediato. Los nuevos miembros que se incorporan en el proyecto, trabajan en un entorno productivo desde el día uno, viendo código y aportando valor. Esto rompe con la regla de los dos meses de media que tarda un programador en ser productivo y rentable.

Desventajas del Pair Programming

–Difícil comienzo. Es muy costoso empezar a trabajar con esta técnica de programación por primera vez, ya que, al principio, cuesta ver los beneficios de la metodología. Se necesita una mentalidad y actitud abierta.

-Alta concentración. El rol del copiloto es una pieza clave en la ruptura del flujo de trabajo, es muy importante que esté siempre concentrado en lo que hace su compañero y en el aporte de ideas, ya que su distracción puede arrastrar fácilmente al compañero y llevar al equipo a la pérdida de tiempo.

-Frustración o fatiga. El Pair Programming, cuando se hace correctamente genera mucho cansancio, ya que los descansos o las pausas que te puedan surgir cuando miras el correo, por ejemplo, no tienen cabida. Pero tener a alguien viendo tu misma pantalla hace que intentes ser productivo constantemente.

–Problemas de afinidad. Esta técnica de trabajo también puede generar frustración debido a la falta de afinidad con el compañero, ya que dependiendo del emparejamiento y personalidad de los pares puede degenerar en un pair improductivo por las potenciales discusiones (en el buen sentido) y la consecuencia sea una baja producción.

-¿Improductividad? Dos personas trabajando en un mismo ordenador, implica menos código del que harían por separado (obviamente la calidad es tan alta que merece la pena).

-Pereza. Uno de los problemas que se puede dar es la creación de personas perezosas que dejan todo el peso en el compañero limitándose a mirar. A pesar de que son casos aislados, no sería objetivo pasarlos por alto.

Para evitar problemas, es necesario contratar las personas correctas, que cuenten con una mentalidad adecuada de trabajo en equipo y proactividad, y evitar tanto a las personas excesivamente dominantes como a las excesivamente pasivas.

–Desequilibrio. Se da especialmente en proyectos muy grandes que experimentan un crecimiento demasiado rápido. Este crecimiento supone una inclusión de nuevos desarrolladores a un paso acelerado, y trae consigo una consecuencia, y es que se crean parejas muy descompensadas con un integrante muy junior o con poco conocimiento del proyecto, y otro muy senior que tiene que hacer frente a muchas responsabilidades.

Conclusiones y algo de metodología

Aunque parezca que existen más puntos negativos que positivos, para nada es así, ya que para los contras mencionados, existen métodos que hacen de los contras puntos subsanables.

Trabajando con la metodología Pair Programming, existe un aporte de calidad que no puede ser reemplazado de ninguna otra manera, pero es importante aplicar bien la metodología, para ello repasamos algunos puntos importantes para aplicar el Pair Programming:

-Control. No debería hacerse Pair Programming el 100% del tiempo. Cuanto más veterano es el pair (es decir si ambos son veteranos ), no es recomendable un pair al 100%, ya que es competencia de ellos manejarse, ponerse sus tiempos, pausas, etc.

Con las nuevas incorporaciones pasa algo parecido. Durante las primeras semanas desde el onboarding, puede resultar abrumadora la cantidad de información que se recibe. Es por lo tanto importante que al principio se le otorgue algo de tiempo al nuevo desarrollador para que vaya asimilando todo lo que ha hecho con su par y todo lo que le ha ido explicando.

También es bueno dejar a las nuevas incorporaciones, si es posible, que trabajen juntas, ya que dos personas que tienen el mismo nivel irán más lentas, pero podrán darse cuenta de más cosas.

-Crecimiento controlado. El Pair Programming no funciona tan bien cuando los proyectos son demasiado grandes. En cambio, se ajusta a la perfección a proyectos pequeños en los que se puede rotar entre los distintos equipos. Además de generar un contexto de todo, hace posible balancear los equipos del proyecto.

–El recruitment es clave. Tal y como veníamos contando, hay que contratar a las personas más preparadas, y esto no significa que haya que contratar desarrolladores del mismo nivel. De hecho, es más bien al contrario, ya que distintos niveles aportan distintas visiones al proyecto. Lo importante es la actitud. Es clave contratar personas proactivas y no conflictivas, que sean comunicativas y con ganas de aportar. Esto genera pares en constante comunicación, que hablan, no se aburren, explican lo que hacen, dan sus puntos de vista, etc.

–TDD. El Pair Programming es perfecto para combinarlo con TDD (Pero el TDD daría para otro artículo completo).

En resumidas cuentas, la metodología Pair Programming es una herramienta muy potente para crear equipos unidos, autónomos, independientes y, sobre todo, para generar un desarrollo impecable. No obstante, para un correcto funcionamiento de esta metodología, es necesario trabajar en la contratación y centrarse en un análisis constante para no incurrir en las potenciales desventajas por una incorrecta implementación.

Muchas gracias a Gonzalo Redondo y Raúl Sempere por haber aportado su experiencia al artículo.