A riesgo de caer en ser de esos puristas odiosos pero con el genuino afán de corregir un error muy común escribo este breve artículo.
Y es que es muy común en algunos roles en equipos de desarrollo ágil el escuchar frases como:
“la deuda técnica del sprint pasado es de X número de puntos” ,”tenemos mucha deuda técnica, alrededor de 15 defectos críticos”.
Relacionar la deuda técnica con actividades no concluidas de una iteración a otra o con defectos surgidos en el desarrollo es mucho más común de lo que creemos.
¿Qué es la deuda técnica?
Buscando un poco entre definiciones encontré que la respuesta no es tán sencilla así que la simplifico de la siguiente forma.
La deuda técnica es una metáfora que se usa para comunicarnos con personas no técnicas y representa un beneficio a la hora de comunicar aquellos casos en que el equipo de desarrollo haya tomado la decisión de adoptar una estrategia de arquitectura, diseño o desarrollo que no sean sostenible a largo plazo, pero que produzca un beneficio a corto plazo, se dice que es el costo de los intereses de salir en tiempo con lo mínimo indispensable.
Imagina que es como la deuda que tienes con el banco, adquirimos dicha deuda para lograr nuestros objetivos con mayor rapidez y nos ayuda a apalancarnos para obtener resultados en el tiempo esperado pero sabemos que una vez cumplido este objetivo debemos ir pagando el costo y sus intereses.
“Es como la deuda que tienes con el banco”
Martin Fowler habla de que la verdadera discusión no es si es o no deuda técnica sino entre si es deuda prudente o imprudente es decir si el equipo decide conscientemente y está dispuesto o no a correr el riesgo de ejecutar con esas condiciones.
Dentro de todas estas definiciones puedo destacar el hecho de que una característica principal de la deuda técnica es que es algo en lo que incurrimos conscientemente.
¿Entonces se le puede llamar deuda técnica a los defectos surgidos en el desarrollo?
Desde la perspectiva sobre qué el concepto de que un error o defecto es la falla en una interacción esperada por el sistema, podría decirse que difiere del concepto de deuda técnica pues la naturaleza de ambos es es diferente.
Entonces ¿se le puede llamar deuda técnica a lo que no terminamos y debemos del sprint pasado?
No concluir trabajo comprometido en tiempo tampoco puede ser llamado deuda técnica, seguro deberá existir otro concepto que haga mejor referencia a las unidades de trabajo que pasan de un sprint al otro por no haberse podido completar pero el de deuda técnica definitivamente no.
Autor
Alinca Ramos
Agile Consultant en Inteec
Cuenta con más de 5 años de experiencia en Agilidad, acompañando áreas de negocio en la adopción de marcos de trabajo ágiles. Tiene experiencia participando activamente en la transformación ágil de empresas de diferentes ramos, mezclando prácticas, herramientas y frameworks agiles para agilizar el ciclo (E2E) de vida de productos y servicios en la organización (Lean Portfolio Management, Lean change management, Design thinking, Scrum, Kanban, SAFE.)
Trainer de Kanban por la Lean Kanban University.
Links
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
https://www.scrummanager.net/bok/index.php?title=Deuda_t%C3%A9cnica
La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga
