Este documento presenta una introducción a las metodologías ágiles y a SCRUM. Explica los principios del Manifiesto Ágil y describe los roles, artefactos y reuniones clave de SCRUM, incluyendo Sprints, Backlogs y reuniones diarias. El objetivo es proveer una guía básica sobre este enfoque ágil para el desarrollo de proyectos.

1. ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo
DIRECCION Y GESTIÓN
DE PROYECTOS WEB
00. Metodologías Ágiles
Máster y Doctorado
en Ingeniería Web
Curso 2010-2011

2. Ponente
Julio A. Argüello Fernández
Responsable de Arquitectura y Desarrollo
Grupo B2B 2000

3. 3
Índice
1. Introducción
2. Manifiesto Ágil
3. SCRUM
1. Introducción
2. Sprints
3. Roles
4. Backlogs
5. Reuniones
6. Técnicas
7. Caso Práctico
4. Contactos y Página Web
5. Bibliografía

4. MANIFIESTO ÁGIL
Enfoque Metodológico
Postgrados en Ingeniería

5. Introducción
 Burocracia↓↓
 Valor↑↑
 Iteraciones [1s – 4s] (planificación +
análisis + codificación + revisión +
documentación)

6. Manifiesto Ágil
1. Valorar a los
individuos y su
interacción, …
2. Valorar el software
que funciona,…
3. Valorar la
colaboración con el
cliente, …
4. Valorar la respuesta
al cambio, …
…sobre los procesos y
las herramientas.
…sobre la
documentación
exhaustiva.
sobre la negociación
contractual.
…sobre el seguimiento
de un plan.

7. 1. Personas vs.
Procesos (I)

8. 1.Personas vs.
Procesos (II)

9. 2. Funcionamiento vs.
Documentación (I)

10. 3.Colabora vs. Negocia (I)

11. 3.Colabora vs. Negocia (II)

12. 4.Cambio vs. Plan

13. Características
 Proceso iterativo e incremental
 Mitigación del riesgo (mediante iteraciones
fijas)
 Mejora continua
 Calidad desde el primer día
 Priorización de requerimientos (según
valor)
 Equipos dedicados y auto-gestionados
 Colaboración continua con el cliente
 Incorporar el cambio
 Prácticas de desarrollo modernas

14. Ejemplos
 XP (eXtreme Programming)
 TDD (Test Driven Development)
 Crystal Clear
 SCRUM
 AUP (Agile Unified Process)
 EssUP (Agile Unified Process)
 FDD (Feature Driven Development)
 BDD (Behavior Driven Development)

15. ¿¿??

16. ¿¿??

17. SCRUM
Metodología Ágil Objetivo
Postgrados en Ingeniería

18. Introducción (I)
“Programming is so
inherently difficult and
complex”
--Edsger W. Dijkstra

19. Introducción (II)

20. Introducción (III)

21. Origen
 En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística
que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos
comerciales.1 Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las
fases se traslapan de manera intensa y el proceso completo es realizado por
un equipo con funciones transversales, como en el rugby, donde el
equipo entero «actúa como un solo hombre para intentar llegar
al otro lado del campo, pasando el balón de uno a otro». Los casos
de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas
fotográficas, computadoras e impresoras.
 En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous
Solutions (A problemas malvados, soluciones virtuosas),2 se refirieron a esta aproximación
como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por
Takeuchi y Nonaka.
 A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en
práctica el scrum en su compañía, Advanced Development Methods. Por aquel
tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el
primero en denominarla scrum.3 En 1995 Sutherland y Schwaber, durante el OOPSLA '95
desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum,
siendo ésta la primera aparición pública de la metodología. Durante los años siguientes,
Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así
como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo
que ahora se le conoce como scrum. En 2001, Schwaber y Mike Beedle describieron la
metodología en el libro Agile Software Development with Scrum.

22. Roles (I)
El Pollo mira al cerdo y le dice "Hey, por qué
no abrímos juntos un restaurante?". El cerdo
mira al pollo y dice: "Buena idea, ¿cómo
podría llamarse?". El pollo entonces piensa al
respecto y finalmente dice: "¿Por qué no lo
llamamos 'Jamón y Huevos'?". "Mmmmm,
no me parece justo. ", dice el cerdo, "Yo
estaría totalmente comprometido,
mientras que vos sólo estarías algo
involucrado"

23. Roles (II)
 Los cerdos
 Miembros del Equipo
 Scrum Máster
 Dueño de Producto
 Los pollos
 Stakeholders (clientes, vendedores, etc.)
 Usuarios (quienes utilizarán el software)
 Gerentes (los administradores de la org.)
 Otras personas
