Scrum es un proceso de gestión que reduce la complejidad en el desarrollo de productos para satisfacer las necesidades de los clientes. En el cual, se aplican de manera regular un “conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto”. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Scrum no es un acrónimo, es un nombre propio. Es una implementación del agile manifesto (2001), no parte de él.
Surge ante la necesidad de desarrollar proyectos en un breve periodo de tiempo, optimizando al máximo los recursos y generando el mayor valor de inversión.
Se caracteriza por:
- Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
- Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.
- Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.
Scrum está indicado para proyectos en entornos complejos:
- Cuando se busca obtener resultados pronto
- Los requisitos son cambiantes o poco definidos
- Se precisa de innovación, competitividad, flexibilidad, productividad
Se utiliza cuando:
- No se está entregando al cliente lo que busca
- Las entregas tardan demasiado y los costes se disparan
- La calidad no es aceptable
- Se requiere capacidad de reacción ante la competencia
- La moral de los equipos es baja y la rotación alta
- Es necesario identificar y solucionar ineficiencias sistemáticamente
- Se desea trabajar utilizando un proceso especializado en el desarrollo del producto
Su nombre proviene de una formación de Rugby, ya que en analogía, todos los componentes de un equipo actúan unitariamente para construir software de forma iterativa e incremental.
Scrum mucho más que Roles, Eventos y Artefactos.
Cuando se trata de representar Scrum en muchas ocasiones se usan algunas imágenes que muestran los roles, eventos y artefactos para definir Scrum. Si solo se usan estos elementos o se define Scrum en base a estos elementos se puede estar fomentando un enfoque mecánico de Scrum o un Scrum flácido que finalmente no es Scrum. Estos tres elementos de Scrum son solo una parte de la historia.
Roles de Scrum
Un equipo Scrum se compone por 3 roles fundamentales: el Product Owner, el Scrum Master y el Equipo de desarrollo (3 a 9 miembros).
- Product Owner: Optimiza el valor del producto y gestiona el Product Backlog.
- Equipo de desarrollo: Crea incrementos terminados; se gestiona a sí mismo.
- Scrum Master: Gestiona el proceso Scrum y Elimina impedimentos.
El Product Owner gestiona el todo el flujo de valor del producto, a través del Product Backlog, así como todo lo relacionado con informes, presupuestos y relación con las partes interesadas en el producto (Stakeholders). Es el encargado de establecer las prioridades y es el representante del negocio.
El Scrum Master se asegura de que se lleve el proceso Scrum correctamente y de facilitar la ejecución eliminando impedimentos.
El equipo de desarrollo se encarga de crear un incremento terminado a partir de los Product Backlog items seleccionados durante el Sprint Planning. El aspecto mas importante del equipo de desarrollo es que se auto-organiza y se auto-gestiona.
Artefactos en Scrum
En Scrum existen 3 artefactos que se refieren a elementos físicos que se producen como resultado de la aplicación de Scrum. Éstos son:
- El Product Backlog.- Requerimientos, casos de uso, tareas, dependencias. Es la fuente principal de información sobre el producto, es el resultado del trabajo del Product Owner con los distintos Stakeholders y contiene cualquier tipo de tarea en cualquier formato y su única condición es que esté priorizado con aquellos items que tienen más valor en ese momento.
- El Sprint Backlog.- Es un elemento para visualizar el trabajo del Sprint y está gestionado por el equipo de desarrollo, quien se encarga de mantenerlo actualizado y transparente durante toda la iteración, especialmente a través de los daily Scrums. Permite analizar hasta donde se ha cumplido el objetivo en cada Sprint y que se podría eliminar.
- El Incremento.- Es la suma de todas las tareas, casos de uso, user stories y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software al final del mismo. De esta forma se construye software de manera iterativa e incremental.
Eventos y reuniones Scrum (ceremonias)
Existen 5 eventos para cumplir con el control empírico de procesos:
- Sprint.- Es continuo, es decir, su duración no cambia (iteración definida) y nos permite reducir complejidad y comparar resultados a lo largo de diferentes Sprints. Es un evento que contiene a todos los demás eventos en Scrum y tiene una duración de 30 días o menos (2 semanas promedio).
- Sprint planning.- Reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum completo; sirve para inspeccionar el product backlog y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar.
Se divide en 2 partes, en la primera se define el qué? y en la segunda el cómo?. Puede durar hasta 8 horas para sprints de 30 días y se realiza al comienzo del sprint. - Daily Scrum.- Reunión diaria de planificación de 15 minutos en la que participa el equipo de desarrollo exclusivamente. Durante éste se inspecciona el Product Backlog, y se discuten los impedimentos y el progreso.
En cada reunión cada miembro se hace 3 preguntas:
1.- ¿Qué he hecho desde la última reunión de sincronización para ayudar al equipo a cumplir su objetivo?
2.- ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir su objetivo?
3.- ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro objetivo?
- Sprint Review.- Marca la finalización de un Sprint. En este evento se revisará el incremento terminado, se mostrará el software funcionando en producción y los stakeholders tendrán la oportunidad de hacer cuantas preguntas consideren necesarias. El equipo de desarrollo comenta qué ha ocurrido durante el Sprint, los problemas que se han encontrado, así como soluciones las tomadas, y actualizan a los stakeholders con la situación del equipo.
Se involucra a todo el equipo y tiene una duración de 4 horas para un Sprint de 4 semanas. - Restrospectiva del Sprint.- Ocurre al final del Sprint, justo después del Sprint Review. Su objetivo es reflexionar sobre el último Sprint e identificar posibles mejoras para el próximo. Aquí se analiza qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar.
