UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FÍSICAS Y MATEMATICAS

ESCUELA ACADÉMICO PROFESIONAL DE INFORMÁTICA

“METODOLOGÍA ÁGIL SCRUM”

Autores:
 Montañez Julcamoro, Marisol
 Ocas Saldaña, Jhoan
 Quispe Ramirez, Angy
 Suarez Principe, Jose

Curso:
Sistemas Orientados a Objetos

Profesor:
Castillo Diestra Carlos Enrique

2018
Trujillo – Perú
 INDICE

INTRODUCCIÓN

CAPITULO 1

METODOLOGÍAS AGILES DE DESARROLLO DE SOFTWARE

1.1. Manifiesto Ágil

1.2. Metodologías Tradicionales vs Metodologías Ágile

CAPITULO 2

METODOLOGÍA ÁGIL DE DESARROLLO SCRUM

2.1. ¿Qué es Scrum?

2.2. Características de Scrum

2.3. Herramientas Scrum

2.3.1. Backlog de Producto

2.3.2. Historias de Usuario

2.3.3. Backlog del sprint

2.3.4. Panel de Tareas

2.4. Eventos de Scrum

2.4.1. Sprint

2.4.2. Planificación del Sprint o Sprint Planning

 2.4.3. Reunión diaria de Scrum o Daily scrum

2.4.4. Revision del Sprint o Sprint Review

2.4.5. Retrospectiva del Sprint

2.5. Roles

2.5.1. Scrum Master

2.5.2. Product Owner

2.5.3. Equipo de desarrollo

2.6. Ventajas de Scrum

2.7. Limitaciones de Scrum

CONCLUSIONES

BIBLIOGRAFÍA
 INDICE DE FIGURAS

Figura 1: Historia de Usuario ........................................................................................... 2

Figura 2: Tablero de tareas ............................................................................................... 2

Figura 3: Eventos de Scrum ............................................................................................. 2

 INTRODUCCIÓN

En la actualidad la industria del software va evolucionando rápidamente y se han venido

desarrollando diferentes metodologías que aseguran el buen desarrollo durante todo el

proceso de creación de un nuevo software.

En la comunidad de Ingeniería de software hay un gran debate entre aquellos que apoyan

a las metodologías tradicionales y aquellos que apoyan a las ideas relacionadas al

manifiesto ágil. Para muchos equipos de desarrollo el uso de metodologías tradicionales

les resulta muy lejano a su forma de trabajo actual considerando las dificultades de

su introducción e inversión asociada en formación y herramientas. Por otro,

las características de los proyectos para los cuales las metodologías ágiles han

sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales

de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeños,

con plazos reducidos, requisitos que van cambiando, y/o basados en nuevas tecnologías.

La metodología Scrum pertenece a la familia de metodologías ágiles, la cual hoy en día

es una de las metodologías más implementada por los equipos de desarrollo de

software muy simple, que requiere trabajo duro porque no se basa en el seguimiento de

un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

 CAPITULO 1

METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE

En la década de los noventa surgieron metodologías de desarrollo de software ligeras,

más adelante nombradas como metodologías ágiles, que buscaban reducir la probabilidad

de fracaso por subestimación de costos, tiempos y funcionalidades en los proyectos de

desarrollo de software.

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, donde se acuñó el término

“Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a

las metodologías formales. En esta reunión participan un grupo de 17 expertos de la

industria del software, convocados por Kent Beck. Su objetivo fue esbozar los valores

y principios que deberían permitir a los equipos desarrollar software rápidamente y

respondiendo a los cambios que puedan surgir a lo largo del proyecto, su fin era optimizar

el proceso de desarrollo de software, el cual era caracterizado por ser rígido y con mucha

documentación. Los integrantes de la reunión resumieron en cuatro postulados lo que ha

quedado denominado como “Manifiesto Ágil”, que son los valores sobre los que se

asientan estos métodos.

1.1. Manifiesto Ágil

Este es un documento que engloba principios y valores que hacen diferente un proyecto

de desarrollo de software ágil de uno en su forma tradicional.

1. Valores del Manifiesto Ágil

Según el manifiesto ágil se valora a:

 Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito de un

proyecto software. Es más importante construir un buen equipo que construir el

entorno. Muchas veces se comete el error de construir primero el entorno y

esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que

éste configure su propio entorno de desarrollo en base a sus necesidades.

 Desarrollar software que funcione más que la documentación de

este. La regla por seguir es “no producir documentos a menos que sean necesarios

de forma inmediata para tomar una decisión importante”. Estos documentos

deben ser cortos y centrarse en lo fundamental.

 La colaboración con el cliente más que la negociación de su

