Por Oscar A. Esquivel Oviedo – Estudiante de la Maestría en Gerencia de Proyectos

Las metodologías ágiles surgieron hace décadas. En el año 2001 se publicó el manifiesto ágil, una recopilación de valores y principios escrita por autores como Kent Beck, Martin Fowler, Robert C. Martin, Ron Jeffries, entre otros. Este manifiesto proponía darles prioridad a las personas, a la colaboración entre desarrolladores y clientes, a crear software funcional, y a poder reaccionar bien ante el cambio; dejando atrás el estricto seguimiento de procesos, la rigidez de los contratos, la documentación exhaustiva, y el apego a un plan que no se puede cambiar. Pero después de tantos años de incorporar estas metodologías, de pizarras repletas de papeles adhesivos, incontables certificaciones otorgadas y miles de líneas de código sin ninguna documentación asociada, la comunidad global de desarrolladores parece estar de acuerdo en lo siguiente: esto no es lo que se prometió originalmente; y, en lo personal, concuerdo completamente.

En diversos foros de Internet pueden encontrarse los principales problemas: las metas escogidas parecen ser aleatorias, los plazos definidos no son realistas, hay más burocracia en lugar de menos, ya no hay espacio para la creatividad del desarrollador, y la más popular de todas: el trabajo siempre es apurado, siempre hay prisa, y todo es urgente (Krush, 2019). Incluso dos de los autores del manifiesto ágil previamente mencionados, Robert C. Martin y Ron Jeffries, comparten la opinión de que las ideas originales de agilidad se han perdido (Jeffries, 2018). Según ambos, el movimiento ágil ha sido secuestrado por administradores que no entienden cómo se construye el software, pero obtienen certificaciones fáciles en Scrum y otros, y piensan que eso basta (Krush, 2019). Opinan que es lógico que las empresas noten una mejoría, aunque usen estas metodologías de forma incorrecta de todas maneras se prestan para conseguir al menos un poco más de valor un poco más rápido (Jeffries, 2018). El problema es a largo plazo, porque cuando el software no se construye correctamente, lentamente empieza a aumentar y aumentar la deuda técnica

Los casos de éxito sobran. Es bien sabido que adoptar una metodología ágil en el desarrollo de software puede llevar a una mejor calidad, más transparencia a través de nuevas métricas (NTask, 2020), un mayor enfoque en los usuarios y su satisfacción, mayor participación por parte de los involucrados, entregas más rápidas y predecibles, y mejor adaptabilidad al cambio (Blueprint, 2020). Las empresas reportan una reducción en la cantidad de defectos y en la duración de lo ciclos de entrega (Krush, 2019). Pero con tantos beneficios es fácil dejarse llevar y pensar que la agilidad es la panacea, cuando no es así. Si la ejecutamos mal, si nos olvidamos de los valores y principios del manifiesto ágil, si ignoramos la opinión de los desarrolladores mientras les decimos que se apuren y que sean más ágiles, invitamos a que crezca esa deuda técnica, escondida, invisible para nosotros, al menos hasta que empiece a notarse por su impacto.

Eventualmente la deuda técnica puede afectar cualquier software al que se le permita madurar. De no hacer algo al respecto, esta continuará creciendo indefinidamente, hasta que haya una especie de colapso. Por esto debemos tomar un paso atrás, recordar los valores y principios del manifiesto ágil, escuchar a los desarrolladores, y asegurarnos de que la deuda técnica no esté creciendo sin control.

 

MOXIE es el Canal de ULACIT (www.ulacit.ac.cr), producido por y para los estudiantes universitarios, en alianza con el medio periodístico independiente Delfino.cr, con el propósito de brindarles un espacio para generar y difundir sus ideas.  Se llama Moxie - que en inglés urbano significa tener la capacidad de enfrentar las dificultades con inteligencia, audacia y valentía - en honor a nuestros alumnos, cuyo “moxie” los caracteriza.

 

Referencias bibliográficas: