Aquí hay un ejemplo de desarrollo de software ágil comparado con el de cascada:
Toma un banco que necesita actualizar el software que utiliza. Pasan muchas horas de trabajo escribiendo requisitos muy detallados para cada eventualidad posible. Cuando terminan de escribirlos, los pasan a los desarrolladores que los interpretan y los codifican. Se reúnen de vez en cuando para discutirlo y todo el mundo vuelve a sus escritorios y trabaja por su cuenta. Cuando llega el momento de la implementación, el director del proyecto descubre que lo que construyeron no era exactamente lo que se esperaba porque construyeron lo que entendieron pero la comprensión era errónea.
Ahora toma el mismo Banco que trabaja en Agile y que necesita actualizar el mismo software . Antes de escribir una palabra de documentación, se reúnen y hacen una tormenta de ideas. Literalmente, todos se paran alrededor y discuten lo que necesitarán construir. Mientras discuten, crean historias sobre cómo el usuario interactuará con el sistema. Escriben estas historias de usuario y luego desarrollan los criterios para cada funcionalidad que se les ocurre. Hacen esto repetidamente y cuando todos terminan entienden lo que hay que construir. El código se construye de dos en dos semanas y se comprueba para asegurarse de que es correcto antes de pasar a construir más. La documentación se redacta como una recopilación de las historias de usuario junto con una guía de los cambios. En el momento en que el proyecto está hecho, lograron lo que se esperaba.
Parece que ágil trabajó nuestro mejor.
No digo que ágil resuelve todo o que los proyectos de software no pueden fallar incluso con ágil, pero el poder de la comunicación es muy fuerte y realmente ayuda a los equipos ágiles más que en cualquier otra metodología de desarrollo.
Para más sobre la escritura de historias de usuario leer este artículo, también echa un vistazo a este artículo: Qué es el desarrollo de software ágil.