Metodologías Agiles: Programación en pares

En la metodologías tradicionales los programadores estaban atados a una estación de trabajo y de manera individual (y posiblemente asilada) desarrollaban su trabajo en élla. Su forma de trabajo dependía del nivel de madurez de los procesos de su empresa, pudiera ser que el resultado final dependiera exclusivamente de sus capacidades, o que se guie por algún proceso controlado, para garantizar la calidad del software, finalmente el código puede pasar a otra persona que lo revisaría (si es que este paso se da), y entraría en una serie de pruebas, evidentemente fallaría ( porque nunca funciona a la primera), y se regresaría al codificador para corregir los elementos que fallaron. Incluso puede ser que no fallara como tal, simplemente no cumpliera con las necesidades y expectativa del cliente (por que le cliente nunca está satisfecho, hablaremos de eso en otra ocasión). Además es posible que el código a corregir / modificar no le llegue al mismo codificador, si no a otro, que va a tener que tomar su tiempo en comprender el código, la necesidad del cliente y en realizar la modificación, y después de esto… después de esto, ¡Vuelta a comenzar!

Algunas metodologías ágiles, proponen un enfoque diferente a la programación individual. Es la programación en pares, o programación en pareja, esto es, literalmente, dos programadores trabajando en una misma máquina.

Antes de continuar me gustaría precisar que ninguno gran sistema actual, puede ser obra de una sola persona, elija la metodología que elija, por lo menos en un tiempo prudente. Tener un equipo de trabajo integrado por personas capaces de colaborar entre sí para llegar a fines efectivos, es fundamental para la construcción de software exitoso, el cual que cada vez es mas demandante y interconectado.

Aclarado lo anterior, continuamos con la programación en parejas, dos personas, una maquina… A Primera vista parece que es una pérdida de recursos, hasta que te lo ves funcionando y quedas maravillado con los resultados, que son (entre otros), los siguientes:

• Aunque la velocidad de codificación no llega a ser la suma de ambos codificadores trabajando por separado (dicen que es un 15% menor), la calidad aumenta enormemente, ¿Qué quiere decir eso?, que las veces que el software retorna al codificador (o codificadores) es mucho menor. Es decir hay una disminución real del tiempo en tarda en salir a producción un software.
• Agregando al punto anterior, hay un mejor código, no solo porque cuatro ojos los revisen, sino por que dos personas han llegado a un acuerdo consciente sobre qué es lo mejor.
• Ambos codificadores se motivan entre sí, los dos están trabajando por un objetivo común, con lo que cada uno es el soporte del otro, y se da una dinámica de superación entre sí.
• Homologación de conocimiento, cada uno transfiere sus conocimiento al otro, y es reforzado en su puntos débiles, si ambos desconocen un tema se apoyan para capacitarse.
• Hay menos distracciones, lo normal es que los dos estén trabajando y no paren la ejecución del flujo de trabajo por cualquier cosa, incluso al verlos juntos las gente los molesta menos (aun así no es bueno olvidar hacer pequeñas pausas cuando sea prudente).
• Se adquiere un espíritu de equipo real, que ayuda a la moral del mismo, se entiende que el problema de uno es problema del otro, y que ambos están trabajando para un objetivo común. Ya no tienen sentido los lobos solitarios de la codificación, cuyo código ni siquiera entienden ellos pasados unos meses.
• Se favorece la comunicación. Los problemas, malentendidos y necesidades quedan inmediatamente resueltos, y no al día siguiente o hasta la próxima reunión.

¿Qué necesita una oficina para que funcione la programación en pares?

• Escritorios juntos y amplios, se necesita estar cómodo, no se puede estar apretados e incómodos, hace falta espacio.
• Dos monitores, una CPU, siempre debe hacer dos monitores por CPU, (y esto se entiende cuando se vive).
• Posibilidad de hacer ruido. Lo codificadores necesitan, y estarán todo el rato hablando entre ellos.

Algunos detalles más para tener éxito:

• La persona que no está en el teclado actualmente, es la que dirige la programación, menciona sus ideas en voz alta y el que está en el teclado las intenta plasmar en código, y aportar sus propias ideas, al cabo de una o unas pocas funcionalidad, cambian los roles.
• Debe minimizarse la utilización de teléfonos móviles. El peor escenario posible, es que este codificando la persona del teclado y el otro este distraída en el teléfono móvil. Como comentamos la persona que no tiene el teclado, debe estar dirigiendo la programación.

Una vez que superemos los primeros recelos sobre la programación en parejas, y que consigamos armas equipos de programadores entusiastas y deseosos de mejorar, podernos aumentar nuestra producción y disminuir con creces nuestro numero de errores y fallos.