Fundamentos de scrum, Resúmenes de Sistemas Judiciales

¡Descarga Fundamentos de scrum y más Resúmenes en PDF de Sistemas Judiciales solo en Docsity! Fundamentos Scrum Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Scrum es:  Ligero  Fácil de entender  Extremadamente difícil de llegar a dominar Roles Product Owner Es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team. La forma en que esto se hace puede variar ampliamente entre organizaciones, Scrum Teams e individuos. El Product Owner puede representar las necesidades de muchos interesados en el Product Backlog. 1. Expresar claramente los elementos del Product Backlog. 2. Ordenar los elementos en el Product Backlog para alcanzar los objetivos y misiones de la mejor manera posible. 3. Optimizar el valor del trabajo desempeñado por el Development Team. 4. Asegurar que el Product Backlog es visible, transparente y claro para todos, y que muestra aquello en lo que el equipo trabajará acontinuación. 5. Asegurar que el Development Team entiende los elementos del Product Backlog al nivel necesario. Development Team El Development Team está conformado por todos los roles necesarios para construir la funcionalidad o servicio. Se enfocan en la entrega continua de valor. 1. Son autoorganizados, nadie (ni siquiera el Scrum Master) indica al Development Team cómo convertir elementos del Product Backlog en Incrementos de funcionalidad potencialmente desplegables. 2. Los Development Teams son multifuncionales, contando como equipo con todas las habilidades necesarias para crear un Incremento de producto. 3. Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan los dominios particulares que requieran ser tenidos en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla. 4. Los Miembros individuales del Development Team pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo. Scrum Master Es responsable de lograr la efectividad del Scrum Team. Lo hace apoyando al Scrum Team en la mejora de sus prácticas, dentro del marco de trabajo de Scrum. Ayuda a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Scrum Team como de la organización. Eventos Sprint Son eventos de duración fija de un mes o menos para crear consistencia. Un nuevo sprint comienza inmediatamente después de la conclusión del sprint anterior. Durante el sprint: ✓ No se realizan cambios que pongan en peligro el Objetivo del Sprint ✓ La calidad no disminuye 3. Solo números de ticket: las actualizaciones son genéricas y tienen poco o ningún valor para los demás. 4. Convertir la Daily Meeting en un Planning o refinamiento de nuevos requerimientos. 5. Resolución de problemas: las discusiones se activan para resolver problemas 6. Orientación perdida: El Scrum diario tiene un propósito, ya que responde a una pregunta simple: ¿Estamos todavía en camino de alcanzar el Objetivo del Sprint? 7. Desorientación: los miembros del equipo no están preparados para el Scrum diario. 8. Retroalimentación excesiva: los miembros del equipo critican a otros miembros del equipo de inmediato, lo que genera una discusión en lugar de sacar su crítica del Daily Scrum. Consejos para tus Dailys 1. Limitar las discusiones y practicar la capacidad de sintesis y foco 2. No tomar la daily como un reporte, es una sincronización de equipo, tengalo presente. 3. La daily tiene lugar a la misma hora y el mismo lugar... no es tan dificil 4. Respeta la duración máxima de 15 minutos, el timebox en scrum es un aliado 5. Estar atento a reportar los impedimentos para que sean gestionarlos. Sprint Review Es una reunión de colaboración donde se busca “feedback” de todos los presentes fundamentalmente para crear transparencia sobre el incremento de producto y permitir la adaptación del “Product Backlog” El propósito del sprint review es inspeccionar el resultado del sprint y determinar futuras adaptaciones. El Scrum Team presenta los resultados de su trabajo a los interesados clave y se discute el progreso hacia el objetivo del producto / proyecto. Inspeccionar el incremento y recolectar el feedback obtenido en la reunión para adaptar el Product Backlog si fuese necesario. En esta reunión participa todo el equipo SCRUM La Sprint Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación. Ocurre al finalizar el sprint. La duración del evento es de cuatro (4) horas para un sprint de cuatro (4) semanas. Elementos de la Review meeting 1. Los asistentes son el Scrum Team y los stakeholders claves invitados por el Product Owner. 2. El Product Owner explica qué PBIs se han terminado y cuáles no. 3. El Development Team habla acerca de qué estuvo bien durante el sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas. 4. El Development Team hace una demostración del trabajo terminado durante el sprint y responde preguntas acerca del incremento del producto. 5. El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha (si fuera necesario). 6. Los asistentes a la reunión colabora acerca de qué hacer a continuación, de modo que la Sprint Review proporcione información de entrada valiosa para Sprint Planning subsiguientes. Errores más comunes que suceden en la Review 1. Muerte por PowerPoint: Los participantes se aburren hasta la muerte con sus presentaciones 2. Las mismas caras de nuevo: Siempre es la misma gente del equipo de desarrollo que participan, no todos. 3. Trabajo extra: el equipo de desarrollo estaba trabajando en temas fuera del objetivo de Sprint, y el propietario del producto se entera sobre ello por primera vez durante la revisión de Sprint. 4. Hacer trampa:el equipo de desarrollo muestra elementos que no estan "terminados". 5. Un reporte de estatus el Development Team le cuenta al Scrum Master o Product Owner o algún stakeholders el avance del proyecto Sprint Retrospectiva Es una oportunidad para que el Scrum Team se inspeccione a sí mismo; interacciones, procesos, herramientas y definición de terminado, y cree un plan para implementar mejoras durante el próximo Sprint. El Scrum Team analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas. Esta reunión se hace después del sprint review “Es una reunión especial en la cual un equipo decide hacer una pausa para reflexionar sobre el trabajo realizado, ver qué lecciones pueden capitalizar y decidir cómo aplicar lo que aprendieron en el futuro cercano.” La duración del evento es de tres (3) horas para un sprint de cuatro (4) semanas y con él se finaliza el sprint. A diferencia de una reunión “postmortem” que se realiza al final del proyecto, las retrospectivas son reuniones cortas y que se hacen frecuentemente durante el proyecto lo que significa una oportunidad de atacar los problemas cuando todavía estamos a tiempo ¿Qué esperar de una Retrospectiva? Errores más comunes que suceden en la Retrospectiva 1. La ruleta de la fortuna, el equipo se salta uno o dos pasos de la sesión, a veces tienen suerte, y a veces no. 2. La ignorancia del Prime Directive, el equipo atiende la reunión y ocupa el tiempo para quejarse, discutir y culparse. 3. El día de la marmota: Repetimos una y otra vez lo mismo, los mismos problemas de siempre. 4. Muerte Post morten: " esto me lo guardo para la retro…" 5 Acabemos rápido!: no sacan provecho de la sesión y la consideran una pérdida de ti 6. Actitud Victimista: la culpa de todos los males las tienen otras personas ajenas al equipo. Agile Inception 12. Plan preliminar de entregas 11. Mínimo Producto Viaole MVP. 10, Mapa de funcionalidades 9. ¿Cómo podemos dormir tranquilos? el ha 8.¿Qué nos mantiene despiertos en la noche? ] 12 La lstadel 51 /NO PASOS 5 P 6. Visión del Producto Lay 5. Fl vecindario 4. ¿Por qué estamos aquí? ) 3. Reglas de Juego 2. ¿Quiénes somos? 1 Explicación del Proceso de Inception Agile Refinamiento el próximo sprint SS E) ANTES nta úl ESA PA I ! SS O ln (0% DOR- lato 3. Citar sesión A 6. Identificar correcciones o ajustes Antes 1 1 on 1 Durante es 303 8 7. Realizar correcciones y e ! %stefanini Definición de Listo (DOR) Es un método que se utiliza para asegurarse de que los PBIs del Product Backlog lleguen con todos los insumos y requisitos necesarios antes de ser llevados a un Sprint Planning. El DOR nos ayuda a: 1. Tener PBIs listo para comenzar a trabajar 2. Eliminar tiempos muertos 3. Minimizar incidencias Recordemos que el DOR es un acuerdo entre el Product Owner y el Development Team. Al finalizar el refinamiento de un PBIs se realiza la revisión del DOR; si existe algún item que no se esté cumpliendo se puede llegar a un acuerdo con el Product Owner para que lo gestione antes del planning. TÉCNICAS DE ESTIMACIÓN Estimar es la actividad de predecir lo que una pieza de trabajo requerirá en términos de tiempo, recursos y costo. Esto puede tener un rango desde un estimado de alto nivel de un proyecto o programa hasta estimar en detalle las actividades individuales en un paquete de trabajo. Una estimación en Scrum es una puesta en común de los requisitos a lograr, para definir entre todos una suposición lo más exacta posible, de lo que se puede lograr y en cuanto tiempo. Técnicas de Estimación – Utilidad Los equipos deben conocer y elegir las técnicas de estimación, que mejor se adapten a sus necesidades Estas técnicas serán útiles para: • Definir las actividades dependientes: saber cuándo el equipo puede continuar trabajando en un nuevo diseño • Organizar las actividades prioritarias: decidir las actividades urgentes. • Definir las mejores técnicas de trabajo para ese Sprint: tomar una decisión cuando elegimos entre diferentes opciones de trabajo. • Pronosticar diferentes escenarios: predecir tiempos totales y fechas de entrega del producto. Técnicas de Estimación PLANNING PÓKER Es una técnica para calcular una estimación basada en el consenso, en su mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas. El equipo usa un juego de cartas con números basado en la serie fibonacci. El proceso del “juego” es el siguiente: 1. La persona con más conocimiento de cada HU a estimar, da una breve descripción de la misma. Aquí el resto de participantes pueden hacer preguntas para entender mejor lo que hay que estimar. Si el equipo está en etapa inicial de adopción del marco de trabajo ágil, puede sacar el listado de tareas de cada HU. 2. Después de entender la funcionalidad, cada participante escoge una estimación y coloca boca abajo la tarjeta que representa su estimación. 3. A continuación todos los participantes muestran sus cartas de forma simultánea. 4. A aquellos que han tenido estimaciones altas y bajas (en relación a la media) se les ofrece un tiempo para explicar y justificar sus estimaciones. 5. Se repite el proceso de votación hasta llegar a un consenso. TÉCNICA DE LAS CAMISETAS Es una técnica para calcular una estimación basada en tallas de camiseta, es una estimación relativa. El proceso del “juego” es el siguiente: En este caso cada miembro del equipo ha de indicar si considera que la HU a estimar es: XS (Extra Small), S (Small), M (Medium), L (Large), XL (extralarge) o XXL (Double Extra- Large). De esta forma se elimina la implícita precisión necesaria para un modelo numérico como el anterior, haciendo que el equipo tenga un poco más fácil la tarea y pueda pensar de manera más abstracta en las estimaciones de las funcionalidades a evaluar. Técnicas de Estimación - Herramientas https://www.planningpoker.com/ https://www.planitpoker.com/