Universidad Católica de La PlataFacultad de Ciencias Exactas e IngenieríaIngeniería de Sistemas I

Metodología Scrum

Es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para la empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación. Con Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración. Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades.  Beneficios

Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.

Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.

Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.

Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.

Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.

Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada. 

Desarrollo:

1. Product Backlog y Product Owner

Al empezar el proyecto, el responsable del proyecto, que conoce lo que tiene que hacer, que no va a codificar y que está en contacto más estrecho con el cliente , debe crear una lista de funciones que quiere que implemente el programa. Le pondremos un nombre en inglés al cliente, que es el que le da Scrum, le llamaremos Product Owner.

Las funciones de la lista deben ser algo "tangible", es decir, que si nuestro programa implementa una de esas funciones, un usuario que use nuestro programa puede ver que esa función está implementada. Estas funciones "cuadran" muy bien con las historias de usuario de la programación extrema.

A esta lista, también le daremos un nombre en inglés decidido por Scrum y la llamaremos Product Backlog.

A lo largo del proyecto se podrán añadir más funcionalidades a esta lista, o quitarlas o modificarlas. Sólo el Product Owner -el jefe- podrá ordenarla y deberá mantenerla ordenada, de forma que las primeras funciones del Product Backlog -la lista- se harán antes.

2. Sprint Planning Meeting y Spring Backlog

El primer día que empecemos a trabajar en el proyecto, se hace una reunión, en la que estarán el Product Owner y los programadores -Scrum Team- que van a participar en el proyecto. Esta reunión también tiene nombre decidido por Scrum y se llama Sprint Planning Meeting.

En esa reunión se elige un plazo de tiempo que Scrum aconseja que sea un mes. De todas formas, en función del proyecto, necesidades y demás, puede elegirse otro plazo: una semana, dos semanas o lo que sea. Nunca debería ser un plazo muy largo.

Una vez elegido ese plazo de tiempo, se toma el Product Backlog y se van mirando las tareas empezando por la primera. Se pregunta al Scrum Team ... ¿puede la primera tarea estar hecha dentro de un mes?. El Scrum Team la examina, descompone en subtareas si hace falta, estiman el tiempo que tardarán en hacerla y dicen "sí". Si dicen que no, habrá que descomponerla en tareas más sencillas hasta que digan el menos que sí a una de ellas.

Se toma la segunda tarea y se pregunta al Scrum Team ... ¿puede estar la primera y la segunda en un mes?. Vuelven a estimar y dicen "sí".

Se repite el proceso con las siguientes tareas hasta que el Scrum Team empiece a dudar si sí o si no va a estar todo eso. Si el Product Owner quiere que esté alguna tarea que no va a estar, puede cambiarla por otra que sí esté, o "reducir" el alcance de una de las que ha entrado para que entre otra. En fin, este es el momento de "negociar" entre los programadores y el jefe qué va a entrar o no en un mes. El jefe puede decidir el orden, intercambiar tareas, modificarlas o partirlas, pero los programadores tienen la última palabra de cuánto tiempo necesitan para cada tarea. El tiempo necesario para todas las tareas seleccionadas no puede superar el mes.

Una vez llegado a un acuerdo, esas funcionalidades se pasan a una nueva lista, llamada Sprint Backlog. Hemos quedado todos de acuerdo que dentro de un mes vamos a entregar al Product Owner una versión del programa que tenga todas las tareas del Srpint Backlog funcionando.

3. Daily Scrum Meeting y Scrum Master

Después de la reunión anterior en la que se decide el Spring Backlog, vamos todos a trabajar. A partir de ese día, todos los días, preferiblemente a primera hora, el Scrum Team se reúne y cada uno contesta a tres preguntas:

¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Qué ayuda necesitas?

Uno de los programadores hace de moderador de la reunión y se le llama Scrum Master. Este no es jefe de los demás, simplemente debe encargarse de que la reunión no dure más de un cuarto de hora /media hora y de que las ayudas/ problemas que plantean los programadores se resuelvan a lo largo del día. El Product Owner también debería colaborar en eso de "quitar obstáculos", estar disponible para consultas, etc. La ayuda necesaria puede ser de cualquier tipo: "no conozco este tema y necesito alguien que me ayude", "necesitaría tener datos en la base de datos para hacer pruebas", "necesito tener mi PC conectado al osciloscopio", etc. En fin, cualquier cosa que uno de los programadores considere que le facilita el trabajo -y que sea razonable, que hay de todo-.

En esta reunión también se aprovecha para volver a estimar el tiempo de las tareas en curso. Puede que una tarea, el primer día, se dijera que se iba a tardar ocho horas. Resulta que hoy, después de haber trabajado el día de ayer en ella, sale un problema inesperado y hoy decidimos que vamos a tardar 10 horas más en resolverla, se apunta y listo.

Después de varios días de reuniones se verá rápidamente de esta forma si vamos según lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, además, puede verlo, sobre todo si vamos registrando en algún gráfico el día a día indicando cuantas horas suponemos que nos quedan para acabar en el eje vertical y los días en el eje horizontal. El gráfico de la figura, por ejemplo

Aunque en teoría Scrum dice que la lista de tareas a hacer Sprint Backlog no se toca, hay mucha gente que decide añadir o quitar tareas en caso de ir adelantados o retrasados. Lo importante es entregar a final de mes una versión con determinadas funcionalidades implementadas y no irse ni demasiado allá ni demasiado acá en ese mes.

4. Sprint Review y Sprint Retrospective

Ya ha pasado el mes de plazo. Si estimamos bien, tenemos nuestra versión del programa con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizás esta versión tenga alguna funcionalidad menos o alguna de más.

Ahora se hace una reunión de aproximadamente un par de horas, llamada Sprint Review, a la que acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otra persona interesada en el producto. En ella el Scrum Master enseña la versión a los demás. Los asistentes pueden dar opiniones, posibles mejoras, etc.

Inmediatamente después, se hace otra reunión, llamada Sprint Restropective, en la que el Scrum Master, el Scrum Team y el Product Owner analizan qué cosas pueden mejorarse a la hora de trabajar para el siguiente Sprint, si la comunicación ha sido bueno o debe mejorarse, si hay algún problema que deba subsanarse. En general, con un ambiente distendido y espíritu constructivo, ver cómo se puede mejorar la forma de trabajo en el Sprint Backlog del siguiente mes.

Y vuelta a empezar, otro Sprint Planning Meeting para ver qué funcionalidades va a tener la nueva versión del mes que viene, un nuevo Sprint Backlog

Consideraciones:

Como vemos, Scrum no dice nada de si hacer o no hacer diseño, si hacer o no hacer Test Unitarios, si hacer o no hacer documentación, si trabajar en parejas o no, etc, etc. Scrum únicamente nos indica cómo conseguir que todos trabajen con el mismo objetivo, a corto plazo y deja bastante visible como avanza el proyecto día a día.

Lo ideal es complementarlo con una metodología de desarrollo software ágil, como la programación extrema. El Product Backlog pueden ser perfectamente las historias de usuario, el trabajo se puede hacer perfectamente en parejas, con sus test unitarios previos al código, etc.

También podría utilizarse algún otro tipo de metodología. Por ejemplo, pueden dedicarse unos días al principio de mes para diseñar cómo se van a implementar las funcionalidades de ese mes, re-diseñar lo que ya hay hecho para acoger lo nuevo, en cada tarea puede considerarse el tiempo necesario para generar la documentación que se pida de forma que la cada tarea tardará un poco más por la documentación asociada y ese tiempo se tiene en cuenta en la estimación, etc, etc.