Retrospectiva de deuda técnica

Detecta, prioriza y planifica cómo saldar tu deuda técnica

Pruebe esta retransmisión en directo retrospectiva

Fuentes de deuda

¿Qué áreas del código han acumulado deuda técnica?

El módulo de autenticación de usuarios es demasiado complejo y difícil de mantener por la cantidad de parches y soluciones provisionales acumulados con el tiempo.
Tenemos mucho código duplicado en distintos componentes que deberíamos refactorizar en utilidades compartidas.
Muchos de nuestros modelos de datos principales están muy acoplados, así que ampliar o modificar funcionalidades conlleva riesgo de regresiones.
Impacto y riesgos

¿Cómo afecta esta deuda técnica al equipo y al producto?

Incorporar a nuevos desarrolladores es dificilísimo por la complejidad y la falta de documentación en algunas áreas.
Nos pasamos el día apagando fuegos y no conseguimos entregar nuevas funcionalidades a un ritmo razonable por la inestabilidad que provoca la deuda.
Nuestro proceso de despliegue es frágil y propenso a errores, lo que provoca incidencias y caídas frecuentes en producción.
Priorización

¿Qué áreas de deuda deberíamos abordar primero?

Deberíamos empezar por el módulo de autenticación, ya que es una dependencia central que afecta a varias partes de la aplicación.
Mejorar la cobertura de pruebas de los componentes más inestables nos daría una base sólida para futuras refactorizaciones.
Actualizar el frontend a la última versión de React debería ser una prioridad máxima para aprovechar las mejoras de rendimiento y las nuevas funcionalidades.
Plan de acción

¿Cómo podemos abordar de forma sistemática la deuda priorizada?

Dedicaremos el 20 % de cada sprint a los elementos de deuda de mayor prioridad, empezando por la refactorización del módulo de autenticación.
Cada dos semanas tendremos un día dedicado a «amortizar deuda» para hacer mejoras incrementales según la priorización.
Durante el próximo trimestre, un desarrollador sénior se dedicará por completo a liderar nuestros esfuerzos de reducción de deuda técnica.

¿Qué es una retrospectiva de deuda técnica?

Una retrospectiva de deuda técnica es una sesión centrada en un único tema. En ella, el equipo identifica la deuda de su código o sistema, se pone de acuerdo sobre lo que está costando y decide qué saldar primero. Termina con un plan con responsables y fechas. La deuda técnica es la acumulación de atajos y soluciones poco ideales en el código. Una parte surge de priorizar la entrega a corto plazo frente a la calidad a largo plazo, otra de lagunas de conocimiento y otra de refactorizaciones que se fueron posponiendo una y otra vez. Si no se atiende, cada cambio se vuelve más lento y arriesgado. El tablero tiene cuatro columnas. En Fuentes de deuda se señalan las áreas problemáticas concretas: módulos enmarañados, código duplicado, falta de pruebas, frameworks obsoletos. Impacto y riesgos recoge lo que esa deuda está provocando en la entrega, la calidad, la incorporación de nuevas personas y la moral del equipo. Priorización ordena los elementos según su impacto, esfuerzo e importancia. Plan de acción convierte los elementos principales en trabajo con responsables, plazos y revisiones periódicas, como reservar una parte fija de cada sprint para saldar deuda. Hazla más o menos cada trimestre, o siempre que el equipo note que la deuda lo está frenando, para que la deuda siga siendo visible y no crezca.

Formato de retrospectiva de deuda técnica

Fuentes de deuda

¿Qué áreas del código han acumulado deuda técnica?

Pide a las personas que concreten el tipo de deuda y dónde se encuentra: code smells, problemas de arquitectura, falta de pruebas, dependencias obsoletas.

Impacto y riesgos

¿Cómo afecta esta deuda técnica al equipo y al producto?

Hablad de lo que la deuda está costando de verdad: entregas más lentas, errores que ven los clientes, incorporaciones complicadas, desarrolladores frustrados. Los costes concretos justifican la necesidad de saldarla.

