Programacion Extrema

Maestría en Ingeniería de Sistemas con Mención en Gestión En Tecnología de la Información

Ingeniería de Software

LIMA - 2007

Esta situación resulta conocida……???

Fuerzas que influyen en los enfoques para el desarrollo de software

Grado de Grado de Control Control

en el procesoen el proceso

TiempoTiempo

1950’s1950’s 1960’s1960’s 1970’s1970’s 1980’s1980’s 1990’s1990’s 2000’s2000’s 2010’s2010’s

Fuente: Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

Metodología ÁgilMetodología Ágil

Metodología Ágil

Las metodologías ágiles forman parte del

movimiento de desarrollo ágil de software, que se

basan en la adaptabilidad de cualquier cambio

como medio para aumentar las posibilidades de

éxito de un proyecto.

Metodología Ágil

El Manifiesto de la metodología Ágil:

+ Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.

+ Desarrollar software que funciona más que conseguir una buena documentación.

+ La colaboración con el cliente más que la negociación de un contrato.

+ Responder a los cambios más que seguir estrictamente un plan.

Es importante la derecha pero valoramos más la izquierda

¿Qué es una Metodología Ágil?

1. Las Metodologías Ágiles (MAs) valoran:1. Al individuo y las interacciones en el equipo de

desarrollo más que a las actividades y las herramientas

2. Desarrollar software que funciona más que conseguir una buena documentación Minimalismo respecto del modelado y la documentación del sistema

3. La colaboración con el cliente más que la negociación de un contrato

4. Responder a los cambios más que seguir estrictamente una planificación

¿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.Pugna entre comunidades/gurús

4.“Aceptar el cambio” ...

¿Cuándo utilizar una Metodología Ágil?

¿Tienes ya un proceso? No

+ existe pero no reacciona bien a los

cambios

+ existe pero el equipo no está contento

con él

Una Metodología Ágil puede ser una buena

forma de empezarNo involucra gran inversiónA los programadores les (suele)

gustarA los clientes les ofrece mayor

visibilidad y menor riesgo en el

proyecto

Comparación Ágil v/s Tradicional

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

Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran

impacto durante el proyecto

Costo de los Cambios en SW

Costodel

cambio

tiempo

Tradicional

Suposición MAs

Principales MAs

+Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org

+SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com

+DSDM (Dynamic Systems Development Method), www.dsdm.org

+Lean Programming, Mary Poppendieck, www.poppendieck.com

+FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd

+Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com

+Adaptative Software Development, Jim Highsmith www.adaptivesd.com

Programación ExtremaProgramación Extrema

Antecedentes e Historia de Programación extrema

Sin embargo, se reconoce a Kent Beck como el que articuló esta propuesta y le dio nombre propio.

Kent Beck

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


+ Posteriormente, la consolidación de XP se logra

con la publicación del libro “Extreme

Programming Explained: embrace change” en el

año 1999, donde Beck resume su propia

experiencia y le da forma y nombre a la

entonces nueva metodología de desarrollo de

software, la cual le valió el premio: “Software

Development Jolt Product Excellence”.


+ Chrysler Corporation hacía tiempo que estaba

desarrollando una aplicación de nóminas, pero

sin demasiado éxito por parte de la gente que

tenía en el proyecto. El verano de 1996, Beck

entró en nómina en la compañía y se le pidió de

hacer esta aplicación como trabajo. Es en esta

aplicación cuando nace la Programación

Extrema como tal.


+ Las ideas primordiales de su sistema las

comunicó en la revista C++ Magazine en una

entrevista que ésta le hizo el año 1999. En ésta

decía que él estaba convencido que la mejor

metodología era un proceso: Que enfatizase la comunicación del equipo. Que la implementación fuera sencilla. Que que el usuario tenía que estar muy

informado e implicado. Que la toma de decisiones tenía que ser muy

rápida y efectiva.


+ 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?

+ La programación extrema es una metodología

de desarrollo ligera basada en una serie de

valores y una docena de prácticas que propician

un aumento en la productividad a la hora de

generar software.

+ XP permite controlar los problemas de riesgo en

los proyectos.

+ XP permite la participación de pequeños grupos

de programadores.

+ XP requiere un variado equipo de desarrollo.

+ XP permite la capacidad de hacer pruebas

+ La meta real de XP es entregar el software

requerido a tiempo.

¿Que es XP?

+ Las características generales de XP es

deliberadamente una metodología “liviana” que

pasa por alto la utilización de elaborados casos

de uso, la exhaustiva definición de

requerimientos y la producción de una extensa

documentación.

+ Todo lo anterior puede parecer caótico según el

enfoque tradicional de la ingeniería de

software, aunque no hay que olvidar que XP

tiene asociado un ciclo de vida y es considerado

a su vez un proceso.

+ La tendencia de entregar software en lapsos

cada vez menores de tiempo y con exigencias

de costos reducidos y altos estándares de

calidad, hace que XP sea una opción a

considerar.

Características de XP

ImplementaciónRequerimientos Análisis Diseño Prueba Producción

Fig. 1 Relación del costo del cambio contra las etapas del ciclo de vida(adaptado de Beck, 1999)

Cos

to d

el c

ambi

oJustificación y fundamentos de XP


Fig. 2 Costo del cambio modificado por la aplicación de técnicas adecuadas(adaptado de Beck, 1999)

Cos

to d

el c

ambi

oJustificación y fundamentos de XP

Enfoque Tradicional vs. XP


Enfoque Tradicional

Programación Extrema

$$

t


Enfoque Tradicional

Programación Extrema

$$

t

Principios, roles y prácticas de Programación extrema

Principios de la Programación extrema

Se busca :

• Realimentación rápida

• Asumir la simplicidad

• Cambio incremental

• Aceptar el cambio

• Hacer trabajo de calidad.


Las Prácticas son:

1. El juego de la planificación

2. Pequeñas entregas

3. Metáfora

4. Diseño simple

5. Pruebas

6. Refactorización


7. Programación por parejas

8. Propiedad colectiva

9. Integración continua

10. 40 horas semanales

11. Cliente en casa

12. Estándares de codificación.

Objetivos de la Programación extrema

Objetivos de XP

Son:

+ La satisfacción del cliente.

+ Potenciar el trabajo en grupo, todos

están involucrados en el desarrollo del

software.

Interacción entre Las cuatro variablesde Gestión de proyecto

Permite mejorar la calidad, siempre que resuelva el problema básico del cliente. Tambien permite reducir plazo y coste. La herramienta más potente de gestión (*)

Si poco, sufrirá la calidad e inmediatamente detrás el alcance, el tiempo y el coste.

Con poco dinero será imposible resolver los problemas del cliente.

Variable terrible de control. Se puede sacrificar para obtener ganancias a corto, pero los costes posteriores son enormes (humanos, de negocio ytécnicos).

I nsistir en mayor calidad permite conseguir plazos menores o hacer más en un tiempo dado. Efecto humano: se trabaja mejor si se siente que se hace un buen trabajo.

Más dinero puede engrasar el sistema, pero en exceso puede crear más problemas que los que resuelve.

Más puede mejorar calidad y alcance, pero en exceso puede dañar, pues la mejor realimentación viene del sistema en producción.

Si aumenta en exceso... Si se reduce...Variable

Alcance

Tiempo

Coste

Calidad

El coste de Cambio

+El coste de los cambios

crece con el tiempo.

+XP propone que los costes

de los cambios no tienen

por que aumentar con el

tiempo.C

OS

TE

TIEMPO

CO

ST

E

TIEMPO

Las cuatro valores

Valores para desarrollar software:

1.Comunicación

2.Sencillez

3.Retroalimentación

4.Valentía.

Roles de XP

Cliente Escribe “Historias de Usuario” y especifica

Pruebas Funcionales. Establece prioridades, explica las Historias Puede ser o no un usuario final Tiene autoridad para decidir cuestiones

relativas a las Historias.Programador

Hace estimaciones sobre las Historias Define Tareas a partir de las Historias y hace

estimaciones Implementa las Historias y las Pruebas

Unitarias

Roles de XP

