Procesos agiles

¿Por qué un proceso iterativo facilita más manejar el cambio?
Lo primero que deberíamos hacer es preguntarnos por qué es necesario el cambio, y la razón es muy simple: hay un porcentaje de incertidumbre en los requisitos del cliente, en los análisis, en los diseños... y con un proceso en Cascada no tienes opción de maniobra cuando detectas estos problemas (que se detectan casi siempre, y no necesariamente en la fase de pruebas o despliegue). Con un proceso Iterativo, asumimos que hay incertidumbre, y que en diferentes iteraciones nos aproximaremos más a la solución adecuada, ya que la incertidumbre se reduce. Por hacer un odioso símil, la Cascada dice que el desarrollo software es una función del tipo S=f(x), donde f es el proceso de desarrollo, x son los requisitos de usuario, y S es el resultado. En cambio, los iterativos dicen que el desarrollo software es una expresión polinómica S=P0(x)+P1(x)+P2(x)+...+Pn(x), donde el conjunto de iteraciones es la expresion polinómica: a más iteraciones, más cerca del producto que desea el cliente.

¿Todos los procesos agiles son iterativos?
Creo que todos los procesos ágiles se basan en modelos iterativos: en la base de estos procesos están las entregas rápidas, y el cambio constante sobre las Historias de Usuario.

¿Es posible concluir un proyecto en solo una iteración y aún seguir siendo agil?
Se puede ser ágil con una única iteración, si la iteración abarca todo el proyecto de desarrollo. Es evidente que esto solo tiene sentido si el proyecto tiene muy poca incertidumbre, y si el tamaño de la iteración es suficientemente grande. En este caso, la Cascada y los métodos Iterativos son lo mismo.