Aumenta la productividad y calidad software con Pair Programming

Toda mi vida he escuchado que cuatro ojos ven más que dos y que dos cerebros son mejor que uno. A pesar de este hecho parece evidente, por algún motivo mi cabeza siempre había tendido a pensar que el hecho juntar sólo un ordenador y un teclado con cuatro manos era un impedimento para la productividad. ¿Qué me hizo dejar de pensar así? Pues os seré sincero, practicar Pair Programming y abrir mi mente conceptos nuevos, al menos nuevos para mí porque es una de las prácticas comunes de Extreme Programming (XP).

transformar-vida

Recuerdo haber escuchado muchas veces comentarios del estilo  “eso de programar dos en el mismo ordenador… lo hemos hecho muchas veces, nos ponemos dos a resolver un problema, no tiene ningún misterio” o “eso es una tontería, a mi me pones a alguien conmigo y me vuelvo medio loco, me va a retrasar en mi trabajo” o simplemente “eso no vale para nada”. He de reconocer que alguna vez pensé de la misma forma y puede que algunos de estos comentarios hubieran salido de mi boca alguna vez hace años. Por eso para la lectura de este articulo, si lo que conoces de Pair Programming es simplemente el nombre y lo que puedas imaginar al escucharlo, te aconsejo que olvides todo lo que sabes y leas el articulo como si habláramos de : Programación altamente productiva y de calidad e ignores cualquier tipo de pensamiento preconcebido que puedas tener al respecto. Esto es Pair Programming.

pairon

La programación en pareja requiere de dos desarrolladores que  participen en un esfuerzo combinado de desarrollo en un mismo ordenador. Existen varias estrategias o estilos y cada una tiene un objetivo principal bien distinto. Esto quiere decir que aunque todos por norma general tienen objetivos a largo plazo como pueda ser el aumento de la calidad, productividad, comunicación y aprendizaje, cada estrategia a corto plazo focaliza en alguno de ellos con mayor intensidad. Algunos estilos se pueden combinar o alternar.

  • Pair Programming distribuido. No es lo ideal y se puede utilizar tanto en tiempo real como no real. Se suele utilizar en equipos virtuales dispersos geográficamente y nos solemos ayudar con herramientas de comunicación y compartición de escritorio. Se puede usar en combinación con el resto de estrategias que se mencionan a continuación.

liderazgo-y-equipos-virtuales

  • Enseñando por medio de Pair Programming como mentoring. Esto creo que lo ha practicado todo el mundo alguna vez y funciona muy bien. El objetivo buscado no es la productividad a corto plazo si no la formación y training mediante un rol de mentor y un rol de alumno. Conviene utilizarlo durante unas semanas en nuevos miembros del equipo ya que fomenta su adaptación al equipo y aprendizaje. Recordad que el objetivo principal corto plazo en este caso nunca es la productividad, la persona siempre requerirá de una curva de aprendizaje.
  • Enseñando por medio de Pair Programming como transferencia de conocimiento. También lo habréis probado más de una vez. El periodo suele ser más corto y suele utilizarse cuando un miembro abandona el equipo, hay un cambio de tareas o simplemente como rutina de compartición de conocimiento. Su objetivo no es la productividad a corto plazo sino distribuir la información dentro del equipo. Si no practicas Pair Programming habitualmente es una buena manera de evitar silos (conocimiento aislado y no compartido en el equipo, departamento u organización) en el equipo si lo practicas cada cierto tiempo como rutina.

22-2-13-mentoring1

  • Pair Programming Ping-Pong. Ambos miembros cambian alternativamente en función de ciertas acciones. Por ejemplo, uno escribe el test, otro lo implementa, el otro compila, y siguiente refactoriza. Es bastante dinámico y puede combinarse con los anteriores. No se recomienda utilizar cuando el equipo no está acostumbrado a hacer programación en parejas ya que puede llevar al caos por falta de comprensión de la técnica y falta de disciplina. Su objetivo principal es sin duda buscar un aumento de productividad y calidad de código.

PUBLISHED by catsmob.com

  • Pair Programming controlador-navegante. Es el que veremos en profundidad porque creo que es el más habitual y por el que habría que empezar si no se tiene experiencia. Se puede combinar con los anteriores excepto con el Ping-Pong, aunque se pueden alternar con él. Su objetivo es sin lugar a dudas buscar la sinergia y conseguir un aumento de la productividad y de la calidad del código.

