20/11/2019

LECCION-01
Ing. Cristian Barquero, MAP, SMAC, ITIL, PMP®,PMI-ACP®
Agile Coach Professional Certificate
• Skype: c_barquero@[Link]
• WhatsApp: 8445-7993

Logo
Presentación y Logística Partner

1
 20/11/2019

Presentación y Logística

• Nombre • Horario
• Profesión • Instalaciones
• Empresa • Recesos
• Rol en su Compañía • Normas para dispositivos de
• Objetivos al tomar el curso comunicación móvil y PDAs.
• Qué sabe de Scrum • Material

2
 20/11/2019

Logo SCRUM MASTER PROFESSIONAL

Partner CERTIFICATE (SMPC)

Logo
Partner

3
 20/11/2019

Objetivos

Alcance, propósito, términos y definiciones clave para Scrum Master Professional

Certificate (SMPC) y cómo puede ser utilizado.

Certificación profesional

7
7

Introducción

Los proyectos se ven afectados por las limitaciones de

tiempo, costo, alcance, calidad, recursos, capacidades
organizativas y otras limitaciones que los hacen difíciles de
planificar, ejecutar, administrar y finalmente tener éxito.

4
 20/11/2019

Porqué Ágil?

Siete de cada diez empresas confían en la metodología 'agile'

pmnetwork/february_2018

10

5
 20/11/2019

Procesos de Ingeniería de Software

11

11

Procesos de Ingeniería de Software

• Requerimientos
• Diseño
• Codificación
• Integración
• Testeo
• Mantenimiento

12

6
 20/11/2019

Cascada

13

Cascada

14

7
 20/11/2019

Gestión de Proyectos tradicional

Ventaja:
Orden Lógico
Desventaja:
Asume Predictibilidad

15

Tipos de Proyectos

Lejos de acuerdos

En el eje horizontal tenemos

la experiencia y nuestro
conocimiento sobre una
Cerca de acuerdos
herramienta; en el eje vertical
se plasma la claridad de los
requerimientos
Cerca de

Lejos de
certeza

certeza

16

8
 20/11/2019

17

• El manifiesto Ágil surge el 17 de febrero del

2001, cuando se reunieron diecisiete
críticos del desarrollo de software, y
acuñaron el término “metodología Ágil”
para definir a los métodos que estaban
surgiendo como alternativa a las
metodologías formales.
• El manifiesto Ágil está conformado por 12
principios asociados a 4 pilares
REF: [Link]

18

9
 20/11/2019

19

12 Principios del Manifiesto Ágil

I. La mayor prioridad es satisfacer al cliente a través
de la entrega temprana y continua de software
útil.
II. Bienvenidos los cambios a los requerimientos,
incluso los tardíos
III. Liberar frecuentemente software funcionando,
desde un par de semanas a un par de meses, con
preferencia por los periodos más cortos.
IV. Los responsables del negocio y los 12
desarrolladores deben trabajar juntos
diariamente durante el proyecto.
V. Construir los proyectos alrededor de individuos
motivados. Proporcionar el ambiente y el soporte
que necesiten, y confiar en que conseguirán
realizar el trabajo.
VI. La conversación directa es el método más
eficiente y efectivo de transmitir información,
tanto al equipo como dentro de éste.

21

10
 20/11/2019

12 Principios del Manifiesto Ágil

VII. El software funcionando es la medida de

progreso.
VIII. Los procesos ágiles promueven el desarrollo
sostenible
IX. La atención continua a la excelencia técnica y al
buen diseño incrementan la agilidad
X. La simplicidad –el arte de maximizar la
cantidad de trabajo no hecho - es esencial. 12
XI. Las mejores arquitecturas, requerimientos y
diseños emergen de los equipos auto-
organizados.
XII. En intervalos regulares, el equipo reflexiona
sobre cómo volverse más efectivo, entonces
afina y ajusta su comportamiento como
corresponde

22

Gestión de Proyectos tradicional Gestión de Proyectos Adaptativo

Tradicional Adaptativo
Iniciación Concibiendo
Planeación Especulación
Ejecución Explorar
Control Adaptación
Cierre Cierre

23

11
 20/11/2019

Declaración de interdependencia

La Declaración de interdependencia en la gestión de proyectos fue escrita a principios

del 2005 por un grupo de 15 líderes de proyectos como un suplemento al “Manifiesto
Ágil”.

Enumera seis valores de gestión necesarios para reforzar una mentalidad de

desarrollo ágil, particularmente en la gestión de proyectos complejos e inciertos.

24

Los 6 Valores de Gestión

I. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de

valor.
II. Ofrecemos resultados fiables mediante la participación del cliente en las
iteraciones frecuentes, donde también son responsables por el trabajo.
III. Asumimos que habrá incertidumbre y las superamos a través de iteraciones,
anticipación y adaptación.
IV. Damos rienda suelta a la creatividad y la innovación al reconocer que las
personas son la fuente máxima de valor y creamos un entorno en el que
puedan tener un impacto positivo.
V. Aumentamos el rendimiento a través de la rendición de cuentas por parte del
grupo en cuestión de resultados y eficacia del equipo, responsabilidades que
todos comparten.
VI. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente
específicas, procesos y prácticas.

25

12
 20/11/2019

¿Que es agilidad?

“Agilidad es la capacidad de crear y

responder al cambio con el fin de
obtener ganancias en un entorno
empresarial turbulento”
Agile Alliance [Link]

“La agilidad es la capacidad de equilibrar

la flexibilidad y estabilidad”

26

27

13
 20/11/2019

¿Cómo debemos ver a la agilidad?

En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto esto
debe ser una meta que se debe tratar de alcanzar.

La gestión de proyectos Agile especialmente, implica la adaptabilidad durante la

creación de un producto, servicio, o cualquier otro resultado.

28

Por que metodologías Agiles?

El 80% de todos los proyectos

emplearán Métodos Ágiles en los
próximos años (Gartner)

Proyectos que usan metodologías

Agiles son mas exitosos que los
proyectos que usan metodologías
en cascada (Standish Group 2010)

29

14
 20/11/2019

Qué es Scrum?

• Puede Complementarse y Convivir

con otras metodologías Ágiles y no
Ágiles (E].: XP, MSF, RUP, TSP)

30

Qué es Scrum?

Scrum es una marco de trabajo de adaptación

iterativa e incremental, rápida, flexible y eficaz
diseñada para ofrecer un valor significativo de
forma rápida en todo el proyecto.

Scrum es:
• Ligero
• Fácil de Entender
• Extremadamente difícil de llegar a dominar

31

15
 20/11/2019

Qué es Scrum?

“En enfoque de ‘carrera de relevos’ en el desarrollo de productos ...

