TI2023

EXTREME PROGRAMMING
(XP)
 XP
¿Qué es?
Objetivos
Valores
 ¿Qué es XP?
XP es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de
software, promoviendo el trabajo en equipo, preocupándose por
el aprendizaje de los desarrolladores, y propiciando un buen
clima de trabajo. XP se basa en realimentación continua entre el
cliente y el equipo de desarrollo, comunicación fluida entre
todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios.

XP se define como especialmente adecuada para proyectos con

requisitos imprecisos y muy cambiantes, y donde existe un alto
riesgo técnico.
 Objetivos XP
La metodología XP tiene dos objetivos primordiales para el
correcto desarrollo del proyecto:
• La satisfacción de cliente: Entendida como dar al cliente lo
que necesita y cuando lo necesita, respondiendo rápidamente
a las necesidades de este. Uno de los factores importantes en
todo proyecto de software es que el sistema software logre el
objetivo para el cual fue diseñado y que el equipo de trabajo
logre el objetivo para el cual fue contratado.

• Potenciar al máximo el trabajo en grupo: Todos están

involucrados y comprometidos con el desarrollo del software,
tanto los jefes como los desarrolladores y los clientes, no hay
agentes individuales o aislados al proyecto.
 Valores XP
En todo desarrollo de un proyecto de software, los cambios
serán algo inevitables, los requerimientos cambiarán, las reglas
del negocio, el equipo de trabajo y la tecnología, entre otros
elementos involucrados en el proyecto. Por esta razón XP
propone valores, que permitirán afrontar y sortear de una
manera más efectiva los cambios en el proyecto.
1. Comunicación: Aunque hay circunstancias que conducen a la
ruptura de la comunicación, se debe procurar por comunicar
cualquier cambio con el resto del equipo ya sean desarrolladores,
cliente o jefe.
2. Sencillez: Iniciar desde la parte más simple que pueda darle
funcionalidad al sistema, es decir abordar el problema con el
mayor nivel de granularidad. Poner el foco en codificar las
necesidades de hoy, no las de un futuro.
 Valores XP
3. Retroalimentación: La mejor manera de conocer el estado actual
del sistema es haciéndole pruebas funcionales al software, esto
proporcionará información real y confiable sobre el grado de
fiabilidad del sistema.
4. Respeto: El respeto mutuo es fundamental para que un equipo
pueda trabajar de forma eficiente y ofrecer un buen rendimiento.
El respeto se manifiesta de varias formas y todas son cruciales para
una mejor autoestima en el equipo, que lleva consigo un mayor
ritmo de producción.
5. Valentía: El equipo de trabajo debe estar listo para asumir retos,
ser valiente ante los problemas y afrontarlos, no tapar los errores,
ya que tarde o temprano saldrán a flote y todo el sistema
colapsará, no se puede avanzar sobre los errores. Se recomienda
tomar acciones correctivas a tiempo a fin de lograr el objetivo del
proyecto.
 XP
Prácticas
 Prácticas
Los principios XP comprenden diez buenas prácticas que
involucran al equipo de trabajo, los procesos y el cliente; los
cuales son:
1. Planificación incremental.
2. Entregas pequeñas.
3. Diseño sencillo.
4. Desarrollo previamente aprobado.
5. Limpieza de código o refactorización.
6. Programación en parejas.
7. Propiedad colectiva.
8. Integración continua.
9. Ritmo sostenible.
10. Cliente presente.
Prácticas
 Prácticas
Planificación incremental
Se toman los requerimientos en Historias de Usuario, las cuales son
negociadas progresivamente con el cliente.

Entregas pequeñas
Se desarrolla primero la más mínima parte útil que le proporcione
funcionalidad al sistema, y poco a poco se efectúan incrementos que
añaden funcionalidad a la primera entrega, cada ciclo termina con una
entrega del sistema.

Diseño sencillo
Solo se efectúa el diseño necesario para cumplir con los
requerimientos actuales, es decir, no se abordan requerimientos
futuros.
 Prácticas
Desarrollo previamente aprobado
Una de las características relevantes y propias de XP es que primero se
escriben las pruebas y luego se da la codificación, esto con la finalidad
de asegurar la satisfacción del requerimiento.

Limpieza del código o refactorización

Consiste en simplificar y optimizar el programa sin perder
funcionalidad, es decir, alterar su estructura interna sin afectar su
comportamiento externo.
 Prácticas
Programación en parejas
Es otra de las características de ésta metodología, que propone que los
desarrolladores trabajen en parejas en una terminal, verificando cada
uno el trabajo del otro y ayudándose para buscar las mejores
soluciones. Se entiende que de esta forma el trabajo será más eficiente
y de mayor calidad.

Propiedad colectiva
El conocimiento y la información deben ser de todos, por lo tanto no
se desarrollan islas de conocimiento, todos los programadores poseen
todo el código y cualquiera puede sugerir y realizar mejoras.
 Prácticas
