Cuatro Manos en el Teclado, No

En la infancia de la programación en parejas

Hace muchos años participaba de un equipo de desarrollo en el que se propuso usar herramientas de tipo VNC para fomentar la programación en parejas. En aquel entonces se pensaba que si las dos personas tenían el mismo acceso al teclado/ratón podrían hacer programación en parejas de forma más efectiva.

Mucho ha cambiado el mundo desde aquel entonces. En la actualidad los editores de texto tipo Google Docs nos dan una perspectiva diferente al trabajo creativo/colaborativo, donde es posible que múltiples personas editen un documento al mismo tiempo con un mínimo de interrupción entre ellos.

Sin embargo esta reflexión en realidad pretende enfocarse no tanto en «edición conjunta del código» sino en el proceso de pensamiento creativo inherente a la actividad humana que llamamos programar.

Diálogo para Pensar, Si

Diálogo de la mente

No hace mucho leía, creo que del Dr. Jordan B Peterson una reflexión sobre cómo pensamos los seres humanos. Él decía que cuando pensamos lo que hacemos es algo así como «instanciar» dos o más personalidades o «mentes» que establecen un diálogo entre sí, proponiendo ideas, verificando y cuestionando esas ideas entre sí hasta llegar a una conclusión relativamente satisfactoria para estos participantes.

Mucho del arte de programar es también arte de pensar; en especial pensar de forma asertiva y expedita.

En ese proceso de pensamiento, al realizarlo de forma individual tenemos una clara desventaja; y es que este diálogo ocurre entre dos o más entes que tienen las mismas perspectivas, conocimientos y sesgos.

Obviamente el «solo-programming» o programación individual es más que apropiado para tareas pequeñas o conocidas y rutinarias.

Pero para tareas grandes, complejas o nuevas esas desventajas se multiplican en un escenario de programación individual, y se reducen de forma significativa en el caso de programación en parejas.

No debemos olvidar que el arte de pensar, en muchas ocasiones (probablemente la mayoría) se realiza mejor entre varios que de forma individual.

Tiempo en el barro

Una de las situaciones más apremiantes que tratamos de evitar al escribir código es lo que yo llamo tiempo en el barro o «mud time», es una especie de «positive feedback loop» en el que no tenemos una idea clara de cómo resolver un problema y nuestra perspectiva es insuficiente, y permanecemos un tiempo prolongado (>30min) tratando de resolverlo de forma individual hasta que nos damos por vencidos (cuando es demasiado tarde) y buscamos ayuda. Programación en parejas profesional elimina este problema de raíz.

Inconvenientes y Retos

El principal inconveniente de la programación en parejas es que resulta difícil de vender a los equipos de desarrollo y a sus líderes. A nivel superficial podemos visualizar esta idea «matemática» de oponerse a que dos personas hagan el trabajo de una. Esta imagen tomada de Internet ilustra este tema:

https://www.reddit.com/r/ProgrammerHumor/comments/g5kvnc/pair_programming/

Sin embargo, si miramos más a fondo hay otras dificultades para que un equipo formado adopte un esquema de programación en parejas:

  1. Diferencias de personalidad: En muchos equipos existe ese temor (para nada despreciable) de cómo pueden chocar personalidades opuestas a la hora de hacer programación en parejas. Tener la capacidad de llevarse bien es medular, no solo a nivel de programación en parejas, sino también a nivel de otras interacciones de equipo, desde la realización de revisiones de pares (peer review) hasta los mismos DSU y las ceremonias retrospectivas donde «nos decimos las verdades».
  2. Dificultad para concordar: El arte de alcanzar consensos se vuelve fundamental en las interacciones de programación en parejas. Mucho del temor de adopción reside en la posibilidad de enfrentar situaciones en las que los participantes no puedan ponerse de acuerdo. Es un arte que se desarrolla con la práctica y que tiene mucho que ver con las diferencias de personalidad y la capacidad de escucha y diálogo que tengan los participantes.
  3. La conveniencia de programar de forma individual: Programar de forma individual tiene algunos beneficios para el individuo, como por ejemplo poder ir a la cafetería y tomar un snack cuando nos plazca sin depender de otros, realizar cosas personales como transacciones bancarias, chequear la escuela de nuestros niños etc, sin tener que depender del horario de otros. La programación en parejas requiere un esfuerzo adicional para establecer sesiones de trabajo de poca interrupción (1 o 2 horas) y organizar esas otras necesidades de forma efectiva.
  4. Miedo a lo desconocido: Para los equipos de trabajo que no tienen experiencia con la programación en parejas es usual (como con todas las otras cosas) encontrar un rechazo a la metodología por ser desconocida; este rechazo se manifiesta en diversas formas de argumentos elaborados, algunos razonables, otros no tanto, con el fin de no profundizar en la práctica.
  5. Falta de experiencia o de herramientas adecuadas: para que la programación en parejas sea efectiva y productiva es necesario que se realize correctamente con las herramientas adecuadas. Conocer bien la forma de realizar programación profesional en parejas y qué herramientas de colaboración y de interacción pueden ser beneficiosas es de vital importancia. De nuevo, la excelencia se desarrolla con la práctica.
  6. La creencia (errónea) de que programar en parejas es lo mismo que dos personas haciendo el trabajo de una.

Beneficios de la Programación Profesional en Parejas

Aun cuando ciertamente pudiera parecer más fácil articular argumentos en contra de la programación en parejas, especialmente del corte matemático de dos personas haciendo el trabajo de una

Podemos resumir los beneficios de la programación profesional en parejas de la siguiente manera:

  1. Mejora de la Velocidad del Equipo: de nuevo, la programación en parejas no se trata de dos personas haciendo el trabajo de una sola; sino al revés: la programación individual muchas veces falla al tratar de realizar el trabajo de dos personas por parte de una sola.
  2. Eliminación del tiempo de barro: Descubrir el barro, es decir los problemas que nos tomarán más de 15 minutos en resolver, se realiza de forma inmediata en un contexto de programación en parejas.
  3. Mejora del proceso de pensamiento: pensar es un diálogo; cuando ese diálogo se realiza con diferentes perspectivas razonables es mucho más dinámico, expedito, sincero y libre de sesgos
  4. Dando mi mejor versión: solemos ser más condescendientes con nosotros mismos y perdonarnos malas prácticas cuando estamos solos que cuando estamos trabajando con alguien más. Así de simple.
  5. Equipo con forma de «T»: Cuando realizamos programación en parejas, el conocimiento sobre el trabajo realizado se distribuye con un 100% de ventaja en comparación con el trabajo individual. Esto nos permite tener una organización más informada, con conocimientos de todos los aspectos del sistema, evitando silos de conocimientos.
  6. Mayor estabilidad en tareas complejas o grandes: Sin duda alguna la programación en parejas favorece la realización de tareas grandes y complejas tal y como lo ilustra el ejemplo del bloque. Hay tareas cuya complejidad simplemente no puede hacerse de mejor manera de forma individual sin acudir a la «ejecución heróica» o sin caer en fallar el compromiso de entrega.
  7. Mayor cohesión de equipo: Un equipo de trabajo que ha practicado y aprendido el arte de la programación en parejas es un equipo que conoce el valor del respeto, del consenso, del compromiso conjunto, de los logros conjuntos; es un equipo que aprecia las diferencias y sabe cómo sortearlas y sacar el mejor provecho de la diversidad de sus miembros.
Programación Profesional en Parejas

 4,615 total views,  1 views today

0Shares
Última modificación: octubre 23, 2020

Autor

Comentarios

Escribe una respuesta o comentario

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.