puede entrar en conflicto con los objetivos de máxima velocidad y
flexibilidad. En su lugar, un enfoque holístico o estilo ‘rugby’ - donde un
equipo intenta ir a la distancia como una unidad, pasando la pelota hacia
adelante y hacia atrás -pueden servir mejor a los actuales requisitos
competitivos".

Hirotaka Takeuchi and Ikujiro Nonaka, “ The New New Product

Development Game”, Harvard Business Review, January 1986.

Melé

32

Qué es Scrum?

33

16
 20/11/2019

Scrum en pocas palabras

• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto
valor de negocio en el menor tiempo.
• Nos permite rápidamente y en repetidas ocasiones inspeccionar software real
de trabajo (cada dos semanas o un mes).
• El negocio fija las prioridades. Los equipos se auto-organizan a fin de
determinar la mejor manera de entregar las funcionalidades de más alta
prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el software real funcionando
y decidir si liberarlo o seguir mejorándolo en otro sprint.

34

Scrum ha sido utilizado por:

•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •[Link]
•Capital One •Time Warner
•BBC •Turner Broadcasting

35

17
 20/11/2019

Scrum ha sido utilizado para:

• Software comercial • Desarrollo de video juegos
• Desarrollos internos • Sistemas críticos de soporte vital,
aprobados por laFDA
• Desarrollos bajo Contrato
• Proyectos Fixed-price
• Software de control satelital
• Aplicaciones Financieras
• Sitios Web
• Aplicaciones certificadas ISO
• Software para Handheld
9001 • Teléfonos portátiles
• Sistemas Embebidos • Aplicaciones de Network
switching
• Sistemas con requisitos 7x24
y 99.999% de disponibilidad • Algunas de las más grandes
aplicaciones en uso

36

Logo
Principios de Scrum Partner

37

18
 20/11/2019

Principios de Scrum

• Control de Proceso Empírico

• Auto-Organización
• Colaboración
• Priorización basada en valor
• Time-Boxing
• Desarrollo Iteractivo

38

Principios

Los principios de Scrum son las pautas

básicas para la aplicación del marco de
Scrum y obligatoriamente deben usarse
en todos los proyectos Scrum.

39

19
 20/11/2019

Introducción

Los principios de Scrum son el fundamento sobre lo que se basa el marco de Scrum.
Estos principios se pueden aplicar a cualquier tipo de proyecto u organización, y deben
ser respetados con el fin de garantizar la aplicación apropiada de Scrum.
Los principios se consideran los lineamientos básicos para la aplicación del marco de
Scrum.

40

Control de Proceso Empírico

Empirical Process Control

Este primer principio es muy importante ya que en él se ve reflejado la

filosofía de la agilidad por medio de 3 características:

Transparencia Inspección Adaptación

41

20
 20/11/2019

Permite que todas las facetas de cualquier proceso de Scrum

sean observadas por cualquier persona.
Esto promueve un flujo fácil y transparente de información en
toda la organización y crea una cultura de trabajo abierta.

42

43

21
 20/11/2019

44

La inspección es “revisar” el
avance del proyecto y el
producto.
Debe ser lo suficientemente
efectiva como para que en cada
nueva iteración (o Sprint) se
note una mejora.

45

22
 20/11/2019

46

47

23
 20/11/2019

Sucede cuando el Equipo de

Scrum y los Stakeholders
aprenden a través de la
transparencia y la inspección; y
luego se adaptan al hacer
mejoras en el trabajo ya en
progreso.

48

49

24
 20/11/2019

Auto-organización
Self-organization

Se enfoca en los trabajadores de hoy en día que son

auto-motivados y desean una mayor responsabilidad.
Tomando en cuenta eso, ofrecen más valor cuando se
organizan por cuenta propia.

50

Objetivos de la Auto-Organizacion

51

25
 20/11/2019

Colaboración
Collaboration

La colaboración en Scrum se refiere a que el equipo principal de

Scrum trabaja e interactúa junto con los interesados para crear y
validar los resultados del proyecto.

Conciencia Articulación Apropiación

52

Dimensiones básicas de la colaboración

Este principio se centra en las tres dimensiones básicas relacionadas

con el trabajo colaborativo: conciencia, articulación y apropiación.
• Awareness: (Ser consiente del otro): las personas que trabajan
juntas deben estar al tanto del trabajo de los demás.
• Articulación: los colaboradores deben dividir el trabajo en
unidades, dividir las unidades entre los miembros del equipo, y
luego, después de que el trabajo esté hecho, reintegrarlo.
• Apropiación: la adaptación de la tecnología a la propia situación.

Conciencia Articulación Apropiación

53

26
 20/11/2019

¿Que herramientas de colaboración se pueden

utilizar?
• Colocated Teams (es decir, los equipos que trabajan en la misma
oficina): En Scrum, es preferible tener equipos colocados. Si los
equipos están colocados, los modos de comunicación preferidos
incluyen: las interacciones, salas de decisión, War Rooms,
Scrumboards, demostraciones en la pared, mesas compartidas, etc.

• Distributed Teams (es decir, los equipos que trabajan en diferentes

ubicaciones físicas): Algunas herramientas que podrían utilizarse
para tener colaboración eficaz entre los equipos distribuidos
incluyen: la videoconferencia, redes sociales, pantallas compartidas
y herramientas de software que simulan la funcionalidad de
Scrumboards.

54

Beneficios de la colaboración

En el manifiesto agil se hace hinpaié en la “colaboración con el cliente sobre la

negociación contratual”.
El marco de Scrum adopta este enfoque en el que los miembros de equipo principal de
Scrum colaboran entre sí y con los Stakeholders para crear los entregables que
proporcionan el mayor valor posible para el cliente. Esta colaboración se produce
durante todo el proyecto.

55

27
 20/11/2019

Priorización Basada en el Valor

Value-based Prioritization

El marco de Scrum es impulsado por el objetivo de

ofrecer el máximo valor empresarial en un periodo de
tiempo mínimo.

56

Factores de la priorización

El Product Owner (PO) debe de traducir las entradas y las

necesidades de los proyectos de los Stakeholders para crear el
Prioritized Product Backlog. Por lo tanto, se prioriza basado en la
creación de valor, y se hace teniendo en cuenta que:

• Se Liberen primero los elementos de mayor valor.

• Se Evalúen si el elemento es realmente requerido
• Se Evalúen alternativas con menor tiempo/costo

57

28
 20/11/2019

Priorizando Elementos

✓Responsabilidad del PO
✓Es recomendado el involucramiento de todo el equipo
✓Permite retrasar las decisiones sobre los, elementos de menor
prioridad
✓Se considera el valor, conocimiento, incertidumbre, riesgo,
posibilidad de liberación y dependencias
✓Se pueden agrupar elementos del PB para facilitarla priorización

58

Priorizando Elementos

