Desde hace ya varios años, se habla y se discute sobre la deuda técnica como de algo sabido por todos. Sin embargo, en mi experiencia, este no es un tema suficientemente analizado o comprendido por la generalidad de los desarrolladores y los ejecutivos que conozco.

¿A qué nos referimos con el concepto de "deuda técnica"?... básicamente, con este término nos referimos a todas esas decisiones tanto hardware como software, que puedan comprometer la calidad o el funcionamiento del producto. Un ejemplo: desarrollar un sistema software sin pruebas unitarias para minimizar los tiempos de desarrollo por una necesidad urgente de oportunidad o de mercado.

La idea es que "puede ser algo que ahora funciona o tiene sentido", pero que en realidad pagaremos en el futuro cuando suframos las consecuencias de nuestras decisiones (por ejemplo dificultad para mantener el sistema, calidad insuficiente, etc)

Dicho de este modo, pareciera que el concepto de deuda técnica queda claro, y de hecho es un concepto simple, pero hay muchos grises en esta definición ya que queda librada al juicio de un equipo o de una persona, por lo que las interpretaciones pueden diferir entre equipos o personas.

Veamos algunos conceptos que creo son importantes al momento de identificar estas situaciones:

Publicado en Scrum
Volver arriba