Mob pro­gra­m­mi­ng: de­sa­rro­llo de software en equipo

Una forma re­la­ti­va­me­n­te nueva de de­sa­rro­llo de software es el llamado mob pro­gra­m­mi­ng, que se centra en el trabajo en equipo. Con él, varios de­sa­rro­lla­do­res trabajan juntos en el mismo producto final.

El mob pro­gra­m­mi­ng es un método de de­sa­rro­llo de software re­la­ti­va­me­n­te nuevo que se basa pri­n­ci­pa­l­me­n­te en el trabajo en equipos or­ga­ni­za­dos. Inspirado en el agile de­ve­lo­p­me­nt, es un método en el cual las es­tru­c­tu­ras je­rá­r­qui­cas que a menudo se in­te­r­po­nen en la toma de de­ci­sio­nes deben ser disueltas. El fuerte enfoque en la co­la­bo­ra­ción también está inspirado en otros métodos ágiles de de­sa­rro­llo de software.

El enfoque co­la­bo­ra­ti­vo del mob pro­gra­m­mi­ng puede en­te­n­de­r­se como una evolución del pair pro­gra­m­mi­ng. Mientras que en este último los de­sa­rro­lla­do­res trabajan en el software en equipos de dos personas según el lema “cuatro ojos ven más que dos”, el tamaño del equipo en mob pro­gra­m­mi­ng se in­cre­me­n­ta a entre cinco y diez de­sa­rro­lla­do­res.

Pero a di­fe­re­n­cia del tra­di­cio­nal trabajo en equipo, el mob pro­gra­m­mi­ng tiene otras ca­ra­c­te­rí­s­ti­cas es­pe­cia­les: en lugar de trabajar en varios or­de­na­do­res al mismo tiempo a través de he­rra­mie­n­tas de co­la­bo­ra­ción, como GitHub, en el mob pro­gra­m­mi­ng solo se utiliza un terminal. A menudo se proyecta en la pared con la ayuda de un proyector para que lo vean todos los co­la­bo­ra­do­res. Además, los co­m­po­ne­n­tes del sistema global no se di­s­tri­bu­yen a de­sa­rro­lla­do­res in­di­vi­dua­les es­pe­cia­li­za­dos. En la pro­gra­ma­ción en masa, todo el equipo trabaja si­mu­l­tá­nea­me­n­te en el mismo código. Incluso la creación de catálogos de re­qui­si­tos o las pruebas y el de­s­plie­gue del software terminado es un asunto de equipo.

Para es­tru­c­tu­rar el trabajo en equipo, se asignan di­fe­re­n­tes roles a los miembros del equipo al principio de cada fase de mob pro­gra­m­mi­ng. Sin embargo, estas funciones no son estáticas. Al cabo de cierto tiempo (no­r­ma­l­me­n­te de 15 a 30 minutos), se inicia un cambio de roles. En cada equipo hay un driver y varios na­vi­ga­to­rs:

• Driver: El driver es la persona que fi­na­l­me­n­te teclea el código. Es el que pone en práctica los conceptos e ideas de­sa­rro­lla­dos en el equipo.
• Navigator: Los demás miembros del equipo se denominan na­vi­ga­to­rs y de­sa­rro­llan las ideas en co­la­bo­ra­ción.

De­pe­n­die­n­do del enfoque de mob pro­gra­m­mi­ng que se siga, puede haber otras funciones entre los na­vi­ga­to­rs:

Un de­s­ti­na­ted navigator es­tru­c­tu­ra los pla­n­tea­mie­n­tos e ideas de los miembros del equipo y media entre las opiniones en­fre­n­ta­das para que el driver no tenga que decidir entre distintas opciones. A menudo asume al mismo tiempo el papel de cro­no­me­tra­dor, que asegura el cambio de roles dentro del equipo después de un de­te­r­mi­na­do período de tiempo.

