Gestión Ágil de Proyectos

con Scrum

ProviderID: 4703

Presentación
¿Quién soy?
Nombre
Experiencia

¿Quienes son?
Nombre
Compañía
Experiencia en Dirección de Proyectos
Conocimientos de Scrum
Expectativas del Curso
Hobbies.

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 1
 Logística

Puntualidad
Política de celulares
Participación activa
Baños

Objetivos del Curso

Proveer un entendimiento de la filosofía Agile y sus
principios
Discriminar cuando es adecuado usar Scrum
Entender y aplicar el Ciclo de Scrum
Organizar un equipo Scrum y entender los roles
participantes
Quedar preparado para desempeñarse como miembro
de un equipo Scrum, Scrum Master o Product Owner
Entender las principales consideraciones a tomar en
cuenta para la adopción de Scrum
4

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 2
 Programa del Curso

Introducción a Agile Estimación y Priorización

Introducción a Scrum El Ciclo Scrum:
Equipo de Proyecto Planificación Estimación
Implementación
Fases de Scrum
Revisión y Retrospectiva
Inicio del Proyecto
Release
Historias de Usuario Escalabilidad en Scrum
Product Backlog Adopción
Examen de Scrum Master

Scrum Study
Cuerpo de certificación global para Scrum
Para dar examen inscribirse como “Primary Membership” en
www.scrumstudy.com .
• Expert Scrum Master Certified
Nivel Experto (ESMC)
• Scrumstudy Certified Trainer (SCT)

• Scrum Master Certified (SMC)

• Scrum Product Owner Certified
Nivel Intermedio (SPOC)
• Agile Expert Certified (AEC)

Nivel Básico • Scrum Developer C

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 3
 El Examen de Certificación SMC
100 preguntas de Alternativas múltiples
Una alternativa correcta por pregunta
No hay descuentos por preguntas erróneas
2 horas de duración
Examen en línea supervisado
Tasa de aprobación del 95%

El Examen de Certificación SPOC

140 preguntas de Alternativas múltiples
Una alternativa correcta por pregunta
No hay descuentos por preguntas erróneas
3 horas de duración
Examen en línea supervisado
Tasa de aprobación del 93%

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 4
 Programa del Curso

Introducción a Agile Estimación y Priorización

Introducción a Scrum El Ciclo Scrum:
Equipo de Proyecto Planificación Estimación
Implementación
Fases de Scrum
Revisión y Retrospectiva
Inicio del Proyecto
Release
Historias de Usuario Adopción
Product Backlog Examen de Scrum Master

Concepto de Agilidad
“Agilidad es la capacidad de crear y responder a los
cambios con el fin de obtener ganancias en un medio
ambiente de negocios turbulento. La agilidad es la
capacidad de balancear flexibilidad y estabilidad”.

Jim Highsmith, 2002

10

10

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 5
 ¿Por qué se necesita ser ágil?

Mercado y tecnología rápidamente cambiante: la necesidad de

ser innovador

La contracción del “time to market” de los productos y la

creciente demanda por innovación por parte de los clientes

Reducción de los costos de pruebas y experimentación

(simulaciones y automatización)

La necesidad de un método adaptativo en lugar de los

tradicionales métodos predictivos

11

11

Supuestos de los métodos tradicionales

Es posible definir el diseño del producto en forma detallada, y

por lo tanto generar una planificación detallada

Habrán pocos cambios a la solución

Buenos procesos garantizan buen producto

Marco contractual rígido con penalizaciones

12

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 6
 La filosofía ágil
Contracultura que surge como crítica de las pesadas metodologías
basadas en procesos.
Capability Maturity Model Integration(CMMI)
Rational Unified Process (RUP)
Los primeros críticos y disidentes aparecen en 1980s.
Visibilidad de nuevas ideas y moméntum en 1990s
El “Manifiesto Ágil” publicado en 2001, pone la filosofía ágil en la
mente de la gente.

13

Manifiesto ágil – (2001)

A través de este trabajo hemos
Individuos aprendido a valorar más Procesos

SW Funcionando Documentación

Colaboración Contrato

Respuesta al cambio Plan

Esto quiere decir, aunque las declaraciones de la derecha tienen valor, valoramos MÁS
las declaraciones de la izquierda

14

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 7
 Los 12 Principios de la Agile Alliance
Nuestra más alta prioridad es satisfacer al cliente a través de la
entrega temprana y continua de software de valor
Aceptamos que los requisitos cambien, incluso en etapas tardías
del desarrollo. Los procesos ágiles aprovechan el cambio para
generar ventaja competitiva para el cliente.
Entregar frecuentemente software funcionando, desde un par de
semanas, hasta un par de meses, con preferencia al período de
tiempo más corto posible

15

Los 12 Principios de la Agile Alliance, continuación

La gente de negocios y los desarrolladores trabajamos en
conjunto, de forma cotidiana a lo largo del proyecto
Los proyectos se desarrollan en torno a individuos motivados. Hay
que darles el entorno y el apoyo que necesitan y confiarles la
ejecución del trabajo.
El método más efectivo y eficiente de transmitir información
hacia y dentro del equipo de trabajo, es a través de la
conversación cara a cara.

16

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 8
 Los 12 Principios de la Agile Alliance, continuación
Software funcionando es la principal medida de progreso
Los procesos ágiles promueven un desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deben ser capaces de
mantener un ritmo constante de trabajo de manera indefinida.
La atención continua a la excelencia técnica y al buen diseño,
mejora la agilidad.

17

Los 12 Principios de la Agile Alliance, continuación

Simplicidad, el arte de maximizar la cantidad de trabajo que no se
hace, es esencial.
Las mejores arquitecturas, requerimientos y diseños emergen de
equipos auto-organizados.
A intervalos regulares, el equipo reflexiona respecto a como ser
más efectivo, para a continuación ajustar y perfeccionar su
comportamiento de acuerdo con ello.

18

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 9
 Cambio de Paradigma (Fecha fija, Alcance variable)
Triángulo de hierro tradicional Triángulo ágil

Restricciones Alcance Costo Tiempo

Guiados
por la
visión de
Guiados negocio
por un
plan

Estimados Costo Tiempo Alcance

El plan determina los La visión impulsa la
estimados de tiempo y costo priorización de entregas
en tiempo y costo

19

19

Métodos Tradicionales de Cascada

V
A
L
O
R

P
O An. Requer.
R
Diseño
E
N Construcción
T
R Pruebas
E
G
A
R
T I EMPO

20

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 10
 Métodos Iterativos incrementales

T I EMPO

Cada iteración produce una versión ejecutable, un incremento adicional al

sistema
Priorizar funcionalidad de mayor valor y mitigar riesgos (tecnológicos y de
entendimiento de requerimientos)
Promover un ritmo sostenible de trabajo

21

Desarrollo iterativo acelera la entrega de valor

V
A
L
O
R

P
O
R

E
N
T Iterativo Cascada
R
E
G
A
Sprint Sprint Sprint Sprint Sprint Sprint Sprint
R
T I E MPO

22

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 11
 Jerarquía del Trabajo
Fuera del alcance Estrategia
de los métodos Plan de
ágiles (pero tiene Portafolio equipos ágiles
un nivel de Proyecto en estos tres
impacto recípoco) niveles.
Release
Sprint

Día

Cohn, Mike. Agile Estimating and Planning. Prentice Hall, 2006

23

Desarrollo Iterativo

Release 3

Release 2

Sprint
Release 1 3

Sprint
2

Sprint 1

24

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 12
 Tradicional vs Agile
