Universidad Tecnológica del Valle de Toluca

“METODOLO GÍA ÁGIL DE

DESARROLLO DE SOFTWARE”

Presentado por:

Jaime Crisóstomo Cuarto

Jorge Juárez Olivera

Mauricio Gutiérrez Solano

INDICE • Resumen

• Objetivo

• ¿Qué es?

• ¿Quién la creo?

• Historia

• El Manifiesto Ágil

• Certificaciones

• Versiones

• Descripción Detallada Componentes

• Características principales

• Tabla de diferencias vs otro parecido

• Ejemplo

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.

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.

¿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.

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”

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.

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

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

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 y Tom 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

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

Tabla 2. Diferencias entre metodologías ágiles y no ágiles

Requerimientos

Diseño

Desarrollo

Pruebas

Mantenimiento

Requerimientos

Diseño

Desarrollo

Pruebas

Mantenimiento

Requerimientos

Diseño

Desarrollo

Pruebas

Mantenimiento

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

ID Orden Estimado Descripcíon Criterio Validació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

¿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%.

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

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 Is The Reality Of Agile For Most Organizations Today. 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