Además, algunos miembros del equipo pueden ser los llamados re­sea­r­che­rs. En caso de am­bi­güe­da­des e in­ce­r­ti­du­m­bres, in­ve­s­ti­gan y recogen in­fo­r­ma­ción para todo el equipo. Este equipo también puede incluir a personas que no pueden aportar nada concreto a la fase de de­sa­rro­llo, sino que se limitan a observar todo el proceso y hacer preguntas en caso de am­bi­güe­da­des. Se les llama learners.

No está prescrito cómo debe diseñarse el mob pro­gra­m­mi­ng. El diseño depende más bien del propósito y de la dinámica del equipo. No obstante, existen di­re­c­tri­ces cuyo cu­m­pli­mie­n­to co­n­tri­bu­ye al éxito del mob pro­gra­m­mi­ng.

Es aco­n­se­ja­ble conectar el ordenador del driver a una pantalla grande común o a un proyector para que todos los miembros del equipo puedan seguir el estado actual del código. Por tanto, la pro­xi­mi­dad física también desempeña un papel im­po­r­ta­n­te en el mob pro­gra­m­mi­ng: lo ideal es que todo el equipo de pro­gra­ma­ción esté en el mismo lugar. Esta es la única manera de be­ne­fi­ciar­se del in­te­r­ca­m­bio directo y personal.

La asi­g­na­ción de funciones dentro del equipo también es un requisito im­po­r­ta­n­te para el éxito del mob pro­gra­m­mi­ng. En pa­r­ti­cu­lar, el cro­no­me­tra­dor, que inicia el cambio de rol, es in­di­s­pe­n­sa­ble para apro­ve­char las ventajas del mob pro­gra­m­mi­ng. El cambio dentro de los modelos de rol garantiza una nueva apo­r­ta­ción constante.

El enfoque del mob pro­gra­m­mi­ng ofrece una serie de ventajas. El in­te­r­ca­m­bio de co­no­ci­mie­n­tos del equipo garantiza un de­sa­rro­llo de software creativo y orientado a los objetivos. Además, los de­sa­rro­lla­do­res pueden be­ne­fi­ciar­se de la ex­pe­rie­n­cia de sus colegas pro­gra­ma­do­res y ampliar así sus co­no­ci­mie­n­tos. En este contexto, el mob pro­gra­m­mi­ng es ideal para in­tro­du­cir gra­dua­l­me­n­te a los nuevos empleados en los proyectos. El papel del learner, que existe es­pe­cí­fi­ca­me­n­te para estos fines, es una parte integral de este modelo de de­sa­rro­llo de software.

El mob pro­gra­m­mi­ng también comparte la re­s­po­n­sa­bi­li­dad que conlleva el de­sa­rro­llo de software, mi­ni­mi­za­n­do la presión sobre los de­sa­rro­lla­do­res in­di­vi­dua­les. Gracias a la fo­r­mu­la­ción conjunta del código, es menos propenso a errores y de mayor calidad. Además, las pruebas conjuntas ayudan a ga­ra­n­ti­zar la calidad del código. Por supuesto, esto también se ve mejorado por el hecho de que todo el equipo trabaja en el mismo código al mismo tiempo. Así, se eliminan de antemano los errores que surgen durante la in­te­gra­ción de co­m­po­ne­n­tes de software de­sa­rro­lla­dos por separado.

Sin embargo, el mob pro­gra­m­mi­ng también conlleva algunas de­s­ve­n­ta­jas. La más relevante es pro­ba­ble­me­n­te la co­n­si­de­ra­ble cantidad de tiempo y personal que se necesita para aplicar el enfoque ágil. Mediar entre di­fe­re­n­tes opiniones sobre un mismo tema también puede acarrear problemas a la hora de programar un código coherente. Otro punto im­po­r­ta­n­te es que el mob pro­gra­m­mi­ng funciona peor en el te­le­tra­ba­jo y, por lo tanto, no es aco­n­se­ja­ble en este caso. Aunque hay enfoques que proponen el mob pro­gra­m­mi­ng online, la po­si­bi­li­dad de un in­te­r­ca­m­bio personal directo es un co­m­po­ne­n­te im­po­r­ta­n­te en el método.