Remote Mob-programming figura entre las técnicas recomendadas para «considerar» (assess) en la edición de abril 2021 del Technology Radar de Thoughtworks y eso me motivó para comenzar escribiendo algunas ideas/definiciones sobre Mob-programming, en otro artículo hablará sobre las particularidades que agrega el componente Remote.

Mob Programming es un práctica a mi entender aún no muy difundida. Se cuenta que la práctica fue inicialmente utilizada por algunos equipos de XP allá por los años 2000, pero no fue hasta ~2014 que empezó a cobrar más popularidad a partir de la difusión impulsada principalmente por Woody Zuill. Fue precisamente de la mano de él que yo conocí la práctica en la XP 2016 en Edimburgo.

All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer

Woody Zuill

En términos resumidos propone que todo el equipo trabaje en conjunto con una sola computadora. Dicho de otra forma, mob-programming es externder la idea de pair-programming a todo el equipo. En cierto modo, es posible que mucha gente considere que en algún momento ha aplicado mob-programming, pero muy posiblemente no sea así porque mob-programming implica ciertas cuestiones como ser:

• Mob-programming implica cierta dinámica del grupo donde los miembros asumen distintos roles a lo largo del tiempo
  
• Mob-programming propone que todo código productivo sea escrito haciendo mob-programming lo cual se traduce a que los miembros del equipo pasan casi todo su tiempo haciendo mob-programming.

Este último punto es el que suele generar cierta resistencia: que todo el equipo esté trabajando en una tarea por vez. Esta resistencia en ocasiones viene de parte de la gerencia pero en muchas ocasiones viene de los propios programadores. De hecho, en algunos contextos hay incluso rechazo al pair-programming. Veo muchos programadores que prefieren trabajar en una dinámica de solo-programming con feature-branches y merge-request aún cuando eso implique tener que lidear con merges y tiempos de espera para tener su código integrado a la rama principal de desarrollo.

Es interesante mencionar que en el contexto de Extreme Programming se propone que todo el código productivo se haga trabajando en pair-programming. En mi experiencia, pair-programming es un práctica de relativo poco uso en el sentido de que quienes la utilizan no la utilizan todo el tiempo (como propone XP) sino en situaciones muy puntuales donde la tarea en cuestión reviste de cierto grado de complejidad/riesgos.

En mi trabajo como coach/mentor casi todo el tiempo que estoy programando lo hago haciendo mob o pair programming.

El uso de mob-programming tiene ciertas consecuencias interesantes:

• Como todo el equipo está trabajando en una misma tarea, hay una sola rama de desarrollo (trunk-based development) por lo cual no hay que lidiar con merges.
  
• El código es revisado mientras se escribe así que no hay tiempo de espera de revisión
  
• Todo el equipo está familiarizado con todo el código
  
• Es muy fácil la gestión del Work-In-Progress ya que está automáticamente limitado a 1

Les dejo aquí algunos recursos para quienes quieran profundizar en estos temas:

• Muy breve resumen de Mob-Programming en el glosario de la Agile Alliance
• Un reporte de experiencia de sobre Mob-Programming escrito por Woody Zuill
• Video explicativo de Mob Programming de Woody Zuil
• Capítulo de Pair-Programming de James Shore de su libro The Art of Agile Development
• Capítulo de Mob-Programming de James Shore de su libro The Art of Agile Development
• Libro gratuito de Remote Mob Programming de Harrer, Hubert y Christ
• Artículo de una experiencia de un equipo haciendo Mob-Programming por 12 meses

En próximos post contaré mis experiencias aplicando esta técnica.