La Deuda Técnica

La Deuda Técnica

Una cuestión que todo Equipo Scrum deberá tener muy presente a lo largo de los Sprints es cómo abordar la deuda técnica que vaya surgiendo, a veces inevitablemente.

Es muy importante reflejarla en el Backlog ya que te permitirá obtener información muy valiosa respecto a tu productividad. Pero, sobre todo, debes minimizarla en la medida de lo posible.

En este post desmenuzaremos este peligro que acecha a nuestros proyectos continuamente. Saber identificarlo ayudará, en parte, a evitarlo.

Vamos a ello.

Qué es la deuda técnica en Scrum

Este término deuda técnica fue acuñado por Ward Cunningham, uno de los grandes contribuidores, entre otras cosas, a Extreme Programming.

Es un analogismo de la deuda financiera que contrae una persona y que después se materializa en intereses que serán mayores en tanto más tiempo transcurra.

Así, la deuda técnica consistiría en desarrollar un software pobre, típicamente porque hay que salir del paso y necesitamos desarrollar esa funcionalidad tan importante lo antes posible, cuyas carencias tendrás que abordarlas en algún momento y que serán más significativas cuanto más tiempo pase.

De la misma forma que con la deuda financiera pides un dinero prestado que tarde o temprano tendrás que devolver (y con intereses), con la deuda técnica pides un tiempo prestado que tendrás que devolver (también con intereses).

En resumen, deuda técnica es la contraída cuando se desarrolla una solución cortoplacista en la que incurren los desarrolladores, normalmente cuando se les presiona con las fechas, lo que termina resintiendo la calidad del software.

Al final, tarde o temprano, tendrás que adecentar tu código y te costará más esfuerzo de lo que te hubiese costado si lo hubieses hecho bien a la primera.

Por eso es tan importante, aunque de cara a la gerencia decirlo sea muchas veces predicar en el desierto, que no se presione con los tiempos a los desarrolladores, porque generarán un código deficiente que generará una deuda técnica que te saldrá cara. Una mala inversión, ¿no te parece?

Deuda técnica vs funcionalidades parciales

Ojo, no confundir deuda técnica con historias de usuario parcialmente desarrolladas.

Una historia de usuario, si urge mucho, puede quedar resuelta prácticamente en su totalidad de modo que el Product Owner transija con ponerla a done pero con la condición de que en Sprints posteriores se complete al cien por cien. Esto normalmente se traducirá en que el Product Owner creará una nueva historia de usuario que incluirá aquello que no se abordó en la historia original.

En cambio, la deuda técnica, como su nombre indica, no tiene nada que ver con los requisitos funcionales, es una cuestión de falta de calidad técnica de código, por ejemplo:

  • Falta de pruebas y/o de automatización de pruebas.
  • Escasa o mala documentación del aplicativo.
  • Código deficientemente comentado.
  • Uso de hard-code.
  • Código duplicado.
  • Mal tratamiento de excepciones y de errores.
  • Mal control de versiones.
  • Diseño deficiente, como por ejemplo excesiva complejidad ciclomática (cuán difícil es probar el código.).
  • Excesiva complejidad cognitiva (cuán difícil es de entender intuitivamente un bloque de código).
  • Métodos de tamaño excesivo.
  • Etc.

Cómo prevenir la deuda técnica

Hay varios aspectos que deberás tener en cuenta para prevenir la deuda técnica:

El Equipo de Desarrollo decide el volumen de trabajo del Sprint

Recuerda: el Equipo de Desarrollo es autoorganizado. Ellos deciden durante el Sprint Planning qué volumen de trabajo abordarán durante el Sprint y qué se quedará para el siguiente Sprint. Por supuesto, en base a la prioridad definida por el Product Owner…

Por tanto, no presiones al Equipo de Desarrollo a trabajar más allá de su capacidad.

Si se recorta en demasía el tiempo de desarrollo o si sobrecargamos de contenido el Sprint, la calidad se verá perjudicada. Así de simple.

La importancia de un buen Definition of Done

En segundo lugar, procura que tu Definition of Done no presente ambigüedades.