Valor:
Se deben Iiberar primero los elementos de mayor valor
Evaluar Si el elemento es realmente requerido
Evaluar alternativas con menor tiempo/costo

Conocimiento, incertidumbre y riesgo

Entre menos conozcamos sobre un producto mayor incertidumbre se
tiene
A mayor incertidumbre mayor es el riesgo
Los elementos inciertos y de alto riesgo, deben tener alta prioridad

59

29
 20/11/2019

Priorizando Elementos

• Posibilidad de liberación:
— La habilidad para liberar incrementos de producto temprana y
frecuentemente debe influenciar las decisiones de priorización
• Dependencias:
— Las dependencias entre algunos elementos del PB no se podrá evitar
— Los elementos de los que Se depende deben Ser implementados
primero

60

Time-Boxing

Describe cómo se considera al tiempo como una restricción limitante en

Scrum
Beneficios:
Procesos de desarrollo eficiente
Menos gastos generales
Alta velocidad para los equipos
Ayuda a gestionar eficazmente la planificación y ejecución de
proyectos

65

30
 20/11/2019

Time-Boxing

• Un período de tiempo de longitud fija durante el cual

se realiza una actividad
• Beneficios
— Obliga
— Demuestra el avance
— Evita el perfeccionismo innecesario
— Motiva el cierre
— Mejora la predictibilidad

66

Ventajas de Time-Boxing

Time-boxing es una práctica crítica en Scrum y debe aplicarse con

cuidado.

Un Time-boxing arbitrario puede llevar a la desmotivación del

equipo y puede tener como consecuencia la creación de un
entorno aprensivo, por lo que Time-boxing debe ser utilizado de
manera apropiada.

67

31
 20/11/2019

Donde se utilizan los Time-Boxing

68

Desarrollo iterativo
Iterative Development

• Scrum es impulsado por el objetivo de ofrecer el máximo valor

empresarial en un periodo de tiempo mínimo. Para lograr esto
de forma práctica Scrum cree en entregas de desarrollo
iterativas
• En el desarrollo iteractivo de un proyecto, se planifica en
diversos “bloques temporales” llamado “iteraciones”.

69

32
 20/11/2019

Sprint

70

Sprint

• En Scrum los proyectos avanzan en una serie de

“Sprints”
• Análogo a “Extreme Programming iterations”

• La duración típica es 1–4 semanas

• La duración constante conduce a un mejor ritmo

• El producto es diseñado, codificado y testeado durante

el Sprint

71

33
 20/11/2019

Sprint

• Lo suficientemente corto como para mantener el riesgo

de negocio aceptable para el propietario del producto

• Suficientemente corto como para ser capaz de

sincronizar la el trabajo de desarrollo con otros eventos
de negocios

• No más 4 semanas

72

Sprint

Desarrollo secuencial vs. superpuesto

Requisitos Diseño Código Test

En lugar de hacer todo de

una cosa a la vez ...
...los equipos Scrum hacen
un poco de todo todo el
tiempo

Source: “The New New Product Development Game” by Takeuchi

and Nonaka. Harvard Business Review, January 1986.

73

34
 20/11/2019

74

No hay cambios en un Sprint

Cambios

75

35
 20/11/2019

Cancelación de un Sprint

Un Sprint puede ser cancelado antes de que el

bloque de tiempo llegue a su fin, siempre y cuando
el objetivo del Sprint llegara a quedar obsoleto o
no tiene sentido seguir con el Sprint. Solo el PO
tiene la autoridad para cancelar el Sprint.

76

LECCION-02
MAP. Cristian Barquero, MCP, MCTS, SMAC,PMP®
Agile Coach Professional Certificate
• Skype: c_barquero@[Link]
• Whatsapp: 8445-7993

77

36
 20/11/2019

78

79

37
 20/11/2019

Ciclo de Vida de Scrum

80

Ciclo de Vida de Scrum

Cancel
Return

Gift
Coupons
wrap
Gift
Cancel
wrap
Cancel

Imagen disponible en [Link]/scrum

81

38
 20/11/2019

Ciclo de Vida de Scrum

82

Scrum Framework

Roles
•Product Owner
•ScrumMaster
•Development Team Reuniones
•Sprint Planning
•Sprint Review
•Sprint Retrospective
•Daily Standup Meeting
Artefactos Tools

•Product Backlog
•Sprint Backlog
•Incremento del Producto

83

39
 20/11/2019

Logo
Roles Partner

84

Roles

Entender los roles y responsabilidades definidos en un proyecto de Scrum es muy

importante para asegurar la exitosa implementación de Scrum

• Scrum Team - Scrum Core Roles - Comprometidos

• Stakeholder - Implicado

85

40
 20/11/2019

Scrum Team – Scrum Core Roles

Son aquellos papeles que obligatoriamente se requieren para producir el producto o

servicios del proyecto.

Estos son tres:

Product Owner (PO) Scrum Master (SM) Development Team (DT)

86

Product Owner

El Product Owner (PO) representa la voz del

cliente, y es el encargado de maximizar el valor
del producto.
Un PO siempre debe mantener una visión dual.

1. El debe entender y apoyar las necesidades

e intereses de todos los Stakeholders,
2. Comprende las necesidades y el
funcionamiento del Develpment Team.

87

41
 20/11/2019

Responsabilidades del Product Owner

Valores
Aumentamos el retorno de inversión, al
enfocarnos en el flujo continuo de valor

88

Responsabilidades del Product Owner

89

42
 20/11/2019

Responsabilidades del Product Owner

Ajusta Acepta o Es el único

funcionalidades y rechaza los responsable
prioridades en cada resultados del Product
iteración si es del trabajo Backlog
necesario del equipo

90

Caracteristicas de un Product Owner

91

43
 20/11/2019

Scrum Master

Es un líder servicial, un facilitar, coach. Su

responsabilidad es de asegurar que Scrum
es entendido y adoptado.

Está al servicio del Scrum Team (PO y DT) y

la organización para que estén dotados de
un ambiente propicio para completar el
proyecto con éxito, y esto incluye la
eliminación los “impedimentos” que se
encuentren.

92

Características Scrum Master

Experto en
Leader Modelador
Scrum

Solucionador
Accesible Motivador
de problemas

Habilidades
Perceptivo Mentor de
coordinación

93

44
 20/11/2019

Responsabilidades del Scrum Master con el Product Owner

Facilitar técnicas para Fomenta la necesidad Entender la

gestionar el Product de contar con un planificación del
Backlog de manera Incremental Product producto en un
eficiente Release claro y conciso entorno empírico

Ayuda al PO en cómo Explica cómo realizar

Entender y practicar la
volver colaborativo al un levantamiento de
agilidad
Stakeholder requerimientos ágiles

94

Responsabilides del Scrum Master con el Development Team

Manifiesto Ágil
Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.

Asegura que el Ayuda al

