Concepto: Prácticas de Agile y RUP
En esta directriz se explica cómo aplicar algunas de las "recomendaciones" identificadas en la comunidad Agile a proyectos basados en RUP que quisieran beneficiarse de alguna de estas prácticas.
Relaciones
Descripción principal

Temas

Introducción

Rational Unified Process (RUP) es una infraestructura de procesos que Rational Software ha perfeccionado a lo largo de los años y que se ha utilizado ampliamente para todo tipo de proyectos de software, fueran grandes o pequeños. Recientemente, un número creciente de procesos "ágiles", como eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) y la metodología Crystal Clear, han ido adquiriendo reconocimiento como métodos eficaces para la creación de sistemas más pequeños. (Vaya a www.agilealliance.org, donde encontrará más información sobre Agile Alliance).

Las secciones siguientes se han concebido como una ayuda para los equipos de proyecto mediante la evaluación de prácticas "ágiles" que se hayan hallado en uno de estos métodos para ver cómo las tratan los procesos de desarrollo de software más completos definidos por RUP (si desea más información acerca de RUP, consulte el capítulo de Introducción a RUP).

Visión general

La comunidad Agile ha sintetizado ciertas "recomendaciones" que son especialmente aplicables a equipos pequeños y equipos de proyectos en ubicaciones próximas. Aunque RUP puede emplearse con equipos de proyectos de cualquier tamaño, puede aplicarse satisfactoriamente a proyectos pequeños. En general, RUP y los procesos de la comunidad Agile tienen una visión similar de las principales recomendaciones necesarias para desarrollar software de calidad, por ejemplo, aplicar el desarrollo iterativo y centrarse en los usuarios.

