Después de todo lo que hemos visto en relación a un proyecto Scrum, hoy quiero hacer un esquema que te aclare todos esos conceptos. En los últimos nueve post te he hablado de los distintos elementos de esta metodología. Hoy vamos a enlazarlos para que no te queden dudas de su operativa. Verás cómo todo encaja.
La filosofía de un proyecto Scrum
La metodología Scrum busca gestionar los proyectos de manera más eficiente que por medios más tradicionales. En definitiva, esto es de lo que tratan las metodologías ágiles. En su caso Scrum a través de la experiencia persigue el cumplimiento de tres principios que facilitan esa mayor eficacia.
La transparencia de todo el entorno del proyecto. El hecho de que todos los implicados conozcan cada uno de los aspectos del proyecto favorece el ahorro de tiempo y costes.
La inspección continua es lo que permite que se esté siguiendo el camino hacia el objetivo deseado.
La adaptación permite que, si es necesario, se cambien los requerimientos del producto a entregar para que éste sea lo más competitivo posible.
Los elementos de un proyecto Scrum
En un proyecto Scrum debes tener muy claro con qué elementos cuentas y su papel en el desarrollo de la actividad.
El equipo Scrum
Ten en cuenta que el equipo es lo más importante en las metodologías ágiles. En este caso no lo es menos. El equipo Scrum tiene unas características muy particulares. Es multidisciplinar y autoorganizado. Esto quiere decir que es capaz de gestionar su trabajo de manera eficaz y no depende de terceras partes para realizar su cometido. Por otra parte, todos los miembros mantienen una actitud colaborativa, ya que, el resultado del proyecto es responsabilidad de todos.
En un proyecto Scrum tu equipo debe estar compuesto por entre 5 y 9 miembros. Y te encontrarás con tres roles claramente diferenciados.
Por una parte, el Product Owner es el cliente o quien representa al cliente. Sabe qué producto final desea obtener y cómo debe ser.
En segundo lugar, el Scrum Master es el líder del equipo. Dirige, organiza y da apoyo al resto del equipo.
Por último, el Development Team es el grupo de profesionales que elaboran el producto que propone el dueño del producto.
Los eventos de Scrum
Cuando te hablo de eventos me refiero a cada una de las acciones que se repiten cíclicamente en un proyecto. Los eventos están definidos de manera muy concreta para favorecer la eficacia de esta metodología. Así se consigue cumplir con los tres pilares de la filosofía Scrum.
El principal de los eventos es el Sprint. Se trata de cada uno de los ciclos de trabajo que permite alcanzar productos intermedios.
Después tienes las reuniones de Scrum. Con ellas se facilita el conocimiento de la situación del proyecto por parte de todos los medios, la transparencia.
Los artefactos de Scrum
En un proyecto Scrum vas a trabajar con tres artefactos que sirven como herramienta para orientar el proyecto en la dirección correcta.
El Product Backlog es la lista de aquellos requerimientos que el cliente desea que cumpla el producto final. En cada Sprint el dueño del producto entrega el Sprint Backlog que incluye lo que se debe conseguir al finalizar el Sprint. El incremento es ese producto intermedio que puedes entregar a tu cliente y es plenamente operativo.
Desarrollo de un proyecto Scrum
Como ya sabes un proyecto Scrum se compone de una serie de ciclos de una estructura similar.
Antes del Sprint
El Product Owner elabora el Product Backlog, esa lista en la que se relacionan aquellas especificaciones, características o detalles que debe cumplir el producto final. Una de las ventajas de esta metodología es que esta lista no es cerrada y las necesidades o deseos del cliente pueden variar a lo largo del proyecto.
En una reunión llamada Sprint Planing Meeting, en la que se reúne todo el equipo Scrum, se decide qué se debe obtener en el primer Sprint, será el Sprint Goal. En esa reunión se elabora el Sprint Backlog, otra lista que reúne las características que debe cumplir el incremento que se va a entregar. Además se planifica el trabajo que va a desarrollar el Development Team.
El Sprint
A partir de ahí comienza el Sprint, de 2 a 4 semanas de trabajo en las que el equipo de desarrollo realiza las acciones que dan como resultado un producto intermedio entregable y plenamente operativo. Cada día se realiza el Daily Scrum, una minireunión de no más de 15 minutos. En ella el Scrum Master con el Development Team evalúan el desarrollo del Sprint y ponen en común todo aquello relevante que pueda afectar al equipo.
Después del Sprint
Transcurrido el plazo acordado finaliza el Sprint. Se entrega el producto intermedio y se realiza una tercera reunión, el Sprint Review. En esta reunión todo el equipo Scrum valora el resultado alcanzado en el Sprint. A partir de este punto el Product Owner podrá actualizar su Product Backlog y decidir qué quiere alcanzar en el siguiente Sprint.
Pero antes de iniciar un nuevo ciclo falta una última reunión, el Sprint Retrospective. Aunque no lo parezca, esta reunión puede ser de gran utilidad. En ella el Scrum Master y el Development Team tratan de analizar los aspectos positivos y negativos del Sprint anterior. El objetivo es identificar las mejores prácticas que se deben aplicar en la operativa para mejorar en eficiencia y calidad.
Desde este punto comienza un nuevo Sprint, otro ciclo. Esto se repetirá tantas veces como sea necesario hasta el final del proyecto.
Valoración de la Metodología Scrum
La metodología Scrum es una metodología Ágil y eso implica que los proyectos en los que se aplica alcanzan un nivel de eficiencia mayor. Es cierto que está pensada para el desarrollo de proyectos tecnológicos. Sin embargo, si tu proyecto se ve afectado por cambios en los requerimientos, si por su complejidad no puedes hacer una planificación inicial, tal vez sea una opción de gestión adecuada.
Hay un detalle de Scrum que podría parecer contradictorio pero en realidad no lo es. Una de las premisas en que se basa es la adaptabilidad. La estructura en ciclos cortos permite que se puedan incluir tantos cambios en el objetivo final como desee el cliente. Sin embargo, Scrum es como es. No admite cambios, si no sigues sus reglas, si modificas su estructura no es Scrum.
“El joven conoce las reglas, pero el viejo las excepciones”.
Oliver Wendell Holmes