Recientemente me interesé por las prácticas ágiles en el desarrollo de software y desde entonces he visto muchos artículos que señalan que estas prácticas permiten reducir los costos generales.
La lógica detrás de esto generalmente es la siguiente: si sus requisitos cambian, puede reflejar este cambio en el próximo retraso del sprint y esto conducirá a un costo reducido, porque el diseño de la nueva característica y su implementación está muy cerca en términos de tiempo, por lo que el el costo disminuye, de acuerdo con la famosa regla de que cuanto más tarde necesite realizar un cambio en sus requisitos, más costoso será satisfacer ese requisito.
Pero los proyectos de software medianos a grandes son complejos. Un cambio repentino en los requisitos no significa que no tendrá que tocar otras partes de su sistema para cumplir con ese requisito. En muchos casos, la arquitectura deberá modificarse de manera muy significativa, lo que también significa que deberá volver a implementar todas las características que se basaban en la arquitectura anterior. Entonces, todo el punto de los costos reducidos desaparece aquí. Por supuesto, si un nuevo requisito requiere una nueva parte independiente del sistema, eso no es un problema, la arquitectura antigua simplemente crece, no es necesario repensarla y volver a implementarla.
Y lo contrario. Si está utilizando una cascada y de repente se da cuenta de que debe introducirse un nuevo requisito, puede ir y cambiar su diseño. Si requiere que se modifique la arquitectura existente, debe rediseñarla. Si realmente no se mete con él pero solo introduce una nueva parte del sistema, entonces vas y haces todo el trabajo, no hay problema aquí.
Dicho esto, me parece que la única ventaja que tiene el desarrollo ágil es la creación de funciones completas entre sprints, y para muchas personas y proyectos esto no es crítico. Además, parece que ágil da como resultado una mala arquitectura de software en general, porque las características se unen entre sí, a los equipos ágiles solo les importa que una característica funcione, no cómo funciona. Esto parece ser así cuando los sistemas crecen en complejidad con el tiempo, las prácticas de desarrollo ágiles en realidad aumentan el caos en la arquitectura general del producto, lo que eventualmente resulta en costos más altos, ya que será cada vez más difícil introducir cambios, mientras que cascada le permite perfeccionar su arquitectura antes de liberar nada.
¿Alguien puede indicarme dónde me estoy equivocando aquí, porque obviamente mucha gente usa ágil en entornos de producción, por lo que debo estar equivocado en alguna parte.