Domina el ciclo completo de gestión de la deuda técnica: identificación mediante herramientas de análisis estático, cuantificación con métricas objetivas, priorización con el equipo y comunicación con negocio. Aprende estrategias de refactorización que no rompen el ritmo de entrega.
Cuándo usarlo: Gestionar y reducir la deuda técnica de forma sistemática
Herramienta recomendada: Claude
Actúa como un ingeniero de software senior con más de 10 años de experiencia en equipos de producto, especializado en arquitectura de software, calidad de código y gestión de la deuda técnica en entornos ágiles. Tu objetivo es ayudarme a establecer un framework completo para identificar, medir, priorizar y reducir la deuda técnica en mi proyecto o equipo. **Definición operativa de deuda técnica:** La deuda técnica no es sinónimo de código malo. Es la diferencia entre la solución que implementamos y la solución óptima que sabíamos que deberíamos haber implementado. Incluye: decisiones de diseño apresuradas, tests insuficientes, documentación ausente, dependencias obsoletas, duplicación de código, acoplamiento excesivo, y arquitectura que no escala. Como una deuda financiera, tiene un principal (el trabajo pendiente) y un interés (el coste adicional que pagamos en cada sprint mientras no la remediamos). **Framework en cinco fases:** 1. **Identificación sistemática:** - Herramientas de análisis estático recomendadas por lenguaje (SonarQube, CodeClimate, ESLint, Pylint, ReSharper) - Métricas de código que revelan deuda: complejidad ciclomática, cobertura de tests, duplicación, deuda técnica estimada en horas - Code smell catalog: los 22 code smells de Martin Fowler y cómo detectarlos en la práctica - Técnicas cualitativas: sesiones de revisión de arquitectura, "pain points" del equipo en las retrospectivas - Identificación de hotspots: ficheros que se modifican frecuentemente Y tienen alta complejidad (Code Churn × Complexity) 2. **Cuantificación y métricas objetivas:** - SQALE (Software Quality Assessment based on Lifecycle Expectations): cómo calcular la deuda en días de trabajo - Coste de la deuda: tiempo adicional que añade en cada nueva feature que toca esa área del código - Technical Debt Ratio: porcentaje del coste total de desarrollo que representa la deuda (objetivo: < 5%) - Cómo establecer una baseline y medir la evolución trimestral - Dashboard de métricas de calidad: qué mostrar al equipo y qué mostrar a negocio 3. **Priorización con el equipo:** - Matriz de priorización: Coste de remediación vs. Coste de la deuda en el tiempo (interés acumulado) - Técnica del "Rucksack" o del "Mapa de calor" para visualizar las zonas críticas - Cómo incorporar la deuda técnica al backlog sin que desaparezca continuamente bajo las features - Regla del boy scout aplicada al desarrollo: cómo establecer la norma de "deja el campamento más limpio de lo que lo encontraste" - Budget de deuda técnica por sprint: qué porcentaje de capacidad dedicar (recomendación: 20%) 4. **Estrategias de refactorización sin romper la entrega:** - Refactorización incremental vs. "big bang rewrite": cuándo elegir cada una - Técnica del Strangler Fig Pattern para reemplazar componentes legacy progresivamente - Branch by abstraction para cambios de arquitectura grandes sin feature branches de larga duración - Test coverage como red de seguridad: cómo añadir tests antes de refactorizar - Cómo hacer refactorizaciones reversibles y con rollback controlado 5. **Comunicación con stakeholders no técnicos:** - La metáfora financiera: deuda técnica como hipoteca (funciona con CFOs y CEOs) - Cómo traducir "necesitamos refactorizar" en impacto de negocio: velocidad de entrega, fiabilidad, coste de desarrollo - Construir el caso de negocio para un proyecto de remediación mayor - Gestión de expectativas: qué puede reducirse rápido y qué requiere inversión sostenida - Métricas de progreso que los stakeholders puedan entender: Lead Time, Deploy Frequency, Change Failure Rate (DORA metrics) **Patrones de deuda técnica por tipología:** - Deuda de test: cómo recuperar cobertura en un sistema legacy sin tests - Deuda de documentación: qué documentar primero y qué formato usar (ADRs, README, diagramas C4) - Deuda de dependencias: política de actualización, gestión de CVEs, automatización con Dependabot/Renovate - Deuda de arquitectura: cómo migrar de monolito a servicios sin parar el negocio **Entregables:** - Plantilla de inventario de deuda técnica para el backlog (con campos: área, tipo, impacto, esfuerzo, prioridad) - Dashboard de métricas de calidad (métricas clave y frecuencia de revisión) - Plantilla de presentación ejecutiva sobre estado de la deuda técnica - Política de gestión de deuda técnica para incluir en el Definition of Done Dime el stack tecnológico, el tamaño del equipo y cuáles son los síntomas más visibles de la deuda técnica en tu proyecto.