Desarrollo ágil

Como barry Boehm lo ha sugerido, uno debería dejar que los requerimientos de un proyecto cambien mientras vamos desarrollando una solución. Por mientras se soluciona un problema, los clientesaprenden sobre cuáles soluciones son prácticas y posibles, mientras que los equipos de desarrollo aprenden sobre el problema y cómo el software afecta las prácticas de negocio. Un problema y su solucióninteractúan; aprender más sobre uno genera una influencia sobre lo que creemos del otro. El cómo aplicamos esta idea nos separa en dos escuelas de pensamiento sobre lo que los requerimientos de softwaredebieran ser.
Muchos ingenieros de software creen que se debe tener una solución creada y meticulosamente verificada para la solución del problema antes de escribir el código fuente del programa. Porotra parte, algunos creemos que el problema no se ha solucionado hasta que el programa no sea entregado y se demuestre que este funciona. Esta diferencia de percepción sobre cuándo está solucionadoun problema es lo que causa que haya una diferencia sobre el cómo vemos lo que es la documentación de los requerimientos. Yo creo que los requerimientos debiesen describir el problema, no la solución,porque el problema no está solucionado hasta que el código no está funcionando.
La recolección de requerimientos que propone una solución es popular porque se complementa con el modelo de negociodonde la estimación de costos se hace poco después de tener los requerimientos hechos. Considere la diferencia entre la estimación de costos de el solucionar un problema con la estimación del costo deuna solución. A primera vista, parecen ser la misma cosa, y ocasionalmente lo son. Pero si es que lo son, es solo una coincidencia. La solución que se especifica como parte de nuestros requerimientosno es necesariamente la solución que implementaremos. Para hacer una estimación de manera fácil, eliminamos los factores desconocidos para proponer una solución. Claramente, la estimación de costos...