6 min lectura • Guide 511 of 877
Cómo Gestionar Deuda Técnica con Puntos de Esfuerzo GitScrum
La deuda técnica se acumula silenciosamente hasta que paraliza la velocidad de entrega. El sistema de puntos de esfuerzo de GitScrum permite a los equipos cuantificar items de deuda junto con trabajo de features, haciendo el costo real visible a stakeholders y habilitando decisiones basadas en datos sobre cuándo y qué pagar.
Estimación de Deuda Técnica
| Tipo de Deuda | Factores de Complejidad | Puntos Típicos |
|---|---|---|
| Refactor simple | Archivo único, bien testeado | 1-2 |
| Mejora de módulo | Múltiples archivos, tests necesarios | 3-5 |
| Rediseño de componente | Cross-módulo, breaking changes | 8-13 |
| Cambio de arquitectura | Sistema completo, migración necesaria | 13-21+ |
Tracking de Deuda con Puntos de Esfuerzo
INVENTARIO DE DEUDA TÉCNICA
┌─────────────────────────────────────────────────┐
│ ESTRUCTURA DEL BACKLOG DE DEUDA │
│ │
│ Epic: Reducción de Deuda Técnica Q1 │
│ │
│ Categoría: Base de Datos (Total: 34 puntos) │
│ ├── [5 pts] Migrar a connection pooling │
│ ├── [8 pts] Agregar índices faltantes │
│ ├── [13 pts] Refactorizar uso de ORM │
│ └── [8 pts] Implementar caching de queries │
│ │
│ Categoría: Capa de API (Total: 21 puntos) │
│ ├── [3 pts] Estandarizar respuestas de error │
│ ├── [5 pts] Agregar validación de input │
│ ├── [8 pts] Implementar rate limiting │
│ └── [5 pts] Agregar versionado de API │
│ │
│ Categoría: Frontend (Total: 26 puntos) │
│ ├── [8 pts] Reemplazar state management legacy │
│ ├── [5 pts] Extraer componentes compartidos │
│ ├── [8 pts] Agregar TypeScript strict mode │
│ └── [5 pts] Mejorar bundle splitting │
│ │
│ TOTAL BACKLOG DEUDA: 81 puntos │
└─────────────────────────────────────────────────┘
Asignación de Capacidad de Sprint
PLANIFICACIÓN DE SPRINT CON ASIGNACIÓN DE DEUDA
VELOCIDAD DEL EQUIPO: 40 puntos/sprint
┌─────────────────────────────────────────────────┐
│ DIVISIÓN DE CAPACIDAD: │
│ │
│ Desarrollo de Features: 28 puntos (70%) │
│ ├── User stories │
│ └── Nueva funcionalidad │
│ │
│ Deuda Técnica: 8 puntos (20%) │
│ ├── Refactoring │
│ ├── Mejoras de tests │
│ └── Actualizaciones de arquitectura │
│ │
│ Mantenimiento: 4 puntos (10%) │
│ ├── Bug fixes │
│ └── Actualizaciones de dependencias │
└─────────────────────────────────────────────────┘
CRITERIOS DE SELECCIÓN DE DEUDA PARA SPRINT:
┌─────────────────────────────────────────────────┐
│ Orden de prioridad: │
│ 1. Deuda bloqueando features planificados │
│ 2. Deuda causando issues de producción │
│ 3. Deuda desacelerando velocidad │
│ 4. Deuda con implicaciones de seguridad │
│ 5. Quick wins (alto impacto, bajo esfuerzo) │
└─────────────────────────────────────────────────┘
Guía de Estimación de Puntos de Deuda
ESTIMACIÓN DE PUNTOS DE ESFUERZO PARA DEUDA
1 PUNTO - Trivial
┌─────────────────────────────────────────────────┐
│ • Renombrar para claridad │
│ • Agregar null check faltante │
│ • Actualizar comentario desactualizado │
│ • Arreglar code smell simple │
│ Tiempo: < 2 horas │
└─────────────────────────────────────────────────┘
2-3 PUNTOS - Simple
┌─────────────────────────────────────────────────┐
│ • Extraer método/función │
│ • Agregar tests faltantes para una función │
│ • Reemplazar llamada a librería deprecada │
│ • Arreglar duplicación de código en archivo │
│ Tiempo: 2-4 horas │
└─────────────────────────────────────────────────┘
5 PUNTOS - Medio
┌─────────────────────────────────────────────────┐
│ • Refactorizar una clase/módulo │
│ • Agregar cobertura de test para componente │
│ • Reemplazar patrón en múltiples archivos │
│ • Extraer utilidad compartida │
│ Tiempo: 1-2 días │
└─────────────────────────────────────────────────┘
8 PUNTOS - Grande
┌─────────────────────────────────────────────────┐
│ • Refactorizar dependencia cross-módulo │
│ • Reemplazar librería deprecada │
│ • Agregar capa de caching │
│ • Cambio significativo infraestructura tests │
│ Tiempo: 2-4 días │
└─────────────────────────────────────────────────┘
13 PUNTOS - Muy Grande
┌─────────────────────────────────────────────────┐
│ • Rediseño de arquitectura de componente │
│ • Overhaul de state management │
│ • Migración de schema de base de datos │
│ • Upgrade de versión mayor (framework) │
│ Tiempo: 1-2 semanas │
└─────────────────────────────────────────────────┘
Dashboard de Métricas de Deuda
SALUD DE DEUDA TÉCNICA
INVENTARIO DE DEUDA:
┌─────────────────────────────────────────────────┐
│ Total backlog de deuda: 81 puntos │
│ Deuda crítica: 21 puntos (26%) │
│ Prioridad alta: 34 puntos (42%) │
│ Prioridad normal: 26 puntos (32%) │
└─────────────────────────────────────────────────┘
PROGRESO DE SPRINT:
┌─────────────────────────────────────────────────┐
│ Sprint Agregado Removido Cambio Neto │
│ ───────────────────────────────────────────── │
│ Sprint 14 5 pts 8 pts -3 pts ↓ │
│ Sprint 15 3 pts 10 pts -7 pts ↓ │
│ Sprint 16 8 pts 6 pts +2 pts ↑ │
│ Sprint 17 2 pts 12 pts -10 pts ↓ │
│ ───────────────────────────────────────────── │
│ Trimestre 18 pts 36 pts -18 pts ↓ │
└─────────────────────────────────────────────────┘
IMPACTO EN VELOCIDAD:
┌─────────────────────────────────────────────────┐
│ Antes reducción deuda: 32 pts/sprint │
│ Después reducción: 40 pts/sprint (+25%) │
│ │
│ Inversión deuda: 32 puntos en 4 sprints │
│ Ganancia velocidad: 8 pts × 4 sprints = 32 pts │
│ ROI: Ya positivo, continúa creciendo │
└─────────────────────────────────────────────────┘
Mejores Prácticas
- Estimar deuda como features usando misma escala de puntos
- Asignar capacidad consistente (15-25% por sprint)
- Rastrear backlog de deuda por separado pero visible
- Priorizar deuda por impacto en velocidad y calidad
- Celebrar reducción de deuda como logro del equipo
- Medir mejoras de velocidad del trabajo de deuda
- Agregar contexto a items de deuda (por qué importa)
- Evitar bancarrota de deuda con pagos consistentes
Anti-Patrones
✗ No estimar items de deuda
✗ Sin capacidad dedicada para deuda
✗ Deuda solo cuando "tenemos tiempo"
✗ Items grandes sin desglose
✗ Sin tracking de deuda agregada vs removida
✗ Tratar deuda como trabajo menor