sidecar-300x225

En el estilo controlador-navegante, uno de ellos toma el rol de controlador que es el que está codificando y al mando del teclado, mientras que el otro es navegante que va decidiendo y aconsejando al controlador. Se sugiere que se cambien los papeles de cada poco tiempo (en torno a 30 minutos). La programación en pareja, requiere muchísima disciplina, ya que el no seguir ciertas pautas lo único que puede conseguir es que lo que hagamos es “programación con el compañero en el mismo ordenador” que no tiene nada que ver con las bases del Pair Programing.

Disciplina

Dos personas tratando de resolver un problema son dos cerebros funcionando. Lo que tú no ves lo ve tu compañero y lo que él no ve lo ves tú. Los dos están concentrados, no hay uno trabajando y el otro pensando en el fin de semana, charlando con otro compañero o enviando mensajes de texto. Ambos están centrados en lo que están haciendo. El controlador, debe ocuparse únicamente de codificar, pero ojo, esto requiere una gran disciplina para no ponerse a resolver el problema por sí mismo, ya que es el navegador quien decide que es lo que hay o no hay que hacer (aunque normalmente suele ser una negociación). Esto permite al navegador despreocuparse de la codificación y centrarse en resolver el problema global.

Cerebro Derecho e Izquierdo

A muchos desarrolladores les cuesta muchísimo ponerse delante de una pantalla y tener a alguien al lado diciéndote lo que tienes o no que hacer, o simplemente mirando la pantalla. A mí me pasaba. Simplemente es un ejercicio de disciplina y confianza tanto en el compañero como no en uno mismo. La mayor parte de los desarrolladores tienen un punto de introversión que les hace meterse en su mundo, imaginarse la solución y sentirse como dioses creando la vida entre línea y línea. No les suele gustar compartir ese rato de introspección, funcionan mejor solos y tranquilos. Sienten como una amenaza a la otra persona que está mirando por encima de su hombro, se ponen nerviosos, se sienten presionados y empiezan a cometer errores. Es totalmente normal y creo que prácticamente a todo el mundo le pasa que al ponerse a los mandos del teclado “nos volvemos más tontos”.  Pero no os dejéis engañar. Todo es simplemente una ilusión.

what-you-learn-working-as-a-programmer

En el Pair Programming, ambos desarrolladores deben estar totalmente centrados en la solución del problema, deben ser flexibles con las ideas y opiniones del otro, al final se trata de un trabajo colaborativo. Se debe rotar cada cierto tiempo, a ser posible cada 25 o 30 minutos. Dentro del periodo de trabajo, no se puede uno levantar o hacer un break. Para poder explicar estas reglas deberíamos entender el concepto de flow:  Una persona cuando está resolviendo un problema y está muy concentrado en ello, suele sufrir periodos de flow, periodos en los cuales ve tan claro lo que está resolviendo que la solución fluye, sus pensamientos y acciones están totalmente sincronizados. Este efecto, es lo que se intenta provocar de una manera sostenida mediante el Pair Programming para aumentar la productividad. El flow requiere mucho esfuerzo por nuestra parte y no puede mantenerse en el tiempo más de 25 minutos o media hora en sus niveles máximos ya que la concentración disminuye drásticamente debido al agotamiento mental. No sé si conocéis un método de administración del tiempo denominado pomodoro que se basa en el mismo principio. Digamos que cada miembro de la pareja cambia de rol cada 25 minutos para que su nivel de flow no decaiga debido a que se produce un cambio de rol y perspectiva. De esta manera se consigue mantener mayores niveles de flow y productividad a lo largo del tiempo que está haciendo Pair Programming. Tras 8 horas acabas exhausto pero con muy buen ánimo, y es que tener periodos de flow es el efecto que tiene, actúa directamente sobre el ánimo de la persona en positivo.

pomodoro

Normalmente cuando practicas Pair Programming, mejoras la disciplina y la capacidad de poder trabajar de manera colaborativa. Entiendes la importancia de la tolerancia y de que es humano equivocarse. Sin duda se hace mejor código ya que se disminuye la probabilidad de hacer malos diseños. Se aumenta la productividad debido a un flujo constante de trabajo y se mejora la moral debido a que cuando te acostumbras se trata de una experiencia mucho más agradable y amena que trabajar solos. Muchos estudios han demostrado que dos personas habituadas al Pair Programming son más de dos veces productivos y es que como en el caso de equipos se produce también un efecto de sinergia: 2+2 = 5… o bueno en este caso 1+1 = 3.

