1. 1
UNIVERSIDAD LAICA ELOY ALFARO DE MANABÍ
Facultad de Ciencias Informáticas
“METODOLOGÍA SCRUM”
Estudiante:
Delgado Chavarria Kerly
Lopez Sucuzhanay Gabriel
Vélez Flores Bryan Fernando
Curso:
2do. Nivel
Paralelo:
“B”
Docente:
Ing. John Cevallos
Materia:
Teoría de Sistemas

2. 2
ÍNDICE
1.- Concepto de metodología ágil……………………………………………………….3
2.-Historia de las metodologías ágiles……………………………………………….....4
3.-Ventajas de las metodologías ágiles sobre las tradicionales………………......…9
4.-Herramientas actuales que ayudan al desempeño de estas tecnologías………11
5.-Comparar las metodologías ágiles con las tradicionales………………………...12
6.-Según la metodología que le ha tocado, detallar:
6.1.-Características principales……………………………………………………...13
6.2.-Roles……………………………………………………………………………....13
6.3.-Documentos………………………………………………………………………14
6.4.-Iteraciones……………………………………………………………………..….14
6.5.-Beneficios y ventajas sobre otras metodologías…………………………..…15
6.6.-Esquema con el resumen de su funcionamiento……………………...……..15
6.7.-Diferencia entre esta metodología y las tradicionales………………………16
7.-Bibliografía……………………………………………………………………………17
8.-Conclusión……………………………………………………………………………18

3. 3
1.- Concepto de MetodologíaÁgil
Existen numerosas propuestas de metodología para desarrollar software.
Tradicionalmente estas metodologías se centran en el control del proceso,
estableciendo rigurosamente las actividades, herramientas y notaciones al
respecto, dado estas reglas estas metodologías se caracterizan por ser rígidos y
dirigidos por la documentación que se genera en cada una de las actividades
desarrolladas.
La metodología ágil es el método que permite incorporar cambios con rapidez en
el desarrollo de software.
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar
un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en
cualquier fase del proyecto.
Valorar al individuo y las interacciones en el equipo de desarrollo más que a las
actividades y las herramientas.
Desarrollar software que funciona más que conseguir una buena documentación
 Minimalismo respecto del modelado y la documentación del sistema.
La colaboración con el cliente más que la negociación de un contrato.
Responder a los cambios más que seguir estrictamente una planificación.

4. 4
2.-Historia de las metodologíaságiles
El desarrollo ágil es un marco conceptual que reconoce las distintas
interacciones y cambios que ocurren en todo desarrollo de software. Evolucionó a
partir de varios métodos. El Término "Ágil" fue definido por el "Manifiesto Ágil" en
2001. A continuación presentamos una línea de tiempo con los principales eventos
en la historia del movimiento ágil:
1930 - Ciclo PDCA
Walter Shewhart propone el ciclo de "Planear", "Hacer", "Estudiar" y "Actuar", un
concepto que luego fue difundido por Deming.
1940 - Kanban, Sistemas de Producción de Toyota y el Lean Manufacturing
(Manufactura esbelta)
Taiichi Ohno inventa el método Kanban en Toyota. El Lean Manufacturing es una
fuente de inspiración y precursor del movimiento ágil.
1974 - El Proceso de Desarrollo de Software Adaptativo
Un Paper de E.A. Edmonds presenta el concepto de "Proceso de Desarrollo de
Software Adaptativo" en 1974. Asimismo, también durante los 70, Tom Gild
publica conceptos sobre la Gestión de Proyectos Evolutiva (EVO).
1992 – Crystal
Alistair Cockbur presenta los Métodos Crystal, el punto de inicio de la evolución de
las metodologías de desarrollo de software que eventualmente resultaron en lo
que hoy se conoce como el movimiento ágil.
Crystal puede ser aplicada en equipos de trabajo de entre 6 y 8 desarrolladores
localizados en la misma área, trabajando en sistemas no críticos para la vida (es
decir los fallos son tolerables).
1993 – Refactorización

