Maestra en Ingeniera de Sistemas con Mencin en Gestin En Tecnologa de la Informacin

Ingeniera de Software

LIMA - 2007

Esta situacin resulta conocida???

Fuerzas que influyen en los enfoques para el desarrollo de software

Grado de Control en el proceso

Tiempo 1950s 1960s 1970s 1980s 1990s 2000s 2010s

Fuente: Diapositiva obtenida de la presentacin A History of Agile Methods presentada por Alan Davis en JISBD 2002

Metodologa gil

Metodologa gil
Las metodologas giles forman parte del movimiento de
desarrollo gil de de software, que se como basan medio en la adaptabilidad cualquier cambio para

aumentar las posibilidades de xito de un proyecto.

Metodologa gil
El Manifiesto de la metodologa gil: 1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. 2. Desarrollar software que funciona ms que conseguir una buena documentacin. 3. La colaboracin con el cliente ms que la negociacin de un contrato. 4. Responder a los cambios ms que seguir estrictamente un plan. Es importante la derecha pero valoramos ms la izquierda

Qu es una Metodologa gil?

1. Las Metodologas giles (MAs) valoran: 1. Al individuo y las interacciones en el equipo de desarrollo ms que a las actividades y las herramientas 2. Desarrollar software que funciona ms que conseguir una buena documentacin Minimalismo respecto del modelado y la documentacin del sistema 3. La colaboracin con el cliente ms que la negociacin de un contrato 4. Responder a los cambios ms que seguir estrictamente una planificacin

Por qu surgen las Metodologas giles?

1. Dificultades para implantar metodologas tradicionales. Procesos ceremoniosos, herramientas CASE y notaciones de modelado sofisticadas (UML)

2. Una solucin a medida para un segmento importante de proyectos de desarrollo de software 3. Pugna entre comunidades/gurs
4. Aceptar el cambio ...

Cundo utilizar una Metodologa gil?

Tienes ya un proceso? No
+ + existe pero no reacciona bien a los cambios existe pero el equipo no est contento con l

Una Metodologa gil puede ser una buena forma de empezar No involucra gran inversin A los programadores les (suele) gustar A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto

Comparacin gil v/s Tradicional

Metodologa gil Pocos Artefactos. El modelado es prescindible, modelos desechables. Pocos Roles, ms genricos y flexibles No existe un contrato tradicional, debe ser bastante flexible Cliente es parte del equipo de desarrollo (adems insitu) Orientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitio La arquitectura se va definiendo y mejorando a lo largo del proyecto nfasis en los aspectos humanos: el individuo y el trabajo en equipo Se esperan cambios durante el proyecto El cliente interacta con el equipo de desarrollo mediante reuniones Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos Se promueve que la arquitectura se defina tempranamente en el proyecto nfasis en la definicin del proceso: roles, actividades y artefactos Se espera que no ocurran cambios de gran impacto Metodologa Tradicional Ms Artefactos. El modelado es esencial, mantenimiento de modelos Ms Roles, ms especficos Existe un contrato prefijado

durante el proyecto

Costo de los Cambios en SW

Tradicional
Costo del cambio

Suposicin MAs
tiempo

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

Programacin Extrema

Antecedentes e Historia de Programacin extrema

Antecedentes e Historia de Programacin extrema

En 1989, Cunningham form un equipo que usaba los principios y muchas de las prcticas que despus adoptara XP, mientras trabajaba para la compaa 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 Programacin extrema

+ Posteriormente, la consolidacin de XP se logra con la
publicacin del libro Extreme Programming Explained: embrace change en el ao 1999, donde Beck resume su

propia experiencia y le da forma y nombre a la

entonces nueva metodologa de desarrollo de software, la cual le vali el premio: Software Development Jolt Product Excellence.

Antecedentes e Historia de Programacin extrema

+ Chrysler Corporation una haca tiempo de que estaba pero sin

desarrollando

aplicacin

nminas,