Objetivo
•Involucrar a
usuarios, negocio
y stakeholders
Objetivo
•Involucrar a
usuarios, negocio
y stakeholders

24. Roles:
Dueño del Producto
 La voz del cliente
 Responsabilidades
 Retorno de inversión (ROI)
 Fijar características, fechas y
contenidos
 Ofrecer visión única de los “pollos”
 Priorizar las características
 Aceptar o rechazar el resultado del
trabajo

25. Roles:
Scrum Master
 El padre, el facilitador de Scrum
 Responsabilidades
 Asegurar las reglas
 Mejorar vida y productividad de los
miembros
 Asegurar la cooperación de todos los roles
 Proteger al equipo de interferencias
externas
 Invitar a personas a las reuniones
 Seguir la lista de impedimentos
 Asesorar al cliente cómo maximizar su ROI

26. Roles:
Miembros del Equipo
 Los creadores
 Grupo de Trabajo vs. Equipo
 Perfiles (analistas, diseñadores, …)
 Responsabilidades
 Colaborar
 Seleccionar el objetivo de la iteración
 Hacer todo lo necesario para tener éxito
 Se organiza a si mismo y a su trabajo
 Demos. ante dueño producto y
stakeholders.

27. Roles…
 Sea como fuere…

28. Sprints (I)
 Iteración acotada en el tiempo [2s-
4s]
 Meta del Sprint
 …Sprint de Release…
Calidad
[1] ó [4, )[1] ó [4, )
semanassemanas
[3,4] semanas[3,4] semanas
2 semanas2 semanas

29. Sprints (II)

30. Sprints (III)
Alcance
Estimación Importancia
(Alcance) (Calidad)(Calidad)

31. Sprints (IV)
( )

32. Sprints (V)
 Reglas:
 El Equipo puede buscar ayuda externa.
 Nadie del exterior debe proveer al
Equipo con directivas.
 Nadie fuera del Equipo puede cambiar los
items del Backlog del Sprint.
 El Scrum Master o el Dueño del Producto
pueden cancelar el Sprint.

33. Sprints (VI)
 Reglas:
 Ante adelantos/retrasos…
 … el Equipo puede consultar al Dueño del
Producto qué items agregar/quitar. El Scrum
Master podría decidir cancelarlo.
 Gestionar desvíos en las planificaciones.
 Asistencia al Scrum diario y actualizar el
Backlog del Sprint (que puede crecer).
 El Equipo tiene que adherir a los
estándares.

34. Backlog del Producto (I)
 Artefacto más importante de Scrum
 Lista priorizada de:
 Requerimientos funcionales
 Mejoras
 Tecnología
 Corrección de errores
 Típicamente formado por historias de
usuario
 Nunca se da por completo (a diferencia
de un documento de requisitos del
sistema)

35. Backlog del Producto (II)
 Formato: hoja cálculo, pizarra, herramienta
colaborativa
 Incluye: identificador, descripción, prioridad,
estimación
 Opcional: observaciones, criterios validación
 Gestionado por el Dueño del Producto

36. Backlog del Sprint (I)
 Contiene tareas para convertir un
Backlog del Producto en funcionalidad.
 Las tareas del Backlog del sprint están
respaldadas por un Backlog del Producto.
 Las tareas se estiman en horas [1-16]
 Las de más de 16 horas se descomponen
 Los miembros del equipo eligen las
tareas
 Sólo los miembros del Equipo pueden
alterar las tareas del backlog del sprint
 Actualizar la estimación de trabajo
restante

37. Backlog del Sprint (II)
 Formato: hoja cálculo, pizarra, herramienta
colaborativa
 Incluye: lista tareas, responsables, estado,
tiempo restante
 No incluye: información innecesaria
 Es ágil y soporta el Scrum diario

38. Backlog del Sprint (III)

39. La Velocidad
 Factor de foco/dedicación
 Mide cuan fiables son nuestras estimaciones
 Tiene en cuenta los imprevistos (< 100%)
 Inicialmente 70%
 Sprint 2 y sucesivos: ffi = (ff(i-1) + ff(i-2))/2
 Velocidad del equipo
 4 desarrolladores
 15 días ideales
 Factor de foco = 0,7
 15 * 4 *0,7= 42 puntos
Alternativas
•Estimación a OjO
•Tiempo que hizo ayer
Alternativas
•Estimación a OjO
•Tiempo que hizo ayer

40. Reuniones (I)
 Reunión de Planificación
 Exposición
 Resolución
 Scrum Diario
 Demostración o Revisión del Sprint
 Retrospectiva del Sprint

