En el proceso de crecimiento de Buk donde se ha experimentado recientemente el aumento de contrataciones sobretodo en áreas de desarrollo, hemos podido recibir al mejor talento (estamos buscando siempre 😜) y a pesar de que nuestro proceso de onboarding se ha adaptado a este ritmo, hemos detectado oportunidades de mejora.
El caso para el presente artículo es el siguiente:
Cuando más de un integrante nuevo necesita ayuda con un problema similar, lo usual es hacer reuniones 1 a 1 para ayudarlos. ¿Pero qué sucede cuando esto se hace más frecuente?
Cuando encontramos un problema también vemos una oportunidad para mejorar. La siguiente pregunta fue: ¿Qué pasaría si hiciéramos una sesión colaborativa donde abordamos temas que puedan enseñarle a todo el equipo en una sola sesión y trabajando sobre un caso práctico (código que luego será mezclado a la rama principal)? Como en muchas otras situaciones, no fue necesario reinventar la rueda. Alguien ya se había enfrentado a una necesidad similar y fue así como encontramos Mob Programming.
Comenzamos a leer y descubrimos que formaba parte de la metodología de Extreme Programming propuesto por Agile Alliance el año 2014. En un primer acercamiento al Mob Programming hemos podido comprobar en carne propia las siguientes bondades:
- Esparcir más rápido el conocimiento en el equipo.
- Generar cohesión en el equipo.
- Generar empatía en cada integrante.
- Recuperar el trabajo colaborativo en modo WFA.
- Reforzamos el no tener vergüenza de equivocarse y programar en frente de otros (que es algo común en Buk).
Ahora vamos a profundizar un poco más en detalle acerca de la metodología.
¿Qué es el Mob Programming?
Básicamente una forma de programación donde un grupo de desarrolladores trabajan sobre la misma tarea o funcionalidad al mismo tiempo. Es muy similar a un Pair Programming pero con más participantes.
¿Y cómo funciona?
Lo primero es definir dos roles: driver (conductor) y navigator (navegante), los cuales irán rotando en el transcurso de la sesión. La principal tarea del conductor es tomar el teclado y “conducir” el avance del código, pero siempre siguiendo las indicaciones del navegante; el conductor no puede tomar decisiones de forma unilateral. Por su parte, el navegante tiene la responsabilidad de dar indicaciones explícitas al conductor como indicar qué y dónde debe escribir mientras escucha las opiniones del resto del equipo, y cuando hayan dudas de cómo continuar con el código, debe generar discusión para lograr un consenso y continuar avanzando.
¿Cómo lo implementamos en Buk?
Previo a la actividad:
- Se define la tarea sobre la cual se va a trabajar, idealmente un feature/tarjeta de tu sprint en curso.
- Se agenda una reunión con tiempo suficiente para el desarrollo de la actividad:
- ⏱ 5 o 10 mins. de contextualización y objetivo.
- ⏱ 10 o 15 mins. por cada participante.
- 🎙 Margen extra para discusión.
Por ejemplo: 4 participantes, 10 mins. de contexto, 15 mins. de código para cada uno, 70 mins. en total y se puede considerar un margen extra de 15 mins. para las discusiones.
Durante la actividad:
- Se presenta la tarea/feature sobre la cual se va a trabajar: se entrega el contexto, los casos de uso (si aplica) y cuál es el objetivo que queremos alcanzar. Esto es muy importante y deben quedar muy claros los alcances.
- Inicia un participante siendo conductor y otro como navegante.
- Con el contexto y objetivos ya conocidos, el navegante debe empezar a dar las indicaciones al conductor sobre lo que debe ir agregando o editando en el código. Recordemos que solo el conductor puede editar los archivos y siempre siguiendo las indicaciones del navegante.
- Los demás participantes aportan sugerencias al navegante y apoyan validando o levantando dudas que puedan aparecer mientras se avanza en el desarrollo del feature.
- Frente a dudas de cómo continuar la implementación es ideal que se pueda generar la discusión a nivel de equipo. Se deja de escribir código hasta que haya consenso y luego el navegante indicará al conductor cuándo retomar.
- El conductor puede participar de las discusiones, pero no puede escribir código por iniciativa propia, solo lo que el navegante le indique.
- Después de 10 o 15 mins. el navegante pasa al rol de conductor y otro participante pasa a ser navegante.
- Se repite el paso anterior hasta que todos participen en ambos roles.
- Los nuevos miembros del equipo participan de oyentes durante un tiempo, hasta que se sientan seguros para poder participar. Este punto es importante para evitar agregar dudas o confusión innecesaria a los nuevos miembros del equipo.
¿Qué necesitamos para nuestro Mob Programming?
- Timer: Cualquier reloj con timer servirá, pero un participante se debe encargar de controlar el tiempo e indicar cuando corresponda cambiar los roles y pausar cuando haya discusiones muy largas. Nuestro equipo en Buk usa Standup Timer App
- Editor de código en tiempo real: Cualquier editor que permite editar código de forma colaborativa en tiempo real servirá, en nuestro caso VS Code con Live Share o RubyMine con su funcionalidad de Code With Me han funcionado muy bien. Es importante que la herramienta tenga la funcionalidad para que los participantes puedan seguir el cursor del conductor y así estén todos en el mismo segmento de código todo el tiempo.
- Comunicación en tiempo real: es fundamental para poder llevar adelante las discusiones del equipo y las instrucciones que da el navegante al conductor. En nuestro caso Gather y Google Meet son nuestros aliados.
¿Y cómo ha sido nuestra experiencia de equipo?
Tomamos esta metodología para trabajar durante todos los sprints (una vez en cada sprint), donde abordamos una tarjeta de nuestro tablero de Jira. Decidimos hacerlo de esta forma para generar un hábito, lo que no quita la posibilidad de que exista Pair Programming entre desarrolladores.
Puntos que 👍🏻
- El trabajar tarjetas con casos de usos complejos ha ayudado a aumentar el conocimiento del equipo de forma transversal.
- Ha disminuido el tiempo de onboarding, ya que esta metodología le enseña de forma práctica a los nuevos miembros cómo trabaja el equipo.
- Los miembros con menos experiencia han perdido el miedo a programar frente al resto de sus compañeros.
Puntos que 👎🏻
- Dado que trabajamos sobre una tarjeta del sprint en curso, si en la sesión no participa al menos un miembro senior del equipo que sirva de soporte en el contexto de la tarjeta y/o funcionamiento de la aplicación se puede perder tiempo al iniciar con las primeras líneas de código.
- Es una sesión con un alto costo en tiempo (usualmente de 1 a 1:30 hrs. de cada integrante del equipo), pero creemos que es en el fondo es una muy buena inversión del tiempo de cada uno.
Conclusiones
Los beneficios e impacto de Mob Programming cobran especial relevancia para el equipo cuando contamos con un equipo diverso en seniority, tanto desde el punto de vista técnico como desde el conocimiento del negocio.
Atreverse a nuevas cosas siempre es un desafío y trae cierto esfuerzo adicional al inicio, pero desde nuestra experiencia vale la pena el esfuerzo cuando generamos instancias donde el equipo está trabajando, compartiendo y aprendiendo unos de otros y fortaleciendo la comunicación y relación del equipo.
