Mob programming: empujando a tu equipo de desarrollo a la mejora del código común

Trabajar como programador exige una mejora continua. ¿te suena esta frase? Para ello tenemos distintas estrategias. Quizás una de la que mejor puede ayudar al crecimiento profesional de un programador es cuando lo hace junto a sus compañeros de equipo: transferencia de conocimiento, calidad del código común, mejora de la comunicación interna… Un buen acercamiento para conseguir todo esto es la práctica del mob programming.

¿Qué es mob programming?

Mob programming es una estrategia de programación en la que un grupo de desarrolladores trabajan sobre una única tarea al mismo tiempo, en el mismo ordenador y, sobre todo, colaborando entre ellos. Podemos extraer cierta analogía al pair programming pero ampliado a un grupo de programadores.

Por ejemplo, cuatro o cinco programadores es un buen número para practicar esta técnica (aunque con organización es posible incluso manejar grupo de decenas). Uno de ellos se encargará de “pilotar” y el resto actuarán de “navegadores”. El piloto guía el desarrollo de la tarea, mientras el resto va opinando y dando ideas sobre la mejor forma de afrontar el código: detectando malas prácticas (smells) a tiempo, aportando posibles refactors y ayudando a que emerja un diseño lo mejor posible.

Para la práctica de esta técnica se necesita un ordenador común, un proyector a ser posible para que todo el mundo pueda seguir la evolución del código o otro tipo de pantallas paralelas. Lo ideal es que el piloto y el resto del equipo se vayan turnando en sus funciones, así se fomenta que todo el mundo esté activo y en cualquier momento puedan seguir con la tarea. En cualquier caso, los navegantes pueden utilizar sus propios ordenadores para buscar soluciones, buscando dudas y dárselas al piloto para que continúe fluyendo sin bloqueos.

Los tres principios del mob programming

• Trabajar juntos en un única tarea al mismo tiempo. El enfoque es fundamental. Por ello, para maximizar el flow en practicando el mob programming se debe elegir una tarea concreta. Es un buen momento para arrancar una gran historia del backlog y tomar decisiones de diseño con el equipo reunido. De este modo, cada uno sabrá como continuar por separado cuando se divida en tareas más pequeñas. También es interesante seleccionar tareas que impliquen refactor de código para realizar un poco de ?terapia? y analizando/arreglando en un codereview práctico el código común.

• Colaborar en tiempo real. Lo importante del mob programming es que fluyan las ideas. El piloto es el que guía pero los navegantes van aportando ideas para la toma de decisiones en conjunto. Sin darnos cuenta, todo el equipo participa sin distinción entre seniors o juniors, aprendiendo unos de otros (transferencia de conocimiento).

• Todo el mundo en el mismo lugar. Para maximizar que sea lo más productivo posible lo mejor es que todos os reservéis una hora o dos en una sala de reunión. Incluso es beneficioso convencer a personas que participan en la tarea pero no son programadores, como gente de usabilidad o negocio para que se unan, al menos un rato, al mob programming para tomar decisiones sobre la marcha que no estén aun capturadas en los requisitos de negocio. Es una buena forma de potenciar el feedback directo eliminando ruido.

¿Y vosotros habéis practicado el mob programming? ¿Os atrevéis a decirle a vuestro jefe que os vais durante un par de horas varios programadores a trabajar sobre un único ordenador?

Como curiosidad, el término Mob Programming lo popularizó Woody Zuill. Es el responsable del sitio web dedicado al tema y tiene interesante charlas sobre el tema como la siguientes slides y el vídeo dónde pone en prácticas algunos conceptos.