5. 5
Bill Opdyke presenta el concepto de "Refactorización" en su paper titulado
"Creando Superclases Abstractas por medio de la Refactorización".
La Refactorización de código es una técnica para la reestructuración de piezas
de código existente, alterando su estructura interna sin afectar su comportamiento
con el exterior, que se ejecuta para mejorar los atributos no funcionales de un
software.
1995 - Programación en Pares (Pair Programming)
Es un concepto que fue simultáneamente ideado, pero de forma independiente por
varios autores. Por una parte Jim Coplien publicó un Paper, que definió la
"Programación en Pares" como un patrón de desarrollo de software. Por otra parte
Larry Constantine definió los "duos dinámicos" en su libro "Constantine on
Peopleware" del mismo año.
Este concepto se convirtió en una parte integral de la Programación Extrema.
Se han realizado muchas investigaciones que han demostrado la efectividad de la
programación en pares. Sin embargo, la filosofía no está reflejada en el Manifiesto
Ágil.
1995 - Scrum
El método Scrum fue ideado por Ken Schwaber y Jeff Sutherland, quienes lo
presentaron en la conferencia OOPSLA 95 (Object-Oriented Programming,
Systems, Languages & Applications) en Austin Texas. Jeff Sutherland es el
Presidente (CEO) de Scrum, Inc y Ken Schawaber es el fundador de Scrum.org.
Mike Beedle fue uno de los pioneros en adoptar Scrum y colaboró con su
adopción en muchas organizaciones.
Como se sabe, Scrum es prácticamente el estándar de facto para el desarrollo
ágil.
1997 - Desarrollo guiado por funcionalidades / Feature Driven Development
(FDD)
El método FDD fue inicialmente ideado por Jeff De Luca. En él se definen mejores
prácticas como son: Modelado de objetos de dominio, Desarrollo por
funcionalidades, Propiedad individual de las clases (Código), Equipos de trabajo
por funcionalidad, Inspecciones, Gestión de Configuración, Compilaciones
regulares (periódicas) y visibilidad del avance y resultados.

6. 6
El Proceso FDD fue explicado por medio de la publicación del libro "Modelado
Java a Colores con UML: Componentes y Procesos Empresariales", cuyos
coautores son Jeff De Luca y Peter Coad.
1999 Desarrollo de Software Adaptativo
Jim Highsmith formalizó el concepto de Desarrollo de Software Adaptativo y
público su libro del mismo nombre. La idea creció y evolucionó hacia las
metodologías de Desarrollo Rápido de Aplicaciones (RAD). La metodología
propone un ciclo de vida de 3 fases: Especulación, Colaboración y Aprendizaje.
1999 - Programación Extrema / Extreme Programming (XP)
Mientras trabajaba en Chrysler, Kent Beck desarrolla el concepto
de Programación Extrema, publicando el método en 1999 en un libro titulado
"Extreme Programming Explained". Como parte de la Programación Extrema,
también formuló los conceptos de Historias de Usuario y Planificación de
Releases. La metodología especifica buenas prácticas para la planificación,
gestión, diseño, codificación y pruebas.
Ward Cunningham y Ron Jeffries colaboraron con Beck al escribir el libro sobre
XP, a los tres se les considera los fundadores de la Programación Extrema.
1999 - Integración Continua
Kent Beck definió este concepto también, pero fue un paper de Martin Fowler el
que lo popularizó.
2001 - El Manifiesto Ágil
Bob Martin, reúne a otros 16 líderes del movimiento ágil, para escribir el
"Manifiesto Ágil", que engloba las metodologías que hasta ese momento se les
conocía como "Metodologías de Desarrollo de Software de peso liviano".
2002 - Desarrollo guiado por pruebas / Test Driven Development (TDD)
El concepto se originó el enfoque de "Probar primero" asociado a la Programación
Extrema (XP). Luego tomo mayor con la publicación del libro "Desarrollo guiado
por pruebas: Por ejemplos" (Test Driven Development: By Example), escrito por
Kent Beck.
Luego Kent Beck escribe otros libros sobre el tema como "Rediscovering Test-
Driven Development".