Debe quedar clarísimo a todos (y cuando digo todos me refiere a todo el Equipo Scrum, no sólo a los desarrolladores) que una historia de usuario no se podrá considerar terminada si no cumple con los requisitos de calidad pertinentes y éstos deberán quedar perfectamente por escrito.

Por ejemplo, el DoD deberá incluir que el código esté correctamente documentado y comentado.

Parte de una buena base técnica

Además del tester, el technical lead tiene muchísimo que decir respecto a la calidad del software.

Cuenta siempre en tu Equipo de Desarrollo con un technical lead experimentado que apueste siempre por las mejores prácticas de desarrollo y por la máxima calidad de los entregables. Él, mejor que nadie, debe marcar la pauta de cómo deberá trabajarse a nivel técnico.

Añade subtareas que incidan en la calidad

Dentro de las historias de usuario incluye siempre subtasks que obliguen a poner foco en la calidad.

Una historia no se dará por done en tanto todas sus subtareas no estén hechas, así que aprovecha esta circunstancia para meter subtareas que aseguren una buena calidad de código.

Por tanto, nunca podrá faltar una subtarea de testing manual y otra de testing automático.

El Equipo de Desarrollo mejor que nadie sabe qué implica realizar una buena codificación, de modo que a ellos corresponderá incluir las subtasks necesarias para asegurar que el código generado es de calidad.

Ayúdate de herramientas de calidad del software

Realiza análisis del código con alguna herramienta como SonarQube o PMD para la evaluación del código que vas desarrollando y detecta lo antes posible las deficiencias de programación.

Todo Equipo de Desarrollo debería utilizar alguna plataforma de análisis de código. SonarQube, al igual que PMD, JaCoCo, FindBugs, etc, son herramientas automatizables y configurables, aunque fáciles de falsear si quieres hacerte trampas al solitario, así que ojo con esto.

Utiliza TDD

Si tienes la posibilidad usa TDD (Test Driving Development). Nos asegurará la calidad de nuestro desarrollo. Además un buen testing ayuda a entender tu código. Eso sí, los test deben por tanto ser comprensibles.

No desarrolles lo que no necesites

