Comunicación en equiposUna 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.

Basado en Pair Programming: so you don't want to do it..., de Mark Needham

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw