BS GRUPO

GRUPO 2

METODOLOGÍA SCRUM

CURSO : GESTION DE PROYECTOS

ALUMNO : FRANCISCO EZEQUIEL REID MELO

PEDRO MIGUEL ZAVALA VINCES
MIGUEL ANGEL TORIBIO HUARINGA
LUIS ANGEL CUMPA PEÑA

DOCENTE : ING. DAVID CHIGNE, PMP

Lima, Septiembre del 2018

 Metodología Scrum
¿Qué es?

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se
basa en construir primero la funcionalidad de mayor valor para el cliente y en los
principios de inspección continua, adaptación, auto-gestión e innovación.

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se
disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante
la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es
necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto.

Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.

¿Cuándo se utiliza?

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto

dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento
realinear el software con los objetivos de negocio de su empresa, ya que puede
introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin
ningún problema.
 Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo
que forma parte del proyecto, por lo que los profesionales encuentran un ámbito
propicio para desarrollar sus capacidades.

El proceso
En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración
fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son
de 3 y hasta 4 semanas, límite máximo de feedback de producto real y reflexión). Cada
iteración tiene que proporcionar un resultado completo, un incremento de producto final
que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa

como plan del proyecto. En esta lista el cliente (Product Owner) prioriza los objetivos
balanceando el valor que le aportan respecto a su coste (que el equipo estima
considerando la Definición de Hecho) y quedan repartidos en iteraciones y entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene
dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de

requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas
que surgen y selecciona los requisitos más prioritarios que se compromete a completar
en la iteración, de manera que puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de
la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La
estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se
autoasignan las tareas.
 Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos máximo),
