Hace tiempo que hablábamos en el blog del #MobProgramming o si soléis pasar por aquí quizás recordéis que participé hace un año en dando una pequeña charla en el Meetup Madrid Management 3.0 (aprovecho para animaros a que os apuntéis, os dejo el link) donde hablaba de #MobProgramming desde la experiencia de 233 Grados de TI.
Haciendo un remake de los post escritos en el blog (#MobProgramming: caso de estudio y experiencias, Mob Programming: un único ordenador para todo el equipo (más allá del pair programming) ) como me gusta seguir aprendiendo me he basado en algunas preguntas que han surgido cuando hemos hablado de #Mobprogramming y he decidido volver a retomar el tema y compartirlo con vosotros.
Si no vais a acceder a los posts anteriores os explico brevemente que la técnica Mob Programming consiste en trabajar todo el equipo en lo mismo, en el mismo ordenador, al mismo tiempo y en el mismo sitio. Esta técnica fue popularizada por Woody Zuill.
Os dejo una foto de nuestro último MobProgramming, la imagen representa el resultado de trabajar con programación web para la PAM2016.
Veamos una pregunta que se repite con frecuencia…
¿Cuántas personas deben participar?
Bien, como en la mayoría de las preguntas, Woody Zuill y Kevin Meadows dicen que no hay una única respuesta. Esta decisión es de las personas que participan en la sesión y es tomada según si esa persona va a contribuir aportando conocimiento y la participación activa de cada uno. Cuentan que ellos han tenido sesiones de hasta 14 personas, pero que no existe un límite específico para las sesiones de #Mobprogramming.
Incluso nos cuentan que podemos utilizar “la regla de los dos pies” que se utiliza en los Open Space os dejo la descripción de esta regla según el originador del concepto de Open Space Harrison Owen “If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.” Concretamente aconsejan tener un espacio para que las personas se puedan ir a trabajar de forma individual y dejar la sesión de #MobProgramming si no están aprendiendo ni contribuyendo, pero permaneciendo cerca de la sesión por si es necesaria de nuevo su colaboración, siendo siempre la participación voluntaria.
Pero… te contábamos en los posts anteriores que Ron Jeffries decía en su cuenta de twitter algo así como si es tan productivo ¿por qué no metemos a todo el estado de Michigan a programar en un único ordenador?
Veamos entonces cómo escalar y nuevas tendencias de esta técnica.
Escalando el número de personas en #MobProgramming
Según Maaret Pyhäjärvi y Llewellyn Falco el número de personas participando en una sesión de #Mobprogramming podría ser 20 pero tenemos que tener en cuenta:
- El nº de rotaciones y el tiempo de rotación para que todas las personas que participen puedan pasar por el puesto del conductor del Mobprogramming, recuerda que la persona que es conductora es la encargada de manejar el ordenador, y las demás personas son los navegantes que irán ayudando e indicando al conductor). Argumentan que si tenemos 10 personas participando y el tiempo en el teclado son 4 minutos necesitamos 40 minutos, pero si son 20 o reducimos el tiempo en el teclado a 2 minutos y así necesitaremos 40 minutos, o necesitaremos 160 minutos.
- Si rotamos por eventos, por ejemplo rotamos cuando escribamos un escenario en Gherkin (te dejo un post sobre Gherkin Entendiendo qué es BDD (Behavior-Driven Development) (I) ) o cuando pase un step en Calabash (puedes ampliar el conocimiento sobre Calabash con el post Pruebas automatizadas para aplicaciones móviles: Calabash for dummies (1/2)) o cuando escribo un método en Android.
Nosotros cuando empezamos a utilizar la técnica #MobProgramming utilizábamos el tiempo para rotar, pero hoy día utilizamos los eventos, según sobre lo que estemos trabajando.
#MobProgramming con audiencia
Esta nueva forma de aplicar la técnica Mob Programming nos explican Maaret Pyhäjärvi y Llewellyn Falco que es igual que el Mob programming básico. Teniendo en cuenta que las personas pueden unirse o salir cuando quieran a la sesión, con la condición que cuando te unes te tienes que sentar detrás del conductor, es decir, como ponerte el último en la fila de los navegadores, para no “colarte” en el turno rotativo de cada participante en cuanto al puesto de conductor. La audiencia puede dar ideas a los navegadores al igual que participar en las retrospectivas del Mob programming. También en esta nueva forma de utiliza #MobProgramming contamos con la figura de un facilitador.
Os dejo una imagen para que os hagáis una idea de una sala que este utilizando esta nueva tendencia de MobProgramming.
La verdad es que nunca he probado esta alternativa, me resulta curiosa en el sentido de vivir esta experiencia, ojalá y pronto tenga la oportunidad de probarla. Veo esta forma de utilizar Mob programming muy útil para talleres o conferencias con un amplio aforo de personas.
#MobProgramming de forma remota
Hay herramientas como las que utilizamos para las reuniones de Scrum de videollamada como Skype o Hangouts que nos permitirían hacer estas sesiones. El problema de esta tendencia de #MobProgramming es la diferencia horaria por lo menos en nuestro grupo de trabajo, hasta la actualidad no hemos encontramos un periodo de tiempo en el que podamos hacer una sesión completa de #MobProgramming, pero sí que es verdad que hay equipos que lo logran como el de Woody Zuill.
Concluyendo…
Cómo otros temas que tratamos el número de personas que deben participar consiste en probar e ir ajustando en cada sesión de #MobProgramming y del equipo. En nuestro equipo las mejores sesiones de Mob Programming han sido con menos de 9 personas.
Para terminar os dejo las diapositivas que utilicé en la Jornada Peopleware and Agile Management del 2015 para explicar #MobProgramming desde la experiencia, espero veros por la segunda edición de esta jornada (podéis reservar vuestra inscripción aquí).
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024