Deuda Técnica [Castor sin Filtro]

La “Deuda Técnica (DT)” es un concepto usado en el marco del desarrollo de software que hace referencia a los errores o deficiencias en el código que surgen por malas prácticas en la dirección del equipo, por la falta de refactorización, por la entrega apresurada de productos, entre otras razones. Los participantes de esta conversación de “Castor sin filtro” definieron este fenómeno como el “fantasma” o “lastre” que se lleva a cuestas y que no deja avanzar en los proyectos o que, si bien permite seguir el desarrollo, termina repercutiendo con grandes sobrecostos y sufrimiento para la organización en el largo plazo.

      ´Lo urgente no deja tiempo para lo importante´ es un dicho que dibuja ese lugar desde el cual surge la “Deuda Técnica” y que trae a colación Daniel Ramírez, puesto que para evitar errores es necesario partir de buenas prácticas en la toma de decisiones que permitan saber cómo hacer las cosas de la mejor manera desde un principio. Cuando un producto debe desarrollarse de inmediato, dejando poco margen para decisiones, suelen tomarse caminos rápidos y fáciles que incrementan el riesgo de altos niveles de deuda. 

      Para Felipe Mejía, es imprescindible que los facilitadores y mentores de los equipos tengan claro qué es lo urgente y qué es lo importante de un proyecto y, además, reconozcan la evolución o nuevas demandas de los productos de software para que estos puedan sostener su calidad en el tiempo. Es decir, si se quiere hacer las cosas mejor en el futuro, entonces hay que tomar mejores decisiones en el ahora, no debe haber lugar para la pereza cortoplacista si se quieren evitar en gran medida los sobrecostos. Lo rápido ahora, se convertirá en camino lento después.

Los interlocutores están de acuerdo en que la DT es algo con lo que siempre tendrán que vérselas en una organización, pero hacen énfasis en que existen diversas formas de medirla para que ésta no se salga de control. Un primer paso importante es no confundirla con malas prácticas de los equipos, ni con los acumulados de cada Sprint que surgen por el ´no hay tiempo´: No es “Deuda Técnica” de software aquello que no se hizo en el Sprint. Por ello, es importante partir de la buena comunicación, precisa Juan Andrés Ochoa, quien trae a la conversación la “Ley de Conway” para recordar que los sistemas reflejan las maneras de comunicar de las organizaciones. La transparencia con los equipos asegura el lugar a dónde llegar, pues si todos los participantes comparten la misma “definición de terminado” y forman una red de apoyo en torno a la calidad y las buenas prácticas, es poco probable un alto crecimiento de DT.

      A modo de conclusión, si se afirma que la “Deuda Técnica” puede surgir por afán, pereza, falta de comunicación en el equipo de trabajo, o por incapacidad o inexperiencia del programador, ¿cómo hacer para detener esta deuda en los procesos organizacionales? Por un lado, es necesario generar valor en el equipo con prácticas de “Agilidad”, DevOps y Scrum para entregar valor real en el producto. En segundo lugar, realizar iteraciones cortas de entrega y de revisión de código para ir corrigiendo en el camino, incluyendo pruebas automatizadas. Por último, es de gran importancia generar confianza en los proyectos y hacer que el cliente desee invertir en las buenas prácticas de equipos que aseguran una disminución de la DT.

Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.