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

Í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

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

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

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

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

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

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

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

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

 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

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.-Comparar las 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

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

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

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

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

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

7.-Bibliografía

BALLARIN, A. (3 de Septiembre de 2011). http://www.theproject.ws. Obtenido de http://www.theproject.ws/es/project-management-scrum/entrada/metodologias-agiles-vs-tradicionales

Cobo, R. M. (s.f.). http://www.monografias.com. Obtenido de 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.). Obtenido de 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.). Obtenido de http://www.cyta.com.ar/ta0502/v5n2a1.htm

http://www.monografias.com. (s.f.). Obtenido de http://www.monografias.com/trabajos91/metodologias-desarrollo-agil-mele-scrum/metodologias-desarrollo-agil-mele-scrum.shtml#conceptosa