La deuda técnica tiene que suceder,
pero entender de dónde proviene es la clave para deshacerse de ella antes de
que crezca.
En un mundo ideal, cada proyecto se
termina a tiempo, y dentro del presupuesto estimado. Aún mejor, el presupuesto ha permitido a los equipos desarrollar
funciones adicionales y probar todo una vez más antes del lanzamiento. En el
mundo real, el proceso de desarrollo puede encontrar varias dificultades, y la
deuda técnica es uno de los problemas más comunes que puede enfrentar el
proyecto. Es esencial comprender qué es la deuda técnica, cómo evaluarla
y, especialmente, cómo enfrentarla.
¿Qué es la deuda técnica?
La deuda técnica es el trabajo
adicional necesario para completar el desarrollo del software. Pero esta
noción no se refiere únicamente a los proyectos que están en desarrollo. Este
problema a menudo sigue los proyectos que han salido a producción durante algún
tiempo. Esto puede ser cualquier cosa, como un módulo escrito en
tecnología heredada, que impide que el proyecto incluya una nueva funcionalidad
o influya en la
estabilidad general del software. En este caso particular, la deuda técnica se
puede calcular como el tiempo o el dinero necesario para la refactorización del
código de este módulo o para transferirlo a la nueva tecnología. Pero, por lo
general, nunca es tan simple y el software incluye una serie de
inconvenientes que pueden incluirse en la deuda técnica del proyecto.
No hacer frente a estas deudas lo
antes posible puede llevar a más deudas en el futuro, lo que dará como
resultado un rendimiento deficiente del software, una dificultad o incluso la
imposibilidad de introducir cambios en el software, un mayor riesgo de romper
el software después de cada actualización. La gestión
de la deuda técnica en una etapa temprana del proceso de desarrollo es crucial.
El uso del término deuda es una
referencia prestada del mundo financiero, y al igual que las deudas
financieras, las deudas técnicas, si no se resuelven muy rápidamente, pueden
generar interés. En otras palabras, la deuda técnica puede generar nuevas deudas
técnicas y puede costar mucho al propietario del software y al equipo de
desarrollo.
Ahora que sabemos qué es la deuda
técnica, ¿cómo la obtenemos?
¿Qué causa la deuda técnica?
Para abordar mejor la deuda técnica,
es esencial comprender qué los causó en primer lugar. Cuatro mayor razones conducen a técnicas deuda :
· Concepción pobre: Al desarrollar una aplicación, la velocidad a la que el equipo o
la compañía entrega el producto puede marcar una diferencia real; después de
todo, una aplicación o software se desarrolla para responder a un problema en
particular o para enfrentar un desafío específico de manera oportuna. Es importante utilizar el producto cuando la necesidad todavía
está allí. La prisa en entregar más rápido a menudo resulta en un software
mal diseñado. El producto de software no está bien pensado y el desarrollo se
centra principalmente en desarrollar las funcionalidades. Puede haber un acuerdo previo al inicio del proyecto entre los
propietarios del producto y el equipo de desarrollo para lanzar las primeras
funciones más rápidamente y asignar tiempo para corregirlas más tarde y así
reducir el tiempo de comercialización. Esta concepción puede ser a nivel tecnológico o nivel de negocio, pues si bien las necesidades son cambiantes deberian tener al menos similitudes entre el planteamiento inicial y su resultado final (de ahi la importancia del analista de negocio y conceptos de arquitectura empresarial).
· Programación deficiente: Subestimando el proceso de estimación de desarrollo de software. A menudo causa deuda técnica. El enfoque de un equipo de desarrollo está en el respeto de las estimaciones de
tiempo y se acumulan una gran cantidad de malas prácticas que en última
instancia se tendrá que pagar. Esta es una de la principales causas, cuando las necesidades comerciales se contraponen con las necesidades del proyecto y se trata de cumplir las espectativas comerciales por sobre las espectativas tecnologicas.
· Malas prácticas de desarrollo: Es crucial que el equipo de desarrollo tenga un conjunto de
prácticas y convenciones para que no exista una diferencia significativa en el
diseño y la implementación de una característica a otra. La falta de buenas
prácticas y convenciones de desarrollo llevará a los desarrolladores a
implementar su diseño, a reconstruir la misma lógica una y otra vez, y a
formatear su código de la forma que deseen, en lugar de la forma en que
comúnmente se acepta en el proyecto de software en particular.
· Tecnología obsoleta: A medida que la tecnología evoluciona, los estándares de
software se vuelven más altos cada día. Con cada mejora , nuevas técnicas. La deuda puede surgir .
Ahora que entendemos qué es la deuda
técnica y cómo obtenemos deuda técnica en nuestros proyectos, veamos formas de
medir la deuda técnica.
Tipos de
deuda técnica
Hemos explorado qué es la deuda
técnica. Esto es importante para medir la deuda técnica con precisión, ya
que la estimación de la deuda técnica depende de su naturaleza. los más común tipos de técnica las deudas son:
· Formato de código fuente: Esto es muy común, pero afortunadamente, es el más fácil de
solucionar. El uso de la herramienta y la plantilla adecuadas durante e
incluso mejor antes de comenzar el proceso de desarrollo puede reducir
drásticamente este tipo de deuda técnica.
· Cobertura de prueba baja: La cobertura de prueba es una medida esencial de la calidad del
código, especialmente cuando usamos la metodología Agile para respaldar el
proceso de desarrollo. Las pruebas
aseguran que cada parte del código se comporte de la manera deseada. Un nivel muy bajo de la cobertura de la prueba reduce la certeza
de la precisión del comportamiento del software y dificulta la resolución de
problemas cuando ocurren.
· Falta de modularidad: Esto generalmente resulta de un diseño de código pobre. Algún código a veces sirve diferente lógica de negocios. Cuantos más códigos escriban los desarrolladores, más falta de
modularidad puede causar el cuello de botella. Es
más difícil administrar software que tiene lógicas en todos los códigos y
partes de códigos que manejan varias lógicas.
· Complejidad de código: La complejidad se puede medir de varias maneras diferentes, pero
mide la dependencia y la longitud de la ruta para realizar una operación. Un largo el camino conduce al complejo código.
· Ausencia de la documentación: La documentación es parte de las mejores prácticas de desarrollo
de software. El software es a menudo impulsado a evolucionar. Es importante que el código escrito siempre sea comprendido en
todo momento por todas las personas que puedan estar involucradas en el proceso
de desarrollo.
Ahora que hemos identificado los
tipos de deudas técnicas, veamos cómo estimarlas.
Estimación
de la deuda técnica
Ahora que hemos visto qué es la
deuda técnica y hemos revisado los tipos de deudas técnicas, es crucial
encontrar el enfoque correcto para medir la deuda técnica. De ninguna
manera debe calcularse manualmente, ya que hacerlo requerirá ingresar al código
y detectar todos los problemas internos y luego estimar cada posible problema
uno por uno. No solo lleva mucho tiempo proceder de esa manera, sino que es
casi imposible estimar los códigos en evolución. En el
momento en que se realiza la medición de la deuda técnica, los códigos ya
tienen un estado diferente.
Un enfoque es realizar un análisis estático
de código usando herramientas que apoyan el análisis. La siguiente
es una lista de las herramientas más populares utilizadas:
· Coverity
Hay dos formas de medir la deuda
técnica. El primero es obtener una relación de deuda técnica según el
volumen del código, y el segundo es utilizar directamente las estimaciones
proporcionadas por las herramientas (como SonarQube), junto con la lista de
deudas técnicas y sus referencias al código, SonarQube da una estimación en días u horas necesarios para arreglar esta deuda. Para el
enfoque de ratio, podemos utilizar las estimaciones iniciales o, mejor aún, el
tiempo total necesario para desarrollar el software hasta ahora y extrapolar el
valor de acuerdo con el ratio de deuda técnica. El tiempo
necesario para el desarrollo es muy preciso, por lo que medir la deuda técnica
en función de la relación puede proporcionar una estimación precisa del trabajo
necesario para solucionar los problemas.
La medición de la deuda técnica nos
da una aproximación del tiempo necesario para solucionar la deuda técnica. Arreglar las
deudas técnicas cuesta dinero, y el equipo de desarrollo necesitaría días
hábiles adicionales para solucionarlos. Cuantas más
deudas técnicas deban arreglarse, más tiempo necesitará el equipo de desarrollo
para solucionarlas. Dejar las deudas técnicas dentro del código no es una opción, ya
que las deudas técnicas, si no se corrigen, conducirán a más deudas técnicas
que harían que los cambios futuros sean cada vez más difíciles. Aunque el
intento de reducir las deudas técnicas puede ser costoso, no abordarlas en una
etapa más temprana costará más dinero en el futuro.
Cómo
reducir o eliminar la deuda técnica
Ser ágil es la mejor manera de
administrar la deuda técnica y reducirla cuando aparece. Cuanto antes
abordemos el problema, menos intereses tendremos que pagar con el tiempo. Para abordar
la deuda técnica, los equipos de desarrollo de software pueden utilizar el
siguiente enfoque.
· El más rápido de resolver: Reparar deudas que requieren poco tiempo para arreglarlas es una
excelente manera de eliminar gradualmente las deudas técnicas. Las deudas como el formato de código se pueden resolver en poco
tiempo, formando una plantilla y aplicando estas plantillas a todos los códigos
que se han desarrollado hasta ahora, luego integre estas plantillas en las
herramientas utilizadas por los desarrolladores.
· Prioridad: También
es importante abordar los problemas por prioridad. Todos los problemas que pueden conducir a problemas más
importantes deben abordarse rápidamente y deben priorizarse para evitar la
acumulación.
· Actualización de tecnología: Cuando la tecnología obsoleta conlleva una deuda técnica, es
importante actualizar el software a las versiones más recientes de los frameworks,
servidores de aplicaciones, bases de datos, etc. Incluso es importante incluir
cada evolución estable de un framework utilizado, por ejemplo, para tener siempre la última
actualización. Y para traer pequeños cambios sin romper el software.
· Refactorización: Revisar la arquitectura del software y los códigos de
refactorización a menudo puede ser útil cuando no queremos terminar con códigos
duplicados o que carezcan de modularidad.
Estos son enfoques útiles para
reducir o eliminar la deuda, pero ¿cómo manejar la deuda técnica en procesos
ágiles? Como el equipo de desarrollo debe aspirar a resolver la deuda
técnica, la deuda técnica debe ingresarse en la cartera de productos como una
historia de usuario y debe priorizarse como cualquier otra historia de usuario. La
priorización debe tener en cuenta el impacto de no gestionar la deuda técnica
identificada al comienzo de una nueva iteración. Al decidir
qué historias incluir en la próxima iteración de desarrollo, debemos analizar
si posponer la corrección técnica de la deuda para la próxima iteración es más
o menos ventajoso a largo plazo. Como regla general, deberíamos
abordar todos los problemas críticos tan pronto como se identifique.
Pensamientos
finales
Tener una deuda técnica en algún
momento del proceso de desarrollo del software es bastante habitual. Sin embargo,
la gestión de la deuda técnica es importante para evitar su acumulación en el
tiempo. A veces, se puede requerir que acepte una cierta cantidad de
deuda técnica, pero en última instancia, debe mantenerse a un nivel aceptable
en el que no perjudiquen el rendimiento ni la experiencia general de los
usuarios de productos de software.
Contrariamente a la estimación del
tiempo de desarrollo, la estimación de la deuda técnica se basa en el código
existente que a menudo evoluciona. Entonces es necesario tener un buen
enfoque para estimar la deuda técnica incluida en el software desarrollado. Debido a la
naturaleza siempre cambiante del código y al volumen de códigos que se
evaluarán, no es posible realizar una estimación manual. Entonces es
necesario trabajar con las herramientas adecuadas que permitan un cálculo
automático de las estimaciones técnicas de la deuda.
Aunque hacer frente a la deuda
técnica puede costar dinero, dejar las deudas técnicas en el software costará
más dinero en el futuro.
Tener una relacion fuerte entre la parte comercial y la operativa es crucial pues es una de las situaciones mas complejas, por un lado puedes obtener el "tiempo necesario" para el proceso de desarrollo y por otro te puedes quedar fuera de mercado, por ello como parte del proceso de administracion de proyectos es realmente importante contar con el equipo adecuado para poder minimizar la incertidumbre y que éste equipo pueda re aprender y evolucionar con el tiempo.
