Qué es la deuda técnica y cómo saldarla (con ejemplos)

Trabajar en el ámbito de los productos suele requerir decisiones rápidas sobre las funciones del software. Si alguna vez trabajaste en un equipo de operaciones de desarrollo, sabes cuántas decisiones se deben tomar para poder implementar las funciones.

Deuda técnica es el término que se utiliza para describir el resultado de tomar decisiones basadas en la velocidad por encima de todo. Estas decisiones rápidas, en tiempo real pueden hacer o deshacer las actualizaciones de software. Pero tiene que haber un equilibrio entre las buenas decisiones y las rápidas. Incurrir en una deuda técnica puede traer resultados negativos o valer bien la pena; según lo que tú y tu equipo decidan. 

En este artículo, analizaremos la definición de la deuda técnica, cómo gestionar con eficiencia las decisiones rápidas en el proceso de desarrollo y además compartiremos ejemplos para que comprendas mejor cómo evitar futuros contratiempos.

¿Qué es exactamente la deuda técnica?

La deuda técnica es el costo del retrabajo adicional causado por la elección de la solución más rápida en lugar de la más efectiva. La deuda técnica es una expresión acuñada originalmente por el desarrollador de software Ward Cunningham en 1992, aunque el término ha evolucionado desde entonces.

Actualmente, la deuda técnica, también conocida como deuda tecnológica y deuda de código, suele producirse cuando los equipos de desarrollo optan por escribir código rápido al crear nuevas funciones de un producto de desarrollo de software. La entrega de un código rápido puede ayudar al equipo a cumplir con los plazos, y la deuda que se acumula puede valer la pena, aunque también podría conducir a resultados negativos si se gestiona de forma incorrecta. Estos resultados negativos no siempre se pueden evitar una vez que se toma la decisión de acumular deuda técnica. 

Ya sea que experimentes resultados positivos o negativos, analizaremos los datos importantes sobre la deuda técnica para que estés preparado para tomar las decisiones correctas en el momento que lo necesites.

¿Es mala la deuda técnica?

Al igual que la deuda financiera, la deuda técnica puede utilizarse tanto de forma positiva como negativa.

En algunas instancias, la deuda técnica es el resultado de un movimiento calculado para cumplir con los plazos del software y enviar código de alta calidad dentro de los sprints. En otras instancias, es el resultado de un error inevitable que se cometió al lanzar una actualización de software.

Los cuadrantes de la deuda técnica

Existen cuatro causas diferentes de la deuda técnica, denominadas cuadrantes de la deuda técnica. Los cuatro cuadrantes de la deuda técnica, acuñados por Martin Fowler, son: imprudente, prudente, deliberado e inadvertido.

La asignación de la deuda técnica a estos cuadrantes ayuda a medir la intención y los antecedentes de los problemas de código. Aunque algunas deudas de código pueden ser deliberadas y clasificadas como deuda buena, otras pueden ser inadvertidas y clasificadas comodeuda mala. 

1. Prudente y deliberada: La decisión de hacer una entrega rápida y lidiar con las consecuencias más tarde provoca una deuda prudente y deliberada. Este tipo de deuda, por lo general, se utiliza cuando lo que está en juego es relativamente poco y las ventajas de una entrega rápida superan el riesgo. 

2. Imprudente y deliberada: Saber producir el mejor código pero priorizar la rapidez en la entrega es la causa de la deuda imprudente y deliberada.

3. Prudente e inadvertida: La deuda prudente e inadvertida ocurre cuando se desea producir el mejor código, pero encuentras una mejor solución después de la implementación. 

4. Imprudente e inadvertida: La deuda imprudente e inadvertida ocurre cuando un equipo intenta producir el mejor código sin el conocimiento necesario para hacerlo. Por lo general, el equipo no es consciente de los errores que está cometiendo. 

Los equipos eligen la deuda técnica deliberada en pos de una entrega rápida, mientras que la deuda inadvertida es accidental, sucede después de la implementación. El ingeniero de software Steve McConnell explica mejor esta diferencia al describir los dos tipos generales de deuda técnica. Analicemos en detalle cada uno de ellos para comprenderlos mejor.

Tipos de deuda técnica

Steve McConnell, ingeniero de software en jefe en Construx Software, sugirió que hay dos tipos de deuda técnica: 

• Intencionada

• No intencionada

1. Deuda técnica intencionada

La deuda intencionada ocurre cuando una organización toma una decisión consciente de optimizar el presente en lugar del futuro.

Existen variaciones de la deuda intencionada a corto y a largo plazo. Por ejemplo, la deuda intencionada acumulada para pagar una deuda anterior es una deuda a corto plazo, mientras que una deuda intencionada acumulada para prevenir una deuda futura mayor sería una deuda a largo plazo.

Deuda a corto plazo: Esta deuda se contrae de forma reactiva, por razones tácticas, como la utilización de los recursos existentes. Además, la deuda a corto plazo puede ser focalizada o no focalizada.