2-plus-2

Las palabras claves son disciplina, tolerancia y humildad. Pero ¿que suele ocurrir cuando se empieza? bueno aunque una pareja no es un equipo, se suelen pasar por los mismos estados de formación de un equipo: forming, storming, norming y performing. Ten en cuenta que cada uno tiene sus manías y su forma de ver las cosas. Todos tenemos nuestros pequeños egos. Algunos autores dicen que no todo el mundo puede realizar Pair Programming con todo el mundo, ya que ciertos caracteres no son nada compatibles y suelen chocar tanto que nunca se produce el efecto de flow buscado. Aunque esto sin duda puede ocurrir (y ocurre) y nunca debes forzar a los equipos a hacer Pair Programming, bajo mi punto de vista, creo que simplemente es una falta de disciplina que todo el mundo con buena actitud puede llegar a superar. Pondré algunos ejemplos de problemas que suelen darse:

  • Existe un desbalance de conocimiento, uno de ellos conoce mejor el problema, la técnica o el lenguaje. Puede que la persona de mayor conocimiento se sienta frustrada tratando de explicar cada paso que está haciendo y puede que la persona de menor conocimiento se sienta frustrada también al no poder seguir los pasos del otro y termine por desconectarse. Obviamente, no es un estado deseable de Pair Programming, ya que en este caso se está perdiendo el tiempo. Se está utilizando un estilo equivocado, se debería usar uno de los estilos de enseñanza y clarificar cual es el objetivo de la práctica. Recordad: No productividad, si enseñanza.

balanza

  • Existe diferencia extrema de carácter. Existen una serie de caracteres que suelen chocar. Debido a esto suelen producirse por norma general problemas de comunicación que suelen llevar a conflictos y que a su vez suelen llevar a no realizar el Pair Programming con la disciplina que requiere. Normalmente uno de los miembros de la pareja suele convertirse en pasivo dejando hacer el otro para que no haya problema alguno. Una de las cosas que hace el Pair Programming es acelerar el proceso de formación de equipos, haciendo más pronunciado el estado de storming en el equipo. Es un problema de conflicto y como tal es algo que se debe gestionar. Una de las posibilidades es que no hagan Pair Programming juntos, al menos por un tiempo, pero también fomentar la claridad de la técnica, sinceridad de los participantes y profesionalidad, suele funcionar. Ten presente que nunca debes forzarles.

conflictos-300x199

  • Uno haciendo otra cosa mientras el otro codifica. Por ejemplo, mirar el móvil, leer un e-mail. Falta de disciplina sin lugar a dudas. No entienden la técnica, hay que clarificarles los objetivos de la misma.
  • Mi teclado, mi tesoro. Personas muy acostumbradas a trabajar solos no pueden evitar reaccionar apoderándose del teclado en ciertos momentos, sobre todo tras la emoción de ver la solución y no tener el teclado para codificarlo, es algo instintivo. A mí me ocurría con un compañero que al que le ocurría exactamente lo mismo. Fue muy gracioso porque el teclado no paraba dar vueltas por la mesa. El caso es que si no produce ningún conflicto, quizá es mejor usar en estos casos el estilo ping pong, ya que posiblemente ambos se sientan más cómodos. Nosotros hacíamos ping pong sin duda, pero por tendencia natural y la verdad es que entre risa y risa funcionamos bastante bien. En caso de que existiera conflicto, habría que reforzarles clarificando el objetivo y la técnica y resolver las causas raíces del problema, que podría ser una diferencia de caracteres o no entender el propósito.

????????????????????????????????????????????????????????????????????????????????????

  • Estoy tecleando y no puedo escucharte”. Falta de comunicación entre ambos miembros debido a que uno de ellos es incapaz de escuchar por el motivo que sea. A mí me ocurría también y el motivo era que era incapaz de hacer dos cosas al mismo tiempo, me concentraba tanto en el problema que me aislaba sin querer…es una cuestión de disciplina y acostumbrarse. El sentido del humor y la sinceridad del compañero suelen resolver el problema por sí mismo. En caso de conflicto, tratarlo claro.
  • Haz lo que quieras…yo ya miro lo que haces”. El problema contrario, no se produce la comunicación que debería. La solución es la misma, sentido del humor y la sinceridad del compañero. En caso de conflicto, tratarlo por su puesto.

