En esta serie de artículos de James Shore ya vimos de qué trata la programación de a pares (una de las técnicas de Extreme Programming más conocidas y debatidas), la relación entre los roles de conductor y navegante, y un conjunto de consejos útiles al momento de aplicar esta técnica.
En este artículo final James Shore responde varias preguntas que suelen surgir al momento de querer implementar la Programación de a Pares, terminando con una conclusión y alternativas para probar.
¿No es una pérdida de tiempo que dos personas hagan el trabajo de una?
En la programación de a pares, dos personas en realidad no están haciendo el trabajo de una. Aunque sólo se use un teclado, la programación es mucho más que eso. Como dijo Ward Cunningham, "si no piensan con cuidado, podrían terminar creyendo que la programación es sólo escribir sentencias en un lenguaje de programación". En la programación de a pares, una persona está programando y la otra está pensando por adelantado, anticipando problemas y ocupándose de la estrategia.
¿Cómo puedo convencer a mi equipo u organización para que prueban la programación de a pares?
Pidan permiso para probarlo como un experimento. Aparten un mes en el cual todos puedan trabajar de a pares en código de producción. Asegúrense de practicarlo el mes entero, ya que la programación de a pares suele ser más difícil e incómoda en las primeras semanas.
¿Hay que trabajar en parejas todo el tiempo?
[inset side="right" title="No se repitan"]Si se aburren estando de a pares, piensen cómo hacer que el diseño sea menos repetitivo.[/inset]
Esta es una decisión que todo el equipo debería tomar. Antes de decidir, intenten programar en parejas para todo el código productivo (todo lo que se necesite mantener) durante un mes. Quizás lo disfruten más de lo esperado.
Sin importar de la regla, igualmente pueden producir código que no necesitan mantener. Estos casos podrían beneficiarse de un análisis individual.
Algunas tareas de producción son repetitivas y no necesitan de la capacidad extra de pensamiento que nos brinda una pareja. Antes de abandonar la programación de a pares para estos casos, debería considerarse porqué el diseño necesita de tanta repetición. Podría ser un indicativo de fallas en el diseño. Usen el tiempo extra del navegante para pensar en cómo mejorar el diseño; compartan la discusión con todo el equipo.
¿Cómo puedo concentrarme con alguien que me habla?
El navegante no debería tener mucho problema para estar varios pasos por delante del conductor. Si tuviera problemas, le debe pedir al conductor que piense en voz alta para poder entender su razonamiento.
Sin embargo, a veces al conductor podría resultarle difícil concentrarse. Hay que contarle al navegante - podría tener alguna sugerencia que ayude a superar el bloqueo. En otros casos, el conductor podría necesitar un tiempito de silencio para pensar el problema.
[inset side="right" title="Pasos pequeños"]Si te cuesta concentrarte, probá avanzando de a pasos pequeños.[/inset]
Si te encontrás seguido en esta situación, quizás sea porque estás avanzando de a pasos demasiado grandes. Usá el Desarrollo Guiado por Pruebas (TDD) para tomar pasos pequeños. Confía en el navegante para que realice el seguimiento de lo que todavía falta hacer, y enfocate en unas pocas líneas de código que se necesitan para hacer pasar la siguiente prueba.
Si estás trabajando en una tecnología que no comprendés por completo, considerá tomarte unos minutos para trabajar en una solución de prueba. Vos y tu compañero pueden investigar esto juntos o por separado.
¿Qué pasa si hay una cantidad impar de programadores?
Un programador solitario puede realizar varias tareas productivas que no involucran al código de producción. Puede investigar tecnologías nuevas, o aprender alguna tecnología que usa el equipo. Puede trabajar en pareja con el cliente o con un tester para revisar los cambios recientes, pulir la aplicación, o hacer pruebas exploratorias.
También, un programador solitario podría desear pasar parte del tiempo en hacer una revisión del diseño global - tanto sea para mejorar su entendimiento, como para aportar ideas que mejoren ciertas áreas problemáticas. Si hay un refactor grande que está parcialmente completo, el equipo podría autorizar a un programador meticuloso a que termine este refactor.
Si el equipo es pequeño, se podría quedar sin tareas "solitarias" que sean útiles. En ese caso, consideren relajar la regla del "sólo el código productivo en parejas", o agreguen un programador nuevo.
Somos un equipo de dos (o tres) personas. ¿Deberíamos trabajar en parejas todo el tiempo?
Hasta el programador más paciente va a querer explotar si está trabajando en pareja con la misma persona todo el día, todos los días. Usen su criterio sobre cuándo trabajar en parejas y cuando no hacerlo. Si se sienten bien pero su pareja está de mal humor, no insistan; tan sólo digan que ustedes están cansados y tómense un descanso.
Estamos tan concentrados en el trabajo que nos olvidamos de rotar las parejas. ¿Cómo podemos fomentar una rotación más frecuente?
Una forma es recordar que se puede rotar cuando nos sentimos frustrados o bloqueados. De hecho, ese es el momento perfecto para cambiar de pareja y tener una perspectiva nueva.
Algunos equipos usan timers y alarmas para rotar las parejas a intervalos estrictos. Belshee realizó investigaciones donde los resultados muestran resultados interesantes al rotar cada nueve minutos. Aunque esta puede ser una buena forma para adquirir el hábito de rotar parejas, asegurate que todos quieren intentarlo.
¿Cómo podemos hacer programación de a pares de forma remota?
Se puede usar un teléfono con auricular y alguna herramienta para compartir el escritorio como VNC o NetMeeting para trabajar remotamente. Hay equipos que usan estaciones de trabajo individual con sesiones de pantalla compartidas y aplicaciones VoIP.
En general suele ser un pobre sustituto para la pareja en persona. Los equipos XP se suelen sentar juntos, así que la programación en parejas remota no se necesita.
Resultados
Cuando se realiza bien la programación en parejas, encontraremos que nos enfocamos y concentramos intensamente en el código y en el trabajo con nuestro compañero. Experimentamos menos interrupciones y distracciones. Cuando hay una interrupción, una persona se encarga del problema mientras que la otra continua pensando. Después, se vuelve al flujo de trabajo inmediatamente. Al final del día te sentís cansado y satisfecho. Se disfruta la concentración intensa y la camaradería de trabajar con compañeros de equipo.
El equipo completo disfruta construir código de más calidad. La deuda técnica disminuye. El conocimiento fluye rápidamente en el equipo, aumentando el nivel de competencia de todos y ayudando a que los nuevos miembros puedan integrarse sin problemas.
Contraindicaciones
La programación de a pares necesita de un espacio de trabajo cómodo (lean Cómo armar una oficina para hacer Programación de a Pares). La mayoría de los cubículos de oficina no sirven. Si tu espacio de trabajo no permite que las parejas se sienten lado a lado, elegí entre cambiar el espacio de trabajo o no hacer programación de a pares.
De manera similar, si el equipo no se sienta junto, la programación de a pares podría no funcionar. Aunque se puede hacer remotamente, no resulta tan bueno como en persona.
Otro motivo para evitar las parejas puede ser la resistencia de los programadores. El trabajo en parejas es un cambio enorme para los hábitos de trabajo de algunas personas, y se puede encontrar resistencia. En ese caso se les puede pedir que lo prueben por un par de meses antes de tomar una decisión. Si todavía se resisten, quizás sea mejor evitar las parejas en vez de forzarlas.
Alternativas
La programación en parejas es una herramienta muy poderosa. Reduce la cantidad de defectos, mejora la calidad del diseño, comparte el conocimiento en el equipo, apoya la auto-disciplina, y disminuye las distracciones; todo esto sin sacrificar la productividad. Si no podés hacer programación de a pares, necesitás alternativas.
Las inspecciones formales de código pueden ayudar a disminuir los defectos, mejorar la calidad y apoyar la auto-disciplina. Sin embargo, los programadores suelen tener problemas en incluir inspecciones en su planificación, incluso aunque estén a favor. Al trabajar en parejas esto ocurre de forma consistente, y brinda un feedback mucho más rápido que las inspecciones planificadas. Si vas a usar inspecciones en lugar de trabajar en parejas, va a ser necesario pensar algún mecanismo de apoyo para que ocurran con regularidad.
Las inspecciones por si mismas no ayudan a compartir el conocimiento de una manera tan completa como lo requiere la Propiedad Colectiva de Código. Si no podés hacer programación de a pares, vas a tener que considerar evitar la Propiedad Colectiva de Código, al menos al principio.
Si igualmente querés mantener la Propiedad Colectiva de Código, vas a necesitar algún mecanismo alternativo para compartir el conocimiento y el estado del código. Se pueden formar grupos de estudio regulares en donde los programadores se reunen diariamente por media hora para revisar y discutir el diseño.
No conozco ninguna otra herramienta que ayude a disminuir las distracciones tan bien como la programación de a pares. Sin embargo, tiendo a distraerme con más frecuencia cuando estoy cansado. En ausencia de una pareja, podemos poner más énfasis en el Trabajo Energizante.
Aprender más
Pair Programming Illuminated [Williams] analiza en profundidad la programación de a pares.
"The Costs and Benefits of Pair Programming" [Cockburn & Williams] informa sobre el estudio inicial de Laurie Williams sobre la programación de a pares.
"Promiscuous Pairing and Beginner's Mind: Embrace Inexperience" [Belshee] es una mirada atrapante sobre los beneficios de rotar parejas a intervalos de tiempo estrictos.
"Adventures in Promiscuous Pairing: Seeking Beginner's Mind" [Lacey] explora los costos y desafios de rotaciones constantes de parejas. Es de lectura obligatoria si van a probar el enfoque de Belshee.
Peer Reviews in Software: A Practical Guide [Wiegers] discute las inspecciones formales y las revisiones de pares.
