FULL STACK PYTHON

Clase especial
Scrum
Scrum
Introducción
La metodología en cascada es un tipo de
modelo que desglosa las actividades del
proyecto en secuencias lineales
sistemáticas; por lo tanto, también se
llama modelo de ciclo de vida
lineal-secuencial.

En esta metodología, las fases posteriores

se basan en los resultados de la anterior y
corresponden a la especialización de las
tareas. Los cambios en etapas tardías
cuestan más.
Introducción
La metodología ágil es un instrumento de
gestión de proyectos en el que el equipo
gestiona el proyecto dividiéndolo en varias
etapas.

Implica una colaboración constante con

los interesados y una mejora e iteración
ininterrumpida en cada etapa.
Principal problema de los modelos secuenciales

● Un entorno altamente cambiante.

● El contexto de negocio pasó de ser relativamente estable a
convertirse en un entorno altamente volátil.
● Las metodologías Waterfall resultaron muy “pesadas” y
prohibitivas.
El triángulo de hierro
La comunicación en un proyecto de software
Agilidad
Según la Agile Alliance: “La agilidad es la habilidad para responder al
cambio”.
Es una forma de lidiar y tener éxito en entornos inciertos y turbulentos.
La agilidad es una mentalidad, cuya máxima prioridad es satisfacer al
cliente. Se trata de trabajar más inteligente en lugar de esforzarse más.
Se trata de generar más valor con menos trabajo.
Manifiesto Ágil

Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como
ayudando a terceros.

Autor/as/es: Utah, 2001. 17 expertos en desarrollo de software.

Manifiesto Ágil | 4 valores
Manifiesto Ágil | 12 principios
Por qué los negocios deben ser ágiles

● Contextos cambiantes
● Reacción al cambio
● Adaptación al cambio
● Obtener resultados exitosos
● Mejorar continuamente
Scrum

Scrum es un marco ligero que ayuda a las personas, equipos y

organizaciones a generar valor a través de soluciones
adaptables para problemas complejos.

Autor/as/es: Ken Schwaber and Jeff Sutherland

Scrum
Scrum es un marco de trabajo de procesos ágiles que trabaja con el
ciclo de vida iterativo e incremental.
Se entrega y libera producto terminado de forma periódica.
Se aplican buenas prácticas de trabajo colaborativo y trabajo en
equipo, y se facilita el hallazgo de soluciones óptimas a los problemas
que pueden ir surgiendo en el proceso de desarrollo del proyecto.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al cliente.
Scrum | ¿Cuándo se utiliza?
Suele utilizarse en entornos donde se ● Cuando no se está entregando al
necesita obtener resultados pronto, cliente lo que busca.
donde los requisitos son cambiantes ● Cuando las entregas tardan
o poco definidos, donde la demasiado y los costos se
innovación, la competitividad, la disparan.
flexibilidad y la productividad son ● Cuando es necesario identificar y
fundamentales. solucionar ineficiencias
sistemáticamente.
● Cuando se busca obtener
resultados rápido.
Scrum en Entornos complejos

● Marco de trabajo flexible.

● Promueve prácticas emergentes en dominios complejos.
● No es un proceso completo, y mucho menos, una metodología.
● Promueve la innovación y el empoderamiento.
● Formado por un Equipo de desarrollo, Scrum Master, y Product
Owner.
● Ciclos cortos de duración fija: Sprints.
● Compromiso, Ejecución, Inspección.
Sobre Scrum
Qué no es Scrum Qué es Scrum

● Una metodología. ● Scrum es un framework ágil para

● Un proceso complejo. gestionar proyectos complejos.
● Un conjunto de mejores prácticas. ● Scrum fue formalizado originalmente
para proyectos de desarrollo de
software, pero funciona bien para
cualquier ámbito de trabajo complejo
e innovador.
● Las posibilidades son infinitas. El
marco de Scrum es aparentemente
simple.
Scrum | Pilares y Valores
Pilares:

● Transparencia
● Inspección
● Adaptación

Valores:

● Compromiso: dar valor al cliente por encima de

