Principios y Aspectos de Scrum (PDF)

1 – INTRODUCCIÓN 1.4.2 Principios de Scrum Los principios de Scrum son los lineamientos básicos para la aplicación del marco de trabajo de Scrum y deben implementarse de manera obligatoria en todos los proyectos Scrum. Los seis principios de...

1 – INTRODUCCIÓN 1.4.2 Principios de Scrum Los principios de Scrum son los lineamientos básicos para la aplicación del marco de trabajo de Scrum y deben implementarse de manera obligatoria en todos los proyectos Scrum. Los seis principios de Scrum que se presentan en el capítulo 2 son los siguientes: 1. Control del proceso empírico (Empirical Process Control) 2. Autoorganización (Self-organization) 3. Colaboración (Collaboration) 4. Priorización basada en valor (Value-based Prioritization) 5. Time-boxing 6. Desarrollo iterativo (Iterative Development) La figura 1-3 ilustra los seis principios de Scrum. Figura 1-3: Principios de Scrum 8 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN Los principios de Scrum se pueden aplicar a cualquier tipo de proyecto en cualquier organización y deben cumplirse a fin de garantizar la aplicación efectiva del marco de trabajo de Scrum. Los principios de Scrum no 1 están abiertos a la discusión ni pueden modificarse, y deben aplicarse tal como se especifica en la Guía del SBOK®. El mantener los principios intactos y usarlos apropiadamente infunde confianza en el marco de trabajo de Scrum respecto al cumplimiento de los objetivos del proyecto. Los aspectos y procesos de Scrum, sin embargo, pueden modificarse para cumplir con los requisitos del proyecto o la organización. 1. Control del proceso empírico: Este principio enfatiza la filosofía central de Scrum con base a las tres ideas principales de transparencia, inspección y adaptación. El control del proceso empírico ayuda a aprender por medio de la experimentación, especialmente cuando el problema no está bien definido o cuando no existen soluciones claras. 2. Autoorganización: Este principio se enfoca en los trabajadores de hoy en día, que entregan un valor considerablemente mayor cuando se autoorganizan, lo cual resulta en equipos que poseen un gran sentido de compromiso y responsabilidad; a su vez, esto produce un ambiente innovador y creativo que es más propicio para el crecimiento. 3. Colaboración: Este principio se centra en las tres dimensiones básicas relacionadas con el trabajo colaborativo: conocimiento, articulación y apropiación. También fomenta la gestión de proyectos como un proceso de creación de valor compartido con equipos que trabajan e interactúan entre sí, con el cliente y otros interesados del negocio para ofrecer el mayor valor posible. 4. Priorización basada en valor: Este principio resalta el enfoque de Scrum para ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su conclusión. 5. Time-boxing: Este principio describe cómo el tiempo se considera una restricción en Scrum, y cómo este se utiliza para ayudar a manejar eficazmente la planificación y ejecución del proyecto. Los elementos del time- boxing en Scrum incluyen sprints, Daily Standups, reuniones de planificación del sprint y reuniones de revisión del sprint. 6. Desarrollo iterativo: Este principio define el desarrollo iterativo y hace énfasis en la manera de gestionar mejor los cambios y crear productos que satisfagan las necesidades del cliente. También delinea las responsabilidades del Product Owner y las de la organización relacionadas con el desarrollo iterativo. © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 9  1 – INTRODUCCIÓN 1.4.3 Aspectos de Scrum Los aspectos de Scrum deben abordarse y gestionarse durante todo un proyecto Scrum. Los cinco aspectos de Scrum que se presentan en los capítulos del 3 al 7 son los siguientes: 1.4.3.1 Organización Entender los roles y responsabilidades definidos en un proyecto Scrum es muy importante a fin de asegurar la implementación exitosa de Scrum. Los roles de Scrum se dividen en dos amplias categorías: 1. Roles principales: Los roles principales (core roles) son aquellos que se requieren de manera obligatoria para crear el producto o servicio del proyecto. Las personas a quienes se les asignan los roles principales están plenamente comprometidas con el proyecto y son las responsables del éxito de cada iteración del mismo, así como del proyecto en su totalidad. Estos roles incluyen a los integrantes del equipo principal de Scrum: Product Owner: Es la persona responsable de lograr el máximo valor de negocio para el proyecto. Este rol también es responsable de la articulación de requisitos del cliente y de mantener la justificación del negocio para el proyecto. El Product Owner representa la voz del cliente. Scrum Master: Es un facilitador que asegura que el Equipo Scrum cuente con un ambiente propicio para completar el proyecto con éxito. El Scrum Master guía, facilita y enseña las prácticas de Scrum a todos los involucrados en el proyecto; elimina los impedimentos que pueda tener el equipo y se asegura de que se estén siguiendo los procesos de Scrum. Equipo Scrum: Es el grupo o equipo de personas responsables de entender los requisitos especificados por el Product Owner y de crear los entregables del proyecto. 2. Roles secundarios: Los roles secundarios (non-core roles) no son necesariamente obligatorios para el proyecto Scrum, y estos pueden incluir a miembros de los equipos que estén interesados en el proyecto. No tienen ningún rol formal en el equipo del proyecto, y pueden interactuar con el equipo, pero pueden no ser responsables del éxito del proyecto. Los roles secundarios deben tenerse en cuenta en cualquier proyecto de Scrum. Los roles secundarios son: Interesados del negocio: Es un término colectivo que incluye a clientes, usuarios y patrocinadores, que con frecuencia interactúan con el equipo principal de Scrum, e influyen en el proyecto a lo largo de su desarrollo. Lo más importante es que el proyecto produzca beneficios colaborativos para los interesados del negocio. Los interesados del negocio forman parte de un subconjunto de interesados en un proyecto de Scrum. Entre los interesados del proyecto están todas las personas y grupos afectos por el proyecto de Scrum, tanto dentro como fuera de la organización (por ejemplo: todos los roles principales y secundarios, los proveedores, grupos internos, expertos, entre otros). Scrum Guidance Body (SGB): Es un rol opcional, que generalmente consiste en un conjunto de documentos o un grupo de expertos que normalmente están involucrados en la definición de los objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros 10 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN parámetros claves de la organización. El SGB guía el trabajo llevado a cabo por el Product Owner, el Scrum Master y el Equipo Scrum. 1 Proveedores: Son personas u organizaciones externas, ofrecen productos o servicios que no están dentro de las competencias centrales de la organización del proyecto. La figura 1-4 ilustra la estructura organizacional Scrum. Figura 1-4: Organización en Scrum El aspecto de organización de Scrum aborda también los requisitos de estructura del equipo para implementar Scrum en grandes proyectos, programas y portafolios. 1.4.3.2 Justificación del negocio Es importante que una organización lleve a cabo una evaluación adecuada del negocio antes de iniciar cualquier proyecto. Esto ayuda a los tomadores de decisiones clave a entender la necesidad de cambio en la empresa o de un nuevo producto o servicio, la justificación para seguir adelante con un proyecto y su viabilidad. En Scrum, la justificación del negocio se basa en el concepto de entrega basada en el valor (Value-driven Delivery). Una de las características claves de cualquier proyecto es la incertidumbre sobre los resultados. Es imposible garantizar el éxito de un proyecto, independientemente de su tamaño o complejidad. Considerando esta inseguridad de alcanzar el éxito, Scrum busca iniciar la entrega de resultados lo antes posible en el proyecto. Esta entrega temprana de resultados, y por lo tanto de valor, proporciona una oportunidad para la reinversión y demuestra el valor del proyecto a los interesados del negocio. © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 11  1 – INTRODUCCIÓN La adaptabilidad de Scrum permite que los objetivos y procesos del proyecto cambien si cambia su justificación del negocio. Es importante señalar que, si bien el Product Owner es el responsable principal de la justificación del negocio, otros miembros del equipo también contribuyen considerablemente. 1.4.3.3 Calidad En Scrum, la calidad se define como la capacidad con la que cuenta el producto o los entregables para cumplir con los criterios de aceptación y de alcanzar el valor de negocio que el cliente espera. Para garantizar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un enfoque de mejora continua mediante el cual el equipo aprende de sus experiencias y de la participación de los interesados del negocio para mantener constantemente actualizado el backlog priorizado del producto con cualquier cambio en los requisitos. El backlog priorizado del producto nunca solo se finaliza hasta el cierre o conclusión del proyecto. Cualquier cambio en los requisitos debe reflejar los cambios en el entorno del negocio, ya sean internos o externos, y permitirle al equipo trabajar continuamente y adaptarse para lograr dichos requerimientos. Debido a que Scrum requiere que el trabajo se realice en incrementos durante los sprints, esto hace que los errores o defectos se noten con más facilidad mediante pruebas de calidad repetitivas y no simplemente cuando el producto final o servicio esté casi terminado. Por otra parte, las tareas relacionadas a la calidad (por ejemplo, desarrollo, pruebas y documentación) se completan como parte del mismo sprint por el mismo equipo. Esto asegura que la calidad sea inherente a cualquier entregable que se crea como parte de un sprint. A tales entregables de proyectos Scrum, que son potencialmente enviables, se les denomina “terminado”. Por lo tanto, la mejora continua con pruebas repetitivas optimiza la probabilidad de alcanzar los niveles esperados de calidad en un proyecto Scrum. Las discusiones constantes entre el equipo principal de Scrum y los interesados del negocio (incluyendo los clientes y los usuarios), junto con incrementos reales del producto que se entregan al final de cada sprint, aseguran que la brecha entre las expectativas de los clientes del proyecto y los verdaderos entregables se reduzca constantemente. El Scrum Guidance Body también puede proporcionar directrices sobre la calidad que pueden ser de interés para todos los proyectos Scrum en la organización. 1.4.3.4 Cambio Cada proyecto, independientemente del método o marco de trabajo que se utilice, está expuesto a cambios. Es importante que los miembros del equipo del proyecto entiendan que los procesos de desarrollo de Scrum están diseñados para aceptar el cambio. Las organizaciones deben tratar de maximizar los beneficios que se deriven de los cambios y minimizar cualquier impacto negativo a través de procesos de gestión de cambio diligentes, según los principios de Scrum. Un principio fundamental de Scrum es su reconocimiento de que los interesados del negocio (clientes, usuarios y patrocinadores) cambian de opinión acerca de lo que quieren y lo que necesitan durante un proyecto (a esto se le conoce en ocasiones como requisitos volátiles); y que es muy difícil, si no imposible, que los interesados del negocio definan todos los requisitos al inicio del proyecto. Los proyectos Scrum aceptan los cambios mediante el uso de sprints breves e iterativos que incorporan la retroalimentación del cliente en cada entregable del sprint. 12 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum, que vea los entregables a medida que estén listos y que cambie los requisitos si es necesario antes del siguiente sprint. 1 Asimismo, los equipos de gestión de programa o portafolio pueden responder a las solicitudes de cambio pertenecientes a los proyectos Scrum aplicables a su nivel. 1.4.3.5 Riesgo El riesgo se define como un evento incierto o serie de eventos que pueden afectar los objetivos de un proyecto y pueden contribuir a su éxito o fracaso. A los riegos que pueden tener un impacto positivo en el proyecto se les conoce como oportunidades, mientras que las amenazas son riesgos que pudieran afectar negativamente al proyecto. La gestión de riesgos debe hacerse de forma preventiva, y es un proceso iterativo que debe comenzar al inicio del proyecto y continuar a lo largo del ciclo de vida del mismo. El proceso de gestión de riesgos debe seguir algunos pasos estandarizados para asegurar que estos se identifiquen y evalúen, y que se determine un curso adecuado de acción y se proceda en consecuencia. Los riesgos deben ser identificados, evaluados y atendidos con base a dos factores: la probabilidad de ocurrencia de cada riesgo y el posible impacto en el caso de tal ocurrencia. Los riesgos con una alta probabilidad y valor de impacto (que se calcula multiplicando ambos factores) deben ser atendidos primero que aquellos con un valor relativamente bajo. En general, una vez que se detecta un riesgo, es importante entender el mismo en relación con las causas probables y los posibles efectos. © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 13  1 – INTRODUCCIÓN 1.4.4 Procesos de Scrum Los procesos de Scrum abordan las actividades específicas y el flujo de un proyecto de Scrum. Los procesos de Scrum generalmente no son secuenciales, sino iterativos y pudieran sobreponerse unos con otros. En total hay diecinueve procesos fundamentales de Scrum que aplican a todos los proyectos. Estos procesos se agrupan en cinco fases y se presentan en los capítulos del 8 al 12 de la Guía del SBOK® tal como se muestra en la tabla 1-1. Capítulo Fase Procesos fundamentales de Scrum 1. Crear la visión del proyecto 2. Identificar al Scrum Master y a los interesados del negocio 8 Inicio 3. Formar Equipos Scrum 4. Desarrollar épicas 5. Crear el backlog priorizado del producto 6. Realizar la planificación de la liberación 7. Crear historias de usuario 8. Estimar historias de usuario 9. Comprometer historias de usuario 9 Planificación y estimación 10. Identificar tareas 11. Estimar tareas 12. Actualizar el backlog del sprint 13. Crear entregables 10 Implementación 14. Realizar el Daily Standup 15. Refinar el backlog priorizado del producto 16. Demostrar y validar el sprint 11 Revisión y retrospectiva 17. Retrospectiva del sprint 18. Enviar entregables 12 Liberación 19. Retrospectiva de la liberación Tabla 1-1: Resumen de los procesos fundamentales de Scrum Estas fases describen a detalle cada proceso, incluyendo sus entradas, herramientas y salidas asociadas. En cada proceso, algunas entradas, herramientas y salidas son obligatorias (las que tienen un asterisco [*]), mientras que otras son opcionales. La inclusión de las entradas, herramientas o salidas opcionales dependerá del proyecto en particular, de la organización o la industria. Las entradas, herramientas y salidas señaladas con un asterisco son consideradas obligatorias o importantes para la implementación exitosa de Scrum en cualquier organización. Para proyectos Scrum a gran escala que requieren de una coordinación entre múltiples equipos, existen entradas, herramientas y salidas adicionales de Scrum que se definen en el capítulo 13: Escalar Scrum en grandes proyectos. 14 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN Existen también procesos específicos definidos cuando se implementa Scrum al nivel de negocio, lo cual se aborda en el capítulo 14: Escalar Scrum para la empresa. 1 1.4.4.1 Fase de inicio Los procesos relevantes en la fase de inicio son los siguientes: 1. Crear la visión del proyecto: En este proceso se revisa el caso de negocio del proyecto (Project Business Case) a fin de crear una Declaración de la visión del proyecto, que servirá de inspiración y proporcionará un enfoque para todo el proyecto. En este proceso se identifica al Product Owner. 2. Identificar al Scrum Master y a los interesados del negocio: En este proceso se identifica al Scrum Master y a los interesados del negocio utilizando criterios de selección específicos. 3. Formar Equipos Scrum: En este proceso se identifican a los miembros del Equipo Scrum. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero con frecuencia lo hace en colaboración con el Scrum Master. 4. Desarrollar épicas: En este proceso, la declaración de visión del proyecto sirve como base para el desarrollo de épicas. Se pueden llevar a cabo reuniones de grupos de usuarios para hablar sobre las épicas adecuadas. 5. Crear el backlog priorizado del producto: En este proceso se refinan y se crean las épicas, y después se priorizan para crear un backlog priorizado del producto en el proyecto. A este punto también se establecen los criterios de terminado. 6. Realizar la planificación de la liberación: En este proceso el equipo principal de Scrum revisa las historias de usuario en el backlog priorizado del producto para desarrollar un cronograma de planificación de la liberación, que es esencialmente un programa de implementación por fases que se puede compartir con los interesados del negocio del proyecto. En este proceso también se determina la duración del sprint. 1.4.4.2 Fase de planificación y estimación Los procesos relevantes en la fase de estimación y liberación son los siguientes: 7. Crear historias de usuario: En este proceso se crean las historias de usuario y los criterios de aceptación de las historias de usuario. Las historias de usuario generalmente las escribe el Product Owner y están diseñadas para asegurar que los requisitos del cliente estén claramente representados y puedan ser plenamente comprendidos por todos los interesados del negocio. Se pueden llevar a cabo ejercicios de redacción de historias de usuario, lo cual incluyan a los miembros del Equipo Scrum, resultando en la creación de dichas historias. Estas se incorporan al backlog priorizado del producto. 8. Estimar historias de usuario: En este proceso, el Product Owner explica las historias de usuario para que el Scrum Master y el Equipo Scrum puedan estimar el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario. 9. Comprometer historias de usuario: En este proceso, el Equipo Scrum se compromete a entregar al Product Owner las historias de usuario aprobadas para un sprint. El resultado de este proceso serían las historias de usuario comprometidas. © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 15  1 – INTRODUCCIÓN 10. Identificar tareas: En este proceso, las historias de usuario comprometidas se desglosan en tareas específicas y se compilan en una lista de tareas. 11. Estimar tareas: En este proceso, el equipo principal de Scrum estima el esfuerzo necesario para cumplir con cada tarea en la lista de tareas. El resultado de este proceso es una lista de tareas con esfuerzo estimado (Effort Estimated Task List). 12. Actualizar el backlog del sprint: En este proceso, el equipo principal de Scrum elabora un backlog del sprint que contiene todas las tareas a ser completadas en un sprint como parte de la reunión de planificación del sprint. 1.4.4.3 Fase de implementación Los procesos relevantes en la fase de implementación son los siguientes: 13. Crear entregables: En este proceso, el Equipo Scrum trabaja en las tareas en el backlog del sprint para crear los entregables del sprint. Generalmente se utiliza un Scrumboard para dar seguimiento a las actividades que se llevan a cabo. Las asuntos o problemas que enfrenta el equipo Scrum pudieran actualizarse en una lista de impedimentos. 14. Realizar el Daily Standup: En este proceso, se lleva a cabo diariamente una reunión altamente focalizada con un time-box, conocida como Daily Standup. Es aquí donde los miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los impedimentos que pudieran enfrentar. 15. Refinar el backlog priorizado del producto: En este proceso, el backlog priorizado del producto se actualiza y se refina continuamente. Se puede considerar realizar una reunión de revisión del backlog priorizado del producto, en la que se analiza cualquier cambio o actualización al backlog y se incorpora a dicho backlog según sea necesario. 1.4.4.4 Fase de revisión y retrospectiva Los procesos relevantes en la fase de revisión y retrospectiva son los siguientes: 16. Demostrar y validar el sprint: En este proceso, el Equipo Scrum muestra los entregables del sprint al Product Owner y a los interesados del negocio relevantes en una reunión de revisión del sprint. El objetivo de esta reunión es asegurar que el Product Owner apruebe y acepte las historias de usuario del sprint. 17. Retrospectiva del sprint: En este proceso, el Scrum Master y el Equipo Scrum se reúnen para analizar las lecciones aprendidas durante todo el Sprint. Esta información se documenta en forma de lecciones aprendidas que pueden aplicarse a futuros sprints. Frecuentemente, como resultado de esta discusión, puede haber mejoras aceptadas o recomendaciones actualizadas por parte del Scrum Guidance Body. 1.4.4.5 Fase de liberación Los procesos relevantes en la fase de liberación son los siguientes: 16 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN 18. Enviar entregables: En este proceso, los entregables aceptados se entregan o se envían a los interesados del negocio relevantes. La conclusión satisfactoria del sprint se documenta en un acuerdo 1 de entregables funcionales. 19. Retrospectiva de la liberación: En este proceso, mismo que concluye el proyecto, los interesados del negocio y miembros del equipo principal de Scrum se reúnen para reflexionar sobre el proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de mejoras accionables acordadas, que se implementarán en futuros proyectos. 1.4.4.6 Reuniones o ceremonias de Scrum Las reuniones de Scrum tienen una función importante en la implementación eficaz del marco de trabajo de Scrum y son el medio principal para la implementación de los principios de Scrum. Las reuniones importantes de Scrum y los procesos respectivos en las que se llevan a cabo estas reuniones se describen en la tabla 1-2: Reunión de Scrum Proceso de Scrum Reunión de visión del proyecto Crear la visión del proyecto Desarrollar épicas Reuniones con grupos de usuarios Crear historias de usuario Desarrollar épicas Reuniones de grupos de enfoque Crear historias de usuario Sesiones o reuniones de planificación de la Realizar la planificación de la liberación liberación Reuniones de revisión del backlog priorizado del Estimar historias de usuario producto Refinar el backlog priorizado del producto Estimar historias de usuario Comprometer historias de usuario Reuniones de planificación del sprint Identificar tareas Estimar tareas Actualizar el backlog del sprint Daily Standup Realizar el Daily Standup Reunión de revisión del sprint Demostrar y validar el sprint Reunión de retrospectiva del sprint Retrospectiva del sprint Reunión de retrospective de la liberación Retrospectiva de la liberación Tabla 1-2: Reuniones y procesos de Scrum © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 17  1 – INTRODUCCIÓN 1.4.5 Scrum para grandes proyectos Al trabajar en grandes proyectos donde se requiere el trabajo de múltiples (cuatro o más) equipos de Scrum con varios Product Owner y múltiples Scrum Masters, los capítulos del 8 al 12 siguen siendo válidos, aunque tal vez sean necesarias consideraciones adicionales y actualizaciones a las entradas, herramientas y salidas. Esto puede incluir necesidades adicionales de coordinación y sincronización. El impacto de los procesos fundamentales de Scrum al escalar Scrum en grandes proyectos se describe en el capítulo 13. La definición de lo que constituye un proyecto grande generalmente depende de la organización o de la complejidad de los proyectos emprendidos. Un criterio clave para saber si un proyecto se considera pequeño en vez de grande es si requiere de múltiples Scrum Masters o múltiples Product Owners. Si el proyecto requiere solo un Scrum Master y un Product Owner, generalmente estos pueden manejar cualquier actividad adicional de comunicación y sincronización que requiera el proyecto. 1.4.6 Scrum para la empresa Al trabajar con Scrum al nivel de una empresa (un programa o un portafolio), tal vez sea necesaria la participación de cientos de equipos con miles de personas a cargo de múltiples proyectos dentro de los programas o portafolios de la compañía. El uso de Scrum a nivel de un programa o portafolio tendrá ciertos efectos en los proyectos subyacentes. En general, los proyectos de Scrum se pueden ejecutar con los procesos fundamentales de Scrum descritos en los capítulos del 8 al 12 si se trata de proyectos pequeños, pero se deben tomar en cuenta las consideraciones plasmadas en el capítulo 13 con relación a los grandes proyectos (que cuentan con múltiples Product Owners o Scrum Masters). Algunos de los retos que surgen a nivel del programa o del portafolio son similares a las que se presentan en los grandes proyectos de Scrum. Los principales retos en los grandes proyectos son la sincronización entre los equipos y la colaboración general. Esto también representa un reto al aplicar Scrum al nivel del programa o del portafolio. Sin embargo, los más grandes retos en un programa o en un portafolio pueden presentarse en el aspecto de negocio, dado que pudieran contraponerse las prioridades del negocio en los distintos proyectos y estar en conflicto con los objetivos generales del programa o del portafolio. Estas metas y prioridades deben estar en armonía. Al implementar Scrum al nivel de la empresa, no solo se deben aplicar entradas, herramientas y salidas tal como en un proyecto grande, también hay procesos adicionales específicos que son necesarios para atender la priorización adicional, la armonización y las actividades de coordinación. Estas consideraciones adicionales ese abordan en el capítulo 14. 18 © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía SBOK®)  1 – INTRODUCCIÓN 1.5 Scrum vs. Gestión tradicional de proyectos 1 La tabla 1-3 resume muchas de las diferencias entre los modelos tradicionales de gestión de proyectos. Gestión tradicional Scrum de proyectos El énfasis está en Las personas Los procesos Documentación Solo mínima; según se requiera Integral Estilo de procesos Iterativo Lineal Planificación por adelantado Baja Alta Según el valor del negocio y Priorización de requerimientos Fijo en el plan de proyecto regularmente actualizada Garantía de calidad Centrada en el cliente Centrada en el proceso Organización Autoorganizada Gestionada Estilo de gestión Descentralizado Centralizado Actualizaciones al backlog Sistema formal de gestión del Cambio priorizado del producto cambio Liderazgo Liderazgo colaborativo y servicial Mando y control Medición del rendimiento El valor del negocio Cumplimiento del plan Al comienzo y a lo largo del Retorno de la inversión Al final del proyecto proyecto Varía dependiendo del ciclo de Participación del cliente Alta durante todo el proyecto vida del proyecto Tabla 1-3: Scrum vs. Gestión tradicional de proyectos © 2022 SCRUMstudy™. Guía de los fundamentos de Scrum (Guía del SBOK®) 19