Si en vez de leer prefieres escuchar, dale al play.
En este post, comparto una pequeña definición de pair programming y explico los distintos estilos de pairing. Luego hago un repaso general de los beneficios, desafíos y desventajas de adoptar esta práctica. Por último, presento algunas herramientas que, para nosotros en Codurance, han sido fundamentales al momento de hacer pairing a distancia.
El Diccionario de Cambridge define el pairing como:
Dos personas o cosas que se han colocado en pareja, o el acto de emparejar a dos personas o cosas. Al aplicarlo al desarrollo de software, significa: dos personas que trabajan juntas, en equipo, para obtener un determinado objetivo.
El pairing es una de las prácticas de eXtreme Programming (XP) que fueron formuladas a finales de los años 90 por el gurú de desarrollo de software, Kent Beck. Ha sido utilizada una y otra vez en distintos dominios y proyectos (desde los más pequeños y simples a los más grandes y complejos), generando implementaciones sorprendentes y exitosas.
Pero, ¿por qué hacer que dos personas hagan el trabajo de una? ¿No afecta esto directamente a la productividad? Si hubiera que hacer dos tareas, se necesitaría el doble de tiempo y de recursos. Mientras que uno escribe el código, el otro lo supervisa. Pero, ¿por qué? Parece una locura...¿O no?
Para entender esto, tenemos que repasar nuestro concepto de "coste". Si pensamos a largo plazo, ¿qué significa "coste" en términos de dinero y tiempo? Por muy complejo que sea el problema, ¿siempre se necesitaría el doble de tiempo para completar un par de tareas si dos personas trabajan en ellas? ¿Y si hablamos en términos de calidad? En los siguientes párrafos revelo la metodología detrás de esta "locura".
Pero antes, os dejo algunas citas de los grandes de la industria:
Jean Bartik (Una de las mujeres ENIAC, consideradas por muchos las primeras programadoras)
Kent Beck
Empecemos con cómo se hace una sesión de pairing.
Hay distintos estilos de pair programming. Cada uno de ellos tiene sus ventajas y desventajas. Así que debes elegir el estilo que mejor se adapte a ti y a la tarea que vayas a realizar.
Driver & Navigator: el driver es la persona que controla el mouse y el teclado (es decir, la que lleva el volante). Quién cubra este rol siempre deberá comunicar continuamente lo que hace mientras lo hace. En comparación con el driver, el navigator tiene un rol mucho más pasivo. Él revisa el código y da su opinión al respecto, mientras que el driver lo desarrolla. También se encarga de hacerle seguimiento al objetivo principal y detectar posibles bugs. Esto lo hace siguiendo las mejores prácticas y tomando nota de los posibles pasos u obstáculos a enfrentar. La dinámica del driver-navigator funciona muy bien cuando dos expertos trabajan juntos e intercambian roles regularmente.
Strong-Style pairing/ Backseat Navigator: aquí, la regla de oro es la siguiente:
"Para que una idea pase de tu mente a un ordenador, primero DEBE pasar por las manos de alguien más".
En este estilo, normalmente el navigator es quien tiene más experiencia con el setup o la tarea en cuestión, mientras que el driver es un principiante (en relación al lenguaje/herramientas/dominio/codebase, etc...). Así, la persona experta asume el papel de navigator y guía al novato. Aunque esta técnica se acerque mucho al enfoque "haz lo que te digo", puede ser una herramienta útil de onboarding que le permita al principiante aprender a través de la práctica.
Tour Guide: al igual que el Strong-Style/ Backseat Navigator, el estilo Tour Guide funciona mejor con la combinación experto-novato, especialmente cuando se trabaja con novatos primerizos. El driver (experto) se encarga del razonamiento estratégico. La diferencia es que también se encarga de redactar el código. Mientras esta en ello, informa al "turista" (novato) sobre lo que está haciendo. Esto sucede de la misma manera en que un guía turístico explica a un turista los distintos lugares de interés. El turista raramente interviene o desafía al driver. La discusión sobre la implementación del código se hará una vez finalizado el test. Este estilo de pairing corre el riesgo de que el novato (turista) se desinterese después de cierto tiempo. A pesar de esto, el driver (guía turístico) continua con la sesión.
Ping Pong: la mayoría de los programadores opinan que este es el estilo más interesante y probablemente por eso se ha convertido en el más adoptado. Este estilo tiene un factor de diferenciación con respecto al resto: es completamente compatible con el Test Driven Development (TDD). Por este motivo, es perfecto para cuando se tiene una tarea bien definida que puede ser implementada de forma test-driven.
"Ping": el primer programador escribe un código que fallará el test.
"Pong": el segundo programador escribe un código de implementación para pasar el test y continuará escribiendo un nuevo test que fallará (Ping). Luego, le pasara este test al primer programador para que ejecute la implementación (Pong)...y así sucesivamente.
También se puede responder cada "Pong" con una refactorización del código antes de pasar al siguiente test fallido. De esta manera, se sigue el ciclo "Rojo-Verde-Refactorización".
Esto es más una modalidad que un estilo, así que puede ejecutarse siguiendo cualquiera de los estilos mencionados anteriormente.
Para el pairing a distancia necesitarías mantener una pantalla compartida que te permita ver y, si es posible, controlar el ordenador de tu compañero, de manera que puedas cambiar el teclado, marcar correcciones, hacer sugerencias, etc. Hoy en día, muchas herramientas de videoconferencia permiten compartir la pantalla, algunas de ellas son: Microsoft Teams, WebEx, etc. También existen herramientas open source para realizar videollamadas con control remoto.
El pair programming tiene innumerables beneficios. A continuación se especifican algunos de ellos:
Esto significa que el intercambio de conocimiento debe ser un proceso continuo. Debe hacerse mientras se trabaja.
Pair programming ofrece la oportunidad de compartir conocimiento de forma continua. De este modo, más de una persona sabe exactamente porque el código se escribió de la manera en que se hizo, lo que implicó tomar las decisiones de diseño, los obstáculos enfrentados y las soluciones utilizadas. También elimina el cuello de botella que se genera cuando sólo una persona conoce el código y, de esta forma, reduce dependencias.
El pair programming permite formar parejas con diferentes personas del equipo durante distintas fases del desarrollo. Fomenta la colaboración activa y mejora la capacidad del equipo de comunicarse y trabajar juntos. El que tengamos que explicar nuestra forma de pensar ayuda a entender nuestro proceso de razonamiento. De manera similar, la otra persona debe escuchar y responder a los pensamientos de su compañero. En general, esto mejora la comprensión mutua y la moral del equipo. Incluso podría convertirse en un ejercicio de team-building para mejorar la productividad.
Uno de los mayores argumentos en contra del pairing es el riesgo a que un miembro asuma el dominio del ejercicio y se pierda la esencia colaborativa.
Esto sucede cuando los miembros del equipo han trabajado aisladamente durante toda su carrera y no están acostumbrados a compartir el proceso de desarrollo con nadie más.
Hay algunas medidas que se pueden tomar para mitigar este aspecto:
Esto siempre permitirá que el compañero menos dominante tome el volante regularmente.
Lo ideal es cambiar turnos cada dos horas, independientemente del progreso y del estado del codebase.
Eventualmente, algunas de las soluciones no funcionarán y, cuando esto suceda, podrás revertir rápidamente el error y probar tu solución.
De esta manera evitarás cualquier disputa innecesaria al inicio de la sesión.
Sin embargo, no debemos permitir que esto se convierta en una práctica estándar o una necesidad constante.
Un puñado de sesiones deberían bastar para corregir la dinámica de la pareja.
Repasemos algunas de las desventajas del pair programming:
Para un manager que es nuevo al pair programming, la idea de utilizar dos recursos para una misma tarea es difícil de aceptar. La pregunta suele ser: si dos personas realizan la tarea, ¿tomará la mitad del tiempo completarla? La respuesta es: no a corto plazo. Sin embargo, dará resultados equivalentes o mejores a largo plazo. Estos beneficios se verán reflejados no solo en el tiempo de duración, sino también en otras áreas. Pero para quién no conoce este ejercicio, ese futuro no es más que un espejismo lejano.
Si el driver tiene mucha más experiencia que el navigator, y este tiende a adueñarse del tiempo en el teclado, existe el riesgo de que el navigator pierda interés. Para el navigator se vuelve más fácil observar al driver y asentir. Esto anula el propósito del pair programming.
Lo mismo puede decirse cuando se debe hacer una investigación antes de empezar a codificar. Emparejarse para buscar la solución en un solo ordenador no es óptimo. Es mejor que una sola persona se encargue de este tipo de tareas y que el pairing se reserve para tareas complejas. La mejor manera de llevar a cabo las actividades de investigación es que cada uno de los participantes lo haga individualmente. Después pueden compartir sus resultados y decidir conjuntamente el siguiente curso de acción.
Si la pareja es conflictiva o no se lleva bien, juntarla puede ser contraproducente. Por este motivo, tiene que existir un cierto nivel de respeto y confianza. Al fin y al cabo, el respeto es uno de los 5 valores de XP.
Luego de la pandemia muchas cosas cambiaron, no solo en la industria del software sino también en la distribución y estructuración de equipos. A menudo, los miembros de un equipo se encuentran distribuidos en pueblos, ciudades, países e incluso continentes distintos. Así que en algunos casos las sesiones podrían denominarse pair programming a distancia; es decir, pair programming realizado por dos o más desarrolladores que se encuentran en lugares distintos. Por lo tanto, tendría que llevarse a cabo a través de herramientas para compartir pantalla o IDE (mejor conocido como entorno de desarrollo integrado).
Para satisfacer esta necesidad, se han creado varias herramientas de programación a distancia. Cada una de las herramientas de esta lista entra en al menos una de las siguientes categorías:
IDE Colaborativo: las herramientas de esta categoría le permiten a los usuarios invitar a otros programadores a colaborar en su IDE. En esta categoría sólo se comparte el IDE.
Single user sharing, dual/multiple user control: en esta categoría tenemos herramientas que le permiten a un usuario compartir su pantalla mientras otros usuarios pueden verla y controlarla. Solo un usuario puede compartir la pantalla a la vez; sin embargo, tanto él como los espectadores pueden controlar el dispositivo.
Multi-user sharing, multi-user control: las herramientas de esta categoría ofrecen el mayor nivel de interactividad ya que permiten que varios usuarios compartan y controlen las pantallas al mismo tiempo.
Categoría: IDE Colaborativo
Live Share (VS Code)
Live Share es una extensión de VS Code y esta incluida en las ultimas versiones de VS Code. Por lo tanto, es compatible con Windows, Linux y macOS. Esta herramienta permite que los desarrolladores que utilizan VS Code colaboren en tiempo real. Sin embargo, los usuarios que no tienen VS Code instalado también puede unirse a una sesión a través de un browser.
Microsoft Visual Studio Live Share
Microsoft Visual Studio Live Share es una herramienta versátil. Esta diseñada para ser inclusiva y personalizada a las necesidades de cada usuario. Cuando un usuario inicia una sesión de live share en Visual Studio, sus compañeros de equipo obtienen acceso inmediato y seguro al código. De este modo, nadie necesita clonar, copiar o configurar el código.
Microsoft Visual Studio Live Share permite al usuario co-editar, co-debug, llamar, chatear, compartir terminales, servidores e incluso comentarios. Es una buena forma de promover la colaboración y la cohesión del equipo.
Categoría: Single user sharing, multiple user remote control
Tuple
Tuple es una herramienta de pair programming remoto compatible sólo con Mac. No tiene lag y ofrece una gran experiencia de usuario.
Tuple es una aplicación para compartir pantalla que permite controlar las aplicaciones remotamente. Es decir, mientras que un usuario comparte su pantalla, los demás usuarios pueden verla y controlarla. Sólo el anfitrión puede compartir su pantalla durante una sesión.
Esta herramienta es buena para hacer colaboraciones o pair programming a distancia. Todos los participantes tienen teclado y mouse, por lo que cualquiera de ellos puede solucionar problemas en el código controlando el ordenador central de forma remota.
USE Together/Drovio
USE Together ahora se llama Drovio.
Drovio permite a un usuario (el anfitrión) compartir su pantalla con otros miembros del equipo. Los miembros del equipo pueden ver y controlar remotamente las aplicaciones en el dispositivo del anfitrión como si estuvieran en la misma habitación.
Otra característica beneficiosa de Drovio es que da la posibilidad de que un usuario se una a la sesión sin tener la aplicación instalada. Cualquier usuario con un enlace de invitación (que haya recibido por correo electrónico) puede unirse a una sesión desde cualquier browser.
Está disponible para Windows, macOS y Linux.
Categoría: Multi-user sharing, editing and multiple user remote control.
CoScreen
CoScreen es una gran herramienta que los equipos pueden utilizar para compartir pantallas, editar y trabajar en el código juntos. También ofrece la posibilidad de que varios usuarios compartan su pantalla.
Otra característica destacada de CoScreen es que permite compartir una ventana específica de la aplicación. Es decir, los usuarios pueden compartir una ventana, dejar de compartirla y compartir otra ventana sin problemas, todo ello con un solo click.
CoScreen es compatible con Windows y macOS.
Otras herramientas destacables son:
Puedes amarlo u odiarlo, pero el pair programming es un proceso comprobado que, cuando se hace bien, mejora la productividad y da como resultado un código de buena calidad. Es difícil de realizar, pero sin duda merece la pena. Es como la vista desde la cima del Everest: fenomenal. Lo bueno de la programación en parejas es que no es tan difícil como escalar el Everest, pero proporciona la misma felicidad sublime. Pruébalo y disfruta... :)
Algunos de los entornos de pair programming que se mencionan aquí pueden tener costes.
La deuda técnica, aunque ampliamente debatida, rara vez se aborda de manera efectiva. Según un estudio de McKinsey, representa cerca del 40% de los..
La consultoría estratégica es una disciplina fundamental para las empresas en un mundo donde la rapidez del cambio, especialmente el tecnológico,..
KISS (keep-it-stupidly-simple principle) es uno de los primeros principios que se presentaron a los desarrolladores de software. Es un mantra que..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores
