Gestionar la deuda técnica con DX y AI

Todas las empresas, grandes y pequeñas, se preocupan por la deuda técnica. Gartner estima que alrededor del 40% de los sistemas de infraestructura tienen este problema. En una encuesta de CIOs realizada por McKinsey, casi un tercio sintió que más del 20% de su presupuesto para nuevos productos se destinó a resolver problemas relacionados con la deuda técnica. Pero contrario a lo que muchos creen, esto no es solo un problema de codificación; también es un problema de experiencia del desarrollador (DX). Porque cuando los desarrolladores tienen que trabajar con una arquitectura inadecuada, herramientas obsoletas y flujos de desarrollo de baja calidad, la productividad, el rendimiento y la moral sufren.

Priorizar la deuda técnica con el desarrollador en mente, centrándose en cómo abordan el trabajo, qué herramientas utilizan y los avances en su carrera que pueden lograr, ayuda a los equipos a centrarse y a enviar más rápido. Esto es por qué la forma en que las empresas gestionan la deuda técnica está cambiando, impulsada por DX y un enfoque aumentado en la herramienta de AI.

Defendiendo DX

La forma en que los desarrolladores suelen incorporarse deja mucho que desear. Puede tomar un par de semanas solo para que alguien comience a contribuir a un proyecto. Una vez que finalmente hayan podido agregar pequeñas características o parches, no es inusual ver que el servicio de integración continua (CI) falla debido a algo completamente ajeno a los cambios que han realizado. Esto es básicamente la suite de pruebas fallando debido a problemas de mala calidad, y el desarrollador no presentó cambios para hacer que la suite de pruebas fallara. Es una prueba poco fiable y mal escrita que solo funciona el 90% del tiempo. El equipo existente probablemente esté de acuerdo con ello, solo ralentiza los procesos, pero la herramienta puede ser obsoleta y desmoralizante para cualquier persona fuera de la organización.

Este es solo un ejemplo de muchos que impiden la experiencia de DX correcta. Una forma de prevenir esto es tener un campeón designado en su equipo de ingeniería y desarrollo de software. Muchas pequeñas organizaciones no tienen un líder de DX, pero las grandes y exitosas sí. Estos profesionales llevan un registro de cosas como el tiempo que le toma a un nuevo desarrollador configurar un entorno. Y si dos semanas es demasiado tiempo, averiguan cómo reducir ese tiempo a la mitad.

Hay herramientas allí para ayudar, como CircleCI, con características nativas que rastrearán la inconstancia de una suite de pruebas. Lo que se necesita es alguien que tome el liderazgo y detenga después de cada sprint para abordar algunos de los cambios que harán que el código sea más fácil de mantener y trabajar en el futuro. Se reduce a tener un líder interesado en hacer que la DX sea mejor. Para que esto suceda, busque un ingeniero de nivel senior, acompañado de un miembro del personal relativamente nuevo que pueda proporcionar comentarios sobre posibles brechas.

Además, IDC espera que el mercado de automatización de pruebas de software con AI siga creciendo a un CAGR del 31,2% hasta 2027, así que asegúrese de aprovechar al máximo esta tecnología.

Métricas y señales de alerta

Hay muchas métricas que puede rastrear al evaluar cómo la deuda técnica está impactando a su equipo. Algunas básicas son “tiempo de solución” o “tiempo de característica”. Digamos que nota un error y sabe cómo solucionarlo. Algunas herramientas pueden rastrear el tiempo 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 solucionarse y enviar, cuando su equipo necesita poder hacerlo en cuestión de horas. También puedes rastrear ratios, como la cantidad de soluciones de errores versus las características completadas.

También hay formas de identificar cuándo los problemas de moral afectan el rendimiento de su equipo. Los líderes de DX pueden realizar encuestas trimestrales para determinar cuán felices son los desarrolladores trabajando en un proyecto o una parte de él. Pueden profundizar y preguntar sobre áreas específicas como el proceso de CI. Y siempre puede rastrear la rotación o la rotación en su equipo. Si nota que la gente sigue dejando, podrían sentir que sus preocupaciones no están siendo escuchadas.

Jugando con herramientas de AI

