6. CAMBIO
6.6 Cambio en portafolios y programas
Cualquier cambio que surja, ya sea en los programas o portafolios, puede tener un efecto en cascada en todos los proyectos dependientes y sprints. Por lo tanto, se recomienda minimizar los cambios en estos niveles más altos. Si se requiere un cambio, y todos los stakeholders están de acuerdo en hacerlo a estos niveles, se debe tomar en cuenta lo siguiente:
6.6.1
En portafolios
1. No se recomienda hacer cambios entre dos reuniones de Portfolio Backlog.
2. Si el cambio es menor, el Portfolio Product Owner debe contar con la aprobación de los stakeholders correspondientes (por ejemplo, el patrocinador, el cliente y el usuario meta) y después añadir los requisitos al Portfolio Backlog. Los Product Owners y del programa y del proyecto analizarán los requisitos para su inclusión en futuros sprints.
3. Si el cambio es importante, las actividades del portafolio, junto con los programas asociados, los proyectos y los sprints tienen que detenerse y se debe llevar a cabo una reunión del Portfolio Backlog para determinar cuáles serán los siguientes pasos.
4. Las reuniones del Backlog Priorizado del Producto del Portfolio (también conocidas como reuniones del Program Backlog), deben llevarse a cabo en intervalos de 4 a 12 meses. La frecuencia y el impacto de los cambios en un portafolio determinan en gran medida la duración de tiempo entre dos reuniones del Portfolio Backlog. Si son varios los cambios esperados en el portafolio, es preferible llevar a cabo este tipo de reuniones en intervalos más frecuentes (por ejemplo, de cuatro a seis meses); pero si hay menos cambios esperados, y si los requisitos son estables, la duración entre dos reuniones podría aumentarse (por ejemplo, de 9 a 12 meses).
6.6.2
En programas
1. No se recomienda hacer cambios entre dos reuniones del Program Backlog.
2. Si el cambio es menor, el Program Product Owner debe contar con la aprobación de los stakeholders correspondientes (por ejemplo, el patrocinador, el cliente y el usuario meta) y después añadir los requisitos al Program Backlog. Los Product Owners y del programa y del proyecto analizarán los requisitos para su inclusión en futuros sprints.
3. Si el cambio es importante, las actividades del programa, así como los proyectos y sprints relacionados deben detenerse y se debe llevar a cabo una reunión del Product Backlog para determinar cuáles serán los siguientes pasos.
4. Las reuniones del Backlog Priorizado del Producto del programa (también conocidas como reuniones del Program Backlog), deben llevarse a cabo, de preferencia, en intervalos de dos a seis meses. La frecuencia y el impacto de los cambios en un programa determinan en gran medida la duración de tiempo entre dos reuniones del Program Backlog. Si hay varios cambios previstos en el programa, es preferible llevar a cabo este tipo de reuniones en intervalos más regulares (por
6
ejemplo, de dos a tres meses); pero si hay menos cambios esperados y si los requisitos sonestables, la duración entre dos reuniones podría aumentarse (por ejemplo, de cinco a seis meses). La figura 6-8 muestra cómo se pueden administrar los cambios dentro del flujo de Scrum tanto para los portafolios como para los programas.
6.7 Resumen de responsabilidades
Rol Responsabilidades
Equipo Scrum • Sugiere mejoras o cambios durante los procesos de Crear entregables y Realizar Daily Standup.
Product Owner/ Chief Product Owner
• Proporciona solicitudes de cambio de un proyecto
• Evalúa el impacto de las solicitudes de cambio planteadas por el portafolio, el programa o el proyecto
• Prioriza las historias de usuario en el Backlog Priorizado del Producto del proyecto
• Evalúa el impacto de los problemas sobre los objetivos del proyecto identificados por el Equipo Scrum
• Proporciona una comunicación clara a los stakeholders sobre los elementos del Product Backlog que se han vuelto a priorizar Scrum Master/
Chief Scrum Master • Facilita la identificación y evaluación de los problemas y solicitudes de cambio por el Equipo Scrum Program Product
Owner
• Proporciona solicitudes de cambio para los programas
• Aprueba los productos que son modificados, eliminados o agregados de acuerdo con los requisitos del programa
Program Scrum
Master • Facilita la identificación, evaluación y gestión de las solicitudes de cambio para los programas
Portfolio Product Owner
• Proporciona solicitudes de cambio para los portafolios
• Aprueba los productos que son modificados, eliminados o agregados de acuerdo con los requisitos del portafolio
Portfolio Scrum
Master • Facilita la identificación, evaluación y gestión de las solicitudes de cambio para los portafolios
Stakeholder(s) • Proporciona solicitudes de cambios
• Participa en la aprobación y priorización de las solicitudes de cambio Scrum Guidance
Body • Proporcionar una guía general para los procedimientos de gestión de cambios que deben seguirse durante todo el proyecto
6
6.8 Scrum vs. Gestión tradicional de proyectos
La gestión de cambios en los proyectos que se gestionan en forma tradicional está estrechamente relacionada con la gestión de la configuración. Todos los cambios se consideran con base en su magnitud de variación desde un valor base. Al Project Manager se le permite gestionar las actividades y decisiones diarias del proyecto. Cuando una solicitud de cambio supera las tolerancias definidas, el Project Manager debe llevar la propuesta de cambio a niveles superiores de gestión y esperar la decisión antes de hacerla efectiva. El Project Manager registra primero la petición de cambio en un registro de problemas o cambios (Issue Log o Change Log) y después presenta el cambio a autoridades superiores. Estas podrían incluir al patrocinador del proyecto (Project Sponsor), así como a otros stakeholders relevantes y a aquellos que toman decisiones sobre el caso. En algún momento se deberá llevar a cabo una evaluación del impacto. Con base al impacto estimado del cambio, se tomará una decisión respecto a si el cambio debe aplicarse o no. El Project Manager también podrá proponer posibles soluciones a los problemas planteados por el cambio. Si las autoridades superiores deciden proceder con el cambio, el Project Manager es responsable de asegurar que el cambio se implemente correctamente.
El cambio en Scrum funciona de manera muy diferente en comparación con la gestión tradicional de proyectos. El framework de Scrum está altamente enfocado en la gestión de cambios de manera eficaz y eficiente. Cada vez que el Product Owner o el Equipo Scrum reconoce un problema o defecto o identifica un elemento del Backlog Priorizado del Producto que deba modificarse, sustituirse o añadirse, el cambio se realiza en el Backlog Priorizado del Producto. Del mismo modo, la alta gerencia, el Product Owner o el(los) stakeholder(s) puede(n) añadir solicitudes de cambio a dicho backlog. El Product Owner y el(los) stakeholders aprueba(n) las solicitudes de cambio y las nuevas prioridades del portafolio según corresponda. Siempre que hay un problema o una nueva exigencia que se deba atender, la cual resulta en cambios inmediatos que afectan el sprint actual, el Product Owner debe cancelar el sprint con la aprobación de los stakeholders relevantes. Una vez terminado, el sprint se vuelve a planificar y a reiniciar para incorporar los nuevos requisitos.
Sin embargo, si el problema o cambio no es importante y no garantiza un cambio dentro del sprint actual, el cambio se añadirá al Backlog Priorizado del Producto y se incorporará en la planificación para un futuro sprint. Esto les da a los stakeholders la capacidad para responder a los cambios en el ambiente externo, mientras se mantiene un cierto nivel de control sobre las actividades en curso dentro del proyecto. Además, al final de cada sprint el Equipo Scrum muestra los entregables clasificados como terminados. Estos entregables potencialmente enviables pueden revisarse por el Product Owner y otros stakeholders.