Scrum
Índice
Definición de Scrum

Scrum (n): Es un marco de trabajo a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.

Scrum es un marco de trabajo compuesto de procesos que se ha utilizado para gestionar el trabajo de productos complejos desde principios de los años 90. Scrum no es un proceso, una técnica, o método definitivo. Todo lo contrario, es un marco de trabajo donde se pueden emplear un conjunto de diferentes procesos y técnicas. Scrum muestra la eficacia relativa de las técnicas de gestión de producto y de trabajo de modo que podamos continuamente mejorar el producto, el equipo y el entorno de trabajo.

El marco de trabajo Scrum se compone por:

Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso.

Las Reglas de Scrum relacionan los roles, eventos y artefactos, gobernando las relaciones e interacciones entre ellos.

Usos de Scrum

Scrum inicialmente fue desarrollado para gestionar y desarrollar productos. A partir de la década de 1990s, Scrum se ha utilizado extensivamente en todo el mundo, para:

  1. Investigar e identificar mercados viables, tecnologías, y capacidades
  2. Desarrollo de productos y mejoras
  3. Lanzamientos de productos y mejoras, diariamente tantas veces como sea posible
  4. Desarrollo y mantenimiento en la Nube (online, seguridad, por-demanda) y otros entornos operacionales de desarrollo para el uso de producto
  5. Mantenimiento y renovación de productos

Scrum se ha utilizado para el desarrollo de software, hardware, software embebido, redes de funciones interactiva, vehículos autónomos, escuelas, gobiernos, marketing, gestión operacional de las organizaciones y en casi todo lo que utilizamos en nuestra vida diaria, como individuos y sociedades.

Scrum se ha demostrado especialmente efectivo en la transferencia de conocimiento iterativamente e incrementalmente. Scrum es ampliamente utilizada para productos, servicios, y la gestión de la organización matriz.

Teoría de Scrum

Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y en poder tomar decisiones basándose en lo conocido. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.

Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación.

TransparenciaLos aspectos significativos del proceso deben ser visibles para todos aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos en base a un estándar común, de tal modo que los observadores compartan un entendimiento común de lo que se están viendo.
InspecciónLos usuarios de Scrum deben inspeccionar frecuentemente los Artefactos de Scrum y el progreso hacia un objetivo para detectar variaciones indeseadas. Su inspección no debe ser tan frecuente como para que pueda interferir en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo.
AdaptaciónSi un inspector determina que uno o más aspectos de un proceso se desvían de los límites aceptables y que el producto resultante será inaceptable, el proceso o el material que está siendo procesado deben ajustarse. Dicho ajuste deberá realizarse cuanto antes para minimizar desviaciones mayores.

Valores de Scrum

Cuando los valores del compromiso, coraje, focalización y apertura, son incorporados y vividos por el equipo Scrum, los pilares Scrum como son la transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el mundo. Los miembros del Equipo Scrum (Scrum Teams) aprenden y exploran estos valores a medida que van trabajando en los Eventos (Events), Roles (Roles) y Artefactos (Artifacts) de Scrum.

El equipo Scrum

El Equipo Scrum (Scrum Team) consiste en un Propietario del Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum (Scrum Teams) son auto-organizados y multifuncionales. Los equipos auto-organizados eligen la mejor opción de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no formen parte del equipo. El modelo de Equipo en Scrum (Scrum Team) está diseñado para optimizar la flexibilidad, la creatividad y la productividad. El Equipo Scrum (Scrum Team) ha demostrado ser incrementalmente efectivo para todos los usos anteriores y para cualquier trabajo complejo.

Los Equipos Scrum (Scrum Teams) entregan productos de forma iterativa e incremental, maximizando las oportunidades para poder obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.

El Propietario del Producto (Product Owner)

El Propietario del Producto (Product Owner) es el responsable de maximizar el valor del producto del trabajo del Equipo de Desarrollo (Development Team). Cómo se lleva a cabo puede variar ampliamente entre distintas organizaciones, equipos Scrum e individuos.

El Propietario del Producto (Product Owner) es la única persona responsable de gestionar la Pila del Producto (Product Backlog). La gestión de la Pila del Producto (Product Backlog) incluye:

Para que el Propietario del Producto (Product Owner) pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Propietario del Producto (Product Owner) se reflejan en el contenido y en la priorización de la Pila del Producto (Product Backlog). Nadie puede pedir al Equipo de Desarrollo (Development Team) que trabaje en un conjunto diferente de requisitos.

El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo (Development Team) se compone de profesionales que realizan el de entregar un Incremento de producto “Terminado” (“Done” )que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento de producto “Terminado” es obligatorio en la Revisión del Sprint (Sprint Review). Solo los miembros del Equipo de Desarrollo (Development Team) participan en la creación del Incremento.

