SCRUM

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 -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 daScrum, lellamaremos 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ésdecidido 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.
Sprint Planning Meeting y Spring Backlog
El primer día que empecemos a trabajar enel 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 sisí 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, perolos 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 TODASlas tareas del Srpint Backlog funcionando.
Daily Scrum Meeting y Scrum Master
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:
¿Qué hiciste ayer?
¿Qué vas a hacer hoy?
¿Qué ayuda necesitas?
Uno de los programadoreshace 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...