Está en la página 1de 25

METODOLOGÍA

SCRUM
SCRUM es un marco de trabajo
para el desarrollo y mantenimiento
de productos complejos o sencillos. • Muy fácil de entender
Es una de las metodologías ágiles • Es muy liviano muy ligero.
más populares y usadas en
proyectos de software, aunque una
Puede ser un poco complejo de implementar
de sus ventajas es la adaptabilidad
si no se siguen bien sus reglas
lo que la hace ideal para trabajar en
diferentes contextos o a cualquier
área de conocimiento.

2
3
Los roles se dividen en 2 grupos: cerdos y gallinas, esto surge en el chiste
sobre un cerdo y una gallina y su intención de poner un restaurante.

4
Son personas que están comprometidas con el Aunque no son parte del proceso de Scrum, es
proyecto y el proceso de Scrum. necesario que parte de la retroalimentación dé la
salida del proceso y así poder revisar y planear
cada sprint.

Es la representación del cliente dentro del


equipo de trabajo, su principal responsabilidad
es expresar claramente la necesidad del cliente
dentro del Product Backlog.
Es el destinatario final del producto.

Es el responsable de asegurar que el Scrum


es entendido y realizado al asegurarse de
que el equipo trabaja ajustándose a la Las personas a las que el proyecto les
teoría, prácticas y reglas de Scrum. producirá un beneficio. Participan
durante las revisiones del sprint.

Se compone de las personas responsables de dar


cumplimiento a los SPRINT, son un equipo Toma las decisiones finales participando en
autogestionado y organizado. la selección de los objetivos de los
requisitos

5
Va a definir un artefacto,
un documento que tiene
la lista completa de
funcionalidades o
necesidades del cliente.
Este artefacto de llama
“Product BackLog”.

6
Aquí se va a plasmar toda
esa cantidad de
necesidades, todas esas
ideas, requisitos que hará
cumplimiento a la
solicitud del cliente.

Posteriormente le va a
manifestar esas
necesidades al equipo
de desarrollo del Scrum
Master. Esto lo hacen en
una reunión llamada
Sprint Planning Meeting

7
Aquí se va a planear como se
va a dar solución a una 1er
fase de ese producto final.

Como resultado del


Sprint Planning Meeting
vamos a obtener una
lista de funcionalidades
llamadas Sprint BackLog

8
Éstas son tomadas del Product BackLog,
consiste en ese conjunto de requisitos que se
deben de construir en un tiempo de 1 – 4
semanas. Ese tiempo es llamado el SPRINT.

9
• Éste es el corazón del SCRUM.
Ya que el SPRINT corresponde al proceso
de desarrollo o construcción de la
necesidad del cliente, pero divididas en
un módulo funcional o de un producto
incremental.
El tiempo de desarrollo debe ser entre
1 – 4 semanas, dependiendo de la
complejidad de las funcionalidades
definidas en el Sprint BackLog.

10
En el SPRINT intervienen:
• SCRUM MASTER
• TEAM DEVELOPMENT
El TEAM DEVELOPMENT.
Son los encargados de desarrollar y
construir esa necesidad que define el
SPRINT.

El SCRUM MASTER.
Se va a encargar de ayudar y facilitarle las
cosas para que el Team Development
pueda trabajar

Esa persona también puede ser parte del


Team, sin embargo como SCRUM MASTER
va a ser el moderador para que este Team
entienda muy bien cual es la necesidad y
les pueda ayudar para el cumplimiento de
su objetivo.

11
Otras de las actividades más
representativas del SCRUM son los Daily
Scrum o las reuniones diarias.

Esas reuniones tienen como objetivo


hacer seguimiento diariamente a todos
los procesos que tengamos dentro del
SPRINT, de esa manera se reúne el SCRUM
MASTER y el TEAM DEVELOPMENT y se
van a hacer una serie de preguntas muy
puntuales:

• ¿Qué se hizo ayer?


• ¿Qué se está haciendo hoy?
• ¿Qué va a hacer mañana?
• ¿ Qué problemas encontró?

✓ Eso se le va a preguntar a cada persona dentro del equipo de


desarrollo.
✓La idea de ésta reunión es que sea muy corta, que no sea
mayor a 15min. y que diariamente se pueda tener un contexto
global de cual es el estado actual del SPRINT.
✓Esto facilita bastante el seguimiento del proyecto y la toma de
decisiones
12
Estas reuniones por lo general se realizan
frente a un tablero, donde se definen
todas las actividades, todas las tareas
asociadas a los miembros del equipo.

SCRUM utiliza un tablero tipo KANBAN,


que agiliza bastante el proceso de
entendimiento del SPRINT que se está
trabajando y así se garantiza el principio
de transparencia para que todos los
miembros del equipo puedan ayudar,
puedan aportar.

✓El éxito del SPRINT depende de todo el equipo de desarrollo,


lo que se busca es de que todas las personas puedan tener
asignaciones de las cuales sean responsables.

✓De que si yo termino mi asignación pueda ayudarle a otro


compañero para poder dar cumplimiento al objetivo del
SPRINT y a los tiempos definidos.

13
Al finalizar el SPRINT se hace una
nueva reunión que le llama SCRUM
TEAM , allí van a estar involucrados
tanto el SCRUM MASTER, puede
estar el PRODUCT OWNER y el
EQUIPO DE DESARROLLO; para
verificar el cumplimiento de las
metas con los objetivos del SPRINT
en cuestión.

Y así garantizar la
entrega del producto al
cliente final

14
Después de haber entregado el
producto se hace una reunión que
se llama la RETROSPESCTIVA DEL
SPRINT.
En esta se busca analizar cuáles son
los resultados del SPRINT anterior
para poder encontrar:

• Alguna problemática
• Falencias en el proceso
• Mejoras
…que puedan aplicar al siguiente
SPRINT.

Y así al final del SPRINT, automáticamente debemos iniciar un nuevo


SPRINT tomando otras de las funcionalidades del Product BackLog para
sacar nuevamente el Sprint BackLog e iniciar otra vez el proceso hasta
tener un nuevo producto funcional.
15
La idea es de que este producto funcional se le pueda entregar al cliente
para que el pueda interactuar y pueda ir viendo el avance del proyecto
hasta que al finalizar todos los SPRINT se tenga el producto terminado.

16
LA GESTIÓN DE UNA BODA

17

Product Backlog inicial, es el paso el cual estará vivo durante el desarrollo del proyecto, usando la
herramienta de brainstorming para producir un conjunto de ideas (User Stories).
¿Qué User Stories conseguimos definir al final del proceso tratándose de una ceremonia
religiosa?
✓ Iglesia
✓ Fotógrafo
✓ Flores
✓ Traje de novio
✓ Vestido de novia
✓ Anillos
✓ Restaurante
✓ Música
✓ Regalos

18

Una vez definido el Product Backlog inicial, se tiene que dar forma a las funcionalidades del producto
para saber en qué se tiene que trabajar exactamente para cada funcionalidad, pero para ello
primero se necesita definir los roles que cada uno va a tener y de esta forma diferenciar los flujos de
trabajo.

Scrum Team = Prometida,


Product Owner = Prometida Scrum Master = Prometido
prometido, padres, madres y
hermanos

Ahora que ya sabemos quién será quién, el Product Owner con la ayuda del equipo y del Scrum
Master en definir las User Stories del Product Backlog incluyendo los criterios de aceptación para
cada una de ellas.
19
Como prometida de la boda, quiero que mi vestido de novia sea muy bonito de
forma que quede a todos con la boca abierta.
Criterios de Aceptación:

✓ El vestido tiene que costar menos de 2.000 € (IVA incluido)


✓ Tiene que ser de color blanco.
✓ Tiene que ser un vestido de manga corta.
✓ Tiene que ser de palabra de honor.
✓ La cola del vestido debe tener al menos 65cm de longitud
✓ Se permite que los arreglos del vestido cuesten como mucho 150 €

Como prometidos de la boda, quiero que el banquete sea espectacular de forma


que todos los invitados salgan satisfechos de la comida.
Criterios de Aceptación:

✓ El gasto medio por comensal no debe superar los 160 € (IVA incluido)
✓ Tiene que tener canapés, entrante, primer plato, segundo plato, postre, café y
chupito y bebida.
✓ El vino de la comida tiene que ser un Vegasicilia del año 2003.
✓ El segundo plato tiene que ser salomillo de buey hecho en horno de leña.
20

Una vez definido el Product Backlog inicial y especificados sus criterios de aceptación, tenemos
que priorizar las User Stories y para ello, necesitamos que el Product Owner fuera capaz
de priorizar las funcionalidades:
✓ Iglesia
✓ Restaurante
✓ Vestido de novia
✓ Traje de novio
✓ Fotógrafo
✓ Flores
✓ Anillos
✓ Música
✓ Regalos

21

Ahora es responsabilidad de todo el equipo, Scrum Master e incluso del Product


Owner de estimar, por orden de prioridad, las User Stories y de esta forma tener una
visión de cuán difícil será completar esa funcionalidad en un sprint.

22

Ya estamos preparados para empezar a trabajar, así que decidimos que se realizaran sprints
de 3 semanas.
Se hace un pequeño sprint planning en el que vamos comprobando qué
eventos/impedimentos/tareas…, es decir, el tiempo que se tiene que dedicar al proyecto;
durante ese período de tiempo para poder acometer más funcionalidades o no.
Una vez hecho el sprint planning, se empieza a trabajar en el sprint backlog durante ese
período de tiempo, partiendo cada user story en tareas que se puedan acometer de forma
individual.

23

Una vez finalizada el sprint, hacemos retrospectiva de esas 3 semanas y vemos qué tal ha
ido en todo: qué hemos completado, qué no hemos completado y por qué, qué
impedimentos nos hemos encontrado y sobre todo, cómo mejorar para el
siguiente sprint.

24
👍
Gracias!

25

También podría gustarte