¿Qué es la deuda técnica?
Los programas de software tradicionales tienen un enfoque del desarrollo basado en fases: desarrollo de la funcionalidad, alfa, beta y master final.
Cada versión empieza con una fase en la que se crean nuevas funcionalidades e, idealmente, se corrigen los problemas heredados de la versión anterior (aunque, para ser sinceros, esto casi nunca es así). El ciclo de desarrollo alcanza la fase alfa cuando todas las funcionalidades están implementadas y listas para las pruebas. La fase beta empieza cuando se han corregido suficientes bugs para permitir el feedback del cliente. Desgraciadamente, mientras el equipo se encarga de corregir los bugs suficientes para alcanzar la beta, van apareciendo nuevos. Es un caso crónico: arreglas un bug y surgen otros dos. Por último, la versión alcanza el hito de master final cuando no hay bugs abiertos. Esto generalmente se alcanza arreglando algunos problemas conocidos y aplazando el resto (¿la mayoría?) hasta la siguiente versión.
Aplazar constantemente bugs que necesitan corregirse es un modo peligroso de crear software. A medida que crece el número de bugs, enfrentarse a ellos es cada vez más complicado, lo cual da como resultado una espiral letal de deuda técnica. Para empeorar las cosas, la planificación salta por los aires porque la programación alrededor de los bugs ralentiza el desarrollo. Mientras tanto, los clientes sufren los efectos de mil inconvenientes causados por defectos no corregidos. De hecho, algunos de ellos te abandonarán.
Debe haber un modo mejor.
Reducir la deuda técnica mediante una metodología ágil
La agilidad incorpora la calidad en el enfoque de desarrollo iterativo para que el equipo pueda mantener un nivel de calidad constante versión tras versión. Si una funcionalidad no está a la altura, no se lanza. ¿Te parece difícil de creer? Un truco es este: definir, o redefinir, qué se considera "finalizado".
Para un equipo tradicional, "finalizado" significa que tiene el nivel suficiente para que empiece el control de calidad. El problema con esa definición es que los bugs aparecen en una fase muy temprana del ciclo de publicación y no dejan de aumentar. Para cuando el control de calidad interviene, el producto está plagado de capas y capas de defectos. Los equipos ágiles, sin embargo, equiparan "finalizado" a "listo para publicarse", lo cual significa que los desarrolladores no pasan a la siguiente historia o funcionalidad hasta que el elemento actual esté prácticamente en manos del cliente. Para acelerar el proceso, usan técnicas como workflows de ramificación de funcionalidades, pruebas automatizadas e integración continua a lo largo del ciclo de desarrollo.
La rama principal de la base de código siempre debe estar lista para el lanzamiento. Esa es la prioridad número uno. Las funciones nuevas empiezan en una rama de tareas que contiene código para la propia función y sus pruebas automatizadas. Una vez que la función está terminada y se han superado las pruebas automatizadas, puede hacerse la fusión con la rama principal. Debido a que el nivel de calidad siempre es fijo (un nivel elevado), la deuda técnica permanece bajo control.
Para muchas organizaciones, esto supone un gran cambio cultural. Con la metodología ágil, alejan la atención de los programas y la centran en el software comprobable de alta calidad. El propietario del producto está capacitado para hacer que el equipo se centre primero en el trabajo de más valor, lo que reduce el alcance de la publicación en lugar de poner en peligro la calidad.
No lo olvidemos: cuanto más tarden los errores en desaparecer, más difícil es corregirlos.
Controlar la deuda del equipo
Si trabajas con código heredado, es posible que hayas heredado deuda técnica. Los siguientes temas te ayudarán a controlar la deuda existente y permitirán a tu equipo centrarse en asuntos más divertidos, como el desarrollo de nuevas funciones.
Defínelo
En ocasiones, los desarrolladores y gestores del producto no están de acuerdo sobre qué representa una deuda técnica. Acabemos con la polémica:
Esto incluye todos los atajos técnicos tomados para cumplir los plazos de entrega.
En el desarrollo, es muy tentador pensar en el trabajo estructural como deuda técnica. Puede serlo o no, en función de la naturaleza del cambio (por ejemplo, sustituir un atajo por la solución "real" frente a dividir una base de código monolítica en microservicios). Por otro lado, los gestores del producto a menudo sienten que es más urgente crear nuevas funciones que corregir errores o acelerar operaciones lentas. Para evitar confrontaciones entre ambas partes, todos deben entender la diferencia entre deuda técnica, cambios estructurales deseados en la base de código y las nuevas funciones. Es fundamental que haya una comunicación clara entre los equipos de desarrollo y de gestión de productos para priorizar el backlog y desarrollar la base de código.
Establece la prioridad de la deuda técnica en la planificación de sprints al igual que haces con el trabajo normal relacionado con la función. No la ocultes en un backlog o un gestor de incidencias aparte.
Ten cuidado con los sprints y las tareas de las pruebas
Resiste las ganas de alterar la definición de "hecho" añadiendo una tarea de prueba aparte a la historia de usuario original. Es muy fácil aplazar el trabajo, pero solo da lugar a deuda técnica. Si no se realizan pruebas como parte de la historia original o la corrección de errores, el proceso no ha concluido. Mantén una definición rigurosa de "hecho" en tu programa y asegúrate de que incluya pruebas automatizadas completas. No hay nada que mine más la agilidad del equipo que hacer pruebas manuales y encontrarse una base de código llena de errores.
Automatiza la eliminación de errores
Cuando alguien encuentre un error en el software, dedica un momento a añadir una prueba automatizada que lo demuestre. Cuando el error esté corregido, repite la prueba para comprobar que la pase. Esta es la esencia del desarrollo basado en pruebas, un método consagrado para conservar la calidad del desarrollo ágil.
¿Por dónde empezar?
No es fácil cambiar la filosofía del equipo (ni la de las partes interesadas del equipo) en cuanto a la gestión de la deuda técnica. A veces la empresa tiene que reducir el tiempo de desarrollo para poder acceder antes al mercado. Teniendo esto presente, repasemos algunas medidas para domar esa deuda técnica:
- Enseñarle al propietario del producto cuál es el coste real de la deuda técnica. Comprobar que los valores de los puntos de historia sirvan para futuras historias que precisen la resolución de deuda técnica existente.
- Modularizar la arquitectura y adoptar una postura firme con respecto a la deuda técnica de nuevos componentes o bibliotecas de la aplicación. Al ver la agilidad de estos nuevos componentes, no cabe duda de que el equipo y la empresa querrán llevar estas prácticas a otras partes del código.
- ¡Escribir pruebas automatizadas! No hay nada mejor para prevenir errores que las pruebas automatizadas y la integración continua. Cuando encuentres un error, escribe una prueba para reproducirlo y, a continuación, soluciona la incidencia. Si el error reapareciera, la prueba automatizada lo atraparía antes que los clientes.
Recuerda: la deuda técnica es una realidad para todos los equipos de software. Nadie la puede evitar del todo. Lo importante es impedir que entre en una espiral fuera de control.
