SCRUM DE LA TEORÍA

A LA PRÁCTICA
Ana Granados
PRIMER
MÓDULO
Introducción a Scrum
 Introducción al
Profesor y al curso
¿Cómo nació Scrum?
 Historia de Scrum
Rugby

1986 1993 1995 1995

Fue creado por Ken Schwaber y Jeff Se creo un conjunto Se desarrollo el

Hirotaka Takeuchi e Sutherland de reglas o buenas manifiesto ágil.
Ikujiro Nonaka, a raíz presentaron prácticas y se le
de un estudio que colectivamente sus denomino Scrum.
hicieron en algunas experiencias durante
empresas. la conferencia.
¿Qué es Scrum?
 Scrum
Es un marco de trabajo para desarrollar, entregar y mantener productos complejos.

Es liviano Fácil de entender Difícil de dominar

Dentro de este marco de trabajo, se pueden emplear varios procesos y técnicas.

Muestra la eficacia relativa de las técnicas de gestión de producto y las técnicas de trabajo de
modo que podamos mejorar continuamente el producto, el equipo y el entorno de trabajo.

https://www.scrumguides.org/index.html
Mitos

Un proceso, técnica o
método definitivo

Presenta
Una metodología
MITOS DE SCRUM

Se aplica para todos

los proyectos

No existe
documentación

Ahorro de costos
Empresas que
usan Scrum
SEGUNDO
MÓDULO
Pilares y valores
Pilares
1 TRANSPARENCIA
Los aspectos significativos del proceso deben
ser visibles. La transparencia requiere tener
un estandar común para el equipo.

2 INSPECCIÓN
Se inspecciona frecuentemente los artefactos
de Scrum y el progreso hacia un objetivo
para detectar variaciones.

3 ADAPTACIÓN
Después de inspeccionar los artefactos, se
detectan desviaciones , para lo cual se debe
ajustar lo más pronto posible.
Valores
Foco Apertura

Compromiso Respeto

Coraje
 ¿Cómo aplicar los valores?

Foco Compromiso Coraje Apertura Respeto

En el objetivo Con el equipo. Para decir Para escuchar En las

del sprint. algo que la opinión de opiniones
considere que los demás. para otra
Entregar valor Con los esta mal. persona o el
en periodos valores y el Salir fuera de equipo.
cortos de equipo. Hacer las la caja
tiempo. preguntas Al trabajo de
necesarias. Al cambio. otra persona.
Conclusiones de los
Pilares y valores
Reinventarse

Cambio
Reinventarte
Todos los días, te reinventas. Siempre
estás en movimiento. Pero tú decides
todos los días: hacia adelante o hacia
atrás”.

-James Altucher
TERCER
MÓDULO
Roles
Introducción a los
Roles de scrum
 Scrum Team

Autoorganizados

Product Owner Scrum Master

Multifuncionales

Entregan productos de forma iteractiva e

incremental

Equipo de desarrollo
 Rol:
Product Owner
Responsable de maximizar el valor del producto resultante del trabajo del equipo de desarrollo.

Es la única persona responsable de gestionar y ordenar el Product Backlog.

Garantiza la existencia de una visión de producto compartida y compartir objetivos del negocio.

Ayudar al equipo a entender qué construir y por qué.

Manejar las expectativas y mantener relación directa con los Stakeholders.

Maximizar el Retorno de la Inversión (ROI) del Producto.

 Evolución del Product Owner

REPRESENTANTE PATROCINADOR EMPRENDEDOR

ESCRITOR PROXY DE NEGOCIO
Comienza con la El enfoque de un proxy Hay disponibilidad Se le permite pasar más Es completamente
creación del Product cambia de la creación directa de tiempo como responsable de la
Backlog. de elementos de la Lista conocimientos propietario del funcionalidad y los
de Producto a la funcionales y producto, lo que genera presupuestos.
creación de Incrementos expectativas de los menos interrupciones,
de Producto. interesados. cambios de contexto y
tareas y un flujo
mejorado en gran
medida.
http://roneringa.com/evolution-product-owner/
¿Qué no es o no hace un
Product Owner?

Un comité.

Solo recibir pedidos de todas las áreas para su producto.

 Rol:
Equipo de desarrollo
 Trabajar en estrecha colaboración con el PO y Stakeholders.

Profesionales que realizan el trabajo de entregar un incremento de producto “Terminado”.

Son auto-organizados y multifuncionales para entregar un incremento.

Transparentan su progreso diariamente hacia el objetivo del Sprint.

Aseguran la calidad del producto.

Son entre tres a nueve miembros.

Evolución del Equipo de desarrollo

LA MANADA DE
EL GRUPO LA TORMENTA EL EQUIPO LA FAMILIA LOBOS

