# 5. Cambios

Ágil implica la apertura al cambio, por lo que es común que todos los proyectos ágiles estén expuestos a cambios, y es de vital importancia que los miembros del equipo estén preparados para enfrentar los cambios en cualquier etapa del proyecto.

Es aún más importante que la organización sea consciente de la exposición a los cambios para crear sinergia con los equipos Scrum y buscar aprovechar los beneficios minimizando el impacto negativo que pudiese resultar del cambio.

Dada la naturaleza iterativa o incremental de Scrum, es posible manejar los cambios sobre el producto de una manera ordenada y cíclica, respondiendo continuamente a lo que espera el cliente; en correspondencia con el manifiesto ágil, *“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”.*

Aunque en Scrum hay una fuerte inclinación a no mantener grandes cantidades de información sin valor, una forma apropiada de solicitar los cambios sobre los productos Scrum, es a través del formato para Solicitud de Cambios – RFC (Request For Change), sin embargo esto no implica que necesariamente haya documentación de por medio.

Un buen RFC, debería tener como mínimo los siguientes componentes:

- ¿Quién solicita el cambio? ¿Por qué? ¿Para qué necesitamos hacerlo?
- ¿Para cuándo se necesita?
- ¿Qué tan importante es?
- ¿Qué pasa si no se realizara/aprobara el cambio?
- ¿Quién lo va a ejecutar? ¿Qué necesita? ¿Es un empleado o debemos contratar?

Es importante que detrás de cada cambio solicitado exista un “iniciador” para mantener la traza entre el cambio y saber de dónde proviene. Además dentro de la gestión de cambios en Scrum se reconoce la autoridad del Product Owner en la aprobación/rechazo de los cambios, por lo que es importante que durante todo el proyecto, el Product Owner esté enterado de lo que sucede con el producto.

A continuación, se describe el flujo de los cambios:
 
**dibujo**

- El Product Owner es el rol responsable de aprobar/rechazar los cambios, sin embargo, en algunas ocasiones cuando los cambios se salen de su conocimiento o están por fuera del alcance definido para el proyecto podrá escalar los cambios a la gerencia de la organización.
- Los cambios pueden venir de distintas fuentes, las más comunes son:
	- Cambios solicitados por las partes interesadas.
	- Solicitudes realizadas por los miembros del Equipo.
	- Nuevas tecnologías emergen y es necesario realizar cambios al producto.
	- El producto definido comienza a perder vigencia y es necesario cambiar el alcance.