En las secciones siguientes se explica cómo aplicar algunas de las "recomendaciones" identificadas en la comunidad Agile a proyectos basados en RUP que quisieran beneficiarse de alguna de estas prácticas. En este caso, se centran específicamente en aquellas prácticas presentadas por la metodología eXtreme Programming (XP). (Si desea más información sobre XP, consulte el sitio web: http://www.extremeprogramming.org).

Prácticas de XP

XP incluye cuatro "actividades" básicas (codificación, prueba, escucha y diseño), que están muy alineadas con las disciplinas de RUP. Estas actividades de XP se realizan utilizando un conjunto de prácticas que precisan realizar actividades adicionales, que se correlacionan con algunas otras disciplinas en RUP. Las prácticas de XP, según Extreme Programming Explained, son:

  • El juego de la planificación: determinar con rapidez el ámbito del próximo release combinando las prioridades empresariales con los cálculos técnicos. A medida que la realidad se imponga al plan, vaya actualizando el plan.
  • Pequeños releases: lleve rápidamente un sistema sencillo a producción y, a continuación, vaya publicando nuevas versiones en ciclos muy cortos.
  • Metáfora: dirija todo el desarrollo con una historia compartida que sea sencilla sobre cómo funciona todo el sistema.
  • Diseño sencillo: el sistema debería diseñarse de la forma más sencilla posible en todo momento. La complejidad suplementaria debe eliminarse cuando se detecte.
  • Prueba: los programadores deben escribir pruebas de unidades de forma continua, y deben ejecutarse sin error antes de continuar con el desarrollo. Los clientes pueden escribir pruebas que demuestren que las características se han completado.
  • Refactorización: los programadores deben reestructurar el sistema sin modificar su comportamiento para eliminar la duplicación, mejorar la comunicación, simplificar o añadir flexibilidad.
  • Programación de dos en dos: todo el código de producción se escribe con dos programadores en una máquina.
  • Propiedad colectiva: cualquiera puede cambiar cualquier parte del código en cualquier lugar del sistema en cualquier momento.
  • Integración continuada: integre y construya el sistema varias veces al día, cada vez que se complete una tarea.
  • Semanas de 40 horas: no trabaje más de 40 horas a la semana como norma. Nunca realice horas extra de trabajo dos semanas seguidas.
  • Cliente in situ: incorpore un usuario real al equipo, para que esté disponible en todo momento para responder preguntas.
  • Estándares de codificación: los programadores deben escribir todo el código de acuerdo con las normas, insistiendo en la comunicación a través del código.

Las actividades que se realizan como resultado de la práctica "juego de la planificación", por ejemplo, se correlacionarán fundamentalmente con la disciplina de gestión de proyectos de RUP. Pero algunos temas de RUP, como el despliegue del software publicado, se encuentran fuera del ámbito de XP. La obtención de requisitos excede en mucho el ámbito de XP, pues es el cliente quien define y proporciona los requisitos. Asimismo, debido a los proyectos de desarrollo más sencillos que trata, XP puede abordar sólo ligeramente con cuestiones que cubre RUP con más detalle en la disciplina de gestión de cambios y configuración y en la disciplina de entorno.

Prácticas de XP compatibles con RUP

En las disciplinas en las que XP y RUP se solapan, las prácticas siguientes, que se describen en XP, pueden emplearse en RUP, y en algunos casos ya se emplean.

  • El juego de la planificación: la guía de XP para la planificación puede utilizarse para alcanzar muchos de los objetivos utilizados en la disciplina de gestión de proyectos de RUP para un proyecto que sea muy pequeño. Esto es muy útil para los proyectos con un nivel bajo de formalidad que no deben producir artefactos formales de gestión de proyectos de nivel intermedio.
  • Diseño de primera prueba y refactorización: se trata de dos buenas técnicas que pueden aplicarse en la disciplina de implementación de RUP. En concreto, la práctica de pruebas de XP, que requiere del diseño de primera prueba, es una forma excelente de clarificar los requisitos con mucho detalle. Como se verá en la siguiente sección, la refactorización puede no escalar adecuadamente para los sistemas grandes.
  • Integración continuada: RUP da soporte a esta práctica por medio de compilaciones en el nivel de sistema y de subsistema (dentro de una iteración). Componentes probados en unidades se integran y se prueban en el contexto del sistema emergente.
  • Cliente in situ: muchas de las actividades de RUP pueden aprovechar en gran medida la presencia de un cliente in situ como miembro del equipo, lo que reducirá el número de entregas intermedias necesarias, en especial, de documentos. Al igual que su favorito medio de comunicación entre el desarrollador y el cliente, XP favorece la opción de la conversación, que depende de la continuidad y de la familiaridad para tener éxito; sin embargo, cuando un sistema, incluso uno pequeño, tiene que sufrir una transición, se necesitará más que conversaciones. XP permite abordar este tipo de cuestiones a posteriori mediante, por ejemplo, documentos de diseño al final del proyecto. Aunque no prohíbe la producción de documentos u otro tipo de artefactos, XP indica que debe producir sólo los que verdaderamente necesite. RUP coincide, pero lo lleva más allá y describe lo que necesitará cuando la continuidad y la familiaridad no son ideales.
  • Estándares de codificación: RUP tiene directrices para la programación de artefactos que deben observarse casi siempre como si fuesen obligatorias. (La mayoría de los perfiles de riesgo de proyectos, al ser uno de los principales factores de la personalización, harían que lo fuesen).
  • Semana de cuarenta horas: como en XP, RUP sugiere que el trabajar horas extras no debe ser una condición crónica. XP no sugiere un límite estricto en las 40 horas, pues reconoce distintas tolerancias en las jornadas de trabajo. Los ingenieros de software son tristemente famosos por sus jornadas con muchas horas extra sin compensación, simplemente por la satisfacción de ver que han completado alguna parte, y sus responsables no tienen por qué detener ese impulso de forma arbitraria. Lo que los directores no deben es explotar esta práctica o imponerla. Deben recopilar constantemente mediciones de las horas trabajadas realmente, aunque no se compensen. Si el registro de horas trabajadas parece alto durante un periodo extendido, debe investigarse; sin embargo, estas son cuestiones que resolver en las circunstancias en las que se den, entre el individuo y su director, con un reconocimiento de las preocupaciones que puedan derivarse para el resto del equipo. Las cuarenta horas no son más que una guía, pero son una guía muy sólida.
  • Programación de dos en dos: XP sostiene que la programación de dos en dos es beneficiosa para la calidad del código, y que una vez que se adquiere, se disfruta más de esta habilidad. RUP no describe los mecanismos de la producción de código de una forma tan granulada, aunque sería ciertamente posible utilizar la programación de dos en dos en un proceso basado en RUP. RUP es ahora quien proporciona parte de la información sobre programación de dos en dos, así como el diseño de primera prueba y la refactorización, en la forma de documentación. Obviamente, el uso de estas prácticas en RUP no es un requisito, sin embargo en un entorno de equipo, con una cultura de comunicación abierta, significaría la sospecha de que las ventajas de la programación de dos en dos (en términos del efecto sobre los costes del ciclo vital total) sería difícil de discernir. El personal se reúne para hablar de los problemas y para resolverlos de una forma muy natural en un equipo que funciona bien, sin estar obligado a ello.

La insinuación de que el proceso adecuado debe imponerse en el nivel "micro" suele ser mal recibida y puede no ser bien recibida en algunas culturas de empresa. RUP, por tanto, no aboga por la imposición estricta. Sin embargo, en algunas circunstancias, el trabajo en pareja, y algunas de las otras prácticas basadas en equipos recomendadas en XP, son claramente beneficiosas, ya que cada miembro del equipo puede ayudar al otro, por ejemplo:

  • los primeros días de la formación del equipo, cuando las personas se están conociendo
  • los equipos sin experiencia en alguna nueva tecnología
  • los equipos compuestos por personal muy experimentado y por novicios

Prácticas de XP que no escalan adecuadamente

Las prácticas de XP siguientes no escalan adecuadamente para los sistemas grandes (ni XP lo pretende), por lo que las utilizaremos si lo recomienda RUP.

  • Metáfora: para los sistemas más grandes y complejos, la arquitectura como metáfora no es suficiente. RUP proporciona una infraestructura de descripción más rica para la arquitectura que no es sólo lo que se describe en Extreme Programming Explained: "grandes cajas y conexiones". Incluso en la comunidad de XP, la metáfora se está desechando recientemente. Ya no es una de las prácticas de XP (hasta que puedan conseguir describirla adecuadamente, tal vez la metáfora pueda serles de ayuda).
  • Propiedad colectiva: es útil si los miembros de un equipo responsable de un sistema pequeño o de un subsistema están familiarizados con todo su código. Pero si desea o no que todos los miembros del equipo tengan la misma autorización para realizar cambios en cualquier parte dependerá de la complejidad del código. Suele ser más rápido (y más seguro) que aplique un arreglo el individuo (o pareja) que esté trabajando en ese momento en el segmento de código pertinente. La familiaridad con el código, aún con el mejor escrito, en particular si es complejo en su algoritmia, se reduce rápidamente con el tiempo.
  • Refactorización: en un sistema grande, la refactorización frecuente no es un sustituto de la falta de arquitectura. En Extreme Programming Explained se afirma que la estrategia de diseño de XP se parece a un algoritmo que subiera y bajara montañas. Empieza por un diseño sencillo y, a continuación, lo hace un poco más complejo, y luego otra vez sencillo y luego otra vez más complejo. El problema con este tipo de algoritmos es alcanzar el punto local óptimo, en el que la situación no puede mejorarse mediante ningún cambio pequeño, pero un cambio de grandes dimensiones sí podría. En RUP, la arquitectura proporciona la vista y el acceso a la "montaña alta", para hacer tratables los sistemas grandes y complejos.
  • Pequeños releases: el índice al que un cliente puede aceptar y desplegar nuevos releases dependerá de muchos factores, y suele incluir el tamaño del sistema que suele estar correlacionado con el impacto empresarial. Un ciclo de dos meses puede ser demasiado corto para algunos tipos de sistemas; es posible que la logística de despliegue lo prohíba.

Prácticas de XP que requieren precaución

Finalmente, es posible que una práctica de XP que a primera vista suena potencialmente utilizable en el diseño sencillo de RUP, precise alguna elaboración y precaución al aplicarla de forma general.

  • Diseño sencillo
    XP está muy claramente dirigido a la funcionalidad: las historias de los usuarios se seleccionan, se descomponen en tareas y, a continuación, se implementan. De acuerdo con Extreme Programming Explained, el diseño correcto para el software en un momento determinado el que puede ejecutar todas las pruebas, no tiene lógica duplicada, manifiesta todas las intenciones que son importantes para los programadores y tiene el menor número de clases y métodos posibles. XP no cree en añadir nada que no sirva para aumentar el valor empresarial para el cliente.

    Esto encierra un problema, relacionado con el problema de las optimizaciones locales, al tratar con lo que RUP denomina requisitos "no funcionales". Estos requisitos también proporcionan valor empresarial al cliente, pero es más difícil expresarlos en forma de historias. Algunas de las que en XP se denominan restricciones pertenecen a esta categoría. RUP tampoco aboga por un diseño que vaya más allá de lo necesario de forma especulativa, sino que apoya el diseño con un modelo arquitectónico en mente que sea una de las claves del cumplimiento de los requisitos no funcionales.

    Por tanto, RUP coincide con XP que el "diseño sencillo" debe incluir la ejecución de todas las pruebas, pero con el añadido de que éste incluye pruebas que demuestran que el software cumplirá con los requisitos no funcionales. Una vez más, esto sólo surge como un tema principal a medida que crecen el tamaño y la complejidad del sistema, o cuando la arquitectura no tiene precedentes o los requisitos no funcionales muy laboriosos. Por ejemplo, la necesidad de organizar los datos (para operar en un entorno distribuido heterogéneo) parece hacer que el código sea excesivamente complejo, pero sigue siendo necesaria en todo el programa.

Correlación de artefactos para un proyecto pequeño

Cuando se personaliza RUP para un proyecto pequeño y se reducen los requisitos de productos de trabajo según corresponda, ¿cuál es la diferencia con el equivalente de los artefactos de un proyecto XP? En la Tabla 1 se muestra un conjunto habitual de artefactos RUP en un proyecto RUP pequeño.

artefactos de XP
artefactos de RUP
(Ejemplo de proyectos pequeños)
Historias
Documentación adicional procedente de conversaciones
visión
glosario
modelo de guión de uso
Restricciones Especificaciones suplementarias
Pruebas de aceptación y de unidad
Datos de prueba y resultados de pruebas

Plan de prueba Guión de prueba Conjunto de aplicaciones de prueba (que incluye Script de prueba, Datos de prueba)
Registro de prueba
Resumen de evaluación de prueba

Software (código) Modelo de implementación
Releases Producto (unidad de despliegue)
Notas del release
Metáfora Documento de arquitectura de software
Diseño (CRC, esbozo de UML)
Tareas técnicas y otras tareas
Diseñar documentos producidos al final
Documentación de soporte
Modelo de diseño
Estándares de codificación Directrices específicas de proyecto
Espacio de trabajo
Prueba de la infraestructura y de las herramientas
Guión de desarrollo
Configuración de entorno de prueba
Plan de release
Plan de iteración
Cálculos de historia y de tarea
Plan de desarrollo de software
Plan de iteración
Plan general y presupuesto Caso de negocio
Lista de riesgos
Informes sobre progreso
Registros de tiempo para el trabajo de tarea
Datos de métrica (incluidos recursos, ámbito, calidad, tiempo)
Seguimiento de resultados
Informes y notas de las reuniones
Valoración de estado
Valoración de iteración
Registro de revisión
Defectos (y datos asociados) Solicitudes de cambio
Herramientas de gestión de código Depósito de proyecto
Espacio de trabajo
Spike (solución)

Prototipos
Prototipo de interfaz de usuario
Prueba de concepto arquitectónico

El propio XP (sus recomendaciones y guías)

Lista de ideas de prueba
Directrices específicas de proyecto

[No incluido en XP]

Modelo de datos
Material de soporte del usuario.

Tabla 1: correlación de los artefactos de XP a RUP para un proyecto pequeño

Aunque la granularidad de los artefactos varía en ambos lados, en general los artefactos de RUP para proyectos pequeños (el tipo que trataría XP sin problemas) se correlacionan bastante bien con los de un proyecto XP.

Tenga en cuenta que la tabla también incluye algunos artefactos que no están cubiertos por XP, pero que son necesarios en muchos proyectos. Estos incluyen el modelo de datos y los artefactos relacionados con el despliegue, como el material de soporte del usuario.

Actividades

RUP define una tarea como si fuera trabajo realizado por un rol, sea utilizando y transformando artefactos de entrada o produciendo artefactos de salida que son nuevos o modificados. Además RUP enumera estas actividades y las categoriza de acuerdo con las disciplinas de RUP. Estas disciplinas incluyen: requisitos, análisis y diseño, despliegue y gestión de proyectos (entre otras).

Las actividades están relacionadas en el tiempo mediante los artefactos que producen y consumen: una actividad puede empezar lógicamente cuando sus entradas estén disponibles (y en un estado adecuadamente maduro). Esto significa que los pares de actividades de productor y consumidor pueden solaparse con el tiempo, si el estado del artefacto lo permite; no tienen por qué secuenciarse con rigidez. Las actividades deben proporcionar una sólida guía sobre cómo debe producirse un artefacto, y también pueden utilizarse para ayudar al gestor de proyectos con la planificación.

Al estar entretejidos en RUP como se describe en términos de ciclo vital, los artefactos y actividades son "recomendaciones": principios de ingeniería de software con capacidad probada de producir software de calidad construido según una planificación y un presupuesto previsibles. RUP, a través de sus actividades (y sus artefactos asociados), da soporte y realiza estas recomendaciones; son temas que se ejecutan en RUP y que mantienen los principios clave que apuntalan RUP. Tenga en cuenta que XP también utiliza la noción de "prácticas", pero como se verá, no se corresponden de forma exacta con el concepto que en RUP se denomina recomendación, o práctica recomendada.

XP presenta una vista sencilla y atractiva del desarrollo de software basada en cuatro actividades básicas: codificación, prueba, escucha y diseño, que deben habilitarse y estructurarse de acuerdo con algunas prácticas de soporte (como se indica en el capítulo 9 de Extreme Programming Explained). De hecho, como se ha indicado anteriormente, las actividades de XP tienen un ámbito más cercano a las disciplinas de RUP que a las actividades de RUP, y buena parte de los que sucede en un proyecto XP (además de las cuatro actividades básicas) proviene de la elaboración y la aplicación de sus prácticas.

Por tanto, existe un equivalente en XP de las actividades de RUP, pero las "actividades" de RUP no se identifican o describen formalmente como tales. Por ejemplo, si se observa el capítulo 4 acerca de las historias de los usuarios en Extreme Programming Installed, se puede leer la cabecera acerca de la definición de requisitos con historias, escritas en tarjetas, y en todo el capítulo se da una mezcla de descripción de procesos y de guía acerca de lo que son las historias de usuarios, y de cómo deben producirse (y quién debe hacerlo). Y continúa de esa forma; en las diversas secciones de los libros de XP (bajo los encabezamientos que combinan el enfoque de artefacto con el de actividad), se describen tanto las "cosas producidas" como las "cosas hechas" con varios grados de prescripción y detalle.

El aparentemente alto grado de prescripción de RUP es el resultado de la completitud y la mayor formalidad en su tratamiento de las actividades y sus entradas y salidas. No es que XP no tenga prescripción pero, tal vez en su intento de seguir siendo ligero, la formalidad y el detalle se han omitido sin más. La falta de especificidad no es ni una fortaleza ni una debilidad, pero la falta de información detallada de XP no debe confundirse con la sencillez. No disponer de detalles puede ser una opción aceptable para los desarrolladores más experimentados, pero en muchos casos, un mayor número de detalles son de gran ayuda para los nuevos miembros del equipo, que aún no se han adecuado al ritmo de trabajo con que el equipo enfoca el desarrollo de software.

Con las actividades, igual que con los artefactos, es importante no olvidar lo que se trata de conseguir. Llevar a cabo una actividad a ciegas no es nunca una práctica recomendable. Las actividades y las directrices asociadas están ahí para consultarlas cuando sean necesarias para alcanzar los objetivos, pero no debieran utilizarse como excusa para no tener que determinar lo que se intenta alcanzar. Este espíritu está bien articulado en XP, y estimamos que deberían aplicarlo todos los usuarios de RUP.

Roles

En RUP, se dice que las actividades las realizan los roles (o, para ser exactos, los individuos o grupos que desempeñan los roles). Los roles también son responsables de artefactos concretos; normalmente, el rol responsable crea el artefacto y garantiza que los cambios efectuados por otros roles (si está permitido) no rompan el artefacto. Un individuo o un grupo de personas puede desempeñar un rol o varios roles. Un rol no tiene que correlacionarse sólo con una posición o "casilla" en una empresa.

En Extreme Programming Explained se identifican siete roles aplicables a XP: programador, cliente, verificador, rastreador, adiestrador, consultor y gran jefe, y se describen sus responsabilidades y las competencias necesarias en las personas que los desempeñarán. Asimismo, en algunos de los otros libros de XP se hace referencia a estos roles. La diferencia en el número en XP y en RUP es fácil de explicar:

  • XP no cubre todas las disciplinas de RUP.
  • Los roles de XP son más comparables a los puestos dentro de una empresa (posiblemente asumiendo varias responsabilidades) que a los roles de RUP. Por ejemplo, el programador de XP de hecho desempeña varios roles de RUP: implementador, revisor de código e integrador, que necesitan competencias ligeramente distintas.

Roles de XP y RUP en proyectos pequeños

Cuando los roles de RUP se correlacionan con un proyecto pequeño, el correspondiente número de roles similares a los de XP se reduce a 5 en el número de puestos, o tipos de trabajo. En la Tabla 3 (dibujada a partir de RUP) se muestra esta correlación con los roles de XP correspondientes.

Rol de XP Ejemplo de miembro de equipo en un proyecto pequeño de RUP Rol de RUP
Adiestrador
Consultor
Gran jefe
Sally Slalom, gestora sénior Gestor de proyectos
Gestor de despliegue
Revisor técnico
Gestor de configuración
Gestor de control de cambios
Cliente Interesado (tal como se documenta en la visión)
Revisor de gestión
Revisor técnico (requisitos)
Cliente
Gran jefe
Rastreador
Tom Telemark, ingeniero de software sénior Analista de sistemas
Especificador de requisitos
Diseñador de interfaz de usuario
Arquitecto de software
Revisor técnico
Gestor de pruebas
Analista de pruebas

Roles de desarrollador (con menos énfasis)

Programador
Verificador

Susan Snow, ingeniera de software

Henry Halfpipe, ingeniero de software júnior

Diseñador
Implementador
Revisor técnico
Integrador
Diseñador de pruebas
Verificador
Escritor técnico
Rastreador Patrick Powder, administrativo ayudante Responsable del mantenimiento del sitio web del proyecto, ofreciendo asistencia al rol de gestor de proyectos en las actividades de planificación y al rol de gestor de control de cambios para controlar los cambios en los artefactos.  Asimismo puede proporcionar asistencia a otros roles según sea necesario.

Tabla 3: correlación de roles de XP con roles de RUP en un proyecto pequeño

Utilización de prácticas de XP con RUP

RUP es una infraestructura de proceso desde la que se pueden configurar procesos concretos y después se pueden crear instancias de estos. RUP debe configurarse; es un paso obligatorio definido en el propio RUP. Por lo tanto, si se es riguroso, debe comparar una versión personalizada de RUP con XP, es decir, con RUP personalizado para las características del proyecto que establece XP explícitamente (y los que se pueden inferir). Ese proceso personalizado de RUP puede incorporar muchas de las prácticas de XP (como la programación de dos en dos, el diseño con prueba inicial y la refactorización), pero sigue sin ser idéntico a XP a causa del énfasis de RUP en la importancia de la arquitectura, de la abstracción (en el modelado), y el riesgo, y su diferente estructura en el tiempo (fases e iteraciones).

XP está dirigido de forma intencionada a la implementación de un proceso ligero para los proyectos pequeños. Al hacerlo, también incluye las descripciones (al menos en los libros) que no están completamente elaborados. En una implementación de XP, siempre habrá aspectos que deben descubrirse, inventarse o definirse sobre la marcha. RUP puede adecuarse tanto a los proyectos cuya clase y escala se ajusten al ámbito de XP o lo excedan. Como muestran estas instrucciones, RUP es de hecho muy compatible con la mayoría de las prácticas descritas en la documentación de XP.

No olvide que la esencia de XP es que se centra en la organización, las personas y la cultura. Esto es importante en todos los proyectos y desde luego puede aplicarse a los proyectos que utilizan RUP. Los proyectos pequeños pueden beneficiarse mucho del uso conjunto de estas prácticas.

Referencias de procesos Agile

  • eXtreme Programming (XP) (vaya a http://www.extremeprogramming.org/more.html si desea más información):
    • Extreme Programming Explained: Embrace Change. Kent Beck explica los conceptos y la filosofía que sostienen esta forma de programación. En este libro se enseñan los conceptos y las razones pero no los métodos.
    • Refactoring Improving the Design of Existing Code. Martin Fowler escribe el primer volumen serio sobre refactorización. Se presenta en forma de patrones. Hay muchos ejemplos en Java. En este libro se enseña a refactorizar y las razones para hacerlo.
    • Extreme Programming Installed. De Ron Jeffries, Chet Hendrickson y Ann Anderson. En este libro se cubren prácticas específicas de XP con más detalle que en el libro Extreme Programming Explained. En este libro se enseña a programar a la manera de XP.
    • Planning Extreme Programming. De Kent Beck y Martin Fowler. En este libro se presentan las últimas ideas acerca de cómo planificar software en un entorno de entregas rápidas. En este libro se enseña a ejecutar un proyecto de XP.
    • Extreme Programming Examined. De Giancarlo Succi y Michele Marchesi. Documentos presentados en XP2000. Un conjunto de documentos muy completo que cubre la mayoría de los temas.
    • Extreme Programming in Practice. De Robert C. Martin, James W. Newkirk. Un proyecto real que utilizó XP es descrito con todo detalle.
    • Extreme Programming Explored. De William C. Wake. Basado en el popular sitio web XPlorations. Temas específicos explorados al detalle.
    • Extreme Programming Applied: Playing to Win. De Ken Auer y Roy Miller. Experiencias de los pioneros en la aplicación de XP. Se publicará en septiembre.

Para obtener información sobre otros miembros de Agile Alliance, vaya a http://www.agilealliance.org.