Cómo escapar del agujero negro de la deuda técnica

Lista de tareas (¡es broma!) Hablando en serio, ¿no comienzas a gruñir cada vez que ves eso? Sí, a nosotros también nos pasa. 

Dan Radigan Dan Radigan

Los programas de software tradicionales tienen un enfoque del desarrollo basado en fases: desarrollo de la funcionalidad, alfa, beta y master final.

Deuda técnica ágil | Orientador ágil de Atlassian

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, o master, de la base de código siempre debe estar lista para el lanzamiento. Esa es la prioridad número uno. Las funcionalidades nuevas empiezan en una rama de tareas que contiene código para la propia funcionalidad y sus pruebas automatizadas. Una vez que la funcionalidad esté terminada y se hayan superado las pruebas automatizadas, puede hacerse el merge de la rama al master. Debido a que el nivel de calidad siempre es fijo (un nivel elevado), la deuda técnica permanece bajo control.

For many organizations this is a huge cultural change. With agile, the focus away from schedules and towards high-quality, demonstrable software. The product owner is empowered to focus the team on the most valuable work first, reducing the scope of the release instead of compromising on quality.

No lo olvidemos: cuanto más tarden los bugs 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 funcionalidades. 

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 funcionalidades que corregir bugs 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 funcionalidades. 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. 

Pro Tip:

Prioriza la deuda técnica en la planificación de sprints como en el trabajo normal con funcionalidades. No la ocultes en un backlog o un gestor de tiques 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. 

Up Next
Pruebas