Integración continua
Al terminar una tarea, ésta se integra al sistema entero y se realizan
pruebas de unidad a todo el sistema, ésta práctica permite que la
aplicación sea más funcional en cada iteración y garantiza su
funcionamiento con los demás módulos del sistema.

Ritmo sostenible
No es aceptable trabajar durante grandes cantidades de horas ya que
se considera que puede reducir la calidad del código y la productividad
del equipo a mediano plazo, se sugieren 40 horas semanales.

Cliente presente
Se debe tener un cliente o usuario final tiempo completo, ya que en XP
éste hace parte del equipo de desarrollo y es responsable de formular
los requerimientos para el desarrollo del sistema.
 XP
Modelo del Proceso
Flujo
 Modelo del Proceso
El proceso de XP se presenta en fases, en XP se ejecuta teniendo
presente los principios y valores antes mencionados, los cuales
son un eje fundamental para el correcto desarrollo de cada fase
durante el ciclo.
 Flujo del proceso
Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de
usuario que son de interés para la primera entrega del producto. Al
mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologías y prácticas que se utilizarán en el proyecto.

Se prueba la tecnología y se exploran las posibilidades de la

arquitectura del sistema construyendo un prototipo. La fase de
exploración toma de pocas semanas a pocos meses, dependiendo del
tamaño y familiaridad que tengan los programadores con la
tecnología.
 Flujo del proceso
Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de
usuario, y correspondientemente, los programadores realizan una
estimación del esfuerzo necesario de cada una de ellas. Se toman
acuerdos sobre el contenido de la primera entrega y se determina un
cronograma en conjunto con el cliente. Una entrega debería obtenerse
en no más de tres meses. Esta fase dura unos pocos días.

Las estimaciones de esfuerzo asociado a la implementación de las

historias la establecen los programadores utilizando como medida el
punto. Un punto, equivale a una semana ideal de programación. Las
historias valen de 1 a 3 puntos. El equipo de desarrollo mantiene un
registro de la "velocidad" de desarrollo, establecida en puntos por
iteración, basándose en la suma de puntos de las historias de usuario
que fueron terminadas en la última iteración.
 Flujo del proceso
Planificación de la Entrega
La planificación se puede realizar basándose en el tiempo o el alcance.
La velocidad del proyecto es utilizada para establecer cuántas historias
se pueden implementar antes de una fecha determinada o cuánto
tiempo tomará implementar un conjunto de historias.

Al planificar por tiempo, se multiplica el número de iteraciones por la

velocidad del proyecto, determinándose cuántos puntos se pueden
completar.

Al planificar según alcance del sistema, se divide la suma de puntos de

las historias de usuario seleccionadas entre la velocidad del proyecto,
obteniendo el número de iteraciones necesarias para su
implementación.
 Flujo del proceso
Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser
entregado. El Plan de Entrega está compuesto por iteraciones de no
más de tres semanas.

En la primera iteración se puede intentar establecer una arquitectura

del sistema que pueda ser utilizada durante el resto del proyecto. Esto
se logra escogiendo las historias que fuercen la creación de esta
arquitectura, sin embargo, esto no siempre es posible ya que es el
cliente quien decide qué historias se implementarán en cada iteración
(para maximizar el valor de negocio).

Al final de la última iteración el sistema estará listo para entrar en

producción.
 Flujo del proceso
Iteraciones
Los elementos que deben tomarse en cuenta durante la elaboración
del Plan de la Iteración son: historias de usuario no abordadas,
velocidad del proyecto, pruebas de aceptación no superadas en la
iteración anterior y tareas no terminadas en la iteración anterior.

Todo el trabajo de la iteración es expresado en tareas de

programación, cada una de ellas es asignada a un programador como
responsable, pero llevadas a cabo por parejas de programadores.
 Flujo del proceso
Producción
La fase de producción requiere de pruebas adicionales y revisiones de
rendimiento antes de que el sistema sea trasladado al entorno del
cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión
de nuevas características a la versión actual, debido a cambios durante
esta fase.

Es posible que se rebaje el tiempo que toma cada iteración, de tres a

una semana. Las ideas que han sido propuestas y las sugerencias son
documentadas para su posterior implementación (por ejemplo,
durante la fase de mantenimiento).
 Flujo del proceso
Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto
XP debe mantener el sistema en funcionamiento al mismo tiempo que
desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas
de soporte para el cliente.

De esta forma, la velocidad de desarrollo puede bajar después de la

puesta del sistema en producción. La fase de mantenimiento puede
requerir nuevo personal dentro del equipo y cambios en su estructura.
 Flujo del proceso
Muerte/Cierre del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del cliente en
otros aspectos como rendimiento y confiabilidad del sistema. Se
genera la documentación final del sistema y no se realizan más
cambios en la arquitectura.

La muerte del proyecto también ocurre cuando el sistema no genera

los beneficios esperados por el cliente o cuando no hay presupuesto
para mantenerlo.
Flujo del proceso
 XP
Roles
Anti-Roles
 Roles XP
Al igual que el equipo Scrum, XP Team también es
autoorganizado, multifuncional y coubicado, y también realiza
ceremonias como reuniones de planificación, reuniones diarias,
reuniones de revisión y reuniones retrospectivas en cada
iteración.

Un equipo de XP puede constar de 5 a 20 miembros con

habilidades diversas y complementarias. en XP, no se
recomienda trabajar en varios elementos de trabajo o proyectos,
ya que el cambio de contexto de los desarrolladores
obstaculizará los trabajos valiosos.
 Roles XP
En XP, el énfasis está en la colaboración de todo el equipo,
colocado y en comunicación continua.

Sin embargo, se requieren ciertos roles para que un proyecto de

programación extrema funcione y las personas que asumen
estos roles asumen las responsabilidades correspondientes y son
responsables de su contribución a estos roles. Se recomienda
asignar a las personas adecuadas para los roles en lugar de
intentar cambiar a las personas para que encajen en esos roles.

Los roles más utilizados en XP son Tracker, Customer,

Programmer, Coach, Manager, Tester. Cualquiera puede ser
Doomsayer. También existen antiroles.
 Roles XP
Algunos roles pueden ser combinados en la misma persona; por
ejemplo la misma persona puede ser el Manager y el Tracker.
Otros es recomendable que no sean combinados: Programmer-
Tracker, Programmer-Tester, Customer-Programmer, Coach-
Tracker, por mencionar algunos.

El Manager no debería combinarse con algún otro rol además

de Tracker.

Ron Jeffries indica que el Coach no debería combinarse con el

Programador, pero que podría terminar de una manera
satisfactoria. Solo que no lo suficientemente buena.
Roles XP
 Roles XP
Tracker
Es el encargado de seguimiento. Proporciona retroalimentación al
equipo. Debe verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para
mejorar futuras estimaciones.

Customer
El cliente es quien escribe las historias de usuario y las pruebas
funcionales para validar su implementación. Asigna la prioridad a las
historias de usuario y decide cuáles se implementan en cada iteración
centrándose en aportar el mayor valor de negocio.
 Pieza básica en desarrollos XP.
 Define especificaciones.
 Influye sin controlar.
 Define pruebas funcionales.
 Roles XP
Programmer
El programador es considerado el mas importante miembro del equipo
ya que escribe las pruebas unitarias y el código del sistema.
 Pieza básica en desarrollos XP.
 Más responsabilidad que en otros modelos de desarrollo.
 Responsable sobre el código.
 Responsable sobre el diseño (refactorización, simplicidad).
 Responsable sobre la integridad del sistema (pruebas).

Coach
Es responsable del proceso global y se encarga de guiar a los miembros
del equipo para seguir el proceso correctamente.
 Roles XP
Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas
regularmente, difunde los resultados en el equipo y es responsable de
las herramientas de soporte para pruebas.

Big Boss
Es el dueño de la tienda y el vínculo entre clientes y programadores. Su
labor esencial es la coordinación.

Consultor
Es un miembro externo del equipo con un conocimiento específico en
algún tema necesario para el proyecto ayuda al equipo a resolver un
problema específico y puede que no siempre haya un consultor como
parte del equipo.
 Roles XP
Manager
Se encarga de agendar las reuniones, se asegura de que el proceso de
juntas sea seguido, registra los resultados de las reuniones para
futuros reportes para el Tracker. Asiste a las reuniones y trae
información importante para el equipo.

Doomsayer
Se asegura de que todos los miembros conozcan los riesgos del
proyecto.
Asegurándose:
De que todo el mundo sabe los riesgos que algo implica.
Que las malas noticias no se oculten ni sean pasadas por alto.
Que las malas noticias no sean exageradas.
 Anti-Roles XP
StandardsAndMetodologyGuy
Normalmente un ex-académico, la clase de persona que nunca ha
hecho que un día valga la pena, código difícil en su vida, pero tiene el
poder de decirte que estas haciendo mal y por qué el emplear XP
puede no funcionar y no funcionará. Puede haber unas discrepancias
con el Manager.

GodHead
El tipo de persona que quiere ser el ChiefArchitect (rol que no existe
en esta metodología) o el Manager pero no lo es. Gusta de estar en el
centro de todo. Memoriza suficientes detalles del sistema para
abalanzarse dentro de cada discusión acerca del diseño. Toma
responsabilidad en todo lo que ve. Y el resto del equipo teme tocar su
código o el diseño sin el.
 DESARROLLO ÁGIL
Fuentes:
AgileAlliance.org. (s/f). Extreme Programming (XP).
Bello, E. (2021). Descubre qué es el Extreme Programming y sus
características.
López, M. (2020). Extreme Programming: Qué es y cómo aplicarlo.
Mistry, A. (2019). Roles In Extreme Programming (XP).
ViewNext. (2020). Extreme Programming – XP.