SCRUM es una metodología que enfatiza una relación de valores y prácticas relativos a la gestión de proyecto por encima de los orientados a requisitos, la implementación etc. Y puede ser utilizado conjuntamente con otras metodologías, por ejemplo con XP.
Personalmente he vivido una interesante integración con KANBAN, que explicaremos en siguientes artículos.
SCRUM fue creado por Jeff Sutherland y Ken Schwaber con una primera publicación en 1995. Siendo una metodología dirigida por 5 valores principales: compromiso, foco, franqueza, respeto y coraje. El ciclo de vida de un proyecto SCRUM se divide en iteraciones de 30 días denominadas SPRINT, con reuniones de diarias para tener seguimiento del progreso y posibles bloqueos del equipo. (Daily SCRUM)
En un proyecto SCRUM tenemos 4 roles diferenciados:
- Product owner. Representante de los promotores ante el equipo, todo requisito debe canalizarse a través de él. Se encarga de mantener el product backlog (relación de tareas pendientes) así como priorizar, decidir el contenido de cada SPRINT y revisar el producto con el resto de promotores después de cada SPRINT (Stakeholders)
- Scrum master. Se trata de un desarrollador a tiempo parcial y un leader el resto del tiempo, que trabaja para salvaguardar el progreso y el seguimiento de las prácticas SCRUM.
- Scrum team members. Responsables de entregar evoluciones de producto potencialmente entregables en cada SPRINT, así como actualizar la el backlog de tareas o el WBS.
- El resto.
Imagen extraída de Wikipedia
WBS - Work breakdown Structure, es un modo de romper unidades de trabajo, en otras unidades de menor coste temporal, para facilitar la gestión y minimizar la falta de control sobre el progreso. Es muy recomendable romper las historias de cliente (unidades funcionales) en tareas de menor tamaño, siempre alineados con que las unidades de trabajo supongan un incremento de valor del producto en sí mismas, o como mínimo, que la suma de unidades de trabajo durante un SPRINT lo supongan, para facilitar la medición del grado de avance al final de cada SPRINT.
Lista de reglas de SCRUM:
- Cada SPRINT debe dar como resultado un código totalmente funcional, testeado que ofrezca valor tangible al cliente
- Al inicio de cada SPRINT se debe celebrar una Sprint Planning Meeting
- El equipo colectivamente decide la cantidad de trabajo a incluir en cada SPRINT
- El product owner prioriza el product backlog
- El product backlog puede ser incrementado o re-priorizado en cualquier momento
- Una vez el SPRINT ha sido iniciado solo el equipo puede añadir trabajo al backlog del SPRINT
- Un breve Scrum meeting se celebra cada día donde los miembros del equipo comparten su progreso del día anterior, los objetivos del día actual y si tienen algún obstáculo en el camino
- Solo pigs (término asociado a Product Owner, Scrum master y Scrum team members; El resto son denominados chickens) pueden hablar durante el meeting diario
- El resultado del sprint debe ser demostrado en una Sprint Review Meeting a celebrar a la finalización de cada SPRINT
- No se debe dedicar más de dos horas al Sprint Review Meeting
Podéis encontrar una guía en castellano aquí.
Saludos,
No hay comentarios:
Publicar un comentario
Muchas gracias por hacerme llegar tu opinión.
--
Ivan Peralta Santana
LinkedIn | http://www.linkedin.com/ivanperaltasantana
Agility management blog | http://www.useragiledevelopment.com/
Personal blog | http://www.iperalta.com/
Twitter | http://www.twitter.com/jokulsarlon
Photography web | http://www.ivanperaltasantana.com/
Flickr | http://www.flickr.com/ivanperaltasantana