¿Qué mide una evaluación de deuda técnica?
Ward Cunningham acuñó la metáfora de la deuda técnica en su informe de experiencia de OOPSLA de 1992, donde escribió que «publicar código por primera vez es como endeudarse». Un poco de deuda puede ayudarte a ir más rápido. El problema empieza cuando no se paga y cada hora dedicada a sortear código que no está del todo bien se convierte en intereses. Los analizadores de código miden el código. Esta evaluación mide lo que el equipo vive a diario: si podéis ver la deuda, cuánto frena la entrega, cómo de sanos se perciben el código y los sistemas, y si la estáis pagando. Cada persona valora cada afirmación en privado; después lleváis las puntuaciones más bajas a una retrospectiva y acordáis qué arreglar primero.
Dimensiones
Visibilidad
Si el equipo sabe dónde está su deuda y la trata como trabajo real.
Puntos críticos conocidos
Sabemos qué partes de nuestro sistema acumulan más deuda.
Registrada junto al resto del trabajo
La deuda se registra en el mismo backlog que las funcionalidades y los errores.
Coste conocido
Podemos explicar cuánto nos cuestan nuestras mayores deudas en tiempo o en riesgo.
Impacto en la entrega
Cuánto frena la deuda el trabajo que el equipo intenta entregar.
Velocidad de las funcionalidades
La deuda rara vez ralentiza las funcionalidades que estamos desarrollando.
Cambios seguros
Cambiar una parte de nuestro sistema rara vez rompe otra parte que no tiene relación.
Builds rápidas y fiables
Nuestras builds y pruebas son rápidas y fiables.
Salud del código y de los sistemas
Lo fácil que resulta hoy trabajar con el código, los sistemas y las dependencias.
Fácil de cambiar
La mayor parte de nuestro código es fácil de entender y de cambiar.
Dependencias actualizadas
Nuestras dependencias y plataformas están razonablemente actualizadas.
Pruebas que respaldan la refactorización
Nuestras pruebas nos dan la confianza necesaria para refactorizar.
Pago de la deuda
Si el equipo avanza de forma constante y consensuada en la reducción de la deuda.
Tiempo reservado
Reservamos tiempo de forma regular para pagar la deuda.
Deuda deliberada registrada
Cuando asumimos deuda a propósito, la registramos junto con un plan para pagarla.
Prioridades compartidas
Producto e ingeniería están de acuerdo en cómo repartir el tiempo entre funcionalidades y deuda.
Cuándo debe realizarse esta revisión médica
- Cuando las funcionalidades tardan más de lo que deberían y el equipo no deja de señalar al código.
- Antes de la planificación trimestral o del roadmap, para acordar cuánto tiempo se dedica a pagar la deuda.
- Después de un gran esfuerzo o de una fecha límite exigente, para registrar los atajos que tomasteis antes de que se olviden.
Consejos y trucos
- Lee primero el grupo con la puntuación más baja. Una visibilidad baja significa que antes de nada necesitáis una lista de la deuda. Una visibilidad alta con poco pago de la deuda apunta a un problema de planificación, no de código.
- Invita a tu product manager a la conversación, aunque solo valoren los ingenieros. Cómo repartir el tiempo entre funcionalidades y deuda es una decisión compartida.
- Combina las puntuaciones con datos que ya tengas, como los tiempos de build, el número de pruebas inestables o las causas de los incidentes. La evaluación muestra dónde duele; los datos muestran cuánto.
- Hazla junto a la Autoevaluación de métricas DORA, la Evaluación de madurez DevOps o el Modelo de madurez de excelencia en ingeniería para ver cómo se relaciona la deuda con la entrega y las prácticas de ingeniería.
- Repítela cada trimestre. Una puntuación al alza en las afirmaciones sobre el pago de la deuda es la primera señal de que vuestro plan funciona.
Preguntas frecuentes
¿Cómo se mide la deuda técnica?
¿Cuáles son los cuatro tipos de deuda técnica?
¿Cuánto tiempo deberíamos dedicar a la deuda técnica?
¿Cómo se explica la deuda técnica a los product managers?
¿Qué es un ejemplo de deuda técnica?
¿Quién acuñó el término deuda técnica?
Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).