Lunes, 09 Octubre 2017 10:55

Qué es la deuda técnica

Escrito por
Valora este artículo
(0 votos)
deuda técnica deuda técnica

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:

 ¿Deuda técnica es un concepto de desarrollo?

No necesariamente. Considero que la deuda técnica puede generarse en cualquier estadio del desarrollo de un producto: desde su definición, su análisis, desarrollo, testeo o implementación... nadie se salva, en todos los ámbitos puede generarse deuda técnica. De hecho, los seres humanos somos limitados y nuestros recursos también lo son, por lo tanto es inevitable que en cualquier ámbito de nuestra vida generemos "deuda técnica".

¿Deuda técnica o limitación del producto?

Antes que nada, creo necesario aclarar una diferencia conceptual entre deuda técnica y limitaciones del producto. Una deuda técnica nos muestra un diferencial entre el standard de calidad realizado y el standard que el equipo considera debería tener la solución en ese caso en particular. Las limitaciones del sistema, por el contrario, es una definición exclusiva del dueño del producto, y no se refieren a la calidad sino al alcance del proyecto.

¿Deuda técnica o riesgo?

A este respecto las diferencias parecen todavía más difusas... una deuda técnica siempre comporta un riesgo, aunque un riesgo no siempre es debido a una deuda técnica. Podemos decirlo de este modo: una situación de riesgo puede suceder o no dependiendo de varios factores (por ejemplo, factores externos) mientras que la deuda técnica subsiste al margen de otros factores externos. La deuda técnica está más vinculada a la calidad que esperamos en cada solución que se adopte, por lo que no admite probabilidades, o existe o no existe.

¿Qué herramientas poseo para identificar deudas técnicas?

En primer lugar, es necesario que el equipo tenga claro cuál es la visión del producto y

Otra de las herramientas más efectivas para la determinación de la deuda técnica es la "definición de terminado (dod)" del equipo. Este es uno de los motivos que dan sentido a este concepto. Es simple: si no cumplo con la definición de terminado por cualquier motivo, estoy generando una deuda técnica.

Pero obviamente, no podemos concordar definiciones de terminado que prevean todas las situaciones, siempre habrá particularidades que no estarán incluidas en la definición de terminado, a veces porque no aplican para todas las historias, y otras porque se busca sintetizar las definiciones de terminado para no crear burocracia o "grasa" innecesaria para el producto.

En estos casos, una buena herramienta es el contexto en la definición de la historia. Si sabemos que nuestro sistema interfacea con otros sistemas internos que ya están lo suficientemente testeados, podemos ser un poco más laxos a la hora de considerar si ciertas situaciones constituyen deuda técnica o no.

No olvidemos que una deuda técnica es siempre, fundamentalmente, un juicio expresado por el equipo... y como todos los juicios, el contexto puede modificar fundamentalmente la validez de ese juicio.

Ok tenemos una deuda técnica, ¿y ahora?

Lo primero que debemos hacer, es relevar la deuda técnica. No basta con mencionarla en una reunión o en un mail; es importante que esta deuda técnica tenga relevancia como tarea o historia, ya que será posible en el futuro incluirla como refactorización o incluso como nueva historia en futuros sprint. Después de todo no es indispensable que la calidad se aplique en el mismo momento que se detecte la deuda técnica... ya que la calidad es una inversión que se paga con tiempos, recursos, dinero, tiene sentido que el product owner tenga potestad para elegir el sprint adecuado para su corrección.

 

 

Leer 111 veces Modificado por última vez en Miércoles, 08 Noviembre 2017 07:40
elScrumMaster

Soy el creador y autor de este sitio, donde comparto mis intuiciones, conocimientos y descubrimientos a lo largo de mi vida.

Principalmente orientado a mis experiencias laborales.

Soy siempre yo, tres en uno: elCoach, elScrumamaster y elDba... y por supuesto, aunque no tenga perfil en el sitio, soy también:

  • elTrainer
  • elDesarrollador
  • elConferencista
  • .... y próximamente elAutor

 

https://www.linkedin.com/in/pabloagil/
Volver arriba