Cuando algo dentro de nuestro software no está desarrollado de la mejor forma posible, es mejorable, quedan cosas por hacer o surge algún error, existe el hábito de decir que se trata de deuda técnica. Sin embargo, ¿es esto cierto? ¿Dónde están los límites de este término?
Definición
Dentro de la metodología Agile, denominamos deuda técnica al suceso de quitar tiempo de desarrollo actual. Se posterga y se toma el compromiso de abordarlo después, con la intención de entregar valor antes en el tiempo.
De esta definición se pueden extraer varios conceptos.
Quitando tiempo de desarrollo actual
En primer lugar, existe un conocimiento de que una funcionalidad o un código debe realizarse para que la solución técnica quede desarrollada y funcione dentro de los estándares acordados. Cuando existe este conocimiento, pero por requisitos de negocio es necesario entregar una funcionalidad antes en el tiempo, buscamos la forma de recortar esos flecos adicionales.
Se posterga y se toma el compromiso
Siendo conscientes de ello y habiendo decidido qué partes técnicas se pueden quedar fuera porque no tienen un impacto inmediato en negocio, se puede tomar el acuerdo de “ganar tiempo al futuro”. En lugar de hacerlo en ese momento, se abordará a posteriori, pero con el compromiso de que se hará. Esto quiere decir que no se trata de un recorte en sí, sino de mover en el tiempo una acción.
Entregar valor antes en el tiempo
Cuando hablamos de entregar valor antes de tiempo, no debe ser una decisión por parte de desarrollo, sino de negocio. Negocio tiene una necesidad que necesita que sea cumplida de forma imperativa. Esto no siempre puede darse, pero si ocurre debemos recordar que estamos desarrollando un producto, y sin producto no hay negocio. Para que el producto tenga la calidad esperada, se debe abordar dicha deuda, porque es uno de los requisitos necesarios.
La deuda técnica debe ser acordada por negocio y el equipo de desarrollo. Si ambas partes no tienen visibilidad de ello, no se puede realizar dicha replanificación.
¿Qué no es deuda técnica?
Si hemos entendido bien el concepto, debe quedarnos claro que, si no hemos sido capaces de detectar esta deuda, no es otra cosa que mal software, bugs o una funcionalidad no definida. Pero desde luego no es deuda, ya que en ningún momento se ha detectado ni se ha tomado el compromiso por ambas partes.
La deuda técnica se puede originar por muchas causas: desconocimiento técnico, falta de requisitos o mala comunicación. Pero siempre debe ser detectada y negociada. Si no, se tratará de una mala praxis.
Conclusión
Como personas dedicadas al desarrollo de software, debemos ser conscientes de que nos vamos a enfrentar a la deuda técnica a diario, por distintas causas: desconocimiento técnico, tiempos de entrega, expectativas o complejidad inesperada. Y puede llegar a ser frustrante si no se maneja de la forma correcta. Para no llegar a este punto, son importantes varios factores:
- Documentar la deuda: puedes recoger esta información en un fichero
tech-debt.mddentro del proyecto y enlazarlo a tuREADME.md. Evitar sorpresas es importante. - Ser transparente: cuando existe un conocimiento de ello, es más sencillo abordarlo. De hecho, en muchas ocasiones, si las personas responsables tienen conocimiento del mismo, es muy posible que esta deuda no se llegue a generar porque puedan renegociar expectativas con negocio.
- No dejar que se acumule: es más sencillo limpiar un poco todos los días que limpiar una vez cada cuatro meses. Cuando el trabajo se acumula es más estresante.
Evitemos esto:
Y tendamos a esto:
