La metodología ágil ayuda a los equipos a desarrollar software de manera rápida y flexible para adaptarse a los cambios. Ofrece una alternativa a los procesos tradicionales al enfocarse en la colaboración, la flexibilidad y la entrega continua de valor al cliente. El documento describe las características, historia y marcos de las metodologías ágiles y las compara con los métodos tradicionales de desarrollo de software.

1. UniversidadTecnológica delValle deToluca
“METODOLO GÍA ÁGIL DE
DESARROLLO DE SOFTWARE”
Presentado por:
Jaime Crisóstomo Cuarto
Jorge Juárez Olivera
Mauricio Gutiérrez Solano

2. INDICE
• Resumen
• Objetivo
• ¿Qué es?
• ¿Quién la creo?
• Historia
• El ManifiestoÁgil
• Certificaciones
• Versiones
• Descripción DetalladaComponentes
• Características principales
• Tabla de diferencias vs otro parecido
• Ejemplo

3. Resumen
• La metodología ágil ayuda a los equipos desarrollar software de manera
rápida y flexible a los cambios que puedan surgir a lo largo del proyecto.
• Ofrece una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rígidos y enfocados a la
documentación.
• Varias de las denominadas metodologías ágiles cada vez son más utilizadas
por los desarrolladores //ya estaban siendo utilizadas con éxito
en proyectos reales, pero les faltaba una mayor difusión y reconocimiento.

4. Objetivo
• Describir las características fundamentales de la metodología ágil, su
historia, y realizar un comparativo con otras metodologías de desarrollo
del software, para ofrecer una visión completa acerca de sus aplicaciones y
su viabilidad en nuestro entorno profesional.

5. ¿Qué es?
• Es una metodología de desarrollo de software alternativa a la gestión
tradicional de proyectos de software.
• Supone una mejora o innovación al modelo tradicional de cascada o
secuencial.
¿Quién la creo?
• Surge formalmente en Febrero de 2001, con el “Manifiesto Ágil” (Agile
Manifiesto), redactado por 17 desarrolladores norteamericanos de software
destacados: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, entre otros.

6. Historia
• En 1970, el Dr. Winston Royce presentó un documento titulado "Gestión del
desarrollo de sistemas de software grandes", que criticaba el desarrollo
secuencial.
• La definición evolucionó a mediados de 1990 como parte de una reacción
contra los métodos tradicionales, demasiado rígidos y estructurados.
• En el 2001 se adopto el nombre de “Metodología ágil” y luego nacería la
“Alianza Ágil”

7. El Manifiesto Ágil
• El individuo y las interacciones del equipo de desarrollo tienen mayor peso que
los procesos y las herramientas.
• La colaboración con el cliente mas que la negociación de un contrato.
• Ser flexibles antes los cambios mas que seguir estrictamente un plan.
• Los responsables de negocio y los desarrolladores trabajan juntos de forma
cotidiana durante todo el proyecto.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.

8. CAPM® PMI-SP PMI-RMP PgMP® ITIL®V3
Nombre
Certified Associate
in Project
Management
PMI Scheduling
Professional
PMI Risk
Management
Professional
Program
Management
Profesional.
intermediate continual service
improvement
Rol de Proyecto
Contribuye a
equipo de
proyecto
Desarrolla y
mantiene
calendario del
proyecto
Evalúa e identifica
los riesgos, mitiga
las amenazas y
aprovecha las
oportunidades.
Alcanza un
objetivo de
organización a
través de la
definición y
supervisión de
proyectos y
recursos.
ITIL® consiste en una serie de
libros que ofrecen una
orientación en la provisión de
servicios de TI de calidad.
Está basado en un conjunto de
experiencias de profesionales
tanto del sector
público
como privado,
alrededor del mundo
CERTIFICACIONES

9. Características básicas de la metodología ágil
• Incertidumbre: la dirección indica la necesidad estratégica que se desea
cubrir
• Equipos auto-organizados: no existen roles especializados
• Autonomía: libertad para la toma de decisiones.
• Auto-superación: de forma periódica se evalúa el producto que se esta
desarrollando.
• Auto-enriquecimiento: transferencia del conocimiento.
• Fases de desarrollo solapadas: Las fases no existen como tal sino que se
desarrollan tareas/actividades

