Curso Scrum: Eventos Scrum - Flujo de trabajo - Sprints - Parte 4

Eventos Scrum

Sigue de cerca las siguientes partes del Curso Scrum:

Contenidos en el artículo

La naturaleza de los eventos de Scrum

Sprints

Hay sólo cinco eventos en un proyecto Scrum:

  1. Sprint: Cada proyecto Scrum es un conjunto de Sprint. Sprints es un contenedor para los otros cuatro eventos (como se representa en el diagrama anterior), el esfuerzo de desarrollo y el mantenimiento de la cartera de productos.
  2. Planificación Sprint: La Planificación Sprint es el primer evento dentro de un Sprint. El equipo de Scrum planifica los artículos que van a entregar en el Sprint y la forma en que los van a entregar.
  3. Daily Scrum: El Equipo de Desarrollo comienza a trabajar en los objetivos de Sprint tan pronto como se completa la Planificación Sprint. Durante este tiempo, se celebra una reunión diaria (normalmente de 15 minutos) para coordinar el trabajo durante las siguientes 24 horas, que se llama Daily Scrum.
  4. Revisión de Sprint: Antes del final del Sprint, el Equipo de Desarrollo presenta (demuestra) el resultado del Sprint al cliente y recibe retroalimentación. Esta reunión se llama Sprint Review (también conocida como Sprint Demo).
  5. Retrospectiva de Sprint: Después de la Revisión Sprint y justo antes de que termine el Sprint, el Equipo de Desarrollo lleva a cabo una reunión interna para revisar el Sprint y usarlo para mejorar el proceso (lecciones aprendidas) en el próximo Sprint. Esto se llama Sprint Retrospective.

Los eventos están diseñados para permitir la transparencia crítica, la inspección, la regularidad y la adaptación. Preferimos utilizar estas reuniones predefinidas con objetivos fijos y duraciones máximas en lugar de reuniones ad-hoc, que probablemente nos hagan perder el tiempo.

Hay un concepto esencial en los métodos ágiles, llamado time-box: una duración máxima fija predefinida de tiempo. Para maximizar la productividad, todos los eventos de Scrum deben ser cronometrados.

El concepto de caja de tiempo

Time-box es un concepto esencial en Scrum. Es nuestra manera de mantenernos enfocados y hacer las cosas en un ambiente siempre cambiante. Una caja de tiempo es un período de tiempo fijo en el que congelamos el objetivo y trabajamos con un enfoque total en ciertas tareas u objetivos. Eventos de caja de tiempo repita muchas veces, hasta que se logre la meta final. Todos los cambios se aplican sólo cuando una caja de tiempo está terminada y estamos listos a iniciar la siguiente.

La duración de una caja de tiempo debe ser acordada y fijada. Somos libres de cambiar la duración basándonos en las lecciones aprendidas, pero no con frecuencia, y nunca en una sola ocasión. Por ejemplo, no se nos permite decir que "tenemos mucho que hacer esta vez, así que vamos a aumentar la duración de este caso en particular". Lo que se nos permite decir es que "basándonos en las diez cajas de tiempo anteriores, nos dimos cuenta de que la duración de nuestras cajas de tiempo no es adecuada, y un aumento del 30% en la duración podría satisfacer mejor nuestras necesidades. Entonces, vamos a aumentarlos de ahora en adelante".

Evento 1: Sprints

Sprints

Cada proyecto Scrum entrega el producto final después de una serie de ciclos, que se denominan Sprints. Se desarrolla un incremento en cada Sprint. Un Incremento es una parte potencialmente liberable del producto final; una suma de todos los artículos de la Cartera de Productos completados en un Sprint específico y sus sprints anteriores.

Un Incrementos puede ser considerado una revisión menor del producto con nuevas características y funcionalidades. Un incremento puede o no ser liberado al final del Sprint, pero debe ser potencialmente liberable.

Por lo general, los clientes solicitan cambios cuando ven el Aumento (Revisión Sprint) y nosotros aplicamos los cambios en la Cartera de Productos.

Sprints

Sprint es un evento temporal, lo que significa que debemos fijar su duración al principio del proyecto y no cambiarlo con frecuencia u ocasionalmente. Los sprints son generalmente fijos por un mes o menos.