Enfoque Agile Tradicional
Énfasis Personas Procesos
Dominio Impredecible/Exploratoria Predecible
Documentación Mínima, solo la requerida Comprehensiva
Aseguramiento Calidad Centrada en el Cliente Centrada en el Proceso
Estilo de Proceso Iterativo Lineal
Planificación Inicial Baja Alta
Actitud ante el cambio Adaptabilidad Rigidez
Priorización requerimientos Basada en valor de negocio Fija en el plan
Estilo de Gestión Descentralizada Autocrático
Liderazgo Colaborativo, Líder servicial Comando y control
Medición de desempeño Valor para el negocio Cumplimiento del plan
Retorno sobre la inversión Quick Wins (a lo largo del Al final del proyecto
proyecto) 25

25

Cronología de los Métodos ágiles

Dynamic Feature Adaptative

Crystal Scrum Systems Extreme Driven Software
1988 1995 Development Programming Development Development
Method 1995 1996 1997 2000

26

26

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 13
 Métodos ágiles
Crystal
Eficiencia.
Habitabilidad. (El equipo se siente cómodo usándolo)
Foco en las personas y no en los procesos.
Entrega frecuente de código usable.
Mejora reflexiva.
Comunicación osmótica.
Dynamic Systems Development Methos (DSDM)
Involucramiento de los clientes y usuarios.
Establecimiento de costos, calidad y tiempo en el principio del proyecto.
Alcance guiado por el método MoSCoW.

27

27

XP Programación Extrema: Valores

• Con clientes
Comunicación • Dentro del equipo
• Lo más directa posible

Simplicidad • Lo que realmente se necesita ahora

• Del sistema (Test automatizados)

Realimentación • Del cliente
• Del equipo

• Enfrentar problemas dentro del equipo

Coraje • Asumir errores

• El código es de todos: debo escribir para que

Respeto otros entiendan
• Solucionar problemas lo antes posible

28

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 14
 XP Buenas Prácticas

El equipo debe estar junto

El equipo como una unidad (equipo multifuncional)

Usa radiadores de información sobre el progreso del proyecto (visibilidad)

Trabaja las horas razonables para ser productivo

El ciclo semanal y el ciclo trimestral

Programa por pares

Pequeñas versiones incrementales

Integración continua

29

Feature Driven Development (FDD)

Desarrollo de un modelo general.
Construcción de una lista de características
(funcionalidad).
Planificación por característica.
Diseño por característica.
Construcción por característica.

30

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 15
 Adaptative Software Development (ASD)
Serie repetitiva de especulación, colaboración y ciclos de
aprendizaje.
Aprendizaje continuo y adaptación sencilla al estado del
proyecto.
Focalizado en la misión.
Basado en las características.
Iterativo.
Enmarcado en un tiempo determinado.
Conducido por los riesgos.
Tolerante a los cambios.

31

Kanban
KANBAN = “Tarjeta” o “Tablero”
Un sistema de información que controla de modo armónico
la fabricación de los productos necesarios en la cantidad y
tiempo necesarios en cada uno de los procesos que tienen
lugar en una fábrica

32

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 16
 Kanban
No utilizar PUSH (se estimaba la demanda y en base a ello se
producía)

Nuevo enfoque: PULL (cuando tengo disponibilidad voy a buscar

trabajo)

Minimizar el Trabajo-en-progreso (WIP)

Visualizar y compartir el estado del proyecto en una pared dentro de

la sala de proyectos

33

Kanban: Beneficios de limitar el WIP

Mantener el foco

Evitamos desperdicios de tiempo

Evitamos perder información importante

Mejoramos la calidad de nuestro trabajo

Reaccionamos antes a problemas y bloqueos

Conseguimos una frecuencia de entrega predecible

Quedan de manifiesto los cuellos de botella

34

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 17
 Principios Lean

Eliminar todos los desperdicios

Buscar la perfección de manera continua

Origen en sector industrial (Toyota)

Incentiva que los trabajadores identifiquen mejoras

35

Lean aplicado al Software: Principios

Eliminar Desperdicios
Funcionalidades innecesarias
Burocracia
Comunicación interna lenta
Ampliar aprendizaje
Probar tempranamente
Realimentación del cliente
Decidir lo más tarde posible
Entregar tan rápido como sea posible
Potenciar el equipo
Crear la integridad
Véase todo el conjunto

36

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 18
 Ejercicio
¿Para cuál de los siguientes proyectos
usaría enfoque ágil y para cuál tradicional?
Justifique su respuesta.
Construir una nueva línea de Metro
Hacer una modificación a un software
para atender un nuevo requerimiento
normativo
Desarrollar una aplicación móvil que
permitirá lanzar un nuevo negocio
Hacer cambios en una organización con
el propósito de mejorar su desempeño

37

37

Scrum

Módulo 2
Visión General

© TenStep, Inc
Provider ID: 1774
Course ID: (PM00.99)

38

38

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 19
 Historia
“Software ágil desarrollado con 2001
Scrum” por Ken Schwaber y Mike
Beedle

Jeff Sutherland y Ken Schwaber 1995

presentaron Scrum en OOPSLA*

Scrum desarrollado/usado
1990/91
individualmente por Jeff Sutherland y
Ken Schwaber

1986 Nuevo enfoque para el desarrollo de productos por

Hirotaka Takeuchi & Ikujiro Nonaka llamado
enfoque holístico o Rubgy

*OOPSLA - Object-Oriented Programming, Systems, Languages & Applications

39

SCRUM en palabras simples

Scrum es un método basado en la teoría de procesos de control
empírico, empleando un enfoque iterativo e incremental para
optimizar la predictibilidad y el control de riesgos.

Fue formulado como una manera más rápida y flexible de entregar el

más grande valor en un período corto de tiempo.

40

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 20
 Proceso Empírico de Control
3 Pilares fundamentales son la base de Scrum:
Transparencia
Inspección
Adaptación

41

Visión general de Scrum

Un proyecto Scrum sigue un flujo ordenado de pasos que puede ser
visualizado de la siguiente forma:

42

42

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 21
 Visión general de Scrum
El marco de Scrum puede ser mejor entendido a través de los
principios que lo rigen, sus procesos y sus aspectos.

43

43

Principios de Scrum
Control de proceso empírico.

Auto-organización.

Colaboración.

Priorización basada en el valor.

Trabajo en un marco de tiempo.

Desarrollo iterativo.

44

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 22
 Aspectos de Scrum

Organización.

Justificación del negocio.

Calidad.

Cambio.

Riesgos.

45

Justificación del negocio

Es importante para la organización hacer una evaluación
adecuada del negocio antes de comenzar el proyecto.

La justificación del negocio se basa en el concepto de entrega

impulsado por el valor.

46

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 23
 Scrum
Master
Organización
Dueño del
producto
El dueño del producto
Cliente comunica los El Scrum Master guía al
El cliente Voz del requerimientos de equipo y elimina
solicita su cliente negocio priorizados al obstáculos
requerimiento equipo, crea la lista de
al dueño del producto priorizada y
producto define los criterios de
aceptación. Equipo Scrum

El dueño del producto El equipo muestra al

entrega el valor del dueño del producto
negocio al cliente a los resultados
través de entregas parciales obtenidos
incrementales del en la reunión de
revisión del producto El equipo entrega el
producto
producto del proyecto

47

Calidad en Scrum
La calidad es definida como la habilidad de completar un
producto o entregable cumpliendo con los criterios de
aceptación y logrando el valor de negocio esperado por el
cliente.
Calidad basada en la experiencia del equipo y del compromiso de
los involucrados.

48

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 24
 Cambios en Scrum
Gran capacidad de reacción ante los cambiantes requerimientos
generados por las necesidades del cliente o la evolución del
mercado. El marco de trabajo está diseñado para adecuarse a las
nuevas exigencias que implican proyectos complejos.

49

