Introducción al marco de trabajo Scrum

Qué es Scrum

Cuando hablamos de Scrum nos referimos a un marco de trabajo en el que equipos interdisciplinarios pueden crear productos o desarrollar proyectos de una forma iterativa e incremental.

El marco de trabajo Scrum es el modelo de gestión de procesos ágil más aceptado y difundido mundialmente.

Scrum se basa en un proceso iterativo e incremental con entregas de valor temprana al cliente.

La clave del marco de trabajo Scrum es que en cualquier momento pueden surgir cambios importantes en las necesidades del producto.

Scrum se estructura en ciclos de trabajo llamados Sprints (también conocidos como iteraciones).

Manifiesto ágil

El manifiesto ágil está compuesto por Valores y Principios.

Individuos e interacciones sobre procesos y herramientas
Producto funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan establecido

Los principios del manisfesto ágil son:

La mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de valor.
Se acepta que los requisitos cambien, incluso en etapas tardías del proyecto. Los procesos Ágiles aprovechan el cambio para proporcionar una ventaja competitiva al cliente.
Se entrega un producto funcionando frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y el equipo de proyecto trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se realizan entorno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de proyecto y entre sus miembros es la conversación cara a cara.
El producto funcionando es la medida principal de progreso
Los procesos Ágiles promueven el desarrollo sostenible. Los sponsors, el equipo del proyecto e interesados deben ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores ideas, requisitos y diseños emergen de equipos auto-organizados
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Componentes del marco de trabajo scrum

Se suelen llamar “ceremonias” a las reuniones claves del sprint y son:

Reunión de Inicio de Sprint, Reunión de Planificación, Sprint Planning, Reuniones Diarias o Daily, Retrospectiva o Retro, también llamada cierre de sprint.

Planificación

La Planificación es una reunión de trabajo colaborativo cuyos objetivos son:

Entender y determinar el trabajo que el Equipo se compromete a terminar en el Sprint.
Definir cómo se va a realizar este trabajo.

La Planificación es la primera actividad de cada Sprint, y tiene una duración máxima fija acordada (time-boxed).

La Planificación se compone de dos sub-ceremonias, que pueden ser manejadas como reuniones separadas: la primera parte: el “Qué” y la segunda parte: el “Cómo”

Requisitos

Contar con una planificación de alto nivel:
Durante la Planificación, se va a determinar la planificación de un Sprint de duración corta (entre 1 y 4 semanas en general). Este Sprint suele ser parte de una entrega más grande, Release, fase o etapa de duración mayor (entre 3 y 6 meses en general).
Contar con un Backlog de Producto refinado:
El artefacto sobre el cual se basa la ceremonia de Planificación es el Backlog de Producto.

Backlog del producto

El Backlog de Producto es una lista ordenada de ideas para el producto, mantenidas en el orden en el cual se espera que se resuelvan. Es la fuente única desde la cual fluyen todos los requerimientos. Eso implica que todo el trabajo del equipo viene del Backlog de Producto. Por ejemplo, cada idea de funcionalidad, mejora, resolución de incidente, necesidad de documentación se deriva de un ítem del Backlog de Producto. Cada ítem del Backlog de Producto incluye una descripción y una estimación de alto nivel.

El Backlog de Producto puede empezar como una larga o corta lista, puede ser de muy alto nivel o muy detallado. Generalmente empieza como una lista corta y de muy alto nivel, y con el paso del tiempo se vuelve más larga y detallada. Los elementos que van a ser implementados próximamente suelen ser “refinados”: clarificados, mejor definidos, divididos en varios elementos más chicos, como parte de la actividad de Refinamiento de Backlog de Producto.

El Dueño de Producto es responsable de mantener el Backlog de Producto.

Historia de usuario

Una Historia de Usuario describe una funcionalidad que será de valor para un usuario o cliente.

Se suele emplear el siguiente formato para documentar la historia de usuario:

Como <rol>, puedo <funcionalidad>, para <beneficio de negocio>

Por ejemplo: “El usuario pepe registrado en el sitio de turismo online, quiere reservar nuevos viajes para que se actualicé su bonus.”

Otro ejemplo: “Como cliente de PelisOnline, quiero buscar películas por actor, para que pueda encontrar más fácilmente las películas que quiero alquilar.”

Historia de usuario metodología INVEST

I – Independiente: se trata de lograr historias de usuario lo más independientes entre sí, para poder construirlas en cualquier orden según las prioridades del negocio. No siempre es factible, pero es importante tratar de tener historias de usuarios lo más independientes posibles.

N – Negociable: Las historias de usuario deberían permitir al equipo negociar con el representante de negocio sobre el alcance detallado de la misma, para lograr una exploración conjunta de la funcionalidad y llegar a un acuerdo.

V – Valorable: A cada historia de usuario se debería poder asociar un valor claro para el negocio. Una historia de usuario con un valor de negocio ambiguo suele ser muy difícil de priorizar.

E – Estimable: Se debería poder estimar el esfuerzo necesario para construir la historia de usuario.

