Tutoriales
Enlaces
Licencia
Esta obra está bajo una licencia de Creative Commons.
Para reconocer la autoría debes poner el enlace https://old.chuidiang.org
Scrum, más que una metodología de desarrollo software, es una forma de auto-gestión de los equipos de programadores. Un grupo de programadores deciden cómo hacer sus tareas y cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la misma dirección, con un objetivo claro.
Scrum permite además seguir de forma clara el avance de las tareas a realizar, de forma que los "jefes" puedan ver día a día cómo progresa el trabajo.
Sin embargo, Scrum no es una metodología de desarrollo, puesto que no indica qué se debe hacer para hacer el código. Debería, por tanto, complementarse con alguna otra metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la programación extrema.
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 -o sea, el jefe-, debe crear una lista de funciones que quiere que implemente el programa. A este jefe, como nos suele caer un poco mal, le pondremos un nombre en inglés, 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, como la ha hecho el jefe, 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.
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 raro decidido por Scrum y se llama Sprint Planning Meeting.
En esa reunión se coje 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. Supongamos que hacemos caso a Scrum y elegimos un mes.
Una vez elegido ese plazo de tiempo, se coge 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 coge 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.
Después de la reunión anterior en la que se decide el Spring Backlog, nos vamos todos a trabajar. A partir de ese día, TODOS los días, preferiblemente a primera hora, el Scrum Team se reune y cada uno contesta a tres preguntas:
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. No pasa nada, 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.
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 .... y ¡¡ a currar !!.
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.