Al final la aventura de Rollbox duró 4 meses… Resulta irónico que la aventura haya acabado justo cuando publiqué el post sobre Rollbox.
Ha sido un final inesperado. Si es inesperado está claro que una de las partes no ha hecho bien su trabajo. Ahí lo dejo…
Igual que comenté todo lo bueno de Rollbox (que lo sigo manteniendo y creo les irá bien), también tengo que comentar que tienen un proceso de terminar una relación laboral muy mejorable, IMO claro…
Para mi ha sido una decepción, pero en el plano personal. Los detalles me los guardo también en ese plano.
Al final no ha habido encaje, y viéndolo en retrospectiva considero que hicieron un ‘spike’ que no funcionó. IMO no están preparados para este puesto en el momento actual. Me guardo también los porqués.
Que hemos conseguido en este tiempo
Bueno vayamos a las cosas buenas…
Siempre cuando empiezas quieres correr mucho, pero aun sabiéndolo cuesta a veces asumirlo y toca pisar el freno. A mi me ha tocado pisarlo… Al final tienes que ir dejando que el equipo vaya poco a poco incorporando cambios. Cada equipo tiene su propio ritmo.
Luego hay otras cosas que simplemente no ha da dado tiempo de mejorar, o que incluso se han quedado a medias, como hacer uso en toda la base de código de structured logging. Integré ougai.
Veamos que cosas si que hemos conseguido en este tiempo…
Un flujo de trabajo más agile/lean.
Se pasó de un flujo de asignación de tareas a ‘recursos’ a un flujo mas agile. Implementamos un Scrumban con sprints de 1 semana. Como ya he vivido en el pasado afinar el flujo es algo que requiere bastante tiempo… En estos 4 meses iteramos bastante sobre él, y todavía quedaba trabajo ahí. Los sprints de una semana son muy demandantes a nivel de producto, y estaba pendiente reforzar esa parte del equipo.
Como herramienta usamos Jira.
En la última etapa se crearon dos tableros más. Creamos un par de squads temporales teniendo cada uno su tablero. 3 squads == 3 tableros.
Definir roles de soporte/oncall
Básicamente el role de soporte se encargaba de ayudar el equipo de operaciones para resolver incidencias que ellos no podían resolver. El role de oncall (en horario de oficina) se encargaba de monitorizar que todo funcionaba correctamente y no había problemas en el sistema.
Se oficializó el tener un role de soporte (que también se encargaba del oncall) rotativo. Esto nos permitió:
- Repartir esa carga de trabajo (muy alta). Quien no estaba en soporte podía focalizarse en desarrollo. Aún así a veces incluso el resto del equipo tenía que echar un cable.
- Extender el know-how. Al comienzo incluso tuvimos a dos personas, uno de los nuevos en oncall y uno de los veteranos de apoyo.
Como soporte era muy demandante, no se estaba prestando la atención necesaria al oncall. Mi última decisión fue separarlos. El de oncall, realmente era poco demandante, y se podía realizar durante el trabajo normal de desarrollo.
A mi personalmente me gusta tener oncall explícito porque siempre hay gente muy dispuesta a ver como están las cosas, pero hay gente a la que le cuesta… Al final lo acaban haciendo siempre los mismos. Con roles explícitos te quitas ese problema…
Hacer funcionar muy bien el remoto
Esto fue muy fácil. Justo tras mi incorporación se incorporaron dos personas en remoto 100% y con experiencia previa ya en remoto. Para las reuniones internas empezamos a usar Zoom.
Pasamos a usar la regla de ‘uno remoto todos remotos’. Definimos un ‘draft’ de buenas prácticas.
Una cosa que hicimos y que cuando estabas en remoto molaba, era la posibilidad de ver la oficina. Pusimos un portatil que no estaba en uso con un meet permanente apuntando a la ofi.
Conseguir más compartición de conocimiento
Como ya he comentado, el definir el rol explícito de soporte ayudó. El otro factor clave fue crear diferentes diarios (en orden de mayor a menor contenido): Soporte, Desarrollo e Infraestructura.
Soy muy fan de los diarios por dos motivos:
- Es una documentación informal
- Al ser un diario la ‘deprecación’ se asume, por lo que te quitas de un plumazo la responsabilidad de mantener documentación
Quedó pendiente el usar Incident Reports. Pero como ya he comentado la parte de oncall tenía muy poco trabajo y uno de los silos existentes era infraestructura.
Aparte de infraestructura, sólo había un silo más, que explícitamente pospusimos abordar por falta de capacidad para hacerlo (en el momento actual).
Hacer uso de docker en el entorno de desarrollo
En producción ya se usaba pero en desarrollo no. Fue un cambio sencillo.
Aquí quedó trabajo por hacer en toda la parte de generación de imágenes para producción, pero no era el momento de abordarlo…
Mejorar la consistencia de la base de código (introducción de linter)
Empezamos a usar Rubocop.
Al ser una introducción tardía y una base de código muy grande, nos tuvimos que limitar a meter sólo reglas de Layout (e incluso no todas).
Nos fue muy útil que la propia herramienta sea capaz de cambiar el código para hacer cumplir las reglas. ¡Pero ojo! Hay algunas construcciones de Ruby que con cambios automáticos pueden provocar errores, lo que nos llevó a evitar algunas reglas, ya que habría que hacer los cambios manualmente.
Mejoras en los tests
Reducir el número de Test Fixtures en DB
Este es un trabajo al que dediqué bastante tiempo al principio y quedó sin acabar. Eso si, las fixtures más costosas se eliminaron.
El problema de usar un framework es que es muy fácil acoplarse a la BD y es muy intuitivo el tocar la BD en los tests unitarios. Eso hay gente que lo ve bien, y gente que no… Lo que sí que es innegable es que la suite de tests es más lenta…
Lo que hicimos fue hacer más explícito que datos se usaban en los tests y evitar cargar fixtures (costosas) al comienzo. El trabajo consistió en reemplazarlas por el uso de Factory Bot.
Eliminar Broken Windows
Otra cosa que hice, fué cargarme todos los tests que estaban ‘skipeados’ y eliminar prints o sustituirlos por trazas de nivel info del logger.
Cuando ves una salida ‘sucia’ y sobre todo cuando hay tests que no se ejecutan no te sientes culpable por ‘dejar mierda’. Cuando tienes el entorno limpito, si lo ensucias te sentirás culpable, y cantará mucho.
Crecer el equipo
Cuando yo empecé el equipo se duplicó, pasando a ocho. Coincidiendo con mi marcha se incorporaron un par de personas (una remota 100%).
Conseguimos estar en un estado de volver a crecer gracias a que todo el mundo incorporado cuatro meses atrás ya era productivo al 100% creo que principalmente a cómo hemos logrado la compartición del conocimiento.
Cualquier miembro del equipo puede hacer el trabajo de acompañar a las nuevas incorporaciones.