Durante estos años en los cuales venimos implementando la Programación de a Pares (PP), hemos detectado en nuestra propia práctica ciertos errores comunes en los que hemos caído y tratado de corregir. Aquí les dejo una lista de dichos errores, contando un poco de qué se tratan y la manera de solucionarlos.

Desconocer en qué consiste la tarea

Suele ocurrir que luego de asignarse cierta tarea, los miembros que la toman tienen distinta idea de lo que deben realizar. Pair Programming apunta, entre otras cosas, a mejorar la comunicación dentro del equipo. Una buena práctica es ponerse de acuerdo o discutir en qué consiste lo que deben realizar antes de arrancar a hacerlo para que ambos desarrolladores sepan de qué están hablando y sobre qué están trabajando.

Cumplir la función del IDE

“Te falta el punto y coma” o “escribiste mal el nombre de la variable” son frases bastante escuchadas en personas que están haciendo PP para indicarle errores al que esta tipeando. La realidad es que esos errores son errores que el propio entorno de trabajo (por ejemplo Netbeans o Eclipse) marcan por sí solos. ¿Pensaron alguna vez para qué gastar energías en marcar dichos errores cuando el propio IDE ya lo hace? El copiloto, como dijimos antes, debe enfocarse en adelantarse a lo que esta haciendo el que tipea, en pensar mejores soluciones. No tiene sentido que realice una función que el mismo IDE hace. ¡Como copilotos gastemos nuestra energía en cosas útiles!

Ausencia intelectual del copiloto (persona que no tipea)

Suele ocurrir que cuando dos personas realizan PP, el que está como copiloto se queda divagando hasta que el que conductor termina de escribir su porción de código. Este comportamiento hace que el PP pierda la mayor parte del sentido que tiene, ya que no hay ganancia en esto (y de hecho, se pierde el doble de tiempo que trabajando individualmente). Es importante que tengamos conciencia de estar presentes intelectualmente cuando no estamos tipeando, ya que tenemos una responsabilidad quizás mayor que el que tipea: pensar en lo que viene.

Mantener las islas de conocimiento

Otro error bastante común ocurre cuando se proponen hacer PP entre una persona con un conocimiento avanzado (ya sea de negocio o técnico) y otra persona que recién se inicia. En estos casos puede suceder que la persona que más sabe es el que se predispone a escribir con la excusa de “terminar todo más rápido” y el que está aprendiendo termina mirando (y sin entender nada).

PP apunta a destruir las islas de conocimiento y que el conocimiento se comparta entre los miembros del equipo. Es útil que la persona que más sabe ejerza el rol de “mentor”, de manera que el “aprendiz” sea el que tipee, que se choque con el problema y que el mentor lo vaya guiando hacia la solución. Esta es una buena forma de transmitir el conocimiento.

Pensar sin hablar (o no pensar en voz alta)

Más allá del conocimiento que cada miembro del equipo tenga, puede ocurrir también que uno de los miembros asignados en la tarea ya tenga la “solución en la cabeza”, y de nuevo caigamos en el error de ser el que tipea y que haga todo mientras el otro mira, con la excusa de “liquidarlo rápido”. Si bien tener la solución pensada no es un error, en PP es importante compartir dicha solución para que ambos miembros asignados en la tarea sepan qué están haciendo y los dos estén enfocados, no sólo en aplicar dicha solución, sino también a buscar otras que quizás sean mejores.

Rol fijo (piloto, copiloto)

Ocurre algunas veces que entre el piloto y el copiloto no se rota en todo el día, e incluso a veces hasta que se termine la tarea. Es un ejercicio sano rotar. Al cambiar los roles, ambos miembros realizan diferentes actividades, permite poner a cada persona en un lugar distinto para ver cosas que quizás no vió.

Existen varios métodos para rotar: uno puede ser en base al tiempo (por ejemplo, rotar cada 30 minutos). Otro puede ser hacer lo denominado “ping-pong” en el cual un miembro completa una parte del código y el otro lo sigue (por ejemplo, si hacemos TDD, uno codifica el test y el otro codifica su implementación).

"No se puede hacer Pair Programming si hago Teletrabajo"

Una de las críticas que leí sobre el PP es que es difícil (y ciertos autores dicen hasta imposible) de implementar si uno de los miembros realiza Teletrabajo (Home Working).Si bien es más dificultoso implementar PP sin la presencia física de ambas personas en el mismo lugar, no es imposible. Se pueden pensar en alternativas como teleconferencias, compartiendo los escritorios. Por ejemplo, Skype es una buena herramienta para realizar PP en Teletrabajo. Nos permite compartir el escritorio y que ambos miembros puedan comunicarse de manera online. ¡Busquemos alternativas para realizarlo!