Tabla de contenidos
La metodología Scrum es una metodología de desarrollo ágil de software que ayuda a los equipos a desarrollar productos en periodos cortos, permitiendo obtener de forma rápida feedback por parte del cliente, adaptaciones y una mejora continuada.
Para comprender a fondo qué es la metodología Scrum vamos a ver primero las características del desarrollo ágil de software y sus diferencias con respecto a la metodología tradicional.
El desarrollo ágil de software o metodología ágil (Agile Methodology en inglés) es una metodología de desarrollo de software basada en el desarrollo iterativo e incremental, donde los requisitos y soluciones van evolucionando según las necesidades del proyecto.
En las metodologías ágiles la adaptación al cambio forma parte del proceso natural del proyecto.
Hay muchas diferencias entre el desarrollo ágil de software y el método de desarrollo tradicional. Si nos centramos en las diferencias fundamentales cabe destacar lo siguiente:
En la metodología tradicional, se define el proyecto desde el inicio y se crea un plan detallado con contratos estrictos. Sin embargo, en la metodología ágil se comienza definiendo las funcionalidades básicas del proyecto garantizando la entrega continua de software de valor que se va mejorando de forma continuada en cada iteración. En lugar de contratos estrictos, se mantienen reuniones constantes con el cliente y se adapta el proyecto a sus necesidades.
Las metodologías ágiles se basan en una serie de principios:
Scrum es una metodología ágil que engloba una serie de principios que ayudan a los equipos a desarrollar productos en periodos cortos (llamados sprints), permitiendo obtener de forma rápida feedback, adaptaciones y una mejora continua.
El product backlog o pila del producto es una lista ordenada y priorizada de funcionalidades definidas por el cliente.
Dentro del product backlog definiremos los elementos de la pila de producto o PBI (de sus siglas en inglés Product Backlog Item).
Los elementos del product backlog suelen contener la descripción, el orden, la estimación y el valor. Además, también pueden disponer de otra información relevante como diagramas de uso, prototipos, datos de encuestas o gráficos. Sin embargo, lo más habitual es crear este listado de elementos con el formato de Historia de Usuario.
Una historia de usuario (elemento de la lista del product backlog) es una característica o funcionalidad que tiene valor para el usuario final y es lo suficientemente pequeña para que pueda ser desarrollada en un sprint. El formato de Historia de Usuario es el siguiente:
Un ejemplo aplicado podría ser:
Cada historia de usuario del product backlog debe ser estimada. Lo importante de la estimación es la realización de una reunión para ver qué tipo de dificultades, problemas y riesgos pueden surgir durante el sprint. Se suelen tener en cuenta las siguientes características:
Para la realización de estimaciones se ideó el planning poker o scrum poker que ayuda a la estimación de la duración de las historias de usuario de forma rápida evitando largas discusiones por parte del equipo de desarrollo.
El funcionamiento es muy sencillo: durante la estimación cada miembro del equipo dispone de un juego de cartas, y en la estimación de cada tarea, todos los miembros vuelven boca arriba la combinación que suma el esfuerzo estimado.
Cada equipo puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar. Las tareas que exceden el tamaño máximo definido deben descomponerse en tareas de menor tamaño.
Las dos variantes de planning poker más conocidas son las cartas con serie de Fibonacci y con tallas de ropa.
A continuación se propone la operativa que se llevaría durante una reunión de estimación mediante cartas basadas en la serie de Fibonacci:
El mecanismo es el mismo que mediante cartas con serie de Fibonacci. La diferencia es que en vez de utilizar números, se utilizan tallas de camiseta o de ropa. De esta forma se pueden definir otros valores diferentes que se pueden asociar a cada una de las cartas durante en la estimación.
Los PBIs prioritarios deben estar situados en la parte superior del listado ya que son los primeros que se desarrollarán. De tal manera que, si al finalizar el sprint no se han completado todos los PBIs, serán los de menor importancia (los de abajo) los que no se hayan terminado.
Para priorizar la importancia de los elementos de la lista se pueden utilizar diferentes técnicas. Una de las más destacadas es el método MoSCoW:
M: Must have, elementos importantes que se deben desarrollar.
S: Should have, elementos importantes que pueden esperar a otra iteración y que no son necesarios en la entrega actual.
C: Could have, elementos que solo se tendrán en cuenta si hay tiempo suficiente. Son elementos deseables, pero no necesarios.
W: Won’t have, elementos que seguro que no dará tiempo a desarrollar.
El tablero Scrum es una herramienta para monitorizar la carga de trabajo y facilitar la sincronización diaria. El tablero se puede dibujar en una pizarra, colgar en un corcho o pegar en una pared. Además, existen numerosas herramientas online que permiten crear tableros Scrum de forma colaborativa y en tiempo real, como por ejemplo la herramienta Trello.
El objetivo de las reuniones diarias es la comunicación del equipo para resolver posibles barreras y tomar decisiones para asegurar la consecución de los objetivos del sprint. En las reuniones diarias cada miembro dispone de unos 2-3 minutos para responder a las siguientes preguntas:
El objetivo de la reunión es el de planificar la cantidad de trabajo que el equipo va a poder soportar durante el próximo sprint.
La reunión de planificación responde a dos preguntas:
El objetivo de la reunión es realizar una revisión del sprint para facilitar la retroalimentación de información y la colaboración.
El objetivo de esta reunión es el de analizar el trabajo realizado por el equipo y reflexionar sobre acciones de mejora.
Es un proceso continuo donde se revisan y examinan diferentes elementos de la Pila de Producto. Este proceso puede hacerse en diferentes sesiones a lo largo del sprint o en una sola reunión. Sin embargo, resulta recomendable que se realice de forma frecuente.