Ticker

6/recent/ticker-posts

La deuda técnica

La deuda técnica, también conocida como deuda tecnológica y deuda de código, suele producirse principalmente cuando los equipos de desarrollo optan por escribir código rápido al crear nuevas funciones de un producto de desarrollo de software. En resumen la deuda técnica, es el costo del retrabajo causado por la elección de la solución más rápida en lugar de la más efectiva.

La entrega de un producto basado en código rápido puede ayudar al equipo a cumplir con los plazos, y la deuda que se acumula puede valer la pena, aunque también podría conducir a resultados negativos si se gestiona de forma incorrecta. Estos resultados negativos no siempre se pueden evitar una vez que se toma la decisión de acumular deuda técnica.

La deuda técnica se basa en resultados positivos o negativos, nos enfocaremos en describir y brindar datos importantes sobre la deuda técnica, y estar preparados con la finalidad de tomar las mejores decisiones en el momento que lo necesitamos.

La deuda técnica es una expresión originalmente por Ward Cunningham en 1992 -  Desarrollador de software, el término ha evolucionado desde entonces.


Cuadrantes de la deuda técnica:

Existen cuatro causas diferentes de la deuda técnica, los cuatro cuadrantes de la deuda técnica definidos por Martin Fowler, son: imprudente, prudente, deliberado e inadvertido.


Estos cuadrantes ayuda a medir la intención y los antecedentes de los problemas de código, teniendo en consideración, que algunas deudas de código pueden ser deliberadas y clasificadas como deuda buena, otras pueden ser inadvertidas y clasificadas como deuda mala. Para un mejor entendimiento, considera la lectura de los cuadrantes de la siguiente manera:

  1. Prudente y deliberada: La decisión de hacer una entrega rápida y lidiar con las consecuencias más tarde provoca una deuda prudente y deliberada. Este tipo de deuda, por lo general, se utiliza cuando lo que está en juego es relativamente poco y las ventajas de una entrega rápida superan el riesgo. 
  2. Imprudente y deliberada: Saber producir el mejor código pero priorizar la rapidez en la entrega es la causa de la deuda imprudente y deliberada.
  3. Prudente e inadvertida: La deuda prudente e inadvertida ocurre cuando se desea producir el mejor código, pero encuentras una mejor solución después de la implementación. 
  4. Imprudente e inadvertida: La deuda imprudente e inadvertida ocurre cuando un equipo intenta producir el mejor código sin el conocimiento necesario para hacerlo. Por lo general, el equipo no es consciente de los errores que está cometiendo.
La deuda técnica deliberada en pos de una entrega rápida es eligido por los equipos, mientras que la deuda técnica inadvertida es accidental, sucede después de la implementación. El ingeniero de software Steve McConnell explica mejor esta diferencia al describir los dos tipos generales de deuda técnica. Analicemos en detalle cada uno de ellos para comprenderlos mejor.

Tipos de deuda técnica:

Según Steve McConnell - Ingeniero de Software en el año 2007, habló de dos tipos de deuda técnica, la intencional y la no intencional:

Intencionada: También llamada activa o deliberada, ocurre cuando la organización asume conscientemente como herramienta estratégica.

No intencionada: También conocidas como inadvertida o pasivas, ocurre principalmente cuando es el resultado no estratégico de hacer un mal trabajo.


Principales causas de la deuda técnica:

Normalmente las principales causas son:

  • Falta de definición del proyecto.
  • Falta de presupuesto económico.
  • Falta de objetivos claros y medibles.
  • Falta de buenas práctica en el desarrollo.
  • Falta de colaboración del negocio.


Cómo evitar la deuda técnica:

Desarrollar e implementar un proyecto de software de manera acelera y cumplir con todas las buenas practicas y estándares es un desafío, teniendo en consideración en factor tiempo, es complicado NO escapar de una deuda técnica, sin embargo, existe formas de evitarla para que no se convierta en un problema complejo de resolver más adelante; a continuación detallamos algunas medidas para prevenir o reducir la deuda técnica:

  • Establecer tiempo razonable al equipo de desarrollo para aplicar buenas prácticas y mejora continuamente en el código.
  • Aplicar estrategia que administre la deuda técnica con precaución y minimice en generar una deuda de gran impacto al software (producto final).
  • Asignar a personas adecuadas según roles de alta responsabilidad que generen gran impacto en el proyecto.
  • El personal involucrado en el proyecto debe tener claro sus responsabilidades y saber distribuir las tareas en el equipo del proyecto (si tiene personal a cargo).
  • Establecer procesos estandarizados para la refactorización y la gestión de calidad del software.
  • Aplicar patrones de diseño de software y buenas prácticas, desarrollo en base a código limpio y comprensibles.
  • Hacer uso de herramientas adecuadas y actualizadas para medir y analizar los posibles errores que puedan generar deuda técnica.

Métricas:

  • Defectos: El equipo de desarrollo debe tener un estricto seguimiento de los bugs, teniendo en consideración los resueltos al aplicar herramientas que dan una idea de cuánto tiempo debemos invertir en solucionar un problema.
  • Calidad en el código: La calidad del código nos habla de lo que está por debajo de la superficie de nuestro spftware (sistema, aplicación o herramienta digital). Aplicar análisis estático del código para ver su complejidad ciclico es fundamental para orientarnos a los estándares y convenciones de código más adecuadas.
  • Apropiarse del código: A medida que los equipos crecen es más probable que aparezcan deudas técnicas no intencionales, el equipo debe tener una actitud activa sobre el código, es decir, el equipo de desarrollo debe hacer responsable de dicho código, aun si el código es heredado.
  • Cohesión de código: Buscando que nuestro sistema tenga una alta Cohesión y un bajo acoplamiento entre sus partes nos permite saber que el código está más auto contenido y por tanto es más fácil elaborar pruebas individuales para cada parte.
  • Puntos calientes: Buscar lugares de nuestras soluciones que tiene mucho trabajo de reescritura o cambios. Debemos tener un cuidado especial en estos sectores ya que pueden estar evidenciando un área que puede necesitar una reingeniería o refactorización para mejorar.

“Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre”. Lord Kevlin.


Conclusión:

Concientizar sobre la deuda técnica, tanto en el personal involucrado en el negocio como en los pricipales equipos de desarrollo de software es de vital importancia para no generar deudas técnica que impactan en gran manera al producto final (software). Además, la deuda técnica se debe gestionarse adecuadamente para minimizar todos los riesgos que puedan ocuacionar a futuro o de manera inmediata después de la puesta en producción. 

Aplicar herramientas que permite visualizar, analizar y mejorar el flujo de trabajo en el desarrollo de proyectos de software, mejora la productividad y ayuda a detectar o bloquear posibles deudas técnica.

Publicar un comentario

0 Comentarios