Riesgos en Scrum
El riesgo es definido como un evento incierto que puede afectar
positiva o negativamente los objetivos del proyecto.

Riesgo positivo - Oportunidad

Riesgo negativo - Amenaza

50

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 25
 Procesos de Scrum
Los procesos direccionan las actividades específicas y el flujo de un
proyecto Scrum. En total son 19 procesos que están agrupados en 5
fases.
• Inicio.
• Planificación y estimación.
• Implantación.
• Revisión y retrospectiva.
• Entrega.

51

51

Procesos de la fase de inicio

Crear la visión del proyecto (Project Vision).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

52

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 26
 Procesos de la fase de Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer

Historias de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

53

Procesos de la fase de implantación

Ajustar Backlog de
Conducir reuniones
Crear Entregables. productos
de trabajo diaria.
priorizado.

54

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 27
 Procesos de la fase de revisión y retrospectiva

Convocar Scrum de Scrums.

Demostrar y validar el sprint.

Retrospectiva del sprint.

55

Procesos de la fase de entrega

Enviar los entregables.

Retrospectiva del proyecto.

56

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 28
 Eficiencia de Scrum
La mejor utilidad de Scrum se logra en proyectos que
involucran lo siguiente:
Desarrollo de productos tecnológicos innovadores.
Equipos de proyecto cross funcionales dedicados y
altamente calificados.
Desarrollo de productos en ambientes
hipercompetitivos.
Requerimientos de cambio frecuentes e
inesperados.
Una necesidad regular de retroalimentación debido
a requerimientos complejos.

57

Scrum

Módulo 3
Equipo de Proyecto

© TenStep, Inc
Provider ID: 1774
Course ID: (PM00.99)

58

58

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 29
 Roles en Scrum
Roles
complementarios
Equipo de Proyecto Scrum
(Roles principales)
Usuarios Interesados

Product Owner

El equipo
Scrum Master

59

Product Owner
Es la voz del cliente.
Ser voz del cliente se refiere tanto a las necesidades del
cliente declaradas como a las no declaradas, lo que
implica un profundo entendimiento del negocio.
Representa a los interesados y es responsable de
asegurar que el equipo genere valor.
Responsable de asegurar una clara comunicación de las
funcionalidades del producto al equipo.
Establece una visión compartida del producto.
Se asegura de que el equipo trabaje desde la perspectiva
del negocio.

60

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 30
 Product Owner
Funciones
Define la Visión del Proyecto
Ayuda a crear el Presupuesto del proyecto
Identifica interesados y ayuda a conformar el equipo de proyecto
Escribe historias de usuario, sus criterios de aceptación, las prioriza, y
las coloca en el Product Backlog.
Define el Criterio de Terminado
Participa en el Sprint Planning y en la revisión del sprint.
Mantiene el Product Backlog Priorizado

61

Conversación
¿Cree usted qué es conveniente que el Product Owner sea el
Cliente o uno de sus representantes? Ventajas y desventajas

62

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 31
 Scrum Master

63

Scrum Master
Sus roles centrales son
Asegurar de que los procesos Scrum se utilizan como es
debido por todo el equipo, incluyendo al Product Owner
Eliminar los obstáculos que impiden que el equipo alcance
el objetivo del sprint.

64

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 32
 Scrum Master
Se basa en el concepto de Liderazgo Servicial
Más que influir, busca sacar lo mejor del equipo de trabajo
Se comporta como el primero entre pares
Está atento a las necesidades del equipo (escucha
activamente)
Es capaz de explicar y discutir
Es flexible, adaptable, abierto a mejoras
Potencia a su equipo
Inspira a otros a servir
(Sabe que no puede hacerlo todo solo)

65

Scrum Master
Actúa como una protección entre el equipo y cualquier
influencia que le distraiga.
Monitorea el progreso.
Promueve el mejoramiento continuo.
Facilitador en el proceso de planeación, revisión y
retrospectiva.
Facilita reuniones de trabajo del equipo

66

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 33
 Conversación
¿Cuáles son las principales diferencias entre el Scrum Master
y el Jefe de Proyecto tradicional?

67

El equipo de Scrum
Son las personas que deben desarrollar el producto
Características
Auto Gestionados
El equipo tienen la propiedad colectiva del proyecto
Todos están involucrados en las decisiones
Multi Funcionales
Todos las habilidades y conocimientos necesarios
están disponibles, sin depender de alguien externo
Todos enfocados en una meta común
En el mismo espacio físico y comunicados de frente
Desarrollo de producto iterativamente
Tamaño óptimo: Entre 6 y 10 miembros.

68

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 34
 El equipo de Scrum
Funciones
Deben entender las historias de usuario y el Product
Backlog priorizado
Estimación de las historias de usuario.
Asumen el compromiso de que historias de usuario
desarrollar en un Sprint
Identifican la lista de tareas para desarrollar cada historia
de usuario, las estiman y las asignan dentro del equipo
Participan en reuniones de trabajo
Ejecutan las tareas y crean los entregables

69

Dinámica del Equipo

Etapas de Tuckman de Desarrollo de Grupos

70

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 35
 Selección del Equipo Central
Deben ser “Generalistas - Especialistas”
Generalistas: Conocimientos generales en varios campos
Expertos al menos en uno
Idealmente son:
Independientes
Auto Motivados
Focalizados en el cliente
Responsables
Colaborativos
Al definir el equipo, se deben identificar backups para cada
uno

71

Ventajas de Equipos Multi Funcionales

Rápida Toma de decisiones
Mejora la Comunicación
Orientación al Resultado
Propiedad colectiva
Innovación continua

72

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 36
 Roles no Centrales
Interesados (Stakeholders)
Cliente (individuo u organización)
Usuarios
Sponsor
Otros participantes o afectados
Proveedores
Cuerpo de Asesoramiento de Scrum (SGB – Scrum Guidance
Body)

73

Ejercicio
Actividad por equipos (30 minutos)
Lea los escenarios entregados
Discutir como podrían responder a cada situación si fueran un
equipo Scrum

74

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 37
 Módulo 4
Fases de Scrum

© TenStep, inc
ProviderID: 1774

75

75

Fases de SCRUM

Ante- Implemen- Revisión y

Inicio Planificación Release
proyecto tación Restrospectiva

76

76

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 38
 Fases de Scrum - Inicio
Crear la visión del proyecto (Project Vision).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

77

77

Proceso 1 - Crear la Visión del Proyecto

En este proceso, el caso de negocio es revisado para crear una
declaración sobre la Visión del Proyecto que servirá de guía y
proporcionará el enfoque al Proyecto.
Crear la visión del proyecto es responsabilidad del Product
Owner.
El Product Owner es responsable de obtener los requerimientos
del negocio y transformarlos en la visión del producto.
Debe obtener un acuerdo con Stakeholders
La visión del proyecto debe enfocarse en el problema y no en la
solución.
Debe ser lo suficientemente flexible para adaptarse a futuros
cambios conforme avanza el proyecto.
78

78

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 39
 Proceso 1 - Crear la Visión del Proyecto
Declaración de la visión
Describir la visión general del proyecto de una manera clara y concisa.

Grupo Objetivo Necesidades Producto / Servicio Valor

¿A cuál segmento ¿Qué necesidad estará Mencionar entre 3 y 5 ¿Cuáles serán los
del mercado será siendo cubierta por el características principales beneficios para la
dirigido el producto o servicio? del producto o servicio que empresa?
producto? cubren la necesidad
¿Qué tipo de beneficios identificada y lo hacen Ejemplo: Aumento
¿Quiénes serán generará? único de rentabilidad,
los posibles reducción de
compradores? costos,
posicionamiento,
etc.
79

79

Ejercicio - Caso de Estudio

A partir de la información contenida en el Caso “Faster Foods”
generar la Visión del Proyecto

