Curva del coste del cambio

La razón está en la cantidad de trabajo que se apoya en una decisión. Mientras un requisito solo figura en el concepto, cambiarlo afecta a un documento. Si ya está en el diseño, afecta al diseño y a todo lo derivado de él. Si está implementado y aceptado, se añaden el retrabajo, una nueva verificación, la documentación y la comunicación. Por eso la curva no sube de forma lineal, sino aproximadamente exponencial.

Las cifras se remontan a Barry Boehm, que las dedujo de datos de proyectos en «Software Engineering Economics» en 1981. Para proyectos clásicos con una ejecución cara, por ejemplo en construcción, en ingeniería de plantas o en eventos, la relación sigue vigente. Lo que se cambia en la obra cuesta muchas veces más de lo que habría costado el cambio en la planificación.

En el desarrollo de software la curva se ha aplanado notablemente. Las pruebas automatizadas, la integración continua y las entregas pequeñas reducen mucho el coste de un cambio tardío. Kent Beck formuló a partir de ahí la tesis contraria: si la curva es plana, fijar las cosas pronto deja de compensar, porque entonces se puede decidir en el momento en que más se sabe.

La forma que adopta la curva depende por tanto del proyecto, no del método. Sube con fuerza donde la ejecución es cara y los resultados se apoyan unos en otros, como en construcción o en migraciones. Se mantiene plana donde las correcciones son baratas y se pueden verificar de forma automatizada. La pendiente determina en qué fase del ciclo de vida del proyecto una decisión conserva su valor.