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
Buscar temas

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

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

Cada publicación empieza con una fase en la que se crean nuevas funciones e, idealmente, se corrigen las incidencias heredadas de la publicación anterior (aunque, para ser sinceros, esto casi nunca es así). El ciclo de desarrollo alcanza la fase alfa cuando todas las funciones están implementadas y listas para las pruebas. La fase beta empieza cuando se han corregido suficientes errores para permitir los comentarios del cliente. Desgraciadamente, mientras el equipo se encarga de corregir los errores suficientes para alcanzar la beta, van apareciendo nuevos. Es un caso crónico de no dar abasto: arreglas un error y surgen otros dos. Por último, la publicación alcanza el hito de master final cuando no hay errores abiertos. Esto generalmente se alcanza arreglando algunas incidencias conocidas y aplazando el resto (¿la mayoría?) hasta la siguiente publicación.

Aplazar constantemente errores que tienen que corregirse es un modo peligroso de crear software. A medida que crece el número de errores, 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 errores 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 metodología ágil incorpora la calidad en el enfoque de desarrollo iterativo para que el equipo pueda mantener un nivel de calidad constante publicación tras publicación. Si una función 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 errores 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 función hasta que el elemento actual esté prácticamente en manos del cliente. Para acelerar el proceso, usan técnicas como flujos de trabajo de creación de ramas de función, pruebas automatizadas e integración continua a lo largo del ciclo de desarrollo.

La rama principal, o maestra, 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 hayan superado las pruebas automatizadas, puede fusionarse la rama con la maestra. 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 programas y la centran en software comprobable de alta calidad. El propietario del producto está capacitado para hacer que el equipo se centre primero en el trabajo más valioso, reduciendo 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.

Consejo de experto:

Prioriza la deuda técnica en la planificación de sprints como en el trabajo normal con funciones. 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 "finalizado" 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:

  • Enséñale al propietario del producto cuál es el coste real de la deuda técnica. Comprueba que los valores de los puntos de historia sirvan para futuras historias que precisen la resolución de deuda técnica existente.
  • Modulariza la arquitectura y adopta 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.
  • ¡Escribe pruebas automatizadas! No hay nada mejor para prevenir errores que las pruebas automatizadas y la integración continua. Cuando encuentres un nuevo error, escribe una nueva prueba para reproducirlo y, a continuación, soluciona la incidencia. Si reapareciera el error, la prueba automatizada lo detectarí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.

A continuación
Testing