demasiado xito por parte de la gente que tena en el proyecto. El verano de 1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como trabajo. Es en esta aplicacin cuando nace la

Programacin Extrema como tal.

Antecedentes e Historia de Programacin extrema

+ Las ideas primordiales de su sistema las comunic en la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la mejor metodologa era un proceso: Que enfatizase la comunicacin del equipo.

Que la implementacin fuera sencilla.

Que que el usuario tena que estar muy informado e implicado.

Que la toma de decisiones tena que ser muy rpida

y efectiva.

Antecedentes e Historia de Programacin extrema

+ Los autores de la Programacin Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en cada pgina que, poco o

mucho hablara de temas de programacin.

Portland Pattern Repository

Qu es XP?

Que es XP?
+ La programacin extrema es una metodologa de

desarrollo ligera basada en una serie de valores y una docena de prcticas 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 participacin de pequeos 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.

Caractersticas de XP
+ Las caractersticas generales de XP es deliberadamente una metodologa liviana que pasa por alto la utilizacin

de elaborados casos de uso, la exhaustiva definicin de

requerimientos documentacin. y la produccin de una extensa

+ Todo lo anterior puede parecer catico segn el enfoque

tradicional de la ingeniera 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 estndares de calidad, hace que XP sea una

opcin a considerar.

Justificacin y fundamentos de XP

Costo del cambio

Requerimientos

Anlisis

Diseo

Implementacin

Prueba

Produccin

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

Justificacin y fundamentos de XP

Costo del cambio

Requerimientos

Anlisis

Diseo

Implementacin

Prueba

Produccin

Fig. 2 Costo del cambio modificado por la aplicacin de tcnicas adecuadas (adaptado de Beck, 1999)

Enfoque Tradicional vs. XP

$$ Enfoque Tradicional Programacin Extrema t

Requerimientos Anlisis

Diseo

Implementacin

Prueba

Produccin

Principios, roles y prcticas de Programacin extrema

Principios de la Programacin extrema

Se busca :

1.Realimentacin rpida
2.Asumir la simplicidad 3.Cambio incremental 4.Aceptar el cambio 5.Hacer trabajo de calidad.

Principios de la Programacin extrema

Las Prcticas son: 1. El juego de la planificacin 2. Pequeas entregas

3. Metfora
4. Diseo simple 5. Pruebas 6. Refactorizacin

Principios de la Programacin extrema

7. Programacin por parejas 8. Propiedad colectiva 9. Integracin continua

10. 40 horas semanales

11. Cliente en casa

12. Estndares de codificacin.

Objetivos de la Programacin extrema

Objetivos de XP

Son: 1.La satisfaccin del cliente. 2.Potenciar el trabajo en grupo, todos estn involucrados en el desarrollo del software.

Interaccin entre Las cuatro variables de Gestin de proyecto

Variable Alcance Si aumenta en exceso... Si se reduce...
Permite mejorar la calidad, siempre que resuelva el problema bsico del cliente. Tambien permite reducir plazo y coste. La herramienta ms potente de gestin (*) Ms puede mejorar calidad y alcance, Si poco, sufrir la pero en exceso puede daar, pues la inmediatamente detrs el mejor realimentacin viene del sistema tiempo y el coste. en produccin. calidad alcance, e el

Tiempo

Coste

Ms dinero puede engrasar el sistema, Con poco dinero ser imposible resolver pero en exceso puede crear ms los problemas del cliente. problemas que los que resuelve.

Calidad

Insistir en mayor calidad permite conseguir plazos menores o hacer ms en un tiempo dado. Efecto humano: se trabaja mejor si se siente que se hace un buen trabajo.

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

El coste de Cambio
+ El coste de los cambios crece
COSTE

con el tiempo.

TIEMPO

+ XP propone que los costes de los

COSTE

cambios no tienen por que

aumentar con el tiempo.

TIEMPO

Las cuatro valores