completar solo tareas.
● Respeto: hablar con todo el mundo sobre
criticar a todo el mundo.
● Apertura: levantar la bandera cuando estás
atascado por delante de seguir confundido.
● Foco: crear pequeñas partes de valor por
encima de grandes y faraónicas partes.
● Coraje: tener decisión por encima de pedir
permiso por cosas que podríamos estar
haciendo.
Proceso Scrum
Proceso Scrum
Roles
Un equipo Scrum se compone por 3 roles
fundamentales:

● el Product Owner,
● el Scrum Master y
● el Equipo de desarrollo.
Roles | Product Owner
El Product Owner o dueño del producto es el responsable de maximizar el valor del producto.

Es el responsable de gestionar el Product Backlog.

No es el jefe del equipo, sino el contacto entre el equipo que desarrolla el proyecto y el cliente
(interno, o sea, quién sabe lo que se necesita hacer). Su función es priorizar tareas y comunicarse con
los stakeholders (usuarios finales, usuarios clave (key users), tomadores de decisiones en general).

Gestiona todo lo relacionado con las partes interesadas en el producto.

Expresar claramente los requerimientos.

Ordenar los elementos de la lista de requerimientos para alcanzar los objetivos de la mejor manera
posible.

Asegurar que el equipo de desarrollo entiende los elementos de la lista de requerimientos.

Roles | Scrum Master
No es el jefe del proyecto, sino alguien que Características:
facilita el trabajo según las guías de scrum.
Su función es organizar reuniones para ● Líder que está al servicio del Equipo y
realizar revisiones semanales y evitar de la Organización.
conflictos. Destrabar impedimentos ● Responsable de promocionar y
(reuniones diarias y semanales). apoyar al Scrum, promoviendo su
teoría, prácticas reglas y valores.
Habilidades del SM: ● Colabora con las personas externas al
Scrum Team para que entiendan qué
● Coraje al momento de enfrentar interacciones pueden ser útiles y
momentos críticos. cuáles no.
● Habilidades de motivación. ● Maximiza el valor creado por el Scrum
● Capacidades de trabajo en equipo. Team.
● Resolución de conflictos. ● Responsable de la efectividad del
● Responsabilidad incondicional. Scrum Team.
● Ser un jugador de equipo. ● Facilita los eventos de Scrum.
Roles | Equipo de desarrollo
Es quien se encarga de crear el ● No hay jerarquías.
producto. No existe diferenciación ● No hay sub-equipos.
entre developers, designers, QA, etc. ● Autogestionados.
Es prioritaria la buena comunicación ● Ritmo sostenible.
dentro del equipo y buena reacción ● Responsable de todas las
al cambio. No basta con ser bueno, actividades relacionadas con el
sino ser adaptativo. producto.
● Hasta 10 personas.
● Si es más grande, dividir en
varios equipos Scrum.
Roles | Resumen

Dentro de los roles de Scrum, no existe un dueño de proyecto. El

equipo de desarrollo es autosuficiente y decide en conjunto qué tareas
realizar.
El Scrum Master se asegura de que se lleve el proceso Scrum
correctamente y de facilitar la ejecución eliminando impedimentos.
El Equipo de Desarrollo se encarga de crear un incremento terminado
a partir de los Sprint Backlog Items que son los ítems seleccionados
durante el Sprint Planning.
El aspecto más importante del equipo de desarrollo es que se
autoorganiza y se autogestiona.
Eventos

5 eventos de Scrum:
● Sprint
● Sprint Planning
● Daily Scrum
● Sprint Review
● Sprint Retrospective
Timebox:
● Se alcanza la duración máxima.
● Se cumple el objetivo.
Eventos | Sprint
Objetivo: Desarrollar un incremento de
producto.

Duración: Tienen una duración de entre 1 y

4 semanas. Deben tener una duración
constante durante el desarrollo de un
producto.

Características:

● Las metas de calidad no se reducen

durante el desarrollo del Sprint.
● El alcance puede ser aclarado y
re-negociado.
● Engloba el resto de eventos de Scrum.
Eventos | Sprint Planning
Objetivo: Acordar el compromiso del incremento que
se va a desarrollar. Definir un Sprint Goal.

