Una investigación comisionada por una consultora encuentra que los proyectos de software desarrollados mediante las llamadas metodologías ágiles tienen tasas de fallos un 268% mayores que los que no utilizan esas metodologías.
Si bien esta investigación en concreto podría ser etiquetada por algunos como una forma de «investigación de parte», de intentar vender las metodologías de desarrollo de esa consultora concreta, la realidad es que las metodologías ágiles han sido durante mucho tiempo objeto de fuertes críticas y que los estudios que intentaban probar su idoneidad han aportado muy pocas evidencias concluyentes sobre sus supuestas ventajas.
El llamado «Manifiesto por el desarrollo ágil de software«, traducido a más de setenta idiomas, es una declaración de principios generalista basada en doce principios sumamente grandilocuentes, que parte de una definición y un término eminentemente cargado de positivismo: ¿quién iba a oponerse a la idea de «ser ágil»? Sin embargo, y a pesar de los muchos apoyos que recibió el manifiesto en su momento y de la gran cantidad de compañías que lo abrazaron como verdad única, la realidad es que en muchos casos, la supuesta metodología tiende a convertirse en equipos que hablan demasiado del software sin llegar a escribir software, que se dedican a mantener simbólicas reuniones de pie que son en realidad una forma sutil de liderazgo unidireccional encubierto, y a gastar notitas adhesivas como si no hubiera un mañana o como si todos fuéramos accionistas de 3M.
Según uno de los firmantes originales del manifiesto ágil, Dave Thomas,
«La palabra ‘ágil’ se ha subvertido hasta el punto de que en la práctica ya no tiene sentido, y lo que pasa por una comunidad ágil parece ser en gran medida un ámbito para que consultores y proveedores se dediquen a pregonar sus productos y servicios»
El énfasis en cuestiones como los individuos y sus interacciones sobre los procesos y las herramientas parece que incide de manera clara en tasas de fallos superiores, como lo hace también el quitar relevancia a los procesos de documentación. Una cosa es odiar los procesos de documentación, algo común a la práctica totalidad de los desarrolladores, y otra pretender que no documentar porque hay que priorizar que el software funcione sea, como tal, una práctica que genere resultados estables o sostenibles.
Por otro lado, está por ver que las metodologías ágiles, como su nombre debería implicar, generen en realidad proyectos con un desarrollo más rápido: el 65% de los proyectos que emplean este tipo de metodologías sufren retrasos en su fecha prevista de entrega. Según la investigación, lo que realmente importa en un proyecto de software opara poder entregarlo a tiempo y dentro del presupuesto establecido es un buen proceso de determinación de la ingeniería de requisitos, y que los desarrolladores tengan la seguridad psicológica para poder discutir libremente y resolver problemas cuando vayan surgiendo, además de tomar medidas que eviten el agotamiento de los desarrolladores. Fiar ese tipo de factores a unas metodologías ágiles enormemente vagas y genéricas es, simplemente, encomendarse a un supuesto atributo, la agilidad, con connotaciones positivas, pero que posiblemente ofrezca muy pocas herramientas concretas.
¿Es el agilismo en realidad una especie de moda o culto, que ha terminado teniendo implicaciones negativas en el desarrollo de software? ¿O simplemente un conjunto de buenos deseos que sufren cuando se encuentran con la realidad? Tras años predicando de forma grandilocuente la agilidad por todas partes y como supuesta solución a todos los males, ¿es momento de plantear otras formas de hacer las cosas?
This article is also available in English on my Medium page, «Why agile is not always a good thing«
