El Mob Programming (que podría traducirse como programación en mafia) es una estrategia de desarrollo de software en la que todo el equipo trabaja en lo mismo, al mismo tiempo, en el mismo sitio y en el mismo ordenador. Ríete del “pair programming”, eso es de débiles, comparado con el Mob Programming.
En efecto, el Mob Programming recuerda a la “programación por parejas” (pair programming), donde dos personas trabajan en el mismo equipo (tema que ya tratamos por aquí hace unos años en ¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?), el Mob Programming extiende esta idea a todo el equipo (entendiendo equipo a unas 5 personas).
Así que si conocéis de alguno al que se le quedaba la cara blanca al escuchar el “pair programming”, y soltaba alguna frase típica del “management troglodita” del tipo a… “eso es que uno de los dos que están en el mismo ordenador no trabaja”, ya puedes imaginar la cara que se le va a quedar al escuchar el Mob Programming.
Un solo y único PC para programar (lo que es extensible a hacer cualquier trabajo intelectual, diseños, informes, libros, etc.) y, como ya somos muchos, y no sólo dos, un proyector que muestra a todos lo que hay en la pantalla.
Para que te hagas una mejor idea de cómo funciona, abajo te dejo un vídeo de una jornada de Mob Programming. El video es de Woody Zuill, uno de los que más están popularizando el tema, al que a falta de otra fuente asumo creador del término, y que te sonará del post de ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado.
También lo tienes en slideshare:
Me encantaría terminar este post contándote experiencias más cercanas, incluso propias, o de otros cercanos a mi entorno, o, al menos, con algún estudio sobre al eficiencia de esta estrategia, etc.
Pero no tengo tales datos. Quizá por la juventud de esta estrategia. El tiempo dirá.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
No se si en una empresa es más o menos útil, lo que me parecería muy util es su uso en educación.
Por ejemplo, en un curso de programación, uno o dos días hacer Mob Programming.
Pues va a resultar que hace 25 años teníamos prácticas parecidas a las que cuentas: de un equipo de cinco, uno a los mandos del terminal 3270 y tres revisando en pantalla y cediendo cada cierto tiempo el control al siguiente…
Razón para hacerlo así: se trataba de programar en ensamblador el comportamiento de un controlador (servidor se llama ahora) de la familia 4700 de IBM. Ese código, una vez probado exhaustivamente, se grababa en cientos de floppy disk que se enviaban a cientos de oficinas bancarias una vez (o dos, como mucho) al año.
No había margen de error, de ahí la revisión tan concienzuda del código. Y no solo para asegurar que no había fallos sino para tratar de hacer el código lo mas óptimo posible.
Todos están jubilados, menos yo: el último cpterm en activo. 😉
¡¡Qué interesante!! «No había margen de error, de ahí la revisión tan concienzuda del código. Y no solo para asegurar que no había fallos sino para tratar de hacer el código lo mas óptimo posible.»
Y… ¿viviste algún caso de error que hubo que arreglar rápido? ¿cómo se gestionaban los hotfix? en algún momento alguno habría seguro…