Los Equipos de Desarrollo (Development Teams) tienen las siguientes características:

Tamaño del Equipo de Desarrollo (Development Team)

El tamaño óptimo del Equipo de Desarrollo (Development Team) es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una cantidad de trabajo significativa. Tener menos de tres miembros en el Equipo de Desarrollo (Development Team) reduce la interacción y resulta en ganancias de productividad más pequeñas. Tener más de nueve miembros en el equipo requiere demasiada coordinación. Los Equipos de Desarrollo grandes generan demasiada complejidad como para que un proceso empírico pueda ser de utilidad. Los roles de Propietario del Producto (Product Owner) y Scrum Master no se contabilizan en el cálculo del tamaño del equipo a menos que también estén contribuyendo a trabajar en la Pila del Sprint (Sprint Backlog).

El Scrum Master (Scrum Master)

El Scrum Master es el responsable en promocionar y apoyar Scrum como se define en la Guía de Scrum. Los Scrum Masters hacen esto ayudando a todos la teoría de Scrum, prácticas, reglas y valores. El Scrum Master es un sirviente líder que está al servicio del, y para el Equipo Scrum (Scrum Team).

El servicio del Scrum Master al Propietario del Product (Product Owner)

El Scrum Master sirve al Propietario del Producto (Product Owner) de varias formas, incluyendo:

El servicio del Scrum Master al Equipo de Desarrollo (Development Team)

El Scrum Master sirve al Equipo de Desarrollo (Development Team) de varias formas, incluyendo:

El servicio del Scrum Master a la Organización

El Scrum Master sirve a la organización de varias formas, incluyendo:

Eventos en Scrum

En Scrum existen diferentes eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son compartimientos o periodos de tiempo limitado (time-boxes), de tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los otros eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.

Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y adaptación en algún aspecto. Estos eventos se diseñaron específicamente para habilitar los pilares vitales de transparencia e inspección. La falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación.

El Sprint (Sprint) El corazón de Scrum es el Sprint, es un compartimiento o periodo de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable. Sprints tienen duración consistente a lo largo de todo el esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. Los Sprints contienen y consisten en la Planificación del Sprint (Sprint Planning), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective). Durante el Sprint:
  • No se realizan cambios que puedan afectar al objetivo del Sprint (Sprint Goal).
  • Los objetivos de calidad no disminuyen.
  • El alcance puede clarificarse y renegociarse entre el Propietario del Producto (Product Owner) y el Equipo de Desarrollo a medida que se va aprendiendo más.