videopp

Algunos ejemplos

Una de las recomendaciones es que las parejas roten frecuentemente. Esto suele generar rechazo por parte de los desarrolladores (y de los managers) y como siempre los problemas que suelen describir para no hacerlo suelen ser de origen psicológico más que problemas reales. Hay gente que rota cuando se sienten frustrados o bloqueados, otros equipos usan timers y alarmas a intervalos estrictos. Se puede cambiar cada 1-3 días y los cambios deben ser aleatorios, pero esto sólo es una referencia ya que existen estudios que hablan de rotación cada 9 minutos con resultados interesantes. Algunos dirán que es muy poco tiempo y que cambiar de tarea a otra tarea puede hacer que la productividad a nivel de equipo baje: nada más lejos de la realidad, si no todo lo contrario. La excusa estrella es que las historias de usuario o tareas, van a durar más del tiempo estipulado para el cambio de pareja por lo que los desarrolladores “no quieren dejar un trabajo inacabado”. Además, el realizar una transferencia de conocimiento “podría llevar más tiempo”. Un argumento totalmente lógico y si ocurre esto realmente así no les fuerces. Pero ten en cuenta que el problema real que tiene el equipo en este caso es que no todo el mundo conoce el código lo suficiente y puede que tengáis tendencias a tener silos (con lo cual más motivo aún para realizar el cambio cada poco tiempo).

positions

Tened en cuenta que uno de los miembros de la pareja puede y debe quedarse en la tarea o historia de usuario y el otro miembro ser reemplazado. La transferencia de conocimiento se haría mientras hacen Pair Programming de forma natural, y el escaso retraso que pudiera haber se ve justificado por la garantía de que no haya silos en el equipo. El motivo real para no querer rotar cada poco tiempo es de origen psicológico y suele ser que la persona no tiene interiorizado que “el código es de todos, del equipo y aún tiene sensación de pertenencia individual del código que es algo muy común. Nunca les fuerces, ellos llegarán a darse cuenta por sí mismos, haz centrarse el equipo en solucionar el problema raíz, la posibilidad de tener silos, y llegarán a la misma conclusión por sí mismos.  En cuanto a las ventajas de la rotación, enumero algunas:

  • No habrá silos de conocimiento, con lo cual, cada uno de los miembros del equipo podría trabajar en cualquier historia de usuario o tarea.
  • Durante esta práctica se hacen pair reviews de forma natural, por lo que garantizas la calidad del código.
  • Todo el mundo trabaja de la misma manera y habla el mismo idioma. Tienen el mismo conocimiento tácito. Fomenta la alineación del equipo.
  • Mejora las relaciones entre los miembros del equipo, acelera de forma natural el paso por los estados de formación del equipo.
  • Se mantiene la motivación, la colaboración, la sinergia.
  • Reduce la cantidad de defectos y aumenta la calidad de diseño
  • Apoya la auto-disciplina.

isla_desierta

En definitiva, si pensabas que la programación en parejas era simplemente dos desarrolladores en un mismo ordenador, nada más lejos de la realidad. Se trata de una técnica de maximizar varios aspectos del equipo, entre ellos la calidad y la productividad. Los problemas suelen venir en gran parte por la falta de técnica en la ejecución. Cuando empecé a tocar la guitarra, me resultaba muy tedioso y no veía apenas mejoras. En ese momento podría haber pensado que la guitarra no podría servir jamás para tocar música. Sin embargo mi problema, era que no tenía la técnica suficiente. Tocar una grandiosa melodía, tiene su sacrificio y aprendizaje, pero sólo alcanzamos el éxito combinando y dominando los mejores instrumentos a tu alcance: la práctica lleva a la perfección.

PDFicono EXTENDIDO

REFERENCIAS:

[1] Pair Programming anti-patterns
[2] Normal Pair Programming session
[3] Programación por pares – Preguntas frecuentes
[4] Pair Programming is kryptonitel

Anuncios