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?
Dentro de la metodología Agile, denominamos deuda técnica al suceso de “quitando tiempo de desarrollo actual”. Se posterga y toma el compromiso de abordarlo después, con la intención de entregar valor antes en el tiempo.
De esta simple definición, se pueden extraer varios conceptos:
En primer lugar, existe un conocimiento de que una funcionalidad o código, debe realizarse para que la solución técnica sea 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.
Siendo conscientes de ello, y habiendo decidido qué partes técnicas se pueden quedar fuera, ya que 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.
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 de forma imperativa que sea cumplida. Esto no siempre puede darse, pero en caso de que ocurra, debemos mantener en nuestra mente 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.
Si hemos entendido bien el concepto, tiene que 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 tomado el compromiso por ambas partes.
La deuda técnica se puede originar por muchas causas: desconocimiento técnico, falta de requisitos, mala comunicación. Pero siempre debe ser detectada y negociada. Si no, se tratará de una mala praxis.
Como personas dedicadas al desarrollo de Software, debemos ser consientes de que nos vamos a enfrentar a la deuda técnica a diario, por distintas causas: desconocimiento técnico, tiempos de entrega, expectativas, 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:
tech-debt.md dentro del proyecto y enlazarlo a tu README.md. Evitar sorpresas es importante.Evitemos esto:
Y tendamos a esto:
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista