Cuando se habla de deuda técnica, a menudo se achaca a algo por lo que los equipos de desarrollo son responsables. Nada más lejos de la realidad, la deuda técnica es un reflejo de una falta de madurez en la gestión empresarial. El motivo es que, a pesar de que los equipos puedan entregar software que no esté terminado, una organización madura invitará a esos equipos a subir el nivel de calidad del producto Sprint a Sprint.
¿Qué es la deuda técnica?
La deuda técnica es el equivalente en software a no haber ahorrado para ir de vacaciones y pedir un préstamo de alto interés para irse a Cuba, teniendo dudas sobre si tendremos trabajo a la vuelta. Las consecuencias son desastrosas y, a pesar de lo evidente que pueda parecer, es un aspecto común de las organizaciones con las que trabajo.
La deuda técnica es la suma de todas las cosas que no hemos hecho anteriormente y que había que haber hecho para tener un software decente y de calidad. El caso más típico de deuda técnica es cuando alguien dice: – Bueno, lo dejamos así, que funciona, y ya lo resolvemos cuando tengamos tiempo. ¡Error! No hay nadie que haya dicho nunca: Ahora que tengo tiempo, voy a a resolver todas los arreglos de mi código.
Solo existen dos cosas que sobrevivirán un ataque nuclear: Las cucarachas y ese apaño que le hiciste al código para salir del paso
Además, existe un segundo problema: ¿Durante cuanto tiempo crees que podrás entender lo que hiciste sin tardar más tiempo que el que tardaste haciéndolo? Una de las características del buen código no es solamente que funcione, sino que sea legible y mantenible. Y eso muchas veces excluye también al código brillante. Todos hemos tenido ataques de genialidad en los que hemos hecho algo que funcionaba pero no entendíamos muy bien por qué.
Este es quizás el mayor coste de la deuda técnica. Conforme va pasando el tiempo, el conocimiento sobre el código se desvanece y hay que empezar de nuevo. Cuando la complejidad es muy alta, el “pago” de deuda será aún mayor, por el simple motivo de que puede llevar días o semanas entender qué ocurre y que se quiere hacer.
La deuda técnica es un riesgo que hay que gestionar
Desde el punto de vista de gestión y dirección de la organización, la deuda técnica, ya sea por estar implícita en el código, por ser parte de la infraestructura o del despliegue de la aplicación es cómo una deuda en el banco a un alto tipo de interés.
Cuanto más tiempo se tarde en gestionarla, más intereses se pagaran. El problema añadido es que muchos equipos eligen trabajar rápido al principio de un proyecto a costa de generar deuda técnica, lo cual además crea una falsa sensación de velocidad que más adelanta se vuelve en contra.
¿Que el equipo no es capaz de entregar? Pero si ahora hay mucha más gente y al principio desarrollaban software muy rápido. Hay algo que tenéis que estar haciendo mal
Muchas organizaciones ignoran la deuda técnica a la hora de hacer predicciones. Simplemente cierran los ojos y asumen que si en el pasado han sido capaces de salir adelante, esta vez no tiene por qué ser diferente. El problema es que efectivamente tienen razón hasta que un día están equivocados. Es una bomba a punto de explotar que nadie quiere tener en las manos.
Resolver la deuda técnica requiere de un esfuerzo conjunto
Un plan para resolver deuda técnica requiere de un esfuerzo coordinado a cuatro bandas.
El equipo de desarrollo tiene que trabajar con los responsables técnicos u otros equipos dibujando una hoja de ruta para resolver los problemas principales. No tiene que ser extremadamente detallado pero tiene que dejar claro cual es la dirección a seguir. Muchos de mis equipos han usado un poster que refleja su arquitectura actual y un poster que refleja la arquitectura deseada y conforme se iban implementando piezas, se hacían green checks, lo que ayudaba a no perderse.
El Product Owner debe entender que resolver los problemas de hoy y de mañana supone entregar software a un menor ritmo y cuando este se entregue, que siga unos estándares de calidad. El Product Owner es quien maneja el presupuesto en Scrum y quien puede hacer esto realidad. Para ello ha de trabajar con los Stakeholders.
Los Stakeholders deben entender, mediante el trabajo con el Product Owner y el equipo de Desarrollo, que una inversión en resolver la deuda técnica es precisamente eso, una inversión que facilitará las cosas a futuro y les permitirá reducir todo el riesgo asociado al proyecto.
La velocidad en Scrum no se mide en Story points, sino en software terminado y entregado
Eso no significa que el equipo de desarrollo se ponga exclusivamente a resolver deuda técnica y no haga nada más, nada más lejos de la realidad. El objetivo de Scrum es entregar, así que como mínimo el equipo deberá de seguir entregando una pequeña pieza de funcionalidad terminada, que mostrar en la sprint review. En ese momento, y después de varios sprints el equipo tendrá una verdadera visión de cual es su velocidad real.
Algunas herramientas que pueden ayudar
Integrar siempre, como mínimo, una vez por Sprint. La deuda técnica se acumula en equipos que producen software que no es integrado y entregado al menos una vez por Sprint. Algunos de estos equipos intentan evitar esto porque el trabajo de integración es muy grande, lo cual es un Oxímoron, dado que el trabajo será mucho más grande cuando llegue la hora de integrarlo de verdad, y la deuda técnica se habrá apoderados de un código que más que probablemente haya que borrar y volver a hacer.
Usar herramientas como SonarQube® para medir los posibles problemas del código. Estas herramientas miden la calidad del código desde distintos puntos de vista: facilidad de lectura, complejidad ciclomática, complejidad npath, así como hacer transparente que se respetan unas normas comunes a la hora de escribir código.
Usar Integración Continua como Jenkins o Travis y sólo desplegar código que esté integrado y medido. En ambos, se pueden configurar puertas que permitan que sólo se despliegue aquellas features que realmente cumplen con los estándares que se esperan.
Per último, a nivel organización, hablar y medir cual es el riesgo acumulado durante todo el tiempo anterior. No hablar de ello no ayudará a mejorar la situación. Herramientas como SonarQube ofrecen una idea estimada de cual es el coste en días de resolver la deuda técnica de la organización. Ponerlo encima de la mesa y discutirlo cómo se discutiría cualquier otro asunto de riesgo que afecta a la organización es señal de madurez empresarial.
El sistema de tres pasos para pagar la deuda técnica
- Dejar de crear nueva deuda técnica.
- Pagar una pequeña parte de la deuda cada Sprint.
- Repetir el paso 2.
Empezar desde cero NO es una solución
¿Qué ocurre cuando alguien propone empezar todo desde cero solamente por la dimensión de la deuda técnica? Ese comportamiento es muy poco profesional. A pesar de que en un momento dado, empezar de cero pueda parecer la opción más viable, es un espejismo, ya que no tiene en cuenta muchas de las cosas “buenas” que tiene ahora mismo nuestro producto. Tirarlo todo a la basura para volverlo a hacer es tan poco profesional cómo dejar que la deuda técnica se acumule durante años.
Deja una respuesta