7. 7
2002 - Planning Poker
También en 2002 nace la técnica de Planning Poker, ideada por James Greening
y escrita en un Paper.
2003 - Desarrollo de Software Esbelto / Lean Software Development
Mary y Tom Poppendieck presentan su obra "Lean Software Development".
El Lean Software Development es una adaptación de los principios de la
manufactura esbelta y de los del desarrollo de software. Presenta 7 principios:
Eliminar desperdicio, amplificar el aprendizaje, Decidir tan tarde como sea posible,
entregar lo más rápido posible, dar poder al equipo (empowerment), construir
integridad y ver la totalidad. Como se puede ver estos principios están alineados
con la filosofía ágil.
¿Es el Lean Software Development una metodología ágil?, o es algo distinto,
muchos la consideran como el próximo eslabon en la evolución del desarrollo ágil.
2006 - Desarrollo guiado por comportamiento / Behavior Driven Development
Dan North presenta su obra "Behavior Driven Development", un método que
combina las principales ideas y técnicas del TDD con las ideas del Diseño guiado
por dominio y el Análisis y Diseño orientado a objetivos. El método se enfoca en
proporcionar herramientas y procesos colaborativos entre desarrolladores de
software y analistas funcionales, buscando acercar a los técnicos de software con
las necesidades que impulsan al área de negocio.
2007 - Retrospectivas
Esther Derby y Diana Larsen escriben su obra "Agile Retrospectives",
estableciendo las reuniones retrospectivas como práctica ágil estándar.
2007 - Kanban para el Desarrollo de Software
David Anderson presenta su obra "Kanban", adaptando el Kanban para el
desarrollo de software. El método se enfoca en la entrega "justo a tiempo" y en no

8. 8
sobrecargar a los desarrolladores de software, tal como su precursor el Kanban
para manufactura perfeccionado por Toyota. Bajo este enfoque, todas las tareas
necesarias para entregar una funcionalidad al cliente se le muestran a los
desarrolladores, quienes toman la tarea a realizar de una cola, de forma similar al
backlog definido en Scrum.
El Kanban no prescribe una serie de pasos o métodos, no existe algo como "el
método de Gestión de Proyectos Kanban", en su lugar, la intención es iniciar con
los roles y procesos que se tienen actualmente y partir de allí estimular cambios
continuos, incrementales y evolucionarios sobre el método de trabajo.
2009 - Manifiesto de la Artesanía de Software (Software Craftmanship)
Los asistentes a la primera conferencia internacional de Artesanía de Software
escriben sus conclusiones y promulgan el "Manifiesto de Artesanía de Software".
La artesanía de software no solamente se trata de prácticas de programación sino
también de formar a la siguiente generación.
2009 - Lean Startup
Eric Ries escribe su obra "Lean Startup". Es una metodología mayormente teórica
para el desarrollo de empresas y productos. Basado en las experiencias de Ries
trabajando con varios emprendimientos (startups), el método se basa en que los
ciclos de desarrollo de productos pueden reducirse en duración por medio de
ciclos continuos de experimentaciones, iteraciones y lanzamientos de producto.
Ries establece que si las Compañías construyen sus productos o servicios de
forma iterativa, buscando lanzarlos al cliente lo antes posible y adquirir aprendizaje
a partir de allí, pueden evitarse los costosos proyectos y lanzamientos de nuevos
productos.

