Metodología Scrum para el desarrollo de software ágil

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.

1. Desarrollo ágil de software 

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.

2. Principios de la metodología ágil

Las metodologías ágiles se basan en una serie de principios:

1. Satisfacción del cliente mediante la entrega temprana y continua de software de valor.
2. Gran aceptación y respuesta al cambio de los requisitos definidos.
3. Entrega frecuente de software que funcione, normalmente en periodos de dos semanas hasta dos meses.
4. Trabajo conjunto entre el equipo de negocio y los desarrolladores.
5. Creación de equipos motivados y respaldados.
6. Comunicación cara a cara.
7. Equipos auto-organizados.
8. Reflexión continua de formas para mejorar la efectividad y realizar los ajustes necesarios.

3. Metodología Scrum

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.

4. Roles – Scrum

4.1. Product Owner

• Es el más cercano al negocio/cliente.
• Decide qué desarrollar y qué no.
• Define buenas historias de usuario.
• Gestiona el Product Backlog y se asegura que esté claro para todo el equipo.
• Encargado del retorno de inversión del proyecto (ROI).
• Define el producto mínimo viable (MVP).
• Valida las entregas (sprint review).

4.2. Scrum Master

• Planifica la implantación de Scrum y se asegura de que todo el equipo lo entienda y lo aplique correctamente.
• Ayuda a resolver los impedimentos que surjan durante el sprint.
• Crea un buen ambiente en el equipo y favorece la auto-organización.
• Protege al equipo de interferencias externas.
• Ayuda al product owner a comprender la metodología ágil.
• Se asegura de que se celebren las reuniones y de que se cumpla el objetivo en el tiempo establecido.

4.3. Development team

• Compuesto de 5 a 9 componentes.
• Auto-organizado y auto-gestionado.
• Decide la cantidad de trabajo a realizar en un sprint (sprint planning).
• Estable, motivado y dedicado.
• Se obtienen mejores resultados cuando trabajan en la misma localización física.

5. Artefactos – Scrum

5.1. Product Backlog 

El product backlog o pila del producto es una lista ordenada y priorizada de funcionalidades definidas por el cliente.

5.2. Product backlog items 

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.

5.3. 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:

• Como <tipo de usuario>
• Quiero <necesidad a implementar>
• Para <funcionalidad>

Un ejemplo aplicado podría ser:

5.4. Estimación 

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:

• Esfuerzo: Cuánto tiempo llevará su desarrollo.
• Complejidad: Cómo de difícil es.
• Incertidumbre: Grado de inseguridad para su implementación.

5.5. Planning poker o Scrum poker

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.

5.5.1. Cartas basadas en la serie de Fibonacci

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:

1. Cada miembro dispone de un mazo de cartas. Cada componente dispone de un mazo de cartas con puntuación basada en la serie Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.
2. Cliente o Product Owner lee la historia. Las historias de usuario son explicadas por el cliente o por el Product Owner. El equipo de desarrollo debe realizar todas las preguntas necesarias para la estimación.
3. El Development Team selecciona las cartas. Cada miembro del equipo de desarrollo selecciona una carta, sin mostrársela al resto.
4. Se muestran las cartas. Todas las cartas se levantan a la vez.
5. Argumentación de las diferencias. Se argumentan las diferencias entre las estimaciones más extremas.
6. Nueva estimación. Se vuelve a realizar una nueva estimación hasta que se consiga un consenso

5.5.2. Cartas con talla de ropa

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.

5.6. Orden de los PBIs

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.

5.7. Tablero Scrum

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.

6. Ceremonias o reuniones

6.1. Daily meeting (reunión diaria)

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:

• ¿Qué hiciste ayer?
• ¿Qué harás hoy?
• ¿Tienes algún impedimento?

6.2. Sprint Planning (planificación del sprint)

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: 

• ¿Qué puede entregarse en el sprint? El product owner detalla las funcionalidades que hay que desarrollar en este sprint.
• ¿Cómo se realizará el trabajo? El equipo de desarrollo estudia las historias de usuario y estima el esfuerzo que será necesario. Para ello, se suele usar la técnica de planning poker.

6.3. Spring Review (revision de sprint)

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.

6.4. Sprint Retrospective (retrospectiva del sprint)

El objetivo de esta reunión es el de analizar el trabajo realizado por el equipo y reflexionar sobre acciones de mejora. 

6.5. Refinement (refinamiento)

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.