10. Metodología Acrónimo Creación Tipo de modelo Caracteristica
Adaptative Software
Development
ASD Highsmith 2000 Prácticas + ciclo de vida Inspirado en sistemas adaptativos complejos
Agile Modeling AM Ambler 2002 Metodología basada en la
práctica
Suministra modelado ágil a otros métodos
Crystal Methods CM Cockbum 19998 Familia de metodologías Metodología ágil con énfasis en modelo de
ciclos
Agile RUP dX Booch, Martin, Newkirk 1998 Framework/Disciplina XP dado vuelta con
artefactos RUP
Dinamyc Solutions Delivery
Model
DSDM Stapleton 1997 Framework/modelo de
ciclo de vida
Creado por 16 expertos
en RAD
Evolutionary Project
Management
Evo Gilb 1976 Framework adaptativo Primer método ágil
existente
Extreme Programming XP Beck 1999 Disciplina en prácticas de
ingeniería
Método ágil radical
Feature Solutions Delivery Model FDD De Luca & Coad 1998 Palmer&
Felsing 2002
Metodología Método ágil de diseño y construcción
Lean Development LD Charette 2001, Mary yTom
Poppenddieck
Forma de pensar – modelo
logístico
Metodología basada en procesos productivos
Microsoft Solutions Framework MSF Microsoft 1994 Survey de técnicas y
modelos
Selección de best practices, no método
Rapid Development RAD McConnell 1996 Lineamientos, disciplinas,
prácticas
Framework de desarrollo de soluciones
Scrum Scrum Sutherland 1994-schwaber 1995 Proceso – framework de
management
Complemento de otros métodos, ágiles o no
Metodologías Ágiles

11. Metodología Ágil MetodologíaTradicional
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
Tabla 2. Diferencias entre metodologías ágiles y no ágiles

12. Requerimientos
Diseño
Desarrollo
Pruebas
Mantenimiento
Requerimientos
Diseño
Desarrollo
Pruebas
Mantenimiento
Requerimientos
Diseño
Desarrollo
Pruebas
Mantenimiento

13. Multifuncional
Auto-Organizado
Enfocado en las entregas
Representa los intereses del cliente
Experto
Tiene una visión clara del producto
Facilitador
Coach del proceso
Remueve obstáculos
Pila del Producto
Product Backlog
Lista priorizada de
requerimientos
Junta de Planeación
( 1- 2 hrs)
Retrospectiva
( 1- 2 hrs)
Junta de Revisión
( 1- 2 hrs)
Reunión Diaria
( 10-15 min)
¿Qué hiciste ayer?
¿Qué hay para hoy?
¿Qué necesitas?
Identificar oportunidades
de mejora
Mostrar las nuevas características del incremento
Retroalimentación del equipo
Reasignar prioridades en el Product Backlog
INCREMENTO

14. ID Orden Estimado Descripcíon CriterioValidación Observ
1 10 30 Plataforma tecnológica Se tiene el diagrama de la
arquitectura, validado por
XXXXX
La arquitectura
debe permitir
escalabilidad
2 20 40 Prototipos Interfaz de
usuario
Todas las pantallas de
interfaz están hechas y se
puede recorrer la
funcionalidad
Aplicable para
las
funcionalidades
de la pila a la
fecha
4 30 40 Diseño de datos Diagrama BD. Realizado.
Validado por XXXXX

17. ¿Por qué utilizar metodologías ágiles?
•Para reducir el tiempo de desarrollo: 45%
•Para mejorar la calidad: 43%
•Para reducir costes: 23%
•Para alinear el desarrollo con los objetivos de
negocio: 39%
•Otras razones: 12%.

18. Conclusiones
• Las metodologías ágiles presentan una propuesta de mejora para las
metodologías secuenciales o tradicionales; sin embargo, no son aplicables a
todos los proyectos, ya que dependen del tamaño de la organización

19. Bibliografía
• Principios del Manifiesto Ágil. http://www.agilemanifesto.org/iso/es/principles.html
• Project Management Institute. PMI® Agile Certification Integrated Services Frequently
Asked Questions.
• Cockbun, A. “Agile Software Development”. Addison-Wesley. 2001.
• Abrahamsson, P., Salo, O., Ronkainen, J.,Warsta, J. “Agile software development
methods Review and analysis”.VTT Publications. 2002.
• Martinez, Gustavo (2011). Coding, quality check and documentation (300%): Get
them from the same development team!.VPD.
• West, D. Water-Scrum-Fall IsThe Reality Of Agile For Most OrganizationsToday.
http://www.cohaa.org/content/sites/default/files/water-scrum-fall_0.pdf
• Wikipedia. Agile Software Development.
http://en.wikipedia.org/wiki/Agile_software_development