9. 9
3.-Ventajas de las metodologías ágiles sobre las tradicionales
1.- Simplificación de la sobrecarga de procesos
Los equipos que trabajan para crear productos regulados por estándares de la
industria, deben demostrar el cumplimiento de esas normas. Estos equipos suelen
adoptar importantes sobrecargas de trabajo para asegurarse de que cumplen con
los estrictos mandatos de código. Las metodologías ágiles pueden ayudarles a
cumplir los estándares de la industria con menos sobrecarga utilizando iteraciones
más cortas y empaquetadas. El beneficio neto es un proceso que:
- Puede adaptarse a los cambios que, inevitablemente, surgirán
- Requiere menos sobrecarga en el proceso end-to-end
- Implica menos trabajo a medida que se acerca la fecha final
2.- Calidad mejorada
Las prácticas de desarrollo ágil proporcionan la funcionalidad suficiente como para
satisfacer las expectativas de los accionistas con una alta calidad. Piensa en lo
que significa “ofrecer lo suficiente”. Eso es, proporcionar la mínima funcionalidad
con la máxima calidad. La mínima funcionalidad no implica necesariamente una
pobre funcionalidad, implica lo suficiente como para conseguir que el trabajo se
realice. Los accionistas suelen pensar que saben lo que quieren cuando
especifican altos niveles de requerimientos para un producto TI o de software. Sin
embargo, la mayoría de las veces, cuando ven el producto final, éste no resuelve
el problema. Simplemente, no se han imaginado de forma precisa el mismo, o el
problema ha cambiado o, incluso, la tecnología no era tan buena como parecía.
También puede ser que el producto no funcione realmente del modo en que las
partes interesadas tenían intención, incluso aunque pensaran que habían descrito
los requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y
demostrar a los accionistas los productos pronto y con frecuencia, permite tanto a
los accionistas como a los equipos de desarrollo ponerse de acuerdo y coincidir en
que el producto cumple con cada una de sus necesidades.
3.- Mejorar la previsibilidad a través de una mejor gestión del riesgo

10. 10
Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a
menudo se debe a muchas razones completamente justificables. Puede ser que el
equipo no hubiera entendido bien lo difícil que sería utilizar la nueva tecnología;
los requerimientos podían no estar del todo claros o los clientes cambiaron de
opinión cuando el trabajo estaba prácticamente finalizado. En cualquier caso, los
negocios demandan productos que cumplan con las fechas de entrega, de modo
que los planes de negocio directamente relacionados con ellos puedan cumplirse.
Hay muchas formas en las que las metodologías ágiles pueden ayudar a que los
proyectos TI cumplan con las fechas de lanzamiento previstas.
Dar prioridad a los riegos. Las prácticas ágiles priorizan los aspectos de
desarrollo de alto riesgo permitiendo así una reducción de los riesgos iniciales.
Evaluación de riesgos en paralelo. Para áreas de riesgo donde debería haber
múltiples soluciones y el equipo no se pone de acuerdo a la hora de tomar el
camino más adecuado, se debe tener en cuenta la posibilidad de optar por el
desarrollo multi-set. Esto requiere que diferentes equipos trabajen en paralelo
resolviendo el mismo problema con diferentes soluciones. La mayoría de los
equipos no considerarán ni tan siquiera esta forma de trabajar, porque están
convencidos de que el tiempo y el coste requeridos para hacer una evaluación
paralela son demasiado grandes. De hecho, el desarrollo paralelo de alternativas
es probable que traiga consigo las decisiones clave a seguir.
4.- Mejor perfil de productividad
Los equipos ágiles son más productivos que aquellos que utilizan métodos
tradicionales a lo largo de todo el ciclo de desarrollo. El desarrollo tradicional suele
mostrar un patrón de trabajo parecido a un palo de hockey, empezando con un
ciclo de diseño de abajo arriba, moviéndose hasta una fase de prototipo para
pasar luego a un ciclo de desarrollo largo, seguido por otro ciclo totalmente
impredecible en el que se integran las piezas para pasar, por último, a la fase de
prueba final. A medida que el proyecto progresa, los equipos tienen que trabajar
juntos de manera más coherente, confiando en que todas las piezas trabajen
juntas tal y como esperan. Pero lo cierto es que esto raramente ocurre, de modo
que la interacción entre los equipos aumenta a medida que lo hacen los problemas
de integración. Por último, la fase de pruebas lleva todo esto al límite. Trabajando
juntos como un único equipo en fases verticales del producto desde el principio del
ciclo de producción, se evita el ciclo de productividad tradicional de palo de
hockey. Los equipos ágiles tienden a ser muy productivos desde la primera
iteración hasta su lanzamiento y su ritmo tiene que ser gestionado de modo que
no se produzca agotamiento. Los equipos ágiles que mantienen este código de
trabajo con cada iteración, permiten realizar pruebas de rendimiento y sistemas
desde el principio, pudiendo empezar en las primeras iteraciones. De este modo,
defectos críticos como problemas de integración se descubren antes, la calidad
general del producto es mayor y el equipo funciona de manera más productiva
durante todo el ciclo de desarrollo.