Guía al equipo en ser
ScrumBoad Development Team
auto-organizado y
permanezca para crear productos
multifuncional
actualizado de alto valor.

Elimina Asiste al Development

Asegura que exista un
impedimientos para Team en el desarrollo
ambiente ideal para
el progreso de la del Sprint Backlog y el
el Development Team
construccion Sprint Burdown Chart

95

45
 20/11/2019

Responsabilides del Scrum Master con la organización

Planifica la Ayuda al Scrum Team

Lidera y guía a la
implementación de (PO y DT) y Stakeholders
organización en la
Scrum en la a entender y llevar a
adopción de Scrum
organización cabo Scrum

Motiva cambios que Trabaja de la mano de

incrementen la otros Scrum Master para
productividad del Scrum incrementar la
Team (PO y DT) efectividad de Scrum

96

Development Team

Es el grupo o equipo de personas

responsables de la comprensión
de los requisitos, la estimación y
la creación de los Entregables
(Deliverables) del proyecto.

Solo los miembros del

Development Team (DT)
participan en la creación del
incremento

97

46
 20/11/2019

Tamaño del Development Team

El tamaño óptimo de un Development Team (DT) es

de tres a nueve miembros, lo suficientemente
grande para asegurar habilidades adecuadas, pero
lo suficientemente pequeño como para colaborar
fácilmente.

98

Responsabilidades del Development Team

Asegurar una
Estimar los User
comprensión clara Crear entregables
Stories aprobados
de los de alta calidad
por el PO
requerimentos

Desarrollar la lista Calcular el

de tareas basada esfuerzo para las
en las User Stories tareas
aprobadas identificadas

99

47
 20/11/2019

Responsabilidades del Development Team

Desarrollar el
Identificar el riesgo
Sprint Backlog y el Crear los
y ejecutar acciones
Sprint Burdown entregables
para su mitigación
Chart

Identificar Participar en la
oportunidades de retrospectiva del
mejora proyecto y Sprint

100

Características Development Team

Conocimiento Altamente
Colaboración Proactivos
de Scrum motivados

Expertos Auto- Buen miembro

Independientes
Técnicos organización de equipo

Orientados a los
Responsables Intuitivos Multifuncional Solo puede haber cambio de
objetivos
miembros entre los sprints

101

48
 20/11/2019

Stakeholders

Es un término colectivo que incluye a los clientes, usuarios y

patrocinadores, que con frecuencia interactúan con el Equipo
Principal de Scrum (Scrum Team), para proporcionar entradas
(inputs) y facilitar la creación del producto del proyecto,
servicios, o cualquier otro resultado.

102

Stakeholders se dividen en:

• Cliente: el cliente es la persona o la organización que adquiere el producto del

proyecto, servicio o cualquier otro resultado.
• Usuarios: el usuario es el individuo o la organización que utiliza directamente el
producto del proyecto, servicio, o cualquier otro resultado; también, en algunas
industrias el cliente y los usuarios puede ser lo mismo.
• Patrocinador: el patrocinador es la persona o la organizacion que provee rescursos y
apoyo para el proyecto, el patrocinador tambien es el Stakeholder a quien todos le
deben rendir cuentas al final.

103

49
 20/11/2019

104

Teorías de Recursos Humanos y sus Relevancias en Scrum

• Modelo de Tuckman
• Manejo de conflictos
• Técnicas de manejo de conflictos
• Estilos de liderazgo
• Jerarquía de necesidades según Maslow
• Teoría X y Teoría Y

105

50
 20/11/2019

Teoría de Tuckman

• Publicada en 1965
• Es una explicación elegante y útil del desarrollo y comportamiento de un
equipo de trabajo.

106

Teoría de Tuckman

107

51
 20/11/2019

Teoría de Tuckman

• Forming
• Alta dependencia de líder para la orientación y dirección
• Funciones y responsabilidades individuales no están claros
• Los procesos son a menudo ignorados

108

Teoría de Tuckman

• Storming
• pueden producirse conflictos de poder
• Los miembros del equipo se disputan la posición a medida que intentan establecerse en
relación con otro miembros del equipo.
• Las decisiones no vienen fácilmente dentro del grupo
• Necesita ser enfocado en sus metas para evitar dejarse distraer por las relaciones y
problemas emocionales

109

52
 20/11/2019

Teoría de Tuckman

• Norming
• El equipo comienza a madurar
• Acuerdo y consenso constituye en gran medida entre los el equipo, que responde bien a la facilitación de líder
• Los roles y responsabilidades son claras y aceptados
• Las grandes decisiones son tomadas por acuerdo del grupo
• El compromiso y la unidad es fuerte
• El equipo discute y desarrolla sus procesos y estilo de trabajo .
• resolver sus diferencias internas
• Encontrar soluciones para trabajar juntos

110

Teoría de Tuckman
• Performing
• Se convierte en su forma más cohesiva
• Funciona a su nivel más alto en términos de actuación
• El equipo sabe claramente por qué está haciendo lo que es obra
• Hay un enfoque en exceso de la consecución de objetivos , y la equipo hace la mayor
parte de las decisiones en función de criterios acordado con el líder
• El equipo tiene un alto grado de autonomía
• El equipo es capaz de trabajar hacia el logro de la
meta, y también para asistir a la relación, estilo y
cuestiones relativas al proceso en el camino

111

53
 20/11/2019

Gestión de conflictos

• SCRUM fomentar un entorno abierto y el diálogo entre los empleados.

• Los conflictos pueden ser saludable cuando promueve las discusiones
del equipo y anima a los debates.
• Es importante , por tanto, la resolución de conflictos.

112

Gestión de conflictos

• Técnicas:
• Ganar-Ganar
• Perder-Ganar
• Perder-Perder
• Ganar-Perder

113

54
 20/11/2019

Gestión de conflictos

• Ganar-Ganar:

• Actitud de cooperación y un diálogo abierto para trabajar a través de

cualquier desacuerdo para llegar consenso

• Promover un entorno donde los empleados puedan sentirse cómodo

para discutir de manera abierta y enfrentar los problemas o
cuestiones

114

Gestión de conflictos

• Perder-Ganar:
• Algunos miembros del equipo pueden a veces sentir que sus
contribuciones no están siendo reconocidos o valorados por los
demás, o que no están siendo tratados por igual

• Retirarse de contribuir eficazmente al proyecto y están de acuerdo a lo que

se les dice que hacer, incluso si están en desacuerdo

Este enfoque no es una técnica de gestión de conflicto

deseado de proyectos Scrum

115

55
 20/11/2019

Gestión de conflictos

• Perder-Perder:
• Búsqueda de soluciones que aportan sólo parcial grado o la medida
temporal de satisfacción a las partes en una controversia

• Este enfoque implica normalmente un poco de " dar y tomar " para
satisfacer a todos los miembros del equipo, en lugar de tratar de
resolver el problema real

