Scrum es un framework de metodologías ágiles. Propone resolver un problema complejo de a pedazos pequeños.
Algo complejo partirlo en pedazos chicos e ir iterando
Propone un marco de trabajo, un conjunto de reglas para trabajar de forma controlada.
Cuando se esta en una etapa de desorden, en la que no se sabe para donde ir, hay que parar para reflexionar, y ver en donde encaja nuestro problema.
En simple hay un conjunto de pasos.
En complicado, hay pasos para resolverlo pero lo hacen expertos.
En complejo, cuando el efecto de las causas se conocen solo cuando ya ocurrió el evento. Se necesita prueba-error, experimentar.
El caótico, es una situación de emergencia si pasos ni practicas. Hay que actuar.
Las metodologías ágiles funcionan muy bien en problemas complejos. El humano es impredecible
Hay que resolver un problema con cierto grado de desorden.
El product owner junto una parte del equipo va escribiendo las HISTORIAS DE USUARIO (user stories).
El PO arma estas historias evolutivamente, escribe la historia de la aplicacion, describe las historias que va contando el usuario.
USE STORIES -> el usuario le cuenta su historia al PO, ese es el origen del termino.
Se estructuran en SENTENCIAS -> se van acumulando en un PRODUCT BACKLOG -> lista que es un CAOS.
El product backlog crece constantemente.
CAOS -> El PO no pone las cosas en orden, no están totalmente definidas.
Suele faltar información e especificaciones en ese backlog, Lista de todas las cosas que hay que hacer aunque no estén totalmente definidas de antemano.
Hay grado de incertidumbre.
Se definen cuando el PO se vaya juntando con el usuario y vayan definiendo mejor.
Luego hacemos un SPRINT PLANNING, dividimos el desarrollo en SPRINTS. Se agarran algunas de esas historias las que van a entrar en el siguiente sprint.
Estas SPRINTS deben tener tareas DEFINIDAS, no se hace un sprint sin saber que hacer.
Cada una de esas historias se estiman -> se ponen PUNTOS a cada historia según el seniority llegando a un acuerdo con todo el equipo.
El output del SPRINT PLANNING es el SPRINT BACKLOG.
En el sprint backlog YA NO HAY CAOS. Es un conjunto de historias fijas bien definidas.
A estas historias del SPRINT BACKLOG se las estiman antes de cada sprint.
Todos los dias a medida que avanza el sprint, se va teniendo la DAILY SCRUM.
En las DAILY se charla de -> que estan haciendo, que hicieron el dia anterior y que van a hacer en el dia.
Finalizado el sprint se hace la SPRINT REVIEW -> el equipo hace una DEMO al PO y/o al usuario sobre el avance del sprint.
Goal del primer sprint -> algo andando
RETRO -> luego del sprint review, se hace una retro para el equipo, para que evolucione y mejore el equipo
Ademas de las historias de usuario, el Product Owner a medida que va hablando con el Líder Técnico, se pueden ir agregando HISTORIAS TECNICAS al Backlog.
BACKLOG REFINEMENT -> takes place continuesly. agarran el PO con el lider del equipo van refinando las user histories. Le agregan detalles y las puedan incluir an un sprint. Se agregan HISTORIAS TECNICAS.
Se ataca el PRODUCT BACKLOG para ir refinandolo continuamente.
Las ceremonias ágiles facilitan la comunicación entre los miembros del equipo y promueven una comprensión compartida de lo que se está construyendo dentro de un sprint.
DEUDA TÉCNICA -> todas las cosas que dejamos de lado para llegar al deadline, aclarar en las historias tecnicas que nos van a ralentizar esas deudas tecnicas mas adelante. Creamos una historia en el backlog para estas.
-
¿Qué es?
- Un esfuerzo colaborativo que involucra a un Scrum Master, quien facilita la reunión; a un Product Owner, quien aclara los detalles de los ítems del backlog del producto y sus respectivos criterios de aceptación; y al equipo de desarrollo, quienes definen el trabajo y el esfuerzo necesario para cumplir con el objetivo del sprint.
-
¿Qué hace el equipo?
- Planificación de la Capacidad: Colaboración del equipo para decidir cuánto tiempo se puede asignar al sprint.
- Objetivo del Sprint: Resumen del Product Owner sobre el resultado deseado para el sprint que se está planificando. Proporciona un objetivo compartido y explica por qué vale la pena emprender el sprint.
- Sprint Backlog: Las historias de usuario se agregan al sprint backlog en base a un acuerdo colectivo del equipo. Esta es una oportunidad para que el equipo haga preguntas para aclarar lo que se pide en la historia de usuario si no se cubrió completamente en la refinación del backlog.
-
¿Cuál es el resultado?
- Un objetivo del sprint y un sprint backlog sobre el cual trabajar durante el sprint limitado por tiempo.
-
¿Qué es?
- Una reunión diaria limitada por tiempo a la que asisten el Scrum Master, el Product Owner y el equipo de desarrollo para establecer el contexto del trabajo del día, revisar el trabajo recientemente completado y abordar cualquier impedimento para alcanzar el objetivo del sprint. Este tiempo también puede ser utilizado para realizar o discutir cualquier ítem que el equipo acuerde sobre la marcha o que haya sido previamente planificado.
-
¿Qué hace el equipo?
- Cada miembro del equipo aborda su contribución en tiempo real al objetivo del sprint y cualquier cosa que pueda bloquear el progreso futuro dentro del sprint.
- Los equipos a menudo se enfocan en las siguientes preguntas: ¿Qué logré desde la última vez que colaboramos? ¿En qué estoy trabajando hasta que volvamos a colaborar? ¿Qué está impidiendo el progreso en este sprint?
-
¿Cuál es el resultado?
- Una comprensión precisa de lo que se ha hecho, qué trabajo queda por hacer, y qué impedimentos existen que bloquean al equipo para completar el objetivo del sprint.
-
¿Qué es?
-
Es una reunión que se lleva a cabo el último día del sprint, donde el equipo Scrum muestra lo que ha logrado durante el sprint. Generalmente, esto se realiza a través de una demostración de las nuevas características y funcionalidades de un producto para los stakeholders, aunque también puede incluir cualquier otro logro del equipo. Durante esta sesión, se invita a los asistentes a proporcionar retroalimentación sobre el trabajo actual y a sugerir cambios, los cuales se documentan para ser considerados.
-
¿Qué hace el equipo?
- El equipo tiene la libertad de presentar su trabajo de la manera que considere más adecuada, con el objetivo principal de dejar claro lo que se ha logrado durante el sprint y abrir el espacio para recibir retroalimentación y sugerencias de cambios necesarios.
-
-
¿Cuál es el resultado?
- Revisión y retroalimentación sobre lo que se completó en el sprint más reciente.
- Comprensión por parte de los stakeholders sobre lo que se completará en el corto plazo.
-
¿Qué es?
- Es un período dedicado al final de cada sprint en el que el equipo reflexiona sobre sus logros y dificultades durante el sprint, además de explorar oportunidades para mejorar continuamente el valor incremental que están proporcionando al producto, característica o componente.
-
¿Qué hace el equipo?
- Crear un ambiente seguro y exploratorio para identificar los logros y desafíos dentro del sprint, y reflexionar sobre cómo y si el equipo está alcanzando sus metas.
- Algunas preguntas clave que pueden guiar una retrospectiva productiva incluyen: ¿Qué salió bien?, ¿Qué no salió bien?, ¿Qué podemos mejorar? Se recomienda encarecidamente personalizar las preguntas para obtener retroalimentación específica sobre el producto en cuestión.
-
¿Cuál es el resultado?
- Una reflexión sobre lo que el equipo está haciendo bien y lo que pueden mejorar, además de identificar los elementos clave en los que el equipo puede enfocarse para mejorar continuamente su enfoque en el desarrollo del producto.
La Retrospectiva de Sprint te permite revisar tu último sprint e implementar mejoras para futuros sprints.
Estas reuniones son esenciales, ya que evaluar y mejorar los procesos con regularidad mejora los resultados y reduce los obstáculos.
El objetivo de la Retrospectiva de Sprint es determinar qué ha ido bien y dónde ha habido problemas, e identificar las áreas en las que puedes mejorar.