El surgimiento de herramientas de AI está destinado a hacer que los desarrolladores y los ingenieros sean más productivos y que los productos se envíen más rápido, pero la deuda técnica ralentiza esto. Digamos que usa una herramienta como GitHub o Copilot para ayudar con los cambios de código, luego envía la solicitud de extracción, y la CI tarda un par de horas en regresar a usted. Mientras tanto, ¿un desarrollador trabaja en algo más? ¿Revisa correos electrónicos? Es un cambio de contexto y un asesino de productividad.

Los desarrolladores quieren trabajar en productos donde puedan centrarse solo en el código. La herramienta está allí para ayudarlos a llevarlo a producción, no para ser un obstáculo constante. La AI puede ahorrar tiempo, pero depende de los equipos de ingeniería definir sus propios estándares para la complejidad aceptable. Para hacer esto, primero asegúrese de que cualquier código que se agregue a su rama principal tenga un nivel aceptable de deuda técnica. Antes de eso, tenga una discusión abierta y obtenga la aprobación del equipo de ingeniería sobre el umbral aceptable de deuda técnica y calidad de código. Asegúrese de que todos sepan que superar esa marca requiere una remediación inmediata. Una vez que haya definido esos estándares, la AI entra en juego.

Hay un caso para los agentes de AI con los ingenieros actuando como los orquestadores. Una encuesta de Capgemini de 1,100 ejecutivos en grandes empresas ha revelado que el 82% planea integrar agentes de AI en los próximos tres años, y ya están impactando el futuro del trabajo. Podrías estar mirando un informe de errores y ver que es lo suficientemente pequeño como para que un agente de AI lo maneje desde su inicio hasta la revisión del código, ahorrando tiempo a su equipo y liberándolos para realizar un trabajo más complejo. Sin embargo, a veces, cuando seguimos ciegamente estas herramientas, hay compensaciones que la AI lucha por considerar.

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

Alinear la deuda técnica con los objetivos

¿Cómo se alinea la reducción de la deuda técnica con los objetivos que se intentan lograr o los resultados medibles? Se remonta a la deuda técnica aceptable, y a veces en los negocios, debes enviar rápido. Puedes hacerlo sabiendo que un producto no escala, y puede haber problemas de rendimiento con el tiempo. A menudo, un desarrollador hará una nota para regresar a esto más tarde, cuando haya tiempo para abordar estos problemas, pero rara vez sucede. Y cuando esta mala cultura se apodera, en la que constantemente tienes que enviar mañana, el impacto de la deuda se vuelve abundantemente claro.

Esto es comprensible para una startup, pero no para un negocio que ha estado en funcionamiento durante una década. Necesitas comenzar a cambiar tu cultura temprano y activamente para gestionar la deuda técnica; de lo contrario, gastarás una gran cantidad de dinero para solucionar errores de producción o preocuparte por la seguridad y el cumplimiento.

Finalmente, hay métricas para ayudar a comunicar el valor de refactorizar o pagar la deuda técnica a los stakeholders. El tiempo podría ser uno, desde la concepción hasta la producción, o desde la apertura de una solicitud de extracción hasta la fusión y el envío a producción. Otra es el tiempo medio de reparación (MTTR). En este caso, puede haber encontrado un error o una compilación rota, y mide cuánto tiempo le toma a su equipo solucionarlo. También puede rastrear la cantidad de errores que tiene en producción. Si ve que ese número aumenta, podría haber un problema relacionado con la deuda técnica.

Deuda técnica con intereses

Cada organización puede dedicar un par de horas cada semana para mejorar su DX y ayudar a reducir la deuda técnica. Si no, es posible que la pague más adelante, probablemente por un rendimiento lento, una desaceleración considerable en la velocidad de desarrollo o problemas de seguridad. Por ejemplo, su equipo de ingenieros y desarrolladores podría haber estado posponiendo las actualizaciones de Ruby on Rails durante una década. De repente, el costo del proyecto aumenta en medio millón de dólares porque la versión de Ruby está cuatro generaciones por detrás, dejándolo con una masa de código y dependencias obsoletas.

Si hubiera actualizado gradualmente, no estaría en esta situación. Así que apoye a su equipo de desarrollo de software y pague a medida que avanza. De lo contrario, esa deuda técnica regresará para acosarlo, con intereses.