El punto importante es que no cambiamos los ítems del Sprint Backlog después de que se inicia el Sprint y se establecen los planes. La Meta Sprint (discutida más adelante en la Planificación Sprint) tampoco debería cambiar en absoluto. El Propietario del Producto y el Equipo de Desarrollo podrían tratar de clarificar y renegociar el alcance a medida que se aprende más, pero no cambiarán la Cartera Sprint. Incluso la composición del Equipo de Desarrollo no debe cambiar durante un Sprint. Estas limitaciones están diseñadas para que sea posible concentrarse y hacer las cosas.

Cada ítem (historia) en la Cartera de Productos normalmente debe ser desarrollado (completado) en un Sprint sencillo, ya que es mucho más fácil de manejar. El propietario del producto y el desarrollo. El equipo selecciona un número de artículos de la parte superior de la cartera de productos (esto ya ha sido priorizados por el Propietario del Producto) y procurar que sean "Hechos" (100% completos). Queremos para que queden realmente "Listos" cuando termine el Sprint, y crear un Incremento. Un incremento es la suma de todos los ítems completados durante un Sprint y todos los Sprints anteriores.

Es importante acordar una definición de "Hecho" al principio del proyecto. No vamos a llamar a algo "Hecho", a menos que se ajuste a la definición. Un elemento completado en un 99.999% no es considerado como "Hecho", no formaría parte del Incremento, y no sería demostrado al cliente en el Sprint Review.

Cajas de Tiempo Sprint: La mayoría de las empresas utilizan cajas de tiempo Sprint de 2 a 4 semanas. Si usamos cuadros de tiempo más de un mes calendario para Sprints, es probable que para los cambios no aplicados para ser lo suficientemente grandes como para crear problemas. Esto aumentará la complejidad y el riesgo.

Por lo tanto, debemos mantener las carreras no más de un mes calendario. Las carreras no deben ser demasiado cortos, ya que no podríamos producir una cartera de pedidos completa durante el mismo. Nuestro objetivo es entregar el producto final artículo por artículo, dentro de los Sprints; nosotros no desea dividir un solo artículo de la cartera de productos entre varios Sprints.

¿Se puede cancelar un Sprint? A pesar de que cada Sprint está congelado, el Propietario del Producto tiene la autoridad para cancelar un Sprint. Esto puede pasar cuando la Meta del Espíritu se vuelve obsoleta, debido a los cambios en la Cartera de productos, estrategias, enfoque, etc. Cuando se cancela un Sprint, la tecla de los ítems que están "Hecho" serán revisados y aceptados, y el resto de los ítems que están "Hecho" serán revisados y aceptados.

Evento 2: Planificación Sprint

Sprints

El Equipo de Desarrollo no espera hasta que el Producto de la cartera de pedidos está planificada al 100% (se reúnen todas las necesidades) y para comenzar a desarrollar el proyecto. Tan pronto como el Producto de la cartera de pedidos está lo suficientemente madura como para guiarnos en un futuro próximo, es el Propietario de Producto y el Equipo de Desarrollo pueden que iniciar el primer Sprint.

Lo primero que hay que hacer en cada Sprint es planearlo. La Planificación Sprint es una reunión de tiempo limitado, generalmente fijada en 8 horas para un Sprint de un mes, o más corta para Sprints de menos de un mes. Los tres roles deben asistir a esta reunión.

El Equipo de Desarrollo debe estimar la capacidad de trabajo que puede entregar en un solo Sprint. El Propietario del Producto ya ha clasificado y ordenado la Cartera de Productos basada en el valor de los artículos. El Propietario del Producto también se asegura de que los artículos (historias) sean fáciles de entender. El Equipo de Desarrollo selecciona entonces un número apropiado de artículos de la parte superior de la Cartera de Productos, y los pone en la Cartera de Sprint, para entregarlos en la Sprint actual. La cantidad de trabajo para cada ítem es estimada por el Equipo de Desarrollo y la cantidad total de trabajo de los ítems seleccionados de la Cartera de Productos es cercana a la capacidad estimada del Equipo de Desarrollo.

Después de la selección de los artículos, el equipo de Scrum debe crear una Meta Sprint, que es un objetivo que debe cumplirse dentro de Sprint a través de la implementación de la Cartera de Productos. La Meta de Scrum proporciona orientación al Equipo de Desarrollo sobre por qué está construyendo el Incremento.

No hay duda de que la cartera de productos debe ordenarse de manera que facilite el establecimiento de los objetivos de Sprint.

