Quizá estés familiarizado con el concepto de Pair Programming, o tal vez sea una práctica que normalmente no hacés o no conocés bien. Capaz pensás que lo estás haciendo perfectamente. O quizá creas que no. Podría ser que creas que tu organización rechaza la idea de hacer pair programming por pensar que es perjudicial para el negocio.
Si tenés algunas dudas sobre el Pair Programming o hay cosas que no te cierren de la práctica (¡más ahora en cuarentena!) te invito a que reflexionemos juntos.
Pair Programming (o PP) es una de las técnicas más famosas de Extreme Programming1. Consiste en dos personas desarrollando juntas con el objetivo de lograr un código de mejor calidad. Esto es posible ya que, bajo la premisa que el software es de "creación intelectual", la dinámica propuesta facilita la revisión de código constante y el fluir inmediato de feedback, ideas y conocimiento. En fin, conversaciones que generan mejor código.
Algunas personas piensan que esta práctica se trata de "dos desarrolladores haciendo el trabajo que uno solo podría hacer", y por lo tanto pierden el interés y foco en todos los beneficios. Este y otros mitos hacen que no hagamos pair programming, o lo hagamos mal. ¡Revisemos algunos de ellos!
Pair Programming no es una persona haciendo y otra viendo
El teletrabajo hace que no tengamos una pc común donde mirar, que no podamos altenar con el otro entre teclado y mouse... pero no quiere decir que no podamos asumir y respetar los roles como corresponde. ¿Qué roles?
- Conductor: quien está escribiendo el código.
- Navegante: quien está revisando el código y, un paso detrás, el avance de la historia.
Como navegante tu responsabilidad tiene que estar en facilitar el código y procurar la presencia intelectual de ambos.
Pair Programming no es paralelizar tareas de una misma historia
Trabajar dos en una única funcionalidad significa que, en cada tarea, ambos deben estar completamente involucrados, colaborando para generar el mejor código posible. Que paralelicemos tareas implica que tengamos el foco en dos cosas distintas, resolviendo dos problemas distintos. Si el foco está en dos cosas distintas, ¿cómo participar de conversaciones que faciliten las ideas y los debates? Nuestra responsabilidad como conductor y navegante es otra.
Pair Programming no son dos personas haciendo lo mismo
¿No era que teníamos que hacer la misma tarea? ¿no tenemos el mismo objetivo? Si, ¡tenemos el objetivo de hacer software de calidad!
Esto lo logramos desde dos lugares distintos, con dos roles y responsabilidades diferentes. No se trata de ser conductor y, cuando me toca ser navegante, ir a tomar un café y descansar un rato mirando instagram. Hacer PP es switchear y conversar desde lugares distintos. Si estás quemado, ambos hagan un break.
Pair Programming no aumenta el costo de desarrollo
La revisión de código constante, el mitigar las islas de conocimiento técnico y funcional, e incluso el desarrollo de habilidades comunicacionales en el equipo de desarrollo, nos permiten hacer software de mayor calidad y más mantenible2. Estas son ventajas a largo, mediano y también corto plazo.
Pero, ¿qué pasa con el factor económico? ¿resulta más costoso hacer pair programming? Si te quedás con el pensamiento que mencionamos al principio del artículo, es probable que pienses que no. Sin embargo, la realidad es que a largo plazo está demostrado que no sólo no aumenta el costo, también lo reduce3.
Pair Programming no atenta contra la velocidad
Se relaciona con el punto anterior, así que aplica el mismo principio. Cuando somos capaces de colaborar entre nosotros nuestra agilidad para decidir se potencia, vamos a poder debatir y proponer alternativas, encontrar el camino de acción y la propuesta que nos permita un software de calidad que dá valor.
Pair programming es una práctica muy beneficiosa, y no sólo para equipos con mucho gap de skills. ¡Te animo a que lo puedas implementar en tu día a día!
Referencias: