# Auditoría de deuda técnica Convierte un código base en un registro de lo que cuesta mantenerlo — ordenado por el trabajo que bloquea cada elemento, no por su aspecto. ## Entregable Un documento Markdown, `technical-debt-register.md`, con la estructura fijada en **Salida** más abajo. Alimenta la planificación directamente: el registro ordenado es una lista de elementos que se pueden secuenciar junto al resto del trabajo. ## Entradas obligatorias - **Acceso al código base, o documentación que lo describa** — lo suficiente para localizar un elemento en un archivo o un módulo y no en una impresión. - **Qué pretende construir el equipo a continuación** — el trabajo con el que se mide la deuda. La deuda solo es deuda en relación con un cambio que alguien quiere hacer. Sin lo segundo, la salida es una lista de cosas que a alguien no le gustan. Sin ninguna de las dos, detente y repórtalo: una auditoría sin material y sin dirección produce opiniones con epígrafes encima. ## Entradas opcionales - El historial de cambios: qué se modifica más y qué se modifica siempre junto - Registros de incidencias y defectos, y las zonas del sistema a las que apuntan - La cobertura de pruebas y las partes del sistema a las que las pruebas no llegan - Registros de construcción y publicación, y dónde fallan o esperan - El relato del propio equipo sobre qué le frena, atribuido a quien lo dijo - Auditorías anteriores del mismo sistema y qué se hizo con sus hallazgos Una fuente ausente estrecha la auditoría; nunca ensancha la conjetura. Un elemento sin coste observable se registra con su coste `desconocido`, nunca con un coste que simplemente suena verosímil. ## Ejecución **1 — Acotar la auditoría.** Declara qué se examinó y qué no: qué partes del sistema, qué registros y qué periodo de historia. Una auditoría que no declara su frontera se lee como completa, y las zonas que nadie miró se leen como limpias. **2 — Reunir candidatos por evidencia, no por gusto.** Cada candidato necesita una observación detrás: un fallo, un cambio que hubo que repetir en varios sitios, una zona a la que las pruebas no llegan, un apaño que alguien describió. El código que solo resulta poco familiar o pasado de moda no es candidato y no entra en el registro. **3 — Localizar cada elemento con exactitud.** El archivo o el módulo, y la frontera del elemento dentro de él. Un elemento localizado al nivel de una capa entera no se puede planificar, ni discutir, ni verificar como arreglado. Cuando la ubicación es genuinamente difusa, dilo y nombra la frontera que lo contiene. **4 — Declarar el coste actual en términos observables.** Qué obliga a hacer hoy este elemento: el paso manual antes de una publicación, el cambio repetido en varios sitios, el fallo que reaparece, la revisión que exige una segunda persona. Cuando no se observa ningún coste, escribe `coste desconocido` en lugar de convertir una impresión en una cifra. **5 — Declarar el interés.** Qué cobra el elemento sobre el trabajo cercano: qué cambios vuelve más lentos, cuáles vuelve arriesgados y cuáles impide del todo. Esta es la sección que separa la deuda de una imperfección, y un elemento que no cobra nada sobre nada pertenece a la lista de aceptados. **6 — Dimensionar la remediación y su riesgo.** En qué consiste el arreglo, qué toca, cuánto costaría en la unidad de dimensionamiento del propio equipo si la aportó, y qué podría romperse mientras se hace — incluido el trabajo que debe detenerse alrededor. Si el equipo no aportó dimensionamiento, registra `sin dimensionar` y nombra a quién puede hacerlo. **7 — Ordenar por lo que bloquea y marcar lo aceptado.** Ordena el registro por el trabajo que bloquea cada elemento, tomado del trabajo previsto que se aportó como entrada, y nombra ese trabajo junto a cada elemento. Un elemento que no bloquea nada y no cuesta nada se registra como `aceptado` con su motivo: ni se planifica ni se borra. ## Salida `technical-debt-register.md`, en este orden: - **1. Entrada y fecha** — qué se examinó, qué no, con qué trabajo previsto se mide el registro y cuándo - **2. Registro** — por elemento: qué es, dónde está, la evidencia que lo sostiene y su coste actual - **3. Interés** — por elemento: el trabajo que ralentiza, el que vuelve arriesgado y el que impide - **4. Remediación** — por elemento: el arreglo, qué toca, su tamaño o `sin dimensionar`, y el riesgo de hacerlo - **5. Orden** — los elementos ordenados por el trabajo que bloquean, con ese trabajo nombrado junto a cada uno - **6. Aceptados** — elementos que no cuestan nada ni bloquean nada, cada uno con el motivo por el que se acepta - **7. Sin verificar** — elementos reportados por una persona y no confirmados contra el sistema - **8. Preguntas abiertas** — la pregunta, qué bloquea, quién puede responderla ## Validación El registro está listo cuando se cumple todo esto: - Cada elemento de la sección 2 nombra un archivo o un módulo y la evidencia que lo sostiene - Cada elemento de la sección 2 lleva un coste observable o la marca `coste desconocido` - Cada elemento de la sección 3 nombra al menos un trabajo al que afecta, o pasa a la sección 6 - Cada elemento de la sección 4 declara el riesgo de la remediación, no solo la remediación - La sección 5 está ordenada por el trabajo bloqueado y nombra ese trabajo junto a cada elemento - No aparece ningún tamaño, recuento ni proporción que el equipo no haya aportado Falla la ejecución si un elemento aparece sin evidencia detrás, o si el registro está ordenado por algo que no sea el trabajo que bloquea cada elemento. ## Gestión de fallos - **Sin acceso al código base** — audita la documentación aportada, coloca cada elemento en la sección 7 como sin verificar y declara que un registro construido desde documentación recoge lo que se escribió, no lo que hay. - **No se declara el trabajo previsto** — produce las secciones 1 a 4, 7 y 8, deja la sección 5 sin ordenar e informa de que sin trabajo previsto cualquier orden es cuestión de gusto. - **El equipo no aportó dimensionamiento** — registra cada remediación como `sin dimensionar`, nombra a quién debe dimensionarla y entrega el registro sin columna de tamaño en lugar de con una inventada. - **El equipo discute un hallazgo** — mantén el elemento, registra la evidencia y la objeción una al lado de la otra con ambos nombres, y elévalo a la sección 8. No retires un hallazgo observado porque resulte incómodo. - **Acceso parcial** — audita lo que fuese alcanzable, nombra en la sección 1 exactamente qué no lo fue y entrega. Una auditoría de parte de un sistema sirve cuando dice de qué parte.