• Deuda a corto plazo focalizada: Consiste en “atajos” individuales perfectamente identificables. 

• Deuda a corto plazo no focalizada: Consiste en numerosos pequeños “atajos”.

Deuda a largo plazo: Esta deuda se contrae de forma proactiva, por razones estratégicas, como el cumplimiento de un plazo.

Como puedes ver, el tipo de deuda acumulada determinará cuánto tiempo llevará saldarla.

2. Deuda técnica no intencionada

Por otro lado, la deuda técnica no intencionada ocurre debido a una falta de comprensión, errores accidentales o, en algunos casos, código mal escrito. Un ejemplo de deuda técnica no intencionada sería un enfoque de diseño que resulta ser propenso a errores. Es el resultado no estratégico de cometer un error inevitable.

Podemos asumir que la deuda técnica no intencionada es accidental, ya que el equipo no incurrió en ella a propósito. Lo más habitual es que recién te des cuenta del error después de implementar la actualización del software o finalizar el proyecto.

Cómo deshacerte de la deuda técnica

Si bien es posible acumular cierta deuda técnica de forma intencionada, muchos equipos de producto tienen dificultades para realizar un seguimiento y comunicar la deuda técnica. Esto puede provocar más trabajo del previsto cuando se trate de resolver las brechas en el código del software. 

Existen dos formas principales de gestionar la deuda técnica y crear una mayor transparencia en el lugar de trabajo en torno a la carga de la deuda. 

1. Mantener una lista de deudas dentro de un sistema de seguimiento: Cada vez que contraigas una deuda, ingresa las tareas necesarias para saldar esa deuda en tu sistema de seguimiento junto con un esfuerzo y cronograma estimados. Usa el backlog de la deuda para hacer un seguimiento del progreso de tu deuda técnica. Cualquier deuda no resuelta de más de 90 días debe considerarse crítica.

2. Mantener la lista de deudas como parte de un trabajo pendiente del producto de Scrum: Trata cada deuda como una “historia” de Scrum y estima el esfuerzo y el cronograma para saldar cada deuda; de la misma manera que lo haces con las otras historias en Scrum dentro de un backlog del producto.

Estos dos métodos pueden ayudarte a hacer un seguimiento eficaz de la deuda técnica y a deshacerte de la deuda de la manera más rápida y eficaz posible. Al igual que con el pago de una tarjeta de crédito, ambos enfoques te permiten pagar pequeños incrementos de la deuda hasta que el total general queda saldado.

Ejemplos y soluciones de deuda técnica

Ahora que ya conoces la gestión de la deuda técnica y algunas de las causas de la deuda intencionada y no intencionada, veamos algunos ejemplos de la vida real.

Ejemplo 1: Deuda técnica intencionada

• Descripción: El equipo elige un marco que es rápido de construir, con problemas de rendimiento conocidos y capacidades de funcionalidad mínimas.

• Solución: El equipo usa aplicaciones adicionales para la implementación posterior del software que cuenta con la funcionalidad que le falta al marco.

• Deuda: Aunque cumplieron con el plazo del producto, el equipo tendrá que rehacer las características después del lanzamiento y necesitará fondos adicionales. 

Ejemplo 2: Deuda técnica no intencionada

• Descripción: El equipo tiene muchos desarrolladores júnior que están ayudando con el lanzamiento de una nueva función del software con un plazo ajustado y no cuenta con la cantidad suficiente de desarrolladores sénior para revisar cada parte del código. 

• Solución: El equipo contrata un apoyo temporal adicional de desarrolladores sénior para que revisen el código y comprueben su correcto funcionamiento. 

• Deuda: Aunque el equipo detectó la mayoría de los problemas, la falta de comunicación entre el personal de tiempo completo y el de apoyo temporal hizo que se pasaran por alto algunos errores en el código. Esto significa que el equipo tendrá que depurar estos problemas después del lanzamiento. 

Como puedes ver, aunque son diferentes, tanto la deuda intencionada como la no intencionada tendrán que saldarse con el tiempo. Al pensar en una solución a la deuda técnica, puedes asegurarte de que las actualizaciones de software se lancen a tiempo y con poca deuda acumulada. 

Salda tu deuda técnica con transparencia

No siempre se puede evitar la deuda cuando se trabaja en el lanzamiento de un producto de software. Ya sea tener que tomar decisiones difíciles o errores en el código, los equipos ágiles saben de qué manera la cantidad de deuda técnica acumulada puede afectar a las actualizaciones del software. 

La clave para saldar la deuda es mantener y hacer un seguimiento de los pagos incrementales. Aunque el tipo de pago de la deuda es diferente en cada situación, la transparencia y la comunicación del equipo pueden ayudar a saldar la deuda más rápido. Esto se debe a que una mayor claridad en los proyectos ágiles puede facilitar una solución colectiva al problema en cuestión.