MOB PROGRAMMING: desarrollo de software en equipo

En esta ocasión vamos a hablar de Mob programming, una técnica de desarrollo de software que consiste en que un equipo de trabajo realiza la misma tarea a la vez. Esta técnica es recomendable para un equipo no superior a 6 ó 7 personas que se encierran en una sala con  un ordenador, un teclado, un ratón y un proyector.

Existen dos roles durante el desarrollo de esta forma de trabajo: conductor y navegantes. Mediante turnos de 15-20 minutos se va rotando en el equipo el puesto de conductor y el de navegantes. Los navegantes son los encargados de discutir, pensar, diseñar y guiar al conductor que es quien escribe lo que los navegantes le comunican.

Se trata de una técnica parecida a la programación en parejas (Pair programming), en la que 2 personas trabajan sobre la misma tarea y se van turnando el mando cada cierto tiempo, uno es navegante y otro conductor.

¿Qué nos permite Mob Programming?

En mi experiencia, dos equipos de trabajo en distintos proyectos han utilizado esta técnica y han escrito cada uno sus conclusiones. Sorprendentemente son muy parecidas.

• Alineación. Todo el equipo toma parte en el desarrollo.
• Reglas de codificación. Todo el equipo define normas de codificación y reglas de calidad de software.
• Aprendizaje, traspaso de conocimientos. Los programadores más junior aprenden más y mejor de los programadores más senior.
• Durante el desarrollo de esta técnica de trabajo se evitan reuniones de alineamiento, puesto que ya se está trabajando y desarrollando sobre la funcionalidad.
• Se evitan problemas de comunicación.
• Se evitan problemas de toma de decisiones, las toma el equipo al completo.

¿Cómo es posible que 6 personas trabajando sobre la misma tarea, sean más productivos que 6 personas trabajando cada uno en su tarea? La respuesta no es fácil, depende dónde se quiera llegar y de lo que se entienda por productividad.

Si lo que queremos es entregar funcionalidad de manera rápida, código de alta calidad, y alinear al equipo en conocimientos, ésta sería una buena forma de desarrollar, Mob programming nos puede ayudar. Por otro lado, si trabajamos con programadores desarrollando de forma paralela sobre una funcionalidad y queremos obtener velocidad, o debemos hacer una entrega crítica en un breve periodo tiempo, quizá sea el momento de utilizar Mob programming.

Si por el contrario lo que se quiere es avanzar en tareas de manera paralela, lo que tendremos seguro es un número mayor de líneas de código escritas por los programadores de manera individual, podremos tener calidad y alineamiento entre los miembros del equipo, pero hay que tener en cuenta que estos programadores están inmersos en su tarea de forma individual; la comunicación entre ellos no fluye de la misma manera.

Imaginemos un caso en que se va a desarrollar una funcionalidad muy compleja que afecta al dominio de la aplicación, el equipo es consciente del riesgo que hay que asumir y no tiene claro del todo las consecuencias. Entonces puede ser buen momento para que todo el equipo se encierre en una sala y, utilizando esta técnica, pensando todos sobre lo mismo, sean capaces de manera más rápida y con menos riesgos, poder realizar ese cambio que tanto puede afectar al futuro de la aplicación.

Otro caso, la creación de la arquitectura de una aplicación. Una fase que suele desarrollar gente más Senior y los Junior toman heredada y muchas veces no saben de dónde proceden las cosas y por qué. Se puede crear la arquitectura con todo el equipo cerrado en una sala, definir las capas que va a tener la aplicación. A partir de ese momento el equipo tiene un punto de partida para seguir desarrollando el aplicativo.

Por el contrario,  cuando los miembros del equipo tienen que trabajar sobre una tarea repetitiva que no tiene una gran complejidad, en este caso es mejor no utilizar Mob programming y que cada programador desarrolle su parte de código. Por ejemplo, si se van a generar clases parecidas a otras ya existentes.

No parece eficiente utilizar Mob programming para todo, hay tareas que por su constitución o por lo que se desarrolla en ellas, se avanza más rápidamente de manera paralela entre los miembros del equipo. O utilizando Pair programming, o demás técnicas que leamos o se nos ocurran. Hay gente que escribe sobre este tema, como el precursor de Mob programming, Woody Zuill, que defiende esta manera de trabajo. Véase por ejemplo este enlace.

En definitiva, podemos afirmar que Mob programming probablemente sea la manera de entregar funcionalidad de buena calidad en el menor tiempo posible.

¿Qué tal si alternamos durante los Sprint unas técnicas con otras y se va viendo la evolución y velocidad del equipo?

Para saber más sobre cómo Sogeti puede ayudarle en el desarrollo proyectos IT, haga clic aquí. 

Más información:

José Antonio González Romera es Técnico Superior en Desarrollo de aplicaciones informáticas, MCT Sharepoint Developer 2010 y MCPD Asp.Net Framework 3.5. Trabaja como informático desde el año 1999 y se incorporó a Sogeti en Abril de 2006 donde desarrolla aplicaciones para clientes de diversos sectores como sector público, museos, banca o aeronáutica.