Deuda técnica: Difference between revisions
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
''' | {{Meta-bok|min=5}} | ||
La '''deuda técnica''' es el coste diferido que se asume cuando se elige una solución más rápida pero de menor calidad en lugar de la más adecuada. Al igual que una deuda financiera, genera "intereses": cuanto más tiempo pasa sin resolverse, más trabajo adicional requiere mantener, extender o corregir el código afectado. | |||
La deuda técnica | El término fue acuñado por Ward Cunningham en 1992 a partir de una analogía con el crédito financiero: igual que un préstamo permite obtener liquidez a corto plazo a costa de intereses futuros, las soluciones técnicas incompletas o deficientes proporcionan un beneficio inmediato —entregar antes— pero generan un coste creciente que tarde o temprano hay que afrontar. | ||
* Documentación escasa, incompleta o | |||
* Errores. | == Por qué se genera == | ||
La deuda técnica no siempre es producto del descuido. Puede surgir de decisiones conscientes y justificadas: | |||
* Necesidad de entregar antes de una fecha crítica, aceptando que habrá que volver a mejorar el código. | |||
* Falta de conocimiento en el momento de implementar: lo que era la mejor solución disponible entonces no lo es después de aprender más. | |||
* Cambios en los requisitos que hacen que código bien escrito deje de ser adecuado. | |||
* Presión externa que sacrifica calidad técnica por velocidad percibida. | |||
Lo que convierte la deuda técnica en un problema no es que exista, sino que no se gestione. | |||
== Manifestaciones habituales == | |||
* Documentación escasa, incompleta o desactualizada. | |||
* Errores conocidos y no resueltos. | |||
* Ausencia o deficiente control de versiones. | * Ausencia o deficiente control de versiones. | ||
* Arquitectura no escalable. | * Arquitectura no escalable. | ||
* Rigidez para actualizar a nuevas tecnologías o plataformas. | * Rigidez para actualizar a nuevas tecnologías o plataformas. | ||
== | * Pruebas insuficientes o de mala calidad. | ||
* Código duplicado o sin refactorizar. | |||
== Clasificación == | |||
Las deudas técnicas pueden clasificarse en dos dimensiones: | |||
* '''Advertidas vs. inadvertidas:''' si el equipo es consciente de la deuda en el momento en que se genera o no lo descubre hasta más tarde. | |||
* '''Prudentes vs. imprudentes:''' si se realizó un análisis de coste-beneficio antes de aceptarla o se asumió sin evaluación. | |||
La deuda advertida y prudente es gestionable: el equipo sabe que existe, sabe por qué y puede planificar cuándo abordarla. La deuda inadvertida e imprudente es la más peligrosa porque es invisible hasta que genera problemas. | |||
== El diario de deuda técnica == | |||
Una herramienta habitual para gestionar la deuda técnica advertida es el '''diario de deuda técnica''': una lista que registra las deudas conocidas con su contexto y su fecha de detección. Una opción muy extendida es usar las listas de tareas de los entornos de desarrollo, que escanean automáticamente el código en busca de etiquetas como: | |||
* '''FIXME:''' código que falla o puede fallar en determinadas circunstancias. | |||
* '''TODO:''' mejoras a realizar en el futuro. | |||
* '''NOTE:''' funcionamiento interno o dificultades no documentadas. | |||
* '''XXX / KLUDGE / HACK:''' código ineficiente o poco elegante que funciona pero no está bien resuelto. | |||
Incluir la fecha en el comentario facilita el seguimiento. Con esta información el equipo puede decidir cuándo ha llegado el momento de detener el avance de nuevas funcionalidades para saldar la deuda acumulada. | |||
== Deuda técnica y la IA generativa == | |||
La adopción masiva de herramientas de generación de código está creando un nuevo vector de deuda técnica que los equipos deben aprender a gestionar: | |||
El [[vibe coding]] —escribir código conversacionalmente con un asistente de IA hasta que "funciona"— es extraordinariamente productivo para prototipos y funcionalidades simples. El problema es que genera deuda técnica a una velocidad sin precedentes: el código producido tiende a ser poco modular, con duplicaciones, sin cobertura de pruebas y difícil de mantener. | |||
Un estudio de METR publicado en julio de 2025 con 16 desarrolladores experimentados encontró que cuando usaban herramientas de IA en sus propios repositorios de código, tardaban un 19% más en completar sus tareas, aunque creían haber ido un 20% más rápido. La percepción de velocidad no coincidía con la realidad medida. | |||
<div class="bok-aviso"> | |||
La IA genera código rápido. La [[refactorización]], las pruebas y la [[revisión por pares]] siguen siendo responsabilidad humana. Sin ellas, la deuda técnica crece de forma exponencial, no lineal: a más código generado sin revisar, más difícil y costoso resulta cada nueva modificación. La [[Definición de hecho|DoD reforzada]] para equipos con IA existe precisamente para contener este riesgo. | |||
</div> | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Tratar la deuda técnica como algo que "ya se arreglará cuando haya tiempo".''' El tiempo para arreglar la deuda técnica nunca llega si no se planifica: siempre hay funcionalidades nuevas que compiten por la capacidad del equipo. La deuda no pagada genera intereses crecientes que reducen progresivamente la velocidad del equipo. La práctica recomendada es reservar una proporción de la capacidad de cada sprint para saldar deuda técnica antes de que se vuelva inmanejable. | |||
</div> | |||
== Véase también == | |||
== | |||
<div class="bok-tags"> | |||
[[Refactorización]] [[TDD]] [[Agilidad técnica]] [[Definición de hecho]] [[Pair programming]] [[Deuda técnica]] [[KISS]] [[Integración continua]] | |||
</div> | |||
<div class="bok-ecosistema"> | |||
<div class="texto"> | |||
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span> | |||
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span> | |||
</div> | |||
<div class="botones"> | |||
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div> | |||
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div> | |||
</div> | |||
</div> | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
[[Category:Prácticas técnicas]] | |||
Latest revision as of 15:01, 14 May 2026
La deuda técnica es el coste diferido que se asume cuando se elige una solución más rápida pero de menor calidad en lugar de la más adecuada. Al igual que una deuda financiera, genera "intereses": cuanto más tiempo pasa sin resolverse, más trabajo adicional requiere mantener, extender o corregir el código afectado.
El término fue acuñado por Ward Cunningham en 1992 a partir de una analogía con el crédito financiero: igual que un préstamo permite obtener liquidez a corto plazo a costa de intereses futuros, las soluciones técnicas incompletas o deficientes proporcionan un beneficio inmediato —entregar antes— pero generan un coste creciente que tarde o temprano hay que afrontar.
Por qué se genera
La deuda técnica no siempre es producto del descuido. Puede surgir de decisiones conscientes y justificadas:
- Necesidad de entregar antes de una fecha crítica, aceptando que habrá que volver a mejorar el código.
- Falta de conocimiento en el momento de implementar: lo que era la mejor solución disponible entonces no lo es después de aprender más.
- Cambios en los requisitos que hacen que código bien escrito deje de ser adecuado.
- Presión externa que sacrifica calidad técnica por velocidad percibida.
Lo que convierte la deuda técnica en un problema no es que exista, sino que no se gestione.
Manifestaciones habituales
- Documentación escasa, incompleta o desactualizada.
- Errores conocidos y no resueltos.
- Ausencia o deficiente control de versiones.
- Arquitectura no escalable.
- Rigidez para actualizar a nuevas tecnologías o plataformas.
- Pruebas insuficientes o de mala calidad.
- Código duplicado o sin refactorizar.
Clasificación
Las deudas técnicas pueden clasificarse en dos dimensiones:
- Advertidas vs. inadvertidas: si el equipo es consciente de la deuda en el momento en que se genera o no lo descubre hasta más tarde.
- Prudentes vs. imprudentes: si se realizó un análisis de coste-beneficio antes de aceptarla o se asumió sin evaluación.
La deuda advertida y prudente es gestionable: el equipo sabe que existe, sabe por qué y puede planificar cuándo abordarla. La deuda inadvertida e imprudente es la más peligrosa porque es invisible hasta que genera problemas.
El diario de deuda técnica
Una herramienta habitual para gestionar la deuda técnica advertida es el diario de deuda técnica: una lista que registra las deudas conocidas con su contexto y su fecha de detección. Una opción muy extendida es usar las listas de tareas de los entornos de desarrollo, que escanean automáticamente el código en busca de etiquetas como:
- FIXME: código que falla o puede fallar en determinadas circunstancias.
- TODO: mejoras a realizar en el futuro.
- NOTE: funcionamiento interno o dificultades no documentadas.
- XXX / KLUDGE / HACK: código ineficiente o poco elegante que funciona pero no está bien resuelto.
Incluir la fecha en el comentario facilita el seguimiento. Con esta información el equipo puede decidir cuándo ha llegado el momento de detener el avance de nuevas funcionalidades para saldar la deuda acumulada.
Deuda técnica y la IA generativa
La adopción masiva de herramientas de generación de código está creando un nuevo vector de deuda técnica que los equipos deben aprender a gestionar:
El vibe coding —escribir código conversacionalmente con un asistente de IA hasta que "funciona"— es extraordinariamente productivo para prototipos y funcionalidades simples. El problema es que genera deuda técnica a una velocidad sin precedentes: el código producido tiende a ser poco modular, con duplicaciones, sin cobertura de pruebas y difícil de mantener.
Un estudio de METR publicado en julio de 2025 con 16 desarrolladores experimentados encontró que cuando usaban herramientas de IA en sus propios repositorios de código, tardaban un 19% más en completar sus tareas, aunque creían haber ido un 20% más rápido. La percepción de velocidad no coincidía con la realidad medida.
La IA genera código rápido. La refactorización, las pruebas y la revisión por pares siguen siendo responsabilidad humana. Sin ellas, la deuda técnica crece de forma exponencial, no lineal: a más código generado sin revisar, más difícil y costoso resulta cada nueva modificación. La DoD reforzada para equipos con IA existe precisamente para contener este riesgo.
Error frecuente
Tratar la deuda técnica como algo que "ya se arreglará cuando haya tiempo". El tiempo para arreglar la deuda técnica nunca llega si no se planifica: siempre hay funcionalidades nuevas que compiten por la capacidad del equipo. La deuda no pagada genera intereses crecientes que reducen progresivamente la velocidad del equipo. La práctica recomendada es reservar una proporción de la capacidad de cada sprint para saldar deuda técnica antes de que se vuelva inmanejable.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.