Mecánica de emparejamiento
El trabajo en parejas consiste en que dos programadores trabajen en una misma estación de trabajo. Un programador «conduce», operando el teclado, mientras que el otro «navega», observando, aprendiendo, preguntando, conversando y haciendo sugerencias. En teoría, el programador que conduce se centra en el código en cuestión: la sintaxis, la semántica y el algoritmo. El programador que navega se centra menos en eso y más en un nivel de abstracción superior: la prueba que intentan superar, la tarea técnica que se debe entregar a continuación, el tiempo transcurrido desde que se ejecutaron todas las pruebas, el tiempo transcurrido desde la última confirmación en el repositorio y la calidad del diseño general. La teoría es que el trabajo en parejas da como resultado mejores diseños, menos errores y una mejor distribución del conocimiento en el equipo de desarrollo, y por lo tanto, una mayor funcionalidad por unidad de tiempo, a largo plazo.
Difundir el conocimiento
Sin duda, como mecanismo de mentoría, el trabajo en parejas es difícil de superar. Si las parejas se alternan regularmente (como deberían), el trabajo en parejas distribuye varios tipos de conocimiento por todo el equipo con gran eficiencia: conocimiento de la base de código, conocimiento de diseño y arquitectura, conocimiento de las características y el dominio del problema, conocimiento del lenguaje, conocimiento de la plataforma de desarrollo, conocimiento de marcos de trabajo y herramientas. conocimiento de refactorizacióny poniendo a prueba el conocimiento. No hay mucho debate sobre que el trabajo en parejas difunde este tipo de conocimiento mejor que las revisiones de código tradicionales y los métodos menos formales. Entonces, ¿qué impacto negativo en la productividad, si es que lo hay, tiene esta eficacia para difundir el conocimiento?
Emparejamiento y productividad
Los resultados de las investigaciones y los informes anecdóticos parecen indicar que la productividad a corto plazo podría disminuir ligeramente (alrededor del 15%), pero debido a la gran calidad del código resultante, la productividad a largo plazo aumenta. Y, por supuesto, depende de cómo se mida la productividad y durante cuánto tiempo. En un contexto ágil, la productividad suele medirse en función de las funcionalidades ejecutadas y probadas que se entregan por iteración y por versión. Si un equipo mide la productividad en líneas de código por semana, es posible que observe que el trabajo en parejas reduce esta cifra (y si esto implica menos líneas de código por funcionalidad ejecutada y probada, ¡mejor aún!).
Productividad y rotación de personal
Los defensores del trabajo en parejas afirman que, si se mide la productividad a largo plazo, incluyendo las contrataciones y salidas de personal, esta práctica demuestra un valor aún mayor. En muchos proyectos convencionales, la experiencia tiende a acumularse en "islas de conocimiento". Los programadores suelen dominar muchos aspectos importantes que otros desconocen. Si alguno de estos "islas" abandona el equipo, el proyecto puede retrasarse considerablemente o incluso fracasar. Parte de la teoría del trabajo en parejas se basa en que, al distribuir el conocimiento de forma tan amplia dentro del equipo, la dirección reduce su exposición a la constante amenaza de la rotación de personal. En la programación extrema (XP), se habla del "número de camiones": la cantidad de miembros del equipo que, de no ser por ellos, tendrían que ser atropellados para que el proyecto se paralizara. Los proyectos XP se esfuerzan por mantener este número lo más cercano posible al tamaño total del equipo. Si alguien se va, normalmente hay varios que pueden ocupar su lugar. No es que no exista especialización, sino que, sin duda, todos tienen un conocimiento más profundo del proyecto. Si se mide la productividad en términos de funcionalidades entregadas a lo largo de varias versiones por un equipo de este tipo, debería ser mayor que si no se produjera el trabajo en parejas.
Estrategias de emparejamiento
En XP, donde se sigue al pie de la letra el manual, todo el código de producción se escribe en parejas. Muchos equipos ágiles que no usan XP no utilizan el trabajo en parejas en absoluto. Sin embargo, existe un amplio margen intermedio entre no usar parejas y que todos trabajen en parejas constantemente. Se recomienda usar el trabajo en parejas al mentorizar a nuevos empleados, para tareas de alto riesgo, al inicio de un nuevo proyecto con un diseño novedoso, al adoptar una nueva tecnología o de forma rotativa mensual o semanal. Los programadores que prefieran trabajar en parejas pueden hacerlo, mientras que aquellos que no, tienen la opción de no hacerlo. La decisión de usar revisiones de código en lugar de trabajar en parejas es popular, pero no encontramos ninguna razón para no experimentar al menos con esta práctica. No hay evidencia razonable de que perjudique a un equipo o un proyecto, y cada vez hay más evidencia de que es una buena práctica muy útil.