80

80

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 40
 Fases de Scrum - Inicio
Crear la visión del proyecto (Product Vision
Board).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

81

81

Proceso 2 - Identificar al Scrum Master y a los

interesados

Habilidad de resolución de
problemas
Disponibilidad

Compromiso

Estilo de liderazgo servicial

82

82

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 41
 Fases de Scrum - Inicio
Crear la visión del proyecto (Product Vision
Board).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

83

83

Proceso 3 - Formar al equipo Scrum

Entre 6 y 10 miembros
Generalistas - Especialistas

84

84

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 42
 Fases de Scrum - Inicio
Crear la visión del proyecto (Project Vision).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

85

85

Proceso 4 - Desarrollar Épicas

En este proceso, se realizan reuniones con los grupos de usuarios
y clientes para definir los objetivos de alto nivel que permitirán
cumplir con la visión del proyecto.
Una Épica son requisitos de alto nivel, que podrían ser muy
grandes abordados en un Sprint y deben ser desagregados en
historias de usuarios que si puedan desarrollarse en un Sprint.
Una Persona es una caracterización ficticia de un grupo de
usuarios o stakeholders, que sirve para identificar épicas basadas
en sus necesidades
El responsable es el Dueño del Producto, sin perjuicio que los
miembros del equipo puedan colaborar.

86

86

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 43
 Ejemplo de Persona
Persona Primaria

Julián Sánchez.
“Fido es mi compañía más fiel ”

Objetivos prácticos:
•Minimizar el riesgo que Fido (mi perro) se pierda
Objetivos personales:
•Disfrutar de un compañero fiel y ameno

Foto de Flickr, todos los derechos reservados.

•Datos personales Tareas típicas en Internet:

Vista rápida sobre Julián •Edad 32 años •Revisar correos electrónicos
Habilidades •Titulación IEBS •Investigar temas técnicos
(informáticas) Experto
•Dónde vive Quiro •Compartir en redes sociales
•Estado civil Casado con Marta Pérez •Comprar
•Dónde trabaja: acaba de crear una
Empleo (Situación) Empresario Startup
•Hijos No tienen aún, ambos trabajan
Sus frases:
“Mi pasatiempo favorito es jugar con FIDO, con él nunca tengo discusiones”

Acceso a internet Permanente

habitual
Ordenador Mac Book Pro ¿Quién es Julián?
Julián es un exitoso empresario que desarrolló una Start Up. Su esposa Marta es una destacada
ejecutiva de un Banco.
Apps Ordenador MS Office
habituales Tienen muy poco tiempo libre, y les encanta jugar con Fido.

Móvil iPhone
Sin embargo, Fido es muy juguetón y como lo dejan todo el día solo, temen que se pueda
Apps Móvil habituales Spotify extraviar
Facebook
Tablets iPad
Apps Tablets Spotify
habituales Facebook

87

Ejemplo de Épicas
Conocer ubicación mascota
Enrolar mascota
Consultar servicios para mascota

88

88

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 44
 Ejercicio - Caso de Estudio
Para el caso “Faster Foods”
Identificar 3 PERSONAS
Identificar 10 épicas

89

89

Fases de Scrum - Inicio

Crear la visión del proyecto (Project Vision).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

90

90

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 45
 Proceso 5 - Crear Backlog de Producto Priorizado
Es una lista de las funcionalidades deseadas
Épicas
Otras características
Mantenida por el Product Owner
Priorizada
Valor para el negocio
Riesgo
Dinámica:
Se pueden añadir funcionalidades
Se pueden eliminar funcionalidades
Reorganización cada vez que se incluye o elimina una funcionalidad
A partir del Product Backlog se construyen las historias de usuarios
91

91

Proceso 5 - Crear Backlog de Producto Priorizado

En este proceso, las épicas son refinadas para crear el product backlog
priorizado y definir el criterio de “Terminado”.

Técnicas de priorización:
Esquema de Priorización MoSCoW. Se analizan las épicas
considerando los siguientes criterios “Must have”, “Should have”,
“Could have” y “Will not have” (Won’t have now but Would be
later).

92

92

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 46
 Proceso 5 - Crear Backlog de Producto Priorizado
Técnicas de priorización:

Método de los 100 Puntos. Se trata de darle al customer 100

puntos que pueden usar para votar por las épicas que son más
importantes. El objetivo es dar más peso a las épicas
que son de mayor prioridad en comparación con las otras épicas
disponibles. Cada miembro del grupo asigna puntos a las diversas
épicas, dando más puntos a los que se sienten son
más importantes. Al finalizar el proceso de votación, la priorización
se determina calculando el total de puntos asignados a cada
épicas.

93

93

Proceso 5 - Crear Backlog de Producto Priorizado

Técnicas de priorización:
Analysis de Kano. Se clasifican requerimientos en
Entusiasmantes: (Si está se valora, pero si no está es
indiferente).
Satisfactores: (Si está se valora y si no está perjudica).
Mínimos (Si está no se valora, pero si no están, perjudican).
Indiferentes

Comparación de pares. Los requerimientos son comparados en

pares, debiendo priorizar uno sobre el otro.

94

94

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 47
 Fases de Scrum - Inicio
Crear la visión del proyecto (Project Vision).

Identificar al Scrum Master e interesados.

Formar al Equipo Scrum.

Desarrollar Épicas.

Crear Backlog de productos priorizado.

Conducir planificación de entregas.

95

95

Proceso 6 - Conducir planificación de Release

Establece qué entregables recibirán los usuarios en el tiempo.
Se define el largo de los SPRINTS
Usualmente permanece constante durante el proyecto
El largo del Sprint puede ir de 1 a 6 semanas, sin embargo se
recomienda que no sea más de 4, y mientras más corto mejor
El plan se hace de manera que cada “release” provea valor
significativo para el cliente.

96

96

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 48
 Ejercicio - Caso de Estudio
Tomando como base las épicas identificadas en el caso anterior,
genere un Product Backlog priorizado

Elija alguna de las técnicas de priorización revisadas en clase

97

97

Módulo 5
Fase de Planificación

© TenStep, inc
ProviderID: 1774

98

98

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 49
 Programa del Curso

√ Introducción a Agile El Ciclo Scrum:

√ Introducción a Scrum Planificación Estimación
Historias de Usuario
√ Equipo de Proyecto
Implementación
√ Fases de Scrum Revisión y Retrospectiva
√ Inicio del Proyecto Release
√ Product Backlog Adopción
√ Priorización Examen de Scrum Master

99

99

Fases de Scrum

Ante- Implemen- Revisión y

Inicio Planificación Release
proyecto tación Restrospectiva

100

100

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 50
 Fases de Scrum - Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer Historias

de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

101

101

Proceso 1 - Crear Historias de Usuario

En este proceso, se elaboran y documentan las Historias de Usuario
que aseguran el cumplimiento de los requisitos.
El Product Owner es el responsable de crear las historias de
usuario.
Las Historias de Usuario permiten hacer una conexión entre la
característica, el rol del usuario y los beneficios que traerá al
negocio.
Una Historia de Usuario es una descripción corta de la
funcionalidad que debe proveer el sistema que se esta
desarrollando.

102

102

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 51
 Proceso 1 - Crear Historias de Usuario
Una Historia de Usuario es una herramienta de comunicación
entre quien define el producto (típicamente el Product Owner) y
el equipo de desarrollo.
También es útil para las pruebas
Se escriben desde el punto de vista de un usuario. Por ejemplo,
para una aplicación para tomar fotos:
Como Usuario, quiero tomar una foto, para venderla

103

103

Proceso 1 - Crear Historias de Usuario