S – Pequeña: Se debería tratar de tener historias de usuario lo más pequeño posible, para facilitar su estimación y minimizar el tiempo de construcción correspondiente.

T – Testeable: Se debería tratar de tener historias de usuario que se puedan testear (verificar, validar) para asegurar su cumplimiento.

La Parte I de la Planificación se centra en “qué” es lo que el Dueño de Producto quiere que se desarrolle en el Sprint y “por qué” es necesario.

1. Definición de Sprint

El Scrum Master agenda o repasa con el Equipo y el Dueño de Producto las fechas claves del Sprint:

Inicio y fin del Sprint, y eventuales feriados o días que no se pueden contar en el Sprint.
Fecha, horario y lugar de las ceremonias de Reunión Diaria, Revisión y Retrospectiva.

2. Revisión de Elementos

El Dueño de Producto y el Equipo revisan los elementos de mayor prioridad del Backlog de Producto que al Dueño de Producto le interesa desarrollar durante este Sprint. Se discuten los objetivos, la motivación y el contexto correspondiente a cada uno de los elementos, de tal forma que el Dueño de Producto pueda transmitir al Equipo la visión del producto a desarrollar, y se aclaran todas las dudas que puedan surgir. Si no estuviera hecho anteriormente, se pueden definir criterios de aceptación para cada uno de los elementos.

3. Definición del Objetivo del Sprint

El Dueño de Producto y el Equipo pueden formular un objetivo del Sprint. Se trata de una declaración que resume la finalidad del Sprint, en el caso que este mismo tenga un tema central.

4. Estimaciones de Alto-Nivel

El Equipo determina una estimación de alto nivel de cada uno de los elementos del Backlog de Producto presentados, en el caso que no lo hayan estimado previamente (por ejemplo, en Sprints anteriores o en reuniones de Refinamiento de Backlog).

Una característica bastante común de las estimaciones en las metodologías ágiles es que sean relativas. Eso significa que no se busca una estimación universal de la complejidad o del esfuerzo de construcción un elemento del Backlog de Producto, sino una comparación de su complejidad

contra otros elementos conocidos. En particular no se busca una estimación en horas del esfuerzo de construcción del elemento, sino poder comparar su complejidad de desarrollo contra la de otros elementos. Para lograr este objetivo, se suele usar una unidad de estimación abstracta de comparación entre elementos, como por ejemplo el (Story Point).

Punto de historia (Story Point)

Un Punto de Historia es una unidad arbitraria pero fija que describe cuánto esfuerzo requiere un elemento del Backlog de Producto para ser entregado al cliente.

Esta medida relativa suele ser útil para pensar en forma más abstracta las estimaciones y compararlas contra elementos conocidos. La escala de Puntos de Historia y su correspondencia promedia con el esfuerzo son características propias de cada equipo de proyecto.

Se suelen usar técnicas de estimaciones como Planning Poker, T-Shirt Sizing, Wideband Delphi u otras.

5. Acuerdo Preliminar de Alcance

A partir de las prioridades expuestas por el Dueño de Producto en el paso 2. Y de las estimaciones definidas en el paso 4, el Equipo determina el alcance del Sprint: que elementos del Backlog de Producto se comprometen a terminar.

1. Identificación de tareas

El Equipo colabora para identificar todas las tareas necesarias para terminar cada uno de los elementos del Backlog de Producto comprometidos para el Sprint. Lo ideal es que cada tarea dure entre 1-8hs. División sub-tareas para mejor granularidad.

2. Estimación de tareas

El Equipo estima el esfuerzo requerido para cada una de las tareas identificadas. Se registra el esfuerzo en horas de cada tarea, y si fuera necesario se agrupa o se divide la tarea para llegar a la granularidad esperada.

3. Chequeo de Alcance

El Scrum Master ayuda al Equipo a realizar distintos chequeos para validar la factibilidad de cumplir con el alcance preliminar comprometido para el Sprint (por ejemplo, horas estimadas vs. horas disponibles del equipo).

Si fuera necesario se acuerda un cambio al alcance del Sprint con el Dueño de Producto.

De esta forma queda fijado el alcance del Sprint.

4. Armado Backlog de Sprint / Tablero de Sprint

En este paso, el Scrum Master ayuda al Equipo a terminar de registrar o armar el Backlog de Sprint / Tablero de Sprint.

Ejemplo de Tablero de Sprint

5. Asignación de Primeras Tareas

El Equipo determina en conjunto las primeras tareas que se van a realizar en las próximas 24h (o hasta la próxima Reunión Diaria), y se asignan las responsabilidades correspondientes.

Resultados

La Planificación genera un entendimiento común por el Equipo y el Dueño de Producto de la cantidad y complejidad de lo que debe completarse durante el Sprint. También genera el compromiso del Equipo entero de completarlo razonablemente (dentro de un rango de circunstancias racionales).

En cuanto a artefactos, estos resultados se reflejan en el Backlog de Sprint construido durante la Planificación, en particular por los elementos del Backlog de Producto elegidos para el Sprint, las tareas identificadas para terminar cada uno de estos elementos y sus estimaciones de esfuerzo restante asociadas.

Reunión diaria (Daily)