¿Cómo se gestiona la deuda técnica en Agilidad?

La deuda técnica se define según la wikipedia como:

"Deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware"

La deuda técnica también puede ser pensada como las tareas necesarias a hacer para que un trabajo pueda ser considerado completo. Si realizamos un cambio en una parte clave o crítica del código, puede existir la necesidad de hacer otros cambios coordinados al mismo tiempo en otras partes del código o en la documentación. Recordemos que estos últimos son necesarios, pero si no se realizan, se consideran deuda que deberá ser pagada en algún momento del futuro.

La deuda técnica
es como el ketchup
Cortesía de Pixabay

Ejemplos de deuda técnica:

• Código poco claro e ilegible
• La falta de pruebas automatizadas, construcción automatizada, despliegue automatizado y cualquier otra cosa que pudiera ser automatizada hoy en día y se haga manualmente
• La falta de calidad
• Código duplicado
• Arquitectura enmarañada y dependencias innecesariamente complejas
• Herramientas ineficaces y lentas
• Código no comprometido y ramas de larga duración
• Documentación técnica importante que falte o esté obsoleta
• Falta de entornos de test, y que estos no sean equivalentes al entorno de producción
• Ciclos de construcción-test largos
• Falta de integración continua

La deuda técnica es como el ketchup, si se elimina enseguida mientras está fresco sólo hacen falta un par de segundos de enjuague, mientras que si está resecado puede tomar minutos y múltiples intentos de friega intensa.

La deuda técnica crece y se complica de forma exponencial en el tiempo

Causas comunes que llevan a la deuda técnica:

• Las presiones comerciales: cuando la empresa prefiere obtener algo lo antes posible sin efectuar otros cambios necesarios se acumula deuda técnica de todo aquello que no se finaliza.
• Falta de comprensión del proceso: cuando la empresa acepta deuda técnica sin comprender el concepto ni sus consecuencias.
• La construcción de componentes fuertemente acoplados: por ejemplo cuando hay funcionalidades "hardcoded", cosas codificadas fijas que hacen que el software sea inflexible y que los cambios futuros sean costosísimos.
• La falta de pruebas automatizadas: que permitan reducir el riesgo, identificar y resolver bugs en caliente y dar soluciones rápidas.
• La falta de documentación: que resulta por la sobrecarga de trabajo de los equipos de desarrollo.
• La falta de colaboración: donde el conocimiento no es compartido por toda la organización.
• El desarrollo en paralelo de dos o más ramas en el gestor de versiones: estas pueden causar acumulación de deuda técnica debido a un trabajo divergente que cuando sea combinado de problemas de integración. Cuantos más cambios se hagan de forma aislada, más se acumulará la deuda técnica.

A medida que los requisitos de un producto evolucionan, comienza a quedar claro que algunas partes del código se vuelven más difíciles de mantener y deben de ser rediseñadas para soportar las nuevas necesidades. Cuanto más tiempo se demore en refactorizar y se siga escribiendo el código nuevo empleando el formato actual, hará que se acumule más y más deuda técnica.

Cinco cosas importantes a considerar para superar la deuda técnica:

• Involucrar al Propietario del Producto: Algunos Propietarios del Producto tienden a no entender completamente las necesidades y beneficios de la refactorización para pagar la deuda técnica, por lo que es importante que los equipos de desarrollo aprendan a transmitir el impacto de la deuda técnica en el producto y de como les afecta en su trabajo. La forma más sencilla de transmitirlo es hacer hincapié en la importancia del crecimiento continuo del producto (manteniendo el rendimiento a corto plazo y la salud a largo).
• Definir la regla para la "buena" deuda técnica: Hay situaciones en que la deuda técnica es necesaria en un primer momento, por ejemplo si hay un hito a la vista. En todo caso hay que resolver la deuda técnica adquirida cuanto antes una vez haya pasado el punto crítico.
• Visualizar y estructurar la deuda técnica: inventariar todas las aplicaciones/módulos y crear historias técnicas con las cosas pendientes en cada una de ellas para incorporarlas después a la pila de producto. Esto ayudará a entender la forma que tiene la deuda técnica en cada aplicación.
• Estimación y priorización de la carga de trabajo y elaborar una estrategia: Comprender el esfuerzo necesario para pagar la deuda técnica ayudará al equipo a crear un plan de pago de la misma y que el Propietario del Producto pueda incorporarla en la pila de producto.
• Integración al proceso existente: Siguiendo los pasos anteriores se estará en disposición de reducir la deuda técnica, lograr un consenso entre el equipo y el Propietario del Producto permitirá extraer políticas explícitas propias del equipo.

Si un equipo decide reducir su deuda técnica actual les recomiendo que visibilicen su decisión en una frase que pueden imprimir en un banner:

Vamos a dejar de escribir Código Basura,

y limpiaremos Gradualmente el Código Viejo

Mis agradecimientos a Erich, quien sin saberlo y a través de un texto que escribió, me inspiró a escribir este post.