2. Metodología Ágil Scrum Ejemplos
Prácticos
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
INTEGRANTES
● Omar Alexis Sanmartín Tapia
● Ángel Steven Martínez Chamba
● Diana Gabriela González Chillogalli
● Cristian Eduardo Medina Morocho
● Johanna Patricia Montaño Guamán
Loja, Ecuador
4. ¿Cómo nace Scrum?
El concepto de Scrum tiene su origen
en un estudio de 1986 sobre los
nuevos procesos de desarrollo
utilizados en productos exitosos en
Japón y los Estados Unidos.
Los equipos que desarrollaron
estos productos partían de
requisitos muy generales, así
como novedosos, y debían salir al
mercado en mucho menos del
tiempo.
En 2001 un grupo de
personas muy relevantes en
lo que empezaba a ser el
desarrollo ágil escribieron
los valores fundamentales de
los procesos ágiles
En 1993 se realizó el
primer Scrum para
desarrollo de software
En 1995 el proceso fue
formalizado.
Scrum es un proceso o metodología en el que se aplican de manera
regular un conjunto de buenas prácticas para trabajar
colaborativamente, en equipo, y obtener el mejor resultado posible
de un proyecto. Ligero ,Simple de entender, Difícil de dominar,
aunque una vez dominado redunda en grandes beneficios.
5. Aspectos Importantes que debes Conocer sobre Scrum
Es la metodología Ágil más usada a nivel Mundial, seguida de
programación Externa (XP), Kanban.
Según las Estadísticas de Scrum Mundiales, Scrum sigue destacando como lo
más utilizado para llegar a la agilidad (56% de los encuestados).
¿Por qué escogen Scrum ?En este caso, las razones más elegidas han sido (se podían elegir
varias opciones): para acelerar la entrega de productos (59%), permitir gestionar los
cambios en las prioridades (56%), aumentar la productividad (53%) y mejorar la calidad
del software (46%).
7. El Sprint
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el
cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
Durante el Sprint:
● No se realizan cambios que puedan afectar al Objetivo del Sprint
● Los objetivos de calidad no disminuyen
● El alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de
Desarrollo
● Los Sprints están limitados a un mes calendario.
8. Cancelación del Sprint
Las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en otra Planificación de
Sprint para empezar otro Sprint
1. Un Sprint puede cancelarse antes de que el bloque de tiempo llegue a su fin. Solo el Dueño
de Producto tiene la autoridad para cancelar el Sprint
2. Un Sprint se cancelaría si el Objetivo del Sprint llega a quedar obsoleto
9. Planificación del Sprint
Involucrados:
❖ Scrum Master
❖ Product Owner
❖ Equipo de Desarrollo
El Sprint Planning responde a las dos
siguientes preguntas:
1. ¿Qué se puede hacer en este Sprint?
2. ¿Cómo haremos el trabajo elegido?
10. Objetivo del Sprint (Sprint Goal)
Es una meta establecida para el Sprint que puede lograrse mediante la implementación de la
Lista de Producto.
Proporciona una guía al Equipo de Desarrollo acerca de por qué está construyendo el incremento
Se crea durante la Planificación del Sprint.
11. Scrum Diario (Daily Scrum)
El Scrum Diario es una
reunión con un bloque de
tiempo de 15 minutos
para que el Equipo de
Desarrollo sincronice sus
actividades y cree un
plan para las siguientes
24 horas.
Se usa para evaluar el
progreso hacia el
Objetivo del Sprint
Los Scrum Diarios
mejoran la
comunicación,
eliminan la necesidad
de realizar otras
reuniones, identifican
impedimentos a
remover relativos al
desarrollo, resaltan y
promueven la toma de
decisiones rápida
12. Revisión de Sprint (Sprint Review)
Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si fuese necesario.
Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto
El resultado de la Revisión de Sprint es una Lista de Producto revisada
13. Sprint Retrospective
● Es una oportunidad para el equipo Scrum de inspeccionarse a sí mismo y de crear un
plan de mejoras que sean abordadas durante el siguiente Sprint.
● Tiene lugar después de la Revisión de Sprint y antes de la siguiente Planificación de
Sprint.
● El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes
entiendan su propósito
14. Sprint Retrospective
El propósito de la Retrospectiva de Sprint es:
Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña
su trabajo.
● Inspeccionar ● Identificar ● Ordenar
15. Stages of Sprint Retrospective
Establecer el
escenario-
Establecer el
objetivo; Dele
tiempo a las
personas para
que "lleguen" y
se pongan de
buen humor
Recopile datos:
ayude a todos
a recordar;
Cree un grupo
compartido de
información
(todos ven el
mundo de
manera
diferente)
Generar
información:
¿por qué las
cosas
sucedieron de
la manera en
que
sucedieron?
Identificar
patrones
Decida qué
hacer: elija
algunos temas
para trabajar y
cree planes de
acción
concretos
sobre cómo
abordarlos
Cerrar la
retrospectiva:
aclarar el
seguimiento;
Apreciaciones;
Final claro;
¿Cómo podrían
mejorar las
retrospectivas?
16. Product Backlog
● Es una lista ordenada de todo lo que podría ser
necesario en el producto y es la única fuente de
requisitos para cualquier cambio a realizarse en
el producto.
● El Dueño de Producto (Product Owner) es el
responsable de la Lista de Producto, incluyendo
su contenido, disponibilidad y ordenación.
● Una Lista de Producto nunca está completa.
● Es dinámica; cambia constantemente para
identificar lo que el producto necesita para
ser adecuado, competitivo y útil.
17. Sprint Backlog
● Es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint, más un
plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.
● Es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará
parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en
un Incremento “Terminado”.
● Hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para
alcanzar el Objetivo del Sprint.
18. Incremento
El incremento es la suma de todos los ítems del Product Backlog completados
durante un Sprint y el valor de los incrementos de todos los previos. Al final del
Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe
estar en condición de ser utilizado y cumplir con la definición de "Terminado"
del Equipo Scrum.
19. Transparencia de los Artefactos
Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar
el riesgo se toman basadas en el estado percibido de los artefactos.
El Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas si no
hay una transparencia completa.
20. La Definición de “Terminado” (Definition of
“Done”)
Cuando un elemento del Product Backlog de un Incremento se describe como
“Terminado”, todo el mundo debe entender lo que significa “Terminado”. Aunque
esto puede variar significativamente para cada Equipo Scrum, los miembros del
Equipo deben tener un entendimiento compartido de lo que significa que el trabajo
esté completado para asegurar la transparencia.
21. Un caso de estudio ágil: El
Proyecto Havannah
Metodología Scrum
23. El equipo Scrum
● Francisco: Responsable de productos.
● Alberto: Programador.
● Santiago: Programador.
● Carlos: Coach en métodos ágiles.
● Paula: Responsable de pruebas.
● Rosa: Diseñadora gráfica.
● Diana: Analista.
● Laura: Directora financiera.
● Felipe: Director general.
24. Día 1
Reunión con todo el equipo (Todos sin excepción).
Aprender o reforzar el Dominio del Problema mediante un conversatorio.
25. Brainstorming para escribir Historias de
Usuario
● Escribir tarjetas físicas y organizar una reunión de brainstorming para hacer que los miembros
del equipo vayan deduciendo los requisitos.
● Usar Historias de Usuario (User Stories).
● Estructurar el brainstorming por temáticas para no dejar ninguna funcionalidad sin analizar.
26. Una regla básica que hay que recordar
es que las historias de usuario deben ser
independientes, negociables, valorables,
estimables, pequeñas y verificables
(Independent, Negotiable, Valuable,
Estimable, Small, Testable -INVEST-).
28. Cada persona califica la historia de
usuario y se suma a los otros puntajes
del equipo para designar una
calificación general
Estimar el tamaño o complejidad de los
requisitos mediante un juego conocido
como planning poker
Se estima el tamaño y complejidad de
cada historia en unidades llamadas story
points.
29. Descomponiendo las Historias Grandes
● Tendremos que descomponer las Historias de Usuario antes de trabajar en ellas para que quepan
en una iteración
● Cualquier historia de 100 puntos no cabría en una iteración
33. Comprometidos como Equipo con la primera iteración
Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para
planificar la primera iteración y comprometerse como equipo para terminar las historias más
prioritarias.
La analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores.
34. Preparando la Investigación de Mercado
● Diana se puso a preparar la encuesta que debería enviar a los potenciales compradores del juego.
● Como responsable de productos, Francisco tomaría las decisiones finales
● Francisco revisó la tabla que le había pasado Diana.
35. Dos semanas después de escribir y estimar las historias de usuario, el equipo
se reunió en la misma sala con 3 Objetivos.
● Planificar nuestra primera iteración
● Diana expondrá los resultados de la investigación de mercado
● Estimación preliminar del plan de entregas y el calendario.
36. Planificando la Iteración (Iteration Planning)
● El equipo decide que la primera iteración se realizará en dos semana.
● Se escogen las historias de usuario:
Como jugador, puedo jugar contra un motor débil que reconozca solo anillos (8).
Como jugador, puedo jugar contra un motor débil que reconozca solo puentes (5).
Como jugador, quiero que el ordenador reconozca una figura ganadora (2)
Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi
ordenador (3)
● Se suman las horas, que llevará terminar las tareas y el trabajo se divide
entre Paula, Santiago y Carlos
39. Quemando las iteraciones del Proyecto
Havannah
Anteriormente el equipo comenzó la primera iteración de 2 semanas.
Planificaron 4 historias de 18 puntos, también habían previsto que el proyecto
duraría entre 12 y 20 semanas.
El equipo demuestra los resultados de la 1ª semana
40. Planificando la 2ª iteración
Falta de terminar la historia sobre “que el ordenador reconozca una figura
ganadora”,y se dio prioridad a esta iteración, aunque signifique hacer menos
pruebas.
Se comprometieron como equipo a acabar 3 historias de usuario estimadas en 18
puntos:
Como jugador, quiero que el ordenador reconozca una figura ganadora (2)
Como jugador, puedo jugar contra un motor débil que reconozca solo tenedores (8)
Como jugador, me gustaría ser capaz de elegir entre tablero y fichas de madera o metal
(8)
41. 2 Semanas más tarde
Revisión de la Iteración
El equipo demostró buen progreso
otra vez.
El juego está tomando forma.
Completaron todas las historias
planificadas.
Diana tuvo tiempo de completar su
investigación de mercado
42. Revisión del Plan de Entrega (Release Plan)
Descubren dos nuevas posibles funcionalidades
Se dan cuenta que tiene un tiempo de alcance de
finalización justo
Discuten sobre el rango por qué el cuestionario de
Diana no identificó estas funcionalidades
Deciden incluir una funcionalidad nueva al proyecto
de software
Calculan una velocidad actual de 17 puntos (story
point) por iteración
43. El equipo piensa en renunciar a algunas historias de usuario, para cumplir con el tiempo
planificado.
Todo el equipo discute sobre las historias de usuario desde el analista hasta el técnico,
todos estaban muy involucrados desde que comenzó el proyecto
44. Presentación del Plan Revisado
● Presentan el plan Desarrollado por el Equipo de Trabajo a Felipe el Director General.
● Muestran a Felipe un Gráfico Release Burndown Chart para saber el progreso real
de las iteraciones del proyecto
45. 18 semanas más tarde
❖ Se hace una reunión para revisar la última iteración
❖ Originalmente pensaban terminar en 14-20 semanas
❖ Terminaron acabando en 22 semanas
❖ Después de cada iteración, tenían una estimación más precisa de cuántas semanas iban a
tardar.
46. Empresas que Utilizan Scrum
Desde 1995 miles de
proyectos en todo el
mundo han
utilizado Scrum
para el desarrollo
de productos, tanto
en empresas
pequeñas,
“startups” con tan
sólo 3 personas
desarrollando un
producto, como en
multinacionales,
entre las que se
encuentran las
siguientes:
47. Ventajas vs Desventajas
Ventajas Desventajas
Tiempo altamente reducido debido a la
planeación y organización.
Cualquier falta de comunicación y organización
provocará que el modelo falle.
Cualquier falta de comunicación y organización
provocará que el modelo falle.
Depende mucho de la madurez y dedicación de los
involucrados (mucha experiencia).
Crea un producto 100% funcional al terminar
cada Sprint.
Requiere de muchos recursos e inversión.
Alta Involucración del Cliente, por lo que
tiende a estar satisfecho con los resultados.
Mínima Documentación
48. Conclusiones
● La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda
reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los
tiempos y al equipo de trabajo.
● Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no
se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un
proyecto, algo que en otras metodologías es impensable.
● Scrum se basa más en la parte humana, en el equipo, en el trabajo con personas y en las
relaciones humanas como parte fundamental y prioritaria en el desarrollo del software.
49. Conclusiones
● Es importante realizar una buena estimación de la “velocidad” de los incrementos ya que esto
permitirá estimar la culminación en tiempo del proyecto.
● Scrum no dice cómo desarrollar, el equipo de desarrollo escoge la metodología
50. Recomendaciones
● Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta
8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
● Certificarse en el uso de Scrum para conocer más detalladamente esta metodología ágil.
● Para realizar una buena estimación del tiempo de un incremento se debe obtener un pivote, el cual
se puede obtener midiendo los puntos de historia que se puede realizar en la primera iteración.
51. Bibliografía
● CohnCohn, M. M. (2016). Agile estimating and planning. Robert C. Martin Series.
● Fuentes, J. R. L. (2015). Desarrollo de Software ÁGIL: Extreme Programming y
Scrum. IT Campus Academy.
● Un caso SCRUM: El proyecto Havannah extraido de https://blog.pmpeople.org/un-
caso-scrum-el-proyecto-havannah/
● Schwaber, K., & Sutherland, J. (2011). The Scrum guide. scrum. org. October, 2, 17.