Los miembros del Las personas comienzan Después de superar los Enfocados en asegurar Determinan
equipo todavía se están a conocer sus conflictos, se forman terminar lo que se continuamente nuevas
descubriendo unos a diferencias, están en lazos de respeto, donde acuerda, miden prácticas o perfeccionan
otros y su lugar en el desacuerdo y hay propuestas de constantemente su las existentes. Los
equipo. Como resultado, aparecerán conflictos. mejora y estándares desempeño y mejoran miembros del equipo
tienen una actitud de como TDD, los KPI. enseñan a personas
esperar y ver qué pasa y programación en ajenas al equipo sobre
no muestran su parejas, CI. buenas prácticas y lo
verdadero yo. que funciona bien.

http://roneringa.com/development-team-evolution/
 ¿Qué no es o no hace un
Equipo de desarrollo?
Nadie indica al equipo de desarrollo como convertir elementos del Product Backlog en incrementos.

No existen títulos para los miembros del equipo de desarrollo.

Scrum no reconoce sub equipos.

 Rol:
Scrum Master
 Motivar cambios que incrementen la productividad del equipo de Scrum.

Responsable de promover y apoyar Scrum, ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum.

Remover impedimentos que el equipo no pueda resolver.

Guía, enseña al PO y equipo desarrollo en su rol.

Facilitar los eventos de Scrum.

Liderar y guiar a la organización en la adopción de Scrum.

 Evolución del Scrum Master

EL MAESTRO EL
EL SECRETARIO EL ENTRENADOR EL CONSEJERO EL EXPERTO
DE MARIONETAS ORGANIZADOR

Generalmente Todos en el equipo Él se asegura de Puede impactar a Logró crear / Es altamente

elimina muchas deben seguir las que realmente otros con su habilitar equipos competente y
tareas reglas de Scrum al vivan los valores. conocimiento, Scrum comprometido.
administrativas del pie de la letra. Esto Se centra en mientras que el empoderados. Asesora a
equipo de a menudo resulta asegurarse de que organizador solo Como resultado de directivos,
desarrollo (como en una todos los eventos usó este eso, su enfoque profesionales de
actualizar el Sprint implementación de Scrum tengan un conocimiento él ahora se ha RRHH. Lidera la
Backlog, gráficos Scrum muy resultado óptimo. mismo. desplazado hacia organización hacia
de evolución, etc.) mecánica. la organización. una mayor agilidad.

http://roneringa.com/evolution-scrum-master/
¿Qué no es o no hace un
Scrum Master?

Solo un facilitador.

Removedor de todos los impedimentos.

CUARTO
MÓDULO
Eventos
Introducción a los
Eventos Scrum
Eventos

Sprint

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective
El sprint
 Sprint
Corazón de Scrum Bloque de tiempo <- 1 mes

Se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.

Contiene Sprint Planning, Daily Scrum, trabajo de desarrollo, Sprint Review y Sprint Retrospective.

Cada sprint puede considerarse con un horizonte no mayor a un mes.

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.
¿Qué no se hace en un Sprint?

Corazón de Scrum

Cambiar el Objetivo del Sprint

Disminuir la calidad del producto

 Sprint
Planning
 Sprint Planning
La planificación y Inicio del Sprint El equipo Scrum
negociación 8 horas

El trabajo a realizar se realiza en este evento, se realiza en colaboración con el Equipo Scrum completo.

El Scrum Master se asegura que se lleve a acabo el evento y se entienda su propósito.

Preguntas:
¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
 Sprint Planning virtual
Objetivo de Sprint
¿QUÉ? Product Backlog

Sprint Backlog

¿CÓMO?

Herramientas de
facilitación

Reuniones
Virtuales
 ¿Qué no se hace un Sprint Planning?
La planificación y
negociación

Solo el Product Owner define el objetivo del Sprint.

El Scrum Master dirige el evento.

El número de elementos de la Lista de Producto seleccionados para el Sprint depende únicamente del Product Owner.

El Product Owner no asista al evento.

Daily
Scrum
 Daily Scrum

La sincronización 15 minutos El equipo Desarrolo

Se realizan todos los días a la misma hora, orientados a sincronizar para llegar al objetivo del sprint.

Preguntas:
¿Qué hice ayer, que ayudó al equipo a estar más cerca del objetivo?
¿Qué haré hoy, que ayudará al equipo a estar más cerca del objetivo?
¿Qué me esta bloqueando para llegar a cumplir el objetivo?
¿Qué no se hace en una daily Scrum?

La sincronización

No se realice diariamente.

No enfocarse en el objetivo del Sprint

El Scrum Master dirija el evento.

Hacer preguntas técnicas.

Sprint
Review
 Sprint Review

El Feedback Final del Sprint El equipo Scrum

4 horas y Stakeholders

El producto owner presenta lo que se terminó y no terminó durante el sprint.

Se realiza una demo de lo que se desarrollo.

Inspección y adaptación del incremento, para que con ello se pueda obtener el feedback de los interesados.
¿Qué no se hace una Sprint Review?

El Feedback

Solo se realice con el equipo Scrum.

Se realice de vez en cuando.

El Scrum Master dirija el evento.

 Sprint
Retrospective
 Sprint Retrospective
La evaluación Después del Srint Review
3 horas El equipo Scrum
del Sprint

El equipo reflexiona sobre el Sprint actual, permitiendo inspeccionarse y adaptarse para crear un plan de mejoras.

Se buscan mejoras en proceso, personas y prácticas.

Crear un plan para implementar las mejoras a la forma en la que el equipo Scrum desempeña su trabajo.

Preguntas:
¿Qué funcionó?
¿Qué no funcionó?
¿Qué podemos probar?
 Sprint Retrospective virtual

La evaluación
del Sprint

Acuerdos Dinámica Recolectar información

Analizar información Acciones de mejora Feedback

¿Qué no debería pasar en una
Sprint Retrospective?

La evaluación
del Sprint

Solo enfocarse en mejoras a nivel de personas.

Que asistan personas ajenas al equipo scrum.

Que no se obtenga acciones de mejora después del evento.

QUINTO
MÓDULO
Artefactos
 Introducción a los
Artefactos de Scrum
 Artefactos

Product Backlog Sprint Backlog Incremento

Product
Backlog
 Lista ordenada de lo que es necesario
hacer en el producto.

El Product Owner es el responsable

de la lista de producto.

Nunca está completa.

Evoluciona con el tiempo.

Es dinámica y cambia constantemente.

Enumera todas las características, funcionalidades,

requisitos, mejoras y correcciones.
PBI: Product Backlog Item
 Sprint
Backlog
 Conjunto de elementos de la Lista de Producto
seleccionados para el Sprint.

Es una predicción hecha por el Equipo

de Desarrollo.

Cuando se requiere nuevo trabajo, el Equipo de

Desarrollo lo adiciona a la Lista de Pendientes del
Sprint.

Cuando algún elemento del plan se considera

innecesario, es eliminado.

PBI: Product Backlog Item

Incremento
 Es la suma de todos los elementos de la Lista de
Producto completados durante un Sprint.

Al final de un Sprint el nuevo Incremento

debe estar “Terminado”.

Es un cuerpo de trabajo inspeccionable y

terminado que respalda el empirismo.

Es un paso hacia una visión o meta.

PBI: Product Backlog Item

SEXTO
MÓDULO
Definition of Done
 Introducción al
Definition of done
¿Cuándo decimos que un PBI está terminada?

Cuando cumple su Definition of Done.

Cuando el incremento es potencialmente liberable.

 ¿Qué es el
Definition of done?
 Cada equipo Scrum, tiene su propia Definition of Done.

Pero para ello, el equipo Scrum debe tener entendimiento compartido

de lo que significa que el trabajo esté completado.

Se utiliza para evaluar cuándo se ha completado el trabajo sobre

el Incremento de producto.

El propósito de cada Sprint es entregar Incrementos de funcionalidad que

potencialmente se puedan poner en producción.

Cada Incremento se integra con todos los Incrementos anteriores y es probado de

manera exhaustiva,asegurando que todos los Incrementos funcionan en conjunto.

https://www.scrum.org/resources/blog/done-understanding-definition-done
 DoD inicial DoD madura DoD riguroso

Se cumplen todas las funcionalidades Se cumplen todas las funcionalidades

Todos los criterios de aceptación.
comerciales y los criterios de aceptación. comerciales y los criterios de aceptación.

Cobertura de pruebas unitarias Cobertura de pruebas unitarias mayor

Prueba de integración aprobada.
mayor a 85%. a 85%.

Prueba funcional aprobada. Deudas técnicas menor al 5%. Sin fallas de construcción.

Revisión de código de pares. Pruebas automatizadas mayor al 75%. Pruebas de regresión conforme.

Sin defectos. Revisión de código de pares. Documentación completa

https://www.scrum.org/resources/blog/done-understanding-definition-done
 Explicación del proyecto
A realizar y el cuestionario
Se adjunta el caso a realizar, es recomendable que lo realicen con dos personas más.

Considerar que una persona tenga el rol de Product Owner.

Considerar que una persona tenga el rol de Scrum Master.

Considerar que una persona tenga el rol de equipo de desarrollo.

Leer el caso y seguir las instrucciones.

 Conclusiones y
despedida del curso
 Scrum es fácil de entender, pero difícil de aplicar.

El cambio realmente empieza por uno mismo.

Si se quiere realizar cambios a nivel organizacional, se debe empezar por las gerencias.

El ritmo de adopción de este marco de trabajo, va a depender mucho del cambio en las personas.
 Nueva guía Scrum 2020
https://www.scrumguides.org/scrum-guide.html