Cómo gestionar la deuda técnica

¿Qué es entonces una deuda técnica?

Hay muchas definiciones que puede encontrar fácilmente en la web. Algunos de ellos son muy limitados, como el de Wikipedia : “La deuda técnica (también conocida como deuda de diseño o deuda de código) es un concepto en el desarrollo de software que refleja el costo implícito de retrabajo adicional causado por elegir una solución fácil (limitada) ahora. en lugar de utilizar un enfoque mejor que llevaría más tiempo”. Algunas son muy amplias y dividen la deuda técnica en varias categorías como: Código, Diseño, Documentación, Defectos, Tecnología, Negocios, etc.

En este artículo me gustaría considerar la deuda técnica como una diferencia entre el estado actual de un sistema y el sistema ideal, teniendo el mismo conjunto de funcionalidades.

Independientemente de la definición que se utilice, creo que hay una cosa con la que todos estarían de acuerdo: cuanto más deuda técnica tengamos en el sistema, mayor será el coste de su mantenimiento y desarrollo posterior. Al presentarlo en un gráfico, se verá como se muestra a continuación:

En este sistema, el costo de eliminar aún más la deuda técnica es mucho mayor que el de agregar nuevas funciones. Por lo tanto, es aconsejable centrarse en nuevas funciones que brinden valor comercial a los clientes a corto plazo. Por supuesto, agregar nuevas funciones creará una nueva deuda técnica (documentación faltante, cobertura de prueba inferior a la esperada, algunos atajos en el código, etc.) que a su vez disminuirán un poco nuestra calidad. Entonces nos moveremos en consecuencia a las flechas verdes.

En segundo lugar, suponiendo que tengamos un sistema de baja calidad:

En dicho sistema, el costo de eliminar la deuda técnica es menor que el de agregar nuevas funciones. Por eso es bueno centrarse en mejorar la calidad del sistema (disminuyendo la deuda técnica), lo que aumentará nuestra capacidad de desarrollo en el largo plazo. La disminución de la deuda técnica mejorará la calidad y reducirá el costo del desarrollo de nuevas funciones (nuevamente, muévase en consecuencia a las flechas verdes).

Conclusión

Después de combinar estas dos decisiones (invertir en el desarrollo de nuevas funciones o en la calidad del sistema) en un gráfico, notará que oscilará cerca del punto de cruce.

Cuando el costo de agregar una nueva función es demasiado alto, cambia la prioridad y se concentra en la calidad (eliminando la deuda técnica). Cuando el costo de nuevas mejoras de calidad es demasiado alto, se cambia el enfoque hacia el desarrollo de nuevas funciones.

El equilibrio entre los objetivos a corto y largo plazo (ofrecer nuevas funciones versus invertir en calidad) es crucial. El mejor enfoque es trabajar en nuevas funciones y calidad simultáneamente.

Teniendo en cuenta que cada nuevo desarrollo aumenta la deuda técnica, siempre se debe recordar y trabajar en la calidad al mismo tiempo. Si tienes el equilibrio adecuado, tu oscilación será muy estrecha, tal vez no se note: siempre estarás en el punto de cruce. Si no tiene equilibrio, perderá tiempo, esfuerzo y se concentrará en cambiar entre calidad y nuevas funciones. Los síntomas que lo demuestran pueden ser: desarrolladores luchando por iniciativas de calidad, refactoring o Sprints técnicos, fases de estabilización y similares.

¿Cuál es mi nivel de deuda técnica?

Como probablemente habrá notado, para una gestión adecuada de la deuda técnica es necesario saber dónde se encuentra: cuál es su nivel de deuda técnica y cómo está cambiando.

Sin el conocimiento adecuado no podrás encontrar el punto de cruce y atenerte a él.

Le recomiendo encarecidamente que realice un breve taller con el equipo de desarrollo, centrado en definir métricas adecuadas para la medición de la deuda técnica.

Articulo escrito originalmente por Krzysztof Liszewski en su blog 4agile.pl