Want to create interactive content? It’s easy in Genially!
PRESENTACIÓN CASO PRACTICO SCRUM
edpinto
Created on April 9, 2022
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Audio tutorial
View
Pechakucha Presentation
View
Desktop Workspace
View
Decades Presentation
View
Psychology Presentation
View
Medical Dna Presentation
View
Geometric Project Presentation
Transcript
INTEGRANTES EMILY DAYANA PINTO CARPIO JHON ANTONY UREÑA BOHORQUEZ TOMMY JOSUA VIANA NAVARRO MICHAEL DAVID YUQUILEMA CAMPO
Caso practico Scrum
elementos
ROLES
Development team
Product Oner
Scrum Master
eventos
SPRINTS
Duracion de sprints: 4 semanas reuniones: 5 de 2 a 3 horas Cada Sprint puede tener una duración diferente, pero todos los que conforman un Scrum no deberían durar más de un mes. Una vez que han sido definidos no puede haber cambios durante la ejecución que supongan un riesgo para la consecución de los objetivos. Sprint Planning, Daily Scrum Meeting, Sprint Review, Sprint Retrospective, backlog refinement
SPRINT PLANNING
se ponen objetivos para el protecto y se realiza a un principio participa el equipo de desarrolladores se reasliza un Un product backlog se desglosan las tareas se muestran las historias presentadas por el product owner se ponen todas las historias en una pizarra e ideas como si fuera un borrado El equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint.
SPRINT PLANNING
Daily SCRUM
Es denominada la Reunión diaria de sincronización del equipo o (Scrum daily meeting) Reuniones diarias de duracion de 15 minutos Se lleva a cabo en la misma hora y lugar cada día Durante el daily scrum, cada miembro del equipo responde las siguientes 3 preguntas: ¿Qué hiciste ayer? ¿Que harás hoy? ¿Hay impedimentos en tu camino? es una reunión donde cada miembro del equipo se informa y compromete con el resto. Mejora la comunicacion entre los desarrolladores
Daily SCRUM
Sprint Review
El Sprint Review es la reunión que ocurre al final del Sprint, generalmente el último viernes del Sprint, se revisará el incremento terminado. Se mostrará el software funcionando en producción y las partes interesadas tendrán la oportunidad de hacer cuantas preguntas que tengan sobre el proyecto El equipo de desarrollo comenta qué ha ocurrido durante el Sprint, los impedimentos que se han encontrado, así como soluciones tomadas y actualizan a llas personas interesadas con la situación del equipo no se trata de una demo para un cliente o para los stakeholders o incluso para el product owner, ni es tampoco una reunión para felicitar al Equipo de Desarrollo. Es una reunión de trabajo, una de las más importantes porque sirve para marcar la estrategia de negocio.
Sprint Retrospective
El Sprint Review es la reunión que ocurre al finTambién se utiliza el formato de retrospectiva basado en cinco fases: Preparar el ambiente: un pequeño ejercicio para romper el hielo. Recolectar información: durante esta fase, se utilizan actividades para intentar construir una imagen de lo que ha sido el último Sprint, resultando una imagen conjunta de equipo. Generación de ideas: el equipo intenta generar ideas para identificar acciones que ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint. Decidir qué hacer: de las ideas generadas, se proponen acciones que el equipo pueda implementar en el próximo Sprint. Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la propia retrospectiva, ayuda al equipo a decidir hacia dónde dirigirse en próximas ocasiones. Un recordatorio de la mejora continua.
El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo.
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En algunos casos y por comodidad de los equipos, se realiza conjuntamente con el Sprint Planning,
Un formato común es analizar qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar.
REFINEMENT
El refinamiento del Product Backlog es un evento dedicado a agregar detalles, estimar y ordenar las historias de usuario que haya dentro del Product Backlog. Esta ceremonia sigue un patrón similar al resto y tiene una agenda fija específica en cada Sprint. Se estima su duración en 2 horas máximo por semana del Sprint. 🚀 Incrementar transparencia 💎 Agregar valor a los items 💣 Reducir dependencias } 🔑 Predictividad 💊 Empirismo
Lorem ipsum dolor
beneficios de refinar el product backlog
2020
ARTEFACTOS
En los artefactos se encuentran el product backlog, sprint backlog, y el incremento son pensados y diseñados para poder garantizar la transparemcia dentro del proyecto evitan una mala comunicacion entre el equipo scrum previene un mal manejo de la informacion en la entrega del proyecto
Sprint backlog
se construye durante el evento del Sprint Planning Es un plan realizado por y para los Developers. Se compone del Sprint Goal (“por qué”), el conjunto de elementos del Product Backlog seleccionados para el Sprint (“qué”) y un plan para entregar el Incremento (“cómo”). Se puede ajustar a lo largo de Sprint si es necesario, a medida que el equipo aprende más sobre la tarea. Debe tener suficientes detalles para que el Scrum Master pueda inspeccionar el progreso del equipo en el Daily Scrum.
Sprint backlog
Product backlog
Es una lista emergente y ordenada de todo lo que se conoce que es necesario que un producto o servicio cumpla. Si el proyecto o producto amerita una lista larga, podemos tener cientos o miles de actividades en el product backlog.product backlog tiene permitido crecer y cambiar tanto como sea necesario, en función a lo que se va aprendiendo sobre el producto y los clientes. El trabajo técnico y las actividades para adquirir nuevo conocimiento también se consideran en el product backlog.
Product backlog
Increment
Cada Incremento debe ser probado extensivamente para asegurar que funciona de manera integral junto con los Incrementos anteriores. – Al final de un Sprint el nuevo Incremento debe estar “Terminado”, esto es, ha de cumplir la Definición de Hecho y debe estar en condiciones de utilizarse, con independencia de si el Product Owner decide su puesta en producción o no. – Un Incremento puede ponerse en producción antes de que concluya el Sprint, no es necesario que esperemos a la Sprint Review. De hecho, cuanto antes esté a disposición de clientes o stakeholders, antes generaremos valor. El Incremento es presentado en la Sprint Review, que es una sesión colaborativa entre Equipo Scrum y stakeholders, en la que obtener feedback sobre el producto y adaptar el Product Backlog, si procede.
REsultados
REsultados
REsultados
REsultados
REsultados
Bibliografias