Cómo funciona Scrum

Vamos a hablar hoy de una de las metodologías ágiles que mayor impacto han causado en el desarrollo de software en los últimos años. Seguro que a todos os suena: Scrum.

Como ya sabréis si me leéis habitualmente, no voy a contaros la historia de dónde se originó Scrum ni quién la desarrolló porque esa información, en caso de que tengáis curiosidad, está a al alcance de todos vosotros en internet.

Voy a ser práctico. Esto no es un manual, pero sí me interesa que os enteréis de cómo funciona la base de Scrum. Así podéis valorar si es algo que podría adaptarse a vuestros desarrollos (ya sean internos o externos) y a vuestro equipo. No pretendo llegar más allá, pues eso sería objetivo ya de un curso y no de un simple artículo del blog.

Vamos a ello.

Al igual que Lean, del que me habéis visto escribir en muchas ocasiones, Scrum trata de dejar de lado el modelo clásico de desarrollo en cascada que se basaba en que un cliente te contactaba, te decía lo que quería, firmabáis un acuerdo y tú te disponías a desarrollar el producto y su documentación hasta que al final se lo entregabas y todos contentos. Aquí, al igual que en Lean, lo que interesa es ir paso a paso, trabajando codo con codo con el cliente, ir creando pequeños módulos funcionales y estar preparados para cambios continuos.

Vamos a enumerar los fundamentos principales de Scrum para que, antes de pasar a la chicha, podamos entender un poco qué busca esta filosofía:

FUNDAMENTOS

Los individuos y las interacciones sustituyen a los procesos y herramientas. Scrum enfoca los problemas desde una perspectiva más humana, cercana a los usuarios finales, en vez desde el punto de vista del que contrata el software.
La relación entre nosotros y el cliente se basa en la colaboración contínua, no en el cumplimiento de un contrato.
Desarrollo iterativo e incremental: al igual que en Lean, lo que buscamos es aprender y mejorar el producto poco a poco, trabajando sobre módulos pequeños que irán creciendo según vayamos iterando en el proyecto.
Control empírico: damos por hecho que no podemos predecir todas las variables del proyecto porque dependen de muchos factores que se nos escapan en fases iniciales del proyecto. Por ello, el control sobre el proyecto será empírico, basado en una inspección y adaptación regular que viene dada tanto de los resultados que vayamos obteniendo como del contexto cambiante del proyecto. Eso nos permitirá realizar una mejora contínua del producto.
Priorización de requisitos en base a valor y coste: ¿qué podemos otener y cuánto nos cuesta serán las preguntas que nos permitan decidir qué prioridades les damos a las diferentes tareas del proyecto?
Timeboxing: todas las actividades en Scrum estarán limitadas por un marco de tiempo. No sólo las tareas en sí, sino también las reuniones y cualquier evento de planificación.
El triángulo de hierro: o, más concretamente, las tres claves denominadas alcance, tiempo y coste. Las tres mantienen un equilibrio que nos permite ser óptimos a la hora de trabajar, pero si variamos alguna, esto tendrá consecuencias sobre las otras dos para tratar de mantener la calidad del producto.

Ahora vayamos a la chicha de Scrum.

Normalmente, cuando empiezas a hablarle a alguien de Scrum comienzas explicando los distintos roles que existen en esta metodología y qué funciones tiene cada uno. Personalmente, prefiero empezar explicando los artefactos de Scrum.

Artefactos

Los artefactos son aquellos elementos de la metodología Scrum que nos permiten llevar el control y dirección del proyecto. Si buscáis por internet os vais a cansar de encontrar diferentes definiciones de los que son los artefactos. Lo mejor es definir cada uno y que veais en qué consisten.

Product Backlog (Lista de producto)

El Product Backlog es, por decirlo de una forma sencilla, todo aquello que el cliente quiere que se incluya en el producto. Con ello, tendremos una lista de requisitos que contendrá los siguientes elementos:

