Deuda Técnica ¿Qué es y cómo gestionarla?

La Deuda Técnica es un tema recurrente en los equipos agiles que desarrollan software o productos digitales, y también es recurrente el no entender realmente lo que es y no gestionarla.

¿Entonces que es?

Es un concepto en el desarrollo de software que refleja el costo implícito del trabajo adicional causado por elegir una solución fácil (o que no cumple con todo técnicamente) en lugar de utilizar un mejor enfoque que tomaría más tiempo. La deuda técnica se puede comparar con la deuda monetaria, ya que, si la deuda técnica no se paga, puede acumular ‘intereses’, lo que dificulta la implementación de cambios más adelante o incluso problemas. La deuda técnica no abordada aumenta la entropía del software.

La deuda técnica no es necesariamente algo malo, lo malo es no entenderla y no gestionarla.

He visto a muchos equipos llamar deuda técnica al trabajo pendiente, historias o PBI que no alcanzaron a terminando durante el Sprint, eso es trabajo pendiente no deuda técnica.

La deuda técnica es Técnica, es decir no es visible para el usuario/cliente hasta que esta nos cobra, algunos ejemplos:

  • Desarrollar un portal o funcionalidad que soporte una recurrencia de 10 transacciones, pero se sabe que en el futuro deberá soportar 500. Entonces un equipo podría decidir caer en deuda técnica y entregar la funcionalidad operativa, sabiendo que solo soporta una recurrencia de 10 pero que deberán mejorarla a 500, ¿Qué pasa si no pago esta deuda técnica? Pues cuando mas usuarios comiencen a usar la funcionalidad la experiencia será terrible y sufrirán errores, caídas, etc.
  • Desarrollar un App, con una estructura de código, módulos, archivos deficientes. Quizás por presiones de negocio, tiempo se hace sin un diseño correcto técnicamente y se libera funcionalmente. Deuda técnica acá es corregir la estructura y diseño internos del código (patrones), ¿Qué pasa si no pago? La App probablemente seguirá creciendo con la misma mala estructura, lo que hará más difícil mantenerla y mas propensa a errores (modificas un elemento y se estropean 3), aumentaran los costos de mantenimiento, necesitara mayor QA y el cliente/usuario recibirá mas lento actualizaciones o actualizaciones con errores.

Como vemos, la deuda técnica de un producto digital o sistema puede afectar:

  • Su performance o rendimiento.
  • Su mantenimiento y evolución.
  • La seguridad.
  • La experiencia.

Por otro lado, hay 4 formas de clasificar la deuda técnica, respecto de cómo esta surge.

Para Finalizar, ¿Cómo gestionarla?

1° La deuda técnica debe ir en el Product Backlog como otro Product Backlog Item y debe priorizarse para hacerse cargo de ella durante algún Sprint. (Mientras antes mejor)

2° El Product Owner debe entender la deuda técnica para tomar decisiones, no necesita entender la profundidad técnica, pero si el impacto que tiene un su Producto y el que tendrá en sus Clientes/Usuarios.

Una buena técnica para el punto 2, que tome de https://www.linkedin.com/in/jemdjelal/ son las historias de usuario negativas, este es el formato:

Si no hacemos esto < Acción requerida para eliminar la deuda técnica>
se producida el siguiente impacto < performance, seguridad, mantenimiento, etc.>
y eso resultara en <Disminución de alguna métrica del producto> y/o <Impacto Monetario>

Estos conceptos y otras técnicas son enseñados y practicados en mis Workshops:

https://fabianthinking.com/scrum-in-action/

https://fabianthinking.com/product-ownership-in-action/

Saludos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s