Guía de Scrum · Artefactos y prácticas
Deuda técnica en Scrum: cómo detectarla y gestionarla
La deuda técnica es el coste futuro de los atajos que se toman hoy: código hecho con prisas, pruebas que faltan, herramientas obsoletas. Como la deuda financiera, un poco puede ser útil, pero sin gestionarla ralentiza cada Sprint.
Puntos clave
- La deuda técnica es el coste futuro de los atajos de hoy.
- Hágala visible en el Product Backlog.
- Evite nueva deuda con una Definición de Terminado exigente.
De dónde procede
- La presión de los plazos que lleva a tomar atajos.
- Una Definición de Terminado débil.
- Falta de pruebas automatizadas.
- Bibliotecas e infraestructura obsoletas.
- Conocimiento que solo tiene una persona.
- Requisitos que cambiaron después de construir el diseño.
Señales de una deuda creciente
- Descendente o irregular velocidad.
- Más defectos que llegan a los usuarios.
- Los cambios sencillos tardan más.
- Developers reacios a tocar determinadas áreas.
Cómo gestionarla en Scrum
- Hágala visible: añada elementos de deuda al Product Backlog con una descripción clara de su coste.
- Refuerce la Definición de Terminado para que no se genere nueva deuda.
- Reserve capacidad en cada Sprint, por ejemplo una parte del trabajo del equipo, para reducir la deuda.
- Refactorice de forma continua como parte del trabajo habitual.
- Trátela en la Sprint Review para que los interesados entiendan la contrapartida.
Explicar la deuda a los interesados
Plantee la deuda en términos de negocio: «Cambiar esta área lleva el triple de tiempo y provoca la mayoría de nuestras incidencias en producción. Invertir dos Sprints aceleraría todo el trabajo futuro en ella».
Plantillas gratuitas sobre este tema
Preguntas frecuentes
¿Quién decide cuándo saldar la deuda técnica?
El Product Owner ordena el backlog, con la información de los Developers, que explican el coste de la deuda.
¿Es mala toda la deuda técnica?
No. Una deuda deliberada y a corto plazo para aprender rápido puede ser sensata, siempre que se registre y se salde.
¿Qué es la deuda técnica?
El coste futuro de elegir ahora una solución rápida o fácil en lugar de una mejor. Se manifiesta en cambios más lentos, más defectos y publicaciones más arriesgadas.
¿Quién acuñó el término deuda técnica?
Ward Cunningham introdujo la metáfora de la deuda en 1992 para explicar a los interesados del negocio por qué era necesaria la refactorización.
¿Cómo se mide la deuda técnica?
No existe una única medida. Los equipos usan indicios como el tiempo necesario para hacer cambios sencillos, las tasas de defectos, las herramientas de análisis de código y el tamaño de los elementos de deuda en el Product Backlog.
¿Debe incluirse la deuda técnica en el Product Backlog?
Sí. Hacer visible la deuda como elementos del Product Backlog permite al Product Owner sopesarla frente a nuevas funcionalidades.
¿Cuánto tiempo debe dedicar un equipo Scrum a la deuda técnica?
No hay ninguna regla. Muchos equipos reservan una parte de la capacidad de cada Sprint y la ajustan según cuánto les esté frenando la deuda.
¿Cómo evita la Definición de Terminado la deuda técnica?
Una Definición de Terminado exigente, que incluya pruebas, revisión de código y documentación, impide que los atajos pasen a formar parte del Incremento.
¿Cómo reduce la refactorización la deuda técnica?
La refactorización mejora la estructura interna del código sin cambiar su comportamiento. Hacerla con regularidad evita que se acumule la deuda técnica.
¿Es la deuda técnica solo un problema de software?
El término procede del software, pero existe una deuda similar en otros ámbitos, como procesos obsoletos, conocimiento no documentado o soluciones rápidas en contenidos y datos.
¿Cómo convencer a los interesados de que hay que saldar la deuda técnica?
Explíquela en términos de negocio, por ejemplo cuánto más lentos son los cambios o cuántas incidencias provoca, y muestre la ganancia esperada al corregirla en la Sprint Review.