Valores para desarrollar software: 1.Comunicacin 2.Sencillez 3.Retroalimentacin 4.Valenta.

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 seales 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 accin 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 grficas de los resultados y se asegura de que la gente conoce cundo 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 proporcin.

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 reunin para futuros informes y los pasa al Perseguidor. Posiblemente responsable ante el Propietario de Oro Asiste a las reuniones, aporta informacin til anterior. Propietario de Oro La persona que paga el proyecto, que puede ser o no la misma que el Cliente.

Las cuatro actividades bsicas

1.Codificar 2.Hacer pruebas 3.Escuchar 4.Disear.

Proceso de Desarrollo

Artefactos esenciales en XP
+ Historias del Usuario + Tareas de Ingeniera + Pruebas de Aceptacin + Pruebas Unitarias y de Integracin + Plan de la Entrega + Cdigo

Historia de Usuario

Historia de Usuario
Nmero: 1
Usuario: Autor Modificacin de Historia Nmero: Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: (Alto / Medio / Bajo) Descripcin: Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artculo. Observaciones: Iteracin Asignada: 2 Puntos Estimados: Puntos Reales:

Nombre: Enviar artculo

Spike para Historia de Usuario

Tarea de Ingeniera

Tarea
Nmero tarea: Nombre tarea: Nmero historia:

Tipo de tarea : Desarrollo / Correccin / Mejora / Otra

Puntos estimados:

Fecha inicio: Programador responsable: Descripcin:

Fecha fin:

Prueba de Aceptacin
Caso de Prueba
Nmero Caso de Prueba: Nombre Caso de Prueba: Nmero Historia de Usuario:

Descripcin:

Condiciones de ejecucin:

Entradas:

Resultado esperado: Evaluacin:

Escenarios en XP : Exploracin ?
Prioridad
Historias de Usuario Riesgo Esfuerzo (puntos)

Definir Historias de Usuario Estimar Esfuerzo y Riesgo

Elaborar Spikes Spikes (Bosquejos)

Escenarios en XP: Planificacin de la Entrega

Velocidad de Proyecto (VP) puntos/semana Historias de Usuario Primera Iteracin

Segunda Iteracin

N-sima Iteracin

ltima Iteracin

Historias fuera de la entrega

2 a 3 semanas

Entrega <= 3 meses

Escenarios en XP : Comenzar Iteracin

Historias de la Iteracin

Definir y ordenar Tareas de Ingeniera

Tareas de la iteracin

Escenarios en XP : Programacin

Tareas de Historias de la iteracin

Historias de la Iteracin

Refactoring Programacin Pruebas Unitarias Integracin Pruebas de Integracin Pruebas de Aceptacin

Programacin Diseo en Parejas

Pruebas de Aceptacin de Historias de la iteracin

Versin del Producto

Escenarios en XP : Pruebas de Aceptacin

Definir Pruebas de Aceptacin

Pruebas de Aceptacin

Corregir errores Definir nuevas Historias Aplicar Pruebas de Aceptacin

Entorno y clima de trabajo Espacio de trabajo XP

+ Espacio abierto

+ Mesas centrales
+ Cubculos en el espacio exterior

Espacio de trabajo del proyecto C3 de DaimlerChrysler

 Entorno y clima de trabajo Reunin diaria XP

+ Reunin diaria: Stand-up Meeting

+Todo el equipo
+ Problemas + Soluciones +De pie en un crculo + Evitar discusiones largas

+ Sin conversaciones separadas

 Entorno y clima de trabajo Gantt de Pared

Centro del universo del proyecto Punto de reunin para la Stand-up Meeting
Obtenida de www.agiletek.com

Fases de la metodologa XP

Como hacemos funcionar la Metodologa XP

Diseo simple Historias del usuario valores Criterios de las pruebas de iteracin Plan de iteracin Cartas CRC Soluciones pico prototipos

DISE ION

AC NIFIC PLA

recodificacin

ICAC ODIF C

