Hoy en día es muy común escuchar hablar de la Programación en Pareja. En general, la mayoría de los desarrolladores nunca tuvieron la oportunidad de trabajar correctamente de a pares, ni tienen ganas de hacerlo. Y para empeorar las cosas, la gente del negocio sigue pensando que dos desarrolladores en una única máquina es un desperdicio... ¿cómo será puede lograr una implementación exitosa?
A no desesperar. La realidad muestra que al superar los prejuicios y ver la forma correcta de hacer programación de a pares, la mayoría de las personas se convencen de sus beneficios. Puede resultar dificil aplicar con éxito la programación de a pares, pero es completamente posible de lograr si usamos los consejos de este artículo.
Consejos para la Programación en Pareja (PP)
Este artículo asume que ya hiciste algo de la Programación en Pareja, y estás buscando ayudar a tu organización a adoptar esta práctica en donde tenga sentido. Los siguientes consejos sirven para distintos roles; sin embargo, está escrito en su mayor parte para los desarrolladores que quieran introducir esta práctica en sus equipos.
Entonces, si ya estás convencido que la programación de a pares es beneficiosa, ¿cómo se puede aplicar con éxito a un equipo?
Puestos de trabajo
Uno de los mayores obstáculos para adoptar Programación de a Pares es conseguir estaciones de trabajo adecuadas. Una posible configuración podría ser la que sigue, aunque cada uno puede personalizarla a gusto:
- Usar escritorios planos y rectos, de forma que ambas presonas puedan sentarse cómodas una al lado de la otra. Las mesas redondas también puede servir. Los escritorios que se "curvan" hacia uno no son muy cómodos para trabajar con un par, y deberían evitarse.
- Usar la computadora para desarrollo más rápida que se pueda comprar. Si las estaciones para hacer PP son mejores que las individuales es más probable que se usen. Además, sólo se tiene que comprar 1 por cada dos personas, con lo cual se podría gastar un poco más.
- Una placa de video con salida DVI dual. Los splitters también funcionan, pero no tan bien. Es mucho mejor tener una salida DVI dual para lograr la máxima resolución.
- Dos monitores de 24" o 30".
- Dos teclados y dos ratones, aunque lo cierto es que muchos equipos prefieren usar un único par de teclado y ratón.
La idea es crear un ambiente de trabajo que sea más cómodo (o aunque sea igual) que trabajar en una computadora propia. Es dificil pedirle a alguien que deje su escritorio (y auriculares) detrás, pero es tonto pedirle esto mismo y hacerlo trabajar en un ambiente peor. En cambio, hay que crear un ambiente de trabajo para PP el cual sea preferible a las computadoras personales.
Conseguir el espacio para hacer PP también es importante, pero casi todos están dispuestos a ceder una sala o desmantelar escritorios cuando se promete un 20% de incremento en la eficiencia (entre las parejas y la co-ubicación, es bastante fácil lograr este 20%).
Enfocarse en un miembro del equipo a la vez
No creo que haya que forzar a nadie a programar en parejas. A algunos les gusta hacer PP, a otros no. Sin embargo, no vamos a ganar muchos amigos si forzamos a todos los miembros a hacer PP.
A veces se pueden lograr mejores resultados si se emplea un enfoque de "esparcimiento". Se puede empezar trabajando exclusivamente con alguien que no esté convencido pero si abierto a la idea. No suele tomar mucho para que esta persona prefiera hacer PP en vez de trabajar solo. En ese momento se puede sumar alguien más a la idea. Es bueno ir sumando gente que esté abierta, moviéndose desde el más abierto al menos.
En la mayoria de los casos no va a ser necesario llegar a la persona que está cerrada a hacer PP. Generalmente ocurre alguna de estas dos cosas:
- Se da cuenta que el resto del equipo está trabajando más rápido y mejor, y por lo tanto pregunta si puede empezar a trabajar de a pares.
- Se da cuenta que el resto del equipo está trabajando más rápido y mejor, y termina renunciando.
En general, el 90% de las personas que queremos retener prefieren trabajar de a pares. Sin embargo, hay que considerar el impacto de perder a alguien del equipo, ya que es una posiblidad. A veces puede convenir reubicar a estas personas en puestos donde no se sientan amenazados. En otros casos puede que convenga dejarlos ir.
Hay muchos buenos desarrolladores que no creen en la programación de a pares. La mayoría nunca probó hacer PP de manera correcta; sin embargo, incluso después de hacerlo, todavía va a existir un porcentaje que prefiera codificar por su cuenta. Estas personas son buenas también, pero no sirven para aquellos equipos que estén compuestos por personas que hacen PP. Hay que dejar en claro que trabajar en pareja no es un indicador de talento; de la misma manera, el preferir trabajar individualmente no es un indicativo de falta de talento.
A largo plazo resulta un error mantener un equipo en donde haya dos posturas sobre este tema. Ambos lados tienden a pensar que la otra alternativa es muy ineficiente. Estoy podría ocasionar roces y discusiones dentro del equipo. Una organización puede usar ambas posturas, pero no dentro del mismo equipo. Parte de generar una adopción exitosa consiste en descubrir quienes pueden hacer PP, y no perder el tiempo con el resto.
Rotación de pares
Es bueno trabajar de a pares con distintos miembros del equipo. En mi experiencia es mejor estar con una pareja como mínimo 1 día, y como máximo 2 días.
Hay varias discusiones sobre cuánto debe durar junta la misma pareja. Generalmente se habla de 1 día, y no más de 2. Pero hay quienes dicen de cambiar una vez por iteración, y otros la llamada "pareja promiscua" (más de 1 vez al día). Ambos son extremos, pero dependiendo del contexto pueden ser la opción correcta. En todo caso, al rotar la preja con frecuencia se obtienen dos beneficios importantes:
- Cada persona tiene un diferente grado de conocimiento en distintos temas (herramientas, IDEs, dominio de negocio, patrones, testing, y más). El conocimiento se transmite más rápido, u además distintos expertos pueden aportar en diferentes características y áreas del proyecto.
- Trabajar con distintos miembros del equipo va a permitir balancear mucho más el tiempo que se invierte en estar como mentor y aprendiendo.
Los beneficios de la rotación de parejas permite lograr una mayor eficiencia, lo cual ayuda al éxito de la adopción.
Quién debe dirigir
Si alguna vez surge la inquietud por la cantidad de código que escribe uno de los miembors de la pareja (por estar escribiendo mucho o poco), se puede solucionar rápidamente usando la Programación en Pareja con Ping Pong.
El Ping Pong es cuando las dos personas se alternan para escribir las pruebas y las implementaciones. El ciclo sería algo así:
- La pareja 1 escribe un test que falla.
- La pareja 2 hace pasar el test al implementar sólo lo necesario.
- La pareja 2 escribe un test que falla.
- La parea 1 hace pasar el test al implementar sólo lo necesario.
- Volver al paso 1.
Después de unos días las parejas suelen encontrar el ritmo, y más que seguir este flujo comprenden el rol que juegan en cada momento.
La pareja que es mentor
En casi cualquier tarea, generalmente hay un miembro de la pareja que conoce más sobre el problema que el otro. En estos casos tiene sentido que el par menos informado se encargue de conducir (es decir, de escribir código). El mentor debe cambiar su forma de pensar de "esto es lo que haría para construir esta característica" a "¿cómo puedo guiar a mi pareja para que llegue a la solución correcta?". En lugar de ser un implementador, es mucho más importante convertirse en profesor cuando se toma el rol de mentor. Como dice el dicho: "Dale un pescadp a una persona, y lo alimentás por un día. Enseñale a pescar, y lo alimentarás durante el resto de su vida".
Asumir el rol de mentor es es una buena oportunidad para considerar la situación general del proyecto y el camino recorrido. Quizás pienses que hay una forma más simple de resolver el problema actual. Si se te ocurre una forma más efectiva de resolver el problema, en general conviene terminar de explicarle a la pareja como completar la tarea usando el primer enfoque, y luego explicar la nueva idea. Si resulta ser mejor, hay que asegurarse que la pareja comprenda porqué cambiamos. Si resulta ser inferior, seguimos con la solución original.
La pareja que es estudiante
Si hay un mentor, también hay un estudiante que aprende. Como estudiante sólo tenés que tomar control de la estación de trabajo, discutir el problema hasta que lo entiendas, e implementar la solución que resulte más obvia. Si tu solución es adecuada el mentor debería brindarte toda la guía necesaria. Si tu solución no es tan buena, debería resultar fácil discutir con el mentor sobre las limitaciones de la propuesta y encontrar así una mejor solución.
El rol de mentor y estudiante no son fijos, y van cambiando todo el tiempo. Dependiendo la tarea que hagamos, podemos tener conocimiento en esa área o no. Lo importante es reconocer qué rol se está jugando en un momento dado, para poder aprovecharlo mejor.
Como regla general, el estudiante es quien debería estar la mayor parte del tiempo como conductor, escribiendo en el teclado.
Parejas distraidas o con poco interés
Puede ocurrir que tu pareja no esté interesada en la tarea. No es divertido para ninguno de los dos trabajar con una pareja que no le interesa lo que hace. Uno de los beneficios de PP es ue dos personas colaboren para encontrar la mejor solución. Queda claro que una persona sin interés no va a colaborar, por lo que la solución será inferior. Es decir, la solución será tan buena como si hubiera sido pensada por una sola persona, mientras que la otra perdió el tiempo.
Hay varias razones por las cuales una persona puede no mostrar interes. Sin embargo, hay que tener en cuenta que este es un asunto personal, propio de cada persona, y no hay respuestas generales.
Las parejas distraidas, como su nombre implica, son aquellas que se distraen fácilmente por su entorno. Estas parejas tienden a pasar menos tiempo escribiendo, porque siempre están ocupadas ayudando a cualquier otra persona a su alrededor. Las parejas distraidas no son inútiles; de hecho suelen contribuir una parte significativa del código en el que trabajan. Sin embargo, las parejas distraidas no suelen colaborar a su total potencial porque siempre están intentando resolver los problemas de múltiples parejas a la vez. Algunas parejas distraidas también pueden pasar mucho tiempo leyendo emails o haciendo otras actividades.
El principal problema con las parejas distraidas es que no están haciendo PP en su totalidad, y por lo tanto se pierden muchos de los beneficios. Por suerte hay varias cosas que podemos hacer para intentar solucionar el problema.
Un método útil es intentar practicar Programación en Pareja con Ping Pong. Este método fuerza a la pareja a prestar atención todo el tiempo. Además, es una alternativa simple que no necesita reglas adicionales que podrían traer efectos secundarios. El Ping Pong ayuda a convertir una pareja distraida en una pareja que contribuye; sin embargo, a veces el nivel de contribución no está a su máximo potencial. Otra forma útil de lidiar con parejas distraidas es fingir confusión.
Fingir confusión puede ser muy, muy aburrido. A veces ya tenés en claro lo que hay que hacer, la solución está en tu cabeza. Podemos implementarlo de inmediato, dejando de lado a la pareja sin interés. Pero si esto ocurre, la otra persona no sabrá lo que hicimos, y sólo nosotros conoceremos la solución. Cuando haya que hacer un mantenimiento, es probable que tengan que interrumpirnos a nosotros para ayudar, ya que nuestra pareja nunca entendió lo que se hizo.
Entones, aunque fingir confusión puede ser aburrido, resulta en beneficio de todo el equipo. En vez de implementar esa solución que ya vemos tan claramente, debemos preguntarle a nuestra pareja: ¿cómo lo vamos a hacer?. No hay que aceptar la primer respuesta, porque seguramente va a ser horrible. Debemos mantener la discusión, fomentando el pensamiento sin dar nuestra solución, y seguir con las preguntas. En todo momento debemos fingir confusión, haciendo preguntas y tratando de interesar a nuestra pareja. Podemos entonces forzar a la pareja a que escriba 3 pruebas y que implemente el código para pasar esas pruebas. En ese momento, tomamos el control y escribimos una prueba, pero dejamos que la implemente nuestra pareja. De a poco vamos procediendo hacia un Ping Pong. No debería llevar mucho lograr que la pareja desinteresada se comience a realizar contribuciones reales, con beneficio para todos.
Cuando no estar en pareja
Hay algunas situaciones en las que no tiene sentido estar en pareja. Estas situaciones incluyen:
- Cuando hay que leer sobre alguna librería que se va a usar más tarde.
- Cuando hay que investigar un tema complejo o hacer un debug de un error complicado con alguien que no tiene experiencia. En general, hacer PP no va muy bien cuando se combina con la exploración.
Es importante recordar que, si bien estas situaciones pueden no ser óptimas para hacer PP, no quiere decir que no pueda realizarse. De hacerse, hay que recordar que quizás un miembro de la pareja no esté interesado en brindar valor, especialmente si hay una gran diferencia de experiencia entre las personas.
No todas las tareas requieren de una pareja; sin embargo, la mayoría de las tareas se ven beneficiadas cuando se trabaja junto a una pareja.
¿A qué hora estar en parejas?
Suele dar muy buenos resultados determinar durante qué horas del día se debe estar disponible para trabajar en parejas. Usualmente, las horas principales de trabajo en parejas son el 60%-70% del tiempo total del día laboral. Por ejemplo, si trabajás de 9:00 a 18:00, las horas principales para hacer PP podrían ser de 10:00 a 16:00.
Durante estas horas no es obligatorio estar en pareja. Pero, en caso de ser necesario, debería poder hacerse sin problemas, ya que tendría que haber gente disponible para esto. Esto también ayuda a poder posponer actividades que se pueden hacer individualmente hacia las horas fuera del horario de para PP. Por ejemplo, si surge un error a las 12:00 que vamos a solucionar en forma individual, tendría sentido esperar hasta después de las 16:00 para resolverlo.
Una de las objeciones para hacer PP es que la gente "necesita su propio tiempo", y que no puede "estar en pareja las 8 horas del día". Es gracioso, porque nadie dice que hay que hacer esto. De hecho, el poner horarios para hacer PP formaliza esta situación. Algunos hacen el 60% del día en parejas, otros apuntan al 95%, pero nadie intenta lograr el 100%. Es importante tener en claro cuándo se va a trabajar en parejas y cuando no, especialmente durante la etapa de adopción.
Conclusión
"Permitir" trabajar en parejas no es un éxito. El éxito es cuando el equipo disfruta trabajando en parejas y son más productivos a causa de esto. Cuando se enfoca la adopción con este punto de vista hay muchas más probabilidades de lograr el éxito. Entonces, cuando pongas en práctica estas ideas, siempre implementalas de forma que enfoquen al equipo a construir mejor software, de forma más eficiente.
