Deuda técnica de TI: cómo medir y reducir la deuda técnica de los proyectos & portafolio projects

Escapar del agujero negro de la deuda técnica... ¿Su reflejo es refunfuñar cuando ve esto? Sí, nosotros también. Pero el problema tiene solución. La deuda técnica es un concepto de desarrollo de software inventado por Ward Cunningham en 1992. El término proviene de una metáfora, inspirada en el concepto de deuda existente en las finanzas y los negocios, aplicada al campo del desarrollo de software. Más allá de lo que la empresa ya tiene detrás, las acciones, crea un legado en cuanto se desarrolla. Es un flujo permanente. Es cuando se deja sobrepasar cuando crea una deuda técnica que se vuelve restrictiva...

Más información en este artículo:

• Principales categorías de deuda técnica
• ¿Cómo se cifra la deuda técnica?
• ¿Cómo gestionar un proyecto reconociendo su deuda técnica?
• ¿Cómo se mide la deuda técnica?
• ¿Qué palancas puede utilizar el Departamento de TI para gestionar mejor la deuda técnica?

El pensamiento del creador del concepto de deuda técnica, Ward Cunningham

Hace ya 30 años, Ward Cunningham estableció una comparación entre complejidad técnica y deuda en un informe de retroalimentación.

Entregar el primer código se parece mucho a contraer una deuda. Una pequeña deuda acelera el desarrollo siempre que se amortice rápidamente con una reescritura...

El peligro surge cuando la deuda no se paga rápidamente. Cada minuto invertido en un código que no es del todo correcto aumenta los intereses de esa deuda. Cada semana que pasa hace que los desarrolladores olviden qué hacer para saldar la deuda que han aceptado.

Un departamento informático puede paralizarse por completo porque se desmorona bajo el peso de las deudas de desarrollo impagadas.

Conviene que un equipo de desarrollo de proyectos informáticos aproveche las oportunidades para pagar (o saldar) esta deuda técnica. Si gestiona uno de estos proyectos de desarrollo de software, reserve un porcentaje de su ciclo de desarrollo para saldar la deuda. O mejor aún, dedique todo un ciclo de desarrollo. Un Sprint 0 por ejemplo con Scrum. Para completar este trabajo. Si no lo haces, ese código subóptimo o defectuoso volverá a perseguirte. Ya sea tu equipo de proyecto o el "help desk", el equipo de soporte, o alguien más aguas abajo de tus entregables. Por no hablar de la dificultad de actualizar la aplicación con el tiempo.

Es una deuda real, y como cualquier otra deuda, tendrás que pagarla tarde o temprano.

A veces aceptas desarrollos rápidos y sucios. Porque te ahorra tiempo y justifica los riesgos y el coste total. Pero entonces adoptas un proceso de pensamiento a muy corto plazo. No sabes calcular los costes y riesgos a largo plazo. Si no es absolutamente necesario correr ese riesgo, no lo hagas. Tu prioridad es hacer un trabajo de calidad.

Principales categorías de deuda técnica

1. Deuda acumulada a lo largo del tiempo como consecuencia de los cambios o la evolución del marco de desarrollo

Es casi inevitable que tu framework evolucione y mejore hasta el punto de que quieras adoptar versiones más recientes. Si no supervisas estos cambios y evolucionas tu base de código en consecuencia, cada vez será más difícil adoptar versiones recientes. Tal vez alguien añada un nuevo módulo o integre un nuevo servicio que usted necesitará en un futuro próximo. Esta categoría de deuda es la menos destructiva y puede evitarse adoptando una buena estrategia de actualización del framework.

2. Deuda por obsolescencia

Los proyectos dependen de elementos externos (bibliotecas, API, modelos, arquitecturas, etc.). También generan deuda técnica, ya que los elementos externos evolucionan en paralelo, provocando queciertas partes del código quedenobsoletas y requieran actualizaciones. La deuda técnica es inevitable en el desarrollo de software y persiste durante toda la vida del producto.

3. Deuda pragmática

La realidad del desarrollo de software es que nunca hay tiempo suficiente para hacer un trabajo perfecto. Tarde o temprano, tendrá que hacer algo menos ideal para cumplir el plazo y el presupuesto. A menudo puede permitirse renunciar a la calidad, pero ¿cómo saber cuándo? La regla empírica es que el coste de implementar la funcionalidad de esta manera subóptima es igual al coste de hacerlo dos veces. Una para completarla a tiempo y otra para rehacerla de una forma más óptima y sostenible.

