Scrum no es una metodología, la metodología en la cual se basa Scrum es Agile. En cambio, Scrum es un framework de trabajo ágil orientado al desarrollo de software (y el más utilizado en la actualidad).

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 la selección de las mismas tiene origen en un estudio de la manera de trabajar en equipos altamente productivos.

Scrum es un modelo de referencia que define un conjunto de prácticas, roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. 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á recomendado 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 costos se disparan
  • La calidad no es aceptable
  • Se requiere capacidad de reacción ante la competencia
  • La motivación 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

Roles de Scrum

Un equipo Scrum se compone por 3 roles fundamentales: el Product Owner, el Scrum Master y el Equipo de desarrollo (de 3 a 9 miembros aproximadamente).

  • Product Owner
  • Equipo de desarrollo
  • Scrum Master

El Product Owner gestiona el 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 a partir del Product Backlog presentado por el Product Owner, se compromete en la Sprint Planning con una serie de features/requerimientos a trabajar, los cuales deben encontrarse desarrollados, probados y finalizados al finalizarse el Sprint (iteración de trabajo). 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 del uso de Scrum. Éstos son:

  • El Product Backlog: Requerimientos/caracteristicas a trabajar, las cuales generan valor de producto. 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 el listado de requerimientos/características que el equipo se compromete a trabajar durante el Sprint (iteración). 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 todo el Sprint (iteración), especialmente a través de la daily. Permite analizar hasta donde se ha cumplido el objetivo en cada Sprint y que se podría eliminar.
  • El Incremento de producto: Es la suma de todo lo desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software funcionando 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 entre 2 – 4 semanas (dependiendo la madurez de la organización).
  • 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.
  • Daily: Reunión diaria de planificación de 15 minutos en la que participa el equipo de desarrollo exclusivamente. Durante este encuentro se revisa el Sprint Backlog, y se discuten los impedimentos y el progreso. En cada reunión cada responde a 3 preguntas:

1.- ¿En que estuve trabajando?

2.- ¿En que voy a estar trabajando durante el día de hoy?

3.- ¿Qué impedimentos tengo que me imposibilitan avanzar/cerrar la tarea en la cual me encuentro trabajando?

  • Sprint Review + Demo.- Marca la finalización de un Sprint. En este evento se revisará el incremento de producto 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.
  • Restrospectiva del Sprint.- Ocurre al final del Sprint. 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.

Latest news

Check our latest articles to keep you posted!

Como les contamos en la primera parte, el primer webinar […]
El jueves pasado realizamos nuestro primer webinar, enfocado en herramientas […]
En Adviters fomentamos uno de nuestros valores principales a cualquier […]