Identificar PERSONAS o roles que interactúan con el sistema y
pensar que necesitan del sistema
Por ejemplo en el sistema fotográfico podríamos tener 4 roles:
Fotógrafo
Comprador
Vendedor
Administrador del sistema
Ejemplos de historias de usuario
Como fotógrafo, quiero sacar fotos para poder venderlas
Como vendedor, quiero definir el precio para una foto, para establecer el
listado de precios de venta al público
Como comprador, quiero poder comprar una foto para imprimirla
Como administrador, quiero poder borrar una foto, para que estas
cumplan con los términos y condiciones 104

104

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 52
 Proceso 1 - Crear Historias de Usuario (Ejemplo)
“Como <Rol>, quiero <Objetivo/Funcionalidad> para que <Razón/Resultado>

Título Criterios de aceptación

Descripción

Estimación

105

105

Calidad Historias de Usuario - Técnica “INVEST"

Valiosa
Estimable
Negocia-
Indepen ble
diente
Tamaño
apropia
do
Certifica
ble

Historia de Usuario

*INVEST: Modelo Propuesto por Mike Cohn and Bill Wake (2003) 106

106

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 53
 Generación de Historias de Usuario
Nueva funcionalidad
Cambios sobre funcionalidad existente
Un error, cuya resolución pueda ser demasiado compleja
Feedback de Usuarios
Test de usabilidad

107

107

Historias de Usuario - Criterios de Aceptación

Proporcionan la objetividad requerida para que la Historia de
Usuario sea considerada “Terminada”.
Proporcionan claridad al equipo, eliminando ambigüedad en los
requisitos.
El Scrum Master debe asegurar que el Product Owner no cambie los
criterios de aceptación durante un sprint.
Ayuda a la alineación de expectativas con el Product Owner como
representante del cliente.
Ayuda a entender al equipo como se espera que se comporte el
producto.
Facilita el proceso de estimación.

108

108

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 54
 Historias de Usuario - Criterios de Aceptación
Los criterios de aceptación no tienen porqué estar listos al mismo
tiempo que la historia, si bien es necesario que estén definidos
antes de comenzar su construcción
Si estamos trabajando en papel, los criterios de aceptación se
escriben en la parte posterior de la tarjeta
Sirven de guía para las pruebas
Deben cubrir tanto “el camino feliz” como “casos extremos”
Ejemplo “camino feliz”
El usuario hace una foto y esta se hace y se guarda con éxito
Ejemplo “caso extremo”
El usuario está haciendo una foto y en ese momento se queda
sin batería. El sistema debe alertar esta situación. 109

109

No confundir con Criterio de Término

(Done Criteria o Definition of Done)
Una lista de verificación de actividades que deben estar realizadas
para aceptar todas las historia de usuario
Son únicas dentro de un Proyecto
En cambio, los criterios de aceptación son propios de cada Historia de
Usuario
Se definen en la Planificación de Release
Ejemplo:
Código escrito
Código comentado
Test unitario
Test de Integración
Notas de release
110

110

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 55
 Ejercicio - Caso de Estudio
Para las épicas de mayor prioridad definidas por cada equipo,
identifique al menos 5 historias de usuario
Utilizar la estructura aprendida en clase.
Definir los criterios de aceptación para dos historias de usuario
Defina el Criterio de Término (Done Criteria o Definition if Done)

111

111

Fases de Scrum - Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer Historias

de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

112

112

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 56
 Proceso 2 - Aprobar, Estimar y Comprometer
Historias de Usuarios
En este proceso, el Product Owner aprueba las Historias de Usuario,
para que luego, el Scrum Master y Equipo Scrum estimen el esfuerzo
necesario para desarrollar la funcionalidad descrita en cada una y se
comprometen a cuales de ellas hacer en el Sprint.

El Product Owner es el responsable de asegurar que las historias

de usuario aprobadas agregan valor al cliente.
El Equipo Scrum utiliza distintas técnicas de estimación para
valorar el esfuerzo de cada historia y puedan ser comprometidas
en el sprint.

113

113

Puntos de Historia o Tamaño Relativo

Las estimaciones en Scrum se realizan midiendo el tamaño relativo de una
historias de usuario o característica en comparación con otra.
Se define un puntaje asociado a cada historia de usuario basado en riesgo,
esfuerzo y nivel de complejidad.
Se debe utilizar el mismo criterio, de tal manera que una historia de usuario que
tiene 2 puntos es el doble de compleja que una que tiene un punto.
Es muy útil para medir la productividad del equipo y como ella va
evolucionando.
Velocidad
Cantidad de Puntos de Historia por Sprint

114

114

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 57
 Técnicas de Estimación: Wideband Delphi
Cada persona hace una estimación anónima sobre su estimación
de esfuerzo para cada funcionalidad
Las estimaciones se escriben en un gráfico
Se discuten los resultados
Se hace una segunda ronda
El proceso se repite hasta que se obtiene consenso, o mucha
cercanía en las estimaciones.

115

115

Técnicas de Estimación: Planning Poker

Es una variación del Wideband Delphi
Se junta a todo el equipo alrededor de una mesa y se les entrega un juego de
cartas con la escala a utilizar. Cada número representa la complejidad, en
términos de esfuerzo
El Product Owner lee la historia a estimar a todo el equipo. El Equipo Scrum
puede hacer preguntas orientadas a entender la complejidad
Cada miembro del equipo, incluido el Product Owner, escoge una carta.
Se descartan estimaciones mínimas y máximas. Los miembros que difieren
explican sus motivos. Se repite el ejercicio hasta tener consenso o cercanía

116

116

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 58
 Técnicas de Estimación: Fist of Five
Mecanismo rápido para alcanzar consenso
Después de una discusión inicial de una propuesta, cada uno vota en una escala
de 1 a 5 usando sus dedos:
Un dedo: Estoy en completo desacuerdo con la decisión: tengo
observaciones graves
Dos dedos: Estoy en desacuerdo, quisiera discutir algunos temas
Tres dedos: No estoy seguro
Cuatro dedos: Estoy de acuerdo, pero quisiera discutir algunos aspectos
Cinco dedos: Estoy totalmente de acuerdo

117

117

Técnicas de Estimación: Estimación por Afinidad

El equipo coloca las tarjetas que corresponden a cada historia de usuario, sobre
una superficie, en orden de más simple a más compleja.
Al principio, cada miembro del equipo toma un subconjunto de historias de
usuario del Product Backlog y las va colocando. Esto se hace en silencio.
Una vez que esta hecho, el equipo revisa y hace las adecuaciones que estime
necesarias. En esta parte, hay discusión.
Finalmente, el Product Owner define ciertas categorías (por ejemplo: Pequeña,
mediano o grande) y el equipo asocia cada historia de usuario a una categoría.

118

118

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 59
 Ejercicio - Caso de Estudio
Cada equipo deberá estimar las historias utilizando para ello la
técnica de Planning Poker.
Utilizar la aplicación para smartphone “Scrum Poker Cards”.

119

119

Fases de Scrum - Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer Historias

de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

120

120

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 60
 Proceso 3 - Crear Tareas
En este proceso, las Historias de Usuario aprobadas son desagregadas
en tareas específicas por el Equipo Scrum y se compilan en una lista.
Para ello, se realiza una reunión de Planificación del Sprint (Sprint
Planning).

La definición de las tareas - Específico

deben cumplir con el criterio: - Medible
-Alcanzable
- Realista
- Acotado en el tiempo

121

121

Proceso 3 - Reunión de Planificación del Sprint

4 Horas para un Sprint de 1 mes

Qué
Product Backlog
Capacidades del
equipo Objetivo Sprint
Reunión de Planificación
Condiciones de negocio
Del Sprint Sprint Backlog
Tecnología

Producto Actual
Cómo

4 Horas para un Sprint de 1 mes

122