11. 11
5.- Capacidad para aprovechar las inversiones realizadas
Adoptar las técnicas ágiles de manera satisfactoria precisa un importante soporte
de herramientas. La mayoría de los equipos invierten fuertemente en buenas
herramientas de software y necesitan elevar esa inversión y reducir la cantidad de
cambios cuando empiezan a adoptar las metodologías ágiles.
4.-Herramientas actuales que ayudan al desempeño de estas
tecnologías
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. Si se sigue un
buen proceso de desarrollo, pero el equipo falla, el éxito no está asegurado; sin
embargo, si el equipo funciona, es más fácil conseguir el objetivo final, aunque no
se tenga un proceso bien definido. No se necesitan desarrolladores brillantes, sino
desarrolladores que se adapten bien al trabajo en equipo. Así mismo, las
herramientas (compiladores, depuradores, control de versiones, etc.) son
importantes para mejorar el rendimiento del equipo, pero el disponer más recursos
que los estrictamente necesarios también puede afectar negativamente. En
resumen, 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 funciona más que conseguir una buena
documentación.
Aunque se parte de la base de que el software sin documentación es un desastre,
la regla a seguir es “no producir documentos a menos que sean necesarios de
forma inmediata para tomar un 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 un contrato.
Las características particulares del desarrollo de software hacen que muchos
proyectos hayan fracasado por intentar cumplir unos plazos y unos costes
preestablecidos al inicio del mismo, según los requisitos que el cliente manifestaba
en ese momento.

12. 12
Responder a los cambios más que seguir estrictamente un plan.
La habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina
también el éxito o fracaso del mismo.
5.-Compararlas metodologías ágiles con las tradicionales
Metodología Ágil Metodología Tradicional
Pocos Artefactos. El modelado es
prescindible, modelos desechables.
Más Artefactos. El modelado es
esencial, mantenimiento de modelos
Pocos Roles, más genéricos y
flexibles
Más Roles, más específicos
No existe un contrato tradicional,
debe ser bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de
desarrollo (además in-situ)
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Orientada a proyectos pequeños.
Corta duración (o entregas
frecuentes), equipos pequeños (< 10
integrantes) y trabajando en el
mismo sitio
Aplicables a proyectos de cualquier
tamaño, pero suelen ser especialmente
efectivas/usadas en proyectos grandes y
con equipos posiblemente dispersos
La arquitectura se va definiendo y
mejorando a lo largo del proyecto
Se promueve que la arquitectura se
defina tempranamente en el proyecto
Énfasis en los aspectos humanos: el
individuo y el trabajo en equipo
Énfasis en la definición del proceso:
roles, actividades y artefactos
Basadas en heurísticas provenientes
de prácticas de producción de código
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Se esperan cambios durante el
proyecto
Se espera que no ocurran cambios de
gran impacto durante el proyecto

13. 13
6.-Según la metodología que le ha tocado,detallar:
6.1.-Características principales
El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duración de 30 días. El resultado de
cada sprint es un incremento ejecutable que se muestra al cliente.
La segunda característica importante son las reuniones a lo largo proyecto.
Éstas son las verdaderas protagonistas, especialmente la reunión diaria de
15 minutos del equipo de desarrollo para coordinación e integración.
6.2.-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 y en vencer cualquier obstáculo que pudiera entorpecer la
tarea del equipo de desarrollo.
El equipo Scrum está formado por los siguientes roles:
Scrum master: Persona que lidera al equipo guiándolo para que cumpla las
reglas y procesos de la metodología. Gestiona la reducción de impedimentos del
proyecto y trabaja con el Producto Owner para maximizar el ROI.
Producto owner (PO): Representante de lso accionistas y clientes que usan el
software. Se focaliza en la parte de negocio y él es responsable del ROI del

