Metodologia xp cortesserranoeliud

Métodos ágiles de programación
Programación Extrema
Cortés Serrano Eliud – 5IM8

Esta situación resulta conocida……???

Fuerzas que influyen en los enfoques para
el desarrollo de software
Grado de
Control
en el proceso
Tiempo
1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s
Fuente: Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

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:
1. Al individuo y las interacciones del equipo de desarrollo
sobre el proceso y las herramientas.
2. Desarrollar software que funciona más que conseguir
una buena documentación.
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
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 empezar
No involucra gran inversión
A los programadores les (suele) gustar
A 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
Costo
del
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

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

+ 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)
Costodelcambio
Justificación y fundamentos de XP

Fig. 2 Costo del cambio modificado por la aplicación de técnicas adecuadas
(adaptado de Beck, 1999)
Costodelcambio
Justificació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 :
1.Realimentación rápida
2.Asumir la simplicidad
3.Cambio incremental
4.Aceptar el cambio
5.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

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.

Interacción entre Las cuatro variables
de 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 y
técnicos).
Insistir 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.
COSTE
TIEMPO
COSTE
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.

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 Riesgo
Esfuerzo (puntos)
Spikes (Bosquejos)
Definir
Historias
de Usuario
Elaborar
Spikes
Estimar Esfuerzo
y Riesgo
?

Escenarios en XP:
Planificación de la Entrega
Historias
de Usuario
Primera
Iteración
Segunda
Iteración
Última
Iteración
…
N-ésima
Iteración
Historias
fuera de la
entrega
Velocidad de
Proyecto (VP)
puntos/semana
Entrega
<= 3 meses
2 a 3
semanas

Escenarios en XP :
Comenzar Iteración
Historias de la
Iteración
Definir y
ordenar
Tareas de
Ingeniería
Tareas de
la iteración

Escenarios en XP :
Programación
Pruebas de
Aceptación
de Historias
de la iteración
Programación
en Parejas
Tareas de
Historias de
la iteración
Historias de la
Iteración
Versión del
Producto
Diseño
Refactoring
Programación
Pruebas Unitarias
Integración
Pruebas de Integración
Pruebas de Aceptación

Escenarios en XP :
Pruebas de Aceptación
Pruebas de
Aceptación
Definir Pruebas
de Aceptación
Aplicar Pruebas
de Aceptación
Corregir errores
Definir 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”

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 XP
Interacció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 de
programació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 funcionará
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

Metodologia xp cortesserranoeliud

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Metodologia xp cortesserranoeliud

Último

Metodologia xp cortesserranoeliud