Want to create interactive content? It’s easy in Genially!

Get started free

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:

Audio tutorial

Pechakucha Presentation

Desktop Workspace

Decades Presentation

Psychology Presentation

Medical Dna Presentation

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

https://www.youtube.com/watch?v=HhC75IonpOU https://www.youtube.com/results?search_query=marco+de+trabajo+scrum+video+explicativo+con+dibujos https://www2.deloitte.com/es/es/pages/technology/articles/ceremonias-scrum.html https://www.obsbusiness.school/blog/las-5-etapas-en-los-sprints-de-un-desarrollo-scrum https://www2.deloitte.com/es/es/pages/technology/articles/roles-y-responsabilidades-scrum.html https://docs.google.com/presentation/d/1-TrysWG27_b6BhCLNLJ6diN1VQ5tA2V-6Kmpr1hXJhc/edit