122

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 61
 Fases de Scrum - Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer Historias

de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

123

123

Proceso 4 - Estimar tareas

En este proceso, el equipo de Scrum estima el esfuerzo requerido
en la ejecución de cada tarea. Se desarrolla en la reunión de
planificación del sprint.
El resultado de este proceso es la lista de tareas actualizada con el
esfuerzo estimado en horas para su desarrollo.
La información resultante también determina la velocidad del
equipo.

124

124

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 62
 Fases de Scrum - Planificación y Estimación

Crear Historias de Usuarios.

Aprobar, Estimar y Comprometer Historias

de Usuarios.

Crear Tareas.

Estimar tareas.

Crear Sprint Backlog.

125

125

Proceso 5 - Crear el Sprint Backlog

El sprint backlog muestra la lista de tareas creadas y estimadas para
desarrollar durante el sprint
Plan para completar los objetivos
Representa el compromiso del equipo durante la iteración
Cambios:
El equipo puede añadir tareas para cumplir con el objetivo del sprint
El equipo puede eliminar tareas innecesarias
El Sprint Backlog solo puede ser actualizado por el equipo scrum
Las estimaciones se actualizan cada vez que se produce una nueva
información

126

126

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 63
 Proceso 5 - Crear el Sprint Backlog
Es una práctica habitual representarlo como un Scrum Board, muy
útil para el seguimiento y visibilidad

127

127

Proceso 5 - Crear el Sprint Backlog

También se genera el “Gráfico del Trabajo Consumido del Sprint”
(Sprint Burndown Chart)

128

128

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 64
 Módulo 6
Fases: Implementación,
Revisión y Retrospectiva

© TenStep, inc
ProviderID: 1774

129

129

Programa del Curso

√ Introducción a Agile El Ciclo SCRUM:

√ Introducción a Scrum √ Planificación Estimación
√ Historias de Usuario
√ Equipo de Proyecto
Implementación
√ Fases de Scrum
Revisión y Retrospectiva
√ Inicio del Proyecto Release
√ Product Backlog Adopción
√ Priorización Examen de Scrum Master

130

130

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 65
 Procesos de la fase de implementación

Crear Entregables.

Conducir reuniones de trabajo diario.

Ajustar Backlog de productos priorizado.

131

Procesos de la fase de implementación - 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:
El Scrum Master es el responsable de asegurar que no existan cambios que
modifiquen el objetivo del Sprint.
Las metas del equipo y los objetivos de calidad se mantienen constantes, no
disminuyen.
Solo el Product Owner puede cancelar el Sprint.
Los Sprints contienen y consisten en la Reunión Diaria, el trabajo de desarrollo,
la Revisión del Sprint, y la Retrospectiva del Sprint.
El alcance puede clarificarse y renegociarse entre el Dueño de Producto y el
Equipo de Desarrollo a medida que se va aprendiendo más.

132

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 66
 Procesos de la fase de implementación

Crear Entregables.

Conducir reuniones de trabajo diario.

Ajustar Backlog de productos priorizado.

133

Proceso 1 - Crear Entregables

En este proceso, el Equipo Scrum ejecuta las actividades requeridas para obtener los
entregables definidos para el Sprint.
El esfuerzo principal recae en el Equipo Scrum , cuyos miembros se auto-
organizan para tomar decisiones en relación la forma de desarrollar los
entregables
El Product Owner actúa como un puente entre el equipo Scrum y los
interesados, proveyéndolos de información relevante para el desarrollo de los
entregables.
El Scrum Master es el responsable de asegurar que durante el desarrollo del
Sprint no existan impedimentos para los miembros del equipo.
Ni los interesados, ni el Scrum Master ni el Product Owner pueden dirigir al
equipo en la forma de desarrollar los entregables.
No se pueden hacer cambios al alcance del Sprint. En caso de ser necesario, se
deben dejar en el Product Backlog
En la medida que se avanza se debe actualizar el Scrumboard
134

134

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 67
 Procesos de la fase de implementación

Crear Entregables.

Conducir reuniones de trabajo diario.

Ajustar Backlog de productos priorizado.

135

Proceso 2 - Conducir Reunión diaria (Daily Standup

Meeting)
Reunión con un bloque de tiempo de 15 minutos para que el Equipo Scrum
sincronice sus actividades y cree un plan para las siguientes 24 horas.
En este proceso, se promueve la colaboración entre los distintos miembros
que integran el Equipo Scrum.
Se realiza a la misma hora y en el mismo lugar todos los días para reducir la
complejidad.
Se espera la asistencia de todo el equipo, pero si alguien falta no se cancela

136

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 68
 Proceso 2 - Conducir Reunión diaria (Daily Standup
Meeting)
Durante la reunión, cada miembro del Equipo de Desarrollo explica:
¿Qué hice ayer?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
¿Estoy enfrentando algún obstáculo o impedimento?
El Scrum Master es solo un facilitador

137

Proceso 2 - Conducir Reunión diaria (Daily Standup

Meeting)
Debe ser una reunión “cara a cara”. Se realiza de pie.
La reunión no puede ser reemplazada por intercambios de correo electrónico.
Es una reunión de transmisión de información.
Cualquier discusión o resolución de problemas se debe hacer después.
El Scrum Master recolecta información sobre los problemas e impedimentos y,
posteriormente, se ocupa de su resolución .
Se ocupa para:
Mejora la comunicación: todo el equipo sabe el estado del proyecto
Identificar impedimentos.
Mejora el nivel de conocimiento de todo el equipo.
Ayuda a incrementar la probabilidad de que el equipo cumpla con los
objetivos del Sprint.
Promueven la toma de decisiones rápida.
138

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 69
 Procesos de la fase de implementación

Crear Entregables.

Conducir reuniones de trabajo diario.

Ajustar Backlog de productos priorizado.

139

Proceso 3 - Ajustar Backlog de Producto Priorizado

En este proceso, se realiza el refinamiento requerido al Backlog del producto,
añadiendo o cambiando elementos al Product Backlog como consecuencia de
cambios en los requerimientos o para detallar más las Historias de Usuario del
próximo Sprint.

Es un proceso continuo, responsabilidad del Product Owner.

Se examinan y revisan los elementos del Product Backlog, detallando
especialmente lo que se desarrollará el próximo Sprint.
También se hacen repriorizaciones basados en la opinión del cliente, cambios
externos y conocimiento ganado durante el proyecto.
Usualmente consume entre el 7% y el 10% del tiempo del Sprint.
Los elementos del Backlog del Producto pueden ser actualizados en cualquier
momento por el Product Owner.

140

140

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 70
 Procesos de la fase de revisión y retrospectiva

Convocar Scrum de Scrums.

Demostrar y validar el sprint.

Retrospectiva del sprint.

141

Proceso 1 - Convocar Scrum de Scrums

Este proceso solamente aplica para grandes proyectos donde hay múltiples equipos
Scrum lo cual permite asegurar la coordinación del trabajo a realizar.

Los proyectos grandes pueden tener múltiples equipos de scrum trabajando

paralelamente por lo que es necesario sincronizarse y facilitar el flujo de
información para mejorar la comunicación.

142

142

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 71
 Proceso 1 - Convocar Scrum de Scrums
Es aplicable a proyectos grandes con más de un equipo Scrum.
Es una reunión de coordinación entre los diferentes equipos Scrum.
Asisten los Scrum Master de cada equipo Scrum.
Se establecen intervalos predeterminados para realizar la reunión de acuerdo a
las necesidades del equipo.
Se puede tornar compleja dependiendo de las distintas capas en las que se
desarrolle, por tanto, la comunicación es un factor clave en el proceso.

143

143

Proceso 1 - Convocar Scrum de Scrums

