Table of Contents
Introducción
Los desarrolladores tienden a sentir mucho miedo cuando deben responsabilizarse del mantenimiento de un software que se ha construido hace mucho tiempo. No me referiré a un tiempo concreto porque eso depende del proyecto y de su magnitud. Algunos consideran que un proyecto es antiguo si tiene más de 6 meses, mientras que otros lo consideran antiguo cuando lleva años en funcionamiento.
El mayor temor al que se enfrentan los programadores cuando tienen que hacerse cargo de un proyecto antiguo es el código heredado y el crecimiento de la deuda técnica. Sin embargo, nada hace más felices a los desarrolladores que empezar un nuevo proyecto, en cuya construcción se puede aplicar lo último y más moderno.
La mayoría de las veces, se supone que empezar un proyecto desde 0, como un bebé, no conlleva achaques ni molestias de su pasado anterior. Pero, ¿es siempre así? De eso vamos a hablar en este artículo.
Mi experiencia en proyectos con deuda técnica
Hoy me gustaría compartir una experiencia que tuve recientemente en un proyecto en el que estuve trabajando.
Nuestro equipo de desarrollo comenzó el proyecto, con mucho entusiasmo y otras ventajas. Pero, como si de una película de terror se tratara, mientras se desarrollaban nuevas funcionalidades (acordadas en cada sprint), la deuda técnica empezaba a crecer. Todo el equipo estaba centrado únicamente en construir nuevas funcionalidades y entregarlas a tiempo.
El crecimiento de la deuda técnica empezó a notarse cuando se incurrió en esfuerzos adicionales no planificados y la velocidad de entrega de funcionalidades empezó a disminuir, sin cambiar el equipo. Tras analizar este problema, nos detuvimos a tomar medidas para reconducir esta situación.
¿Qué se hizo para reducir esta carga?
Notamos un descenso de la velocidad del equipo a partir del cuarto o quinto sprint, empezando por los sprints iniciales. Como detectamos estos problemas al principio del proyecto, pudimos examinar las raíces del problema y aplicar soluciones rápidamente.
¿Cuál fue la principal causa que descubrimos?
El equipo trabajaba continuamente en el desarrollo de nuevas funciones. Al final de cada sprint, se entregaba al cliente para que diera su opinión. Al corregir regularmente todos los errores críticos, el equipo introducía defectos en el sistema sin saberlo.
Sin embargo, siguieron trabajando con el deseo de entregar al cliente funcionalidades nuevas y acordadas, y en algunos casos no se dio prioridad a la corrección de esos defectos. En otros casos, esta corrección hizo que cambiara la funcionalidad entregada, y acabó ocurriendo lo que no podía ocurrir. Había diferencias entre lo previsto y lo entregado.
Obviamente, había una gran necesidad de gestionar el crecimiento de la deuda técnica. Pues bien, se decidió gestionar y trabajar en la deuda técnica a medida que desarrollábamos nuevas funcionalidades.
En las reuniones de planificación del sprint, que es donde se discute y planifica la cantidad de trabajo que hay que hacer para alcanzar los objetivos del sprint, se creó un trabajo para liquidar el crecimiento de la deuda técnica. Esto también estableció la expectativa correcta con el cliente, que comprendió que gestionar el crecimiento de la deuda técnica ya no sería una sobrecarga. Es decir, hicimos de la deuda técnica una parte integral de la cartera de productos para asegurarnos de que se tiene en cuenta y se aborda. Las historias de usuario empezaron a estimarse teniendo en cuenta la refactorización cuando fuera necesario.
Un papel vital en todo este proceso de desarrollo de nuevas funcionalidades y corrección de la deuda técnica en funcionalidades anteriores fueron las pruebas de integración y las pruebas automatizadas. Por cada deuda técnica corregida y defecto encontrado, el equipo escribía pruebas automatizadas. Esta práctica les ayudó a detectar el defecto a tiempo si volvía a producirse.
A partir de entonces, nos aseguramos de que cada sprint tuviera espacio para la refactorización. También nos ayudamos con la programación en parejas y fue mucho más fácil.
Al aplicar estas prácticas, el equipo redujo la deuda técnica y volvió a disfrutar del desarrollo de un nuevo producto (el sueño de todo programador), así como de una mayor previsibilidad y productividad.
Conclusión
Cuando las tareas de nuestro desarrollo resultan diferentes de lo esperado, es un claro síntoma de que algo va mal, y es fundamental detenerse a investigar el problema.
Ante el problema del crecimiento de la deuda técnica en nuestro código, conseguimos erradicar totalmente este mal que temen los desarrolladores utilizando medidas sencillas y eficaces.