El propio requisito: vendrá dado, normalmente, en forma de historia de usuario (luego lo explicamos).
El valor que aporta al cliente este requisito. Hay muchas maneras de exponer este valor (de 1 a 10, por ejemplo).
El coste de conseguir del requisito (en tiempo).
Sprint donde se ejecutará (lo explicamos en el siguiente punto).
Posibles riesgos del requisito y plan para mitigarlo.
Notas o comentarios que consideremos que merece la pena apuntar.

Si tenemos en cuenta el entorno tecnológico en el que nos movemos, podemos decir que el Product Backlog es un artefacto vivo. Lógicamente, a lo largo de la ejecución del proyecto se producen cambios constantemente. ya sea por las condiciones del mercado, la evolución tecnológica o las alteraciones en los requisitos del negocio, o porque el dueño del producto incluye cambios en la lista de producto.

También querría comentar que el Product Backlog puede tener más información, como el status de cada requisito. Esto depende mucho de quién dirija el proyecto y de las características del mismo.

Este es un ejemplo del producto backlog más sencillo que nos podamos encontrar:

Historia de usuario

Ya hemos comentado que el Product Backlog es una lista de tareas/requisitos. Esas tareas estarán expresadas en un formato distinto al habitual, el cual se ha denominado Historias de Usuarios.

Una historia de usuario es una descripción sencilla de una característica, contada desde punto de vista del usuario interesado. Es decir, estamos hablando de algo que un usuario (por ejemplo, un cliente de un eCommerce, el administrador de la tienda…) necesita, y se expone como si lo pidiera dicho tipo de usuario.

El esquema a seguir sería el siguiente:

Como <usuario> quiero <característica> para que <motivo>.

Pongamos ejemplos:

“Como usuario final quiero acceder a un listado donde se puedan ver todas mis compras en la plataforma”.

“Como administrador del sistema, quiero ser capaz de dar de baja a clientes que tienen una tasa de devolución de productos de más del 50%”.

Como veis, ambas historias pertenecen a tipo de usuarios distintos y representan necesidades de cada uno. No hablamos de aspectos técnicos como, por ejemplo, “hay que habilitar un campo en base de datos para poder…”, ni hablamos de ello desde fuera, sino que lo expresamos como si fuéramos una persona normal, ajena al desarrollo

A veces, una historia de usuario incluye criterios de aceptación, cosa que nos ayudará a comprender los pormenores de aquello que nos están pidiendo. Pongamos un ejemplo:

Historia de usuario: “Como usuario final quiero acceder a un listado donde se puedan ver todas mis compras en la plataforma”.

Criterios de aceptación:

“El listado de compras debe incluir producto, precio y fecha de la compra.”
“El listado de la compra debe permitir que el usuario filtre entre fechas.”
“El listado de la compra debe permitir al usuario el pedir una devolución por cada producto comprado.”
Etc, etc

Sprint

El sprint no es sino un ciclo de tiempo o iteracción en el que vamos a desarrollar y entregar algo de valor en el producto. El proyecto se dividirá en sprints, todos de una duración determinada, y en cada uno tendremos que desarrollar o mejorar ciertos módulos funcionales.

¿Cuánto ha de durar un sprint? Depende del proyecto, pero normalmente estamos hablando de dos semanas, cuatro como mucho. Hay proyectos especialmente complejos en los que duran más, aunque personalmente no aconsejo sprints tan largos porque pueden volverse difíciles de gestionar, especialmente si hay desvíos.

Imaginemos que se ha estimado que el proyecto, en su totalidad, puede abarcarse en dos meses. Podríamos planear ocho sprints de una semana cada uno. Eso significa que tendríamos ocho entregas al clientes en el que el producto va mejorando hasta llegar a su finalización.

Una vez tengamos el Producto Backlog, podemos empezar a planear el primer Sprint con todos los requisitos que pensamos desarrollar en el mismo.

Sprint Backlog

Ya hemos hablado del Sprint y del Product Backlog. Ahora toca hablar del Sprint Backlog que, como supondrás, es simplemente un subconjunto de las tareas que pusimos en el Product Backlog y que vamos a realizar en el sprint actual.