Priorización

¿Qué áreas de deuda deberíamos abordar primero?

Ordenad los elementos de deuda según su impacto, el esfuerzo que requieren y cuánto bloquean otros trabajos. Una matriz rápida de impacto frente a esfuerzo ayuda a que el equipo se ponga de acuerdo.

Plan de acción

¿Cómo podemos abordar de forma sistemática la deuda priorizada?

Elaborad un plan concreto: quién hace qué, para cuándo y cuándo revisaréis el progreso. Decidid qué parte de la capacidad de cada sprint se dedicará a saldar deuda.

Cuándo utilizar este estudio retrospectivo

  • Cuando cada cambio hace que el código sea más difícil de mantener y ampliar.
  • Cuando el equipo se pasa el tiempo apagando fuegos y las nuevas funcionalidades se retrasan una y otra vez por la inestabilidad.
  • Cuando incorporar a nuevos desarrolladores es lento porque algunas áreas son enrevesadas o no están documentadas.
  • Cuando el mantenimiento y la corrección de errores ocupan más tiempo que el trabajo nuevo.
  • Cuando los desarrolladores se frustran con las mismas áreas problemáticas sprint tras sprint.

Preguntas sugeridas para romper el hielo

  • Si nuestro código fuera un edificio, ¿cómo sería y por qué?
  • ¿Cuál ha sido tu encontronazo más divertido o más doloroso con la deuda técnica?

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

  • Mantén una conversación sin culpables. Todo código acumula deuda; la cuestión es qué hacer con ella ahora.
  • Asegúrate de que las personas no técnicas presentes entienden qué es la deuda técnica y por qué afecta a la entrega.
  • Prioriza la deuda según su impacto, esfuerzo e importancia en lugar de intentar arreglarlo todo a la vez.
  • Asigna al plan plazos, responsables y revisiones periódicas para que no se estanque.
  • Reserva una parte fija de cada sprint o ciclo para saldar deuda.
  • Automatiza el linting, las pruebas y parte de la revisión de código para que entre menos deuda nueva.

Preguntas frecuentes

¿Qué es una retrospectiva de deuda técnica?
Es una reunión del equipo centrada en detectar dónde se ha acumulado deuda técnica, hablar de lo que está costando, decidir qué abordar primero y planificar cómo saldarla.
¿Cuándo conviene hacer una retrospectiva de deuda técnica?
Hazla cuando notes que las entregas se ralentizan, que se repiten errores o que se han acumulado atajos de decisiones pasadas. Muchos equipos también la hacen con una frecuencia fija, por ejemplo una vez al trimestre, además de sus retrospectivas de sprint habituales.
¿Cómo se prioriza la deuda técnica en la retrospectiva?
Puntúa cada elemento según su impacto, esfuerzo e importancia en lugar de abordarlo todo a la vez. Después, convierte los elementos principales en un plan de acción con responsables y plazos.
¿Quién debería asistir a una retrospectiva de deuda técnica?
Los desarrolladores que trabajan en el código, además del product owner o quien fije las prioridades. Si la persona que decide qué se construye no está, el plan rara vez consigue hueco en el sprint.
¿Cuánto tiempo deberíamos dedicar a saldar deuda técnica?
No hay una cifra correcta única. Muchos equipos reservan una parte fija de cada sprint, lo que mantiene un ritmo constante de amortización en lugar de esperar a un sprint de limpieza que nunca llega.

Plantillas relacionadas

Retrospectiva de corrección de bugs

Descubre por qué surgen los bugs y evita que se repitan

Retrospectiva de revisión de código

Haz que las revisiones de código de tu equipo sean más rápidas y útiles

Proceso de desarrollo de producto

Aléjate de los sprints y revisa cómo construyes tus productos.

Retrospectiva DevOps

Revisa despliegues, incidentes y traspasos entre desarrollo y operaciones.

¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva