Scrum está de moda y el resto de metodologías ha de seguir su ejemplo. No obstante, está claro que es un estilo de trabajo que no todo el mundo puede llevar a cabo fácilmente. Así que, ¿Qué hacer si tienes dudas sobre cómo aplicar el método en tu empresa? Aquí te contamos todos los secretos.
¿Qué es Scrum?
Es un marco de trabajo que dirige y da las claves para un equipo autoorganizado con herramientas que ayudan a aumentar la probabilidad de éxito de un proyecto complejo.
¿Cómo?
A través de una colaboración productiva y creativa del equipo mediante herramientas y reuniones.
¿Por qué?
Para entregar productos/servicios de máximo valor.
Es uno de los métodos ágiles más utilizados en todo el mundo (el Manifiesto Ágil es una constitución de principios y valores). Comenzaron a principios de los años 90 hasta hoy, donde un alto porcentaje de equipos de desarrollo de software lo utilizan.
Scrum no es una técnica, un proceso o un método definitivo. Más bien, es un marco dentro del cual se pueden utilizar varios procesos y técnicas. Scrum implementa la técnica lógica de la experimentación, que implica una forma de pensar en la información por observación.
Como dijeron los padres de Scrum, Ken Schwaber y Jeff Sutherland
“Scrum es ligero, sencillo de entender y difícil de dominar”
Esto significa que Scrum es simple pero no es fácil.
Si las empresas utilizan Scrum, aumentarán su productividad multiplicada por 10.
Consejo: Scrum es fácil de entender difícil de dominar.
La transparencia, la inspección y la adaptación son criterios esenciales y básicos, apoyando un proceso más eficaz.
Durante más de 20 años, la evolución de Scrum pasó por muchos desafíos y muchas empresas no lograron implementar Scrum debido a su propia resistencia.
¿Qué es el Manifiesto Ágil?
En febrero de 2001, en Estados Unidos, se reunieron 17 pensadores independientes con una base común y una experiencia iniciada por Bob Martin, de la que surgió el Manifiesto de “Desarrollo de Software” Ágil. Representantes y conocedores del desarrollo de software discutieron la necesidad de un cambio, de buscar una alternativa a los procesos de desarrollo de software pesados e impulsados por la documentación.
Se denominaron a sí mismos “La Alianza Ágil”, un grupo de personas que mantenían un conjunto de valores compatibles, basados en la confianza y el respeto mutuo y que promovían modelos organizativos basados en las personas, la colaboración y la construcción de los tipos de comunidades organizativas en las que querríamos trabajar. Dando prioridad a la entrega de buenos productos a los clientes, operando en un entorno que hace más que hablar, sino que realmente “actúa” como si las personas fueran lo más importante.
En aquel momento, e incluso hoy en día, la vieja mentalidad de proceso “fijo” estándar predominaba en la industria del desarrollo de software, lo que está llevando a enormes fracasos con un coste de millones de dólares.
Por eso, para tener éxito en la nueva economía, para entrar en la era del comercio electrónico, el e-business y la web, las empresas tienen que deshacerse de su propia resistencia a los cambios y a la nueva mentalidad.
Lamentablemente, como en todas partes, los cambios siempre encuentran obstáculos, los cambios como el Agile que trata de hacer lo mejor para el “cliente” y entregar algo con valor, oportuno y tangible, se enfrenta a la oposición dentro de la industria.
El movimiento Ágil no es anti-metodología, sino que intenta restablecer un equilibrio. Este movimiento no rechaza el modelado, la documentación y la planificación, sino que los adopta con equilibrio y adaptación a la realidad.
Su objetivo es ayudar a los demás a pensar en el desarrollo de software, las metodologías y las organizaciones, de nuevas formas más rápidas y fáciles, formas “ágiles”.
¿Cuáles son los 4 valores y los 12 principios del Manifiesto Ágil?
El Manifiesto Ágil establece 4 valores y 12 principios que guían el desarrollo de software ágil.
|
AGILE MANIFESTO
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
● Las personas y las interacciones por encima de los procesos y las herramientas ● Software de trabajo sobre documentación completa ● Colaboración del cliente sobre la negociación del contrato ● Responder a los cambios en lugar de seguir un plan Es decir, aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda. |
1. Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso. 2.Acepte los cambios en los requisitos, incluso en los últimos momentos del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.3. Entregar el software de trabajo con frecuencia, desde un par de semanas hasta un par de meses, con preferencia por el plazo más corto.4.Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.5.Construya proyectos en torno a personas motivadas. Dales el entorno y el apoyo que necesitan, y confía en que harán el trabajo.6.El método más eficiente y eficaz para transmitir información a un equipo de desarrollo y dentro de él es la conversación cara a cara.7.El software de trabajo es la principal medida de progreso.8.Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante indefinidamente.9.La atención continua a la excelencia técnica y al buen diseño aumenta la agilidad.
10.La simplicidad -el arte de maximizar la cantidad de trabajo no realizado- es esencial.
11.Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
12.A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, y luego afina y ajusta su comportamiento en consecuencia.
https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ |
¿Cuáles son los orígenes de Scrum?
Hacia la mitad de los años 80, Hirotaka e Ikujiro Nonaka definieron una estrategia de desarrollo de productos flexible en la que el equipo trabaja como una unidad con un mismo objetivo. Era un método innovador para desarrollar productos llamado visión holística o rugby.
No querían seguir una carrera de relevos, sino que se acercaba más al juego de rugby en el que los jugadores se pasaban el balón hacia delante y hacia atrás cuando era necesario mientras avanzaban hacia el lado del enemigo.
El concepto de scrum en el rugby es aplicado por los autores Ken Schwaber y Jeff Sutherland para el desarrollo de software durante una presentación en la conferencia internacional sobre Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones, o OOPSLA en 1995 en Austin, Texas.
Desde entonces, muchos profesionales, expertos y autores de Scrum están mejorando la conceptualización y el marco de Scrum. Al principio, no había una guía oficial a seguir y cada uno aplicaba e interpretaba scrum libremente. Así que en 2011, Ken Schwaber y Jeff Sutherland decidieron publicar la Guía oficial de Scrum, resolviendo el problema.
Desde 2011, la Guía de Scrum tuvo dos grandes cambios, en 2013 y 2016. En primer lugar, por ejemplo, se eliminó el gráfico de burndown, se cambió el nombre de la reunión de preparación por el de refinamiento, se añadió la funcionalidad de programación a los stand-ups diarios como un factor de programación, no sólo de sincronización. En el segundo cambio, se añadieron los valores de Scrums ( realmente importante porque da el marco de la organización para que funcione) y algunos cambios menores.
Parece que hay muchos profesionales que todavía se confunden porque creen que es un acrónimo debido a que el artículo original se escribió completamente en mayúsculas para dar más importancia al título.
Una gran confirmación de la guía es que Scrum no es un acrónimo (S.C.R.U.M.) sino un nombre propio, por lo que se escribe con mayúscula, Scrum.
Consejos. Para entender bien los orígenes de Scrum, es interesante leer el artículo original “The New Product Development Game” que describe las reglas del actual marco de trabajo de Scrum.
En los últimos años, Scrum está creciendo en popularidad, y hoy en día es el método favorito para desarrollar proyectos en todo el mundo.
¿Qué es la Guía oficial de Scrum?
Es el documento donde se puede encontrar la definición de Scrum, el propósito, los usos, la teoría de Scrum y los valores de Scrum. Los diferentes roles de Scrum: Product Owner, Scrum Master y Equipo de Desarrollo. La explicación de los eventos ( El Sprint, la Planificación del Sprint, el Scrum Diario, la Revisión del Sprint, la retrospectiva del Sprint) y los artefactos (Product Backlog, Sprint Backlog, y el incremento. La guía explica las reglas que los unen para aumentar la probabilidad de un proyecto exitoso.
Este año, 2020, todavía bajo la última versión es de 2017, donde aclararon que Scrum es útil incluso fuera del software.
Consejo: El marco en sí mismo no aporta mucho. El objetivo principal es la AGILIDAD. Es un framework listo para ser utilizado en proyectos complejos.
Te puede interesar nuestro artículo: Scrum VS Kanban
Los valores del Scrum
Todos los involucrados en el proyecto deben seguir y aplicar los valores de Scrum, porque Scrum es un marco de trabajo, la base de ese marco, los valores: coraje, enfoque, compromiso, respeto y apertura.
El objetivo principal de los 5 valores es permitir que los equipos Scrum sean ágiles.
Compromiso
lleva al equipo Scrum a trabajar juntos como una unidad. Permitiendo que la confianza entre los miembros sea la base de los pilares de todo lo que están construyendo. Cuando los miembros no están seguros, preguntan, y los equipos Scrum se comprometen con lo que creen que pueden lograr, por lo que tienen cuidado de no comprometerse demasiado.
El increíble Scrum Master valora el compromiso: refuerza el compromiso del equipo en la reunión de planificación del sprint, protege al equipo de los cambios a mitad del sprint y desvía la presión excesiva de los Product Owners.
Valor
lleva al equipo a sentirse lo suficientemente seguro y confiado para decir que no, pedir ayuda y probar cosas nuevas. El equipo tiene que ser lo suficientemente valiente como para expresarse y hacer lo mejor cuando algo impide el éxito.
El asombroso valor del Scrum Master es el coraje: El Scrum Master elimina implacablemente los impedimentos que frenan el trabajo del equipo. El Scrum Master impulsa el coraje del equipo creando seguridad cuando se tienen conversaciones difíciles entre ellos, con el propietario del producto o con las partes interesadas.
Enfoque
significa que el equipo termina todo lo que empieza. Los miembros son imparables en su camino hacia el éxito.
El increíble valor del Scrum Master es el enfoque: El Scrum master motiva el enfoque del equipo a través de la implementación de su propia definición of done, motivándolos a participar y ver la utilidad en cada reunión diaria, y asegurando que cada miembro sólo presente un trabajo terminado en la reunión de revisión.
Apertura
significa que los miembros del Equipo Scrum siempre piden humildemente ayuda cuando realmente la necesitan. Ellos están constantemente buscando nuevas ideas y cualquier oportunidad de aprender.
El increíble Scrum Master valora la apertura: El Scrum Master fomenta un ambiente abierto y franco en las reuniones de retrospectiva de los sprints para que el equipo pueda crecer y desarrollarse de sprint en sprint. El Scrum Master recuerda al equipo que cuanto antes se detecten o compartan los defectos del producto, es menos costoso y mucho más eficaz que conocerlo más tarde durante el proyecto o peor, una vez entregado al cliente. El Scrum Master se asegura de que la retroalimentación escuchada por el equipo de las partes interesadas sea constructiva, fomentando la apertura en las Revisiones del Sprint. La apertura lleva a motivar la transparencia para que todos estén siempre al tanto de cómo va el Sprint.
Respeta
Está presente a todas horas. Los miembros del equipo Scrum muestran respeto a todo el mundo, al Scrum Master, a las partes interesadas, al propietario del producto y, por supuesto, a los demás. Todos son conscientes de que la clave de su fuerza reside en la colaboración, cada miembro tiene su propia contribución a la consecución del proyecto. Cualquier éxito se celebra y se felicita, cualquier fracaso se comparte, se respetan todas las ideas, se aceptan los errores de los que hay que aprender y se aprende profundamente, y se tiene paciencia con los días malos ocasionales.
El increíble valor del Scrum Master es el respeto: El Scrum Master desarrolla y promueve el respeto en los compañeros. Recuerda la necesidad de reforzar la colaboración en los momentos necesarios y facilita la conversación hacia nuevas ideas. Les ayuda a escucharse activamente durante los scrums diarios. Invita a todos a compartir sus retos, problemas y logros.
Estos valores juegan un papel muy importante en el éxito de los equipos Scrum porque les da pautas sobre cómo realizar sus tareas, planificar, tomar decisiones, comportarse y trabajar. Cada miembro de un equipo Scrum entiende por qué es necesario aplicar estos valores en cada una de las decisiones, procesos y sprints que llevan a cabo.
¿Cúales son los seis principios de Scrum?
- Control empírico del proceso: la principal forma de aplicar el control es siguiendo las 3 ideas principales: transparencia, inspección y adaptación.
- Autoorganización: cuando los trabajadores tienen un gran sentido del compromiso y de la responsabilidad, se produce fácilmente un hábito de autoorganización, lo que conducirá a una mayor entrega de valor y a un entorno innovador y creativo adecuado para crecer en todos los sentidos.
- Colaboración: los tres elementos básicos relacionados con el trabajo colaborativo son la conciencia, la articulación y la apropiación. Se centra en la gestión de proyectos como un conjunto de equipos creadores de valor que interactúan juntos para entregar un valor aún mayor.
- Priorización basada en el valor: Scrum se centra en la entrega de un valor de negocio máximo y continuo. Y se aplica a lo largo de todo el proceso.
- El encajonamiento del tiempo: el tiempo es un factor que se utiliza para ayudar a gestionar eficazmente la planificación, ejecución y revisión del proyecto. Los elementos de encajonamiento del tiempo en Scrum son los Sprints, los Standups diarios, las reuniones de Planificación de Sprint y las reuniones de Revisión de Sprint.
- Desarrollo Iterativo: el énfasis se pone en cómo gestionar mejor los cambios y crear valor para el cliente a través del producto entregado.
¿Cuáles son las funciones del equipo Scrum?
El Scrum clasifica los roles en dos grupos: los roles centrales y los no centrales.
Los roles centrales del Equipo Scrum son:
- Product Owner
- The Development Team
- Scrum Master.
Nota.
La posición tradicional de director de proyecto no existe en Scrum, ya que sus funciones se han distribuido entre los tres roles centrales. Si se añade este papel, es debido a la falta de cómo funciona Scrum, y que la aplicación tiende a conducir a la confusión en la autoridad, los conflictos de responsabilidad, y, en consecuencia, los resultados menos eficaces y valiosos.
- Los roles centrales no son Stakeholder(s), Cuerpo Guía de Scrum y Vendedores.
La diferencia entre los papeles centrales y los no centrales es que los centrales son obligatorios para crear un producto o servicio del proyecto.
Nota:
La posición de los stakeholders (gerentes, clientes y usuarios) cambia una vez que la implementación de Scrum está en proceso:
- Accesibilidad abierta, voluntaria y activa a sus conocimientos y experiencia.
- Colaboración en la eliminación de los impedimentos identificados por otros.
- Familiarización, aplicación y respeto de las reglas y el espíritu de Scrum.
Deben convertirse en un Gurú/Sirviente del equipo, esto implica la tutoría, el coaching, la resolución de problemas, guiar el desarrollo de las habilidades de los miembros, dar retroalimentación constructiva y eliminar o ayudar a eliminar los obstáculos. Un ejemplo de cambio es aplicar las preguntas socráticas, no dan la respuesta sino que les ayudan a encontrar las soluciones al problema por sí mismos.
¿Conoces el ScrumMaster en Scrum?
Es responsable de las necesidades del equipo. Orienta, proporciona, enseña la práctica de scrum a todos los que están involucrados. Elimina cualquier impedimento, anticipa los riesgos y facilita los cambios que se producen y se asegura de que se apliquen en el momento adecuado. Se asegura de que el Equipo Scrum trabaje en un entorno ideal para el éxito del proyecto.
El Scrum Master busca, gestiona, asegura y facilita que todos sigan el proceso de Scrum junto con la ejecución y la mecánica de Scrum. Debe asegurar la aplicación constante de los principios y valores de Scrum para que el objetivo del proyecto pueda ser alcanzado de la manera más efectiva, fomentando la agilidad.
Las principales funciones del Scrum Master:
Gestionar el proceso de Scrum:
Busca el flujo correcto del proceso scrum, facilita el coaching, el mentoring, facilita cualquier formación que sea necesaria y se asegura de que haya una entrega constante de valor.
Ayuda a eliminar cualquier impedimento:
Localiza y elimina constantemente cualquier obstáculo que surja en la organización y que afecte al camino del éxito del proyecto y dentro de la organización.
Nota: Cuando se habla de impedimentos, no se refiere al nivel del equipo sino al nivel de la organización. El Scum Master no es un reparador mágico de hardware.
El Scrum Master es responsable de buscar todos los medios posibles para facilitar la implementación del Scrum y disminuir la resistencia de la organización a su plena implementación.
Por lo tanto, el Scrum Master no participa no crea directamente el producto, pero tiene que centrarse en lo que afecta a la organización en general. Por ejemplo, es el equipo de desarrollo el que tiene que actualizar el tablero de Scrum y es el Product Owner el que tiene que actualizar la justificación del negocio.
La eliminación de impedimentos implica la influencia de la dirección general para lograr cambios internos exitosos en aras de la agilidad de la organización.
¿Qué es el ProductOwner en Scrum?
Responsable de maximizar y gestionar el flujo de valor del producto, a través del Prioritized Product backlog. Esta tarea no es fácil de realizar, es bastante complicada. Se encarga de los informes, los presupuestos y la relación con las partes interesadas. Sólo hay un Product Owner para cada producto. Transmite las necesidades del cliente y mantiene la justificación del producto.
Gestiona las prioridades y los presupuestos, contrata al equipo de desarrollo y explica a las partes interesadas el valor que produce el producto en el que están invirtiendo. De ahí la importancia de los incrementos al final de cada sprint. Porque si se entrega el valor esperado, aún más, exige una mayor reinversión.
Representar al negocio. Tienes el poder de decisión y la autoridad sobre el producto, conoces el negocio, el cliente y el mercado. Si no eres capaz de tomar decisiones por ti mismo, no eres el Propietario del producto correcto. Debe tomar decisiones sin consultar a otra persona, maximizando así la inversión realizada en el desarrollo del producto y reduciendo los riesgos inherentes. Representar los deseos y necesidades del cliente.
Son persuasivos, ya que pueden trabajar tanto con el equipo de desarrollo como con las partes interesadas. Al mismo tiempo, están disponibles, son accesibles tanto para el equipo como para las partes interesadas.
¿Qué es el Equipo de Desarrollo en Scrum?
Personas que se encargan de entender lo que el propietario del producto comunica y da resultados constantemente al proyecto.
Grupo formado por entre 3 y 9 profesionales sin incluir al Product Owner o al Scrum Master. El equipo desarrolla el producto, trabaja en un entorno en el que predomina la autoorganización y decide cuál es la mejor manera de conseguir los entregables o de alcanzar cualquier objetivo. Preferiblemente, es mejor no intervenir en su dinámica, ya que ellos deciden cómo terminar la tarea a realizar. El equipo está capacitado para gestionar su propio trabajo.
Su autoorganización conduce a la creación de un entorno creativo e innovador. Ayuda a los miembros a ser responsables y comprometidos. Los equipos Scrum se auto-organizan para elegir la mejor manera de realizar el trabajo, en lugar de ser dirigidos por otros fuera del equipo.
No se reconocen subgrupos o títulos, cada miembro pertenece al equipo en su conjunto.
Los equipos Scrum son interfuncionales. Los equipos interfuncionales tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no forman parte del equipo.
El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.
¿Qué es el ciclo de vida de Scrum o el proceso de Scrum?
1. Declaración de la visión del proyecto. Una reunión de las partes interesadas crea la visión del proyecto.
2. Creación de los usuarios de Epics and Stories.
3. El Product Owner desarrolla un Prioritized Product Backlog ( una lista de historias de usuario )
4. Cada Sprint comienza con una reunión de planificación del sprint que el propietario del producto y el equipo de desarrollo llevan a cabo, y donde se discuten las historias de usuario de alta prioridad que necesitan ser incluidas en el sprint.
5. A medida que avanza el Sprint, el equipo de desarrollo realiza el trabajo necesario para entregar los elementos del backlog del producto seleccionados, los entregables. Un sprint generalmente organiza lo que hay que hacer de 1 a 6 semanas.
6. Durante cada sprint, informando cada día, el equipo de desarrollo coordina su trabajo en un Daily Standup. Alrededor de 15 minutos de reunión diaria donde los miembros del equipo discuten el progreso diario en breve y específicamente sobre el progreso y los obstáculos.
7. Hacia el final del Sprint, el equipo de desarrollo entrega los Elementos del Backlog del Producto seleccionados durante la Planificación del Sprint. El equipo de desarrollo celebra una Reunión de Revisión del Sprint para mostrar al cliente el incremento y obtener feedback.
8. El ciclo de un Sprint termina cuando el equipo de desarrollo y el propietario del producto también reflexionan sobre cómo se ha desarrollado el Sprint hasta el momento y adaptan sus procesos en consecuencia durante una Reunión de Retrospectiva del Sprint.
El equipo repite los pasos explicados anteriormente hasta que se haya alcanzado el resultado deseado del producto.
¿Cuál es un ejemplo de proceso Scrum?
Necesidades del cliente:
La empresa Personality Match Team quiere un test de personalidad para conocer la mejor forma de trabajo en equipo y permite a las empresas encontrar el mejor perfil. La plataforma permite hacer el test y elegir si algún perfil es bueno para ellos.
Iniciar
La visión del proyecto la deciden los Stakeholders, los inversores, los usuarios y la empresa. El Product Owner representa el negocio, se encarga de la Justificación del negocio y de encontrar el valor y los beneficios de la inversión. El Scrum Master ayuda al Product Owner en lo que sea necesario. Eligen los miembros del equipo de desarrollo que se necesita para crear la plataforma. Se desarrollan las epopeyas.
Una epopeya es una historia de usuario grande que no puede ser entregada como se define dentro de una sola iteración o es lo suficientemente grande como para que pueda ser dividida en historias de usuario más pequeñas
Todos los requisitos del producto se enumeran en el Product Backlog. Esta lista contiene todo el trabajo que hay que hacer para que el producto sea real. Llevará muchos meses. El Product Owner es el encargado de mantener actualizada la lista en el backlog del producto y tiene que mantener las prioridades urgentes. El papel del Product Owner es el único que decide las prioridades y la dirección del proyecto. Tienen que reunirse para realizar la planificación de la versión.
Planificación y estimación
El equipo entrega un producto cada 4 semanas. Al principio de la primera semana, la reunión de planificación del sprint da la oportunidad de reunirse con el equipo de desarrollo y el propietario del producto. Donde el Product Owner explica al equipo la máxima prioridad, entregar la parte de la plataforma que conecta los perfiles y las empresas. Este es el objetivo de la iteración.
El Equipo de Desarrollo comprueba la lista de requisitos, que está actualizada y ordenada por prioridades, y decide qué parte creen que pueden completar en cuatro semanas, coincidiendo con el objetivo de esa iteración.
Una vez decidido el trabajo a realizar, el Equipo de Desarrollo analiza y desglosa cada uno de los requisitos en tareas, suficientes para empezar a trabajar. Durante esta fase tienen que identificar, estimar y crear el Sprint Backlog. En este proceso, las Historias de Usuario aprobadas, estimadas y comprometidas se desglosan en tareas específicas y se compilan en una Lista de Tareas. El Equipo se encarga de mantener la actualización durante todo el Sprint.
Implementación
Después de cada Sprint tienen que crear valor a través de la creación de Entregables.
Cada mañana de trabajo, en las reuniones diarias de Standups, el Equipo de Desarrollo se reúne durante 15 minutos donde cada miembro comenta las tareas realizadas, los problemas encontrados con sus posibles soluciones y las siguientes tareas a realizar. Juntos deciden cómo resolver los problemas, si los hay.
A medida que el equipo completa las tareas sobre los requisitos, se las muestra al Product Owner, que es quien decide si cumplen los criterios de calidad. Es él quien informa al equipo sobre la situación del producto.
El incremento significa todos los requisitos terminados junto con la parte del producto realizada anteriormente. El objetivo de la iteración es entregar un Incremento terminado que cumpla con el objetivo establecido.
Entre las actividades no sólo se incluye la creación de entregables y la realización de Standups diarios, sino que además deben actualizar constantemente el Product Backlog.
Revisión y retrospectiva
Al final del Sprint, el Product Owner organiza la reunión de Revisión del Sprint, donde muestra a los stakeholders y al Equipo de Desarrollo el incremento, revisan los entregables y validan el Sprint. Las partes interesadas dan su opinión sobre el incremento y hacen cualquier pregunta al equipo de desarrollo. A continuación, comparten cuál es la situación actual del negocio. Al final, se actualiza el Product Backlog con la nueva información que haya podido surgir.
Liberación
Después de la reunión de Revisión del Sprint y una vez que los entregables aceptados son enviados al cliente, el Scrum Master, la persona encargada de gestionar todo el proceso de Scrum, organiza la reunión de Retrospectiva con todo el equipo, Product Owner, Equipo de Desarrollo y Scrum Master. Donde se analizan los problemas, las formas de trabajar y dónde mejorar.
La reunión de retrospectiva significa el final del Sprint e inmediatamente después comienza un nuevo Sprint, siguiendo el mismo proceso explicado anteriormente.
¿Cuáles son los eventos, ceremonias o reuniones de Scrum?
Los eventos llamados también ceremonias o reuniones ocurren dentro de cada el evento llamado Sprint:
✔ Planificación del Sprint
✔ Standups diarios
✔ Revisión del Sprint
✔ Retrospectiva del Sprint.
¿Qué es un Sprint?
El sprint contiene los otros eventos de Scrum.
El Sprint es una caja de tiempo de un mes o menos durante el cual el equipo scrum produce un incremento de producto potencialmente.
La duración es continua, el Sprint mantiene una duración consistente a lo largo de un esfuerzo de desarrollo.
La invariabilidad, en tiempo y ritmo no cambia a largo plazo para afrontar la complejidad y la comparación entre Sprints.
La razón principal para establecer un tiempo encajonado es dar el período en el que un Equipo de Desarrollo puede crear valor a través de los entregables. La duración de un Sprint debe ser entre un mes o menos, normalmente los miembros del Equipo de Desarrollo deciden la duración. Al tratarse de un proyecto de gran complejidad, es habitual que el equipo deba descubrir cuál es el periodo mínimo necesario para crear valor.
El sprint se construye en base a los tres pilares que permiten la transparencia, la inspección y la adaptación y se aplican en todos los eventos.
El sprint es una iteración definida (encajonada en el tiempo) que sirve para el desarrollo interactivo. El sprint sustituye a las fases. Un nuevo Sprint sigue inmediatamente al final del Sprint anterior. Se fija en avanzado la fecha de inicio y fin del Sprint.
Nota:
Todo ocurre en un Sprint.
Entender lo siguiente es clave para una implementación o transición exitosa a Scrum.
El cambio a la mentalidad de Sprint es el más fácil de asumir en las organizaciones.
Esta increíble herramienta para la gestión de proyectos que dura un mes en comparación con la forma tradicional que la duración de los proyectos puede durar meses, incluso años. Sin embargo encuentras, por ejemplo, la planificación, las pruebas, la revisión que están orientadas a la máxima generación de valor en un solo Sprint. Otra gran diferencia es que los proyectos se financian por sprint, decidido por el Product Owner.
¿Qué es una reunión de planificación del Sprint?
Es la lista de trabajos a realizar en lo establecido en el sprint por el equipo Scrum al inicio de cada Sprint.
Se inspecciona la definición de Hecho, el Equipo de Desarrollo, el Backlog del Producto, los compromisos retrospectivos y el objetivo del Sprint.
En esta reunión, el Equipo decide después de inspeccionar el Backlog actualizado del Sprint de inicio en el que el equipo estimará el trabajo y aclarará cualquier duda.
Todos participan excepto los Stakeholders .
Al final de la reunión, dos preguntas esenciales deben haber sido respondidas.
Primero, ¿Qué? se va a hacer en el Sprint.
En esta parte, el Product Owner lidera, sin embargo, debe llegar a un acuerdo con el equipo ya que predice cuántos elementos del Product Backlog cree que es capaz de terminar en el Sprint una vez escuchado el Product Owner.
Segundo, ¿Cómo? donde el Equipo de Desarrollo debe liderar.
Ellos deben fragmentar el trabajo seleccionado en tareas más pequeñas y tienen la última palabra en este tema. Es importante que recuerden constantemente analizar lo mínimo y necesario para empezar a trabajar.
El Scrum Master en este caso se asegura de que la reunión se lleva a cabo y se siguen las directrices de Scrum. Esto no significa que el Scrum Master deba organizar o facilitar por sí mismo.
La guía de Scrum establece que la duración de la reunión debe ser de 8 horas para un sprint de un mes. El objetivo principal de esta reunión es sincronizar las prioridades entre el negocio y el desarrollo del producto.
En conclusión:
¿Qué necesitamos en la reunión de Sprint Planning?
1. Definición de Hecho
2. Equipo de desarrollo (velocidad y capacidad)
3. Backlog del producto
4. Compromisos retrospectivos
¿Qué es el resultado final?
1. Objetivo realista del sprint
2. Previsión
3. Backlog de producto del sprint actualizado
¿Qué es el Daily Standup o Daily Scrum?
Alrededor de 15 minutos de reunión diaria donde los miembros del equipo discuten el progreso diario en breve y específicamente sobre el progreso y los obstáculos para actualizar a todos.
Los participantes son el equipo, el Product Owner (opcional), y el Scrum Master suele estar presente y se asegura de que la reunión se lleve a cabo.
Una vez que el Sprint ha comenzado, el Scrum diario es clave. Se celebra todos los días a la hora acordada. Se recomienda que sea breve (15 “) y de pie para facilitar esta dinámica.
El objetivo principal es la sincronización del trabajo del equipo y si hay algún obstáculo que se informe y comparta aunque no se discuta en profundidad. Si se encuentra algún obstáculo, se discute después de la reunión. Los obstáculos se anotan y el Scrum Master es responsable de ayudar a resolverlos.
Aunque esta reunión no es obligatoria, permite la sincronización del Equipo de Desarrollo y ayuda a la aplicación de la inspección y la adaptación. Es importante tener en cuenta que no se trata de una reunión de informes, sino de información compartida para una mejor sincronización y para asegurarse de que todos van en la misma dirección y sin problemas.
Las principales preguntas que cada participante responde son:
¿Qué han hecho desde la última reunión?
¿Qué van a hacer hasta la próxima reunión?
¿Qué obstáculos han encontrado?
Nota: Los nuevos equipos, se recomienda anular cualquier ayuda de cualquier persona que pueda crear la sensación de control si quieren promover la autogestión y la microgestión. Alternativamente, cualquier parte interesada puede después de la reunión para ofrecer la accesibilidad de su experiencia y conocimientos para desbloquear lo que detiene el flujo del proyecto.