Si no consigue pagar las deudas 1 y 3 en un plazo razonable, es como si hubiera firmado una hipoteca de alto riesgo. Descubrirá que esta acumulación de deuda técnica hace casi imposible añadir nuevas funcionalidades al sistema existente en el momento oportuno. Es probable que tenga muchos más errores en su sistema de lo que es aceptable. Inevitablemente, gastará más en mantenimiento operativo. Tus usuarios ya han empezado a notar errores, fallos de seguridad o problemas de rendimiento... Esto representa el coste de mantenimiento de la deuda, algo así como los intereses que pagas por tu hipoteca cuando aún tienes que encontrar la forma de devolver el capital.

La disciplina es su propia recompensa a largo plazo. Con el tiempo, podrás permitirte gastar más dinero en nuevas prestaciones si pagas tus deudas a tiempo. Lo mejor es crear un plan estructurado para pagar las deudas con un calendario aceptable.

¿Cómo se cifra la deuda técnica?

Antes de contraer esta deuda, conviene calcular cuánto tendrás que invertir para pagarla. Calcula la deuda propuesta en euros sumando :

• los días de desarrollo necesarios para corregir el código
• los esfuerzos de apoyo adicionales que serán necesarios durante el periodo en que el cliente del proyecto esté utilizando una solución no óptima
• plazos de pago para el cliente del proyecto, que no estará satisfecho al 100%...

Al poner una cifra económica a la menor calidad estructural de la aplicación, puede comparar los costes informáticos con las pérdidas potenciales en el lado empresarial como resultado de un fallo que era impensable antes de aceptar esta deuda.

Como mínimo, cuantificar su deuda técnica le ayudará a reducir el número de violaciones de la calidad estructural. La clave está en vigilar este contador de infracciones.

Al igual que con la deuda en el mundo real, el truco con la deuda técnica es controlar tus deudas de cerca y asegurarte de que tienes un plan de acción para pagarlas. Dejar que tus deudas crezcan sin pensar en lo que estás haciendo es una forma inaceptable de llevar tus finanzas personales...
... como tu proyecto de desarrollo de software.

Para ello, lleve un registro de sus deudas en un formato sencillo, como el de un rastreador de cuentas, que sea fácil de entender para todos. El equipo debe detallar las consecuencias técnicas de estas decisiones, que repercutirán negativamente en la calidad de la aplicación del producto (probabilidad, impacto y soluciones previstas). Asegúrese de que todos los desarrolladores del equipo conocen y comprenden este registro. Cada vez que añada una deuda, añada una línea a su registro al mismo tiempo que entrega el código en cuestión.

Cuando reembolse una deuda, tache la entrada correspondiente en el registro.

Convierta en rutina la revisión del registro de deudas al final de cada Sprint. Al igual que con el registro de riesgos, asegúrate de contar con un plan de acción para abordar cada línea.

Comparta el registro con su equipo. Asegúrate de que entienden la razón para plantearse una nueva deuda y la magnitud del próximo reembolso.

...No todo es deuda técnica

No todos los defectos y fallos son deuda técnica. A menudo no son más que errores, aunque usted los considere irresponsables o indignos. En realidad, estos errores no suelen reflejar decisiones de diseño. Si no ponen directamente en peligro la calidad del producto, no son deuda técnica.

En Scrum, una buena definición de DONE debe ser lo suficientemente robusta como para garantizar que no se alcancen niveles irrazonables de deuda. Si, a pesar de esto, la deuda técnica sigue aumentando, la definición de DONE probablemente tendrá que ser revisada.

¿Cómo gestionar un proyecto reconociendo su deuda técnica?

Detallar las consecuencias técnicas

Para una gestión eficaz del proyecto, lleve un registro de sus deudas en un formato sencillo. Detalle las consecuencias técnicas: probabilidad, impacto y soluciones previstas. Cada vez que añada una deuda, añada una línea a su registro cuando entregue este código. Y cuando reembolse la deuda, tache la entrada correspondiente en el registro. Y, al final de cada Sprint, realiza una revisión de tu registro de deudas.
Si quieres ir más allá, puedes definir indicadores de riesgo. Y aplicarlos a los proyectos utilizando portafolio .

