Muchos de los que me conocen ya saben que más que Scrum, Kanban... si hay algo que realmente creo que funciona es eXtreme Programming. Es por ello que en Profile intentamos combinar las diferentes prácticas de las que nos habla XP con otros frameworks ágiles. Y una de las prácticas que considero más poderosas (bien ejecutada, explicaremos cómo) es el Pair Programming o programación por pares. Todos los conceptos que describiremos en este post están basados en el libro ‘Extreme Programming’ de Kent Beck, primera edición, donde podréis encontrar mucha más información detallada sobre esta práctica y muchas más. Con origen en 1999, muchos conceptos no están adaptados a un mundo en remoto como en el que estamos ahora mismo, pero intentaré aportar mi visión «distribuida» a los conceptos originales.
Qué vas as ver en esta entrada
¿Qué es el Pair Programming?
La respuesta es simple: dos personas trabajando sobre el mismo ordenador desarrollando. Un teclado, un ratón, una pantalla y dos personas. La explicación es sencilla, pero no así la implementación. Realmente es una técnica muy poderosa cuyos beneficios van más allá de solucionar problemas complejos en pares, pero ¿estás utilizándola correctamente? ¿Sabes cómo sacarle el mayor provecho?
¿Qué roles podemos encontrarnos?
Diferenciamos claramente dos roles:
– Navigator: debe asegurarse que todas las herramientas y el entorno de trabajo están preparados para la sesión de pair programming que se va a tener.
Debe tener el foco fijo en la meta, en el objetivo que se haya decidido para la sesión, esa visión a largo plazo. ¿Por qué? Porque es responsable de mantener el rumbo si la sesión se desvía. Siempre se debe tener presente (ambos) que hay que ir dando pasos pequeños (baby steps). Debe sugerir y promover prácticas de XP tal y como TDD (Test Driven Development, ya hablaremos de esto en otro post), o refactorización constante.
Por otro lado es importante que reconozca cuando el Driver (rol de la otra persona) está concentrado y no interrumpir (evitar sugerencias como «falta un punto y coma»). Y una de las labores más importantes que tiene es reconocer si hay que cambiar los roles. Es buena práctica cambiar varias veces los roles durante una misma sesión de pair. Este cambio puede ser propiciado si el driver está cansado o se ha atascado en algún paso y no se está avanzando.
– Driver: es quien está en el teclado. Quien tiene control de la máquina. Debe mantener el foco en el paso o «step» que se esté dando en ese momento. Debe concentrarse en la pieza de código que se está trabajando en ese momento. También es responsable de comentar con la otra persona el enfoque que va a dar a la solución al problema en cuestión (ya que tampoco se trata de desarrollar sin comunicarse y/o suponer que la otra persona nos está siguiendo).
Combinaciones ganadoras
Se identifican diferentes patrones según la experiencia y habilidades de cada persona a la hora de tomar un rol u otro:
– Dos seniors/expertos juntos: parece el combo perfecto, ¿no? De este par se espera una alta productividad, resolución de problemas y grandes resultados. Sin embargo, puede darse el caso de que no emerjan soluciones nuevas, innovadoras y/o creativas. Puede darse el caso de un acuerdo no verbalizado de no cuestionar las prácticas establecidas.
– Senior/experto y alguien nuevo/junior: esta combinación aporta beneficios en ambos sentidos. La persona más senior entrena a la más junior, la cual aprende. A su vez, el junior puede aportar nuevas ideas (al llevar poco tiempo tiende a cuestionar las prácticas establecidas). En este caso, al tener que explicarlas, puede que la persona experta se las cuestione también. En el otro lado puede ocurrir que la persona más junior no tenga la suficiente confianza y tenga una postura más pasiva donde simplemente observa del experto cómo soluciona los problemas. Alguien senior sin paciencia podría perjudicar la confianza del junior y que el pair no sea tan provechoso como podría ser.
– Dos personas nuevas/juniors: no es lo más común, y no es muy usado pero está claro que ante esta situación los resultados serán mejores juntos que por separado.
Errores comunes en Pair Programming
Ya hemos nombrado algunos, pero vamos a listar los errores más comunes a la hora de hacer una sesión de pair:
– Monopolizar el teclado siendo driver, aunque el navigator lo esté solicitando.
– Casi peor que lo anterior: no solicitar el teclado en caso de que sea necesario.
– No facilitar las opiniones de ambos participantes.
– Las dos personas tienen que estar igual de cómodas (suponiendo un pair presencial).
– No descansar lo suficiente.
– No alternar los roles de manera eficiente.
Pair programming distribuido
Como hemos comentado, gran parte de esta estrategia está basada en un mundo presencial donde, en 1999, desde luego, nadie se imaginaba que el trabajo en remoto estaría a la orden del día. Muchas de las normas anteriores pueden ser adaptadas para un pair programming y para ello tenemos diferentes herramientas que nos pueden facilitar estas sesiones. Son herramientas de código colaborativo donde, más allá de compartir pantalla, facilita mucho la colaboración y trabajo sobre el mismo código.
Os dejo el enlace de una charla formativa donde hablamos sobre las reglas de juego de Pair Programming y echamos un vistazo a las diferentes opciones que existen, ventajas, desventajas y herramientas para poder hacer Pair Programming en distribuido.
Desde mi experiencia, siempre que me he sentado a una sesión de pair programming, todo han sido beneficios y nuevos aprendizajes. Aprendizajes que valen oro. ¿Conoces esta técnica? ¡Compártenos tu experiencia! Si quieres ampliar más información sobre este tema, suscríbete a nuestro canal de YouTube.
