Gestión de la deuda técnica con DX e IA

Toda empresa, grande o pequeña, se preocupa por la deuda técnica. Estimaciones de Gartner que aproximadamente el 40% de los sistemas de infraestructura tienen este problema. En una encuesta de McKinsey a CIO, casi un tercio consideró que mayor a 20% De su presupuesto para nuevos productos se destinó a resolver problemas relacionados con la deuda técnica. Pero, al contrario de lo que muchos creen, esto no es solo un problema de código, sino también de experiencia del desarrollador (DX). Porque cuando los desarrolladores tienen que trabajar con una arquitectura inadecuada, herramientas obsoletas y flujos de trabajo de desarrollo deficientes, la productividad, el rendimiento y la moral se ven afectados.

Priorizar la deuda técnica pensando en el desarrollador, centrándose en su enfoque del trabajo, las herramientas que utiliza y las oportunidades de desarrollo profesional que puede obtener, ayuda a los equipos a concentrarse y agilizar los lanzamientos. Por eso, la forma en que las empresas gestionan la deuda técnica está cambiando, impulsada por la DX y un mayor enfoque en las herramientas basadas en IA.

Defendiendo el DX

La forma en que se incorporan los desarrolladores suele ser deficiente. Puede tomar un par de semanas para que alguien empiece a contribuir a un proyecto. Una vez que finalmente han podido añadir pequeñas características o parches, no es raro ver que el servicio de integración continua (CI) falla debido a algo completamente ajeno a los cambios en los que han trabajado. Esto se debe básicamente a que la suite de pruebas falla debido a problemas de calidad, y el desarrollador no envió cambios que la hicieran fallar. Es una prueba inestable y mal escrita que solo funciona el 90 % del tiempo. El equipo existente probablemente no tenga problema con ello (solo ralentiza los procesos), pero las herramientas pueden quedar obsoletas y desmoralizar a cualquier persona externa a la organización.

Este es un ejemplo de los muchos que impiden una DX adecuada. Una forma de evitarlo es designar un líder en el equipo de ingeniería y desarrollo de software. Muchas organizaciones pequeñas no cuentan con un líder de DX, pero las grandes y exitosas sí. Estos profesionales controlan aspectos como el tiempo que tarda un nuevo desarrollador en configurar un entorno. Y si dos semanas son demasiado tiempo, buscan la manera de reducirlo a la mitad.

Existen herramientas de ayuda, como CircleCI, con funciones nativas que detectan las fallas de una suite de pruebas. Se necesita alguien que tome la iniciativa y se detenga después de cada sprint para abordar algunos cambios que facilitarán el mantenimiento y la utilización del código en el futuro. En resumen, es necesario contar con un líder interesado en mejorar la experiencia de usuario (DX). Para ello, se busca un ingeniero sénior, acompañado de un miembro relativamente nuevo del equipo que pueda brindar retroalimentación sobre posibles deficiencias.

Además, IDC espera que el mercado de automatización de pruebas de software impulsado por IA continúe creciendo a una CAGR del 31.2% hasta 2027, así que asegúrese de aprovechar esta tecnología al máximo.

Métricas y señales de advertencia

Hay muchas métricas que puedes monitorizar al evaluar el impacto de la deuda técnica en tu equipo. Algunas básicas son el "tiempo de corrección" o el "tiempo de implementación de funciones". Supongamos que detectas un error y sabes cómo solucionarlo. Algunas herramientas pueden monitorizar el tiempo transcurrido desde la escritura del código hasta la producción. Por ejemplo, podrías ver que un parche muy pequeño tardó dos días hábiles en corregirse y enviarse, cuando tu equipo debería poder hacerlo en horas. También puedes monitorizar ratios, como el número de correcciones de errores en comparación con las funciones completadas.

También hay maneras de identificar cuándo los problemas de moral afectan el rendimiento de tu equipo. Los líderes de DX pueden realizar encuestas trimestrales para determinar el grado de satisfacción de un desarrollador al trabajar en un proyecto o en una parte del mismo. Pueden profundizar y preguntar sobre áreas específicas como el proceso de CI. Además, siempre puedes monitorear la rotación o la deserción de tu equipo. Si observas que los empleados se van constantemente, podrían sentir que sus preocupaciones no están siendo escuchadas.

Jugando con IA

