¿Por qué Scrum es uno de los frameworks ágiles más populares? Para responder a esta pregunta, mencionaré las principales ventajas de Scrum:
- Funciona bien para proyectos de desarrollo rápidos.
Ayuda a los equipos a lanzar productos de forma rápida y eficiente. - Los sprints cortos permiten realizar cambios en las primeras fases del desarrollo en función del feedback.
- Mayor calidad y productividad.
- Aumenta la satisfacción del cliente/usuario.
- Por supuesto, Scrum también tiene algunas desventajas… ¡Nada es perfecto! Pero conociéndolos, se pueden solucionar estos inconvenientes. Hay un par de desventajas que me gustaría destacar:
Es un reto para equipos grandes.
Como dice Scrum, es sencillo de entender y difícil de dominar. Cuando no se aplica correctamente, pueden aparecer disfunciones o antipatrones.
Scrum es el framework de software más popular para proyectos de desarrollo. Inicialmente se diseñó para lanzar productos de forma eficiente, aunque puede duplicar la producción de cualquier cosa, ya sea de ventas, finanzas, marketing, etc. Scrum simplemente anima a los equipos a trabajar mejor y con mayor calidad.
Ahora vayamos al grano. ¿Qué es Scrum? Como dice Scrum.org, el hogar de Scrum:
«Scrum es un framework ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.»
Valores de Scrum
Antes de empezar a hablar del framework en sí, me gustaría mencionar que Scrum es un conjunto de valores y principios explícitos y transparentes que amplían el poder de Scrum. Por lo general, vienen con un cambio de cultura, cambian la forma de pensar y trabajar creando un gran ambiente de trabajo.
La ilustración anterior contiene los 5 valores: Valor, Enfoque, Compromiso, Respeto y Apertura. Cuando todos esos cinco valores son vividos por los Equipos Scrum, los pilares de transparencia, inspección y adaptación también cobran vida y la confianza aparece en todos los niveles.
Scrum Team
El proceso Scrum
Observa la siguiente ilustración que resume Scrum tal y como lo representan Ken Schwaber y Jeff Sutherland en Scrum.org. En ella se pueden observar los diferentes eventos y artefactos del marco dentro del evento contenedor principal que es el Sprint:
El proceso comienza cuando el Product Owner crea la Visión del Producto hacia donde debe dirigirse el equipo. La visión se desglosa en Historias de Usuario, que son los requisitos que conforman el Backlog de Producto. El Backlog del Producto se divide en el Backlog del Sprint al principio del Sprint para definir el trabajo a realizar por los desarrolladores, más concretamente en el Sprint Planning. En este punto comienza el desarrollo del Incremento del producto o de la nueva funcionalidad que será revisada en la Revisión del Sprint por las partes interesadas para recibir feedback. En cada día del Sprint, los Desarrolladores realizan el Scrum Diario en el que ajustan su plan para cumplir el Objetivo del Sprint. El Sprint se cierra con la Retrospectiva para llevar a cabo la inspección y adaptación que requiere Scrum. A continuación, comienza otro ciclo rápido.
Eventos Scrum
Cada uno de los eventos de Scrum está diseñado específicamente para permitir la transparencia y la inspección requerida en las metodologías ágiles. Se utilizan para crear regularidad y para minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos tienen un límite de tiempo, hay un límite máximo.
- Sprint: Es el corazón de Scrum, el contenedor de los otros eventos. Tiene una duración de entre una semana y un mes.
- Planificación del Sprint: Inicia el Sprint estableciendo el trabajo a realizar en el Sprint. Establece la transformación del «¿Qué?» (visión/objetivo del Product Owner) en el «¿Cómo?» (trabajo de los Desarrolladores). Tiene una duración de 8 horas para un Sprint de un mes y todo el Equipo Scrum tiene que asistir.
- Daily Scrum: Permite a los Desarrolladores inspeccionar el progreso hacia el Objetivo del Sprint y la tendencia del progreso hacia la finalización del trabajo. El Sprint Backlog se puede adaptar según sea necesario. Está limitado a 15 minutos por día a la misma hora y lugar cada día para reducir la complejidad.
- Revisión del Sprint: El objetivo del evento es inspeccionar el resultado del Sprint y determinar futuras adaptaciones discutiendo el progreso hacia el Objetivo del Producto con los interesados. Es entonces más que una demostración, es otra oportunidad para inspeccionar y adaptar. Está limitado a 4 horas en los Sprints de un mes y todo el Equipo Scrum tiene que asistir. El Product Owner es responsable de invitar a los stakeholders.
- Retrospectiva del Sprint: Todo el equipo revisa el Sprint terminado y planea cómo aumentar la calidad y la eficacia, lo que salió mal y bien no sólo en relación con las personas, sino también a los procesos. El equipo pretende identificar las posibles mejoras de los procesos y generar un plan para aplicarlas lo antes posible. El tiempo es de 3 horas para un Sprint de un mes y todo el equipo Scrum tiene que asistir.
Artefactos de Scrum
Los Artefactos Scrum proporcionan la información clave para que el Equipo Scrum y los interesados tengan una comprensión común del producto que se está desarrollando, su valor y las actividades para llevarlo a cabo. Están diseñados para mejorar la inspección y la adaptación.
- Product Backlog: Es una lista única y priorizada de todo lo necesario para construir el producto. Es dinámica, nunca está completa y evoluciona con el producto y su entorno.
- Sprint Backlog: Es un conjunto de los Elementos del Backlog del Producto (PBIs), sin dependencias externas, seleccionados para el Sprint más un plan para entregar el Incremento del producto y alcanzar la Meta del Sprint. Los Desarrolladores prevén qué funcionalidad habrá en el próximo Incremento «Hecho».
Su compromiso es la Meta del Sprint, un objetivo único que proporciona coherencia y enfoque al equipo. Durante el Sprint, los Desarrolladores colaboran con el Product Owner para negociar el alcance del Sprint Backlog sin afectar al Sprint Goal.
- Incremento: Es la suma de todos los ítems «hechos» del Backlog del Producto completados en el Sprint más los ítems de los Sprints anteriores. El Incremento siempre tiene que cumplir con la Definición de Hecho y ser utilizable independientemente de que el Product Owner lo libere o no.
Su compromiso es la Definición de Hecho, una lista de actividades comunes a cada historia de usuario para evaluar si están terminadas. Es un acuerdo definido por la organización o el Equipo Scrum que permite cumplir con la calidad requerida para el producto.
- Gráfico de Burndown: Es un gráfico que da al equipo una visión general del trabajo restante en el Sprint. Guía al equipo hacia la finalización exitosa del Sprint cuando se actualiza cada día.
- Definición de Listo: Es una lista de verificación que se utiliza para evaluar si los PBI’s están listos para el Sprint. En la nueva Guía de Scrum 2020, la alternativa a esto es el refinamiento del Product Backlog que es el acto de añadir detalles, como una descripción, tamaño y orden a los PBI’s. El refinamiento es un proceso continuo, no hay límite de tiempo.
