Mecánica de emparejamiento
El emparejamiento implica tener dos programadores trabajando en una sola estación de trabajo. Un programador “conduce”, operando el teclado, mientras que el otro “navega”, mirando, aprendiendo, preguntando, hablando y haciendo sugerencias. En teoría, el controlador se enfoca en el código en cuestión: la sintaxis, la semántica y el algoritmo. El navegador se enfoca menos en eso y más en un nivel de abstracción más alto: la prueba que está tratando de pasar, la tarea técnica que se entregará a continuación, el tiempo transcurrido desde que se ejecutaron todas las pruebas, el tiempo transcurrido desde la última confirmación del repositorio y la calidad del diseño general. La teoría es que el emparejamiento da como resultado mejores diseños, menos errores y una mejor difusión del conocimiento en un equipo de desarrollo y, por lo tanto, más funcionalidad por unidad de tiempo, medida a largo plazo.
Difundir el conocimiento
Ciertamente, como mecanismo de tutoría, el emparejamiento es difícil de superar. Si los pares se apagan regularmente (como deberían), el emparejamiento distribuye varios tipos de conocimiento en todo el equipo con gran eficiencia: conocimiento de la base de código, conocimiento de diseño y arquitectura, conocimiento del dominio de características y problemas, conocimiento del lenguaje, conocimiento de la plataforma de desarrollo, conocimiento del marco y la herramienta, refactorizando el conocimientoy prueba de conocimientos. No hay mucho debate de que el emparejamiento difunde este tipo de conocimiento mejor que las revisiones de código tradicionales y los métodos menos formales. Entonces, ¿qué penalización de productividad, si es que hay alguna, paga por difundir tan bien el conocimiento?
Maridaje y productividad
Los resultados de la investigación y los informes anecdóticos parecen mostrar que la productividad a corto plazo puede disminuir ligeramente (alrededor del 15 %), pero debido a que el código producido es mucho mejor, la productividad a largo plazo aumenta. Y ciertamente depende de cómo se mida la productividad y en qué plazo. En un contexto ágil, la productividad a menudo se mide en la ejecución de funciones probadas que se entregan realmente por iteración y por release. Si un equipo mide la productividad en líneas de código por semana, es posible que descubran que el emparejamiento hace que esto disminuya (y si eso significa menos líneas de código por función probada y en ejecución, ¡eso es algo bueno!).
Productividad y rotación de personal.
Los defensores del emparejamiento afirman que si mide la productividad a lo largo de un período lo suficientemente largo como para incluir el personal que se contrata y se va, el emparejamiento comienza a mostrar aún más valor. En muchos proyectos principales, la experiencia tiende a acumularse en “islas de conocimiento”. Los programadores individuales tienden a saber muchas cosas importantes que los otros programadores no conocen tan bien. Si alguna de estas islas abandona el equipo, el proyecto puede retrasarse mucho o peor. Parte de la teoría del emparejamiento es que al difundir muchos tipos de conocimientos de manera tan amplia dentro de un equipo, la gerencia reduce su exposición a esta amenaza constante de rotación de personal. En programación extrema (XP), hablan del número de camión: la cantidad de miembros del equipo que necesitarían ser atropellados por un camión para matar el proyecto. Los proyectos XP se esfuerzan por mantener el número de camiones lo más cerca posible del tamaño total del equipo. Si alguien se va, por lo general hay varios otros para tomar su lugar. No es que no haya especialización, pero seguro que todo el mundo sabe más de todo lo que está pasando. Si mide la productividad en términos de funciones entregadas en varios releases por tal equipo, debe ser mayor que si no se produce el emparejamiento.
Estrategias de maridaje
En XP estándar, todo el código de producción se escribe por parejas. Muchos equipos ágiles que no son XP no utilizan el emparejamiento en absoluto. Pero hay mucho término medio entre no emparejarse y todos emparejarse todo el tiempo. Intente utilizar el emparejamiento cuando asesore a nuevos empleados, para tareas de riesgo extremadamente alto, al comienzo de un nuevo proyecto cuando el diseño sea nuevo, cuando adopte una nueva tecnología, o de forma rotativa mensual o semanal. A los programadores que prefieran emparejarse se les puede permitir, mientras que a los que no, se les permite no hacerlo. La decisión de usar revisiones de código en lugar de cualquier emparejamiento es popular, pero no conocemos ninguna razón para no experimentar al menos con el emparejamiento. No hay evidencia razonable de que perjudique a un equipo o proyecto, y cada vez hay más evidencia de que es una mejor práctica útil.
