QUE ES LA DEUDA TÉCNICA?

Ward Cunningham en 1992 introdujo el concepto de Deuda Técnica en relación a un producto, por su similitud con lo que ocurre cuando incurrimos con la deuda financiera.

Según la observación de Cunningham, cuando tomamos deuda técnica de forma contralada, podemos acelerar el desarrollo del producto, y si tenemos una estrategia para pagarla podríamos estar frente a una decisión acertada. Sin embargo, cuando no se contempla el pago de dicha deuda, el peligro aumenta hasta que la gestión del producto se vuelve incontrolable o impagable. Esto lo empezamos a ver en aquellos productos que debido a la lluvia de incidentes, consumen todas las horas de nuestros equipos internos e inclusive de nuestros proveedores para arreglar los problemas subyacentes, y sentimos que esto nunca acaba sino que por lo contrario sigue creciendo. Existen organizaciones que no pueden satisfacer nueva demanda debido a la enorme deuda técnica que tienen que atender. En la actualidad la metáfora de la deuda técnica está ganando mucha fuerza en la comunidad de IT como forma de entender y comunicar aspectos de calidad, propuesta de valor y costos de los productos. Al igual que lo que sucede con la deuda financiera, en la deuda técnica también corren  intereses. Las consecuencias de las malas decisiones tecnológicas al igual que los intereses crecen con el paso del tiempo. Por ejemplo, el “interés” es el costo extra invertido en mantener el software por tener una mala calidad técnica.

En la actualidad existen propuestas para medir la deuda técnica, como es el caso del método SQALE (Software Quality Assessment based on Lifecycle Expectations) o CQM modelo para el análisis de un producto de software diseñado por la empresa Optimyth y disponible “out-of-the-box “ en su producto Kiuwan. CQM esta basado en la norma ISO-25000 (inicialmente ISO-9126), ISO 25000 define tres aspectos de validación:

La calidad interna: conjunto de características desde el punto de vista interno (seguridad, fiabilidad, eficiencia, mantenibilidad y portabilidad).
La calidad externa: características obtenidas mediante la ejecución del software.
Calidad de uso: perspectiva del software desde el punto de vista del usuario.

Se utiliza en aplicaciones de todo tipo y tamaños para monitorear la calidad del código y gestionar la deuda técnica. El propósito del CQM es cubrir una necesidad general sobre la evaluación del código fuente de la capa de aplicación de un producto y nos da respuestas a preguntas como:

¿Cuál es la calidad del código que los programadores han entregado?

¿El código es flexible, escalable, fácil de mantener, portable, reutilizable?

¿Cuál es la deuda técnica acumulada por el proyecto?

¿A qué características de calidad está afectando la deuda técnica que se está acumulando?

¿Quiero empezar a pagar parte de mi deuda técnica, por dónde empezar?

CQM lleva el concepto de deuda técnica un poco más lejos, creando un modelo de calidad a partir de  características y subcaracterísticas. Esto permite conocer a qué características está afectando la deuda técnica y así poder gestionar mejor su corrección.

INDICADORES CQM

CQM define indicadores sintetizados sobre calidad. Además cada implementador puede definir otros según sus necesidades. Un indicador puede definirse como algo que nos ayuda a comprender dónde estamos, hacia dónde vamos y qué tan lejos estamos del objetivo. Como ejemplo tenemos:

EL eje vertical representa el valor de negocio de las aplicaciones mientras que el eje horizontal representa el riesgo. Esta vista tiene como objetivo identificar aquellas aplicaciones en el portfolio que requieren una acción inmediata en función de su criticidad para el negocio y su exposición a cualquiera de los 4 tipos de riesgo que se enfrentan:

  1. Global Risk (Risk index)
  2. Failure Probability (Production Risk)
  3. Maintenance (Development Risk)
  4. Security Risk.

Si tenemos servicios en el cuadrante superior derecho debemos tomar acciones correctivas urgentes para disminuir la deuda técnica del servicio.

HERRAMIENTAS

Kiuwan permite controlar la evolución de la deuda técnica en el portfolio de aplicaciones de la organización, haciendo transparente la deuda técnica generada tanto por centros de desarrollo internos como por proveedores. Independientemente de la tecnología web o móvil, inclusive de los sistemas legacy, visualiza malas prácticas de codificación y errores, dando respuesta rápidamente y en todo momento a la pregunta ¿en qué estado se encuentra cada componente del producto?

Algunos de los KPIs provistos por Kiuwan son:

 

  • Reducción del riesgo de seguridad
  • Reducción del riesgo de fallo
  • Reducción del riesgo de mantenimiento
  • Reducción de deuda técnica
  • Reducción del riesgo del software
  • % de reducción de esfuerzo de mantenimiento
  • Reducción de costes en el proceso de desarrollo
  • % de eliminación de defectos (DRE, Defect Removal Elimination)
  • % de reducción de código duplicado
  • % de reducción de complejidad de código
  • % de reducción de problemas de producción

CONCLUSIÓN

Chris Sterling hace referencia a distintos tipos de deudas con respecto al producto:

  • Technical debt
  • Quality debt
  • Configuration management debt
  • Design debt.
  • Platform experience debt

Retomando la ley de Conway, podemos agregar lo que sería el origen de todas las deudas, la deuda de no haber conformado un equipo ágil multidisciplinario de alto rendimiento, asociado al producto y de brindarle una estructura organizativa que le permita trabajar enfocado en los objetivos de negocio del producto.

Si estos temas son de tu interés, podes recibir un mail cada vez que publico, ademas tenes disponible para bajarte el  -> Gift del mes. Por supuesto te agradezco que difundas por cualquier red.