1. Ing.Wilfredo Montero Mogollón

2.  Conocidos anteriormente como Metodologías Livianas, los
procesos ágiles de desarrollo de software evitan los tortuosos
y burocráticos caminos de las metodologías tradicionales y se
enfocan en la gente y los resultados.

3.  Minimizar la cantidad de esfuerzo y tiempo gastados en
construir modelos que sólo servirán como documentación.
 Asegurar que el software entregado funciona para los
usuarios.
 Permitir que el proyecto se adapte de manera flexible e
inmediata a los cambios originados por tecnologías y/o
requisitos.

4.  Programación extrema (XP)
 Metodologías Crystal
 SCRUM
 Desarrollo de software adaptativo
 Desarrollo guiado por características (FDD)
 Metodología de desarrollo de sistemas dinámicos (DSDM)

5.  Retrasos y desviaciones en la planificación.
 Coste de mantenimiento elevados.
 Alta tasa de defectos.
 Requisitos mal comprendidos.
 Cambios de negocio.
 Falsa riqueza de características.
 Cambios de personal.

6.  Retrasos y desviaciones: versiones cortas.
 Cancelan el proyecto: entregas
periódicas.
 Sistemas deteriorados y defectos:
pruebas continuas.
 Requisitos mal comprendidos: cliente
dentro del equipo.
 Cambios de negocio: versiones cortas.
 Falsa riqueza de características: realizar
tareas prioritarias.
 Cambios de personal: anima el contacto y
la integración.

7.  “Un proceso ligero, de bajo riesgo, flexible, predecible,
científico y divertido de desarrollar software”.
 Kent Beck
 (Extreme Programming Explained)

8.  Metodología creada a base de prueba y error.
 Surge considerando 5 valores que pueden mejorar cualquier
proyecto de software: Simplicidad, Comunicación,
Realimentación, Coraje, Respeto.
 Expresada en forma de 12 prácticas (algunas ya existentes
desde hace años), que se soportan las unas a las otras y
conforman un conjunto completo.

9.  Codificar
 Es necesario codificar y plasmar nuestras ideas a través del código.
 Hacer pruebas
 Las pruebas dan la oportunidad de saber si lo implementado es lo que en
realidad se tenía en mente
 Escuchar
 Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo
deseado, y tenemos que preguntar a quien necesita la información.
 Diseñar
 Los diseños deben de ser sencillos, si alguna parte del sistema es de
desarrollo complejo, lo apropiado es dividirla en varias.

10.  Resumiendo las actividades de Xp: Tenemos que codificar
porque sin código no hay programas, tenemos que hacer
pruebas por que sin pruebas no sabemos si hemos acabado de
codificar, tenemos que escuchar, porque si no escuchamos no
sabemos que codificar ni probar, y tenemos que diseñar para
poder codificar, probar y escuchar indefinidamente

11.  Simplicidad: XP propone el principio de hacer la cosa más
simple que pueda funcionar, en relación al proceso y la
codificación. Es mejor hacer algo simple hoy, que hacerlo más
complicado hoy y probablemente nunca usarlo.
 Comunicación: Algunos problemas en los proyectos tienen su
origen en que alguien no dijo algo a alguien más sobre algo
importante en algún momento. XP hace casi imposible la falta
de comunicación.

12.  Realimentación: retroalimentación concreta y frecuente del
cliente, del equipo y de los usuarios finales da una mayor
oportunidad de dirigir el esfuerzo.
 Coraje: se requiere coraje para confiar en que la retroalimentación
durante el camino es mejor que tratar de adivinar todo con
anticipación. Se requiere valor para comunicarse con los demás
cuando eso podría exponer la propia ignorancia. Se requiere valor
para mantener el sistema simple, dejando para mañana las
decisiones de mañana.Y, sin un sistema simple, sin comunicación
constante, sin retroalimentación y respeto, es difícil ser valeroso.
 Respeto: El equipo debe trabajar como uno, sin hacer decisiones
repentinas.

13.  Retroalimentación a escala fina:
 Desarrollo guiado por pruebas
 Planificación iterativa
 Cliente como parte del equipo
 Programación en pares
 Proceso continuo:
 Integración continua
 Refactorización
 Liberación pequeña, entregas frecuentes

14.  Entendimiento compartido:
 Diseño simple
 Metáforas del sistema
 Propiedad colectiva del código
 Estándares de codificación
 Bienestar del programador:
 Ritmo sostenible (Semanas de 40 horas)
 Cliente en el Sitio

16.  Fase de la exploración:
 En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de interés para la primera entrega del producto. Al mismo tiempo el equipo
de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto.
 Fase del planeamiento:
 se priorizan las historias de usuario y se acuerda el alcance del release. Los
programadores estiman cuánto esfuerzo requiere cada historia y a partir de allí
se define el cronograma. La duración del cronograma del primer release no
excede normalmente dos meses. La fase de planeamiento toma un par de días.
Al final de la última iteración el sistema esta listo para producción.

17.  Fase de producción:
 Requiere prueba y comprobación extra del funcionamiento del sistema antes de
que éste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden
todavía ser encontrados y debe tomarse la decisión de si se incluyen o no en el
release actual.
 Fase de mantenimiento:
 Requiere de un mayor esfuerzo para satisfacer también las tareas del cliente. Así, la
velocidad del desarrollo puede desacelerar después de que el sistema esté en la
producción.
 Fase de muerte:
 Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema.

18.  Programador (Programmer)
 Responsable de decisiones técnicas
 Responsable de construir el sistema
 Sin distinción entre analistas, diseñadores o
codificadores
 En Xp, los programadores diseñan, programan y
realizan las pruebas

19.  Cliente (Customer)
 Es parte del equipo
 Determina qué construir y cuándo
 Escribe tests funcionales para determinar cuándo está
completo un determinado aspecto

20.  Entrenador (Coach)
 El líder del equipo - toma las decisiones importantes
 Principal responsable del proceso
 Tiende a estar en un segundo plano a medida que el equipo madura

21.  Rastreador (Tracker)
 Metric Man
 Observa sin molestar
 Conserva datos históricos

22.  Probador (Tester)
 Ayuda al cliente con las pruebas funcionales
 Se asegura de que los tests funcionales se ejecutan

27.  Algunas de las críticas recopiladas de Xp son:
 Xp tiene muchas críticas contra la programación por parejas por parte de
muchos programadores, piensan que ellos son los mejores conocedores
de las herramientas y lenguajes que utilizan y que si alguien no lo entiende
es por que no sabe lo suficiente.
 También se critica el mito de las 40 horas semanales ya que es un lujo para
las exigencias del mercado.
 También hay críticas hacia Xp que dicen que solo puede funcionar con
programadores muy buenos.
 Xp es mas una filosofía de trabajo que una metodología.
 Xp esta diseñado para grupos de pequeños programadores, más de 10 ya
seria muy complicado.

28.  http://www.extremeprogramming.org/
 http://www.programacionextrema.org/
 http://www.jera.com/techinfo/xpfaq.html
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
http://clabs.org/caseforxp.htm
http://ootips.org/xp.html
http://www.bobjectsinc.com/cstug/xpslides/
http://www.xp123.com/
http://c2.com/cgi/wiki?XpGlossary