Una característica clave de los equipos que hacen Programación en Parejas es que su nivel de comunicación es mucho más alto que los equipos que trabajan en forma individual. Y es ahí donde podremos encontrar el verdadero motivo en aplicar esta técnica.
La cultura del silencio
La cantidad de comunicación en un equipo que no trabaja en parejas casi por definición va a ser menor que los equipos que aplican esta práctica - no existe el constante diálogo/discusión que tienen las parejas, ya que todos están codificando en su propio mundo.
Como consecuencia de esto, también se reducen otros tipos de comunicación.
En un cuarto lleno de personas trabajando en parejas no parece raro que alguien pida ayuda a un compañero en la otra punta de la habitación, pidéndole que se acerque a ayudar a su pareja con algo. Como ya hay mucha comunicación ocurriendo, se siente natural hacer esto, y como además otras personas nos pueden escuchar hablar, ocurren los beneficios de la comunicación por ósmosis.
En los equipos que no trabajan en parejas se siente muy incómodo pedir ayuda, ya que todos están en sus teclados individualmente.
Esto genera una cultura en la cual la próxima vez que se necesite ayuda se intenta resolver todo como se pueda individualmente, lo que profundiza y lastima la comunicación general de todo el equipo.
Islas de conocimiento
Otra consecuencia de las personas que trabajan solas es que las personas se vuelven muy especializadas en ciertas áreas del código, y eventualmente ocurre que cuando dejan el proyecto (o están ausentes) no queda nadie que sepa cómo trabajar con esa área de código.
Se hace evidente la existencia de estas islas de conocimiento cuando las personas comienzan a usar frases como "el código de José", o "está hecho como lo hace José". Otro signo de advertencia es cuando se intenta delegar trabajo hacia el "responsables de esa parte del código", un signo claro que no hay colaboración en el equipo para crear software.
Una forma de solucionar este problema sin programación de a pares es hacer obligatoria una revisión de código antes de que se suba al respositorio de código. El tema es que no hay forma de garantizar que esto ocurra si las personas no quieren que se les revise el código, y revertir los cambios una vez que está subido puede parecer demasiado confrontativo y generar más conflictos.
Código repetido
La tendencia en los equipos que trabajan en forma individual es que muchas personas terminan resolviendo el mismo problema una y otra vez.
Como cada desarrollador no tiene visibilidad sobre lo que está haciendo cada uno de sus colegas (está ausente el conocimiento compartido que fomenta la Programación de a Pares), se terminan creando diversas soluciones de baja calidad al mismo problema, en vez de colaborar para llegar a una única buena solución.
El código repetido es quizás uno de los mayores desperdicios en los tiempos del desarrollador - no estamos agregando ningún valor al hacerlo, y creamos confusión para los demás desarrolladores que no saben qué parte del código deberían usar.
Conclusión
Seguramente hay varias formas de resolver estos problemas, pero nunca vi se resuelven de manera efectiva sin hacer que las personas trabajen juntas, más cerca, todos los días.
No debemos pensar en la programación de a pares sólo como una práctica de estar con un compañero, sino que su consecuencia final es mucho más relevante. El objetivo final de la Programación de a Pares es promover y generar una cultura grupal en donde la colaboración y la comunicación sean valores fundamentales para todas las personas del equipo. Y hacia eso debemos enfocarnos.