Tutor Observa todo, identifica señales de peligro, se

asegura que el proyecto se mantiene en curso Ayuda en todo Da avisos cuando se necesita.

Perseguidor (calidad) Monitoriza el progreso de los programadores,

toma acción si las cosas tienden a salirse de su senda.

Las acciones incluyen reuniones con el Cliente, solicitar ayuda al Tutor u otro Programador.

Roles de XP

Verificador Implementa y corre las Pruebas Funcionales

(no Pruebas Unitarias) Presenta gráficas de los resultados y se

asegura de que la gente conoce cuándo los resultados empiezan a decaer.

“Agorero” Se asegura que todos conocen los riesgos que

existen Se asegura que las malas noticias no se

ocultan, se disculpan o se reducen de proporción.

Roles de XP

Gestor Planifica las reuniones (por ej., plan de

iteraciones, plan de lanzamientos releases), se asegura que el proceso de las reuniones se sigue, anota los resultados de la reunión para futuros informes y los pasa al Perseguidor.

Posiblemente responsable ante el “Propietario de Oro”

Asiste a las reuniones, aporta información útil anterior.

“Propietario de Oro” La persona que paga el proyecto, que puede

ser o no la misma que el Cliente.

Las cuatro actividades básicas

1.Codificar

2.Hacer pruebas

3.Escuchar

4.Diseñar.

Proceso de Desarrollo

Artefactos esenciales en XP

+Historias del Usuario

+Tareas de Ingeniería

+Pruebas de Aceptación

+Pruebas Unitarias y de Integración

+Plan de la Entrega

+Código

Historia de Usuario

Historia de Usuario

Número: 1 Nombre: Enviar artículo

Usuario: Autor

Modificación de Historia Número: Iteración Asignada: 2

Prioridad en Negocio: Alta

(Alta / Media / Baja) Puntos Estimados:

Riesgo en Desarrollo:

(Alto / Medio / Bajo) Puntos Reales:

Descripción:

Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los

autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de

contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al

autor de contacto con un userid y password para que el autor pueda posteriormente

acceder al artículo.

Observaciones:

Spike para Historia de Usuario

Tarea de Ingeniería

Tarea

Número tarea: Número historia:

Nombre tarea:

Tipo de tarea :

Desarrollo / Corrección / Mejora / Otra Puntos estimados:

Fecha inicio: Fecha fin:

Programador responsable:

Descripción:

Prueba de Aceptación

Caso de Prueba

Número Caso de Prueba: Número Historia de Usuario:

Nombre Caso de Prueba:

Descripción:

Condiciones de ejecución:

Entradas:

Resultado esperado:

Evaluación:

Escenarios en XP : Exploración

Historias de Usuario

Prioridad RiesgoEsfuerzo (puntos)

Spikes (Bosquejos)

DefinirHistorias

de Usuario

ElaborarSpikes

Estimar Esfuerzo y Riesgo

?

Escenarios en XP: Planificación de la Entrega

Historias de Usuario

PrimeraIteración

SegundaIteración

ÚltimaIteración

…

N-ésimaIteración

Historiasfuera de la

entrega

Velocidad de Proyecto (VP)

puntos/semana

Entrega<= 3 meses

2 a 3semanas

Escenarios en XP : Comenzar Iteración

Historias de laIteración

Definir y ordenar

Tareas deIngeniería

Tareas de la iteración

Escenarios en XP : Programación

Pruebas deAceptación

de Historias de la iteración

Programaciónen Parejas

Tareas de Historias dela iteración

Historias de laIteración

Versión delProducto

DiseñoRefactoring

ProgramaciónPruebas Unitarias

IntegraciónPruebas de IntegraciónPruebas de Aceptación

Escenarios en XP : Pruebas de Aceptación

Pruebas deAceptación

Definir Pruebasde Aceptación

Aplicar Pruebasde Aceptación

Corregir erroresDefinir nuevas Historias

Entorno y clima de trabajo Espacio de trabajo XP

+ Espacio abierto

+ Mesas centrales

+ Cubículos en el espacio exterior

Espacio de trabajo del proyecto C3 de DaimlerChrysler