Duración: Máximo 8 horas para Sprints de 4 semanas.

Características:

Debe responder dos preguntas:

1. ¿Qué podemos entregar al final de este Sprint?

2. ¿Cómo se logrará el trabajo necesario para
entregar el incremento?

Sprint Goal:

● Es el objetivo de negocio marcado para el Sprint.

● Se alcanza implementando los PBI del Sprint
Backlog.
● Ayuda al equipo a trabajar de manera alineada.
Eventos | Daily Scrum
Objetivo: Inspeccionar el progreso hacia el Sprint
Goal. Mantener al equipo alineado con el Sprint Goal.

Duración: Máximo 15 minutos.

Características:

● Debe realizarse a la misma hora en el mismo

sitio durante todo el Sprint
● Si hay impedimentos sin resolver se acuerda
cómo se van a afrontar
● Los participantes deben responder a tres
cuestiones:
○ ¿Qué hice ayer que ayudó al equipo a acercarse
al Sprint Goal?
○ ¿Qué voy a hacer hoy para ayudar al equipo a
acercarse al Sprint Goal?
○ ¿Veo algún impedimento que nos complique o
impida al equipo completar el Sprint Goal?
Eventos | Sprint Review
Objetivo: Inspeccionar el incremento de
producto creado y reajustar el Product
Backlog si es necesario

Duración: Un máximo de 4 horas para un

Sprint de 4 semanas

Características:

● Los miembros del Development Team

comentan las dificultades encontradas
durante el Sprint
● También muestran las nuevas
funcionalidades a los Stakeholders
● Se inspecciona el incremento, la decisión
de liberarlo es del Product Owner.
Eventos | Sprint Retrospective
Objetivo: Inspeccionar el último Sprint.
Identificar elementos positivos y con
espacio de mejora. Crear un plan de acción
para mejorar definiendo: Acciones, Fechas
y Responsable).

Duración: Un máximo de 3 horas para un

Sprint de 4 semanas.

Características:

En este evento el Scrum Master participa

activamente como miembro del equipo
encargado del proceso de trabajo.
Eventos | Resumen
● Sprint: es un evento que contiene a todos los demás eventos en Scrum y tiene una duración de
30 días o menos (2 semanas promedio).
● Sprint Planning: reunión que se realiza al comienzo de cada Sprint donde participa el equipo
Scrum completo y sirve para inspeccionar el Product Backlog y que el equipo de desarrollo
seleccione los Product Backlog Items (PBI) en los que va a trabajar.
● Daily Scrum: reunión diaria de planificación de 15 minutos en la que participa el equipo de
desarrollo exclusivamente y dónde se responden las siguientes preguntas: ¿Qué hiciste ayer?
¿Qué vas a hacer hoy? y ¿Qué impedimentos tuviste?
● Sprint Review: marca la finalización de un Sprint, en este evento se revisa el incremento
terminado, y se muestra el software funcionando, el equipo de desarrollo comenta qué ha
ocurrido durante el Sprint, los problemas que se han encontrado, así como soluciones las
tomadas, y la situación del equipo. En este evento se involucra a todo el equipo.
● Retrospectiva del Sprint: ocurre al final del Sprint, justo después del Sprint Review y su
objetivo es reflexionar sobre el último Sprint e identificar posibles mejoras para el próximo. Aquí
se analiza qué ha ido bien durante el Sprint, qué ha fallado y qué se puede mejorar.
Artefactos

Existen 3 artefactos que se refieren a elementos físicos que se

producen como resultado de la aplicación de Scrum: el Product
Backlog, el Sprint Backlog y el Incremento de Producto.
Artefactos | Product Backlog
● Los requerimientos, casos de
uso, dependencias.
● Lista ordenada de lo que se
necesita
● Única fuente de requisitos
Artefactos | Sprint Backlog
Son los requerimientos que se desarrollarán en el
sprint actual. Lista de tareas que el equipo se
compromete a terminar en un Sprint.

Está gestionado por el equipo de desarrollo, quien