contrato. Se propone que exista una interacción constante entre el cliente y el

equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha

del proyecto y asegure su éxito.

 Responde a los cambios más que seguir con el plan establecido. La

habilidad de responder a los cambios que puedan surgir al largo del proyecto

(cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también

el éxito o fracaso de este. Por lo tanto, la planificación no debe ser estricta sino

flexible y abierta. (López Menéndez de Jiménez, 2015)

2. Principios del Manifiesto Ágil

Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los

principios que de ellos se derivan:

 Nuestra principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua de software con valor.

 Aceptamos que los requisitos cambien, incluso en etapas tardías del

desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar

ventaja competitiva al cliente.

 Entregamos software funcional frecuentemente, entre dos semanas y dos

meses, con preferencia al período de tiempo más corto posible.

 Los responsables del negocio y los desarrolladores trabajamos juntos de

forma cotidiana durante todo el proyecto.

 Los proyectos se desarrollan en torno a individuos motivados. Hay que

darles el entorno y el apoyo que necesitan, y confiarles la ejecución del

trabajo.

 El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.

 El software que funciona es la medida principal de progreso.

 Los procesos ágiles promueven el desarrollo sostenido. Los promotores,

desarrolladores y usuarios debemos mantener un ritmo constante de forma

indefinida.

 La atención continua a la excelencia técnica y al buen diseño mejora la

agilidad.

 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado,

es esencial.

 Las mejores arquitecturas, requisitos y diseños emergen de

equipos autoorganizados.

 A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo

para, a continuación, ajustar y perfeccionar su comportamiento en

consecuencia.
2. Metodologías Tradicionales vs Metodologías Ágiles

Las metodologías tradicionales de desarrollo de software son orientadas por planeación.

Inician el desarrollo de un proyecto con un riguroso proceso de obtención de

requerimientos, previo a etapas de análisis y diseño. Con esto tratan de asegurar resultados

con alta calidad circunscritos a un calendario. En las metodologías tradicionales se

concibe un solo proyecto, de grandes dimensiones y estructura definida; se sigue un

proceso secuencial en una sola dirección y sin marcha atrás; el proceso es rígido y no

cambia; los requerimientos son acordados de una vez y para todo el proyecto,

demandando grandes plazos de planeación previa y poca comunicación con el cliente una

vez ha terminado ésta.

Las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la

realidad de cada equipo y proyecto. Los proyectos ágiles se subdividen en proyectos más

pequeños mediante una lista ordenada de características. Cada proyecto es tratado de

manera independiente y desarrolla un subconjunto de características durante un periodo

de tiempo corto, de entre dos y seis semanas. La comunicación con el cliente es constante

al punto de requerir un representante de él durante el desarrollo. Los proyectos son

altamente colaborativos y se adaptan mejor a los cambios; de hecho, el cambio en los

requerimientos es una característica esperada y deseada, al igual que las entregas

constantes al cliente y la retroalimentación por parte de él.

 CAPITULO 2

METODOLOGÍAS ÁGIL DE DESARROLLO SCRUM

2.1. ¿Qué es Scrum?

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.

2.2. Características de Scrum

  Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos,

prácticas de desarrollo, implementación y demás cuestiones técnicas

 Hace uso de Equipos autodirigidos y autoorganizados

 Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente

necesita trabajar junta para lograr una meta común.

 Desarrollo de software iterativos incrementales basados en prácticas agiles

 Iteraciones de treinta días; aunque se pueden realizar con mas frecuencia, estas

iteraciones, conocidas como Sprint

 Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien

llevará a cabo la gestión de la iteración

 e convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión

de avance diaria de no más de 15 minutos con el propósito de tener realimentación

sobre las tareas de los recursos y los obstáculos que se presentan. En la cual se

responden preguntas como: ¿Qué has hecho desde el último encuentro? ¿Qué

obstáculos hay para cumplir la meta? ¿Qué harás antes del próximo encuentro?

2.3. Herramientas de Scrum

2.3.1. Backlog de Producto

Cuando trabajamos con Scrum, lo primero que debemos hacer es crear el “Product

Backlog” o Backlog de Producto en castellano. Este no es más que la lista de

características que hemos pensado para el proyecto. Es lo mismo que si estuviéramos

hablando de la definición del alcance.

Recuerda que Scrum no es predictivo, por lo que no planea por adelantado; en lugar

de crear un completo y detallado Backlog del Producto, simplemente añadimos los

suficientes elementos para los próximos ciclos (también conocidos como iteraciones o

Sprints). A continuación, empezamos inmediatamente con el primer ciclo y

mantendremos el Backlog del Producto continuamente actualizado (“adaptativa”).

Esto significa que iremos añadiendo elementos conforme surjan.

El Backlog de Producto debe estar compuesto únicamente por funciones; cosas que el

cliente pueda entender, y cuando se han desarrollado, pueda probar y darnos su

opinión. Es por eso que los elementos del Backlog de Producto deben tener dos

características:

 Deben ser no técnicos, porque los usamos para comunicarse con el cliente y la

comprensión mutua es la clave de nuestro. Normalmente el cliente no es o tiene

un carácter técnico. Así pues, no utilizamos una documentación sofisticada para

hablar con el cliente sobre la definición del producto; necesitamos que se sienta

cómodo y colabore.

 Deben ser independientes entre sí, porque queremos ser capaces de ordenarlo

libremente en función de su valor de negocio (importancia) y centrarnos primero

en los elementos más importantes.

Una muy buena opción para redactar los elementos del Backlog de Producto es

utilizar “historias de usuario”

2.3.2. Historias de Usuario

Una buena manera de redactar elementos del Backlog de Producto es utilizando

“historias de usuario”. Este es un ejemplo de una historia de usuario:

 “Como usuario final, quiero obtener un informe sobre la actividad de mi cuenta, para

comprobar si todo está bien”.

En Agile se prefiere tener objetos pequeños, ya que hace más fácil el control del

proyecto. Además, durante una iteración también podemos producir o completar al

100% varios artículos pequeños, mientras que, si los artículos son grandes, es difícil

decir saber cuándo se completan realmente.

La plantilla genérica para una historia de usuario es la siguiente:

Como (rol)…, quiero (función)…, para (propósito)…

Figura 1: Historia de Usuario

El tercer elemento de la plantilla es opcional y no lo mencionaremos cuando sea

obvio. Fijae en el siguiente ejemplo:

Como administrador del sistema (rol), quiero poder restablecer las contraseñas

(función), para… (no es necesario mostrar el propósito).

2.3.3. Sprint Backlog

Lista de tareas que el equipo elabora en la reunión de planificación de la iteración

como plan para completar los objetivos/requisitos seleccionados para la iteración y

que se compromete a demostrar al cliente al finalizar la iteración, en forma de

incremento de producto preparado para ser entregado.

Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza,

con lo que le permite tomar decisiones al respecto.

Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo

pendiente para finalizarlas y la auto asignación que han hecho los miembros del

equipo.

Uso de la lista:

 Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.

Por ello, signos de falta de foco, problemas o impedimentos serían que se estén

completando objetivos que no son los primeros de la lista, así como tener

demasiados objetivos/requisitos en progreso simultáneamente.

 Si una tarea depende de otra, se coloca en algún punto por debajo de la que

depende.

 Las tareas deben estar identificadas de manera que tengan un coste semejante

para ser completadas, entre 4 y 16 horas. Este tamaño permitirá.

 Que las tareas sean suficientemente pequeñas como para poder detectar progreso

o estancamiento de manera diaria.

 Que las tareas no sean muy pequeñas, que sean suficientemente relevantes, no

generen ruido ni micro gestión.

 Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas

dentro de la iteración.

2.3.4. El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteración se puede gestionar mediante un

tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas

necesarias para completarlo, en forma de post-its, y se van moviendo hacia la

derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para

cada miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre

cada tarea, de manera que se pueda ver en qué tareas está trabajando cada cual.

Figura 2: Tablero de tareas

2.4. Eventos de Scrum

Otro factor determinante para la buena marcha de la metodología son los eventos que

realizan los distintos participantes. Los eventos se usan en Scrum para crear un patrón

constante y minimizar la necesidad de reuniones no definidas.

Todos los eventos son “time boxeados”, es decir, tienen una duración máxima, pudiendo

acabarse, siempre que se logre el objetivo del evento.

Beneficios de usar los eventos de Scrum

1. Mejora la comunicación entre los miembros del equipo

2. Elimina la necesidad de otras reuniones

3. Identifica y elimina impedimentos

4. Resalta y promueve la toma rápida de decisiones

5. Mejora el nivel de conocimiento del equipo

6. Optimiza la posibilidad de que se cumpla el objetivo del Spring

Un proyecto que sigue Scrum se gestiona siguiendo cinco eventos:

Figura 3: Eventos de Scrum

2.4.1 Sprint
Cada proyecto Scrum es un conjunto de Sprint. El Sprint es la esencia del método

Scrum. Son períodos cortos de 15-30 días en los que se realiza una acción concreta.

Cada sprint debe ponerse en marcha sólo cuando el anterior haya terminado. Lo ideal

es no modificar sus plazos y tiempos; por el contrario, la mejor forma de obtener los

resultados esperados es cumpliendo con lo acordado.

Un Sprint contiene, los cuatro eventos o rituales, el esfuerzo de desarrollo, y el

mantenimiento del Backlog de Producto.

2.4.2. Planificación del Sprint o Sprint Planning

Es el primer evento dentro de un Sprint. El Equipo Scrum planea los artículos que se

van a entregar en el Sprint y cómo se hará es decir determina cual va a ser el objetivo

del sprint y las tareas necesarias para conseguirlo.

La duración del Sprint planning debe durar como máximo 8 horas para un Sprint de

un mes, y si el Sprint es más corto, el evento suele ser más corto.

El Sprint Planning se realiza para responder a las siguientes preguntas:

 ¿Cuál va a ser el incremento de valor del próximo Sprint (Sprint Goal)?

 ¿Cómo se logrará el trabajo necesario para lograrlo?

2.4.3. Reunión diaria de Scrum o Daily scrum

Durante el desarrollo del Sprint los miembros el Equipo de Desarrollo mantienen una

serie de reuniones diarias que se conocen como scrum diario Scrum Diario. Estás

reuniones tienen una duración máxima de 15 minutos, y son solo para los

desarrolladores; nadie más puede participar. Bueno, cualquiera puede “asistir” a la

reunión, pero en “modo de silencio”.

Durante el Scrum Diario los desarrolladores responden a tres preguntas:

 ¿Qué hice desde ayer?

 ¿Qué voy a hacer hasta mañana?

 ¿Qué obstáculos he encontrado o podría encontrar?

Recuerde que la reunión debe hacerse en 15 minutos. Así que, ¡NO hablamos de los

problemas! Discutiremos los problemas después de la reunión, y si el problema no

es técnico y no podemos resolverlo, entonces pediremos ayuda al Scrum Máster.

2.4.4. Revision del Sprint o Sprint Review

Una vez concluido el ciclo de sprint se mantiene una reunión en la que se define qué

parte del trabajo previsto se ha completado y qué parte permanece pendiente. En

cuanto al trabajo completado se realiza una revisión (demo) del mismo al product

owner y otros usuarios que pudiesen estar involucrados.

Antes del final del Sprint el equipo de Desarrollo demuestra el resultado del Sprint al

cliente y recibe retroalimentación (feedback). Esta reunión se llama Revisión del

Sprint, también se conoce como Demostración del Sprint.

Es una reunión de 4 horas de duración máxima para Sprint de un mes, asegurándose

el Scrum Master de que tiene lugar y que los asistentes entiendan su propósito. Es el

Product Owner el que inivita a los stakeholders que cree conveniente a participar.

PASOS DEL SPRINT REVIEW

 El Product Owner explica qué elementos del Product Backlog se han movido a

la columna “Done” y cuales no, pero es el Development Team quien muestra el

trabajo y responde a las preguntas sobre el incremento.

 El Development Team discute qué fue bien durante el Sprint, qué problemas

sucedierón y como se resolvieron.

 El Product Owner analiza el Product Backlog, comentando fechas de

finalización basadas en el progreso hasta la fecha en el caso de que sea es

necesario.

 Todo el grupo habla sobre qué hacer a continuación, por lo que el Sprint Review

genera una conversación y un entendimiento hacia la siguiente planificación de

Sprint.

 Se revisa si el mercado o las necesidades potenciales del producto han cambiado

para decidir cuáles son los pasos siguientes más importantes.

 Revisión del timeline, presupuestos, capacidades potenciales y el estado del

mercado en base al próximo lanzamiento del producto.

Lo que se debe obtener al final de un Sprint Review es un Product Backlog revisado

y priorizado con los elementos más importantes a trabajar durante el próximo Sprint.

2.4.5. Retrospectiva del Sprint

Es la es una oportunidad para el Equipo Scrum de examinarse a sí mismo, y crear un

plan de mejoras para el siguiente Sprint. Es un punto para determinar que se hizo

bien y que se puede mejorar.

Esta se debe desarrollar después de la revisión de Sprint y antes de la siguiente

Reunión de Planificación de Sprint. Al igual que las demás reuniones debe tener una

restricción de tiempo que depende de la duración del Sprint.

Sus objetivos son:

  Revisar cómo fue el último Sprint en aspectos como Procesos, Herramientas,

etc.

 Identificar los elementos más importantes que fueron positivos y crear posibles

mejoras.

 Desarrollar un plan para la implementación de mejoras en el desempeño del

trabajo del equipo.

Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica formas de

aumentar la calidad del producto.

Al momento de finalizar la Retrospectiva de Sprint, el Equipo Scrum debe haber

identificado las mejoras que implementará en el próximo Sprint.

2.5. Roles

En Scrum, el equipo se focaliza en construir software de calidad. La gestión de un

proyecto Scrum se centra en definir cuáles son las características que debe tener el

producto a construir (qué construir, qué no y en qué orden) y en vencer cualquier

obstáculo que pudiera entorpecer la tarea del equipo de desarrollo.

El equipo Scrum está formado por los siguientes roles: (Business School)

2.5.1. Scrum Máster

Es el rol central del proyecto. En algunas ocasiones es quien representa al cliente y en

otras son la misma persona. Sus principales funciones son:

 Transmite las necesidades del negocio ante el director y su equipo de trabajo.

 Decide las características funcionales del producto o servicio.

 Protege los intereses del negocio; maximiza el valor de la inversión.

  Revisa el producto al final de cada iteración.

 Sugiere cambios y adaptaciones al término de cada nueva iteración.

2.5.2. Product Ownen

Muchos consideran que el Scrum Máster es el líder del proyecto. Y en cierta forma

lo es, pero su labor no acaba ahí. Además de la gestión de las acciones en cada

iteración, es el encargado de mantener en contacto al equipo de trabajo con el cliente.

Otras de sus funciones más destacadas son:

 Resolver los conflictos que obstaculicen el ritmo normal del proyecto.

 Incentivar y motivar al equipo de trabajo.

 Fomentar la autogestión de sus colaboradores durante el proceso.

 Negociar y renegociar las condiciones con el cliente.

 Evitar la intromisión de terceros en las labores.

2.5.3. Equipo de desarrollo

Finalmente, el Scrum Team hace referencia al equipo de trabajo que lleva a cabo las

acciones propias de cada iteración: programadores, diseñadores, arquitectos, personal

de servicio, entre otros. Lo principal es que deben estar organizados como un grupo o

equipo y desempeñar roles concretos dentro de él. Se ocupan básicamente de cosas

como las siguientes:

 Desarrollar cada una de las tareas incluidas en el plan de trabajo.

 Poner al servicio del proyecto sus conocimientos y técnicas.

2.6. Ventajas de Scrum

 Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras

vas atacando los objetivos más sencillos, eso te hace ganar tiempo para atacar los

objetivos más complejos.

 el Scrum Master tiene el conocimiento necesario para lograr el objetivo primario

y secundario por lo cual puede ir controlando el proyecto y delegando roles.

 Cada persona sabe que es lo que tiene que hacer y no es necesario estar

reorganizando una y otra vez los Tracks de cada persona.

 Se involucra desde un principio y se da un rol a todos los stakeholders (personas

que van a participar en el proyecto incluyendo cliente final, QA, Testers, etc.)

2.7. Limitaciones de Scrum

 Algunos miembros de tu equipo pueden saltar pasos importantes en el camino

rápido para llegar al “sprint” final.

 El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces

los va a pedir antes, cuando capaz no pudiste avanzar en nada.

 Demasiadas Reuniones para poco avance, a veces es muy cansado y estresante

reunirse demasiadas veces por el mismo tema, algunos van perdiendo el interés

en el proyecto.

 Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya

que es la persona que se lleva el conocimiento específico y afecta a todo el

proyecto.

 No es aplicable a grandes escalas o cuando el sector IT es variado.

 CONCLUSIONES

Scrum por sus características no es válido para cualquier proyecto ni para cualquier

persona o equipo de personas. Es más, Scrum según muchos especialistas de esta

metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas

que han utilizado Scrum con éxito con equipos más grandes.

La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda

reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes,

los tiempos y al equipo de trabajo.

 BIBLIOGRAFÍA

Business School. (s.f.). Obtenido de https://www.obs-edu.com/int/blog-project-

management/scrum/principales-roles-de-la-metodologia-agil-scrum

Gallego, M. T. (2012). Gestion de Proyectos Informaticos. Obtenido de

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memo
ria.pdf
Lara, W. (2015). Metodologia Scrum. Obtenido de https://platzi.com/blog/metodologia-
scrum-fases/
López Menéndez de Jiménez, R. E. (2015). Metodologías Ágiles de Desarrollo de
Software Aplicadas a la Gestión de Proyectos Empresariales. REVISTA
TECNOLÓGICA, 6-11.

Página web: https://www.scrummanager.net/bok/index.php?title=El_manifiesto_ágil

Página web: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-

manifesto/