ION

Programacin en pareja

PR U

EB A
Prueba de unidad

Lanzamiento Incremento de software Velocidad calculada del proyecto

Integracin continua

Pruebas de aceptacin

Planificacin
XP plantea la planificacin como un permanente dialogo
entre las partes la empresarial (deseable) y la tcnica (posible).

deseable

posible

 Planificacin
.1 El Juego de la Planificacin

Negocio
mbito Qu debe resolver el software? Prioridad Qu debe ser echo en primer

lugar?
Composicin de versiones Cunto es necesario

hacer para aportar valor?

Fechas de versiones Fechas para presencia

del software?

 Planificacin
.1 El Juego de la Planificacin

Tcnico.
Estimaciones Cunto lleva implementar una

caracterstica?
Consecuencias, informar sobre consecuencias

de las decisiones que adopta el negocio.

Procesos Cmo se organiza el trabajo en el

equipo?
Programacin detallada: En una versin Qu

se resolver primero?

 Planificacin

.2 Pequeas versiones. Cada versin debe de ser tan pequea como fuera posible, conteniendo los requisitos de negocios ms importantes, las versiones tiene que tener sentido como un todo. .3 Metfora. Es una historia que todo el mundo puede contar a cerca de cmo funciona el sistema.

Diseo

.4 Diseo simple. El diseo adecuado par el software es aquel que: 1.Funciona con todas las pruebas. 2.No tiene lgica duplicada.

3.Manifiesta cada intencin importante para los

programadores 4.Tiene el menor nmero de clases y mtodos.

Codificacin

.5 Recodificacin. 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 cundo el sistema te lo pida.

 Codificacin

.6 Programacin por parejas. Todo el cdigo de produccin se escribe con dos personas mirando a una mquina, con un solo teclado y un solo ratn. Cada miembro de la pareja juega su papel: uno

codifica en el ordenador y piensa la mejor manera

de hacerlo, el otro piensa mas estratgicamente, Va a funcionar?, Puede haber pruebas donde no

funcione?, Hay forma de simplificar el sistema

global para que el problema desaparezca?.

 Codificacin

.7 Propiedad Colectiva. Cualquiera que crea que puede aportar valor al cdigo en cualquier parcela puede hacerlo, ningn miembro del equipo es propietario del cdigo.

.8 Integracin contina.
El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del

sistema.

 Codificacin

.9 Cuarenta horas. Si queremos estar frescos y motivados cada maana 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.

 Codificacin

.11 Estndares de Codificacin. Se debe establecer un estndar de codificacin aceptado e implantado por todo el equipo.

Pruebas

.12 Hacer pruebas. Toda caracterstica 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.

Prcticas XP
1. El juego de la planificacin
PLANIFICACION DISEO

2. Entregas pequeas 3. Metfora 4. Diseo simple 5. Recodificacin 6. Programacin en parejas 7. Propiedad colectiva

CODIFICACION

8. Integracin continua 9. Semana de 40 horas 10. Cliente in situ

11. Estndares de programacin

PRUEBAS

12. Pruebas

 Prcticas XP Interaccin entre Prcticas

Cliente in situ Semana de 40 horas Metfora Recodificacin Diseo simple El juego de la planificacin

Programacin en parejas

Pruebas

Pequeas versiones

Estndares de programacin Propiedad Colectiva Integracin Continua

XP: Kent Beck

Aspectos sobre Programacin Extrema

Aspectos Positivos De Xp
+ Pruebas unitarias en el cdigo factor clave para obtener un software de alta calidad. + La integracin continua es aceptada y recomendada para evitar catstrofes ocasionadas por defectos no detectados a tiempo.

+ la simplicidad y la refabricacin es encontrado como un factor saludable en la prctica de programacin.

+ El enfoque extremadamente humano, siendo este un aspecto que el resto del campo del software debera tratar de emular. + Cliente tambin 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 metodologa 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 tecnologa o el entorno no permiten realizar integraciones frecuentes o realizar pruebas continuamente.

