Mob Programming

En mi corto recorrido por el mundo laboral he podido experimentar de primera mano trabajar en Pair programming y en ocasiones en Mob. Lo primero que se te pasa por la mente es pensar que el trabajo saldría más rápido si cada programador hiciese su tarea individualmente. Sin embargo dependes del trabajo de los demás para saber cómo funciona el software que están desarrollando entre todos.

Beneficios

El juntar a varios miembros del equipo trae más beneficios que inconvenientes, dejo a continuación algunas de las más relevantes para mí:

• Mientras 1 programa, la otra persona revisa por si me he despistado y he escrito algo mal que el IDE no me notifica
• Se pueden debatir las ideas y escoger la que más se acerque a lo que buscamos
• Se forja un compañerismo propio de un equipo y dejamos de lado el estereotipo de que l@s programdor@s nos aislamos. Además nos ayudar a comunicarnos mejor.
• Se pueden alternar roles de driver y navigator y así evitar poner el “piloto automático”
• Se aprende recíprocamente y se complementan conocimientos (Lo que no sepas hacer tu podría saberlo yo y viceversa)
• Reduce tiempo de feedback al preguntar directamente a la persona y no tener que levantarme a la mesa de mi compañero/a a preguntar cada 2 por 3 si lo comparamos con realizar tareas individuales.
• Te aporta nuevas formas de pensar

Todos hemos escuchado el dicho “4 ojos ven mejor que 2” o “2 cabezas piensan mejor que 1”. Pues se aplica exactamente igual cuando practicamos Pair/Mob. Podemos estar tranquilos de no meter la pata e ir por un camino equivocado ya que se ponen todas las ideas sobre la mesa y escogen la más adecuada al problema que van a resolver.

De la mano al Pair/Mob va el testing, término muy importante que no todo el mundo aplica en sus desarrollos y que provoca que un programa sea un infierno mantenerlo y/o actualizarlo. Estas metodologías al practicarlas diariamente en grupo van evitando futuros dolores de cabeza y te avisan cuando algo que se ha modificado puede romperlo todo. Ayuda mucho a localizar el problema cuando fallan cosas y no sabes ni por donde empezar (Con un programa de 100 líneas no hay problema, pero cuando trabajas con 1 millón ya no nos reímos tanto :laughing: )

Una cosa que comenta Carlos en los episodios y creo que es de vital importancia es que si tomas el rol de navigator, deja que el driver termine de sacar la idea de su cabeza y, a poder ser, evita interrumpir su flujo de pensamiento. Ya luego cuando haya una pausa le comentas la idea o la sugerencia que se te vino a la mente (anótala para que no se te olvide).

Si se da el caso en Mob programming, es mejor debatir primero la idea y no ir soltándolas de golpe porque el driver se va a saturar y llegará el punto en el que no sabrá qué escribir ni qué idea era la que tenía que implementar.

Conclusión

A modo de conclusión y por no soltar más la chapa, hay muchos más beneficios que inconvenientes a la hora de practicar Pair/Mob. Usar estas metodologías no nos libra de tener que realizar trabajo individual, pero sí nos facilita mucho más el aprendizaje y optimiza muchos aspectos tanto individuales como profesionales.