¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?

El “pair programming” se basa en que dos programadores trabajan juntos en un solo ordenador. Uno de ellos desarrolla mientras que el otro ayuda y revisa el código del compañero. No me hace falta decir más para que entendáis lo controvertido de esta técnica. Los hay que dicen que es un desperdicio de tiempo, que es dividir la capacidad del equipo en un 50%, que “cuando lo escuchó mi jefe no paro de reírse”, etc. Y los hay que dicen que su uso acaba mejorando el desarrollo, en lo que refiere a calidad e incluso productividad.

Y a todo esto añado que, en mi experiencia, son poquísimas las empresas que han dado el paso de implantar el pair programming. Son demasiadas las dudas y el miedo al respecto.

Pero ¿en qué puede ayudarte el pair programming? Principalmente mejorando la productividad, la transferencia de conocimiento y, obviamente, el trabajo en equipo. Veamos como…

¿Mejora la productividad el pair programming?

Este es uno de los aspectos más controvertidos, ya que los escépticos de esta técnica aseguran que el pair programming divide a la mitad la capacidad del equipo.

Como todo en esta vida, no hay una única y absoluta respuesta sobre si esto es cierto, si el pair programming mejora o no la productividad. No obstante, se han realizado numerosos casos de estudio al respecto, véase por ejemplo éste o éste, los cuales, normalmente, concluyen en que a la larga (no en el primer proyecto) se mejora la productividad del equipo con el pair programming.

Entre todos estos estudios, sin duda, uno de los más populares es aquel en el que participaron los famosos Ward Cunningham y Ron Jeffries, un experimento realizado en la Universidad de Utah en 1999. En este experimento un conjunto de programadores con experiencia tenían que hacer 3 ejercicios de programación, un tercio del grupo programó de forma individual y el resto por parejas. Y del estudio se extrajeron las siguientes conclusiones:

• En cuanto al tiempo que tardaron en el primer ejercicio, los que programaron en parejas emplearon un 15% de tiempo más que los que trabajaron de manera individual.
• Pero los pair programming fueron recortando ese tiempo en los ejercicios siguientes. Todo ello debido al proceso de acomodación que requiere trabajar en equipo.
• Los programas resultantes de los pair programming tenían, de media, un 15% menos de fallos y seguían de una manera más correcta los estándares de programación, llegando a tener un 30% menos de líneas de código.

¿Ayuda el pair programming a la transferencia del conocimiento?

Otro beneficio del pair programming es que el proyecto software no dependerá tanto de desarrolladores clave (te recomiendo aquí este post dedicado a los héroes). Gracias a la forma colaborativa de trabajar y el aprendizaje conjunto, siempre habrá más de un desarrollador familiarizado con la misma parte del sistema.

¿Mejora el pair programming el ambiente de trabajo?

Esto depende del equipo y de la empresa. Pero si hay un ambiente de trabajo en equipo, el pair programming ayuda por tres vías:

• Los programadores aprenden a trabajar en equipo.
• La comunicación fluye de forma más a menudo y más eficiente.
• Se crea un aprendizaje continuo, entre compañeros, y es más fácil que un nuevo miembro del equipo se ponga rápido a trabajar y conocer el entorno.

Pero claro, también hay quien piensa que el pair programming invade su trabajo. Aunque según los distintos experimentos y casos de estudio más de un 80% de los programadores que usan durante un tiempo el pair programming aseguran que están satisfechos con la práctica ya que confían más en el producto resultante y en la calidad del mismo.

Alguna conclusión sobre el pair programming …

Como comentaba al principio, no hay una única y absoluta respuesta sobre si el pair programming mejora o no la productividad. Depende del equipo, de la empresa, etc. Lo que sí está claro es que ayuda principalmente a medio plazo, no en el primer proyecto. Lo mejor, si es posible, hacer una prueba controlada.

Y que al final tampoco es algo mágico. Como comentaba Michael Kirby, al relatar su experiencia implantando el pair programming, no te esperes que si tienes programadores malos, juntos hagan buen código, si son malos, juntos también serán igualmente malos.

Si alguien tiene experiencia en el tema o algún comentario…estaríamos encantados de leerlo.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
• Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
• HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024