+ Reunión diaria: “Stand-up Meeting”

+Todo el equipo

+Problemas

+Soluciones

+De pie en un círculo

+Evitar discusiones largas

+Sin conversaciones separadas

… Entorno y clima de trabajo

Reunión diaria XP

… Entorno y clima de trabajo Gantt de Pared

Obtenida de www.agiletek.com

“Centro del universo del proyecto”

“Punto de reunión para la “Stand-up Meeting”

Fases de la metodología XP

Como hacemos funcionar la Metodología XP

PRUEBA

DISEÑO

CODIFICACION

PLANIFICACION

Historias del usuario

valores

Criterios de las pruebas de iteración

Plan de iteración

Diseño simple

Programación en pareja

prototiposCartas CRC

Integración continua

Prueba de unidad

Pruebas de aceptación

Incremento de software Velocidad calculada del proyecto

Lanzamiento

recodificación

Soluciones pico

Planificación

XP plantea la planificación como un permanente

dialogo entre las partes la empresarial (deseable)

y la técnica (posible).

deseable posible

… Planificación

.1 El Juego de la Planificación

Negocio

Ámbito ¿Qué debe resolver el software?

Prioridad ¿Qué debe ser echo en primer

lugar?

Composición de versiones ¿Cuánto es

necesario hacer para aportar valor?

Fechas de versiones ¿Fechas para

presencia del software?

… Planificación

.1 El Juego de la Planificación

Técnico.

Estimaciones ¿Cuánto lleva implementar

una característica?

Consecuencias, informar sobre

consecuencias de las decisiones que

adopta el negocio.

Procesos ¿Cómo se organiza el trabajo

en el equipo?

Programación detallada: En una versión

¿Qué se resolverá primero?

… Planificación

.2 Pequeñas versiones.

Cada versión debe de ser tan pequeña

como fuera posible, conteniendo los

requisitos de negocios más importantes,

las versiones tiene que tener sentido como

un todo..3 Metáfora.

Es una historia que todo el mundo puede

contar a cerca de cómo funciona el sistema.

Diseño

.4 Diseño simple.

El diseño adecuado par el software es

aquel que:

1.Funciona con todas las pruebas.

2.No tiene lógica duplicada.

3.Manifiesta cada intención importante

para los programadores

4.Tiene el menor número de clases y

métodos.

Codificación

.5 Recodificación.

Este proceso se le denomina recodificar o

refactorizar (refactoring).y consiste en

hacer el programa mas simple sin perder

funcionalidad.

No debemos de recodificar ante

especulaciones si no solo cuándo el sistema

te lo pida.

… Codificación

.6 Programación por parejas.

Todo el código de producción se escribe

con dos personas mirando a una máquina,

con un solo teclado y un solo ratón.

Cada miembro de la pareja juega su papel:

uno codifica en el ordenador y piensa la

mejor manera de hacerlo, el otro piensa

mas estratégicamente, ¿Va a funcionar?,

¿Puede haber pruebas donde no funcione?,

¿Hay forma de simplificar el sistema global

para que el problema desaparezca?.

… Codificación

.7 Propiedad Colectiva.

Cualquiera que crea que puede aportar

valor al código en cualquier parcela puede

hacerlo, ningún miembro del equipo es

propietario del código.

.8 Integración continúa.

El código se debe integrar como mínimo

una vez al día, y realizar las pruebas sobre

la totalidad del sistema.

… Codificación

.9 Cuarenta horas.

Si queremos estar frescos y motivados

cada mañana y cansado y satisfecho cada

noche. del sistema.

.10 Cliente In Situ.

Un cliente real debe sentarse con el equipo

de programadores, estar disponible para

responder a sus preguntas, resolver

discusiones y fijar las prioridades.

… Codificación

.11 Estándares de Codificación.

Se debe establecer un estándar de

codificación aceptado e implantado por

todo el equipo.

Pruebas

.12 Hacer pruebas.

Toda característica en el programa debe

ser probada, los programadores escriben

pruebas para chequear el correcto

funcionamiento del programa, los clientes

realizan pruebas funcionales. El resultado

un programa mas seguro que soporte

cambios en el tiempo.

1. El juego de la

planificación

2. Entregas pequeñas

3. Metáfora

4. Diseño simple

5. Recodificación

6. Programación en parejas

7. Propiedad colectiva

8. Integración continua

9. Semana de 40 horas

10.Cliente in situ

11.Estándares de

programación

12.Pruebas

Prácticas XP

DISEÑO

CODIFICACION

PLANIFICACION

PRUEBAS

… Prácticas XPInteracción entre Prácticas

XP: Kent Beck

Cliente in situ

Metáfora

Propiedad Colectiva Integración Continua

El juego de la planificaciónSemana

de 40 horas

Programación en parejas

Recodificación

Estándares deprogramación

Pruebas

Diseño simple

Pequeñas versiones

Aspectos sobre Programación Extrema

Aspectos Positivos De Xp

+Pruebas unitarias en el código factor clave para obtener un software de alta calidad.

+La integración continua es aceptada y recomendada para evitar catástrofes ocasionadas por defectos no detectados a tiempo.

+ la simplicidad y la refabricación es encontrado como un factor saludable en la práctica de programación.

+El enfoque “extremadamente humano”, siendo este un aspecto que el resto del campo del software debería tratar de emular.

+Cliente también se percibe el enfoque humano, ya que tenemos su presencia constante en las instalaciones del desarrollador.

Aspectos Controversiales de Xp

+La XP se ha afirmado que no es la metodología que

va a resolver todos los problemas en IS y se han

resaltado sus limitaciones.

+No es aconsejable XP si no es posible disminuir la

curva costo/tiempo.

+Tampoco si la tecnología o el entorno no permiten

realizar integraciones frecuentes o realizar

pruebas continuamente.

+No se recomienda intentar XP si la distribución

física impide la programación en pares o si no

todos los programadores se encuentran en el

mismo sitio.

+Desalienta el diseño, que es débil en la

documentación, que el modelo no aplica para

proyectos donde la seguridad es crítica.

+Exceso de pruebas retrasa el desarrollo, el diseño

simple solo aplica a proyectos simples, que la

programación en pares consume mayor tiempo y

recursos.

+XP asume implícitamente que siempre se utiliza el

enfoque de programación orientada a objetos.


+La refabricación, como sinónimo de rediseño

constante y que se puede tomar como una excusa

para relegar hasta el último minuto el diseño.

+La planeación, según algunos críticos, no debería

hacerse “sobre la marcha” como parece

recomendar XP.

+La programación en pares. Se argumenta que no

cualquier “clase” de programador desea trabajar

de esta manera.

+Beneficios, tales como: producir menos defectos,

aumentar la productividad, elevar la moral del

equipo, mejorar la confianza y el trabajo en

equipo, naturalidad en la transferencia del

conocimiento y favorecer el aprendizaje.


Posturas A Favor Y En Contra

0 10 20 30 40 50 60

Lo he probado y no me gusta nada

Es una mala idea, no puede funcionar nunca

Es una buena idea, pero no f uncionará

Lo he probado y me gusta mucho

Extrapolación De Las Prácticas De Xp

+XP adecuada para proyectos de software pequeños o

cuando mucho medianos.

+Diseño al inicio: Aquí se recomienda un buen diseño

inicial (up-front) que respalde al proyecto.

+Se producen funcionalidades completas en cada

iteración (entrega) durante el ciclo del software. El

tiempo entre cada entrega es corto.

Extrapolación De Las Prácticas De Xp (Cont..I)

+Se simula al cliente en las instalaciones, en lugar de

ser un cliente real como dice XP, este rol lo asume

alguien con experiencia.

+Programación en pares flexible. Se modifica la

práctica de XP y en lugar de ser obligatoria para todo

el código que se escribe.

+Selección y administración del equipo de desarrollo.

Se buscan diferentes habilidades y experiencias en los

programadores.

BENEFICIOS

+Satisfacción del cliente.

+Cumplimiento de plazos.

+El cliente tiene el control sobre las prioridades.

+Se hacen pruebas continuas durante el proyecto.

+Calidad en el trabajo.

+La XP es mejor utilizada en la implementación de

nuevas tecnologías donde los requerimientos

cambian rápidamente.

CONCLUSIONES

+La programación extrema es una forma ligera,

eficiente, flexible, predecible, 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 .

CONCLUSIONES Cont.. (II)

+Aprovecha el tiempo de los clientes y ayuda a que

un cliente se sienta integrado, evitando que se

desmoralice por no sabe como preparar pruebas

de aceptación.

+El proceso de desarrollo de las pruebas ayuda al

cliente a clarificar y concretar la funcionalidad de

la historia de uso y favorece la comunicación

entre el cliente y el equipo de desarrollo.

+El desarrollo de pruebas ayuda identificar y

corregir fallos u omisiones en las historias de uso.

CONCLUSIONES Cont.. (III)

+Permite corregir errores en las ideas del cliente, por

ejemplo encontrando resultados que el cliente espera

encontrar en la implementació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.

+Garantiza la cobertura de la funcionalidad de las

pruebas de aceptación, garantizando que no se deja

ningún punto importante de la funcionalidad de una

historia de uso sin probar.

RECOMENDACIONES

+Algunas prácticas podrán ser controversiales y

hasta contraproducentes fuera de un dominio

específico. Las metodologías ágiles se recomiendan.

Para proyectos y equipos pequeños.

+Requerimientos cambiantes (enfoque evolutivo).

+Equipo de desarrollo competente.

+Cliente dispuesto a participar con el equipo.

+El proceso como una manera de agilizar el Proceso

Unificado, combinándolo con la XP.

BIBLIOGRAFÍA

+ Una explicación de la Programación extrema: aceptar el cambio

Autor: Kent Beck. Publicado: Addison-Wesley Iberoamericana

Espanya, S.A. – 2002.

+ La Programación Extrema en la práctica Autor: James Newkirk,

Robert C. Martin. Publicado: Addison-Wesley Iberoamericana

Espanya, S.A. – 2002.

+ Extreme Programming Installed. Autor: Ron Jeffries, Ann

Anderson, Chet Hendrickson, Ronald E. Jeffries. Publicado:

Addison-Wesley Pub Co; 1 edición (13 Octubre 2000).

+ Extreme Programming Explained: Embrace Change. Autor: Kent

Beck.Publicado: Addison-Wesley Pub Co; 1 edición (5 Octubre

1999).

BIBLIOGRAFÍA

+ Extreme Programming Pocket Guide. Autor: chromatic.

Publicado: O'Reilly & Associates; 1 edición (Junio 2003).

+ Extreme Programming Refactored: The Case Against XP. Autor:

Matt Stephens, Doug Rosenberg. Publicado: APress; (1 Enero

1970).

+ Planning Extreme Programming. Autor: Kent Beck, Martin

Fowler. Publicado: Addison-Wesley Pub Co; 2000

Referencias Web

+Sitio Extreme Programming: A Gentle Introduction.

www.extremeprogramming.org

+Secciones “Artículos” y “Roadmap” del sitio de la Agile Alliance.

www.agilealliance.org

+Sitio Xprogramming, mantenido por Ron Jeffries.

www.xprogramming.com

+WikiWiki de Extreme Programming http://c2.com/cgi/wiki?

ExtremeProgrammingRoadmap

+Revista electrónica Software Development. www.sdmagazine.com

+Número monográfico de revista CrossTalk: Agile Software

Development. www.stsc.hill.af.mil/crosstalk/2002/10/

+Una extensiones de XP, Agile+. www.agiletek.com

+Sitios de modelado ágil, mantenidos por Scott W. Ambler.

www.agilemodeling.com y www.agiledata.org

+Refactoring, mantenido por Martin Fowler. www.refactoring.com

+Pruebas en contexto ágil, www.junit.org

+International Conference on eXtreme Programming and Agile Methods

in Software Development (XP200x) http://www.xp2004.org

+XP Agile Universe http://www.agileuniverse.com

Ejemplo de Programador Extremo

GRACIAS

Programacion Extrema

Travel