normalmente delante de un tablero físico o pizarra (Scrum Taskboard). Cada miembro
del equipo inspecciona el trabajo que el resto está realizando (dependencias entre
tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este
objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el
compromiso adquirido. En la reunión cada miembro del equipo responde a tres
preguntas:

 ¿Qué he hecho desde la última reunión de sincronización?

 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda

cumplir con su compromiso y de que no se merme su productividad.

 Elimina los obstáculos que el equipo no puede resolver por sí mismo.

 Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican
los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno.

Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos
partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto preparado para ser
entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los
cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar
y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando
de manera continua su productividad. El Facilitador se encargará de ir eliminando los
obstáculos identificados.

Ver en detalle las diferentes actividades, responsabilidades y herramientas en cómo

funciona Scrum.

Fases de la metodología Scrum

El desarrollo de producto tiene un ciclo de vida en la metodología Scrum. Estas son
fases en las que se divide un proceso Scrum:

 ¿Qué y quién? El producto que queremos conseguir una vez terminemos el

Sprint, y los roles de equipo con sus tareas asignadas.
 ¿Dónde y cuándo? El plazo y el contenido del Sprint.
  ¿Por qué y cómo? Las distintas herramientas para aplicar esta metodología ágil.
Cada Sprint puede tener una serie de eventos o etapas. Los más comunes son:
1. Reunión para la planificación del Sprint. En ella, se divide el tiempo de duración
del Sprint, así como el objetivo y entregable del mismo. Además, el equipo de
desarrollo deberá saber cómo realizarlo. Muy parecido a lo que llamamos
reunión de Kick off y que puedes descubrir en este curso gratis y online de
gestión de proyectos.
2. Scrum diario. Se basa en poner en común y sincronizar actividades para
elaborar el plan del día.
3. Trabajo de desarrollo durante el Sprint. Nos aseguramos que los objetivos se
están cumpliendo, que no se producen cambios que alteran el objetivo del Sprint
y se mantiene un feedback constante con el cliente o dueño del proyecto.
4. Revisión del Sprint. Reunión con el cliente o dueño del proyecto, en la que se
estudia y revisa el Product Backlog del Sprint. Se definen los aspectos a
cambiar, en caso necesario, de mayor valor o probables para planificarlo en el
siguiente Sprint.
5. Retrospectiva del proyecto. Oportunidad del equipo de desarrollo para mejorar
su proceso de trabajo y aplicar los cambios en los siguientes Sprints.

Perfiles de la metodología Scrum

Como decíamos, este método no sería posible sin el concepto de “equipo de
trabajo”.

Por una parte, tenemos al Product Owner representa la voz del cliente y del resto de
interesados no implicados directamente en el proyecto. Este perfil es el encargado de
definir los objetivos del proyecto y de garantizar que el equipo trabaja del modo
adecuado para alcanzar dichos objetivos.
No está solo. El Scrum Master es el encargado de asegurar que el resto del equipo
no tiene problemas para abordar sus funciones y tareas. Guía y ayuda al Scrum Team
para garantizar el cumplimiento de objetivos. En otras palabras, este perfil ayuda al
equipo a mantenerse activo y productivo.
El Scrum Team es el equipo encargado de desarrollar y entregar el producto. Su
trabajo es imprescindible: estamos hablando de una estructura horizontal auto-
organizada capaz de auto-gestionarse a sí misma.
Y, finalmente, tenemos que hablar de los Stakeholders. Este grupo comprende
aquellos perfiles interesados en el producto: directores, dueños, comerciales. Se trata
de perfiles que si bien no forman parte del Scrum Team deben ser tenidos en cuenta.
Roles de Scrum
La metodología Scrum tiene unos roles y responsabilidades principales, asignados a
sus procesos de desarrollo. Estos son:
 Project Owner. Se asegura de que el proyecto se esté desarrollando acorde con
la estrategia del negocio. Escribe historias de usuario, las prioriza, y las coloca
en el Product Backlog.
 Master Scrum o Facilitador. Elimina los obstáculos que impiden que el equipo
cumpla con su objetivo.
 Development team Member. Los encargados de crear el producto para que
pueda estar listo con los requerimientos necesarios. Se recomienda que sea un
equipo multidisciplinar, de no más de 10 personas. Sin embargo, empresas
como Google disponen de unos 15.000 desarrolladores trabajando en una rama
del código. Y con una metodología Scrum. La automatización en el testeo explica
sobre por qué este gran volumen en el equipo.
 Funcionamiento de la metodología Scrum
El proceso comienza con la elaboración del llamado Product Backlog. Se trata de
un archivo genérico que recoge el conjunto de tareas, los requerimientos y las
funcionalidades requeridas por el proyecto. Cualquier miembro del equipo puede
modificar este documento pero el único con autoridad para agregar prioridades es el
Product Owner, responsable del documento.
La segunda etapa pasa por la definición del Sprint Backlog, documento que recoge
las tareas a realizar y quién las desempeña. Es interesante asignar las horas de
trabajo que va a suponer realizar cada una de ellas y asignarlas un coste. Si su
volumen es muy grande, crear metas intermedias será un acierto.
El Sprint es el periodo en el que se realizan todas las acciones pactadas en el Sprint
Backlog y supone entregas parciales para ir testeando el producto final.
El ciclo anterior deberá repetirse hasta que todos los elementos del Blacklog hayan
sido entregados. Entre los distintos Sprints no se deben dejar tiempos sin
productividad.

Todas las acciones que realicemos han de tener un control. Es en el Burn Down
donde marcamos el estado y la evolución del mismo indicando las tareas y
requerimientos pendientes de ser tratados.

Beneficios

 Cumplimento de expectativas: El cliente establece sus expectativas indicando el

valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con
esta información el Product Owner establece su prioridad. De manera regular, en las
demos de Sprint el Product Owner comprueba que efectivamente los requisitos se
han cumplido y transmite se feedback al equipo.
 Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del mercado. La
metodología está diseñada para adaptarse a los cambios de requerimientos que
conllevan los proyectos complejos.
 Reducción del Time to Market: El cliente puede empezar a utilizar las
funcionalidades más importantes del proyecto antes de que esté finalizado por
completo.
 Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una
versión funcional después de cada iteración, ayuda a la obtención de un software de
calidad superior.
 Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean
autónomos para organizarse.
 Maximiza el retorno de la inversión (ROI): Producción de software únicamente con
las prestaciones que aportan mayor valor de negocio gracias a la priorización por
retorno de inversión.
 Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media
del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una determinada
funcionalidad que todavía está en el Backlog.
 Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en
primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto,
permite despejar riesgos eficazmente de manera anticipada.
Ventajas y desventajas de la Metodología Scrum

Ventajas
 Scrum es muy fácil de aprender, los roles, eventos y artefactos son claros y
tienen un objetivo muy relacionado a nuestra manera diaria de trabajar.
 El cliente puede comenzar a usar su producto rápidamente.
 Se agiliza el proceso, ya que la entrega de valor es muy frecuente.
 Menor probabilidad de sorpresas o imprevistos, porque el cliente está
viendo frecuentemente el proyecto.

Desventajas
 Aunque Scrum sea fácil de aprender, es muy difícil poder implementarlo.
Esto supone una predisposición y un cambio de cultura de la organización
que debe ir desde los altos mandos hasta los clientes.
 La necesidad de tener equipos multi-disciplinares puede ser un problema,
ya que es difícil encontrar personas que sean capaces de hacer todo el
trabajo de un equipo.
 El equipo puede tender a realizar el camino más corto para conseguir el
objetivo de un Sprint, el cual no siempre es el de mayor calidad.
Ejemplo: Éxito de Spotify.
 Contrato externo de un especialista en metodologías ágiles. Gran importancia al
rol del Scrum Master.
 Fundamental el trabajo del Product Owner, para saber entender las necesidades
reales del cliente y trasladarlas a tiempo al equipo.
 Buena coordinación central de la compañía.
 Rápidos, baratos y mejores frente a sus competidores Google y Apple.
 Los pequeños equipos Scrum son hábiles para implementar el software al final
de cada sprint, sin romper a otros equipos.
 Cada equipo tiene una parte del software exclusivo suyo. Entre todos forman
tribus o Tribe, añadiendo distintos Squad o escuadrones.
Aquí un ejemplo gráfico de cómo funciona Scrum en Spotify.

Pasos para implementar la metodología Scrum

1. Elige un responsable de producto.

Esta persona es la que tiene la visión clara de lo que se necesita, se va a hacer,
fabricar o conseguir. tendrá en cuenta riesgos y compensaciones, qué es posible y qué
es factible.

2. Elige un equipo.

¿Quién va a hacer el trabajo real? Este equipo necesita tener las habilidades
necesarias para convertir en realidad la visión del responsable de producto. Los
equipos tienen que ser pequeños: entre 3 y 9 personas es lo normal.

3. Elige un Scrum Master.

Es la persona que conducirá a todos los demás por el sistema de trabajo Scrum
ayudando al equipo a eliminar todo aquello que les frene. Quitar desperdicios.

4. Elabora y prioriza una lista de objetivos o backlog.

El Backlog no es más que una lista de todo lo que debe hacerse para convertir la
visión en realidad. Esta lista existe y evoluciona a lo largo del proceso, es el mapa o la
hoja de ruta del producto.

En cualquier momento del proyecto, la lista de objetivos pendientes es la única y

definitiva vista panorámica «de todo lo que el equipo podría hacer, por orden de
prioridades». Existe una sola lista de objetivos pendientes. Esto quiere decir que el
responsable de producto tiene que tomar decisiones sobre las prioridades del proceso.

Debería consultar con todos los interesados y con el equipo para asegurarse de que
representan tanto lo que quiere el cliente como lo que es factible construir.

5. Haz una estimación afinada de la lista de objetivos pendientes.

Es crucial que las personas que realmente van a llevar a cabo los ítems enumerados
en la lista, calculen el esfuerzo que les llevará cada uno. El equipo deberá ir ítem por
ítem para decidir si realmente es factible hacerlo.

¿Hay información suficiente para llevar a cabo cada uno? ¿Es lo suficientemente
pequeño para poder calcular? ¿Hay una definición de “hecho”? ¿Todo el mundo está
de acuerdo en los requisitos que hay que cumplir para considerar que una cosa está
“hecha”? ¿Ofrece un valor visible?

Cada ítem tiene que poder presentarse, tiene que estar listo para, idealmente, poder
ser puesto en marcha. No hagas estimaciones de la lista de objetivos pendientes
en horas, porque a las personas se nos da fatal calcular el tiempo. Haz estimaciones
sobre el tamaño: pequeño, mediano o grande. O incluso mejor: utiliza la sucesión
de Fibonacci y calcule el punto de valor de cada una de las entradas de la lista: 1, 2, 3,
5, 8,13, 21, etc. Lo que se conoce como el Póker de Planificación.
6. Planificación de sprints.

Ésta es la primera reunión Scrum. El equipo, el Scrum Master y el responsable de

producto se sientan a planificar el sprint.

Los sprints siempre duran una cantidad determinada de tiempo, que es menos de un
mes. Habitualmente, casi todo el mundo hace sprints de una o dos semanas. El equipo
mira el principio de la lista de objetivos pendientes y hace una previsión de cuánto
pueden tener terminado en este sprint. Si el equipo ya ha hecho algún sprint, deberían
tener en cuenta los puntos que hicieron en el último. Ese número se conoce como la
velocidad del equipo. El Scrum Master y el equipo deberían estar siempre intentando
aumentar esa cifra en cada sprint. También es el momento para que el equipo y el
responsable de producto se aseguren de que todo el mundo entiende exactamente
cómo estos ítems van a lograr crear la visión. Además, en esta reunión todos deben
ponerse de acuerdo en la meta, lo que todos quieren lograr en ese sprint.

Uno de los pilares del Scrum es que una vez que el equipo se ha comprometido con lo
que creen que pueden terminar en un sprint, no hay vuelta atrás. No se puede cambiar
y no se le puede añadir nada. El equipo tiene que ser capaz de trabajar de forma
autónoma durante todo el sprint, para terminar lo que previeron que podían hacer.

7. Haz que el trabajo sea visible.

La forma más habitual de hacer esto es con una pizarra de Scrum y sus tres
columnas: Pendiente, En proceso, Hecho. Los post-it representan los ítems que hay
que completar y el equipo los cambia de sitio en la pizarra, a medida que se van
terminando, uno por uno.
Otra forma de hacer que el trabajo sea visible es crear un diagrama burn down o de
trabajo pendiente. En uno de los ejes está el número de puntos que el equipo ha
llevado al sprint y en el otro el número de días. Cada día el Scrum Master registra el
número de puntos que se han completado y los anota en el diagrama de trabajo
pendiente. Lo ideal sería que hubiera una curva descendente que llegara a cero
puntos en el último día del sprint.

8 Scrum Diario. Reunión Diaria de pie.

Éste es el pulso vital del Scrum. Cada día a la misma hora, durante no más de
quince minutos, el equipo y el Scrum Master se ven y responden a tres preguntas:

¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?

¿Qué vas a hacer mañana para ayudar al equipo a terminar el sprint?

¿Qué obstáculos se interponen en tu camino o el del equipo?

Ya está. En eso consiste la reunión. Si dura más de quince minutos usted está
haciendo algo mal. Esto ayuda al equipo a saber exactamente en qué punto está cada
ítem del sprint.

¿Se van a terminar todas las tareas a tiempo? ¿Existe la posibilidad de ayudar a otros
miembros del equipo a superar obstáculos? Las tareas no se asignan desde arriba, el
equipo es autónomo; son ellos los que deciden. No hay que despachar detalladamente
con los directivos. El Scrum Master es el responsable de eliminar los obstáculos que
impiden que el equipo avance.

9 Revisión o demostración del sprint.

Ésta es la reunión en la que el equipo muestra lo que ha construido durante el sprint.

Puede estar presente cualquiera, no sólo el responsable de producto, el Scrum Master
y el equipo, sino los directivos de la empresa, los jefes, los clientes, todo el que quiera.
Es una reunión abierta en la que el equipo explica lo que han podido pasar a la
columna de «hecho» durante el sprint.

El equipo debería mostrar únicamente lo que se ajuste perfectamente a la

definición de «hecho». Aquello que esté completamente terminado y que se puede
entregar porque no necesita más trabajo. Puede no ser un producto terminado, pero
debería ser una característica del mismo, que está lista para empezar a funcionar.

10 Retrospectiva del sprint.

Después de que un equipo haya mostrado lo que ha conseguido durante el último

sprint se sientan a reflexionar sobre lo que ha ido bien, lo que podría hacerse mejor y
lo que se podría perfeccionar en el siguiente sprint. ¿Qué mejora puede incorporar el
equipo al proceso de forma inmediata?

No estamos buscando a quién echarle la culpa; estamos analizando el proceso. ¿Por

qué eso fue así? ¿Por qué se nos escapó aquello? ¿Qué podría hacernos ser más
rápidos? Es crucial que la gente asuma la responsabilidad de su proceso y resultados
y trate de encontrar soluciones como equipo. A su vez, las personas tienen que tener
la valentía de plantear los problemas con los que realmente se están encontrando de
una forma constructiva. Para solucionar y no a acusar. El resto del equipo debe tener
la madurez de escuchar esa opinión, tenerla en cuenta y buscar una solución, en lugar
de ponerse a la defensiva.

Al final de la reunión, el equipo y el Scrum Master deberían haberse puesto de

acuerdo en una mejora del proceso que incorporarán en el siguiente sprint. Ese
proceso de mejora, que se conoce también como kaizen, debería incluirse en la lista
de objetivos pendientes del siguiente sprint, con tests de aceptación. Así, será fácil
para el equipo ver si realmente han implementado la mejora y qué efecto ha tenido en
la velocidad.

11 Empieza inmediatamente el siguiente ciclo de sprints.

Teniendo en cuenta la experiencia anterior del equipo con obstáculos y la

incorporación de mejoras.