¿Cómo negociar la deuda técnica?

La deuda técnica es un término acuñado por Ward Cunningham para explicar a sus stakeholders la necesidad de refactorizar software, que inicialmente se escribió con el conocimiento limitado del problema que solucionaba y que, con el aprendizaje adquirido durante su desarrollo, se comprobó que dicho fragmento de código no era todo lo bueno que se esperaba, lo que traería consecuencias negativas a largo plazo.

Realmente, lo que Cunningham estaba negociando con sus clientes era invertir dinero en calidad de código versus nueva funcionalidad.

El concepto encierra una analogía que es fácil de entender para los encargados de tomar decisiones, pues aclara, en términos financieros básicos, la implicación de no cuidar la calidad.

Cunningham siempre que hablaba de deuda técnica lo hacía en términos de calidad de código y refactorización, pero es un término que perfectamente puede ser ampliado a aspectos más generales de la tecnología.

¿Por qué se genera la deuda técnica?

Para garantizar cualidades del software, como la adaptabilidad y mantenibilidad, es necesario: invertir y establecer mecanismos de despliegue y pruebas automáticas, documentación correcta, cuidar el diseño de los componentes del sistema, entender qué responsabilidad tiene cada componente para no distribuir funcionalidades entre varios y un largo etcétera.

Todos los los requerimientos no funcionales pendientes y falta de calidad en el software pueden ser considerados deuda técnica.

El problema de la deuda técnica no es la deuda en sí misma, sino que son los intereses que acarrea a medio y largo plazo. Estos intereses se traducen en:

• Altos costes para hacer un pase a producción.
• Que realizar un evolutivo supone el riesgo de inestabilizar el sistema.
• Que el software es difícil de adaptar porque se ha convertido en espaghetti code.

Cabe preguntarse, ¿por qué se crea deuda técnica? Si sabemos que a la larga es negativa, ¿por qué no se evita desde el principio? Desde mi punto de vista existen tres grandes generadores de deuda técnica, sin que vayan en orden:

• El famoso triángulo de hierro.
• La incertidumbre en el desarrollo de software y la complejidad de los entornos.
• La falta de conocimiento de las buenas prácticas tecnológicas.

El triángulo de hierro

El triángulo de hierro indica que el resultado de un proyecto está completamente afectado por el tiempo, el alcance y la calidad. El problema que describe se hace más notable cuando los modelos de relación en torno al desarrollo de software están basados exclusivamente en dicho triángulo.

La idea que hay detrás del triángulo de hierro es que si se mueven las expectativas en cualquiera de dichas variables, las demás se verán afectadas.

En el caso que nos ocupa la calidad, ausencia de deuda técnica, es degradada por compromisos financieros (por ejemplo, la incapacidad de emplear recursos adecuados por problemas de presupuesto); o por compromisos de alcance (por ejemplo, si se quiere sacar al mercado funcionalidad antes que la competencia).

Falta de conocimiento

La otra razón por la que se genera deuda técnica es la falta de conocimiento sobre el problema que se pretende resolver con software. Este es un factor presente en la mayoría de los proyectos y es intrínseco.

Los desarrolladores aprenden del problema al que quieren dar solución con software en la medida que van desarrollando el propio sistema. Esto, aunque parezca paradójico, es lo más normal. Si ya existiera una solución de software para dicho problema de negocio, lo suyo es emplearla, no ‘reinventar la rueda’.

Si se decide desarrollar nuevo software es porque no existe otro software o el que existe no se ajusta al problema a resolver. El problema, entonces, tiene matices propios más o menos grandes y, por lo tanto, áreas desconocidas.

Otro ejemplo de esto es el hecho de que los programadores saben programar (que es lo que se espera de ellos) y no siempre son expertos en el dominio del negocio donde se circunscriben sus desarrollos. Desarrolladores de software con conocimiento de negocio son activos que no siempre se encuentran.

Falta de conocimiento tecnológico

Por último, existe la falta de conocimiento sobre tecnología en general. Al fin y al cabo, no se puede saber de todo.

El responsable de negocio que contrata el desarrollo de un software solo piensa en la funcionalidad que necesita, no conoce (ni tiene por qué conocer) todos los requerimientos no funcionales que rodean a los requerimientos funcionales y que, a la larga, redundarán en un mejor activo tecnológico.

Es decir, que su software se convierta en un aliado, no en un lastre. Cuando se genera deuda técnica por esta razón, la situación típica es la de un proyecto donde la mayor influencia viene de decisores que no conocen las implicaciones de la mala calidad y donde el equipo técnico no está logrando hacerse oír.

Cultura de deuda técnica

La deuda técnica es, por tanto, un asunto crítico para el éxito de las inversiones en desarrollo de software a largo plazo. Algo tan importante debe ser tratado con cierta relevancia. Gestionar la deuda técnica, además, es una carrera de fondo, lo importante es la concienciación y la constancia.

Todos los involucrados en desarrollo de software, tanto negocio como IT, deben entender cómo se identifica la deuda técnica, cómo se gestiona, en qué momentos y bajo qué condiciones se permite crecer y cuándo es mejor aprovechar para reducirla. Al final, se trata de que la cultura del desarrollo embeba la realidad de la deuda técnica.

Además de hacerlo de manera positiva, la deuda técnica no debe ser ocultada. Todo lo contrario. Debe ser expuesta para poder gestionarla. Es importante que los equipos entiendan que nadie les va a penalizar por tener deuda técnica, sino todo lo contrario.

Se debe penalizar la ocultación de la misma. Para ello, es importante impulsar una cultura de la confianza y la comunicación en relación a la calidad del software.

¿Cuál es el mecanismo de la deuda técnica?

Las distintas etapas son definirla, inventariarla y visualizarla, priorizarla y remediarla. Veamos cada una en detalle:

Definir la deuda

En primer lugar es importante definir la deuda técnica y hacer llegar dicha definición a todas las personas. Normalmente en las organizaciones grandes existe un Departamento de Arquitectura que ayuda a impulsar buenas prácticas, herramientas o activos IT corporativos y que ayuda a definir la estrategia tecnológica.

Las prescripciones que llegan desde el Departamento de Arquitectura y que no han sido implementadas en un proyecto son deuda técnica.

Además, cada producto en función de su naturaleza tendrá más necesidad de cierta cualidad de software que de otra. Esto, normalmente, se define en las sesiones de estrategia de producto.

Por ejemplo, las cualidades más importantes para un producto con la aspiración de convertirse en una plataforma podrían ser la extensibilidad, la observabilidad y la adaptabilidad.

Por el contrario, un producto cuyo objetivo sea la transformación de datos, sus cualidades más valiosas podrían ser la interoperabilidad y la escalabilidad. Fijar la ecualización de las cualidades de un proyecto de software permite al equipo entender qué carencias del software son deuda técnica más o menos crítica.

Una vez se tenga claro cuál es la definición de la deuda técnica en un proyecto (será la suma de las prescripciones de Arquitectura y los aspectos locales al proyecto), esta debe escribirse en el Definition of Done (DoD) en forma de requerimientos no funcionales.

Al final, una historia de usuario o una tarea debe ser considerada terminada correctamente cuando se ha implementado su funcionalidad, además de todos los requerimientos no funcionales que la acompañan. La definición de deuda técnica a partir de ese momento será muy sencilla: todo lo que haya quedado pendiente del DoD.

Inventariar y visualizar

Comenzamos el desarrollo del software y generamos deuda técnica por cualquiera de las razones arriba indicadas. Al final, lo que estará pasando es que no hemos implementado algo o no hemos podido dejar un fragmento de software con la calidad esperada o es necesario cambiar una función de módulo, etc.

Cualquiera de estas carencias debe ser apuntada en el backlog como una tarea pendiente de hacer. Cabe recalcar que la manera de escribirla es en modo positivo. Por ejemplo, en lugar de escribir “no se ha automatizado X”, será mejor escribir “automatizar X”.

Además, es interesante poder medir la evolución de la deuda técnica. Para lograrlo es condición imprescindible no solo que se esté dando de alta en el backlog, sino que además se etiquete (por ejemplo, con la marca techdebt). Así, será sencillo filtrar por aquella etiqueta cuando se trabaje con el backlog, además de que será posible obtener métricas.

Ni qué decir tiene que las PBIs (Product Backlog Items) relacionadas con deuda técnica deberán ser estimadas como si se trataran de una historia de usuario cualquiera.

Una métrica que es interesante seguir y que es sencilla de obtener es el acumulado de deuda técnica (en número de PBI, en número de puntos de historia o en número de horas, según el equipo) generada, contra el acumulado de deuda técnica remediada.

Más tarde analizamos cómo interpretar y emplear el gráfico.

Priorizar

Cuando tengamos un backlog repleto de historias de usuario y de tareas de deuda técnica es necesario entender cuál es la deuda más crítica. Para ello, será necesario realizar una matriz de riesgos que nos ayude a entender los intereses que genera cada una de las tareas de deuda técnica y la dificultad de remediarla.

El Product Owner, con la ayuda del arquitecto, es el encargado de entender el impacto que la deuda técnica puede acarrear en el negocio. Dicho impacto tiene que estar escrito en la descripción de la PBI.

Para ello, no basta con decir “no tenemos automatizado el módulo X”. Será necesario decir “los cambios en todo lo referente a facturación (implementada en el módulo X) tienen unos tiempos de despliegue de 1 día, mientras no lo automaticemos no podemos aceptar cambios (salvo los muy justificados) en dicho módulo porque nos bloquean todo el pipeline de despliegue global”.

Esta frase permite al negocio entender que su proceso de facturación no pueden realizar cambios, lo que puede o no ser crítico para sus objetivos.

Remediar

Finalmente, con los datos anteriores, se toma la decisión de ir remediando la deuda en la medida que lo permita el contexto del proyecto. Se incluirán las PBIs de deuda técnica junto con el resto en el backlog del sprint. Esto mantendrá la salud de nuestro software en un estado óptimo.

Negociando la deuda técnica

El sprint planning suele ser una ceremonia controvertida porque es donde se ponen encima de la mesa los intereses cruzados de cada stakeholder.

A grandes rasgos, las tensiones se agrupan en dos fuerzas que a priori pueden parecer contrapuestas aunque, a la larga, ambas tienden a la mejora general del producto. Estas son la tensión del negocio o funcional y la tensión técnica.

Ambas tensiones, en ciertos momentos del sprint planning, pueden aparentar intereses propios y contrapuestos. Aunque, si lo pensamos fríamente, son miradas desde distintas caras de un mismo prisma: el prisma de la búsqueda de éxito en el producto o proyecto de software.

Los miembros técnicos del equipo, normalmente, centran sus preocupaciones en la calidad del software y son los mayores conocedores de la deuda técnica existente y de su impacto a largo plazo. Históricamente, se ha demostrado la dificultad que estos han tenido para trasladar sus preocupaciones al negocio. El mecanismo aquí expuesto pretende servirles de ayuda.

La fuerza aparentemente opuesta es la funcional: la necesidad de nuevas funcionalidades, de modificar las existentes o de eliminar algunas obsoletas. El negocio tiene sus objetivos y le cuesta observar la capa técnica.

Para ayudar al Product Owner a negociar con los stakeholders de negocio es de gran ayuda que el arquitecto colabore con él en mantener actualizada la matriz de riesgos de la deuda técnica (anteriormente introducida).

Así el Product Owner podrá poner encima de la mesa los intereses de negocio y los técnicos (traducidos a términos de negocio) y llegar a acuerdos en los que se logre un equilibrio entre los incrementos funcionales y la reducción de la deuda.

Por último, la métrica de la deuda técnica acumulada (vista con anterioridad) debe llevarse a las retrospectivas para buscar, con todo el equipo, medidas que la equilibren en el caso de que se observe algunos de estas situaciones:

• La deuda no crece: esto es un indicador claro de que no se está inventariando. Es imposible que no haya deuda técnica.
• La deuda crece demasiado rápido: es signo de que el equipo no tiene capacidad para entregar el producto con los niveles de calidad especificados en el DoD.
• La deuda crece más rápido de lo que se remedia de manera continuada: no se está remediando a la velocidad debida o se está generando demasiada deuda nueva.

Conclusión

En definitiva, establecer una cultura de confianza, transparencia y gestión de la deuda técnica es vital para asegurar niveles óptimos de calidad del software.

Estos valores deben perseguir que esta deuda se gestione de manera constante, mediante acuerdos entre el cuerpo funcional y el técnico. Acuerdos a los que se llega porque la deuda ha sido traducida a términos que el negocio entiende como riesgos a sus objetivos.