Creada por Jeff Sutherland en 1993, de las metodologías ágiles, es la más utilizada, según una encuesta publicada por VersionOne en 2010 realizada a 4770 entrevistados de 91 países. La misma, revela que el 58% de los encuestados, utiliza Scrum como metodología para la gestión de proyectos de desarrollo de Software.

Hay determinados proyectos de desarrollo que por su propia naturaleza no pueden ser completamente definidos al comienzo del mismo, ya que requieren de un proceso de revisión y modificación constante. En este tipo de proyectos debemos utilizar una metodología de desarrollo ágil, que permita mantener la flexibilidad suficiente para adaptarse a un contexto cambiante pero manteniendo unas reglas de juego que todos los participantes en el proyecto deben conocer.

En este sentido podemos considerar SCRUM como el paradigma de metodología de desarrollo ágil, definiendo la forma de abordar un proceso de desarrollo de software de forma ágil y liviana, a través de la descripción de un conjunto de roles, componentes y organización de la actividad diaria.

La base fundamental de esta metodología consiste en la división del trabajo completo(Product Backlog) en distintos apartados o bloques que pueden ser abordados en periodos cortos de tiempo (1-4 semanas) que se denominan Sprints.

Esta organización del proceso de creación de software permite potenciar los siguientes aspectos:

Ágil: La división del trabajo en pequeñas unidades funcionales (sprints) permite mantener una política de entregas frecuentes de software que ofrecen una visión clara del estado del proceso y permite la introducción de modificaciones.

Simple: Se centra especialmente en facilitar el desarrollo rápido, por lo que su complejidad (por ejemplo desde el punto de vista de la documentación a generar o de la organización de equipos) se ha tratado de reducir al máximo.

Flexible: Todo el desarrollo se contempla como un ciclo de iteraciones continuas de desarrollo, lo que facilita la introducción de modificaciones “sobre la marcha”, mejorando continuamente el proceso.

Colaborativa: El planteamiento, desde el punto de vista de la organización del equipo, resulta bastante horizontal (en contraposición a una organización jerárquica férrea), otorgando a los miembros del equipo de desarrollo una elevado grado de autonomía y auto-organización de su trabajo.

Roles en la metodólogía SCRUM

Es la persona responsable de transmitir al equipo de desarrollo la visión del producto que se desea crear, aportando la perspectiva de negocio. Representa al resto de interesados (Stakeholders, clientes, directivos etc) en el desarrollo del producto. Sobre el Product Owner recae la responsabilidad de definir el conjunto de requerimientos (Product Backlog), de priorizarlos, y de finalmente validarlos.

Conjunto de personas que no forman parte directa del proceso de desarrollo pero que si deben ser tenidos en cuenta, por ser personas interesadas en el mismo, tales como directores, gerentes, comerciales etc. El Product Owner será el encargado de recoger sus opiniones y sugerencias y decidir si las aplica a la definición del proyecto (Product Backlog), así como decidir si invita a alguna de estas personas al proceso de revisión de entregables.

Al igual que los Stakeholders no forman parte del proceso de creación directamente (podrían estar en la fase de revisión de entregables si se considera necesario) Son los destinatarios finales de la aplicación a desarrollar, el público objetivo del mismo. Una vez que la aplicación esté completada serán los que accedan a ella con mayor frecuencia.

En un contexto SCRUM el equipo de trabajo se auto-organiza y gestiona, por lo que no hay que confundir este rol con el de un jefe de proyecto. El papel principal del Scrum Master consiste en garantizar que el equipo de trabajo no tenga impedimentos u obstáculos para abordar sus tareas dentro del proyecto.

Equipo responsable de desarrollar y entregar el producto. Mantiene una organización horizontal en la que cada miembro del equipo se auto-gestiona y organiza libremente en la definición y ejecución de los distintos srpints.

Componentes de la metodología SCRUM

Definición del proyecto (Product Backlog): Consiste en un documento que recoge el conjunto de requerimientos que se asocian al proyecto. Es responsabilidad del Product Owner realizar esta definición y establecer las prioridades de cada requerimiento. Es un documento de alto nivel, que contiene descripciones genéricas (no detalladas), y que está sujeto a modificaciones a lo largo del desarrollo.

Definición del Sprint (Sprint Backlog): Un sprint debe entenderse como un subconjunto de requerimientos, extraídas del product backlog, para ser ejecutadas durante un periodo entre 1 y 4 semanas de trabajo. El sprint backlog sería el documento que describa las tareas que son necesario realizar para abordar los dicho subconjunto de requerimientos.

Ejecución del Sprint: Sería el periodo de entre 1 y 4 semanas (periodo definido previamente en base a las tareas recogidas en el sprint backlog) durante el cual el equipo de trabajo abordaría las tareas de desarrollo correspondientes. Una vez iniciada la ejecución de un sprint definido, este no podrá ser modificado, y en caso de ser necesario introducir cambios estos se harán una vez concluido el periodo a través de la definición de otro sprint backlog.

Entrega: Una vez concluida la ejecución del sprint, se dispondrá de una porción de la aplicación potencialmente definitiva.

Evolución del proyecto (Burn down): Es un documento que refleja el estado del proyecto, indicando el volumen de requerimientos que en ese momento se encuentran pendientes de ser abordados (en el product backlog), los requerimientos que en ese momento se están desarrollando (sprint backlog) y los requerimientos cuyo desarrollo ya se ha completado en su totalidad.

Reuniones de trabajo en un contexto SCRUM

Planificación de sprint: Se realiza al principio de cada ciclo de sprint, y está encaminada a seleccionar el conjunto de requerimientos del product backlog que serán abordado, el equipo de trabajo que será necesario y el tiempo que se estima (entre 1 y 4 semanas) para su desarrollo.

Reunión diaria: Conocida como daily scrum, se realiza al comienzo de cada día en que ese esté ejecutando un sprint. Es una reunión corta (no más de 30 minutos) en la que los integrantes del equipo responden las siguientes preguntas:

¿Qué has hecho desde la última reunión?

¿Qué problemas has encontrado para realizar el trabajo previsto?

¿Qué planeas hacer antes de la próxima reunión?

Revisión de sprint: Una vez concluido el ciclo de sprint se mantiene una reunión en la que se define qué parte del trabajo previsto se ha completado y qué parte permanece pendiente. En cuanto al trabajo completado se realiza una revisión (demo) del mismo al product owner  y otros usuarios que pudiesen estar involucrados.

Retrospectiva de sprint: Es una reunión en la que todos los miembros del equipo realizan una valoración del trabajo realizado en el último sprint, identificando puntos de mejora de cara a los siguientes a realizar. El objetivo principal es introducir un componente de mejora continua en el proceso.