Ejecutar experimentos para mejorar nuestros procesos forma parte de nuestro trabajo diario. Por eso, cuando oigo hablar de algo que podría ayudarnos a mejorar, quiero investigarlo. A principios de 2019, me uní a la convención Domain Driven Design Europe. Durante los descansos, charlé mucho con otros participantes, en su mayoría desarrolladores.
En muchas de estas conversaciones, salió a colación el taller Programación Mob de la convención de un año antes. Los desarrolladores estaban muy, muy entusiasmados con la programación en grupo: varios desarrolladores trabajando en la misma sala en un único PC. Explicaron lo mucho que habían aprendido y crecido como equipo gracias a esas sesiones. Esa fue una señal clara para que yo aprendiera más sobre el tema. Después de eso, decidí que experimentaríamos con ello.
Una parte vital de un experimento es la hipótesis. Sin ella, no se sabe si el experimento ha tenido éxito. Mi teoría era que el mob programming nos ayudaría a compartir conocimientos entre desarrolladores a la vez que construíamos código limpio.
Planifiqué y preparé nuestra primera sesión de programación de la mafia, que no fue tan difícil:
Consigue un ordenador conectado a una pantalla grande
Coloca una mesa delante de la pantalla.
Añade cinco asientos a la mesa.
Coloca algunos aperitivos y provisiones en la mesa.
Consigue un ordenador conectado a una pantalla grande.
Y allí estábamos, cinco desarrolladores en una habitación con un solo ordenador:
¿Qué ocurrió durante nuestra primera sesión de programación de la mafia?
Wesley se sienta cerca del teclado (estamos utilizando su PC) y se le asigna automáticamente el papel de conductor. El conductor es un dispositivo de entrada inteligente: puede escribir pero no puede tomar decisiones. Los demás desarrolladores tienen el papel de navegador. Son ellos los que discuten lo que debe ocurrir y le dicen al conductor lo que debe hacer.
El conductor es un dispositivo de entrada inteligente: puede teclear pero no puede tomar decisiones.
Empezamos a trabajar en una simple historia de calentamiento en la que tenemos que eliminar algunos contenidos obsoletos en el pie de página del sitio.
Los navegadores le dicen a Wesley que inicie Docker. Inmediatamente aparece un mensaje de error. Wesley explica que esto ocurre a veces, pero siempre se soluciona con un par de reintentos. No reintentamos, pero los navegantes nos explican qué ajustes cambiar. A partir de ahora, Docker siempre arranca sin error;
Wesley escribe en una nota adhesiva lo que ha aprendido sobre Docker. Pone esta nota adhesiva en la hoja grande de papel llamada Aprendizajes.
Escribo en una nota adhesiva que el hecho de que Docker no arrancara nos estaba retrasando. Se la paso a la Serpiente de Residuos, una gran hoja de papel con una serpiente dibujada. En esta hoja, se ponen notas adhesivas describiendo todo lo que frena a la mafia a la hora de programar de verdad:
Después de 12 minutos, suena un timbre. Todo el mundo tiene que cambiar a la derecha. El conductor se convierte en navegante, y uno de los navegantes se convierte en conductor. Es un poco complicado, y lleva algún tiempo volver a ponerse en marcha. Pero lo hacemos mucho mejor después de un par de cambios.
Terminamos la historia y empezamos a trabajar en la siguiente: La vista Yii2 provoca comentarios falsos en HTML, lo que provoca la invalidación de HTML. Una historia interesante. Ya fue recogida dos veces por diferentes desarrolladores, pero ambas se atascaron. Todo el mundo se apunta a la historia. Al final, arreglamos el problema de una manera con la que todo el mundo está muy satisfecho.
Después de dos horas, la sesión termina.
¿Qué hemos aprendido en nuestra primera sesión de programación?
Hacemos una reunión retrospectiva para hablar de lo que ha ido bien y de lo que podemos mejorar. Lo más importante es que en una iteración hemos solucionado la historia mejor y más a fondo que si hubiera trabajado en ella una sola persona.
Arreglamos la historia mejor / más a fondo en una iteración que cuando una sola persona hubiera trabajado en ella.
Todo el mundo se siente lleno de energía durante la retrospectiva. A todos nos gustó el experimento. Resulta evidente que la programación en grupo nos ayuda a compartir conocimientos al tiempo que creamos código limpio.
La mayoría de los aprendizajes fueron bastante obvios, como cuando un acceso directo era desconocido para el controlador, o la configuración de herramientas para ayudarte de forma más eficiente. Se hizo evidente lo fácil que es añadir residuos a su propio proceso de desarrollo mediante el uso de soluciones si un sistema se comporta de forma inesperada. Esto confirma la necesidad de adoptar la Kata de Mejora.
Otros aprendizajes fueron más sutiles. Por ejemplo, encontrar formas de dividir un problema difícil en problemas más pequeños. O las sugerencias sobre cómo trabajar realmente Test Driven creando primero una prueba que falla en lugar de simplemente añadir una prueba después.
El experimento ha tenido éxito. La próxima sesión está prevista de inmediato
Una de las cosas más difíciles de hacer bien fue el nivel de comunicación entre los navegantes y el conductor. No hay que explicárselo todo, sobre todo a los desarrolladores más experimentados. Pero tampoco hay que dejar que un desarrollador más joven se sienta arrojado a lo más hondo. Con el tiempo, la multitud aprende a dirigirse a los conductores individuales de la manera correcta.
Programación de turbas a distancia
En los Países Bajos, estamos actualmente en un cierre patronal. Nuestra oficina está cerrada y todo el mundo trabaja a distancia. Esto hace que la programación en grupo descrita anteriormente sea imposible porque no podemos estar en la misma sala.
Sin embargo, seguíamos queriendo hacer sesiones de programación en grupo. Por ensayo y error, se nos ocurrió lo siguiente para una excelente sesión de programación remota:
Todo el mundo tiene una cámara web, y todo el mundo la enciende durante una sesión.
Utilizamos Whereby para alojar nuestras reuniones porque puedes compartir tu pantalla y seguir viendo las imágenes de la cámara de los demás.
El conductor inicia sesión en un ordenador dedicado a través de una conexión de escritorio remoto (creamos una cuenta de usuario mob en la red interna para esto).
Creamos una cuenta de usuario mob separada para Git. Esto hace que sea muy fácil cambiar los roles.
La cuenta de usuario de Git.
¿Cómo puedo experimentar con esto en mi propio entorno de trabajo?
De todos los artículos, blogs y libros electrónicos que he leído sobre programación para mafias, recomiendo encarecidamente la lectura de estos dos:
The Mob Programming Guidebook (recientemente rebautizado como Ensemble Programming Guidebook) de Maaret Pyhäjärvi.
Mob Programming - A Whole Team Approach de Woody Zuill.
Mob Programming - A Whole Team Approach de Woody Zuill.
Después, elige una fecha con tu equipo y pruébalo. ¡Que aproveche!
Descubre más de nuestros blogs
Caroline
"Me alegro mucho de que hayamos integrado la perspectiva del cliente en nuestro trabajo"
En nuestra serie de entrevistas, Easy LMS talks, pedimos a nuestros colegas que nos hablen de su trabajo. ¿Qué hace que su trabajo sea divertido y desafiante? Esta vez es el turno de Dyann’de hablar sobre la investigación de la experiencia del usuario.
Leer más
Caroline
Nuestras prestaciones de empleo secundario explicadas
Aunque el salario es un factor importante a la hora de elegir un trabajo, no debemos olvidar las ventajas que conlleva. Los beneficios adicionales pueden endulzar el trato. Y creemos que hemos creado un paquete fantástico. ¡Sumérjase en todos nuestros maravillosos extras!
Leer más
Caroline
¡Trabajar y progresar!
¡Trabajar para Easy LMS es gratificante! Por supuesto que proporcionamos un salario competitivo, viajes y permisos para trabajar desde casa y ¡25 días de vacaciones pagas por año! Pero también estamos orgullosos de ofrecerte beneficios que te ayudan a sentirte y a hacer lo mejor. Tu bienestar, físico y mental, ¡es una máxima prioridad! Porque nuestros empleados son la columna vertebral de nuestra organización.
Leer más