El Bruno

Hola!

Lo de programar a pares (“Pair Programming”) tiene cierto punto de adicción y odio que hace que cuando lo comienzas a probar, es algo muy parecido a un programa de 12 pasos. En los primeros momentos, por lo general es complicado dar con un ritmo bueno de trabajo. La siguiente fase, es algo así como “esto es la rehostia !!!” y el equipo solo quiere trabajar en un modelo de Pair Programming. Finalmente te terminas dando cuenta que ni tanto ni tan poco, que es bueno tal vez tener 2 sesiones de Pair Programming al día en el equipo, una por la mañana y otra por la tarde. Esto da tiempo para que luego cada persona(je) del equipo pueda tener su propio tiempo de investigación, desarrollo personal y jugar al Apalabrados.

Un ejemplo clásico de Pair Programming mal aplicado es cuando se juntan un developer Alpha y un developer Beta, sin dejar claras las reglas de juego. El programador Alpha, como todos sabemos es por lo general muy dominante. Los Alpha Devshablar mucho, imponer su punto de vista, etc. (una especia de Punisher en modo developer).  En un modelo de Pair Programming, este programador acaba adueñándose del teclado, escribiendo el código que a él (o ella) le parece y refutando todas las sugerencias o críticas que recibe del programador Beta. Por otra parte, el programador Beta se encuentra más cómodo en una posición donde no recaiga en él (o ella) mucha responsabilidad, así que esto de estar en 2do plano está muy bien.

Una solución para este tipo de escenarios, es trabajar en Pair Programming, con un modelo “emisor” y “receptor” (o “líder” y “pica teclas”). En este modelo por ejemplo, se definen períodos de tiempo de trabajo, por ejemplo de 25 minutos (al estilo Pomodoro Technique). Durante este período de tiempo, uno de los developers será el encargado de codificar y el otro será el que le indique lo que debe hacer. El “pica teclas” no podrá codificar directamente en base a lo que piensa, sino que deberá ser las manos y dedos del “líder”. Este modelo, es increíblemente improductivo al principio, sin embargo cuando pasa un tiempo tiene una serie de ventajas inherentes

• El hecho de forzar a que uno codifica y el otro lidera, ayuda a que los integrantes del equipo mejoren sus capacidades de comunicación
• El líder, tiene que aprender una forma rápida y coherente de comunicar sus ideas para que el pica teclas las pueda llevar a cabo
• El pica teclas, tiene que aprender a escuchar (esto parece obvio, sin embargo suele ser muy complicado)
• Cuando el líder explica su idea en voz alta, suele ser un excelente momento para detectar problemas, fallos, etc.
• Por otra parte, la parte que escucha también tiene voz y voto, puede desafiar una idea, colaborar con la misma, etc.

Dependiendo del tamaño del equipo, también es importante ir realizando rotaciones en los pares que trabajan. Y no intentar de juntar a los perfiles más obvios.

Los animo a que prueben este modelo y luego me cuentan !!!

Saludos

/El Bruno

Referencias

> Pair Programming, http://en.wikipedia.org/wiki/Pair_programming

> Punisher,  http://en.wikipedia.org/wiki/Punisher

> Pomodoro Technique, http://en.wikipedia.org/wiki/Pomodoro_Technique

> Picture, http://avengersalliance.wikia.com/wiki/Punisher/Dialogues