METODOLOGIA AGIL - SCRUM

3. En el año 1986 Takeuchi y Nonaka publicaron el
artículo “ The New Product Developroent Game”, el
cual dará a conocer una nueva forma de gestionar
proyectos en la que la agilidad, flexibilidad, y la
incertidumbre son los elementos principales.
Takeuchi y Nonaka se fijaron en empresas
tecnológicas que estando en el mismo entorno en el
que se encontraban otras empresas, realizaban
productos en menos tiempo, de buena calidad y
menos costes.

4. DEFINICIONES BASICAS

5. Según la definición que nos proporciona
PMI en su guía PMBOOK, un proyecto se
podría definir como “un servicio temporal
que se lleva a cabo para crear un
producto, servicio o resultado único”.
Diremos entonces que un proyecto tiene
un inicio y un fin, el fin se tienen que
alcanzar dentro del tiempo fijado.
PROYECTO

7.  Entorno: No sufre modificaciones de forma
rápida, sino que se alargan en el tiempo.
 Cliente: Tiene muy claro que es lo que se
necesita, sabe transmitirlo y nosotros
entendemos perfectamente sus necesidades.
 Equipo: Disponemos del equipo de
profesionales necesarios para poder atender
a esta necesidad y además sabemos cómo
resolverla.
 Fases: Las fases se harían de una forma
lineal, organizada y no surgiría ningún
problema durante su realización.

8.  ¿Qué trabajo se va a realizar en cada fase?
 ¿Quién participara en cada fase?
 Las fases se definirán de forma secuencial, es decir, que una fase no comienza hasta que termina
la otra. Suelen contener una serie de hitos o tareas que marcan los momentos más importantes
en el desarrollo del proyecto.

9. Definiremos la metodología
como aquella disciplina que
indicara que métodos y técnicas
hay que usar en cada fase del
ciclo de vida de desarrollo del
proyecto.
METODOLOGIA

10. Las metodologías agiles surgen como una alternativa a las
metodologías tradicionales las cuales, son rígidas para las
actuales características del mercado. Años atrás la
evolución de los productos era lenta y se producía siempre
en un entorno estable en el que apenas había variaciones.
Hoy en día sin embargo el entorno en el que se mueve el
software es demasiado inestable y cambiante por lo que
estas metodologías no se adaptan, ya que hay que reducir el
tiempo de creación pero son dejar de todo la calidad del
software.
METODOLOGIAS
AGILES

11.  Se establecen mecanismos de control para el
proyecto que a veces dan sensación de
inflexibilidad a posibles cambios y que de hacerlo
incrementaría el coste.
 Excesiva documentación que a veces incluso no
es útil.
 La lentitud del desarrollo. Hoy en día para ser
competitivos es necesario la agilidad y
flexibilidad a la hora de la creación de los
productos

12. Todos los inconvenientes han hecho que las metodologías
clásicas no hayan sido capaces de eliminar fallos y que
haya una explosión de creación de software orientado a la
Web, en la que se requiere constantes cambios, y que los
tiempos de desarrollo sean más cortos hacen que
aparezca el concepto METODOLOGIAS AGIL
El desarrollo ágil está centrado en la iteración,
comunicación y en reducir elementos intermedios.

14. DESRROLLO TRADICIONAL VS AGIL

15.  El alcance definirá las tareas necesarias
para alcanzar las características que
deseamos obtener de nuestro producto.
 El tiempo, previsión de la duración que
llevara el proyecto.
 El presupuesto o coste, dinero y recursos
que se van a destinar al proyecto.

17. CONOCE A SCRUM

18. CURSO: DISEÑO Y EVALUACION DE PROYECTO

19. La palabra SCRUM procede
del vocabulario del rugby y
significa melé; es decir, esa
“figura” en la que los
compañeros del equipo se
amontonan, forman una piña
y empujan todos en la misma
dirección

20. SCRUM

21. ¿QUE ES SCRUM?

22. Es mejor tener equipos pequeños y auto-organizados:
Formados por miembros de diferentes disciplinas Capaces de organizarse por si
mismos (auto-organización) Con una comunicación transparente De esta forma, en
general, se suelen obtener mejores resultados y todos los miembros del equipo
están más comprometidos y motivados

23. Scrum es un proceso 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. Estas prácticas se
apoyan unas a otras y su selección tiene
origen en un estudio de la manera de
trabajar de equipos altamente productivos.

24. Scrum es una metodología ágil, y como
tal:
• Es un modo de desarrollo de carácter
adaptable más que predictivo.
• Orientado a las personas más que a
los procesos.
• Emplea la estructura de desarrollo
ágil: incremental basada en
iteraciones y revisiones.

26. Se comienza con la visión general del producto,
especificando y dando detalle a las
funcionalidades o partes que tienen mayor
prioridad de desarrollo y que pueden llevarse a
cabo en un periodo de tiempo breve
(normalmente de 30días).
Estas iteraciones son la base del desarrollo ágil,
y Scrum gestiona su evolución a través de
reuniones breves diarias en las que todo el
equipo revisa el trabajo realizado el día anterior y
el previsto para el día siguiente.

27. OBJETIVO DEL SCRUM
“Quiero que los proyectos siempre se
terminen antes de tiempo. Quiero que los
desarrolladores se diviertan. Quiero que
los clientes estén entusiasmados. Quiero
que los administradores hagan mucho
dinero. Así que el objetivo de Scrum fue
crear tanto software que los
administradores de hecho pidan a los
desarrolladores bajar el ritmo.

28. El cliente necesita
 Tener resultados a corto plazo
 Cambiar a menudo los requisitos del proyecto
 Ver si se cumplen sus expectativas
Nosotros necesitamos
 Equipos altamente productivos y motivados
 Solucionar los problemas que impiden que los equipos progresen
 Utilizar un proceso de gestión ligero aún en proyectos complejos

29.  Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese
momento, ya completados)
 Productividad y calidad.
 Alineamiento entre el cliente y el equipo de desarrollo.
 Equipo motivado.

32. Los elementos que conforman el desarrollo Scrum son:
LAS REUNIONES
Planificación de sprint: Jornada de trabajo previa al inicio de
cada sprint en la que se determina cuál va a ser el trabajo y los
objetivos que se deben cumplir en esa iteración.
Reunión diaria: Breve revisión del equipo del trabajo realizado
hasta la fecha y la previsión para el día siguiente.
Revisión de sprint: Análisis y revisión del incremento generado.

34. Especulación
En esta fase se hacen disposiciones con la
información obtenida y se establecen los límites que
marcaran el desarrollo del producto, tales como
costes y agendas.
Exploración:
Se incrementa el producto en el que se añaden las
funcionalidades de la fase de especulación.
Revisión:
El equipo revisa todo lo que se ha construido y se
contrasta con el objetivo deseado.
Cierre:
Se entregara en la fecha acordada
una versión del producto deseado. Al
tratarse de una versión, el cierre no
indica que se ha finalizado el
proyecto, sino que seguirá habiendo
cambios, denominados
“mantenimiento” que hará que el
producto final se acerque al producto
final deseado.V

35. COMPONENTES
DE
SCRUM

36. A. PLANIFICACION DE BACKLOG
Se definirá un documento en el que se
reflejaran los requisitos del sistema por
prioridades
En esta fase se definirá también la
planificación del Sprint 0, en la que se
decidirá cuáles van a ser los objetivos
y el trabajo que hay que realizar para
esa iteración.
B. SEGUIMIENTO DEL SPRINT
En esta fase se hacen reuniones diarias en las que
las 3 preguntas principales para evaluar el avance
de las tareas serán:
 ¿Qué trabajo se realiza desde la reunión
anterior?
 ¿Qué trabajo se hará hasta una nueva reunión?
 Inconvenientes que han surgido y que hay que
solucionar para poder continuar.

37. C. REVISION DEL SPRINT
Cuando se finaliza el Sprint se realizara
una revisión del incremento que se ha
generado.
Se presentaran los resultados finales y
una demo, esto ayudara a mejorar el
feedback (realimentación) con el cliente.

38. Reunión previa al comienzo de cada sprint:
◦ Cuál es el trabajo
◦ Objetivos a cumplir
Intervienen todos los roles
Se genera el “Sprint Backlog” o lista de tareas que se van
a realizar
Se determina el “objetivo del Sprint” (funcionalidad del
negocio que se va a generar)

39. Las Reuniones
Breve reunión diaria para repasar cada una de las tareas y el trabajo
previsto de la jornada
Sólo interviene el equipo de desarrollo
Cada miembro responde a tres questiones:
◦ Trabajo realizado desde la reunión anterior
◦ Trabajo que se va a realizar hasta la próxima reunión de seguimiento
◦ Problemas que se deben solucionar para realizar el trabajo propuesto

40. LOS ROLES
Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en:
propietario del producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y “otros
interesados”.
“Sí, me gustaría. ¿Y cómo lo
llamaríamos?”.
“Pensándolo mejor, creo que
no voy a abrir un restaurante
contigo”.
“ Yo estaría realmente comprometido, mientras
que tu estarías sólo
implicada”.
“Huevos con Jamón”.
“Quieres abrir un restaurante
conmigo”.

42. Scrum diferencia claramente entre estos dos grupos para garantizar que quienes tienen la responsabilidad
tienen también la autoridad necesaria para poder lograr el éxito, y que quienes no tienen la responsabilidad no
producen interferencias innecesarias
COMPROMETIDOS
(cerdos)
IMPLICADOS
(gallinas)
Propiet. del producto Dirección general
Equipo Dirección comercial
Scrum Manager Marketing Usuarios,
etc)

