Hablemos de Deuda técnica

Definición de deuda técnica

La metáfora de la deuda técnica nace de una frase originalmente acuñada por el desarrollador de software, Ward Cunningham[1], para explicar a los “no técnicos” la necesidad de «refactorizar». Como las metáforas son inherentemente abstractas, la verdadera definición de deuda técnica depende de la interpretación. Por lo que, a lo largo de los años, varias personas han desarrollado sus propias definiciones personales a lo largo de los años. Lo que ha llevado por ejemplo a malas interpretaciones que existen en muchas organizaciones, al confundir la deuda técnica con el Carry-Overs (La deuda técnica no incluye ignorar o retrasar cosas como funcionalidades, que intencionalmente no se construyeron).

Una de las expresiones mas utilizadas para estas es: “La deuda técnica es el coste y los intereses que se deben pagar por hacer mal las cosas”, es decir que provocaran afectaciones a futuro en la solución que se está desarrollando.

La mayoría de los autores coinciden en que la principal causa de la deuda técnica es la presión en fechas y planes. Sin embargo, con el tiempo, el término deuda técnica se ha perfeccionado y ampliado. Por ejemplo. el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon señala que la deuda técnica «conceptualiza la compensación entre el beneficio a corto plazo de la entrega rápida y el valor a largo plazo». Otra perspectiva proviene del analista de la industria, Gartner, que define la deuda técnica como la desviación de una aplicación de cualquier requisito no funcional.

Otro par aportes importantes fueron presentados por Steve McConnell con su taxonomía y Martin Fowler con sus cuatro cuadrantes. La pequeña taxonomía de McConnell, habla de que:

  1. No hay deuda técnica, si… Hay retrasos, recortes, etc., que no requieren el pago de intereses. No todo el trabajo incompleto es deuda.
  2. Si hay deuda técnica… puede ser (I) Deuda incurrida involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrida intencionalmente.

Dándole una vuelta más al término, la figura de abajo muestra cuatro tipos de posibles mejoras o tareas a realizar en el futuro para aumentar el valor del producto software, como pueden ser ampliar funcionalidades (que es en lo que suelen fijarse las empresas), o invertir en arquitectura, invertir reducir los defectos o la deuda técnica, que es invisible y tiene un efecto negativo.

Existen 3 tipos de deuda técnica que son:

Deuda técnica planificada: este tipo de deuda técnica ocurre cuando la organización toma una decisión informada de generar alguna deuda técnica con el pleno conocimiento de las consecuencias (riesgos y costos). En el caso de la deuda técnica planificada, es fundamental ser lo más preciso posible en términos de definir los compromisos que la organización pretende hacer. Un ejemplo podría ser: “Para cumplir con la nueva fecha límite de lanzamiento de noviembre, hemos decidido renunciar a las pruebas de la unidad de escritura en las últimas tres semanas del proyecto. Escribiremos estas pruebas después del lanzamiento «.

Debido a que estas decisiones pueden acumularse rápidamente con el tiempo, es imperativo mantener un registro de ellas. Al hacerlo, aumentará la probabilidad de que la deuda técnica se aborde y se pague más rápido. De lo contrario, se olvidará rápidamente, lo que podría costarle mucho tiempo a la organización a largo plazo.

Deuda técnica no intencional: se refiere a la deuda técnica no planificada que surge debido a malas prácticas. Por ejemplo, un enfoque de diseño que termina conteniendo muchos errores. Este tipo de deuda técnica a veces ocurre como resultado directo de una comunicación deficiente dentro de la organización o cuando los objetivos de Desarrollo y Operaciones están desalineados.

Deuda técnica inevitable: esto ocurre debido a cambios en el negocio y al progreso de la tecnología a lo largo del tiempo que presentan mejores soluciones. Por lo general, surge cuando se solicitan cambios en el alcance a mitad del proyecto, lo que resulta en un costo inmediato, como agregar una nueva característica a un diseño existente para respaldar mejor la entrega móvil. En resumen, la deuda técnica se crea cuando los nuevos requisitos comerciales hacen obsoleto el antiguo código.

Siempre evitar acumular deuda técnica

Si bien la deuda financiera es fácil de rastrear, la deuda técnica no es inherentemente una métrica. Con algunos ajustes, la teoría de la deuda técnica se puede traducir a ciertas métricas, como el tiempo de comercialización frente al tiempo que trabaja horas extras para pagar intereses. También puede aparecer como una menor productividad de un equipo, que también es difícil de medir.

Los expertos recomiendan hacer un seguimiento de su deuda técnica para evitar que sea demasiado difícil de manejar. Como las deudas pueden sobrevivir a múltiples ciclos de desarrollo, su seguimiento es esencial. Así es cómo:

  1. Comience una lista de deudas técnicas. (Esto incluye todas las instancias donde los desarrolladores saben que el código no es tan limpio como debería o debe ser para el desarrollo futuro).
  2. Listar y agrupar tareas diferidas en unidades viables.
  3. Tenga en cuenta las consecuencias de ignorar cada unidad.
  4. Mantenga la lista visible.
  5. Informe a los equipos que confían en los lanzamientos de entrega, como marketing, ventas, etc., que está trabajando en deudas técnicas, para que cada nuevo lanzamiento no pueda incluir solo nuevas características.
  6. Programe un horario regular y frecuente para pagar la deuda técnica.

Algunas ideas de como Gestionar la Deuda Técnica

Evaluación:

Al identificar la deuda técnica, es posible que haya encontrado algunas señales clave. Por ejemplo, las clasificaciones de rendimiento de su producto podrían estar disminuyendo o sus desarrolladores pueden tardar mucho más en iterar. ¿Pero cómo mides esto? ¿Cuál es el verdadero costo de la deuda técnica?

Una forma de llegar a esta medida es observar la cantidad de días que los desarrolladores necesitarían dedicar a reducir la deuda técnica realizando actividades como refactorizar o reemplazar la aplicación.  Esto proporcionará un excelente análisis de costo / beneficio. Además de proporcionar una actualización del estado actual, también es importante generar estimaciones de cómo espera que la deuda técnica cambie con el tiempo.

Comunicación

Uno de los pasos más importantes a tomar en la gestión de la deuda técnica es reconocer que existe en primer lugar y compartir ese descubrimiento con las partes interesadas clave. Por lo tanto debería buscar identificarse siempre el verdadero costo de la deuda técnica, hacerlo visible, comunicarlo a todos. y explicar la importancia de pagar la deuda técnica más temprano que tarde.

Implementación

Hay tres opciones a considerar en términos de gestión de la deuda técnica.

  1. Renunciar al requisito por completo. En otras palabras, la organización decide vivir con el sistema tal como es y ya no considera que el requisito sea necesario. Si no puede renunciar al requisito, deberá refactorizar o reemplazar la aplicación.
  2. Refactorizar la aplicación. Esta opción tiene como objetivo reducir la complejidad, eliminar duplicados y mejorar la estructura del código. La refactorización es la única forma de mejorar la estructura interna de un código sin cambiar el comportamiento del programa.
  3. Reemplazar la aplicación. Si bien esto introducirá una nueva deuda técnica, la idea es abordarla rápidamente y minimizarla lo más posible.

Gracias por tu tiempo.

Pd:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Saludos,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


Una respuesta a «Hablemos de Deuda técnica»

    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: