Metodología Ágil El Manifiesto de la metodología Ágil

Universidad “Gran Mariscal de Ayacucho”
Ingeniería de Sistemas
Dirección de Operaciones I
Participantes:
Montes, Kimberlys
Mosquera, Johanbert
Suarez, Ocnelis
Metodología Ágil
Metodología Ágil
Las metodologías ágiles forman parte del movimiento de
desarrollo
ágil
adaptabilidad
de
de
software,
cualquier
que
cambio
se
como
basan
medio
aumentar las posibilidades de éxito de un proyecto.
en
la
para
¿Para que un método de gestión?
Metodología Ágil
El Manifiesto de la metodología Ágil:
1. Individuo y las iteraciones del equipo de desarrollo sobre el
proceso y las herramientas. (Calidad del profesional del
equipo, Entrega Temprana y Continua)
2. Software funcionando sobre documentación extensiva.
3. La colaboración con el cliente sobre negociación contractual.
4. Respuesta ante el cambio sobre seguir estrictamente un plan.
Es importante la derecha pero valoramos más la izquierda
¿Por qué surgen las Metodologías Ágiles?
1. Dificultades
para
implantar
metodologías
tradicionales.
Procesos
ceremoniosos,
herramientas CASE y notaciones de modelado
sofisticadas (UML)
2. Una solución a medida para un segmento
importante de proyectos de desarrollo de
software
3. “Aceptar el cambio” ...
¿Cuándo utilizar una Metodología Ágil?
- Sus clientes no tienen una idea firme de lo que el
sistema debe hacer.
- Sistemas cuya funcionalidad se espera que cambie
cada pocos meses.
- Si los clientes necesitan un nuevo sistema en una fecha
específica.
Comparación Ágil v/s Tradicional
Metodología Ágil
No existe un contrato tradicional, debe ser bastante
Metodología Tradicional
Existe un contrato prefijado
flexible
Cliente es parte del equipo de desarrollo (además in-
El cliente interactúa con el equipo de desarrollo
situ)
mediante reuniones
Orientada a proyectos pequeños. Corta duración (o
Aplicables a proyectos de cualquier tamaño, pero
entregas frecuentes), equipos pequeños (< 10
suelen ser especialmente efectivas/usadas en
integrantes) y trabajando en el mismo sitio
proyectos grandes y con equipos posiblemente
dispersos
La arquitectura se va definiendo y mejorando a lo
Se promueve que la arquitectura se defina
largo del proyecto
tempranamente en el proyecto
Énfasis en los aspectos humanos: el cliente y el
Énfasis en la definición del proceso: roles, actividades
trabajo en equipo
y artefactos
Se esperan cambios durante el proyecto
Se espera que no ocurran cambios de gran impacto
durante el proyecto
Programación Extrema
Antecedentes e Historia de
Programación extrema
Antecedentes e Historia de
Programación extrema
En 1989, Cunningham formó un
equipo que usaba los principios y
muchas de las prácticas que
después adoptaría XP, mientras
trabajaba
para
la
compañía
“Wyatt Software” [Fowler 2000].
Sin embargo, se reconoce a
Kent Beck como el que
articuló esta propuesta y le
dio nombre propio.
Kent Beck
Antecedentes e Historia de
Programación extrema
+ Los autores de la Programación Extrema, crearon el
sitio web Portland Pattern Repository y empezaron a
hablar de ella y promocionarla, de lo que era y cómo
realizarla. Estos propulsores de la XP hablaban de ella
en cada ocasión que tenían y en cada página que, poco o
mucho hablara de temas de programación.
Portland Pattern Repository
- ¿Qué es XP?
- Características
Costo del cambio
Justificación y fundamentos de XP
Requerimientos
Análisis
Diseño
Implementación
Prueba
Fig. 1 Relación del costo del cambio contra las etapas del ciclo de vida
(adaptado de Beck, 1999)
Producción
Principios, roles y prácticas
de Programación extrema
Principios de la Programación extrema
Se busca :
1.Realimentación rápida
2.Asumir la simplicidad
3.Cambio incremental
4.Aceptar el cambio
5.Hacer trabajo de calidad.
Prácticas XP
1. El juego de la planificación
PLANIFICACION
2. Entregas pequeñas
3. Metáfora
DISEÑO
4. Diseño simple
5. Recodificación
6. Programación en parejas
7. Propiedad colectiva
CODIFICACION
8. Integración continua
9. Semana de 40 horas
10. Cliente in situ
11. Estándares de programación
PRUEBAS
12. Pruebas
Las cuatro actividades básicas
1.Codificar
2.Hacer pruebas
3.Escuchar
4.Diseñar.
Roles de XP
Cliente
 Elabora especificaciones de los requerimientos
iniciales.
Programador
 Responsable de diseñar, codificar, probar e integrar
el producto de software.
Administrador
 Responsable de coordinador de las actividades de
desarrollo y asegurar su cumplimiento.
Los cuatro valores
Valores para desarrollar software:
1.Comunicación
2.Sencillez
3.Retroalimentación
4.Valentía.
Objetivos de XP
Son:
1. La satisfacción del cliente.
2. Potenciar el trabajo en grupo, todos están involucrados en el
desarrollo del software.
Ventajas
+ Da lugar a una programación
sumamente organizada.
+ Ocasiona eficiencias en el
proceso de planificación y
pruebas.
+ Cuenta con una tasa de
errores muy pequeña.
+ Propicia la satisfacción del
programador.
Desventajas
+ Es recomendable emplearla
solo en proyectos a corto
plazo.
+ En caso de fallar, las
comisiones son muy altas.
+ Requiere de un rígido ajuste
a los principios de XP.
+ Puede no siempre ser más
fácil que el desarrollo
tradicional.
CONCLUSIONES
+ La programación extrema es una forma ligera, eficiente, flexible, científica y
divertida de generar software.
+ La programación extrema se beneficia de la existencia de un gran número de
herramientas de software libre que permiten aplicarla con gran productividad.
+ El software libre se inspira en algunas de las prácticas de la XP .
+ Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado,
evitando que se desmoralice por no saber como preparar pruebas de aceptación.
+ Permite identificar historias adicionales que no fueran obvias para el cliente o en las
que cliente no hubiese pensado de no enfrentarse a dicha situación.
Ciclo
GRACIAS