El alcance del Sprint, que se compone de los artículos seleccionados de la cartera de productos, puede necesitar la adición de algunos detalles a través del Sprint. Estos detalles deben estar alineados con la Meta Sprints, y las posibles renegociaciones deben hacerse en presencia del Propietario del Producto. La Meta Sprint también está incluida en la Cartera Sprint.

Cuando se seleccionan los artículos a entregar y se acuerda el Objetivo Sprint, es hora de planificar cómo convertirán los artículos en un Incremento de producto "Hecho" y realizar el Objetivo Sprint. Esta es la última parte de la Cartera Sprint. Esta planificación no necesariamente se completa en esta reunión; basta con tener un plan detallado para los primeros días; el Equipo de Desarrollo puede preparar planes detallados para el resto del trabajo más adelante.

Un plan detallado, como se muestra en la siguiente figura, es un desglose de un ítem de la Cartera de Productos en tareas detalladas necesarias para crear el ítem. Cada tarea puede tener estimaciones, dependencias e información similar para hacer posible el seguimiento.

Sprints

El Backlog de Sprint estará listo al final de esta reunión y el Equipo de Desarrollo deberá ser capaz de describir qué artículos entregarán a través de Sprint y cómo lo harán.

No hay una regla específica para documentar, almacenar y presentar el Backlog de Sprint. Se puede escribir en un tablero (gráfico mural) similar al que se muestra en la siguiente figura.

Sprints

Las notas adhesivas amarillas (post-it) en la pizarra de arriba son tareas que se crean desglosando cada uno de los elementos. Estas tareas definen lo que el Equipo de Desarrollo hará para entregar y ellos son los responsables de prepararlos. Algunas tareas se crean en la reunión de planificación de Sprint y otras a lo largo de Sprint.

El Backlog de Sprint consiste en lo siguiente:

  • 1. La meta de Sprint
  • 2. Artículos seleccionados de la cartera de productos, que se entregarán a través de la red Sprint
  • 3. Un plan detallado para convertir los elementos seleccionados en "Hecho" Incremento del producto y realizar el Objetivo Sprint (el plan no sería completamente detallado en la reunión de Planificación Sprint)

Como puedes ver, los tres elementos del Sprint Backlog (Meta Sprint, productos seleccionados para el Sprint y el plan detallado) se muestran en la placa de muestra. Esta placa Scrum de muestra también tiene características adicionales para el seguimiento de las tareas y elementos en las columnas "To Do", "Doing" y "Done". La siguiente figura muestra el mismo Sprint después de que el primer ítem está completo y los ítems #2 y #3 están en progreso.

Sprints