+ No se recomienda intentar XP si la distribucin fsica

impide la programacin en pares o si no todos los programadores se encuentran en el mismo sitio.

Aspectos Controversiales de Xp
+ Desalienta el diseo, que es dbil en la documentacin, que el modelo no aplica para proyectos donde la seguridad es

crtica.
+ Exceso de pruebas retrasa el desarrollo, el diseo simple solo aplica a proyectos simples, que la programacin en pares consume mayor tiempo y recursos. + XP asume implcitamente que siempre se utiliza el enfoque de programacin orientada a objetos.

Aspectos Controversiales de Xp
+ La refabricacin, como sinnimo de rediseo constante y
que se puede tomar como una excusa para relegar hasta el ltimo minuto el diseo. + La planeacin, segn algunos crticos, no debera hacerse sobre la marcha como parece recomendar XP. + La programacin 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

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 funcionar Lo he probado y me gusta mucho

Extrapolacin De Las Prcticas De Xp

+ XP adecuada para proyectos de software pequeos o cuando mucho medianos. + Diseo al inicio: Aqu se recomienda un buen diseo inicial (upfront) que respalde al proyecto. + Se producen funcionalidades completas en cada iteracin

(entrega) durante el ciclo del software. El tiempo entre cada entrega es corto.

Extrapolacin De Las Prcticas 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. + Programacin en pares flexible. Se modifica la prctica de XP

y en lugar de ser obligatoria para todo el cdigo que se

escribe.

+ Seleccin y administracin del equipo de desarrollo. Se buscan

diferentes habilidades y experiencias en los programadores.

BENEFICIOS
+ Satisfaccin 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 implementacin de nuevas tecnologas rpidamente. donde los requerimientos cambian

CONCLUSIONES
+ La programacin extrema es una forma ligera, eficiente,
flexible, software. + La programacin extrema se beneficia de la existencia de un gran nmero de herramientas de software libre que permiten aplicarla con gran productividad. + El software libre se inspira en algunas de las prcticas de la XP . predecible, cientfica y divertida de generar

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

+ El proceso de desarrollo de las pruebas ayuda al cliente a

clarificar y concretar la funcionalidad de la historia de

uso y favorece la comunicacin 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 implementacin. + Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situacin. + Garantiza la cobertura de la funcionalidad de las pruebas de aceptacin, probar. garantizando que no se deja ningn punto

importante de la funcionalidad de una historia de uso sin

RECOMENDACIONES
+ Algunas prcticas podrn ser controversiales y hasta

contraproducentes fuera de un dominio especfico. Las metodologas giles se recomiendan. Para proyectos y

equipos pequeos.
+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, combinndolo con la XP.

BIBLIOGRAFA
+ Una explicacin de la Programacin extrema: aceptar el cambio Autor: Kent Beck. Publicado: Addison-Wesley Iberoamericana Espanya, S.A.

2002.
+ La Programacin Extrema en la prctica 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 edicin (13 Octubre 2000).

+ Extreme

Programming

Explained:

Embrace

Change.

Autor:

Kent

Beck.Publicado: Addison-Wesley Pub Co; 1 edicin (5 Octubre 1999).

BIBLIOGRAFA
+ Extreme Programming Pocket Guide. Autor: chromatic. Publicado: O'Reilly & Associates; 1 edicin (Junio 2003).

+ Extreme Programming Refactored: The Case Against XP.

+ Planning Extreme Programming. Autor: Kent Beck,

Autor: Matt
Fowler.

Stephens, Doug Rosenberg. Publicado: APress; (1 Enero 1970). Martin Publicado: Addison-Wesley Pub Co; 2000

Referencias Web
+Sitio Extreme Programming: A Gentle Introduction. www.extremeprogramming.org
+Secciones Artculos 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 electrnica Software Development. www.sdmagazine.com +Nmero monogrfico 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