Vamos, que simplemente nos ayuda a separar las tareas en sprints de manera de que sea más fácil gestionarlas y observar su evolución.

Si tenemos previstos ochenta tareas o requisitos en total (Producto Backlog), un Sprint Backlog supondrá una parte de las mismas, concretamente las que nos de tiempo a hacer en el sprint que estemos ejecutando en estos momentos.

Scrum Daily Meeting

Todos los días (preferentemente a primera hora) tendremos una reunión entre el equipo de desarrollo y el Scrum Master (luego hablamos de estos perfiles). Esta reunión exige que cada miembro del equipo de desarrollo responda a las siguientes cuestiones:

Qué hice ayer.
Qué tengo pensado hacer hoy.
Qué impedimentos he tenido o tengo para cumplir con los objetivos.

El Scrum Master, del que luego hablaremos, se encargará de dirigir la reunión y de solventar los problemas que salgan en la misma.

El objetivo de esta reunión diaria no es otro que el de impedir que los obstáculos pongan en peligro el sprint actual, así como el de compartir información entre todos los miembros del equipo, haciendo que el conjunto de trabajadores sea consciente no sólo de su trabajo sino también del estado de las tareas de sus compañeros.

Incremento

Cuando el sprint acaba y ya hemos trabajado sobre su backlog, se supone que hemos debido de obtener un resultado trabajando en el mismo. Podríamos decir que este trabajo debe dar como resultado un nueva versión mejorada del producto, que debe estar lista para que el cliente la use e, incluso, llegue a producción si se estima conveniente.

Se le llama incremento pues, según vayamos terminando Sprints, se supone que estamos incrementando el valor del producto.

Estos son los artefactos principales de Scrum. En realidad existen tres más, pero no siempre se usan, aunque yo sí los recomiendo. Estos serían los siguientes:

Definition of Done

Hablamos de un documento donde definimos qué significa que una tarea está terminada. Por ejemplo, una tarea se dará por hecha cuando cumpla estos requisitos:

El análisis de la tarea ha sido terminado.
El desarrollo de la tarea ha sido terminado.
La tarea ha sido dada por buena desde el departamento de calidad.
La tarea ha sido documentada.
Etc, etc.

Definition of Ready

Hablamos de un documento donde definimos cuando un requisito está listo para que el equipo pueda entenderlo, valorarlo e incluirlo en un Sprint. Por ejemplo, este documento podría contener lo siguiente:

La tarea debe tener una complejidad no tan grande como para que no se pueda abarcar dentro de un Sprint.
La tarea no debe tener bloqueos que impidan que se ejecute.
La tarea no ha de tener dependencias de otras tareas que no se hayan abordado todavía.

Burndown Chart

Se trata de una gráfica que representa la diferencia entre las estimaciones que hemos hecho sobre las tareas y el tiempo real que ha llevado ejecutarlas. Eso nos ayuda a ver si estamos bajo los tiempos calculados, si tenemos el ritmo adecuado o si, por el contrario, el proyecto no está llevando más de lo que inicialmente pensábamos.

También nos ayuda a medir mejor los siguientes sprints, pues aprenderemos de los desvíos iniciales.

Roles

Muy bien, ya hemos vistos los elementos que componen Scrum. Tan sólo faltaría hablar de los distintos roles que se van a encargar de hacer que el trabajo salga adelante.

Product Owner

Aquel que representa a los stakholders y usuarios que usan el software. Sería algo así como la persona que entiende qué necesita el negocio, que tenga una buena visión de producto y sea capaz de definir y priorizar los elementos que crean valor. Es decir, es el encargado de realizar lo siguiente:

Definir claramente los objetivos del producto (Product Backlog).
Saber priorizar los desarrollos que persiguen cumplir esos objetivos.
Optimizar el valor de trabajo del equipo de desarrollo.
Asegurar que los objetivos son visibles y claros para los miembros del equipo de desarrollo.

Aquí muchos os quedaréis con la ceja levantada: ¿pero es el cliente? ¿o un jefe de proyecto al uso? Pues la realidad es que podría ser cualquiera de las dos cosas.

