SCRUM Framework

SCRUM es una metodología ágil y este tipo de metodologías colocan a los individuos e interacciones por encima de los procesos y herramientas; se enfocan en un software que funcione, por encima de tener una documentación extensiva; le da importancia a la colaboración con el cliente, por encima de la negociación contractual y estimula la respuesta al cambio, por encima del seguimiento de un plan.

SCRUM es un framework para la gestión de proyectos ágiles bajo un enfoque iterativo e incremental (sprints) para los proyectos que involucre un desarrollo de software. Es ligero, fácil de entender y extremadamente difícil de dominar.

SCRUM considera la comunicación tanto a nivel individual como de equipo ya que valora el consenso y promueve la auto-organización del equipo. Ante el cambio constante en los requerimientos, es muy eficaz ya que incorpora mecanismos de gestión de cambios que implican un menor esfuerzo. Incrementa la productividad y la calidad del producto. Se reducen o estabilizan los costos de los productos. Genera una alta satisfacción del cliente

Elementos de SCRUM

Los elementos principales de SCRUM son:

• Roles: Scrum Master, Product Owner y el Scrum Team
• El backlog
• Los sprints
• Las ceremonias o reuniones de SCRUM

Roles

La comunicación y la auto-organización juegan un factor muy importante dentro de la administración de los proyectos que usan SCRUM.

La gestión del proyecto es compartida por los roles del Scrum Master y el Product Owner.

El Scrum Team tiene el empoderamiento para decidir qué y cuánto pueden ellos hacer para un sprint o para toda la iteración del proyecto.

SCRUM Team

• El equipo estará completamente dedicado al proyecto, recibiendo la definición del trabajo a realizar
• Trabajan de forma cohesiva
• Persiguen un objetivo en común, el objetivo del sprint (sprint goal)
• Se adhieren a las normas y reglas establecidas
• Tienen respeto por cada uno de sus compañeros
• Son responsables de las entregas (releases)
• Tienen empoderamiento
• Trabajan de forma auto-organizada y autónoma
• Tienen habilidades balanceadas
• Descomponen los requisitos, crean tareas, las estiman y se las distribuyen. Realizan estas acciones sobre los requisitos contenidos en el sprint en curso.
• Llevan a cabo reuniones diarias del sprint
• Aseguran que al final del sprint, la funcionalidad sea entregada
• Actualizan el estado y el esfuerzo restante de las tareas para crear y/o actualizar el diagrama de cumplimiento del sprint

SCRUM Master

• Su principal función es asegurarse que el Scrum Team se adhiere a la teoría, reglas y prácticas del SCRUM
• Es parte del SCRUM Team y es un guía-servidor del equipo
• Protege al equipo de obstrucciones e interferencias externas
• Funge como agente de cambio y hace los cambios a los procesos para maximizar la productividad del equipo
• Entrena al equipo en SCRUM
• Facilita la comunicación entre el Team y el Product Owner

Product Owner

• Administra tanto al proyecto como al producto
• Representa al cliente y sus requerimientos del producto, busca maximizar su valor.
• Asegura entregar el trabajo correcto y a tiempo
• Es el único que provee de trabajo al Scrum Team con base a las prioridades y atiende sus dudas técnicas, revisando la funcionalidad y entregables.
• Administra los releases del producto
• Trabaja de forma coordinada con el Scrum Master durante todo el proyecto
• Asegura que el Scrum Team tiene un correcto y unificado conocimiento de los requerimientos
• Valida y acepta lo entregado en cada sprint
• Define los objetivos del sprint

Backlog

• Es simplemente una lista de las cosas necesarias para hacer dentro del proyecto
• Los elementos de que se compone puede ser de naturaleza técnica o bien representada en requerimientos conocidos como historias de usuario
• La planificación del sprint está basada en el contenido del backlog de acuerdo a la estrategia del equipo
• Todo lo que se ingresa en el backlog debe contener prioridades y un orden de acuerdo a la estrategia
• El nivel de detalle estará de acuerdo a que tan próximo esté a realizarse esa tarea
• El backlog tiene vida, se actualiza constantemente

User Stories o Historias de Usuario

• Todo lo que se ingresa en el backlog es frecuentemente escrito como una historia de usuario
• Es una descripción breve acerca de alguien que usa el producto
• Su ventaja es que se enfoca en qué es lo que el usuario necesita o quiere, sin entrar en los detalles
• Contiene un nombre, una breve descripción, criterios y condiciones de aceptación
• Cuantas menos palabras tenga, mejor
• Su lenguaje es natural y puede ser entendido por personas técnicas y no técnicas
• Se deben evitar tecnicismos en la historia de usuario.
• El SCRUM Team luego desglosará cada historia en tareas más técnicas y relacionadas con las acciones a realizar para su completitud

Estructura

• Como un [actor], [quiero | debo], [acción] para [logro]
• Como un [actor], [quiero | debo], [acción]

Ejemplo

Como [cliente habitual] quiero [ver productos relacionados] para [ver si hay otros productos de la tienda que me puedan interesar]

Criterios de aceptación (Acceptance Criteria)

• Los productos relacionados estarán ordenados por valoración y margen de beneficio
• Cuando el usuario haga clic en un producto relacionado, se abrirá el detalle de ese producto
• Etc.

Sprint

• Es un ciclo o iteración que comprende un periodo de tiempo
• El periodo de duración suele ser de 2 semanas, pero cada equipo lo ajusta. Hay sprints de 1 semana, de 3 semanas, de 1 mes.
• Las tareas a realizar durante un sprint forman parte del sprint backlog y deben ser ejecutadas en el orden o prioridad que defina el Product Owner o el Scrum Team
• Al final de cada sprint se entrega una parte funcional del producto que puede ser utilizada o testeada por el cliente.

Ejecución del Sprint

• Cada miembro toma una tarea del sprint backlog y la coloca en la columna de Tareas Iniciadas
• Cuando una tarea finaliza se pasa a la columna Hecho
• Es responsabilidad del equipo decidir la mejor asignación de una tarea basado en habilidades y responsabilidad.

Ceremonias o reuniones

Sprint Planning o Planificación del Sprint

• Se realiza antes de iniciar cada sprint
• El Product Owner define el objetivo del sprint
• Con base a este objetivo, los items más importantes del backlog son propuestos por el Product Owner y se negocia con el Scrum Team.
• Se pueden revisar las estimaciones de cada tarea a realizar durante el sprint
• Se pueden incluir items de menor prioridad si se justifican y si el Product Owner está de acuerdo
• El equipo establece tantos items del backlog como cree que puede atender en el siguiente sprint, según su capacidad
• Se establecen todas las tareas que deben completarse en el siguiente sprint
• Los miembros del equipo eligen sus tareas y estiman la duración

Daily Meeting o Daily Standup

• Es una reunión diaria de análisis de estado que dura unos 15 minutos
• Debe ocurrir todos los días a la misma hora
• Participan todos los miembros del equipo y contesta 3 preguntas: ¿Qué hiciste ayer?, ¿qué te propones hacer el día de hoy? ¿Qué está impidiendo tu progreso?
• Se actualizan los tiempos restantes de las tareas

Sprint Review o Revisión del Sprint

• Se realiza al final del sprint
• Durante esta reunión, el Scrum Team muestra qué elementos del backlog se completaron durante el sprint
• El Product Owner inspecciona las entradas del sprint backlog implementadas y acepta la solución o añade nuevas historias en el backlog para adaptar la funcionalidad
• La funcionalidad no completada durante el sprint, se devuelve al backlog general y se vuelve a priorizar la lista completa de tareas.
• Se saca del backlog aquella funcionalidad que el equipo haya completado inesperadamente
• Como consecuencia de esta reunión se puede cancelar el proyecto y no autorizar más sprints, autorizar la aceleración del progreso autorizando a equipos adicionales a trabajar en el backlog o continuar trabajando en el próximo sprint.

Sprint Retrospective o Retrospectiva del Sprint

• Se realiza al finalizar el sprint.
• Participan el Scrum Team y el Scrum Master
• Todos reflexionan sobre los siguientes aspectos: ¿Qué funcionó bien y debemos seguir haciendo? ¿Qué no funcionó bien y debemos dejar de hacer? ¿Qué debemos mejorar?
• Este tipo de reunión es bien importante y hace que se pueda cumplir con el proceso de adaptación que promueve SCRUM
• Como consecuencia de la reunión se debe desarrollar un plan de acción concreto para mejorar el proceso

Conclusiones

• Scrum es un modelo empírico y adaptable para cada equipo
• La mejor metodología es la que se adapta a nuestra operación, los sprints deben adaptarse a nuestro ritmo de trabajo.
• Una vez que se encuentre el mejor lapso de tiempo para los sprints, hay que respetar su duración para conseguir medir la velocidad del equipo
• Se deben seguir todas las reglas y prácticas de SCRUM
• Se debe ser disciplinado
• Se debe dar empoderamiento a los equipos

Escrito por: Yanet Morales Ramirez

Editado por: Nelaida Calleja Chico