Porque tres no son multitud

Desde que empecé a trabajar en habitissimo siempre se ha practicado, unas veces más y otras menos el pair programming. Esta técnica se basa en 2 personas trabajando a la vez en un desarrollo. Normalmente una a las teclas y otra a las neuronas. El que escribe el código solo se plantea tareas a corto plazo, mientras que el otro va revisando el código al momento y teniendo en cuenta el medio-largo plazo. Es una buena práctica que vaya apuntando puntos de mejora y futuros refactors. Este último tiene que ser paciente y no dar instrucciones demasiado concretas.

Podemos coger esta técnica e ir un poco más allá. El mob programming es básicamente la misma idea pero ampliándolo a más de dos participantes (¡cuantos más mejor!). Aunque a priori pueda parecer un coste muy elevado a nivel de recursos, 3 o 4 personas trabajando en un mismo desarrollo puede darnos más ventajas de las que parecen a simple vista, sobre todo en el largo plazo. ¡Tapaos los ojos product owners que ahí va!

Antes de remarcar qué ventajas / desventajas nos da esta técnica voy a enumerar un poco los requisitos que se necesitan para poder hacer mob programming en remoto:

  • Conexión estable, sin interrupciones
  • Un software para poder comunicarnos, compartir pantallas y a ser posible poder interactuar con la pantalla de los demás (nosotros empezamos usando google meets y ahora estamos usando tandem)
  • Entornos de desarrollo por cada uno de los participantes ya que se irá rotando el rol de conductor
  • Un ambiente entre los participantes sin tensión, donde todos puedan aportar y no sentirse menospreciados, comunicación asertiva, paciencia y capacidad de llegar a acuerdos con las decisiones del desarrollo
  • Aunque no es un requisito los plugins de los IDE’s modernos para hacer mob pueden ayudaros a trabajar todos sobre exactamente el mismo código:

Ventajas y desventajas

D I S C L A I M E R con mayúsculas. El Mob programming es una herramienta más en el mundo del desarrollo como muchas otras. Por razones obvias, este artículo enumera las ventajas del mob programming para que otra gente se decante a probarlo en sus equipos pero cabe remarcar que no siempre podemos tener los requisitos para que funcione: el desarrollo adecuado, el tiempo o cualquier otro factor que imposibilite trabajar de esta manera. Además, siendo una herramienta que requiere de un grupo de personas trabajando de manera síncrona en un mismo desarrollo tiene un impacto a nivel temporal por lo que es una herramienta a ir implantando progresivamente.

Dicho esto, os comento las ventajas que nos ha traído a nuestro equipo dentro de habitissimo:

  • Garantiza unos mínimos de calidad muy superiores al exponer el código a la vez a varias personas, la toma de decisiones está mucho más consolidada.
  • Facilita, e incluso elimina la revisión del código al haberlo hecho juntos.
  • Todos los participantes entienden el código y el negocio y pueden trabajar sobre él, no nos tenemos que preocupar si nuestro compi está de vacaciones o se pasó con la barbacoa el fin de semana pasado y está con una buena gastroenteritis.
  • Todos los participantes tienen que forzarse a salir de su zona de confort y de esta manera se aprende a plantear y ejecutar las cosas de otra manera. Por otra parte, los participantes con mayor experiencia pueden transmitir directamente conocimientos muy provechosos a los demás. Por otra parte, si hay alguien recién llegado al equipo es una oportunidad perfecta para que empiece a hacerse al código, los procesos y la comunicación dentro del equipo.
  • En nuestra experiencia, al combinarlo con TDD hemos creado una sinergia perfecta. Hemos empezado a coger buenas prácticas haciendo baby steps y viviendo en verde. Aprovechamos la escritura de los tests y la implementación para hacer rotaciones.

Las desventajas:

  • La inversión en tiempo se dispara tanto por el número de participantes a la vez como a la hora de alcanzar un consenso en las decisiones tomadas.
  • La capacidad de paralelizar algunas cosas se ve frustrada.
  • Supone un desgaste mayor al tener que adaptarte a la manera de trabajar del resto.

Nuestra experiencia

Nuestra experiencia con esta herramienta empieza hace mucho tiempo, haciendo pair programming presencial en la oficina donde ya empezamos a verle las ventajas que nos aportaba. Por las circunstancias en las que nos hemos visto, hemos tenido que adaptar esta manera de trabajar al remoto y de paso hemos podido experimentar añadiendo más participantes. Unos consejos que a nosotros nos han servido son:

  • Planificar al principio del día que queremos hacer, analizar bien el objetivo antes de empezar para asegurarnos que todos queremos llegar al mismo punto y dejar los detalles de cómo implementarlo siempre al final.
  • Hacer descansos cada cierto tiempo de manera obligatoria ya que es muy fácil perder el foco.
  • Cuando no hemos tenido la oportunidad de hacer mob programming y hay que revisar algún desarrollo grande hacer mob review (o un tour por el código). Aunque no aportará la mayoría de beneficios que antes he explicado nos dará a todos la oportunidad de entender el código en el contexto del que lo ha programado.
  • Celebrar los éxitos y el progreso, aunque una tarea no esté acometida al 100%. Con un donut, un café, una cerveza, un donut o un high five mediante tandem (como mínimo).
  • Después de ciertas sesiones o de arreglar una incidencia dejar un tiempo de mini retrospectiva para ver qué aprendizajes hemos sacado o podemos sacar.
Celebrando que vivimos en verde

Recursos

https://martinfowler.com/articles/on-pair-programming.html

https://blog.codium.team/2020-09_pair-y-mob-programming

larahogan.me/donuts/

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

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