Metodología Agile: Scrum (1/3)

 Metodología Agile: Scrum

Scrum,  es una forma de auto-gestión de los equipos de desarrolladores. El grupo de desarrolladores 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, organizando las tareas y enfocándolas, 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 (XP).

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 (Product Owner), debe crear una lista de funcionalidades o características (Product Backlog) que quiere que se implementen en el programa.

Estas funcionalidades deben ser tangibles, y «cuadran» muy bien con los User Stories de la programación extrema (XP).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 podrá ordenarla y deberá mantenerla ordenada, de forma que las primeras funciones del Product Backlog se harán antes.

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 desarrolladores (Scrum Team) que van a participar en el proyecto. Esta reunión recibe el nombre de Sprint Planning Meeting.

En esa reunión se elige un plazo de tiempo (en función del proyecto, necesidades y demás):

  • Una semana
  • 15 días
  • Un mes

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 una semana?. 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 «al 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 una semana?. 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 desarrolladores y el jefe qué va a entrar o no en una semana. El jefe puede decidir el orden, intercambiar tareas, modificarlas o partirlas, pero los desarrolladores tienen la última palabra de cuánto tiempo necesitan para cada tarea. El tiempo necesario para todas las tareas seleccionadas no puede superar una semana.

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 una semana vamos a entregar al Product Owner una versión del programa que tenga TODAS las tareas del Srpint Backlog funcionando.

Anuncio publicitario

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Blog de WordPress.com.

A %d blogueros les gusta esto: