Desarrollo: Nuestra Experiencia en Programación por Pares

Desarrollo: Nuestra Experiencia en Programación por Pares

En este artículo me referiré a la programación por pares, un tema que cuenta con partidarios y detractores y que involucra muchas variables tecnológicas y sobre todo humanas, hasta el punto en que ni la ciencia ha logrado ofrecernos conclusiones definitivas.

Este artículo no pretende resolver esta controversia, sino aportar al debate contando la experiencia que hemos tenido en este grupo con su implementación.

Recuerdo que la primera vez que escuchamos el término fue hace unos años en el marco de la programación extrema, que tal como su nombre lo indica, invita a llevar las prácticas que propone a niveles extremos.

En nuestro caso generalmente optamos por los puntos medios en lugar de los extremos, así que contamos con prácticas dónde dos desarrolladores hacen uso de la misma pantalla para trabajar en la misma pieza de código, pero no aplicamos algunas de las características propuestas por la programación extrema, por ejemplo, no la usamos el 100% del tiempo y si hacemos prácticas tipo tutoría, dónde un desarrollador busca enseñar algo a otro.

En general un par se forma cuando:

  • Se está haciendo la preparación de un nuevo desarrollador o se están introduciendo técnicas o tecnologías nuevas en el grupo.
  • Alguien está trabajando en un tema que es del interés de otro.
  • Alguien está trabajando en código complejo, bien sea nuevo o más aun cuando se trata de código que ya estaba en producción, dónde se desea minimizar el riesgo de que se pasen errores sin detectar.
  • El par tiene un objetivo concreto.
  • Ambos desarrolladores están de acuerdo en formar el par y ambos aportan significativamente al objetivo a cumplir, esto generalmente se nota en que ambos intercambian ideas en voz alta.

Hemos adoptado la metáfora de una mudanza, si alguien tiene que cargar una caja de zapatos está bien que lo haga solo, pero si lleva una caja de piezas de porcelana o un mueble muy pesado, es mejor que alguien lo ayude, en pares moverán las cajas problemáticas más rápido y con menor riesgo de que las dejen caer.

Para lograr esto ha sido necesario mejorar nuestras habilidades comunicativas, por ejemplo, poner en orden nuestras ideas para expresarlas con claridad y hablar del código mientras lo escribimos, pero los beneficios han sido muchos, cómo mejoras en la propiedad colectiva del código, reducción del tiempo de capacitación y reducción de código con errores que pasa a producción, así como una mejor integración del grupo de trabajo.

¿Qué experiencias han tenido en programación por pares? Cuéntenos en la sección de comentarios, no olviden darle Like y compartirlo en sus redes sociales. 

Deja un Comentario

CAPTCHA code
X