Deuda técnica: la sombra que nos persigue en cada iteración

Durante mi camino como facilitador en Scrum, como Scrum master, conversando con mis colegas surgió el tema de la “deuda técnica”, lo gracioso es que todos teníamos diferentes definiciones de la deuda técnica y como abordarla durante algún Sprint.

Luego de esa conversación me quede con la duda si lo que yo tengo claro como deuda técnica es correcto, por eso decidí investigar y leer mis sitios de referencias, a los cuales acudo cuando me surgen dudas (aparte de releer la guía de Scrum). Y esta sería mi definición de deuda técnica.

Deuda técnica

Pero que es la deuda técnica.

Este término surge en el 1992 por Ward Cunnigham , para compensar un poco lo que busca la agilidad, que es la entrega continua y de calidad de estos entregables, en cuanto a construcción de software se refiere. Y que por esa rapidez por entregar un producto nos lleve a pasar por alto pequeñas “buenas practicas” a la hora de entregar un producto.

Por ejemplo, consideremos que un  integrante de nuestro equipo developers está trabajando en una base de código, donde una parte de ella no está correctamente comentada o refactorizada, supongamos que tendrá que hacer un esfuerzo adicional de 1 día para comprender el código, y tal vez un esfuerzo adicional de prueba (supongamos también que 1 día). Ahora, este esfuerzo extra de 2 días es el impacto de la Deuda Técnica causado por la mala calidad del código.

A continuación otra forma de verlo, que lo relaciona a un interés que acumulamos como equipo:

Si tratamos de utilizar la metáfora de la deuda financiera que tiene principal e interés, la deuda técnica será:

  • Principal = Esfuerzo para arreglar el código de baja calidad
  • Interés = Cada vez que el esfuerzo de un equipo aumenta debido al código de baja calidad.

Para el primer caso de ejemplo nuestro interés será de 2 días, imaginemos esto si lo analizamos para un equipo que tenga 9 iteraciones y que nunca se hizo cargo de su interés, se convertirá en mucho esfuerzo para el equipo.

Pero el nombre de “deuda técnica” no tiene que ser siempre sinónimo de algo malo o algo que estamos haciendo mal, en ocasiones puede ser una oportunidad:

  • Crear un prototipo rápido, para mostrar a interesados el valor del producto.
  • Lanzar un producto rápido al mercado, para ganar a la competencia.
  • Reaccionar de inmediato frente a algún cambio inesperado.

La deuda técnica no es necesariamente algo malo, siempre y cuando haya un plan real para pagarla

Masterting Professional Scrum por Stephanie Ockerman y Simon Reindl

Efectos de la deuda técnica

Valor negativo: Esto puede ser una mala interfaz de usuario que afecta la relación cliente/usuario, un mal rendimiento del sistema, flujos que ya nos son utilizados pero de igual forma tienen que ser mantenidos. Afectando directamente al valor del producto.

Golpe a la velocidad del equipo: Un ejemplo preciso de esto es cuando un equipo ágil tiene que tomar un producto ya construido y trabajar desde ahí, encontrando código incorrecto creado hace años. Donde nadie en la organización podría decir con seguridad cuál podría ser el impacto de códigos en este estado. Debido a esta incertidumbre, el equipo de desarrollo tendría que aumentar el esfuerzo de prueba para asegurarse de que nada esté roto y que el producto siga siendo seguro en cada nueva funcionalidad agregada. Siempre que se encuentren estos problemas, la velocidad de nuestro equipo disminuirá.

Los equipos generarán más desperdicio de trabajo o reducirán la productividad. Esto les dejará menos tiempo para trabajar en nuevas funciones. En otras palabras, podemos decir que el ‘ Time to Market‘ de un equipo disminuye.

Y por ultimo y el más critico para mi: Golpe a la motivación de los equipos: Esta claro que al hacernos cargo de la deuda técnica dejamos de generar valor en los entregables, si se mira del lado de la organización que no vera incrementos o evolutivos en el software, entonces que pasa, se le pide más velocidad a los equipos para volver al camino de entregar valor continuo y esto puede provocar desmotivación y hasta frustración pudiendo convertirse en un ambiente muy tenso entre los desarrolladores.

Conclusión:

La deuda técnica es una sombra que sigue al software por cada entrega que se realiza, que si no se toma en cuenta tanto por el equipo de desarrollo como por el Product Owner puede afectarnos en varias aristas: entrega de valor, el empirismo y afectar directamente a la moral del equipo, por eso, cuanto antes nos hagamos cargo y evitamos que esta sombra crezca será mejor para nuestra entrega continua.


Consejo: Cuando la detectes, comentala de inmediato a tu Product Owner, analicen el impacto en conjunto y decidan si es que puede esperar hasta la próxima iteración.


Deja un comentario