Desarrollar la gestión del ciclo de vida de las infraestructuras para incluir interfaces estratégicas de gestión portafolio

Las empresas digitales exigen una infraestructura resistente y adaptable; sin embargo, la deuda técnica incontrolada está impidiendo que los gestores de infraestructuras y operaciones cumplan este requisito. Los responsables de TI deben reforzar la gestión de portafolio adoptando prácticas que mantengan sus infraestructuras ágiles y actualizadas.

Una práctica de gestión de infraestructuras de portafolio proporciona el apoyo y los recursos necesarios para la evaluación continua, la gestión del ciclo de vida y la gobernanza.

Elija un componente de infraestructura para realizar una prueba piloto de planificación de gestión estratégica de portafolio que sea de alto valor y no tenga barreras obvias para su implementación.
Asigne al propietario adecuado la redacción de un plan de interfaz de gestión estratégica portafolio para el componente de infraestructura.

Una vez que las partes interesadas se sientan cómodas con el procedimiento, aumente el número de componentes de infraestructura sujetos a este procedimiento. Continúe hasta que todos los componentes identificados por otras carteras como necesitados de mayores niveles de rendimiento en términos de beneficios, riesgos y costes cuenten con un plan de interfaz de gestión estratégica de portafolio.

¿Qué herramientas pueden utilizarse para medir la deuda técnica?

• Herramientas de medición automática: se trata de una solución interesante para empezar a medir el nivel de deuda técnica sin esfuerzo, gracias sobre todo a herramientas que detectan los incumplimientos de las buenas prácticas. Por ejemplo, la herramienta Sonar garantiza que los desarrolladores respeten las métricas relativas a las clases y los métodos.
• Herramientas de medición de la cobertura de las pruebas: este tipo de solución muestra qué parte del código está cubierta por pruebas automáticas. Por ejemplo, una cobertura inferior al 75% puede indicar problemas importantes en el código.
• Herramientas de medición manual: puede crear informes para medir el impacto de la deuda técnica utilizando determinados indicadores. Como el número de errores en un periodo determinado y por aplicación, la duración de las investigaciones sobre un producto, componente o código heredado, la tasa de insatisfacción con las entregas, etc.

¿Qué palancas puede utilizar el Departamento de TI para gestionar mejor la deuda técnica?

1. Deuda técnica ágil: mejorar la calidad general del código 

El desarrollo ágil se basa en la velocidad. Cuando los equipos se apresuran a cumplir los plazos de los sprints, el resultado suelen ser métodos tediosos, rutinas ineficaces o código de mala calidad.

En revisiones inter pares son una forma costosa pero eficaz de comprobar que se siguen las buenas prácticas de programación. Controle los problemas del código y corríjalos lo antes posible. Compártalos con el equipo para aprender siempre de los errores cometidos. Aproveche la oportunidad para ampliar su documento sobre las normas y buenas prácticas que deben seguir los desarrolladores. Para una mejora más significativa, implique a su arquitecto técnico con el equipo de desarrollo. Refactorice el código con regularidad (no cada Sprint, sino cada Release, por ejemplo). Esto dará al equipo la oportunidad de analizar y reescribir parte del código a intervalos regulares para reducir la deuda técnica.

2. Prueba, tanto manual como automática

Las pruebas manuales no son muy eficaces. Una de las formas más eficaces de reducir la deuda técnica es automatizar las pruebas en la medida de lo posible. Empieza por centrarte en las pruebas no regresivas, que son las que más tiempo consumen y las que con demasiada frecuencia se descuidan o estropean por este motivo. A continuación, centre su atención en las pruebas de extremo a extremo que garantizan la usabilidad de su solución. Probablemente serán manuales y las realizarán expertos en la materia, al menos al principio.

3. Limitar el riesgo racionalizando la elección de tecnologías

Cuanto mayor sea la diversidad de tecnologías utilizadas, mayor será el riesgo para la calidad y mayor la complejidad del mantenimiento de las aplicaciones. Cuanto más "jóvenes" son las tecnologías, menos probadas están. Seleccione componentes estables, con soporte y actualizados periódicamente. Es importante limitar el número de tecnologías que intervienen en la construcción de la aplicación. Cuantas más tecnologías haya, más difícil será controlar las fuentes de deuda (y, por tanto, el número de acreedores).