A ver, la dificultad de Scrum radica en que si nos dedicamos a desarrollar software para terceros, es muy difícil que el cliente sea capaz de aportar un product owner adecuado, especialmente por la fuerte implicación que debe tener en todo el ciclo de vida del proyecto.

Bajo mi opinión (y bajo mi experiencia), Scrum funciona mejor cuando desarrollamos software para nosotros mismos. Cuando hay perfiles de la empresa que conocen bien el valor del producto que se busca y están 100% comprometidos con las soluciones de desarrollo que se deben realizar. Si no es el caso, o bien el cliente nos trae un product owner apropiado o bien nosotros ponemos a un project manager de nuestra parte que se ha de empapar de las necesidades y objetivos del cliente, necesitando tener un contacto exhaustivo con él y, muy probablemente, entorpeciendo los paradigmas de Scrum.

Vamos a por el siguiente rol.

Scrum Master

Es el responsable de que se realice bien todo el proceso Scrum, cerciorándose de salvar impedimentos y obstáculos. Está situado entre el PO (Product Owner) y el equipo (Team). No es el jefe de proyecto, ni el representante del equipo. No establece prioridades ni es el responsable de la entrega del sprint. Tan sólo se asegura de que usamos la metodología scrum, ayudando tanto al equipo de desarrollo como al producto owner a organizar y guiar todo bajo los preceptos scrum.

Luego, cuando veamos ejemplos más adelante, comprenderéis mejor este perfil.

Equipo de desarrollo

No me gusta la denominación que le da scrum porque da a pensar que estamos hablando de desarrolladores de software, cuando realmente aquí habrá más perfiles implicados (como diseñadores, expertos en UX, control de calidad, etc).

Este equipo se autogestiona, es decir, no tiene líderes ni nadie que les asigne las tareas. Eso sí, son los responsables del desarrollo de cada uno de los requerimientos del Product Backlog en los que hay que trabajar.

Normalmente se dice que el número de personas que componen el equipo ha de ser pequeño, siendo tres el número ideal. Esto, realmente, depende del proyecto en el que estemos, su complejidad, la carga de trabajo y los tiempos de los que dispongamos, aunque es cierto que tenemos un número grande de trabajadores la autogestión es más compleja.

Estos roles van a tener que trabajar bajo unas dinámicas muy concretas basadas en reuniones.

Ciclo de trabajo en Scrum

Ahora, con todo lo que hemos aprendido, vamos a ver, por encima, cómo sería el ciclo habitual de trabajo en un proyecto en el que usemos Scrum.

Llega el cliente (Product Owner) con una lista de requisitos (Product Backlog) del proyecto que quiere abordar. Esta lista no es todo el proyecto, sino los primeros requisitos que se quieren abordar y sobre los que pretendemos aprender.
Se reúne el equipo de desarrollo con el Product Owner y el Scrum Master. Este último únicamente estará allí como facilitador y para garantizar que seguimos la metodología Scrum.
Se decide la duración de los sprints.
En base a las prioridades del Product Backlog, decidimos qué historias de usuario (tareas) vamos a realizar en el Sprint 1, viendo sus historias de usuario y aclarando las dudas sobre las mismas. Estas tareas no pueden ser modificadas durante el sprint salvo por causas de fuerza mayor.
Empezamos a trabajar en las tareas del sprint actual.
Cada día, a primera hora, tenemos con el Scrum Daily Meeting, donde participarán tanto el Scrum Master como el equipo de desarrollo.
Una vez hayamos terminado el primer Sprint, nos reuniremos todos los roles en la reunión de Incremento.
Volvemos al punto 4 y reiteramos todo el ciclo hasta cumplir con todos los Sprints.

Muy bien, ya tenemos cierta base que nos permite comprender Scrum. No voy a engañaros, esto que hemos visto hasta ahora no es sino la punta del iceberg. Scrum tiene mucho más por ofrecer, pero no tiene sentido abordarlo en un artículo de un blog porque esto es más bien material para un curso entero.

