Una pregunta común de las entrevistas para rol de lead es "¿Cómo manejas la deuda técnica cuando hay presión de productos?"
Para empezar, no creo que haya una respuesta correcta. Probablemente el entrevistador solo quiere saber cuál sería nuestro criterio técnico, qué aspectos tomamos en cuenta en la toma de decisiones o cuál ha sido nuestra experiencia.
La deuda técnica es inevitable
No conozco la manera de tener CERO deuda técnica en un proyecto. Así como la vida: nada es perfecto. Por esta razón, el problema no es que haya deuda técnica sino que no haya visibilidad, ni registro o plan de ataque.
Si sumado a lo anterior tenemos un proyecto con fechas ajustadas, un equipo pequeño, criterios técnicos débiles, información incompleta o desconocimiento del negocio, es muy probable dejar una deuda técnica mayor. Esto no es un fracaso, sino que es una realidad del proceso de desarrollo de software.
En mi experiencia, aunque requiera más tiempo, se debe documentar el contexto que se tenía a la hora de tomar una decisión específica, qué otras alternativas había y porqué se eligió por encima de las demás. Luego, creamos un ticket, se etiqueta como deuda técnica y se deja en el backlog (con referencia hacia la documentación antes mencionada) para que el equipo entienda qué se hizo y por qué.
El famoso "sprint de refactor"
Después de acumular mucha deuda técnica, el equipo empieza a quejarse y no falta el que propone hacer un sprint (o más) entero dedicado a limpiar todo.
Solo una vez en mi vida vi cómo se aprobaba esta iniciativa, pero en realidad esto casi nunca funciona. El negocio difícilmente va a aprobar detener la producción por dos semanas sin entregar nuevas funcionalidades. ¿Cómo puedo medir el alza en productividad? ¿Cómo sé que el refactor fue efectivo y ahora el equipo se mueve con más velocidad?
En mi experiencia, creo que funciona mejor integrar la deuda técnica dentro del flujo normal. Cuando estimamos una tarea, si hay deuda relacionada que va a afectar el trabajo, eso entra en la estimación. NO SE PUEDE DISCRIMINAR como "refactor extra", sino que hace parte del costo real de la tarea.
La regla del boy scout aplicada al código
Robert Martin siempre habla de un principio simple: "Deja el código un poco mejor de como lo encontraste". La idea básicamente consiste en que no tenemos que refactorizar todo de golpe, sino que podemos hacerlo poco a poco.
Si entro a un archivo a hacer un fix y noto que hay un método con lógica duplicada: construyo una prueba automatizada y lo limpio de paso. Si hay un nombre de variable confuso: lo renombro. Hay muchas cosas pequeñas que individualmente no cambian mucho pero que en el tiempo van mejorando la salud del proyecto.
En cierto proyecto, la cobertura de las pruebas sobre el código era MUY BAJA, así que traté de promover una iniciativa "en segundo plano" con los desarrolladores: ¿qué tal si en cada MR o PR de un feature o fix, incluimos al menos una prueba automatizada de una funcionalidad que no tenga nada que ver con lo que estemos haciendo? Y si hay una región del código crítica sin una prueba, ¿qué tal si nos enfocamos allí? De esta forma podríamos aumentar poco a poco la cobertura de las pruebas con un costo muy bajo.
Todo esto no reemplaza el trabajo más profundo en piezas críticas, pero ayuda a que la deuda no crezca sin control.
Priorizar no es fácil
No toda deuda técnica tiene el mismo impacto. Hay cosas que molestan pero que no afectan la velocidad del equipo ni la estabilidad del producto y hay otra sque son un bloqueo silencioso que frena todo lo que tocamos.
Si al empezar un sprint o sesión ad-hoc evaluamos una región del código y se determina que 1) se toca mucho y 2) causa mucho dolor HOY, entonces se puede tomar una decisión bastante informada sobre la necesidad de refactorizar esa región.
¿Qué pasa si necesito rediseñar un módulo grande de mi sistema?
Rediseñar un módulo entero no es lo mismo que refactorización que se puede llevar a lo largo del mismo proceso de desarrollo.
Edgar Bonilla, un excompañero de trabajo, me dio una analogía para este caso:
El codebase es como un camión. Haces una inversión inicial para comprarlo, trabajas con él y con el tiempo le hacen falta reparaciones. Periódicamente lo llevas al taller, le hacen mantenimiento preventivo y lo sigues usando. Pasados unos diez años te das cuenta que en el mercado hay otros camiones más eficientes, más veloces o que tienen otras funcionalidades. Aquí no hace falta llevar el camión a mantenimiento, sino que debes comprar uno nuevo. Eso mismo le pasa al software: a veces simplemente hay que reconstruirlo, modernizarlo.
Esta discusión es la parte más difícil de llevar con el negocio. Cuando hay presión para entregar, la conversación de "necesitamos tiempo para reconstruir una parte del sistema" se siente como una batalla, y el negocio solo va a escuchar cuando le toques el bolsillo: ¿Cuánto tiempo más tarda agregar esto? (velocidad) ¿Qué tan probable es que la aplicación falle? (riesgo)
Algo así puede funcionar: "Si seguimos sin atender este módulo, cada feature que toque esta área va a tardar el doble de que debería. Podemos seguir así dos o tres sprints más, pero después ese costo se va a ver en los tiempos de entrega"
Conclusión (si es que la hay)
No existe fórmula exacta para esto. Cada equipo, cada producto y cada empresa tiene sus propias presiones. Lo más importante es hacer la deuda visible y buscar maneras para atacarla sin parar del todo.
Y tú, lector, si llegaste hasta acá quisiera saber cómo lo manejas en tu equipo de trabajo. ¿Qué te ha funcionado? ¿Crees que podría hacer algo diferente?
Top comments (0)