Programacion Extrema
-
Upload
edgar-espinoza-silverio -
Category
Travel
-
view
39.133 -
download
0
description
Transcript of 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].
Antecedentes e Historia de Programación extrema
+ 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”.
Antecedentes e Historia de Programación extrema
+ 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.
Antecedentes e Historia de Programación extrema
+ 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.
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.
Antecedentes e Historia de Programación extrema
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
ImplementaciónRequerimientos Análisis Diseño Prueba Producción
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
ImplementaciónRequerimientos Análisis Diseño Prueba Producción
Enfoque Tradicional
Programación Extrema
$$
t
ImplementaciónRequerimientos Análisis Diseño Prueba Producción
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.
Principios de la Programación extrema
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
Principios de la Programación extrema
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.
Aspectos Controversiales de Xp
+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.
Aspectos Controversiales de Xp
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