Uno de los motivos, creo, que impulsaron el nacimiento de ‘agile’, aunque sin duda no el único, fue la más que imperfecta gestión de los requisitos del software que se produce cuando se aplica el modelo en cascada tradicional.
Cuando se aplica en modelo en cascada puro la especificación de requisitos se produce al inicio del proyecto. En ella se debe definir de forma completa e inequívoca lo que se espera que haga el software. A partir de ahí la especificación debe quedar congelada o actualizarse mediante un riguroso proceso de gestión del alcance.
Es cierto que los métodos de ingeniería software, incluso métodos en cierto sentido tradicionales como el Método Unificado, admiten la necesidad de unas ciertas iteraciones que pueden convertir a esa especificación en menos monolítica e inamovible.
Sin embargo, llega un punto en que los requisitos se congelan. En realidad, si se piensa, el planteamiento es bastante lógico y racional y parece perfectamente alineado con las buenas prácticas de la dirección de proyectos.
Y, sin embargo, esa especificación de requisitos inicial, tiene a fallar, tiende a funcionar mal. ¿Por qué?
En su libro ‘Métodos Ágiles. Scrum, Kanban, Lean‘, Carmen Lasa, Alonso Álvarez y Rafael de las Heras nos identifican cuatro motivos.
En la siguiente lista, en negrita, el texto con el motivo tal y como lo aportan los autores en el libro. Los comentarios que le siguen son míos.
- Desconexión entre las personas que definen los requisitos y las personas que los llevan a cabo: existe, en efecto, la mala costumbre de alejar al usuario final o al responsable del negocio del desarrollador. No es extraño que al usuario le represente una persona (que no es el propio usuario) quien, a su vez, habla, no con el desarrollador, sino con un analista que es quien suele plasmar formalmente los requisitos que se trasladan luego al desarrollador. No es extraño que se produzca el efecto ‘teléfono escacharrado’ y que lo que finalmente entienda el desarrollador tenga poco que ver con lo que realmente quiere o necesita el usuario. A ese respecto, no puedo olvidar la sensación (ya que los detalles sí que se me han olvidado) que tuve hace bastantes años cuando, en medio de un desarrollo que estábamos llevando a cabo con la mejor de las voluntades, y que pensábamos estábamos ejecutando de forma excelente, y con el desarrollo avanzado, tuvimos la oportunidad de hablar con usuario final… Y la sorpresa fue mayúscula al comprender que lo que necesitaba ese usuario era algo bastante diferente y muchiiiiiísimo más sencillo que lo que le estábamos preparando con toda nuestra mejor intención. Cuánto tiempo nos habríamos ahorrado y cuánto más habríamos acertado si hubiésemos podio hablar con el usuario desde el principio.
- Interpretación ambigua de los requisitos: En efecto, los requisitos deben ser inequívocos, pero es muy, muy difícil de conseguir. Requiere mucho rigor conceptual e incluso mucha capacidad de escritura, para plasmar en un papel unos requisitos exactos, completos y sin ambigüedad ninguna. Además, muchas veces el esfuerzo de conseguir esa exactitud es exagerado para el alcance de lo que se está especificando.
- Cambio de los requisitos desde que se definen hasta que se implementan: en este caso puede deberse, tanto a una falta de disciplina en la gestión del proyecto (tanto por el equipo de desarrollo como por el usuario o negocio) que no se esfuerzan lo suficiente en cerrar los requisitos, como, y esto es más difícil de salvar, a la falta real de imaginación o análisis para, en abstracto, y sin haber visto nada del software, saber concretar todo lo que se necesita y cómo se necesita.
- Necesidad de incorporar nuevos requisitos durante el ciclo de vida del desarrollo de un producto: creo que, de nuevo, se puede deber a falta de disciplina pero también de previsión, imaginación o abstracción.
Es, entre otras cosas, para salvar todas estas carencias que los métodos ‘agile’ proponen ciclos de desarrollo muy rápidos y una presencia constante y cercana del usuario/negocio en el equipo de proyecto.
