𝓒𝓻𝓮𝓪𝓭𝓸 𝓹𝓸𝓻:
𝓚𝓮𝓷 𝓢𝓬𝓱𝔀𝓪𝓫𝓮𝓻 𝓙𝓮𝓯𝓯 𝓢𝓾𝓽𝓱𝓮𝓻𝓵𝓪𝓷𝓭
¿𝓠𝓾𝓮 𝓮𝓼 𝓢𝓬𝓻𝓾𝓶?
Proceso en el que se aplican conjuntos de buenas prácticas para trabajar
de manera colaborativa y así obtener el mejor resultado de un proyecto.
¿𝓒𝓾𝓪𝓵 𝓮𝓼 𝓼𝓾 𝓹𝓻𝓸𝓹𝓸𝓼𝓲𝓽𝓸?
Tener un marco de trabajo para desarrollar, entregar y mantener productos
complejos.
𝓛𝓲𝓿𝓲𝓪𝓷𝓸
𝓕𝓪𝓬𝓲𝓵 𝓭𝓮 𝓔𝓷𝓽𝓮𝓷𝓭𝓮𝓻
𝓓𝓲𝓯𝓲𝓬𝓲𝓵 𝓭𝓮 𝓭𝓸𝓶𝓲𝓷𝓪𝓻
Scrum se basa en la teoría de control de procesos empírica o empirismo.
El empirismo asegura que el conocimiento viene de la experiencia y la toma
de decisiones basándose en lo que se conoce.
𝓘𝓶𝓹𝓵𝓮𝓶𝓮𝓷𝓽𝓪𝓬𝓲𝓸𝓷 𝓭𝓮𝓵 𝓬𝓸𝓷𝓽𝓻𝓸𝓵 𝓭𝓮 𝓹𝓻𝓸𝓬𝓮𝓼𝓸𝓼
𝓮𝓶𝓹𝓲𝓻𝓲𝓬𝓸𝓼
Transparencia: Visible para quienes son responsables del resultado, debe
compartirse con un ‘lenguaje común’ para referirse a los procesos.
Inspección: No debe ser frecuente, debe revisarse el progreso hacia un
objetivo fijado para la detección de algún cambio no deseado.
Adaptación: Si se considera que algo cambia y no es aceptable debe
ajustarse en el menor tiempo posible.
𝓑𝓾𝓻𝓷𝓭𝓸𝔀𝓷 𝓒𝓱𝓪𝓻𝓽 𝓭𝓮𝓵 𝓢𝓹𝓻𝓲𝓷𝓽
Es el proceso por el cual es medido un proyecto Scrum.
Debe:
Mostrar el trabajo restante
Responsables
Ser actualizado cada reunión
𝓟𝓾𝓷𝓽𝓸𝓼
𝓢𝓹𝓻𝓲𝓷𝓽
𝓜𝓪𝓷𝓲𝓯𝓲𝓮𝓼𝓽𝓸 𝓐𝓰𝓲𝓵
Lean: Maximiza valor para el cliente, se reduce el ‘desperdicio’ del
producto.
Ágil: Se debe tener mentalidad con valores y principios.
Scrum: Debe existir un marco para el manejo de tareas complejas.
𝓢𝓽𝓪𝓷𝓭𝓲𝓼𝓱 𝓖𝓻𝓸𝓾𝓹
Se especializa en la Gestión de proyectos y muestra una estadística de
éxitos al año; se enfoca en 3 niveles:
Exitoso: Cumple con alcance, STANDISH GROUP
tiempo y presupuesto. Exitoso Parcialmente exitoso Fracaso
Parcialmente exitoso: No
cumple con alguno de los
puntos fijados desde el inicio.
Fracaso: No termina ninguno
de los puntos.
𝓟𝓻𝓸𝓬𝓮𝓼𝓸 𝓔𝓶𝓹𝓲́𝓻𝓲𝓬𝓸
Marco Cynefin: Compara las características y el grado de dificultad
de las siguientes situaciones:
o Sencillo: Fácil de hacer.
o Complicado: Se resuelve y ejecuta con un plan definido.
o Complejo: No se define ningún detalle y comportamiento
desde que se inicia.
o Caótico: La actividad pasa a tener que salir de ese ‘estado’ y
a actuar de manera inmediata.
𝓢𝓹𝓻𝓲𝓷𝓽
𝓣𝓲𝓮𝓶𝓹𝓸 𝓹𝓻𝓸𝓭𝓾𝓬𝓽𝓲𝓿𝓸 𝓹𝓪𝓻𝓪 𝓪𝓬𝓽𝓲𝓿𝓲𝓭𝓪𝓭𝓮𝓼
Es iterativo e incremental.
Iterativo: Desde el inicio puede usarse,
solo va mejorando.
Incremental: Algo bien hecho desde
que se inicia.
El sprint siempre debe 𝓮𝓼𝓽𝓪𝓻 𝓹𝓻𝓸𝓽𝓮𝓰𝓲𝓭𝓸, no deben realizarse cambios que
puedan afectar su objetivo principal, los objetivos de calidad no deben
disminuir.
𝓣𝓲𝓶𝓮𝓫𝓸𝔁𝓲𝓷𝓰
En Sprint, debe tener una duración de 1 a 4 semanas, la retroalimentación
en esta etapa es para mejorar el producto.
Timeboxing de eventos de Scrum
Sprint: 1 mes de duración como
máximo.
Sprint Planning: 8 horas para un
Sprint de un mes.
Daily Scrum: 15 minutos sin importar
la duración del sprint.
Sprint Review: 4 horas para un Sprint
de un mes.
Sprint Retrospective: 3 horas para un
Sprint de un mes.
𝓥𝓲𝓼𝓲𝓸𝓷 𝓖𝓮𝓷𝓮𝓻𝓪𝓵 𝓭𝓮 𝓵𝓸𝓼 𝓻𝓸𝓵𝓮𝓼 𝓭𝓮 𝓮𝓺𝓾𝓲𝓹𝓸
Un equipo Scrum está conformado por grupos de trabajo de entre 3 a 9
miembros del equipo de desarrollo, más el Scrum Master y el Product Owner.
Cada uno, tiene diferentes responsabilidades y debe de mostrar los avances
alcanzados de acuerdo a sus responsabilidades y objetivos.
𝓟𝓻𝓸𝓭𝓾𝓬𝓽 𝓞𝔀𝓷𝓮𝓻
Define y prioriza elementos.
Toma decisiones que abarcan contenidos
y fechas de entregas.
Responsable de que el producto sea
exitoso.
Debe estar disponible para cualquier duda
que pueda tener el equipo.
Trabaja en conjunto con el cliente y el
equipo.
𝓢𝓬𝓻𝓾𝓶 𝓜𝓪𝓼𝓽𝓮𝓻 – 𝓛𝓲𝓭𝓮𝓻 𝓪𝓵 𝓼𝓮𝓻𝓿𝓲𝓬𝓲𝓸 𝓭𝓮𝓵 𝓮𝓺𝓾𝓲𝓹𝓸
Ayuda a que sea más fácil el proceso y
organización del equipo.
Elimina posibles fracasos y facilita el intercambio
de información.
Es el '𝓓𝓾𝓮𝓷̃𝓸 𝓭𝓮𝓵 𝓹𝓻𝓸𝓬𝓮𝓼𝓸'.
Es el encargado de entrenar al Product Owner y
al equipo de desarrollo. 𝓝𝓮𝓬𝓮𝓼𝓲𝓽𝓪 𝓒𝓻𝓮𝓭𝓲𝓫𝓲𝓵𝓲𝓭𝓪𝓭
𝓔𝓺𝓾𝓲𝓹𝓸 𝓭𝓮 𝓓𝓮𝓼𝓪𝓻𝓻𝓸𝓵𝓵𝓸
Normalmente conformado de 3 a 9
personas.
Debe ser autoorganizado.
Es el encargado de entregar el
incremento y progreso del sprint.
Tiene el poder de solicitar cualquier
recurso adicional.
𝓟𝓻𝓸𝓭𝓾𝓬𝓽 𝓑𝓪𝓬𝓴𝓵𝓸𝓰
Es la única fuente del ‘Alcance del Proyecto’, contiene una lista ordenada
de características, se encuentra en cambio constante y utiliza historias de
Usuario del Product Backlog Item (PBI).
𝓗𝓲𝓼𝓽𝓸𝓻𝓲𝓪𝓼 𝓭𝓮 𝓤𝓼𝓾𝓪𝓻𝓲𝓸
No son descripciones detalladas, sin embargo, es un requerimiento del
producto visible para el cliente
Como <𝓡𝓸𝓵> quiero <𝓪𝓬𝓬𝓲𝓸́𝓷> [𝓹𝓪𝓻𝓪 𝓺𝓾𝓮 <𝓿𝓪𝓵𝓸𝓻 𝓭𝓮 𝓷𝓮𝓰𝓸𝓬𝓲𝓸>]
Ejemplo:
ℂ𝕠𝕞𝕠 𝕦𝕤𝕦𝕒𝕣𝕚𝕠, 𝕢𝕦𝕚𝕖𝕣𝕠 𝕙𝕒𝕔𝕖𝕣 𝕦𝕟𝕒 𝕔𝕠𝕡𝕚𝕒 𝕕𝕖 𝕤𝕖𝕘𝕦𝕣𝕚𝕕𝕒𝕕 𝕕𝕖 𝕥𝕠𝕕𝕠 𝕞𝕚 𝕕𝕚𝕤𝕔𝕠
𝕕𝕦𝕣𝕠.
Definición de Terminado Criterios de Aceptación
Debe contener una lista de Debe ser cumplir con las
chequeo. condiciones de satisfacción.
Cada historia de usuario debe Debe ser individual para cada
cumplir con las condiciones historia de usuario.
descritas.
Ejemplo: Ejemplo:
Compra con tarjeta de
crédito.
¿𝓒𝓸𝓶𝓸 𝓮𝓼𝓽𝓲𝓶𝓪𝓻?
Historia de
Estimado Resultado
Referencia
Elegir la historia Se estima el tamaño de Se discuten resultados y
más pequeña las historias después de se vota nuevamente
(se agregan ser compartidas con el para después promediar
puntos). equipo. los números que estén
dentro de las últimas
cartas.
¿𝓟𝓸𝓻 𝓺𝓾𝓮 𝓮𝓼𝓽𝓲𝓶𝓪𝓻 𝓬𝓸𝓷 𝓹𝓾𝓷𝓽𝓸𝓼?
Porque los puntos representan valores relativos y son variables para cada
equipo, estos dan idea del tamaño y esfuerzo de cada uno para que la
tarea sea realizada.
Estimación de tiempo Estimación de tamaño
Es la medida para todo el Después de 3 0 4 sprint, el
equipo, no se mide por equipo llega a un ‘estado
experiencia/ estable’ y es más fácil llenar
habilidades de cada las historias de usuario para el
integrante. producto owner.
𝓘𝓷𝓬𝓻𝓮𝓶𝓮𝓷𝓽𝓸 𝓭𝓮𝓵 𝓹𝓻𝓸𝓭𝓾𝓬𝓽𝓸
El equipo de desarrollo es el encargado de entregar avances.
El incremento es la suma de todos los elementos de la lista de
productos completados y el valor de los incrementos de los Sprint
anteriores.
Debe ser aceptado por el Product Owner para su validez.
𝓡𝓮𝓾𝓷𝓲𝓸𝓷𝓮𝓼 𝓭𝓮 𝓢𝓬𝓻𝓾𝓶
𝓟𝓵𝓪𝓷𝓮𝓪𝓬𝓲𝓸́𝓷 𝓭𝓮 𝓢𝓹𝓻𝓲𝓷𝓽
¿Quién/quiénes deben participar?
o Equipo de desarrollo
o Product Owner
o Scrum Master
o Invitados (clientes)
¿Cuándo y cuánto dura?
o Al inicio de cada Sprint
o 8 hrs para un sprint por cada mes
Entrada
o Product backlog
o Último incremento del producto
o Capacidad proyectada del equipo de desarrollo
o Desempeño anterior del equipo
Salida
o Meta del Sprint
o Product Owner define prioridades y responde preguntas
o El equipo de desarrollo desglosa sus actividades
o El Scrum master se asegura que el marco de referencia sea
seguido
𝓢𝓬𝓻𝓾𝓶 𝓓𝓲𝓪𝓻𝓲𝓸
¿Quién/quiénes?
o Equipo de desarrollo
o Scrum master (no es siempre necesario)
¿Cuándo y cuánto tiempo?
o A la misma hora, definida por el equipo
o Dura máximo 15 minutos
Entrada
o El equipo responde: ¿qué hice ayer para lograr el objetivo?,
¿qué haré hoy?, ¿hay algún impedimento para mis
actividades?
Salida
o Entendimiento del trabajo para llegar a la meta
El Sprint Backlog debe mostrar los puntos trabajados y por quien.
𝓡𝓮𝓿𝓲𝓼𝓲𝓸́𝓷 𝓭𝓮𝓵 𝓢𝓹𝓻𝓲𝓷𝓽 - 𝓥𝓪 𝓮𝓷𝓯𝓸𝓬𝓪𝓭𝓸 𝓪 𝓵𝓪 𝓻𝓮𝓿𝓲𝓼𝓲𝓸́𝓷 𝓭𝓮𝓵 𝓹𝓻𝓸𝓭𝓾𝓬𝓽𝓸
¿Quién/quienes?
o Equipo de desarrollo
o Product Owner
o Scrum Master
Entrada
o Incremento
o Product Backlog
Salida
o Incremento del producto
o Retroalimentación
El equipo muestra parte del código de trabajo y solo son mostradas las
historias terminadas al 100%.
𝓡𝓮𝓽𝓻𝓸𝓼𝓹𝓮𝓬𝓽𝓲𝓿𝓪 𝓭𝓮𝓵 𝓢𝓹𝓻𝓲𝓷𝓽 – 𝓔𝓷𝓯𝓸𝓬𝓪𝓭𝓸 𝓪𝓵 𝓹𝓻𝓸𝓬𝓮𝓼𝓸
¿Quién/quiénes?
o Equipo de desarrollo
o Product Owner
o Scrum master
¿Cuándo y cuánto tiempo?
o Después de la revisión del sprint
o 3 horas para un sprint de 1 mes
Entrada
o Información de todos los equipos acerca del último sprint
Salida
o ¿Qué salió bien?
o Mejoras en el producto
𝓟𝓵𝓪𝓷 𝓭𝓮 𝓵𝓪𝓷𝔃𝓪𝓶𝓲𝓮𝓷𝓽𝓸
Basado en alcance
Basado en tiempo
Debe ser refinado en puntos obligatorios definidos en el producto backlog y
pronosticados en funcionalidad, es decir predecir cuando estarán listos para
su entrega final.