Te animo a hacer caso del popular concepto de ingeniería del software YAGNI (you aren`t gonna need it – No vas a necesitarlo).

Esto viene a aconsejarte que no desarrolles cosas que no vas a necesitar, por lo menos por el momento, porque te verás forzado a mantenerlo y a lidiar con la posible deuda técnica que pueda generar.

Refactoriza tu código

El refactoring implicará limpiar el código, hacerlo más legible, más mantenible, más optimo y, en resumen, se traduce en hacerlo comprensible a los demás.

Puedes hacerlo entendible usando javadoc, utilizando métodos, clases o variables con nombres comprensibles, etc.

La refactorización requiere de test, para poder asegurarnos que al cambiar el código (con la idea de mejorarlo, claro) no rompemos nada que funcionara.

Testing, testing, testing

La incidencia o falta de calidad de hoy es la deuda técnica de mañana. Por tanto, corta esa posibilidad mediante un buen testing, tanto manual como automatizado. No escatimes en un buen tester!!

Cómo detectar y abordar la deuda técnica

La deuda técnica del día a día puede detectarse y reducirse en gran medida teniendo muy presente la comunicación entre los miembros del Equipo de Desarrollo, de ahí la importancia del papel que desempeñan los eventos de Scrum en general y de la daily en particular. La transparencia es siempre la mejor forma de detectar cualquier deficiencia en el trabajo del Equipo Scrum.

Además, es imprescindible el buen hacer del tester y del Product Owner. Un buen testing será fundamental para detectar una posible carencia de la calidad. Por otra parte, el Product Owner debe conocer perfectamente el aplicativo de forma que pueda detectar cualquier funcionalidad que no presente la calidad que debiera. Cuanto antes lo detectes más fácil será enmendarlo.

Es importante que el Equipo de Desarrollo sea autocrítico y busque siempre la máxima calidad, que no espere a que el Product Owner o peor aún, el usuario, sea quien saque a flote el resultado de un mal código.

La Retrospectiva es un excelente evento para repasar aquellos aspectos donde no pusimos excesivo foco en la calidad.

Sea como fuere, una vez detectada la deuda técnica habrá que eliminarla lo antes posible. Recuerda que la deuda se cobrará intereses cuanto más tiempo pase sin pagarla. Si detectas rápidamente una falta de calidad en el desarrollo de una historia, tendrás muy fresco ese conocimiento y seguramente irás a tiro hecho para poder arreglarlo, evitando cargar con una deuda. Pero imagina abordar en un Sprint una historia que se quedó haciendo aguas varios Sprints atrás: seguro que ya no te resultará tan fácil arreglarla ahora.

El Sprint Planning es un buen momento para crear las historias de deuda técnica que solventarán esas fisuras en tu entregable. Dichas historias pasarán a formar parte del Sprint Backlog y se estimarán como cualquier otra historia técnica. Trata la deuda técnica como cualquier otro PBI, es decir, debe durar como máximo lo que dura el Sprint. No cometas el error de tener un ítem de deuda técnica dando vueltas y vueltas Sprint tras Sprint.

Cómo representar la deuda técnica en el Backlog

En el Backlog no sólo podemos reflejar esa deuda técnica como historia técnica, incluso podemos crear un ítem específico que sea deuda técnica, technical debt o algún nombre por el estilo.

Herramientas como Jira permiten crear nuevos tipos de ítems además de los típicos de historia de usuario, historia técnica o bug.

Yo personalmente apuesto por utilizar un issue type específico para la deuda técnica. Esto te permitirá obtener más fácilmente una estadística de qué esfuerzo dedicas a deuda técnica y te permitirá sacar datos objetivos y a partir de ellos conclusiones al respecto. Por ejemplo:

La deuda técnica en los tres últimos Sprints ha supuesto el 33% de los puntos de historia del Sprint ⇒ estamos dedicando demasiado esfuerzo a deuda técnica ⇒ Conclusión: el equipo de desarrollo no se está enfocando en desarrollar de primeras historias de usuario con la suficiente calidad ⇒ buscar soluciones para atajar este problema.

Saber vender la deuda técnica

Un problema de la deuda técnica es que es difícil vendérsela a Negocio. Ellos consideran que pagan por un producto, no por tecnología, y no siempre asumirán el esfuerzo que debe dedicarse a solventarla. Habrá que realizar una buena labor de educación a Negocio…

Una vez que en el Sprint Planning añadas a tu Sprint Backlog las historias de deuda técnica que consideres, es muy posible que también el Product Owner cuestione su prioridad y se queje de que estamos destinando demasiado esfuerzo a cuestiones que él no ve y por tanto carecen del valor suficiente como para restar foco de lo que es importante para él: desarrollar historias de usuario.

Esto no es muy diferente de lo que te puede suceder con cualquier tipo de tarea técnica. Debes hacerle entender (y aquí el Scrum Master deberá ser suficientemente persuasivo) de qué significa arrastrar deuda técnica y de cómo ese pan para hoy y hambre para mañana puede terminar por hacer de tu producto un fracaso.

Ten mano izquierda y si tu Product Owner no tiene un perfil técnico no lo trates con condescendencia ni lo satures con cuestiones técnicas, simplemente háblale con sinceridad y si, además, dispones de estadísticas que demuestren el impacto que supone esa deuda técnica no atendida, mejor que mejor. Siempre mejor dar datos fríos (puntos de historia y horas) que dar opiniones.

Reflexión final

A ti, Scrum Master, te digo que no admitas que se desprecie la deuda técnica. Insiste, patalea, haz lo que debas hacer para que la calidad no se vea comprometida. Inculca al Equipo de Desarrollo el amor por la calidad y al Product Owner hazle entender que no todo es hacer historias de usuario como churros. Un producto software debe pasar, siempre, por la calidad del propio software. Puede parecer de perogrullo, pero no todo el mundo lo tiene tan claro…

A ti, Product Owner, te digo que atiendas a razones y confíes en el criterio de los técnicos de tu Equipo Scrum. Sé consciente de la importancia de abordar la falta de calidad lo antes posible antes de que se convierta en deuda técnica. Cualquier problema que pueda generar esa falta de atención a la calidad será también responsabilidad tuya.

Y a vosotros, desarrolladores, que en vuestro ADN esté siempre presente la calidad. Luchad siempre por mantenerla y porque nada la comprometa… en la medida de lo posible.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario