El 1° de abril de 2024 comencé a trabajar en una nueva empresa. Esta empresa tiene un mercado en expansión, pero su producto tecnológico no está orientado al usuario final, sino a los usuarios internos, lo cual me resulta un tanto curioso, ya que es más sencillo predecir su comportamiento y en caso de fallo, no afecta a tantos usuarios.
Al ingresar a esta empresa, noté que enfrentan numerosos problemas, principalmente en cuanto a buenas prácticas de desarrollo, uso de metodologías ágiles e infraestructura.
Cuando se desea desarrollar algo, el dueño de la empresa indica al equipo qué hacer y se involucra mucho en diferentes partes del proceso, lo que hace que la persona encargada realmente pierda su autoridad. Los desarrolladores prefieren hablar directamente con el dueño, quien deja muchos detalles de lo que se quiere realizar al aire, lo que hace necesario usar la intuición para completar las tareas, con el riesgo de que al final no sean lo que se esperaba. Además, el dueño cambia las prioridades del equipo con mucha frecuencia, lo que lleva a que lo que se planeó trabajar en tres días o menos deje de ser prioritario. Todo debe pasar por su autorización, lo que ralentiza los procesos de implementación de cambios.
El equipo afirma que utilizan Scrum, pero solo llevan a cabo tres de las cinco ceremonias (daily, planning y review), dejando fuera el refinamiento y la retrospectiva. El encargado tampoco tiene una clara comprensión de estas ceremonias, lo que lleva a que las realicen de forma improvisada. Según lo que me han contado y lo que he visto, las dailys parecen más una reunión donde el encargado cambia las prioridades del día, y la review se convierte en una sesión de planificación para ver qué se trabajará en los siguientes 15 días.
El equipo carece de una guía en cuanto a buenas prácticas de desarrollo, lo que hace que cada uno haga lo que cree correcto. Esto resulta en códigos escritos de manera inconsistente en el mismo proyecto, numerosas ramas en el repositorio de git cuyo propósito ya no se recuerda, archivos transpilados en el repositorio y variables de entorno también incluidas, entre otras cuestiones.
En cuanto a la infraestructura, han optado por un enfoque más tradicional, utilizando servidores en AWS para ejecutar sus APIs y entregar el frontend. Sin embargo, cada servidor aloja varios proyectos, lo que significa que si uno falla, todos los proyectos se ven afectados. Sus despliegues consisten en conectarse al servidor, hacer un pull y reiniciar las aplicaciones, lo que puede ocasionar problemas si algún paquete de node en el archivo package.json no está actualizado. También tienen una instancia de base de datos muy grande para sus necesidades (2xlarge), incluso teniendo menos de 100 usuarios, lo que parece deberse a malas indexaciones en las bases de datos. Además, carecen de conocimientos sobre pruebas y de un proceso de CI/CD.
Este es el panorama con el que me encuentro en mi nuevo trabajo. Son muchos desafíos, pero el reto es interesante.
Las primeras acciones que estoy tomando se centran en establecer acuerdos con el Product Owner para adoptar Scrum de manera adecuada y mejorar la elaboración de las historias de usuario. Con el equipo, planeamos realizar una limpieza de los repositorios y aplicar una estandarización en la escritura de código utilizando "Standard.js". Además, estamos explorando extensiones en VSCode para mejorar la claridad en el desarrollo.
En cuanto a la infraestructura, estoy llevando a cabo investigaciones para identificar mejoras que puedan representar cambios significativos pero que sean simples de implementar. La primera acción fue activar el Performance Insights de RDS y realizar la indexación de dos columnas en una base de datos, lo que resultó en una reducción del 50% en el uso de la CPU del servidor.
Tengo previsto implementar un sistema de pull request en GitHub antes de que finalice esta semana, con la esperanza de tener la estrategia "ship-show-ask" en todos los repositorios antes de que termine el año.
Top comments (0)