Se supone que el auge de las herramientas de IA aumenta la productividad de los desarrolladores e ingenieros y acelera la entrega de productos, pero la deuda técnica lo ralentiza. Supongamos que usas una herramienta como GitHub o Copilot para ayudarte con los cambios de código, envías la solicitud de extracción y la CI tarda un par de horas en responderte. Mientras tanto, ¿un desarrollador trabaja en otra cosa? ¿Revisa correos electrónicos? Es un cambio de contexto y un destructor de productividad.

Los desarrolladores quieren trabajar en productos donde puedan centrarse exclusivamente en el código. Las herramientas están ahí para ayudarles a llevarlo a producción, no para que sea un obstáculo constante. La IA puede ahorrar tiempo, pero los equipos de ingeniería deben definir sus propios estándares de complejidad aceptable. Para ello, primero asegúrese de que todo el código que se añada a su rama principal tenga un nivel aceptable de deuda técnica. Antes de eso, mantenga una conversación abierta y obtenga la aprobación del equipo de ingeniería sobre el umbral aceptable de deuda técnica y calidad del código. Asegúrese de que todos sepan que superar ese umbral requiere una solución inmediata. Una vez definidos esos estándares, la IA entra en juego.

Existe un caso de agentes de IA con ingenieros que actúan como orquestadores. Una encuesta de Capgemini a 1,100 ejecutivos de grandes empresas ha revelado que El 82% planea integrar agentes de IA en los próximos tres años, y ya están impactando la futuro del trabajoQuizás estés viendo un informe de errores y veas que es lo suficientemente pequeño como para que un agente de IA lo gestione desde el inicio hasta la revisión del código, ahorrando tiempo a tu equipo y permitiéndoles dedicarse a trabajos más complejos. Sin embargo, a veces, cuando seguimos ciegamente estas herramientas, existen desventajas que a la IA le cuesta considerar.

Entonces es cuando la opinión humana se convierte en el factor decisivo.

Alineando la deuda técnica con los objetivos

¿Cómo alinear la reducción de la deuda técnica con los objetivos que se intentan alcanzar o con resultados medibles? Se trata de una deuda técnica aceptable, y a veces, en el ámbito empresarial, es necesario entregar con rapidez. Esto se puede lograr sabiendo que un producto no escala y que podría haber problemas de rendimiento con el tiempo. A menudo, un desarrollador anota para volver a esto más adelante, cuando haya tiempo para abordar estos problemas, pero esto rara vez ocurre. Y cuando esta cultura deficiente se impone, donde constantemente se tiene que entregar el producto mañana, el impacto de la deuda se hace evidente.

Esto es comprensible para una startup, pero no para una empresa que lleva una década funcionando. Es necesario empezar a cambiar la cultura con anticipación y de forma activa para gestionar la deuda técnica; de lo contrario, se gastará un dineral corrigiendo errores de producción o preocupándose por la seguridad y el cumplimiento normativo.

Finalmente, existen métricas que ayudan a comunicar el valor de la refactorización o la reducción de la deuda técnica a las partes interesadas. El tiempo puede ser una de ellas, desde el inicio hasta la producción, o desde la apertura de una solicitud de extracción hasta su fusión y envío a producción. Otra es el tiempo medio de reparación (MTTR). En este caso, puede que hayas encontrado un error o una compilación defectuosa y midas cuánto tarda tu equipo en solucionarlo. También puedes registrar la cantidad de errores que tienes en producción. Si ves que esa cifra aumenta, podría haber un problema relacionado con la deuda técnica.

Deuda técnica con intereses

Toda organización puede dedicar unas horas semanales a mejorar su DX para reducir la deuda técnica. De lo contrario, podrías pagar las consecuencias más adelante, probablemente por un rendimiento lento, una ralentización considerable del desarrollo o problemas de seguridad. Por ejemplo, tu equipo de ingenieros y desarrolladores podría haber pospuesto las actualizaciones a Ruby on Rails durante una década. De repente, el coste de un proyecto aumenta en medio millón de dólares porque la versión de Ruby tiene un retraso de cuatro generaciones, lo que te deja con una gran cantidad de código y dependencias obsoletas.

Si hubieras actualizado gradualmente, no estarías en esta situación. Así que apoya a tu equipo de desarrollo de software y paga según el uso. De lo contrario, esa deuda técnica te costará caro, con intereses.