6 min lectura • Guide 628 of 877
Flujos de Trabajo para Mejora de Calidad de Código
Mejorar la calidad de código requiere flujos de trabajo sistemáticos que hagan visible la calidad y la mejora alcanzable junto con el trabajo regular de features. GitScrum ayuda a los equipos a rastrear iniciativas de calidad, equilibrar mejoras técnicas con entregables de negocio y medir el impacto de las inversiones en calidad a lo largo del tiempo.
Estructura del Flujo de Trabajo de Calidad
Asignación de Presupuesto de Calidad
ASIGNACIÓN DE CAPACIDAD DE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAPACIDAD DEL SPRINT (100 puntos): │
│ │
│ Features: 60-70% ████████████████████░░░░░░ │
│ Calidad: 15-20% █████░░░░░░░░░░░░░░░░░░░░ │
│ Bug fixes: 10-15% ████░░░░░░░░░░░░░░░░░░░░░ │
│ Buffer: 5-10% ███░░░░░░░░░░░░░░░░░░░░░░ │
│ │
│ EL PRESUPUESTO DE CALIDAD INCLUYE: │
│ • Refactoring │
│ • Mejoras de cobertura de tests │
│ • Documentación │
│ • Reducción de deuda técnica │
│ • Mejoras de code review │
└─────────────────────────────────────────────────────────────┘
Tipos de Tareas de Calidad
CATEGORÍAS DE TRABAJO DE CALIDAD:
┌─────────────────┬───────────────────────────────────────────┐
│ CATEGORÍA │ EJEMPLOS │
├─────────────────┼───────────────────────────────────────────┤
│ Refactoring │ • Extraer patrones comunes │
│ │ • Mejorar nombres y estructura │
│ │ • Reducir complejidad │
├─────────────────┼───────────────────────────────────────────┤
│ Testing │ • Agregar tests unitarios │
│ │ • Mejorar tests de integración │
│ │ • Agregar cobertura de edge cases │
├─────────────────┼───────────────────────────────────────────┤
│ Documentación │ • Comentarios para lógica compleja │
│ │ • Documentación de API │
│ │ • Registros de decisiones arquitectónicas │
├─────────────────┼───────────────────────────────────────────┤
│ Tooling │ • Reglas de linting │
│ │ • Mejoras de CI/CD │
│ │ • Experiencia de desarrollador │
└─────────────────┴───────────────────────────────────────────┘
Identificación de Mejoras
Métricas de Calidad de Código
MÉTRICAS A RASTREAR:
┌─────────────────────┬───────────────────┬───────────────────┐
│ MÉTRICA │ MEDIDA │ OBJETIVO │
├─────────────────────┼───────────────────┼───────────────────┤
│ Cobertura de Tests │ Líneas cubiertas %│ > 80% │
│ Duplicación Código │ Bloques duplicados│ < 3% │
│ Complejidad Ciclom. │ Prom por función │ < 10 │
│ Ratio Deuda Técnica │ Tiempo remediación│ < 5% │
│ Code Smells │ Cantidad │ Decreciendo │
│ Densidad de Bugs │ Bugs por KLOC │ < 0.5 │
└─────────────────────┴───────────────────┴───────────────────┘
Análisis de Hotspots
IDENTIFICANDO HOTSPOTS DE CALIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIORIZAR POR: │
│ │
│ Frecuencia de Cambio × Complejidad = Prioridad de Mejora │
│ │
│ ALTA PRIORIDAD: │
│ Archivos cambiados frecuentemente + alta complejidad │
│ → Mayor retorno de inversión en mejora │
│ │
│ MENOR PRIORIDAD: │
│ Archivos rara vez cambiados + alta complejidad │
│ → Complejo pero estable, menor riesgo │
│ │
│ Rastrear en GitScrum: │
│ • Crear tarea de calidad por hotspot │
│ • Vincular a historial de bugs │
│ • Etiquetar con "quality-hotspot" │
└─────────────────────────────────────────────────────────────┘
Proceso de Mejora de Calidad
Regla Boy Scout
MEJORA INCREMENTAL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "Deja el código mejor de como lo encontraste" │
│ │
│ AL TRABAJAR EN UNA FEATURE: │
│ │
│ Mejoras pequeñas (sin tarea extra necesaria): │
│ • Renombrar variable poco clara │
│ • Extraer método pequeño │
│ • Agregar test faltante │
│ • Arreglar code smell obvio │
│ │
│ Mejoras mayores (crear tarea): │
│ • Refactoring mayor │
│ • Nueva suite de tests │
│ • Cambios de arquitectura │
│ │
│ TRACKING EN GITSCRUM: │
│ • Etiqueta "boy-scout" para mejoras oportunistas │
│ • No cuenta contra capacidad de features │
│ • Reconocer en retrospectivas │
└─────────────────────────────────────────────────────────────┘
Sprints de Calidad
SPRINT DEDICADO A CALIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CUÁNDO USAR: │
│ • Deuda técnica acumulada significativa │
│ • Antes de fase de crecimiento importante │
│ • Después de feature rush │
│ • Anualmente para "limpieza de primavera" │
│ │
│ ESTRUCTURA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint de Calidad - 2 Semanas ││
│ │ ││
│ │ Semana 1: ││
│ │ • Identificar áreas de mayor impacto ││
│ │ • Refactoring de hotspots ││
│ │ • Agregar tests críticos ││
│ │ ││
│ │ Semana 2: ││
│ │ • Completar refactoring ││
│ │ • Actualizar documentación ││
│ │ • Mejorar tooling ││
│ │ ││
│ │ Objetivo: Reducir deuda técnica en 30% ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Métricas de Progreso
Dashboard de Calidad en GitScrum
TRACKING DE MEJORA DE CALIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROGRESO MENSUAL: │
│ │
│ Cobertura: 68% → 75% ▲ +7% │
│ Complejidad: 15 → 12 ▼ -20% (mejor) │
│ Deuda: 25d → 18d ▼ -28% │
│ Bugs prod: 12 → 8 ▼ -33% │
│ │
│ TAREAS DE CALIDAD COMPLETADAS: │
│ • 8 refactorings │
│ • 15 tests agregados │
│ • 3 documentaciones actualizadas │
│ • 2 mejoras de CI/CD │
│ │
│ TENDENCIA: │
│ ██████████████████████▲ Mejorando │
│ │
└─────────────────────────────────────────────────────────────┘