¡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.
- Expresar claramente los elementos del Product Backlog.
- Ordenar los elementos en el Product Backlog para alcanzar los objetivos y misiones de la mejor manera posible.
- Optimizar el valor del trabajo desempeñado por el Development Team.
- Asegurar que el Product Backlog es visible, transparente y claro para todos, y que muestra aquello en lo que el equipo trabajará acontinuación.
- 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.
- 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.
- Los Development Teams son multifuncionales, contando como equipo con todas las habilidades necesarias para crear un Incremento de producto.
- 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.
- 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
Errores más comunes en la Sprint Planning
- ¿Capacidad? El equipo de desarrollo sobreestima su capacidad y asume demasiadas tareas.
- Ignorar la deuda técnica: el equipo de desarrollo no exige la capacidad adecuada para abordar la deuda técnica y los errores durante el Sprint.
- Planificación demasiado detallada: durante la planificación del Sprint, el equipo de desarrollo planifica cada una de las tareas del próximo Sprint por adelantado. No se vuelva demasiado granular.
- Demasiadas estimaciones: el equipo de desarrollo estima las subtareas
- Muy poca planificación: el equipo de desarrollo se salta la planificación por completo.
Daily Scrum
El propósito de la daily scrum es inspeccionar el progreso hacia el objetivo del sprint y adaptar el sprint backlog según sea necesario, ajustando el trabajo planificado restante.
Las Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.
Reunión que busca sincronizar las actividades y el plan del equipo de desarrollo para las siguientes 24 horas. Participa de esta reunión el Development Team.
Debe realizarse todos los días a la misma hora y en el mismo lugar y tiene una duración de quince (15) minutos.
El Development Team es el encargado de establecer la estructura de la reunión y ésta se puede conducir de diferentes maneras si se enfoca en el progreso hacia el objetivo del sprint
¿Qué hice ayer que ayudó al el equipo de desarrollo a lograr el objetivo del sprint?
¿Qué haré hoy para ayudar al equipo de desarrollo a lograr el objetivo del sprint?
¿Veo algún impedimento que evite que el equipo de desarrollo o yo logremos el objetivo del sprint?
Errores más comunes de la Daily Scrum
- Sin rutina: el Scrum diario no se realiza a la misma hora ni en el mismo lugar todos los días.
- Informe de estado: El Scrum diario es una reunión de informe de estado, y los miembros del equipo de desarrollo están esperando en línea para "informar" el progreso
- Solo números de ticket: las actualizaciones son genéricas y tienen poco o ningún valor para los demás.
- Convertir la Daily Meeting en un Planning o refinamiento de nuevos requerimientos.
- Resolución de problemas: las discusiones se activan para resolver problemas
- 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?
- Desorientación: los miembros del equipo no están preparados para el Scrum diario.
- 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
- Limitar las discusiones y practicar la capacidad de sintesis y foco
- No tomar la daily como un reporte, es una sincronización de equipo, tengalo presente.
- La daily tiene lugar a la misma hora y el mismo lugar... no es tan dificil
- Respeta la duración máxima de 15 minutos, el timebox en scrum es un aliado
- 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.
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
- 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.
- La ignorancia del Prime Directive, el equipo atiende la reunión y ocupa el tiempo para quejarse, discutir y culparse.
- El día de la marmota: Repetimos una y otra vez lo mismo, los mismos problemas de siempre.
- 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
- Actitud Victimista: la culpa de todos los males las tienen otras personas ajenas al equipo.
- Amnesia: Las retrospectivas pasadas no cuenta, no se revisan acciones y experimentos acordados
- El mundo de Barnie: todo es felicidad y armonía, no se menciona obstáculos.
- Aterrizaje forzoso: todas las acciones de mejora son vagas. "hacer más test"
- El facilitador se encarga: las acciones se asignan mágicamente al facilitador y se convierte en el único responsable
Ejemplo de Retrospectiva
Refinamiento
Es el acto de agregar detalles, estimaciones y pedidos a los elementos del Product Backlog.
Este es un proceso continuo en el que el Product Owner y el Development Team colaboran en los detalles de los elementos del Product Backlog.
El refinamiento generalmente no consume más del 10% de la capacidad del equipo.
Artefactos
Product Backlog
El Product Backlog o Pila del Producto, es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse.
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:
- Tener PBIs listo para comenzar a trabajar
- Eliminar tiempos muertos
- 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.