14. 14
proyecto (entregar un valor superior al dinero invertido). Traslada la visión del
proyecto al equipo, formaliza las prestaciones en historias a incorporar en
el Producto Backlog y las reprioriza de forma regular.
Team: Grupo de profesionales con los conocimientos técnicos necesarios y que
desarrollan el proyecto de manera conjunta llevando a cabo las historias a las
que se comprometen al inicio de cada sprint.
6.3.-Documentos
 Pila de producto o Producto Backlog
 Pila de sprint o Sprint Backlog
6.4.-Iteraciones
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas
(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene que
proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable, de manera que cuando el cliente (Producto Owner) lo
solicite sólo sea necesario un esfuerzo mínimo para que el producto esté
disponible para ser utilizado. Para ello, durante la iteración el equipo colabora
estrechamente y se llevan a cabo las siguientes dinámicas:
 Cada día el equipo realiza una reunión de sincronización, donde cada miembro
inspecciona el trabajo de los otros para poder hacer las adaptaciones
necesarias, comunica cuales son los impedimentos con que se encuentra,
actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y
los gráficos de trabajo pendiente (Burndown charts).
 El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con
su compromiso y de que no se merme su productividad.
o Elimina los obstáculos que el equipo no puede resolver por sí mismo.

15. 15
o Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
6.5.-Beneficios y ventajas sobre otras metodologías
Beneficios:
 Es recomendable emplearlo solo en proyectos a corto plazo.
 Altas comisiones en caso de fallar.
Ventajas:
 Programación organizada.
 Menor taza de errores.
 Satisfacción del programador.
6.6.-Esquema con el resumen de su funcionamiento

16. 16
6.7.-Diferencia entre esta metodología y las tradicionales
Simplificándolo mucho, se puede decir que las metodologías tradicionales (SSAD,
RUP, etc.) ponen por encima de lo demás los objetivos de la definición y del
control del trabajo, mientras que las metodologías ágiles priman la libertad del
equipo, la comunicación entre el cliente y el equipo, realizar sólo las tareas que
aportan valor al cliente, y finalmente definir el trabajo tal y como éste se va
realizando para el conocimiento adquirido durante su desarrollo evite realizar
tareas innecesarias.
Una consideración importante es el tamaño de los equipos. La inmensa mayoría
de los proyectos se realizan por empresas o equipos muy pequeños (p.e. 1-10
personas) donde las metodologías tradicionales son difíciles de aplicar, e incluso
imposibles si se quiere hacer de manera exhaustiva.

17. 17
8.-Conclusión
Para obtener un software de calidad aplicando las teorías ágiles de desarrollo es
importante seguir muy ceñidamente los valores y principios ágiles para llegar
al objetivo deseado.
Las metodologías ágiles reducen el coste de desarrollo y mantenimiento del
software.
No hay varitas mágicas para conseguir mejorar la calidad y rendimiento de los
equipos de manera radical sin cambiar profundamente la manera de trabajar. Y
esto no supone en absoluto que los cambios sean difíciles si la dirección y los
miembros de la organización creen en ello decididamente.
Cada organización en mundo. Aplicar una metodología estándar de manera rápida
y sin trabajar abierta y reflexivamente con los miembros de un equipo suele ser
una buena receta para el desastre.

18. 18
7.-Bibliografía
BALLARIN,A.(3 de Septiembre de 2011). http://www.theproject.ws.Obtenidode
http://www.theproject.ws/es/project-management-scrum/entrada/metodologias-agiles-
vs-tradicionales
Cobo,R. M. (s.f.). http://www.monografias.com.Obtenidode
http://www.monografias.com/trabajos91/metodologias-desarrollo-agil-mele-
scrum/metodologias-desarrollo-agil-mele-scrum.shtml#conceptosa
http://wiki.monagas.udo.edu.ve.(s.f.). Obtenidode
http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_el_desarrollo_de
_software#Caracter.C3.ADsticas_deseables_de_una_metodolog.C3.ADa
http://www.cyta.com.ar.(s.f.). Obtenidode http://www.cyta.com.ar/ta0502/v5n2a1.htm
http://www.monografias.com.(s.f.). Obtenidode
http://www.monografias.com/trabajos91/metodologias-desarrollo-agil-mele-
scrum/metodologias-desarrollo-agil-mele-scrum.shtml#conceptosa