Cancelación del Sprint Un Sprint puede cancelarse antes que, el periodo o compartimiento de tiempo, llegue a su fin. Solo el Propietario del Producto (Product Owner) tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo de Desarrollo (Development Team) o del Scrum Master. n Sprint se cancelaría si el objetivo del Sprint llega a quedar obsoleto. Esto podría ocurrir si la compañía cambia la dirección o si las condiciones del mercado o de la tecnología cambian. En general, un Sprint debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias. Sin embargo, debido a la corta duración de los Sprints, su cancelación rara vez tiene sentido.
Planificación del Sprint (Sprint Planning) El trabajo a realizar durante el Sprint se planifica en la reunión de Planificación del Sprint (Sprint Planning). Este plan se crea mediante el trabajo colaborativo de todo el Equipo Scrum. El Equipo de Desarrollo (Development Team) trabaja para proyectar la funcionalidad que se desarrollará durante el Sprint. El Propietario del Producto (Product Owner) discute el objetivo que el Sprint debería lograr y los elementos de la Pila del Producto (Product Backlog) que, si se completan en el Sprint, lograrían el objetivo del Sprint. El Equipo Scrum completo colabora en el entendimiento del trabajo del Sprint.
Objetivo del Sprint (Sprint Goal) El objetivo del Sprint es una meta establecida para el Sprint que puede lograrse mediante la implementación de la Pila del Producto (Product Backlog). Proporciona una guía al Equipo de Desarrollo (Development Team) acerca de por qué está construyendo el incremento. Se crea durante la Planificación del Sprint (Sprint Planning). El objetivo del Sprint brinda al Equipo de Desarrollo (Development Team) cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint. Los elementos de la Pila del Producto (Product Backlog) seleccionados ofrecen una función coherente que puede ser el objetivo del Sprint. El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo (Development Team) trabaje en conjunto y no en iniciativas separadas. A medida que el Equipo de Desarrollo (Development Team) trabaja mantiene el objetivo del Sprint en mente. Con el fin de satisfacer el objetivo del Sprint se implementa funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo (Development Team) espera, ellos colaboran con el Propietario del Producto (Product Owner) para negociar el alcance de la Pila del Sprint (Sprint Backlog).
Daily Scrum (Scrum Diario) El Scrum Diario (Daily Scrum) es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo (Development Team). El Scrum Diario (Daily Scrum) se realiza diariamente para cada día del sprint. En él, el Equipo de Desarrollo (Development Team) planea el trabajo para las siguientes 24 horas. Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario (Daily Scrum) y proyectando el trabajo del Sprint a realizar a continuación. El Scrum Diario (Daily Scrum) se realiza a la misma hora y lugar todos los días para reducir la complejidad. El Equipo de Desarrollo (Development Team) usa el Scrum Diario (Daily Scrum) para evaluar el progreso hacia el Objetivo del Sprint (Sprint Goal) y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Pila del Sprint (Sprint Backlog). El Scrum Diario (Daily Scrum) optimiza las posibilidades de que el Equipo de Desarrollo (Development Team) cumpla el Objetivo del Sprint (Sprint Goal). Cada día, el Equipo de Desarrollo (Development Team) debería trabajar conjuntamente como un equipo autoorganizado para lograr el Objetivo del Sprint (Sprint Goal) y crear el Incremento esperado hacia el final del mismo.
Revisión del Sprint (Sprint Review) Al final del Sprint se lleva a cabo una Revisión de Sprint (Sprint Review) para inspeccionar el Incremento y adaptar la Pila del Producto (Product Backlog) si fuese necesario. Durante la Revisión de Sprint (Sprint Review), el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Pila del Producto (Product Backlog) durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración. La Revisión de Sprint (Sprint Review) incluye los siguientes elementos:
  • Los asistentes son el Equipo Scrum y los interesados clave invitados por El Propietario del Producto (Product Owner);
  • El Propietario del Producto (Product Owner) explica qué elementos de la Pila del Producto (Product Backlog) se han “Terminado” y cuales no se han “Terminado”;
  • El Equipo de Desarrollo (Development Team) habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas;
  • El Equipo de Desarrollo (Development Team) hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;
  • El Propietario del Producto (Product Owner) habla acerca de la Pila de Producto (Product Backlog) en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha (si fuera necesario);
  • El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes;
  • Revisión de la cronología, presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.
Retrospectiva del Sprint (Sprint Retrospective) La Retrospectiva del Sprint (Sprint Retrospective) es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint. La Retrospectiva del Sprint (Sprint Retrospective) tiene lugar después de la Revisión de Sprint (Sprint Review) y antes de la siguiente Planificación de Sprint. Se trata de una reunión restringida a lo máximo de tres horas para Sprints de un mes. Para Sprints más cortos se reserva un tiempo usualmente más corto. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.

Artefactos en Scrum (Scrum Artifacts)

Los artefactos de Scrum representan el trabajo o el valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.

Pila del Producto (Product Backlog) La Pila del Producto (Product Backlog) es una lista ordenada de todo lo conocido que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Propietario del Producto (Product Owner) es el responsable de la Pila del Producto (Product Backlog), incluyendo su contenido, disponibilidad y ordenación.
Seguimiento del Progreso hacia los Objetivos En cualquier momento es posible sumar el trabajo total restante para alcanzar el objetivo. El Propietario del Producto (Product Owner) hace seguimiento de este trabajo restante total al menos en cada Revisión de Sprint (Sprint Review). El Propietario del Producto (Product Owner) compara esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo proyectado en el tiempo deseado para el objetivo. Esta información se muestra de forma transparente a todos los interesados.
Pila del Sprint (Sprint Backlog) La Pila del Sprint (Sprint Backlog) es el conjunto de los elementos de la Pila del Producto (Product Backlog) seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el objetivo del Sprint. La Pila del Sprint (Sprint Backlog) es una predicción hecha por el Equipo de Desarrollo (Development Team) acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.
Seguimiento del Progreso del Sprint En cualquier momento durante un Sprint es posible sumar el trabajo restante total en los elementos de la Pila del Sprint (Sprint Backlog). El Equipo de Desarrollo (Development Team) hace seguimiento de este trabajo restante total al menos en cada Scrum Diario (Daily Scrum) para proyectar la posibilidad de conseguir el objetivo del Sprint. Haciendo seguimiento del trabajo restante a lo largo del Sprint el Equipo de Desarrollo (Development Team) puede gestionar su progreso.
Incremento (Increment) El Incremento es la suma de todos los elementos de la Pila del Producto (Product Backlog) completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum.Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del Sprint. El incremento es un paso hacia una visión o meta. El incremento debe estar en condiciones de utilizarse sin importar si el Propietario del Producto (Product Owner), decide liberarlo o no.