lo mantiene actualizado y transparente durante el
transcurso de cada sprint, en las dailies.

Permite analizar hasta dónde se ha cumplido el

objetivo en cada Sprint y qué se podría eliminar.

Se compone de:

● Sprint Goal (el por qué del sprint).

● Los Product Backlog Items (PBI)
seleccionados para el Sprint (el qué).
● Plan de Acción para entregar el Incremento
(el cómo).
Artefactos | Incremento
Es la suma de todas las tareas, casos de uso, y
cualquier elemento que se haya desarrollado
durante el Sprint y que será puesto a
disposición del usuario final en forma de
software al final del mismo y de esta forma se
construye software de manera iterativa e
incremental. Resultado del Sprint, qué será
entregado al usuario final en forma de
software, aportando valor al negocio.

● El incremento se presenta en la Sprint

Review.
● Debe estar en condiciones de utilizarse
independientemente de que el Product
Owner decida liberarlo o no.
● Es inspeccionable.
Scrum Burn Down
El Scrum Burn Down es responsabilidad
del Scrum Master.

Eje X: Trabajo restante, horas, puntos de

historia u otra unidad de medida.

Eje Y: Día o fecha del sprint.

Herramientas de transparencia para Artefactos
Definition of Ready (DoR) Definition of Done (DoD)

● Es un acuerdo co-creado por un ● Es un acuerdo co-creado por un equipo,

equipo, que se aplica a todos los que se aplica a todos los ítems sobre los
ítems sobre los cuales trabaja este cuales trabaja este equipo.
equipo. ● Refleja el entendimiento compartido por
el PO y los Developers de cuándo algo
● No figura en la Guía Scrum, pero es
está terminado
muy utilizado. ● El objetivo es establecer una serie de
● Es un checklist que refleja el criterios comunes para especificar
entendimiento compartido del cuándo un ítem está completamente
Product Owner y los Developers en terminado y que aplique a todos los
forma de criterios que cada Product ítems que forman parte del incremento.
Backlog Item (PBI) debe cumplir para ● El DoD permite establecer un criterio de
que se pueda comenzar a trabajar en calidad y tener siempre un producto
él. “potencialmente entregable”.
Scrum es un marco ágil de
trabajo que nos permite
construir soluciones para
problemas complejos gracias al
trabajo incremental en Sprints.
Conclusión
Al adoptar Scrum, se genera un contexto de trabajo iterativo, de
inspección de lo construido y adaptación constante en base al
aprendizaje de cada Sprint.
Esto sucede porque en los contextos complejos no existen ni mejores ni
buenas prácticas a priori. Es el Equipo Scrum, integrado por el Scrum
Master, el Product Owner y los Developers, quien encuentra la mejor
solución para cada problemática gracias a su capacidad de aprendizaje
y autogestión.
Material extra
Material complementario
Videos:

● Qué es Scrum: https://youtu.be/sLexw-z13Fo

● Trello. Tutorial breve de cómo utilizarlo: https://youtu.be/3m063IyO7KU

Herramientas de gestión:

● Trello: https://trello.com/
● Miro: https://miro.com/

Material de lectura:
● Manifiesto Ágil: https://agilemanifesto.org/
● Scrum.org: https://www.scrum.org/
Tarea para el Proyecto:

● Definir un Scrum Master para el TPO. No necesariamente es quien

mejor programa ya que su rol no se relaciona con sus habilidades
técnicas sino con las habilidades blandas.
● Realizar reuniones de Scrum cada 1 o 2 días (Daily Scrum). Las
reuniones se organizan según 3 preguntas: 1) ¿Qué hiciste ayer?, 2)
¿Qué harás hoy?, 3) ¿Hay/Hubo impedimentos en tu camino?
● Realizar sprints con una duración de 1 semana, no más.
● Tener un Backlog actualizado a diario. El link al Backlog (y al
Incremento) tiene que ser conocido por todo el Equipo.
Recordá:
● Revisar la Cartelera de Novedades.
● Hacer tus consultas en el Foro.

Todo en el Aula Virtual.

Muchas gracias por tu atención.
Nos vemos pronto