LA GESTIÓN DE LA DEUDA TÉCNICA (Technical Debt Management)

Todo proyecto de software incurre en un concepto llamado deuda técnica (Technical Debt) que es inevitable a pesar de que se pueda reducir con el uso de buenas prácticas.

La metáfora de deuda técnica, desarrollada por Ward Cunnigham, explica cómo el proceso de desarrollar de forma «rápida y sucia» nos hace incurrir en una deuda, que al igual que una deuda financiera, nos obliga al pago de intereses, que se traducen en un esfuerzo extra a realizar en las siguientes iteraciones de desarrollo.

El uso del concepto de deuda técnica es útil a la hora de transmitir a personas menos técnicas los conceptos, estrategias, compromisos y consecuencias de las elecciones y decisiones que se toman a lo largo de un proyecto de desarrollo para poder cumplir con los objetivos trazados.

The problem with quick and dirty, is that the dirty remains long after the quick has been forgotten – Steve C. McConnell.

El cuadrante de la deuda técnica

El cuadrante de la deuda técnica, desarrollado por Martin Fowler, ayuda a establecer el tipo de deuda en la que se incurre: prudente o imprudente y a su vez deliberada o inadvertida.

Una deuda prudente y deliberada es aquélla en la que el equipo sabe que está endeudándose, y por lo tanto analiza si los beneficios de una entrega a tiempo son mayores al coste de pagar después esta deuda. Por otro lado, un equipo que ignora las buenas prácticas de diseño y programación está asumiendo una deuda imprudente e inadvertida.

Las diferentes formas de deuda técnica, pueden incluir pero no están limitadas a: limpieza de código, reestructuración o reingeniería de conceptos, cobertura de código, problemas de bases de datos, etc.

Gestión ágil de la deuda técnica

Teniendo en cuenta que las metodologías ágiles se basan en ciclos cortos de desarrollo, entregas rápidas y correcciones continuas es necesario preguntar: ¿cómo se debe gestionar la deuda técnica?

Antes de iniciar el camino de pagar o cancelar la deuda técnica, se debe establecer un mecanismo de seguimiento y gestión adecuado. Cada situación debe ser descrita en una historia de usuario y colocada en un backlog de deuda técnica.

La deuda debe ser gestionada por lo que es y no en base a quién o qué la ha creado, razón por la cual es necesario alentar a todos los miembros del equipo a contribuir con el backlog de deuda técnica al igual que en el desarrollo de las historias de usuario relacionadas. Es importante resaltar que este backlog nunca está completo ya que siempre está cambiando a medida que surgen nuevos desafíos y se pagan deudas previamente adquiridas.

The time you take out of the schedule to make technical debt payments typically doesn’t result in anything the customers or users will see… – Jeff Atwood

Una vez creado el backlog adecuado, es el momento de convencer y comprometer al product owner. Recordemos que el concepto de deuda técnica puede ser un poco difuso por lo que una introducción podría ser necesaria. Adicionalmente siempre será útil tener a mano una representación visual del backlog (i.e. un gráfico del total de puntos en el backlog de un sprint a otro).

En un entorno Scrum, la reunión de revisión de Sprint se ajusta como anillo al dedo para gestionar de forma continua la deuda. Otra opción podría ser colocar una versión impresa del backlog sobre un tablero Scrum o Kanban ya que es crucial mantenerlo siempre visible y vigente.

El paso final es implementar una estrategia para reducir el número de actividades presentes en el backlog y por tanto pagar la deuda que se ha adquirido. Dicha estrategia debe estar enfocada a la reducción continua de la deuda, razón por la cual, de ser posible, se debe colocar en la hoja de ruta del producto (road-map).

Obviamente surgirán inquietudes sobre los posibles impactos en la productividad o la obtención de resultados menos directos a lo largo de las distintas iteraciones, y es aquí donde la preparación adecuada y el uso de los mecanismos previamente mencionados darán sus frutos.

Cuando el product owner comprende el concepto y examina cuidadosamente las historias de usuario, éste será capaz de evaluar de forma adecuada el riesgo o impacto sobre el negocio de manera que no se acumulen las historias y la deuda crezca provocando que el tiempo del proyecto se emplee más en mitigarla que en desarrollar nuevas características.

Más información:

Carlos Mendible con más de 14 años de experiencia diseñando e implementado soluciones de software, comenzó su carrera en Venezuela, donde en 1999 obtuvo su primera certificación Microsoft. Actualmente está certificado como CISA, ITILF, MCSD, MCTS y MCP. Trabaja desde 2012 como Arquitecto Senior de Soluciones Microsoft en Sogeti España colaborando también como evangelista tecnológico, formador e ingeniero de pre-venta.