46. Diagrama de quemado es una representación gráfica del trabajo por hacer en un proyecto
en el tiempo.

48. DUEÑO DEL PRODUCTO
 Gestiona la visión y el Roadmap
 Recopila requisitos, escribe historias de usuario
 Gestiona la Pila de Producto: decide alcance y
prioridad
 Define criterios de aceptación para cada historia y
valida
 Responsable de satisfacción del cliente y éxito
financiero
 Interfaz de negocio con Scrum
 Realiza estimaciones, reporta
progreso
 Comprometidos con la entrega de
software funcional al final del sprint
 Cross-funcional, auto-gestionado
 Responsable de calidad y velocidad
EQUIPO

49.  Cercano al equipo
 Mantiene el proceso
 Gestiona pila de impedimentos
 Hace mejorar al equipo
 Mejora la vida del equipo
 Moderador - facilitador
 Si es necesario, actua como interfaz del
Dueño de Producto
SCRUM MANAGER

52. Product Backlog
 Se parte del resultado que se desea obtener evolucionando durante el
desarrollo.
 Es un documento vivo
 Todos los integrantes del equipo de desarrollo podrán acceder a él
aportando ideas.
 El responsable es una única persona (Propietario del producto)

53. Sprint Backlog
 Lista de trabajos que realizará el equipo durante el sprint
 Incremento previsto para el sprint
 Compromiso de ejecución
 Asignación de tareas de forma personal con estimación de tiempos y recursos necesarios

54. Incremento
Demostración de los objetivos alcanzados en cada sprint
Asistencia de todos los roles, “Product Owner” e incluso usuarios
Sólo el Scrum Master puede abortar un Sprint debido a una de las
siguientes razones:
◦ La tecnología seleccionada no funciona o es incompatible con los objetivos
definidos
◦ Han cambiado las circunstancias de negocio
◦ El Scrum Team ha tenido inferencias

56. Conocida como Sprint 0, es la fase inicial en la que se intenta comprender
el caso de negocio con la finalidad de tomar decisiones que agregue valor
al producto. Durante esta fase se producen gran número de inexactitudes
con las estimaciones, pero es lógico, debido a que se hacen a alto nivel,
por lo tanto es aconsejable no perder tiempo en buscar las estimaciones

57. Se hace reunión inicial con todos los roles del equipo para
tratar:
Dimensión del proyecto.
Revisión del Backlog.
Organización del equipo y horario para establecer
reuniones de control.

58. Denominado también “Sprint Planning Meeting”, tiene como finalidad
realizar una reunión, en la que participaran el Product Ower, el Scrum
Master y el quipo, con la intención de seleccionar de la lista de Backlog
del producto las funcionalidades sobre las que se va a trabajar, y que
darán valor al producto

59. En los Sprints, el equipo trabaja para conseguir un incremento del
producto, que será productivo para el Product Owner y los
Stakeholders.
El tiempo más conveniente está entre 2 y 4 semanas, o 30 días
consecutivos como máximo. Estos intervalos de tiempo, son los que se
consideran más apropiados para que el Stakeholders no pierda interés.

62. Se han realizado de esta manera una guía por todo el
proceso de creación de un proyecto Scrum en el que se van
realizando las diferentes 5 fases en forma de ciclos, hasta
completar todas las tareas del Backlog.

64.  Personas
 Retrospectivas, retrospectivas, retrospectivas
 Control Diario, Scrum diario
 El producto que funciona es la medida de progreso.
Medimos lo que nos queda, no lo que llevamos hecho
 El equipo se auto gestiona, se autodisciplina y responde
del proyecto – Scrum Master no es un Jefe
 Desarrollo iterativo e incremental
 Sólo equipo maneja pila de Sprint, sólo Dueño de
 Producto maneja pila de producto
 Duración fija de Sprints
 Termino del Proyecto

68. ¿PARA QUÉ SE USA SCRUM?
- Software comercial
- Proyectos internos
- Proyecto de precio fijo
- Aplicaciones financieras
- Sistemas empotrados
-Desarrollo de video juegos
-Software de control de
satélites
-Sitios web
-Software para dispositivos
móviles
-Aplicaciones certificadas ISO
9001

70. DUEÑO DEL PRODUCTO

71. SCRUM MASTER

72. Los programadores son
desorganizados e
indisciplinados… Crearemos una
metodología para que sigan.

79. Quiero el proyecto acabado..!

80. Si escogemos el desarrollo tradicional
esto indicaría que el proyecto estará fuera
del cronograma establecido, indicando
que el proyecto fracaso.