Metodologías Agiles - SCRUM - Clase 4 v1.0

Está en la página 1de 28

Metodología Ágiles – SCRUM

Clase 4

Mg. Ing. Erwin E. Salas Coz


¿Cómo será el curso?

• Introducción a las metodologías ágiles y Scrum


• ¿Qué es una metodología ágil?
• Aprendiendo los principios ágiles
• Introducción a Scrum
• Conociendo los componentes de Scrum
Agenda • Comprender los roles en Scrum
• El equipo Scrum
• Forma tu equipo de Scrum
• Presentando al Dueño del Producto o Product Owner
• El rol del Scrum Master
• La base del equipo de desarrollo
¿Cómo será el curso?

• Preparar los artefactos a utilizar en Scrum


• Backlog del producto
• ¿Qué nos cuentan las Historias de Usuario?
• Estimar historias de usuario
• ¿Por dónde comenzar? Prioridades y backlog del sprint
• Midiendo el avance del proyecto
Agenda • Entender y realizar las ceremonias
• ¿Cuál es el ritmo del equipo? El sprint
• Planeando el sprint
• El seguimiento del proyecto: Daily stand-up
• Refinando historias
• Mostrando y aprendiendo: demos y retrospectivas
Presentaciones de la Clase anterior

• Presentaciones de 3 minutos
Entender y Realizar las Ceremonias
Autor: Carlos Benitez
Autor: Carlos Benitez
Fuente: Deloitte
¿Qué es un Sprint?
• Sprint es un contenedor para el resto de eventos de Scrum. El Sprint es continuo, es decir, su duración no debe
cambiar mientras está en marcha el desarrollo del producto, y se puede interpretar como una medida de ritmo
constante a lo largo del tiempo, permitiéndonos reducir complejidad y comparar resultados a lo largo de
diferentes Sprints. El Sprint permite la transparencia, así como inspeccionar y adaptar los otros eventos de
Scrum.

• Scrum prescribe que un Sprint debe durar 4 semanas más o menos. Aunque es bastante habitual que los
equipos Scrum elijan tener Sprints de diversas duraciones según la finalidad perseguida. Cada caso es diferente
y es el equipo Scrum el que debe descubrir cuál es su periodo mínimo necesario para generar valor a través de
un incremento terminado.

• Todo ocurre en un sólo Sprint y en cada Sprint. La mentalidad de un proyecto por Sprint es uno de los cambios
más difíciles de asumir para las organizaciones que están haciendo una transición a esta metodología Agile-
Scrum. A diferencia de la gestión tradicional de proyectos, donde un proyecto puede durar meses o años, en
Scrum un “proyecto” dura un sólo un Sprint, de modo que todas las tareas necesarias para llevar el proyecto a
cabo (como el diseño, la planificación o el testing) se realizan dentro del mismo Sprint, siempre orientado a
generar el máximo valor.

• En Scrum, los proyectos se financian por cada Sprint y es el product owner quien decide dónde y a qué dedicar
los recursos. Entender esto es crítico para asegurar el éxito en el empleo de Scrum en una organización.
Fuente: Deloitte
Sprint Planning
• El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa 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. Estos Product Backlog
Items son los que compondrán el Sprint Backlog.

• Durante esta reunión, el product owner presenta el Product Backlog actualizado que el equipo de desarrollo se
encarga de estimar, además de intentar clarificar aquellos ítems que crea necesarios.

• Si bien en el Sprint Planning participa el equipo Scrum al completo, no participan los stakeholders. En el Sprint
Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of
Done y se adaptan el Sprint Backlog, Sprint Goal y el plan para poder alcanzar ese Sprint Goal.

• El Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata Qué se va a hacer en el
siguiente Sprint y, en la segunda parte, se discute el Cómo. La primera parte está organizada y liderada por el
product owner, mientras que de la segunda parte se encarga el Development Team. La única labor del Scrum
Master es asegurarse de que la reunión existe como parte de Scrum y que se mantiente dentro de las
duraciones estimadas.

• El Sprint Planning puede durar hasta 8 horas para Sprints de 4 semanas. En la práctica esta ceremonia suele
llevar una mañana completa -alrededor de 5 horas- y, sólo si el producto o el Sprint definido por el Product
Owner son complejos o están poco claros, se llegan a alcanzar las 8 horas definidas en la metodología. La razón
del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en relación a las
prioridades.
Fuente: Deloitte
Daily Meeting
• El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una reunión diaria de 15 minutos en la que
participa exclusivamente el Development Team. En esta reunión todas y cada una de las personas del
Development Team responden a las siguientes preguntas:

• ¿Qué hice ayer para contribuir al Sprint Goal?


• ¿Qué voy a hacer hoy para contribuir al Sprint Goal?
• ¿Tengo algún impedimento que me impida entregar?

• Mucha gente confunde el Daily Scrum con el Standup Meeting, sin embargo, este último es una práctica de
eXtreme Programming (XP) orientada a controlar y gestionar el trabajo motivada por un manager, mientras que
el primer término, Daily Scrum, hace referencia a la práctica que permite la inspección y adaptación a través de
la auto-organización del equipo.
Fuente: Deloitte
Sprint Review
• El Sprint Review es la reunión que ocurre al final del Sprint, generalmente el último viernes del Sprint, donde el
product owner y el Develpment Team presentan a los stakeholders el incremento terminado para su inspección
y adaptación correspondientes. En esta reunión organizada por el product owner se estudia cuál es la situación
y se actualiza el Product Backlog con las nuevas condiciones que puedan afectar al negocio.

• El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software que ahora
mostrará a los stakeholders. No se trata de una demostración, sino de una reunión de trabajo. El software ya ha
sido mostrado y validado junto con el product owner previamente a esta reunión.

• Por un lado, se revisará el incremento terminado. Se mostrará el software funcionando en producción y los
stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El software
funcionando ha sido validado previamente por el product owner, que se ha encargado de trabajar con el equipo
durante el Sprint para asegurarse que cumple con la Definition of Done y, efectivamente, hace que el Sprint
Goal sea válido. Si no existe software funcionando, el Sprint Review carece de sentido, aunque en ciertas
ocasiones y oportunidades se sigue manteniendo.
Sprint Review
• El Development Team tiene que tener un papel importante en esta reunión. Muchas veces no es el product
owner quien demuestra el incremento producido, sino que son los propios miembros del Development Team
quienes lo hacen. Es una buena práctica no sólo el que lo lleven a cabo, sino también el que lo hagan de forma
rotatoria y, tras varios Sprints, hayan participado todos.

• El equipo de desarrollo comenta posteriormente qué ha ocurrido durante el Sprint, los impedimentos que se han
encontrado, así como soluciones tomadas y actualizan a los stakeholders con la situación del equipo. Por último,
el product owner actualiza -con la información de negocio recibida en esta reunión- el Product Backlog para el
siguiente Sprint.

• En contra de lo que comúnmente se cree, el Sprint Review 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. La
duración estimada en el estándar para un Sprint Review es de 8 horas para un Sprint de 4 semanas, aunque
habitualmente estas reuniones se ejecutan en un entorno de entre 2 y 3 horas.
Fuente: Deloitte
Sprint Retrospective
• 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, siendo la retrospectiva la parte inicial de la
reunión.

• El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el
próximo. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del
equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva.

• Un formato común es analizar qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar. Este
formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban notas –en post-its- para
luego agruparlas y votar aquellos ítems más relevantes, dando la oportunidad a todos de hablar y expresar sus
inquietudes.
Fuente: Deloitte
Sprint Retrospective
• Tambié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.

• La duración recomendada por Scrum para un Sprint de 4 semanas es de un máximo de 3 horas, aunque
habitualmente se destina entre 1 y 2 horas a este evento.
Fuente: Deloitte
Sprint Grooming o Refinement

• El refinamiento del Product Backlog es una práctica recomendada para asegurar que éste siempre esté
preparado. 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. Es responsabilidad del product owner agendar,
gestionar y dirigir esta reunión.

• Los participantes de esta reunión son todo el equipo Scrum, así como cualquier recurso adicional que considere
necesario el PO y que pueda contribuir a aclarar el requerimiento. Es necesario, por tanto, que antes de la
reunión todos conozcan los requerimientos o historias de usuario que van a ser tratados en la misma y sólo
asistan aquellos cuya presencia sea estrictamente relevante.
Fuente: Deloitte
Dinámica
• La técnica del barco de vela

• Esta es una técnica muy divertida para reflexionar sobre oportunidades, riesgos y problemas que ha habido en
el sprint.

• 1 – La dinámica empieza dibujando un barco en una pizarra, que va hacia la tierra prometida, otro elemento
que debemos dibujar. Esta tierra prometida es la visión de lo que el equipo quiere llegar a ser, la meta, qué es
lo que quieren llegar a conseguir a nivel de procesos, desarrollo, qa (como equipo).

• Es interesante que el equipo acuerde y refleje en la pizarra cuál es esa tierra prometida.

• 2 – La historia es que todo el equipo viaja en el barco hacia la tierra prometida. En la escena hay otras cosas
(que también hay que dibujar):

• – un sol: Las cosas que nos iluminan y alegran el camino.

• – un ancla (dibujada saliendo del barco hacia el suelo): las cosas que nos frenan.

• – rocas: los riesgos que nos encontramos en el camino.

• – viento: aquellas cosas buenas que nos empujan y acercan a la tierra prometida.

• 3 – La idea es que una vez hecho el dibujo y explicado que significa cada elemento, demos 5 min para que los
miembros del equipo individualmente escriban en post-its qué elementos de cada tipo han encontrado en este
sprint. Yo recomendaría que cada uno escribiera como mínimo 3 cosas de cada tipo, pero esto depende también
del número de personas que haya en la retrospectiva.
Fuente: Deloitte
Dinámica
• 4 – Después, por turnos, cada persona va colocando sus post-it alrededor de cada elemento (sol, ancla, etc.) y
explicando por qué ha decidido escribir eso en los post-it.

• Dejemos que el equipo haga las agrupaciones de post-it que sean oportunas si vemos que el equipo coincide en
algunos elementos de los post-it.

• 5 – Una vez que todas las opiniones estén reflejadas, toca ver por qué han pasado esas cosas y sacar planes de
mejora para el próximo sprint. Si hay muchas tareas, suele funcionar bastante bien dar por ejemplo 5 puntos a
distribuir en las tareas a cada persona y que cada uno vote qué temas son los más prioritarios para solucionar.
Los más prioritarios, acordados por debate, serán los temas que se solucionarán.

• 6 – Por último toca definir qué vamos a hacer para resolver los asuntos que hemos priorizado. Tenemos que
salir de la retrospectiva acordando qué vamos a hacer, cuándo va a estar hecho y quién/quiénes son los
responsables de hacerlo.
Bibliografía

Erwin Salas – Tesis: Desarrollo de un Sistema de Gestión y Plataforma Virtual para


Reserva y Pago para una Start Up Basado en Metodologías Ágiles

Recurso web: https://inakiglez.files.wordpress.com/2018/05/charla-scrum_v1-2.pdf

Recurso web: deloitte.com

Recurso web: https://www.javiergarzas.com/2015/10/dinamicas-retrospectivas-agiles.html

También podría gustarte