116

Gestión de conflictos
• Ganar-Perder:
• El influyente miembro del equipo puede creer que él o ella es un
líder de facto o gerente y tratar de ejercer su punto de vista , a
expensas de la puntos de vista de los demás

• Este enfoque no es recomendable cuando trabajando en

proyectos Scrum , porque los equipos Scrum son de naturaleza
auto- organizada y facultado , sin una persona que tiene cierto
autoridad sobre otro miembro el equipo

117

56
 20/11/2019

Estilos de liderazgo

• Delegado • Compromiso con el crecimiento de

• Autocrático los demás
• Coaching • Construyendo comunidad
• Orientado a Tareas
• Asertivo
• Escucha
• Empático
• Persuasivo

118

Maslow

119

57
 20/11/2019

Teoría X y Teoría Y

120

Preguntas

121

121

58
 20/11/2019

122

123

59
 20/11/2019

124

125

60
 20/11/2019

126

127

61
 20/11/2019

128

Logo
Conceptos Claves en Scrum Partner

129
129

62
 20/11/2019

Conceptos Claves en Scrum

Épicas: Es una historia de usuario que es demasiado grande para caber en un

sprint. A menudo, éste término se utiliza para describir una gran historia de usuario
que tendrá que ser dividido en historias más pequeñas.

130

Conceptos Claves en Scrum

User Stories: Es una representación de un requisito del usuario en forma escrita,

de una o dos frases, utilizando el lenguaje común del usuario.

131

63
 20/11/2019

Historia de Usuario

Son una forma de expresar el valor de negocio para características del

producto (Elementos del PB)

Deben ser entendibles para las personas del negocio y para los técnicos
Se documentan en tarjetas para promover la brevedad en Ia descripción

132

Historia de Usuario

El PO debe tener habilidades para la creación de historias de usuario

Incentivan:

Colaboración
Conversación

Diseñadas para ser incompletas, para fomentar las discusiones y el

debate

133

64
 20/11/2019

Taller de Historia de Usuario

• Diferentes formas de determinar las

historias:
— De arriba hacia abajo
(descomposición)
— De abajo hacia arriba
— Mapeo de historias (basando en la
actividad usuario)

134

Taller de Historia de Usuario

• Participantes:
— Product Owner
— Scrum Master
— Involucrados (Usuarios, Clientes, mercadeo) -> Solicitantes de Requerimientos

El objetivo es colectivamente definir lo que el producto o servicio debe hacer,

considerando su valor de negocio.
Se documentan las historias de usuarios para la siguiente entrega.

135

65
 20/11/2019

Conceptos Claves en Scrum

136

Como está conformada una User Story

Una historia de usuario debe estar Características: modelo INVEST.

conformada por las 3C: • Independencia
Card (tarjeta): Descripción escrita de lo • Negociables
que necesita el usuario.
• Valiosa
Convesación: El PO y el DT aclaran los
detalles. • Estimable
Confirmación: Sirve para determinar lo • Pequeña
que se espera. Las pruebas de aceptación • Verificable
confirman Story es codificado
correctamente [Link]

137

66
 20/11/2019

138

139

67
 20/11/2019

140

Estructura de User Story

141

68
 20/11/2019

Historia de Usuario

Como <rol de usuario> quiero

<función de sistema> para lograr
<valor de negocio>

Como un viajero frecuente ,

quiero volver a reservar un
viaje pasado para ahorrar
tiempo de reserva

142

Ejemplo de User Story: Website de Viaje

Como usuario, quiero Como vacacionista, quiero Características:

modelo INVEST.
reservar una habitación en ver fotos del hotel
el hotel • Independencia
• Negociables
• Valiosa
• Estimable
• Pequeña
Como usuario, quiero Como un viajero frecuente ,
cancelar una reservación quiero volver a reservar un • Verificable
viaje pasado para ahorrar
tiempo de reserva

143

69
 20/11/2019

Ejemplo de User Story: Website de Viaje

Donde están los detalles
• Como usuario , puedo cancelar una reserva
• ¿El usuario recibirá un reembolso completo o parcial ?
• ¿Está el reembolso a su tarjeta de crédito o se trata de
crédito sitio?
• Con cuanto tipo de anticipación debe ser la reserva
cancelada?
• ¿Es lo mismo para todos los hoteles ?
• Para todos los visitantes del sitio ? Los viajeros frecuentes
pueden cancelar más adelante?
• ¿Es una confirmación proporcionado al usuario ?
• ¿Cómo?

144

❑ Verificar que un miembro Ejemplo de User Story: Website de Viaje

Premiun puede cancelar la
mismo día sin cargo.
❑ Compruebe que un Como usuario, quiero
miembro no- premium reservar una habitación en
paga 10 % para una el hotel
cancelación el mismo día .
❑ Compruebe que una
confirmación por correo
electrónico se envía • Las condiciones de
❑ Compruebe que el hotel satisfacción del Product
recibe la confirmación de pueden ser añadido a una
cualquier cancelación. story
• Son pruebas esencialmente

145

70
 20/11/2019

Resultados del Taller de Historia de

Usuario

Un estimado de alto nivel (si mucho detalle) de las historias de usuario del
producto
Un PB general ordenado por prioridad

146

Conceptos Claves en Scrum

Task: Es una representación del requisito que está en lenguaje del usuario, pero de
una forma técnica donde está definido cómo se va a trabajar y quién van a
participar.

147

71
 20/11/2019

Task -Tarea

Unidad de trabajo gestionada por los miembros del Development Team

(DT). Una tarea tiene asignada una persona para su realización, y es
recomendable que el esfuerzo estimado para llevarla a cabo sea como
máximo el equivalente a una jornada de trabajo.

“Una tarea es creada en lenguaje técnico, mientras las User Stories son
creadas en lenguaje de usuario”

148

Cómo está conformada una Task

Características modelo SMART:

• S: Specific (Especifico) ID:

• M: Measurable (Medible)
Responsable:
• A: Achievable (Alcanzable)
• R: Relevant (Relevante) Descripción:
• T: Time-boxed (Tiempo-caja)
Estimación:

149

72
 20/11/2019

DONE!!

150

Definición de Done

Son los acuerdos del PO con los Stakeholders que contiene todas las
condiciones que deben de cumplir los ítems del Product Backlog para
considerar un Sprint completado o finalizado.
Los criterios de Done
aceptacion Done es un conjunto
Son los componentes de reglas que se
objetivos por los aplican a todas las
cuales se juzga la User Stories en un
funcionalidad de un determinado Sprint
User Story.

151

73
 20/11/2019

Definición de Done

Programador Cuando el código este escrito

Tester Cuando todos los test hayan pasado

Operación Cuando este cargado en el servidor de producción

Negocios Cuando este listo para usarse