Antes de acabar, sí me gustaría hablar de una actividad que se realiza mucho en Scrum (aunque no nació con Scrum, sino antes) y que me sorprendió hace unos años por lo práctica que era. De hecho, recuerdo pensar “¿Cómo demonios no se me había ocurrido a mí antes?”. Se trata del Planning Poker, una técnica que sirve para que el equipo de desarrollo estime la complejidad de los trabajos a los que se va a encontrar.

Como ya he comentado, el Planning Poker no es algo exclusivo de Scrum, pero mi experiencia me dice que los equipos que trabajan bajo Scrum suelen utilizarla, aunque yo recomiendo que se use bajo cualquier metodología de desarrollo que implique a varias personas.

Planning Poker

Vamos a ello. Imaginad que llega el momento de evaluar la complejidad de abordar una historia de usuario. Tenemos, entre el equipo, que consensuar cuánto nos va a costar el realizarla. Para ello, vamos a disponer de barajas de cartas, una por cada miembro del equipo de desarrollo.

Cada baraja, contendrá cartas con los siguientes valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. También existirán dos cartas extra: una con signo de interrogación (?) y otra con signo de infinito (∞).

¿Por qué esos números tan raros? Empieza con algo lógico, como son del 0 al 5, pero luego saltan al 8, al 13 y, finalmente, llegan al 100. Esto es porque estamos siguiendo la secuencia de Fibonacci. Se hace así porque los números de las cartas representan el nivel de incertidumbre que supone una tarea para el equipo. No estamos obligados a usarlas de esa manera, podemos quitar las cartas más altas si vemos que sugieren demasiada incertidumbre.

Es importante que antes de empezar a valorar nada, el equipo se ponga de acuerdo en el significado de cada carta. ¿Qué significa otorgar un 5 a una historia de usuario? ¿Qué significa otorgar un 40?

Si esto se os hace complejo, lo que mejor me funciona a mí con desarrolladores es usar una hoja en blanco y sugerir a cada miembro que escriba en la misma cuántas horas considera que llevaría acabar la tarea.

Además, tenemos las cartas de la interrogación y el infinito. ¿Qué significan? La interrogación significa completa incertidumbre. El infinito significa que la persona que lo usa tiene un total desconocimiento sobre la materia y no puede opinar.

El caso es que, una vez tengamos las cartas, el proceso de validación de la complejidad de la tarea o historia de usuario seguiría los siguientes pasos:

El equipo recibe una historia de usuario. Luego, el miembro del equipo que más sepa sobre ese tema hace una presentación de la misma y permite que el resto de miembros hagan preguntas para aclarar cualquier duda sobre los riesgos de la tarea.
Cada miembro del equipo elige una carta de su baraja y la pone boca abajo. Los demás miembros no deben ver su contenido porque la idea es que no se dejen influenciar.
Una vez acabado el anterior punto, mostramos de forma simultánea las cartas de todos los miembros del equipo.
Si las estimaciones son similares, nos quedamos con la media.
Si hay estimaciones muy altas o muy bajas, se le pide a esos miembros del equipo que expliquen el porqué de las mismas. Una vez aclarado, volvemos al punto 2. Así hasta que estamos todos más o menos de acuerdo y haya un consenso.

Lo mejor de este sistema, a mi juicio, es que los miembros del equipo, de primeras, no se pueden dejar influenciar por sus compañeros. Además, si alguien lo ha visto muy sencillo o muy complejo, tendrá que dar explicaciones al resto de integrantes del grupo, y en muchas ocasiones esto hace que detectemos problemas o atajos que no habíamos visto de primeras.

Y ésta es la idea general de Scrum. Algún purista seguro que ha levantado la ceja en algún momento mientras leía el articulo. Mi objetivo es que alguien ajeno a esta metodología ágil comprenda los fundamentos de la misma, que pueda meditar sobre si es aplicable en su día y a día y, en ese caso, estudiarla más a fondo para implementarla. Esto no es un curso o manual de usuario.