Es análogo al Daily Standup.
Existe un Scrum Master Jefe que facilita
Cada equipo entrega información sobre las siguientes preguntas:
¿En qué ha trabajado mi equipo desde la última reunión?
¿Qué hará mi equipo hasta la próxima reunión?
¿Qué cosas qué otros equipos esperaban del nuestro están pendientes
aún?
¿Qué cosas qué nuestro equipo espera hacer pueden afectar a otros
equipos?

144

144

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 72
 Procesos de la fase de revisión y retrospectiva

Convocar Scrum de Scrums.

Demostrar y validar el sprint.

Retrospectiva del sprint.

145

Proceso 2 - Demostrar y validar Sprint

En este proceso el Equipo Scrum presenta o demuestra los entregables obtenidos del
Sprint al Product Owner, y otros interesados, quien valida el cumplimiento de los
requerimientos según los criterios de aceptación definidos.

Reunión restringida a un bloque de tiempo de 4 horas para Sprints de un

mes.
Participa el equipo de Scrum, el Product Owner y otros interesados.
Como resultado de la reunión se aprueba o rechaza los ítems del Sprint
Backlog

146

146

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 73
 Proceso 2 - Demostrar y validar Sprint
La Revisión de Sprint incluye los siguientes elementos:

El Equipo de Desarrollo hace una demostración del trabajo que ha

“Terminado” y responde preguntas acerca del Sprint.
Solo se pueden presentar funcionalidades que cumplen con los Criterios de
Término. El trabajo en proceso queda para el siguiente Sprint.
Se revisa el cumplimiento de los Criterios de Aceptación.
Los ítems no aceptados permanecen en el Product Backlog.
Es responsabilidad del Scrum Master que el Product Owner no modifique
requerimientos o criterios de aceptación. En caso de querer hacerlo, se
acepta el entregable y el cambio va al Product Backlog.

147

147

Procesos de la fase de revisión y retrospectiva

Convocar Scrum de Scrums.

Demostrar y validar el sprint.

Retrospectiva del sprint.

148

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 74
 Proceso 3 - Retrospectiva del Sprint
La Retrospectiva de Sprint 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.

Con esta reunión se pretende:

Inspeccionar cómo fue el último Sprint en
cuanto a personas, relaciones, procesos y
herramientas.
Identificar y ordenar los elementos más
importantes que salieron bien y las
posibles mejoras.
Crear un plan para implementar las
mejoras a la forma en la que el Equipo
Scrum desempeña su trabajo.

149

149

Proceso 3 - Retrospectiva del Sprint

Etapas de la reunión
Preparar el escenario
Bienvenida, objetivos, calibrar el ánimo general
Reunir información
Compartir visiones de las fortalezas y debilidades del trabajo
Generar visión
Discutir porque ciertas cosas andan bien y otras andan mal
Acción
Discutir como mejorar las cosas en futuros sprint
Círculo de preguntas y cierre

150

150

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 75
 Proyecto Villa Financiera.

151

151

Ejercicio de Simulación: “Diseño Villa Financiera”

10 minutos

3 min.

45 - 60 min.
3 días
Construir
Product
Backlog 10 minutos
30 minutos

30 minutos

Se realizarán 2 ciclos de trabajo (Sprints)

152

152

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 76
 Visión “Villa Financiera”
Construir un modelo 3D de una “Villa Financiera” la cual contenga las facilidades
básicas propias de una ciudad, permitiendo realizar negocios con los principales
sectores de la economía del país.
Requisitos mínimos:
4 Edificios tipo rascacielos
10 edificios de mediana altura
1 Hotel
1 Museo
1 Lugar para comer
1 centro de convenciones y exposiciones
1 Parque acuático
Calles y avenidas con intersecciones
1 medio de transporte elevado
1 lugar de entretención
153

153

Módulo 7
Fase Entrega

© TenStep, inc
ProviderID: 1774

154

154

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 77
 Programa del Curso

√ Introducción a Agile El Ciclo SCRUM:

√ Introducción a Scrum √ Planificación Estimación
√ Historias de Usuario
√ Equipo de Proyecto
√ Implementación
√ Fases de Scrum
√ Revisión y Retrospectiva
√ Inicio del Proyecto Release
√ Product Backlog Escalabilidad en Scrum
√ Priorización Adopción
Examen de Scrum Master

155

155

Fases de SCRUM

Ante- Implemen- Revisión y

Inicio Planificación Release
proyecto tación Restrospectiva

156

156

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 78
 Procesos de la fase de entrega

Enviar los entregables.

Retrospectiva del proyecto.

157

Proceso 1 - Enviar los Entregables (Release)

En este proceso, los entregables aceptados se les entregan o trasladan a los
involucrados pertinentes. Un documento de aceptación formal declara la finalización
con éxito de Sprint.

Cada sprint no necesariamente finaliza con el lanzamiento del producto.

La decisión de las fechas de lanzamiento se toma en el proceso “Conducir

planificación de Entregas” (Fase de Inicio)

El Plan de Releases indica que entregables se van a generar y cuando

Cada organización tiene sus propios métodos de despliegue para sus

productos, lo cual incluye procesos de revisión y aprobación.

158

158

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 79
 Proceso 1 - Enviar los Entregables
Las herramientas utilizadas en este proceso son:

Métodos organizacionales de transición/despliegue:

Difieren dependiendo de la industria
El despliegue o transición puede hacerse de forma remota
Son mecanismos bien definidos por la organización para garantizar el
cumplimiento de las normas de calidad y minimizar los riesgos de
implementación.
Incluye: Aprobación de documentos del proyecto y del producto que
registren la aceptación por parte del patrocinador o del cliente sobre los
objetivos alcanzados.

159

159

Procesos de la fase de entrega

Enviar los entregables.

Retrospectiva del proyecto.

160

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 80
 Proceso 2 - Retrospectiva del proyecto
En este proceso, que completa el proyecto, los involucrados de la organización y el
Equipo Scrum se reúnen para la retrospectiva del proyecto para identificar,
documentar e internalizar las lecciones aprendidas.

Las lecciones aprendidas buscan determinar en que aspectos el equipo puede

mejorar su efectividad y niveles de colaboración para futuros proyectos.

Se definen un plan de acción para el mejoramiento en torno a la práctica de

Scrum dentro de la organización.

161

161

Proceso 2 - Retrospectiva del proyecto

La herramienta principal de este proceso es:

Reunión de retrospectiva del proyecto:

No es una reunión con un tiempo determinado.
Busca determinar las oportunidades de mejora del Equipo Scrum.
Se puede realizar “Cara a Cara” o de manera remota.
Entre los asistentes figuran el Equipo Scrum, Scrum Master, Producto
Owner, e involucrados.
Identificación de lecciones aprendidas para mejorar procesos e ineficiencias
presentes.

162

162

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 81
 Módulo 8
Escalabilidad en Scrum

© TenStep, inc
ProviderID: 1774

163

163

Programa del Curso

√ Introducción a Agile El Ciclo SCRUM:

√ Introducción a Scrum √ Planificación Estimación
√ Historias de Usuario
√ Equipo de Proyecto
√ Implementación
√ Fases de Scrum
√ Revisión y Retrospectiva
√ Inicio del Proyecto √ Release
√ Product Backlog Escalabilidad en Scrum
√ Priorización Adopción
Examen de Scrum Master

164

164

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 82
 Escalabilidad en SCRUM
Tamaño ideal de un equipo SCRUM: entre 6 y 10 personas

Si se requiere aplicar en proyectos más grandes: varios equipos SCRUM en

paralelo

Usualmente los proyectos grandes se implementan como Programas o

Portafolios

La sincronización se logra a través de las reuniones de Scrum de Scrum, en las

