La metodología Scrum, como aplicarla a tu proyecto

Scrum es la metodología más representativa dentro de las denominadas metodologías Ágiles. Fue descrita por Hirotaka Takeuchi e Ikujiro Nonaka en la década de los ochenta, concretamente en 1986 y formalizada en 1995. Su origen arranca durante un estudio sobre nuevos procesos de desarrollo que llevaban a cabo empresas tan interesantes como Canon, Honda o HP (en EEUU y Japón). Este tipo de empresas realizaban proyectos novedosos y necesitaban apostar por la rapidez en el desarrollo de los mismo. Por tanto, empezaron a implementar unas metodologías de trabajo que combinaban descripciones de requisitos abiertas a modificaciones y equipos multidisciplinares que trabajaban de forma muy estrecha.

Curiosamente, el nombre de la metodología Scrum nace de la comparación que se hizo de esos equipos de trabajo y su forma de relacionarse entre sí, con una melé en el deporte del Rugby. Lo que en inglés de traduce como Scrum.

¿Qué son las metodologías ágiles?

Antes de explicar con detalle la metodología Scrum, conviene entender que son las metodologías Ágiles. Éstas, son un conjunto de metodologías de trabajo que nacieron orientadas a la gestión del desarrollo de Software. Un tipo de “producto” muy distinto a lo que se fabricaba hasta ese momento, con unas características muy específicas y que necesitaba una formulación a nivel de gestión y producción totalmente nueva.

A principio del año 2001, diecisiete expertos en metodologías de desarrollo de software, reunieron las metodologías sobre las que estaban experimentando bajo el paraguas de las “metodologías Ágiles”. Básicamente como propuesta alternativa ante las metodologías tradicionales. En esa catalogación se definieron determinados postulados que diseñaron lo que se conoce como el “manifiesto Ágil”, donde se destacaron algunas valoraciones que se debían anteponer a preceptos anteriores (aplicados a las metodologías tradicionales):

• Los individuos y su interacción deben situarse por encima de los procesos y las herramientas.
• El software que funciona debe estar por encima de la documentación exhaustiva.
• La colaboración con el cliente debe estar por encima de la negociación contractual.
• La respuesta al cambio debe estar por encima del seguimiento estricto de un plan establecido.

Estos postulados son la base sobre la que se edifica este conjunto de metodologías ágiles. Están adaptadas a la nueva forma de entender el trabajo, donde priorizar la comunicación con el cliente, el trabajo en equipo, el ritmo de trabajo constante, etc… marcaran las guías de funcionamiento. Lo que generó unos principios básicos que ayudan a definirlas:

• La máxima prioridad es satisfacer al cliente a través de entregas continuas y tempranas de un producto de calidad.
• El personal de gestión y el de producción deben trabajar conjuntamente y de manera continua. Con objetivos comunes y homogéneos para todos.
• Los cambios son bienvenidos desde el inicio de un proyecto, e incluso en etapas avanzadas. Con la finalidad de ofrecer al cliente la posibilidad de situarse con una ventaja competitiva.
• La base de un proyecto es contar con trabajadores motivados a los que facilitar apoyo y el entorno apropiado para desarrollar su trabajo. La confianza en que desarrollaran su trabajo es fundamental.
• Lo mejor para comunicarse dentro del equipo es la conversación cara a cara.
• La medida principal de progreso deberá estar basada el producto funcional.
• Todos los miembros del proceso deben ser capaces de mantener un ritmo de trabajo constante, y de forma indefinida.
• Las mejores ideas nacen de equipos que se auto-organizan.

Principios básicos de la metodología Scrum

La gestión ágil de proyectos con la metodología Scrum, tiene una serie de principios y normas básicas, que tiene el objetivo de servir como marco de referencia durante el desarrollo de un proyecto. De hecho, estos principios hacen relación al ciclo de un proyecto (una característica de la metodología Scrum). Son los siguientes:

• Desarrollarse a partir de Sprint o ciclos.
• Estos ciclos deben ser de una duración determinada a lo largo del proyecto.
• Los grupos de trabajo deben ser auto organizados.
• Se deben realizar diarias con los miembros en pie.
• Se debe realizar una demo del trabajo realizado al final de cada iteración.
• El aprendizaje debe ser continuo.

Llevar estos principios a la práctica no acaba de ser siempre posible, depende de la tipología del proyecto y de los recursos disponible. Por tanto, lo importante, no es tanto seguirlos al pie de la letra, sino entender una serie de líneas de actuación, como estas:

El ciclo de vida debe estar compuesto por iteraciones: El rasgo principal de las metodologías ágiles es estar abiertas a los cambios. Dividir el ciclo de vida de un proyecto en iteraciones ofrece la opción de introducir cambios y modificaciones al inicio de cada una de las partes del proyecto.

Se deben reducir los riesgos lo antes posible: Planificar un proyecto ofrece múltiples complicaciones. Una de ellas, es la de determinar qué acciones pueden implicar un riesgo y cómo influyen estos riesgos en el resto de acciones. Cuanto antes se evalúe este riesgo, menor será el impacto.

Priorizar las tareas que impliquen valor para el negocio del cliente: A la hora de ejecutar un proyecto con una metodología Scrum, hay que centrarse en las tareas que impliquen negocio para el cliente. De esta forma el cliente tendrá un producto funcional en primer término, con el que empezar a generar negocio.

La duración de las iteraciones se debe mantener a lo largo del proyecto: Con toda seguridad es una de las complicaciones más habituales. Sin embargo, la rigurosidad en los “tiempos” de las distintas iteraciones en las que se divide el proyecto es básica. Analizar cuando no se han calculado bien los tiempos, ofrecerá información valiosa para futuros proyectos.

Durante una iteración (una parte del trabajo), el tiempo destinado, el coste y la calidad son valores fijos: Lo que debe variar en cada parte del proyecto, son los distintos hitos a conseguir, el tipo de trabajo o las funcionalidades. Pero nada de esto debe afectar a costa de reducir la calidad del trabajo, ni reducir o aumentar el tiempo destinado, ni aumentar la presión sobre los trabajadores para terminarlo.

Mantener las entregas (hitos) o entregables al cliente: Estas metodologías nacen para ofrecer al cliente una colaboración más allá de la relación contractual. Mantener las entregas al cliente y recibir un feedback puede mejorar considerablemente la ejecución del mismo.

Dar valor a las personas implicadas en los proyectos: Scrum es una metodología que se construye en base a equipos auto organizados. Es decir, la confianza en la capacidad de los miembros del equipo debe ser máxima. Estos equipos son multidisciplinares para poder tener experiencia en cada tipología de situación planteada.

Crear un entorno de comunicación adecuado: En este caso no solo es importante permitir la comunicación entre los miembros del proyecto, sino poder interactuar con el desarrollo del propio proyecto, los distintos hitos, interacciones, flujo de trabajo y sobre todo el feedback del cliente. Para ello, la metodología Scrum propone una serie de acciones y reuniones cíclicas donde mostrar todos estos aspectos.

Los equipos de un proyecto se deberán organizar en base a las necesidades del cliente: Obviamente no todos los proyectos requieren de las mismas capacidades, lo que implica que los equipos no tienen por qué ser los mismos. Adaptar los equipos a las necesidades de los clientes es otro rasgo importante de esta metodología de trabajo.

Inconvenientes de esta metodología

Las metodologías de trabajo (las ágiles y las más tradicionales), no son universales. Lo que implica que no todas son útiles para mejorar la gestión de todo tipo de proyectos. Por tanto, analizar bien las características de la metodología Scrum, implica determinar las ventajas o puntos fuertes, pero también los inconvenientes que van asociados a ella:

• El concepto clave de esta metodología es la de adaptarse a las necesidades de los clientes, lo que implica estar dispuesto a realizar cambios en cualquier parte del proyecto. Y esto, está muy relacionado con la complejidad que tiene el dar un proyecto por terminado. Hay que poner una fecha de finalización del trabajo para que el cliente entienda que ese proyecto ha terminado y lo que eso supone.
• Otra de las características importantes es el compromiso de los equipos y puede ser un problema si alguno (o varios) no está igual de comprometido con el proyecto.
• Es una metodología perfecta para equipos pequeños. Scrum es una metodología pensada para equipo de un máximo de 8 miembros. En grupos mayores la coordinación es más compleja.
• Requiere miembros con experiencia en todos los equipos. Y la capacidad de que lo miembros sepan adptar el rol que le toque en cada iteración.
• Solo funcionará si el Scrum master confía plenamente en el equipo asignado al proyecto.

Los Roles de una metodología Scrum

En esta metodología se definen tres roles básicos que deben estar presentes en todos los proyectos y cuya comunicación debe ser directa, cara a cara.

Scrum Master: Es el responsable de que las “normas y principios” de esta metodología se cumplan y que se apliquen correctamente en el proyecto. Sus responsabilidades son muy importantes y pasan por: colaborar en la organización autónoma del equipo, ayudar al equipo a ser productivo, presentar al cliente la metodología Scrum y sus beneficios, eliminar impedimentos, facilitar la comunicación en todos los niveles, manejar el entorno del proyecto y asegurarse del compromiso del equipo con esta metodología.

Product Owner: Es la figura responsable del proyecto en cuestión. Su objetivo es el de dar al cliente lo que espera, así como controlar que los entregables del proyecto sean en fechas y con las funcionalidades más valiosas para el cliente. Algunas de sus responsabilidades más importantes son: crear una visión del proyecto y un plan de entregas, determinar el valor del negocio en las funcionalidades, definir los criterios de aceptación de cada hito u obtener feedback por parte del cliente.

El equipo: Deben estar constituidos por miembros con capacidades complementarias y multidisciplinales. También deben ser auto organizativos y aprender a gestionarse de forma autónoma. El equipo tiene que estimar el esfuerzo necesario de cada interacción o hito para una correcta planificación, así como desarrollar un plan de ejecución y producir entregables periódicos.

Artefactos de Scrum

Aunque la metodología Scrum tiene como objetivo simplificar el trabajo en determinado tipo de proyectos, necesita determinados controles, en forma de ayudas o “Artefactos”, para que el proyecto tenga garantías de éxito. Los Artefactos de Scrum están pensados y diseñados para garantizar la transparencia de información clave en la toma de decisiones. El Scrum Master hará uso de estos Artefactos para gestionar el trabajo de una manera adecuada.

Product Backlog: Se trata de una lista compuesta por fichas, que recogen todo lo que necesita el producto, para satisfacer las necesidades potenciales del proyecto y del cliente. Estas tarjetas llevan información específica de los distintos hitos y se colocan en función de las prioridades (o del orden dentro del proyecto). Es un artefacto de ayuda al Product Owner donde se delimitan las “historias de usuario” y tiene las siguientes características:

• Debe ser una lista única por producto sobre la que el Product Owner es el único responsable. Varios equipos Scrum pueden trabajar en el mismo producto, y compartir esta lista, pero no los atributos y elementos de la misma.
• Es algo vivo, mientras ese proyecto esté en activo, deberá cambiar en función del feedback del cliente (o el mercado, la tecnología, etc…).
• Estas historias reúnen varios atributos (elementos), como son:
  • Título.
  • La descripción.
  • El orden.
  • La estimación.
  • El valor.
  • La prioridad.
  • Requisitos mínimos.

Sprint Backlog: Toda la organización derivada del Product Backlog, resulta también de utilidad para el equipo, ya que al final tienen que trabajar sobre historias de usuario. Sin embargo, la visión del equipo, aun debiendo tener siempre una visión global del producto final, debe estar centrada en la iteración en curso para no tener distracciones del objetivo parcial que se ha marcado a sí mismo. Esta la misión del Sprint Backlog, la de reflejar estas iteraciones específicas, denominadas Sprints.

• Un Sprint es cada una de las iteraciones realizadas en la metodología Scrum. La duración de los mismos debe ser lo suficientemente larga como para que se puedan realizar, pero no tanto como para que un posible cambio sea un gran problema. El tiempo de duración dependerá del proyecto y los requerimientos del Sprint, pero entre 2 y 4 semanas es una duración correcta. Cada Sprint se puede dividir en distintas fases.
• El Sprint Planning es la reunión inicial que dará comienzo a cada Sprint. El Product Owner selecciona los hitos o historias de usuario que forma parte de ese Sprint (basándose en las prioridades del cliente). Este ejercicio implica:
  • Reunión de los participantes.
  • Selección de las historias de usuario.
  • Exposición de las mismas.
  • Evaluación de la importancia de las mismas (el peso de cada una de ellas).
  • Una vez determinado el peso de las mismas se van asignando hasta que el equipo ya tenga trabajo suficiente.
  • Una vez delimitados los hitos de este Sprint, se descomponen estas historias de usuario en tareas independientes con el objetivo de trabajarlas de forma autónoma.
• El Daily Sprint es la reunión diaria que se realizará durante todo el desarrollo del Sprint. En este encuentro los miembros del equipo comparten el progreso de las distintas tareas. Debe ser una reunión corta, que implica respetar determinadas normas:
  • Se realiza cada día (a la misma hora y lo antes posible dentro de la jornada laboral).
  • Asisten todos los miembros del equipo y el Scrum Master (como mínimo).
  • La duración máxima es de 15 minutos, y los asistentes deben estar en pie.
  • Durante esta reunión se trata de ver si: se han terminado las tareas, que tareas se terminan en el día de la reunión y determinar si hay elementos que bloqueen el avance en alguna tarea.
• El Sprint Review hace referencia a la última reunión, una vez finalizado el Sprint. Se hace la entrega de las tareas y una demostración de las funcionalidades desarrolladas. Asisten el Scrum Master, el Product Owner y el cliente. Es el momento de ver el progreso del proyecto y el momento de detectar posibles mejoras respecto a los requisitos iniciales.
• Durante la reunión del Sprint Retrospective, analizaremos lo sucedido para corregir errores en el futuro. Es un análisis con los miembros del equipo y el Scrum Master, donde se ponen en valor los puntos fuertes o débiles del equipo. Tratando los siguientes temas:
  • Destacar lo que ha ido bien.
  • Destacar lo ha ido mal.
  • Cosas que hay que corregir (según lo visto en los puntos anteriores).
  • Cosas que hay que dejar de hacer.

Por tanto, este artefacto es análogo al anterior y en él, el Product Manager, únicamente trasladará lo que el equipo deba terminar en ese Sprint. Este Sprint Backlog suele estar integrado en otro artefacto, la Scrum Board.

Scrum Board: Por definirlo de una forma muy sencilla, es la pizarra que refleja el estado concreto de un Sprint en cada momento. Debe contener información relativa al:

• Trabajo que hay que hacer (la información del Sprint).
• Trabajo pendiente dentro de ese Sprint.
• Trabajo en realización (lo que se está haciendo).
• Trabajo terminado.

Burndown Chart: Se trata de una gráfica que refleja la visión global de la velocidad de cada Sprint respecto al proyecto completo. Por tanto, debe contener información cruzada respecto a la relación entre los días destinados a un Sprint (los puntos del mismo) y las horas globales de un proyecto. Es una de las herramientas más importantes para no perder de vista la situación global de un proyecto (algo fácil de hacer una vez que se está centrado en un Sprint concreto). De hecho, ofrece información muy valiosa para ajustar proyectos futuros, para calcular las horas globales o los días específicos destinados a cada Sprint.