152

Definición de Done

• Crear su propia definición

• Decidir juntos que cosas podrán ser completadas antes de que el equipo declare
si esta terminado

• El equipo determinará su propia definición determinando como un checklist

• Definición de todos los Product Backlog Items

153

74
 20/11/2019

Definición de Done

154

Definición de Done

❑Comentado por otros miembros del equipo

❑User Story completado y realizando el testeo
❑La finalización de las pruebas de control de calidad.
❑Finalización de toda la documentación relacionada con la User Story
❑Todos los problemas se corrigen.
❑La demostración exitosa de las partes a stakeholder y/o representate del
negocio.

155

75
 20/11/2019

Preguntas

156

156

157

76
 20/11/2019

158

159

77
 20/11/2019

160

161

78
 20/11/2019

162

Logo
Reuniones Partner

163

79
 20/11/2019

Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint Planning
•Sprint Review
•Sprint Retrospective
•Daily Standup Meeting
Artefactos
•Product backlog
•Sprint backlog
•Incremento del Producto
164

Reuniones o ceremonias de Scrum

Para que cualquier proyecto tenga éxito, la comunicación es importante. Los equipos
Scrum emplean una serie de reuniones clave para estructurar el trabajo del equipo:

• Sprint
• Daily Standup Meeting
• Sprint Planning Meeting
• Sprint Review Meeting
• Restrospect Sprint Meeting

165

80
 20/11/2019

Daily Standup Meeting

• De pie
• No para la solución de
problemas
• Todo el mundo está invitado
• Sólo los miembros del
equipo pueden hablar
• Ayuda a evitar otras
reuniones innecesarias

166

Daily Standup Meeting

•No es dar un status report al Scrum Master

•Se trata de compromisos delante de pares

167

81
 20/11/2019

Daily Standup Meeting

• Facilita al equipo la comunicación

• La comunicación como un equipo
cada día fomenta la
responsabilidad compartida, así
como la capacidad de responder
más rápidamente a los retos y
cambios

168

Daily Scrum Meeting

169

82
 20/11/2019

Sprint Planning Meeting

170

Preparación de la Planeación

• Definir:
— Velocidad historia del equipo
— Capacidad del Equipo

171

83
 20/11/2019

Preparación de la Planeación

• Plantear una meta del Sprint

La meta:
— Crea alineación entre el Product Owner (PO), Scrum
Master (SM) y el equipo de desarrollo
— Limita el tipo de requerimientos en que se trabaja en
un Sprint
— Facilita con la comunicación con los involucrados
• Se debe hacer Refinamiento antes del Sprint

172

Sprint Planning Meeting

• El PO tiene una idea de que quiere entregar al final del Sprint (elementos
de alta prioridad del PB)
• El equipo establece un compromiso realizable basado en sus capacidades,
velocidad pronosticada y las restricciones conocidas
• Dos partes:
— Qué Será entregado en el incremento resultado del Sprint?
— Cómo Se conseguirá hacer el trabajo necesario para entregar el
Incremento?

173

84
 20/11/2019

Sprint Planning Meeting

Capacidad y
velocidad del Sprint Planning meeting
Equipo
Priorización
Product Backlog • Analizar y evaluar el Product Backlog Objetivo del Sprint
• Seleccionar el objetivo del Sprint

Condiciones del
Negocio Planificación
• Decidir como alcanzar el objetivo del Sprint
(diseño)
Producto Actual • Crear el Sprint Backlog (tareas) en base a Sprint Backlog
los temas del Product Backlog (user stories
/ features)
• Estimar Sprint Backlog en horas
Tecnología

174

Sprint Planning Meeting

Sprint Planning Meeting

Cancel
Return

Gift
Coupons
wrap
Gift
Cancel
wrap
Coupons

Imagen disponible en [Link]/scrum

175

85
 20/11/2019

Sprint Planning Meeting

Que será entregado?

• El PO explica la meta propuesta del Sprint,

describe los temas, características o
historias objetivo

• El equipo de desarrollo pronostica que

elementos del PB entregará en el Sprint

• El equipo Scrum define la meta del Sprint

176

Sprint Planning Meeting

Que será entregado?

Esta pregunta nos ayuda para que el

Development Team (DT) trabaje para
proyectar la funcionalidad que se desarrollará
durante el Sprint, donde se define objetivo del
Sprint (Sprint Goal).

El número de elementos del Product Backlog

seleccionados para el Sprint depende
únicamente del Development Team (DT).

177

86
 20/11/2019

Sprint Planning Meeting

Que será entregado?
El objetivo es proveer a los involucrados una idea de Ia funcionalidad que
probablemente se entregara en una fecha

La planeación de la entrega es continua durante el proyecto a medido que el cliente

va dando retroalimentación

EI PO es responsable de las decisiones en la planeación de la entrega

EI plan de la entrega es una ruta aproximada a un destino

178

Sprint Planning Meeting

Comó?
• El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
• Se crea el Sprint Backlog
• Se identifican tareas y cada una es estimada (1-8 horas)
• Realizado colaborativamente, no solo por el ScrumMaster
• El diseño de Alto Nivel es considerado

COMO planificador Codificar la capa intermedia (8 hs)

de vacaciones, YO Codificar la interfaz de usuario (4)
QUIERO ver fotos Escribir los test fixtures (4)
de los hoteles. Codificar la clase foo (6)
Actualizar test de performance (4)

179

87
 20/11/2019

Sprint Planning Meeting

• Es para que los miembros del equipo

puedan planear y estar de acuerdo con los
Stories o los ítems del Backlog
• Identificar el detalle de las tareas y test
para el desarrollo y aceptación

180

Sprint Planning Meeting

• Es para que los miembros del equipo

puedan planear y estar de acuerdo con los
Stories o los ítems del Backlog
• Identificar el detalle de las tareas y test
para el desarrollo y aceptación

181

88
 20/11/2019

Sprint Planning
Meeting

182

LECCION-03
MAP. Cristian Barquero, MCP, MCTS, SMAC,PMP®
Agile Coach Professional Certificate
• Skype: c_barquero@[Link]
• Whatsapp: 8445-7993

183

89
 20/11/2019

Sprint Goal Objetivo Sprint

184

Sprint Goal Objetivo Sprint

• Una breve declaración de cual será el foco del trabajo

durante el sprint

Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de genética
Aplicación con [Link]
de poblaciones.
Hacer que la aplicación se ejecute
en SQL Server, además de Oracle.
Servicios Financieros

Soportar más indicadores técnicos

que la empresa ABC en tiempo real
y streaming de datos.

185

90
 20/11/2019

¿Cómo se conseguirá completar el trabajo seleccionado?

Una vez determinado cuál es Sprint Goal

