Pages Menu
Categories Menu

Posted by on Nov 10, 2014 in General | 3 comments

Mob Programming: un único ordenador para todo el equipo (más allá del pair programming)

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á.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

3 Comments

  1. 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.

  2. 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…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This