41. Reuniones (II)

42. Reunión
Planificación(I)
 Fase 1: Exposición (de historias)
 Horario
 Durante la mañana
 Asistentes
 Equipo + Scrum Master + Dueño del Producto
 Outputs:
 Priorización
 Estimación
 Hasta superar la Velocidad
 ≤ 20 puntos
 Historias del Backlog del Sprint
•Lidera esta reunión
•Evita divagaciones

43. Reunión
Planificación(II)
 Fase 1: Exposición (de historias)
 Outputs:
Objetivo del
Sprint
Gestión de maestros
Scrum Diario De 9:30 a 9:45 en la Sala de
Reuniones
Duración del
Sprint
3 semanas
Revisión del
Sprint
22 de Junio de 2010 en la Sala
de Reuniones
Gráfico
Burndown
Avance ideal

44. Reunión
Planificación (III)
 Fase 2: Resolución
 Horario
 Durante la tarde
 Asistentes
 Equipo + Scrum Master
 Outputs
 Tareas del Backlog del Sprint
 Tarea < 4 días ideales

45. Reunión
Planificación (IV)
 Agenda
45

46. Reunión
Planificación (V)
 Acuerdo
46

47. Reunión
Planificación (VI)
• Outputs: Tablero del Sprint

48. Reunión
Planificación (VII)

49. Reunión
Planificación (VIII)

50. Reunión
Planificación (IX)
50

51. Scrum Diario (I)
 Scrum Diario
 Horario
 Todos los días a las 10:00 h (a lo sumo 15’)
 Asistentes
 Equipo + Scrum Master
 Objetivos
 Repasar (rápidamente) la situación y el tiempo
restante para finalizar el sprint.
 Identificación temprana de impedimentos, confianza y
motivación, mejora comunicaciones y productividad (presión
inconsciente!!!)
 Sincronizar actividades
 Outputs
 Backlog del Sprint y Gráfico Burndown actualizados
 Identificación de necesidades e impedimentos
•Lidera esta reunión
•Evita divagaciones

52. Scrum Diario (II)
 Reglas
 Todos los días en el mismo sitio y hora
 Asisten todos los miembros
 Puntualidad o multa (para cafés…)
 Todos hablan en sentido agujas reloj (sin
interrupciones)
 Se responde al grupo (NO al Scrum
Master):
 ¿Qué hiciste?¿Qué harás?¿Qué problemas has
tenido?
 Pollos invitados pero NO participan

53. Revisión Sprint (I)
 Revisión (demostración) del Sprint
 Horario
 La preparación no debe superar las 2h, sino algo
falla con el concepto de “Terminado”.
 Duración [1h- 2h]
 Asistentes
 Equipo + Scrum Master + Dueño Producto
 Opcionalmente otros interesados
 Objetivos
 Obvio… …demostrar funcionalidad!!!
 Visualización temprana!!
¿Qué?

54. Revisión Sprint (II)
 Revisión (demostración) del Sprint
 Reglas
 Demostración en vivo (sin transparencias,
papeles…). Se puede utilizar un PC de desarrollo
 Primero se describe previsión (objetivo +
historias) y luego ejecución (¿OK?¿KO?¿Por
qué?)
 Se debe demostrar conforme a pruebas de
aceptación
 Debate y cambios (sólo el Dueño del Producto
puede aceptarlos)

55. Retrospectiva Sprint (I)
 Retrospectiva del Sprint
 Horario
 Asistentes
 Equipo + Scrum Master
 Objetivos
 Mejorar
 Aspectos técnicos,
 Reglas
¿Cómo?

56. Retrospectiva Sprint (II)
 Retrospectiva del Sprint
 Dinámica
 Cada miembro expone su visión y rellena dos
primera columnas
 Luego el grupo propone acciones correctoras
 3 votos en papel x Miembro  Scrum Master
recuenta y propone hacer foco en 2-3 de ellas
Bueno A Mejorar Acción
correctora

57. Retrospectiva Sprint (III)
57

58. Técnicas:
Historias de Usuario (I)
El cliente entra en una pantalla donde se
le pregunta el código de identificación y
entonces se le muestra los datos de
Apellido y Domicilio del mismo
• El cliente visualiza su plan actual, y de
una lista ordenada por importe elige el
nuevo plan al cual desea acceder,
constando la misma de la descripción del
plan y del importe.
Se verifica si el cliente está en condiciones de
tomar este plan.
Se confirma la operación por parte del sistema