y seleccionado los PBI para cumplirlo, los
miembros del Development Team (DT)
deciden técnicamente como construirán
el incremento del producto, esto hace
referencia a la creación de las Tasks por
parte del Development Team (DT).

186

187

91
 20/11/2019

Estimación Ágil

• Estimación del esfuerzo

• Traducir el tamaño (medido en puntos) a una estimación detallada del esfuerzo.

• La estimación del esfuerzo indica cuánto tiempo se tomará el miembro ( s ) para

completar el equipo elemento de trabajo asignado ( s ) .

188

Estimación Ágil

• Estimación del tamaño

• Estimación a un alto nivel usando una unidad neutral (puntos)

• Ana es 3 veces más productiva que Juan

• Item A vale un punto
• Item B es 5 X A
• Ana dice que el ítem B toma 12 horas
• Juan dice que el ítem B toma 36 horas

189

92
 20/11/2019

Estimación Ágil

Story Tareas

Como nadador puedo Test de aceptación de Cambiar la vista, solo

actualizar mi las especificaciones puede editar la página
demografía de demografía.

5 horas 6 horas

Story Points Horas

1 11

190

Como estimar el tamaño?

191

93
 20/11/2019

Estimación
Planning Póker

Esta es una de la técnicas

más reconocida en Scrum,
ya que es muy sencilla,
divertida y eficaz, donde el
Development Team (DT)
estima como grupo el
esfuerzo a realizar en el
Sprint.

192

Estimación
Planning Póker

• Los participantes se dividen de la siguiente manera:

• Los estimadores: donde cada uno tendrá un mazo de cartas
con la siguiente numeración: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40,
100 y ??. Estos participantes serán los encargados de
estimar.
• El moderador: Es el que preside la reunión, y no puede
participar ni estimar.
• El product owner: Puede participar pero no puede ser un
estimador.

193

94
 20/11/2019

Estimación
Planning Póker

• El moderador elige una historia de usuario de una lista

(product backlog) y lee la descripción a los participantes.

• El product owner deberá contestar las preguntas que le

hagan los estimadores acerca de la tarea.

• Los estimadores deben seleccionar una carta de su mazo la

cual representa su estimación, y colocarla sobre la mesa
boca abajo. Una vez que todas las estimaciones hayan sido
realizadas, las cartas se voltean. Porque?

194

Estimación
Planning Póker

• Si las estimaciones son muy variadas, los dueños de los

puntajes más alto y más bajo discuten la razón de su
estimación. Aquí deben participar todos los
estimadores.

• Repetir la estimación hasta que las estimaciones

converjan.

195

95
 20/11/2019

Estimación
Planning Póker

• Porque funciona?
• Reúne a múltiples opiniones de los expertos.

• Se produce diálogo durante la planificación de Póker,

justificando sus estimaciones

• Según estudios permite dar mejores resultados que

promedios individuales.

196

No Recomendado

197

96
 20/11/2019

198

Porqué Fibonacci?

199

97
 20/11/2019

Estimación Ágil

• Velocidad
• Cuantos puntos un equipo puede desarrollar en
un Sprint…puede cambiar de Sprint a Sprint?

• Ejemplo
• 20 puntos de una iteración planificadas para llevar a
cabo
• se entregaron sólo 14 puntos
• Velocidad = 14 puntos

200

Sprint Review Meeting

• Normalmente adopta la forma de una demo de las

nuevas características o la arquitectura subyacente
• No usar diapositivas

201

98
 20/11/2019

Sprint Review Meeting

• Se lleva a cabo con el Product Owner

para asegurar que todos los criterios de
aceptación de los trabajos realizados se
han cumplido.
• Después, el equipo demuestra la
funcionalidad de su trabajo a los
stakeholdes y/o clientes.

202

Sprint Review Meeting

203

99
 20/11/2019

Sprint Retrospective

204

Las 5 Etapas de una Retrospectiva

Preparar el Escenario

Recolectar Datos

Reflexionar

Decidir qué hacer

Cerrar la retrospectiva

205

100
 20/11/2019

Retrospective

• Proporciona al equipo una oportunidad para evaluar

colectivamente sus procesos.
• Compromiso de los miembros del equipo a mejora
continua.
• El objetivo de estas reuniones es inspeccionar y
adaptar las prácticas y procesos de equipo en un
esfuerzo para identificar y tomar medidas sobre
cuestiones fundamentales que constituyen un
obstáculo para el progreso.

206

Sprint Restrospective
Meeting

207

101
 20/11/2019

Preguntas

208

208

209

102
 20/11/2019

210

211

103
 20/11/2019

212

213

104
 20/11/2019

214

215

105
 20/11/2019

216

217

106
 20/11/2019

218

Logo
Artefactos Partner

219

107
 20/11/2019

Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product Backlog
•Sprint Backlog
•Incremento del Producto

220

Artefactos

Los artefactos en Scrum son herramientas que propone Scrum

para mantener organizado un proyecto, estos son 3:

• Product Backlog
• Sprint Backlog
• Incremento del producto

221

108
 20/11/2019

Product Backlog

Es uno de los artefactos más esenciales de Scrum. Consiste en una lista ordenada de
las ideas para el producto. Todo el trabajo que realiza el Development Team (DT)
proviene del Product Backlog.

El Product Owner (PO) es el responsable Product Backlog, incluyendo el contenido,

disponibilidad y ordenación, aunque puede y debería recibir ayuda para construirlo y
mantenerlo actualizado.

222

Product Backlog

• Priorizada por el Product Owner

• Repriorizada al comienzo de cada Sprint

223

109
 20/11/2019

Ejemplo de Product Backlog

Backlog item Estimación

Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de una
3
Cancel reserva.
Return Como un empleado de hotel, puedo ejecutar
8
informes de los ingresos por habitación disponible
Coupons
Gift wrap
Mejorar el manejo de excepciones 8
Gift wrap
Cancel
... 30
... 50

224

Refinamiento del Product Backlog

Es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista

de Producto. Se trata de un proceso continuo, en el cual el Product Owner
(PO) y el Development Team (DT) colaboran acerca de los detalles de los
elementos de la Lista de Producto.

El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este

refinamiento, usualmente consume no más del 10% de la capacidad del
Equipo de Desarrollo.

225

110
 20/11/2019

Sprint Backlog

Es la lista de tareas del Product Backlog refinados que han sido elegidos para ser
desarrollados en el Sprint actual. Generado el Sprint Backlog, comienza el Sprint y el
Equipo de Desarrollo implementa el nuevo Incremento de Producto definido por el
Sprint Backlog.

Este se ve representado por medio de las tableros de Scrum

226

Sprint Backlog

227

111
 20/11/2019

Gestión del Sprint Backlog

• Los individuos eligen las tareas

• El trabajo nunca es asignado

• La estimación del trabajo restante es actualizada diariamente

