La deuda técnica es una metáfora acuñada por primera vez por Ward Cunningham, quien tomó prestado el concepto de deuda del sector financiero para aplicarlo a la industria de las TI.
En el sector financiero, los pagos mensuales que uno hace para devolver una deuda se utilizan para reembolsar parte del capital prestado y también el interés correspondiente.
Si estos reembolsos no se hacen periódicamente, la suma de los pagos de intereses aumentará. Ward Cunningham aplica esta lógica a los proyectos de software y dibuja una comparación entre el sector financiero y el de TI en el que el código representa el capital y los errores representan los intereses.
Cuando los desarrolladores construyen una nueva feature, lo que hacen es escribir código, incrementando así el capital invertido en un producto de software. Como resultado, el equipo generará nuevos errores y requisitos de mantenimiento. La deuda técnica es el código que no se utiliza, que está roto, que es difícil de mantener o ampliar, o que necesita actualizar sus librerías, frameworks o lenguajes.
La deuda técnica es inevitable. Por eso necesitamos identificarla, categorizarla y explicarla
Una herramienta muy interesante para evaluar tu deuda técnica es el «cuadrante de deuda técnica» (Technical Debt Quadrant), creado por Martin Fowler. Este cuadrante ayuda a que el Product Owner pueda organizar la deuda técnica en cuatro categorías diferenciadas:
Por qué debes tener en cuenta la deuda técnica
Puede que parezca que esto se sale un poco de las responsabilidades del Product Owner, pero nada más lejos.
Si quieres construir un gran producto y hacerlo bien, sin fallar en ninguna fecha de entrega y acabar ralentizando todo el proceso por el mantenimiento y la reparación de errores, necesitas aprender a dominar la deuda de tu producto.
Cuando lo explicamos así, lo que esperamos es que sientas que está en tu mano construir un producto con un código de calidad como base. Como Product Owner, necesitas ser el primero en dar ejemplo y hacer las cosas bien, sin atajos y siempre un paso por delante de la deuda técnica.
La deuda técnica puede influir en tres aspectos de tu producto:
Mantenimiento: ya sea mantenimiento correctivo (corrigiendo errores y problemas en el software) o mantenimiento preventivo (mejorando o adaptando tu software para asegurar su compatibilidad con tu stack tecnológico), tú y tu equipo debéis tener siempre presente que la aplicación tiene que mantenerse periódicamente.
Cuantas más necesidades de mantenimiento tenga tu aplicación, más tiempo por sprint habrá que dedicarle a solucionar errores y parchear problemas, lo que significa que construirás tu aplicación más despacio, te costará más e incluirá menos features.
Facilidad de evolución: la idea de trasfondo de la filosofía ágil y el papel del Product Owner es ver el desarrollo del producto como una sucesión de iteraciones.
La facilidad de evolución es la facilidad (¡o falta de ella!) con la que puedes iterar sobre tu producto. Una aplicación con mucha deuda técnica será más complicada de iterar que otra con poca deuda.
Fiabilidad: la deuda técnica puede tener un gran impacto en la fiabilidad de tu software. Todos sabemos que el usuario se frustra si un software no funciona como debe, y podría no volver a utilizarlo si tienen una mala experiencia.
Un producto que no necesita mantenimiento, que es fácil de mejorar y que es 100 % fiable es una quimera.
Como Product Owner, tu trabajo es encontrar un equilibrio entre maximizar la facilidad de evolución y la fiabilidad manteniendo los requisitos de mantenimiento al mínimo.
Siempre tendrás la tentación de reducir la calidad para entregar más rápido, pero asegúrate de hacer siempre lo posible para que producto esté bien construido, haciéndolo fiable y robusto.
Trabaja en reducir la deuda técnica
Con todo esto, la pregunta más inmediata sería: «¿Cómo puedo minimizar mi deuda técnica sin dejar de entregar las features a tiempo?». ¿Cómo puedo aprender a vivir con la deuda técnica manteniéndola al mínimo?
Para controlar la deuda técnica necesitas ser capaz de medirla
Antes de intentar reducir tu deuda técnica, necesitas medirla y entenderla. Como Product Owner, mostrar interés en esto podría ayudar a motivar al resto de tu equipo para que se entregue a la tarea con la atención necesaria.
Comienza por trabajar con tu equipo para introducir algunas herramientas de software que te ayudarán a medir la deuda. SonarQube es una gran herramienta para esto, y ofrece algunos complementos que calcularán tu deuda técnica y propondrán un indicador de porcentajes para que puedas controlarla. Incluso si estos valores son cuestionables y no pueden aplicarse a cada línea de código, siguen siendo un gran punto de partida y te permitirán medir el impacto de las acciones que tu equipo lleva a cabo.
Prioriza tu deuda técnica
¿Te acuerdas de la matriz de producto de Boston Consulting Group? Seguro que sí y, aunque esto no sea ninguna novedad en un libro sobre metodologías ágiles, es una gran herramienta para afrontar la deuda técnica.
Recordemos que el objetivo de esta matriz es ayudarte a categorizar tus productos en una de las cuatro categorías. La forma en la que vayas a afrontar tu deuda técnica depende de en qué categoría de producto estés trabajando:
Estrella: Estos productos suponen una parte importante de los ingresos de tu empresa. Haz lo imposible para eliminar la deuda técnica de este producto.
Vaca: Trata de reducir la deuda técnica para asegurarte de que tu producto sigue siendo mantenible y fiable.
Perro: No intentes reducir la deuda técnica de estos productos, porque, de todos modos, tampoco les estás prestando atención en otros sentidos.
Interrogante: Debes tratar de minimizar el incremento de deuda técnica en estos productos, lo que significa que deberás hacer mucho mantenimiento preventivo. Estas aplicaciones podrían llegar a ser algún día tus estrellas, y no te gustaría descubrir que están cargadas de deuda cuando se convierten en una.
Encuentra expertos artesanos
Hoy en día no hay muchos desarrolladores por ahí sueltos, pero hay un tipo que tienen incluso más demanda que el resto: los artesanos del software. La artesanía del software es un movimiento cultural y profesional que pone el foco en que los desarrolladores estén muy formados, tengan curiosidad y sean muy cuidadosos con la calidad del código que crean.
Los artesanos siguen una regla muy importante a la que Robert C. Martin le ha dado forma: «Deja el código mejor que como estaba».
Eso significa que hay que llevar la mejora continua al nivel más específico: cada vez que un desarrollador toca una parte de código, tiene que dejarla mejor que como se la encontró inicialmente; los artesanos del software están constantemente incorporando pruebas unitarias, eliminando errores y actualizando el código a medida que trabajan. ¡Un gran remedio para combatir la deuda técnica!
Definición de «Terminado»
La definición de «Terminado» debería escribirse junto al Scrum master de tu equipo o al desarrollador principal.
La definición de «Terminado» es la que te permitirá a ti, como Product Owner, confirmar que la historia está realmente finiquitada y que se han aplicado unas buenas prácticas de desarrollo, es decir, que el código debería ser legible, además de incluir pruebas unitarias y funcionales.
Una gran forma de asegurarte de ello es animando a tu equipo de desarrollo a hacer revisiones de código antes de entregar una historia de usuario para pruebas y desarrollar features haciendo pair programming (programación en pareja) cuando sea posible.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
La deuda técnica no puede esperar
Aquí tienes una lista de cosas que puedes hacer para empezar con buen pie desde ahora mismo:
- Incluye una revisión de indicadores de calidad de código en cada retrospectiva; así, todo tu equipo sabrá dónde está la deuda.
- Basa tus estimaciones de puntos de historia en la cantidad de deuda implicada en el desarrollo de una nueva feature. Si esto se hace correctamente, el coste de la feature será mayor cuanto mayor sea la deuda implicada. Así, podrás llevar la cuenta de cuánta deuda técnica le cuesta a tu equipo cada entrega.
- Organiza «días de limpieza». Si tu equipo tiene problemas para gestionar la deuda técnica, dedícale días completos a esa única tarea.
- Anima a que tu equipo a refactorice, pero no le dediques sprints completos. Refactorizar es la práctica de «ordenar» el código, mejorando su legibilidad y facilitando su mantenimiento e iteraciones. Tu equipo de desarrollo debería dedicarle tiempo a la refactorización, pero asegúrate de acotar esos esfuerzos, pues eso te ayudará a entender lo que se ha hecho y medir el progreso (igual que cuando escribes historias de usuario muy pequeñas).
Para saber más: descarga nuestro libro Las Claves del Product Management