También puedes ver que se han agregado tareas adicionales a los ítems de menor rango (ítems #3 a #5), que es la planificación detallada continua hecha a través del Sprint.

Los artículos en la Cartera Sprint usualmente tienen el mismo orden que tenían en la Cartera de Productos, por lo tanto, el Equipo de Desarrollo debe trabajar primero en los artículos de mayor orden.

Evento 3: Scrum Diario o "Daily Scrum"

Sprints

El Diario Scrum es normalmente una reunión de 15 minutos para que el Equipo de Desarrollo inspeccione el trabajo desde la última reunión, y sincronice su trabajo y planifique para las próximas 24 horas. Debe celebrarse a diario.

Durante el Diario Scrum, cada miembro del Equipo de Desarrollo debe responder estas tres preguntas:

  • 1. ¿Qué se ha logrado desde la última reunión?
  • 2. ¿Qué se hará antes de la próxima reunión?
  • 3. ¿Qué obstáculos se interponen en el camino?

Deben evaluar el progreso hacia la Meta Sprint y pronosticar la probabilidad de completar los elementos antes de que termine el Sprint.

La reunión del Daily Scrum debe realizarse a la misma hora y en el mismo lugar durante el Sprint, para minimizar la complejidad. Es sólo para el Equipo de Desarrollo; no es una reunión de estado para todas las partes interesadas.

El Equipo de Desarrollo también debe monitorear el progreso de Sprint cada día y por lo tanto es una buena idea que la pizarra Sprint (gráfico de pared) esté visible durante la reunión del Daily Scrum. Pueden usar una tabla de quemado para llevar un registro de su trabajo restante y verificar si van a completar todos los ítems antes del final del Sprint.

Sprints

La figura de arriba ahora contiene la Tabla de Quemado y Apagado Sprint (la información de rastreo) y ésta puede ser actualizada después de cada reunión de Daily Scrum. Las tablas de quemar y reducir se discuten más adelante en la siguiente sección.

Evento 4: Revisión de Sprint

Sprints

La duración de esta reunión es normalmente de cuatro horas por un mes Sprint. Si las carreras son más cortas entonces esta reunión será proporcionalmente más corta.

Al final del Sprint, el equipo de Scrum y otras partes interesadas se reúnen y celebran una reunión de cuatro horas para presentar e inspeccionar los artículos "Hecho" (el Incremento) del Sprint actual y adaptar la cartera de productos marcando los artículos "Hecho" como completos y añadiendo nuevos artículos o cambiando los existentes si es necesario. La presentación del aumento en esta reunión tiene por objeto recabar información y formular solicitudes de cambio lo antes posible.

Damos la bienvenida a los cambios en Scrum y animamos a que sean demandados, porque aumenta la satisfacción del cliente y creará un producto final que mejor se adapte a las necesidades del cliente.

El Equipo de Desarrollo no presenta un ítem, a menos que esté 100% completo en base de la definición acordada de "Hecho". El Propietario del Producto se asegura (antes de la Revisión Scrum) de que cada uno de los puntos presentados son "Hecho". El Equipo de Desarrollo demuestra y explica los elementos.

El Propietario del Producto discute el estado de la Cartera de Productos y la probable finalización de las fechas basadas en el progreso.

Equipo Scrum

Por último, todo el equipo de Scrum colabora en la revisión de la cartera de productos en base a los siguientes criterios
de la salida del Sprint y la retroalimentación recibida del cliente.

Evento 5: Retrospectiva de Sprint

Sprints

Esta reunión es normalmente de tres horas por un mes Sprints. Si el Sprint es más corto que uno en el mes, esta reunión será proporcionalmente más corta.

Después de la Revisión Sprints y justo antes del final del Sprint, se llevará a cabo otra reunión, con el objetivo de mejorar los procesos (aprender lecciones), que se llama Sprint Retrospective. Hay una regla: siempre debemos buscar formas de mejorar. No importa lo poco que haya, la mejora es que debería haber una mejora. Esta reunión es una oportunidad formal para dar con la mejora, aunque no limitamos nuestra mejora a los resultados de esta reunión.

Revisaremos (inspeccionaremos) el Sprint, con respecto a personas, relaciones, procesos e identificar formas de mejorarlas en el próximo Sprint.

Cartera de productos de Aseo

Además del evento de caja de tiempo discutido anteriormente, también hay una actividad en curso en Scrum los proyectos denominados Product Backlog grooming. Es el acto de revisar y revisar el Producto de los ítems atrasados, que típicamente involucran agregar detalles, estimados y orden a los mismos.

El Propietario del Producto es responsable de ordenar (priorizar) los artículos y el Desarrollo y el equipo es responsable de estimar esos artículos. La principal diferencia entre esta actividad y los cinco eventos Scrum es que los eventos Scrum son
todo el tiempo encajonado, pero el aseo personal es una actividad continua que ocurre a lo largo de la carrera Sprint. Este
no debe consumir más del 10% del tiempo del Equipo de Desarrollo.

Tiempo libre

No importa cuánto trabajemos, lo que producimos es importante. Debería estar orientado al producto, más que a la actividad. Una forma de ser productivo, es limitar el tiempo de trabajo a una cantidad razonable, y tienen frecuentes ausencias a veces. Por eso se recomienda (pero no es necesario) tener un tiempo libre entre cada dos Sprints. Tengamos un día o dos apagado para recargar bien las  baterías, leer algunos artículos relevantes, y mirar lo que otros equipos están haciendo.

El tiempo libre también se puede utilizar para leer artículos, participar en cursos o talleres, gastar
tiempo en proyectos creativos, etc.
Volveremos después del tiempo libre, y repetiremos el mismo ciclo una y otra vez, cada vez, todo esto con una pequeña mejora, hasta que el producto final del proyecto se entrega, y el cliente esté completamente satisfecho con ello.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir

SSOO usa cookies, si permanece aquí acepta su uso. Puede leer más sobre el uso de cookies en nuestra política de privacidad. Ver más.