• Cualquier miembro del equipo puede añadir, borrar o cambiar el
Sprint Backlog
• Si el trabajo no está claro, definir un tema del Sprint Backlog con una
mayor cantidad de tiempo y subdividirla luego.
• Actualizar el trabajo restante a medida de que más se conoce

228

Ejemplo de Sprint Backlog

Tareas L M M J V
Codificar UI 8 4 8
Codificar negocio 16 12 10 4
Testear negocio 8 16 16 11 8
Escribir ayuda online 12
Escribir la clase foo 8 8 8 8 8
Agregar error logging 8 4

229

112
 20/11/2019

Burn-Down Chart (Product, Sprint)

Un diagrama Burn-Down o diagrama de quemados, es una representación

gráfica del trabajo por hacer en un proyecto o muestra el esfuerzo restante
durante un periodo determinado de tiempo.
A este radiador de información se le puede dar dos usos:
Product Burn-Down: visión global del proyecto, se realiza a partir del Product
Backlog.
Sprint Burn-Down: visión concreta para cada Sprint, se realiza a partir del Sprint
Backlog.

230

Burn-Down Chart (Product, Sprint)

Hours

231

113
 20/11/2019

Tareas L M M J V Burn-Down Chart

Codificar UI 8 4 8 (Product, Sprint)
Codificar Negocio 16 12 10 7
Testear Negocio 8 16 16 11 8
Escribir ayuda online 12

50
40
30
20
10
Hours

0
Mon Tue Wed Thu Fri

232

233

114
 20/11/2019

234

Incremento del producto

Al final de cada Sprint se produce un Incremento de Producto utilizable. Éste debe

contar con una calidad lo suficientemente alta como para ser entregado a los usuarios
finales.

El Incremento de Producto debe cumplir con la Definición de hecho (DONE) actual del
Equipo Scrum y cada parte del mismo debe ser aceptable para el Product Owner (PO).

235

115
 20/11/2019

Preguntas

236

236

237

116
 20/11/2019

238

239

117
 20/11/2019

240

242

118
 20/11/2019

Escalabilidad

• Normalmente los equipos son de 9 ± 3 personas

• La escalabilidad proviene de equipos de equipos
• Factores a tener cuenta
• Tipo de aplicación
• Tamaño del equipo
• Dispersión del equipo
• Duración del proyecto
• Scrum se ha utilizado en múltiples proyectos de más de 500 personas

244

Escalabilidad de Scrum

245

119
 20/11/2019

Escalabilidad de Scrum

246

Escalabilidad de Scrum

247

120
 20/11/2019

Escalabilidad de Scrum

248

Caso

249

121
 20/11/2019

Caso práctico

Un cliente se pone en contacto con una empresa que fabrica

robots.

El cliente les realiza el pedido.

Quiero un robot que

me sirva de escolta

250

Caso práctico

El Cliente se reune con el “Product Owner”, que toma nota de

lo que tiene en su cabeza.

Cliente Product Owner

251

122
 20/11/2019

Caso práctico

El “Product Owner” divide el proyecto en “User story” que son

las que componen la “Product BackLog”.

Product Owner

Product BackLog

252

Caso práctico

El Scrum Master es un miembro del equipo que tiene el papel

de comunicar y gestionar las necesidades del Product Owner
y el Product Backlog.

El Product Owner le entrega el Product Backlog para que

estimen el coste de creación del producto.

Product Owner Scrum Master

253

123
 20/11/2019

Caso práctico

El equipo se reune para estimar el coste de cada Story del Product Backlog.

En este caso utilizan Planning Poker.

Equipo

254

Caso práctico

El cliente, una vez aprobado el presupuesto, reordena el Product Backlog para que
el equipo vaya trabajando según la prioridad del cliente.
Más imporantes

Cliente

Menos Importante

255

124
 20/11/2019

Caso práctico

El equipo comienza su trabajo desglosando el primer Story del Product BackLog, la

cual subdividen en tareas menores para crear el Sprint BackLog.

Product BackLog

256

Caso práctico

Sprint Backlog tiene como utilidad fraccionar el trabajo de un periodo de 15 días en

tareas más pequeñas, que tarden como mucho dos días.

257

125
 20/11/2019

Caso práctico

Estas tareas se colocan en el Sprint BackLog, la cual prioriza el Product Owner,

que ha consultado con el cliente, antes de comenzar el sprint.
Mas imporantes

Product Owner

Menos importante

258

Caso práctico

El equipo comienza el sprint tomando las tareas priorizadas.

Una vez concluida una se toma la siguiente de la lista.
Se convoca todos los días una reunión del equipo donde se cuenta las tareas
realizadas el día anterior y cuales se van a realizar ese día.

259

126
 20/11/2019

Caso práctico

Una vez finalizado el sprint, el Product Owner le muestra al cliente el resultado del
trabajo realizado.
El cliente ya tiene el primer contacto con su encargo y además puede volver a
priorizar el Product Backlog antes de que comience otro Sprint.

Buen trabajo

Product Owner Cliente

260

Caso práctico

El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva, donde
se analiza lo ocurrido durante el sprint.

261

127
 20/11/2019

Product Sprint No iniciado En Progreso Completado

Backlog Backlog

262

Sprint Execution
L K M J V L K M J V

8:00 Daily Scrum Meeting (15 minutos)

Sprint Planning Meeting

9:00

10:00
(4h)

11:00
Refinement (2h)

12:00
Sprint Review
Meeting (2h)
Backlog

1:00

2:00

3:00
Retrospective
Meeting (2h)
Sprint

4:00

5:00

263

128
 20/11/2019

Como Iniciar con Scrum

• Aprenda nuevas cosas

• Nuevas habilidades técnicas
• Pensar en equipo
• Crear time boxes
• Iniciar entrenamiento para entender los principios de Scrum

264

Ejemplo Verizon-Argentina IT Global Center

265

129
 20/11/2019

Ejemplo Verizon-Argentina IT Global Center

266

Ejemplo Verizon-Argentina IT Global Center

267

130
 20/11/2019

Ejemplo Verizon-Argentina IT Global Center

268

Preguntas

269

269

131
 20/11/2019

270

271

132
 20/11/2019

272

273

133
 20/11/2019

Donde seguir estudiando?

• [Link]/scrum
• [Link]
• [Link]
• [Link]
• [Link]

274

Una lista de lecturas sobre Scrum

• Agile and Iterative Development: A Manager’s Guide by Craig
Larman
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
• Scrum and The Enterprise by Ken Schwaber
• User Stories Applied for Agile Software Development by Mike
Cohn
• Artículos semanales en [Link]

275

134
 20/11/2019

Ing. Cristian Barquero, MAP, SMAC, ITIL, PMP®,PMI-ACP®

Agile Coach Professional Certificate
Skype: c_barquero@[Link]
Whatsapp: 8445-7993
Logo Partner

276

135