cuales cada equipo:
Informa de su avance
Discute los desafíos que ha enfrentado en el proyecto
Coordina actividades con otros equipos

165

165

Roles Scrum en Programas y Portafolios

Surgen los siguientes roles:

Product Owner del Programa o Portafolio

Define los objetivos y las prioridades estratégicas para el Programa.

Scrum Master del Programa o Portafolio

Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo reuniones
para el Programa.

El foco de los roles está en satisfacer las necesidades de conjunto del Programa o
unidad de negocio, y no los de un solo equipo Scrum

166

166

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 83
 Scrum en Programas y Portafolios
Cuerpo de Portafolio
Asesoramiento de • Administra los programas y proyectos.
Scrum • El trabajo a realizar es contenido en el Backlog del Portafolio.
• Conduce la reunión para la revisión del Backlog Priorizado de Portafolio cada 4
• Opcional meses durante el año.

• Puede ser un Programa

conjunto de • Administra los proyectos relacionados.
documentos y/o • El trabajo a realizar es contenido en el Backlog del Programa.
grupo de expertos • Conduce la reunión para la revisión del Backlog Priorizado de Programa con
periodicidad entre 2 y 6 meses
• Define objetivos
relacionados a
Proyectos
calidad, Seguridad y
• Proyectos gerenciados por un Equipo Scrum.
otras variables
• Un proyecto puede tener uno o más Equipos Scrum.
• El trabajo a realizar es contenido en el Product Backlog.
• Utilizado por el
• El tiempo para completar el trabajo de un SPRINT es entre 1 a 4 semanas.
Equipo Scrum
• Si hay varios equipos, se utiliza la reunión de Scrum de Scrums (SoS) para
cuando es necesario
coordinarse y comunicarse entre los distintos Equipos Scrum.
para su trabajo.
167

167

Reunión Scrum de Scrums (SoS)

168

168

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 84
 Marcos de referencia para escalar métodos ágiles

Enterprise Scrum
DAD
LeSS
SAFe
Tribal Leadership
RAGE

169

SAFe - Scaled Agile Framework

Scaled. Adaptación a los niveles más altos de la organización.
Agile. Un marco de trabajo, basado en valores, guiado por principios expresados
en herramientas y prácticas.
Framework. Una estructura de soporte que propone guiar la construcción del
marco de trabajo ágil de manera extendida en toda la organización.

Estratégico (Portafolio - Alta

Gerencia)

Táctico (Programas - Áreas de

Negocio / Sponsor)

Operacional (Proyectos - Equipos

Scrum)

170

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 85
 171

171

Módulo 9
Consideraciones en la
adopción de métodos ágiles

© TenStep, inc
ProviderID: 1774

172

172

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 86
 Programa del Curso

√ Introducción a Agile El Ciclo SCRUM:

√ Introducción a Scrum √ Planificación Estimación
√ Historias de Usuario
√ Equipo de Proyecto
√ Implementación
√ Fases de Scrum
√ Revisión y Retrospectiva
√ Inicio del Proyecto √ Release
√ Product Backlog √ Escalabilidad en Scrum
√ Priorización Adopción
Examen de Scrum Master

173

173

Ejercicio en grupo
Qué prácticas ágiles se pueden implementar desde ya en su
organización.
¿Cuáles son los factores que facilitan la adopción de agilidad en
su organización.
¿Cuáles son los factores que dificultan la implementación de la
agilidad en su organización?

174

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 87
 ¿Está mi organización lista para adoptar métodos agiles?

¿La empresa trabaja en equipo, delega, promueve la creatividad y mejora continua?

175

¿Está mi organización lista para adoptar métodos agiles?

¿Cuál es el nivel de involucramiento de nuestros clientes en los proyectos?

176

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 88
 ¿Está mi organización lista para adoptar métodos agiles?

¿La dirección de la empresa cree en el valor de la

gente, fomentando la colaboración, la
autogestión y la conformación de equipos
multidisciplinares?

177

¿Está mi organización lista para adoptar métodos agiles?

¿Somos capaces de comprometernos con

otros y de colaborar para alcanzar un
objetivo común?

178

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 89
 ¿Está mi organización lista para adoptar métodos agiles?

¿Estamos dispuestos a flexibilizar los cambios y aceptarlos de manera natural?

179

Desafíos
Cambio Paradigma
De alcance fijo a Tiempo fijo
Gobernabilidad
Nivel Portafolio
Adecuar métricas
Tipos de Contrato
No Precio Fijo
Opciones
Time and Material (muy riesgosa)
Costo reembolsable más incentivos (compartir riesgo)
Por unidad

180

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 90
 ¿Qué se requiere de las organizaciones para que la
implementación sea exitosa?

181

¿Cómo implementar?
• Seleccionar equipo de adopción
• Motivar
• Capacitar
• Acompañar
• Evaluar
• Comunicar, Comunicar, Comunicar

• Convencer
• Capacitarse
• Pedir Ayuda
• Evaluar
• Compartir
• Comunicar, Comunicar, Comunicar

182

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 91
 Implementar Scrum es un proyecto
Genere un Backlog priorizado de los elementos de Scrum a ser
introducidos y priorícelos
¿Cuáles de ellos generarán mayor impacto?
¿Cuáles de ellos pueden ser adoptados con mayor facilidad?
¿Puede tener equipos multifuncionales?
¿Puede desarrollar incrementalmente?
¿Puede comenzar con algunos equipos?

183

Resistencia al Cambio
Especialmente de quienes pierden poder o autoridad
El rol del Jefe de Proyecto se divide en los tres roles
centrales
Pueden no entender su nuevo rol y como contribuir al éxito del
equipo
La gente que ha invertido en las metodologías tradicionales
también puede resistir

184

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 92
 Manteniendo el compromiso de los Stakeholders
Informe adecuadamente a todos los cambios en la forma de
trabajo
Establezca un acuerdo de trabajo de colaboración
Comunique los progresos del equipo y el desarrollo de
capacidades, de manera de generar expectativas realistas acerca
de alcance, tiempo y costo

185

Soporte Ejecutivo
Comuníquese regularmente con quienes financian el proyecto
implementación de Scrum
Es importante que conozcan:
Los beneficios de implementar Scrum
Los costos y fechas de la transición
Cuáles son los riesgos de la transición
Manténgalos conscientes del nivel de avance y resultados
obtenidos
Infórmelos de cualquier problema, especialmente los que pueden
afectar los resultados de los proyectos

186

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 93
 Ejercicio - Retos en la adopción
Trabajo en equipo
Discusión: ¿Cuáles son los problemas potenciales que enfrentarás
en la organización para adoptar la metodología Scrum?
¿Cuál de ellos es el más crítico y por qué?
¿Qué estrategia usarías para resolverlo?

187

187

¿Cuán difícil es abordar los siguientes temas durante

la adopción de métodos ágiles?
Más difícil Cambiar nuestra cultura de negocio

Adopción de técnicas y prácticas ágiles

Cambiar nuestra cultura de TI

Usar las herramientas existentes de una manera ágil

Adoptar nuevas herramientas ágiles de desarrollo

Adoptar prácticas de gestión ágiles

Menos difícil
188

188

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 94
 Programa del Curso

√ Introducción a Agile El Ciclo SCRUM:

√ Introducción a Scrum √ Planificación Estimación
√ Historias de Usuario
√ Equipo de Proyecto
√ Implementación
√ Fases de Scrum
√ Revisión y Retrospectiva
√ Inicio del Proyecto √ Release
√ Product Backlog √ Adopción
√ Priorización Examen de Scrum Master

189

189

Examen de Scrum Master

190

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 95
 191

192

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 96
 193

194

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 97
 195

196

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 98
 197

197

ProyectumTraining Center
www.proyectum.com / contacto@cl.proyectum.com 99