59. Técnicas:
Historias de Usuario (II)
• ¿Cómo sería la
identificación del cliente
(login)?
- Usuario y contraseña
• ¿El pedido de cambio de plan
se resuelve Online o no?
- Online
• ¿Se puede modificar un
pedido grabado?
- Sí
• ¿Se puede cancelar un
pedido?
- Sí
•Surgen nuevas historias•Surgen nuevas historias

60. Técnicas:
Historias de Usuario (III)
 Nombre
 Breve
 Conciso
 Importancia
 ≡ Prioridad
 A es más importante
que B si A > B
 Estimación
 Inicialmente vacía
 Se valora durante la
reunión de planificación
 Validación
 A efectos de aceptación
Nombre Historia
Importancia
Estimación
Validación

61. Técnicas:
Planning Poker (I)

62. Técnicas:
Planning Poker (II)

63. Técnicas:
Actualización Estimaciones
Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
Gestión Maestros
100
Julio
4
Es posible crear, buscar, borrar
y actualizar maestros
Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
X 2 Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
X 2X

64. Técnicas:
Control de impedimentos
Sistema
legado KO!
Sistema
legado KO!
I
Sistema
legado KO!
II
Servicio
Web Down!
Servicio
Web Down!
I
Gestionados por
Scrum Master
Gestionados por
Scrum Master

65. ¿A QUÉ ESTAMOS
JUGANDO?
No me lo creo, ¡demuéstramelo!

66. Sprints Tipo
 Sprint 0: Preparación
 Sprint 1: Comienzo
 Sprint 2: Aumenta Velocidad
 Sprint 3: Impedimentos
 Sprint 4: ¡Más Caña!

67. Sprint 0: Preparación (I)
 Definición Backlog de Producto
 Estimaciones imprecisas (en días)
 No es problema, en las primeras iteraciones se verá si
el proyecto es o no viable
 Presentación de los roles
 Visión de Proyecto
 Cualquier integrante conoce el propósito del proyecto
 Definición de Terminado
 Cumple requerimientos, funciona en desarrollo, diseño
completo, desarrollo TDD, Tests OK, probado IE6 y
Firefox, documentación, 0% CS, 0% PMD…
 Definición inicial de entregables

68. Sprint 0: Preparación (II)
 Reunión kick-off
 Alcance
 Revisión backlog
 Enfoques técnicos
 Acuerdos varios (horas de las reuniones…)
 Logística
 Ubicación (ej.: reserva de salas de
reuniones)
 Material (equipos, red, pizarra, entorno
desarrollo…)

69. Sprint 1: Comienzo
 Día 1
 Velocidad inicial
 Factor de foco (inicialmente 70%)
 Reunión de Planificación del Sprint
 Exposición + Resolución
 Día 2
 Los desarrolladores eligen tareas
 Scrum diario
 Día 15
 Reunión de Revisión
 Reunión de Retrospectiva

70. Sprint 2: + Velocidad
 Día 1
 Recalcular Factor de Foco
 Reunión de Planificación del Sprint
 Día 10: hemos terminado las tareas!!!
 Se recupera del Backlog del Producto un
nuevo item…
 Día 15
 Reunión de Revisión
 Reunión de Retrospectiva

71. Sprint 3: Impedimentos
 Día 1
 Aumenta el Factor de Foco
 Reunión de Planificación de Sprint
 Día 3
 Surge un impedimento
 Registro en la Lista de Impedimentos
 Día 8
 Surge un imprevisto (bajas)
 Registro en la lista de imprevistos
 Día 9
 Se comunica al Dueño del Producto que se prevé retraso.
¡Lo intentaremos de todas formas!
 Día 15
 Reunión de Revisión
 Reunión de Retrospectiva

72. Sprint 4: ¡Más caña!
 Scrum Checklist

73. Conclusiones

74. 74
Contactos y Página web
 http://www.ceb2b2000.com
 j.arguello@b2b2000.com
 info@ceb2b2000.com
Julio A. Argüello Fernández
Responsable de Arquitectura y Desarrollo
Grupo B2B 2000

75. 75
Bibliografía
 Do It Yourself Agile Damon B. Poole. Septiembre
2009.
 Scrum y XP desde las Trincheras Henrik Kniberg.
2007.
 Agile Estimating and Planning, Prentice Hall, Mike
Cohn, 2005
 Blogs
 http://www.dosideas.com
 http://blog.crisp.se/henrikkniberg
 Webs
 http://agilemanifesto.org/
 http://www.navegapolis.net/
 http://www.agile-spain.com/
 http://www.proyectosagiles.org/
 http://www.scrumalliance.org/

76. ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo
DIRECCION Y GESTIÓN
DE PROYECTOS WEB
FIN