•     •   10 min read

Programación Extrema (XP): No
para los Débiles de Corazón

La Pro­gra­mación Extrema (XP) es una metodología ágil de desar­rol­lo de soft­ware. Al igual que otras metodologías ágiles, XP tiene sus her­ramien­tas, pro­ce­sos y roles úni­cos. El creador de XP, el desar­rol­lador esta­dounidense Kent Beck, no inven­tó nada com­ple­ta­mente nue­vo, sino que tomó las mejores prác­ti­cas del desar­rol­lo ágil y las ampli­ficó al extremo, de ahí el nom­bre Pro­gra­mación Extrema.

El autor de la metodología, Kent Beck, lid­eró el proyec­to del Sis­tema de Com­pen­sación Inte­gral de Chrysler a finales de los 90, donde aplicó por primera vez las prác­ti­cas de XP. Doc­u­men­tó su expe­ri­en­cia y el con­cep­to crea­do en el libro Pro­gra­mación Extrema Expli­ca­da,” pub­li­ca­do en 1999. A este libro le sigu­ieron otros que detal­la­ban las prác­ti­cas de XP. Los con­tribuyentes al desar­rol­lo de la metodología incluyen a Ward Cun­ning­ham, Mar­tin Fowler, y otros.
A difer­en­cia de otras metodologías ágiles, XP es exclu­si­va­mente uti­liza­da en el desar­rol­lo de soft­ware. No puede apli­carse a otros nego­cios o à la vida diaria como Scrum, Kan­ban o Lean. 
El obje­ti­vo de XP es hac­er frente a los req­ui­si­tos que cam­bian con­stan­te­mente para el pro­duc­to de soft­ware y mejo­rar la cal­i­dad del desar­rol­lo. Por lo tan­to, XP es ade­cua­da para proyec­tos com­ple­jos e inciertos.

XP gira en torno a cua­tro activi­dades fun­da­men­tales: cod­i­fi­cación, prue­bas, dis­eño y escucha. Además, la Pro­gra­mación Extrema tiene val­ores cen­trales: sim­pli­ci­dad, comu­ni­cación, retroal­i­mentación, cora­je y respeto.

13 Prác­ti­cas de la Pro­gra­mación Extrema

1. Todo el Equipo

Todos los par­tic­i­pantes del proyec­to que uti­lizan XP tra­ba­jan como un solo equipo. Este equipo debe incluir un rep­re­sen­tante del cliente, preferi­ble­mente un usuario final real que conoz­ca el nego­cio. El cliente establece los req­ui­si­tos del pro­duc­to y pri­or­iza la fun­cional­i­dad. Los anal­is­tas de nego­cio pueden asi­s­tir al cliente. Des­de el lado de los eje­cu­tores, el equipo incluye desar­rol­ladores, testers, a veces un coach que guía al equipo, y un ger­ente que pro­por­ciona recursos.

2. Juego de Planificación

La plan­i­fi­cación en XP ocurre en dos eta­pas: plan­i­fi­cación del lan­za­mien­to y plan­i­fi­cación de iteraciones.
  • Plan­i­fi­cación del Lan­za­mien­to: El equipo de pro­gra­mación se reúne con el cliente para deter­mi­nar la fun­cional­i­dad desea­da para el próx­i­mo lan­za­mien­to, gen­eral­mente en 2 – 6 meses. Dado que los req­ui­si­tos del cliente a menudo son vagos, los desar­rol­ladores los clar­i­f­i­can y los descom­po­nen en tar­eas que se pueden com­ple­tar en un día o menos. El cliente debe enten­der el entorno oper­a­ti­vo donde fun­cionará el pro­duc­to.

    Las tar­eas se reg­is­tran en tar­je­tas, y el cliente las pri­or­iza. Luego, los desar­rol­ladores esti­man el tiem­po requeri­do para cada tarea. Una vez que las tar­eas están descritas y esti­madas, el cliente revisa la doc­u­mentación y aprue­ba el ini­cio del tra­ba­jo. Para el éxi­to del proyec­to, es críti­co que el cliente y el equipo de pro­gra­mación jueguen en el mis­mo cam­po: el cliente elige la fun­cional­i­dad gen­uina­mente nece­saria den­tro del pre­supuesto, y los pro­gra­madores alin­ean apropi­ada­mente los req­ui­si­tos del cliente con sus capacidades.
  • Plan­i­fi­cación de Iteración: Se lle­va a cabo cada dos sem­anas, a veces más o menos fre­cuente­mente. El cliente está pre­sente para definir la fun­cional­i­dad para la próx­i­ma iteración y realizar cam­bios en los req­ui­si­tos del producto.

3. Lan­za­mien­tos Pequeños

Los lan­za­mien­tos de XP son fre­cuentes pero con fun­cional­i­dad lim­i­ta­da. Este enfoque facili­ta la prue­ba y man­ten­imien­to de la oper­a­tivi­dad del sis­tema y pro­por­ciona al cliente fun­cional­i­dades de val­or com­er­cial en cada iteración.

4. Prue­bas del Cliente

El cliente especi­fi­ca prue­bas de aceptación autom­a­ti­zadas para ver­i­ficar la fun­cional­i­dad del pro­duc­to. El equipo escribe estas prue­bas y las uti­liza para pro­bar el código.

5. Propiedad Colec­ti­va del Código

En XP, cualquier desar­rol­lador puede mod­i­ficar cualquier parte del códi­go, ya que el códi­go no pertenece a su autor, sino a todo el equipo.

6. Inte­gración Continua

Las nuevas partes del códi­go se inte­gran en el sis­tema de inmedi­a­to; los equipos de XP lan­zan una nue­va ver­sión cada pocas horas o más fre­cuente­mente. Esta prác­ti­ca ase­gu­ra que el impacto de los recientes cam­bios en el sis­tema sea vis­i­ble de inmedi­a­to. Si una nue­va pieza de códi­go rompe algo, iden­ti­ficar y cor­re­gir el error es mucho más fácil.

7. Están­dares de Codificación

Con la propiedad colec­ti­va del códi­go, adop­tar están­dares de cod­i­fi­cación comunes es cru­cial para que el códi­go parez­ca escrito por un solo pro­fe­sion­al. Los equipos pueden desar­rol­lar sus pro­pios están­dares o adop­tar los existentes.

8. Metá­fo­ra del Sistema

La metá­fo­ra del sis­tema es una com­para­ción con algo famil­iar para crear una visión com­par­ti­da den­tro del equipo. Típi­ca­mente, la per­sona que desar­rol­la la arqui­tec­tura y ve el sis­tema en su total­i­dad ideó la metáfora.

9. Rit­mo Sostenible

Los equipos de XP tra­ba­jan à la máx­i­ma pro­duc­tivi­dad mien­tras mantienen un rit­mo sostenible. La Pro­gra­mación Extrema desacon­se­ja el tra­ba­jo extra y pro­mueve una sem­ana lab­o­ral de 40 horas.

10. Desar­rol­lo Guia­do por Prue­bas (TDD)

Una de las prác­ti­cas más desafi­antes en XP. Los pro­gra­madores escriben prue­bas antes de escribir el códi­go que se va a pro­bar. Este enfoque garan­ti­za que cada pieza de fun­cional­i­dad esté com­ple­ta­mente cubier­ta por prue­bas. Cuan­do los desar­rol­ladores envían el códi­go, se eje­cu­tan de inmedi­a­to las prue­bas uni­tarias, y todas las prue­bas deben pasar, ase­gu­ran­do que el equipo se está movien­do en la direc­ción correcta.

11. Pro­gra­mación en Pareja

Imag­i­na a dos desar­rol­ladores tra­ba­jan­do en una com­puta­do­ra en una sola pieza de fun­cional­i­dad. Esta prác­ti­ca es la pro­gra­mación en pare­ja, la prác­ti­ca más con­tro­ver­ti­da en XP. El dicho dos cabezas pien­san mejor que una” ilus­tra bien su esen­cia. De dos solu­ciones a un prob­le­ma, se elige la mejor, el códi­go se opti­miza de inmedi­a­to, y se detectan errores antes de que ocur­ran, resul­tan­do en un códi­go limpio enten­di­do por ambos desarrolladores.

12. Dis­eño Simple

El dis­eño sim­ple en XP sig­nifi­ca hac­er solo lo que se nece­si­ta aho­ra, sin inten­tar pre­de­cir la fun­cional­i­dad futu­ra. El dis­eño sim­ple y la refac­tor­ización con­tin­ua cre­an un efec­to sinér­gi­co: cuan­do el códi­go es sim­ple, es más fácil optimizarlo.

13. Refac­tor­ización

La refac­tor­ización es el pro­ce­so con­tin­uo de mejo­rar el dis­eño del sis­tema para cumplir con nuevos req­ui­si­tos. Incluye la elim­i­nación de dupli­cación de códi­go, el aumen­to de la cohe­sión y la reduc­ción del acoplamien­to. XP exige una refac­tor­ización con­stante, de modo que el dis­eño del códi­go siem­pre se man­ten­ga simple.

Ven­ta­jas y Desven­ta­jas de XP

XP es con­tro­ver­ti­da y a menudo crit­i­ca­da por quienes no lograron imple­men­tar­la. Sin embar­go, sus ben­efi­cios son evi­dentes cuan­do el equipo uti­liza ple­na­mente al menos una prác­ti­ca de XP

Los ben­efi­cios de aspi­rar a XP incluyen:

  • Sat­is­fac­ción del Cliente: Los clientes obtienen el pro­duc­to que nece­si­tan, inclu­so si no tienen una visión clara des­de el principio.
  • Flex­i­bil­i­dad: El equipo real­iza cam­bios en el códi­go ráp­i­da­mente y añade nuevas fun­cional­i­dades debido a un dis­eño de códi­go sim­ple, plan­i­fi­cación fre­cuente y lanzamientos.
  • Fia­bil­i­dad: El códi­go siem­pre fun­ciona debido a prue­bas con­stantes e inte­gración continua.
  • Man­teni­bil­i­dad: El equipo puede man­ten­er fácil­mente el códi­go porque está escrito sigu­ien­do un úni­co están­dar y se refac­tor­iza constantemente.
  • Pro­duc­tivi­dad: Rit­mo de desar­rol­lo rápi­do debido à la pro­gra­mación en pare­ja, sin horas extras y la par­tic­i­pación del cliente.
  • Códi­go de Alta Calidad
  • Mit­i­gación de Ries­gos: Los ries­gos de desar­rol­lo se reducen ya que la respon­s­abil­i­dad se dis­tribuye equi­tati­va­mente, y el proyec­to no se ve com­pro­meti­do por la sal­i­da o lle­ga­da de miem­bros del equipo.
  • Efi­cien­cia de Cos­tos: Los cos­tos de desar­rol­lo son más bajos ya que el equipo se cen­tra en el códi­go en lugar de la doc­u­mentación y las reuniones.

A pesar de sus ven­ta­jas, XP no siem­pre fun­ciona y tiene varias debilidades:

  • Involu­cramien­to del Cliente: El éxi­to depende del involu­cramien­to del cliente, lo cual puede ser desafi­ante de lograr.
  • Pla­zos Impre­deci­bles: Es difí­cil pre­de­cir los cos­tos de tiem­po del proyec­to ya que la lista com­ple­ta de req­ui­si­tos es descono­ci­da al inicio.
  • Depen­den­cia del Niv­el de Habil­i­dad: XP depende en gran medi­da del niv­el de habil­i­dad de los pro­gra­madores y fun­ciona mejor con pro­fe­sion­ales senior.
  • Resisten­cia de la Gestión: La gestión a menudo se opone à la pro­gra­mación en pare­ja, cues­tio­nan­do la necesi­dad de pagar a dos pro­gra­madores en lugar de uno.
  • Cos­to: Las reuniones fre­cuentes con los pro­gra­madores pueden ser cos­tosas para los clientes.
  • Cam­bios Cul­tur­ales: Imple­men­tar XP requiere cam­bios cul­tur­ales significativos.
  • Fal­ta de Estruc­tura: La fal­ta de estruc­tura y doc­u­mentación de XP hace que no sea ade­cua­da para proyec­tos grandes.
  • Req­ui­si­tos No Fun­cionales: Los req­ui­si­tos fun­cionales son difí­ciles de describir como his­to­rias de usuario en metodologías ágiles.

Prin­ci­p­ios de XP

En su primer libro, Kent Beck delineó los sigu­ientes prin­ci­p­ios de XP: sim­pli­ci­dad, comu­ni­cación, retroal­i­mentación y cora­je. En una edi­ción pos­te­ri­or, añadió un quin­to prin­ci­pio: respeto.

1. Sim­pli­ci­dad

El desar­rol­lo de XP comien­za con la solu­ción más sim­ple que sat­is­face la necesi­dad fun­cional actu­al. Los miem­bros del equipo con­sid­er­an solo lo que nece­si­ta hac­erse aho­ra y no incor­po­ran fun­cional­i­dad que pue­da ser nece­saria en el futuro.

2. Comu­ni­cación

La comu­ni­cación en XP ocurre en vivo en lugar de a través de doc­u­mentación. El equipo se comu­ni­ca acti­va­mente entre sí y con el cliente.

3. Retroal­i­mentación

La retroal­i­mentación en XP se imple­men­ta de tres maneras:
  1. Retroal­i­mentación del Sis­tema: A través de prue­bas con­stantes de módulos.
  2. Retroal­i­mentación del Cliente: El cliente es parte del equipo y par­tic­i­pa en la escrit­u­ra de prue­bas de aceptación.
  3. Retroal­i­mentación del Equipo: Durante la plan­i­fi­cación, respec­to a las esti­ma­ciones de tiem­po de desarrollo.

4. Cora­je

Al algu­nas prác­ti­cas de XP son tan poco con­ven­cionales que requieren cora­je y auto­con­trol constante.

5. Respeto

El respeto en XP sig­nifi­ca respetar al equipo y el respeto a uno mis­mo. Los miem­bros del equipo no deben hac­er cam­bios que rompan la com­pi­lación, las prue­bas de módu­lo o ralen­ti­cen el tra­ba­jo de los cole­gas. Cada miem­bro se esfuerza por la más alta cal­i­dad de códi­go y diseño.

Imple­mentación de XP y el Flu­jo de Trabajo

Kent Beck recomien­da imple­men­tar XP para resolver prob­le­mas del proyec­to. El equipo selec­ciona el prob­le­ma más urgente y lo resuelve uti­lizan­do una de las prác­ti­cas de XP. Luego, pasan al sigu­iente prob­le­ma, uti­lizan­do otra prác­ti­ca. Este enfoque ase­gu­ra que los prob­le­mas motiv­en la adop­ción de XP, y el equipo dom­i­nará grad­ual­mente todas las her­ramien­tas de la metodología.

Para imple­men­tar XP en un proyec­to exis­tente, adopte grad­ual­mente sus prác­ti­cas en las sigu­ientes áreas:

  • Prue­bas: El equipo crea prue­bas antes de escribir nue­vo códi­go y refac­tor­iza grad­ual­mente el códi­go viejo.
  • Dis­eño: El equipo refac­tor­iza con­tin­u­a­mente el códi­go antiguo, típi­ca­mente antes de añadir nue­va funcionalidad.
  • Plan­i­fi­cación: El equipo debe inter­ac­tu­ar de cer­ca con el cliente.
  • Gestión: Los ger­entes ase­gu­ran que todos los miem­bros del equipo sigan las nuevas reglas.
  • Desar­rol­lo: Comience orga­ni­zan­do esta­ciones de tra­ba­jo para la pro­gra­mación en pare­ja y ani­mé a las pare­jas a pro­gra­mar la may­or parte del tiempo.

Ejem­p­lo de un Flu­jo de Tra­ba­jo Usan­do XP

Quién Usa XP

Según una encues­ta de Ver­sionOne de 2016, solo el 1% de las empre­sas ágiles usa XP en su for­ma pura. Otro 10% uti­liza un híbri­do de Scrum y XP.
Aunque XP no es la metodología más común, sus prác­ti­cas son uti­lizadas por la may­oría de las empre­sas que emplean metodologías ágiles. Por ejem­p­lo, Piv­otal Soft­ware, Inc. atribuye su éxi­to a XP.

Piv­otal Soft­ware, Inc.

Piv­otal Soft­ware, Inc. desar­rol­la análi­sis de nego­cio basa­dos en big data y pro­por­ciona ser­vi­cios de con­sul­toría. Sus pro­duc­tos son uti­liza­dos por cor­po­ra­ciones como Ford, Mer­cedes, BMW, GAP, Humana, prin­ci­pales ban­cos, agen­cias guber­na­men­tales y com­pañías de seguros.

Piv­otal abo­ga por metodologías ágiles como esen­ciales para el desar­rol­lo mod­er­no. Entre las vari­antes ágiles, eligieron XP, un enfoque que ben­e­fi­cia tan­to a los clientes como a los equipos de pro­gra­mación. Su jor­na­da lab­o­ral comien­za con reuniones de pie y ter­mi­na a las 6:00 PM — sin horas extra. Piv­otal uti­liza jue­gos de plan­i­fi­cación, pro­gra­mación en pare­ja, prue­bas con­stantes, inte­gración con­tin­ua, y otras prác­ti­cas de XP.

Qué Leer Para Enten­der XP

  1. Pro­gra­mación Extrema Expli­ca­da,” Plan­i­fi­cación de Pro­gra­mación Extrema,” Desar­rol­lo Guia­do por Prue­bas” de Kent Beck: Estos libros del creador de XP pro­por­cio­nan una com­pren­sión pro­fun­da de la metodología y sus ventajas.
  2. Refac­tor­ización: Mejo­ran­do el Dis­eño de Códi­go Exis­tente” de Mar­tin Fowler: Un libro de un coau­tor de XP que expli­ca los prin­ci­p­ios y téc­ni­cas de refactorización.
  3. Pro­gra­mación Extrema Apli­ca­da: Jugan­do para Ganar” de Ken Auer y Roy Miller: Una guía prác­ti­ca de las prác­ti­cas de XP con ejemplos.

Her­ramien­tas para Imple­men­tar XP en Equipos

Red­mine

Un gestor de tar­eas gra­tu­ito y de códi­go abier­to con car­ac­terís­ti­cas como soporte para múlti­ples proyec­tos, gestión de tar­eas flex­i­ble, grá­fi­cos de Gantt, seguimien­to de tiem­po, gestión de doc­u­mentación, y creación de tar­eas a través de correo electrónico.

Base­camp


Un ser­vi­cio sim­ple y fácil de usar para el tra­ba­jo colab­o­ra­ti­vo en proyec­tos, que incluye un gestor de tar­eas, tablones de men­sajes, chat inte­gra­do, alma­ce­namien­to de archivos y calendario.

Jira


Un robus­to ser­vi­cio dis­eña­do para desar­rol­ladores de proyec­tos ágiles, que com­bi­na un ras­treador de errores y una her­ramien­ta de gestión de proyec­tos con muchas car­ac­terís­ti­cas y opciones de sincronización.

Work­sec­tion


Un ser­vi­cio seguro para el tra­ba­jo en proyec­tos, que per­mite la con­fig­u­ración de tar­eas y el con­trol de pro­ce­sos, el seguimien­to de cor­re­spon­den­cias, la per­son­al­ización de fil­tros, el seguimien­to de tiem­po y financiero, y la gestión de archivos.

Con­clusión

La Pro­gra­mación Extrema es una metodología ágil cen­tra­da en pro­ducir códi­go fun­cional de alta cal­i­dad con una arqui­tec­tura sim­ple. Su propósi­to es reducir la incer­tidum­bre en los proyec­tos y respon­der de man­era flex­i­ble a los cam­bios en los req­ui­si­tos del producto. 

XP es exclu­si­va­mente para el desar­rol­lo de soft­ware y no puede adap­tarse a otros negocios. 
Es una de las metodologías más desafi­antes de imple­men­tar debido a sus trece prác­ti­cas. Sin embar­go, sus prác­ti­cas son ampli­a­mente uti­lizadas en proyec­tos ágiles, demostran­do su efectividad.

Los autores acon­se­jan dom­i­nar grad­ual­mente las prác­ti­cas de XP mien­tras se resuel­ven los prob­le­mas del proyec­to. Si ves los ben­efi­cios, con­tinúa en el mis­mo espíritu. No hay obligación de imple­men­tar XP de man­era todo o nada. Después de todo, las metodologías ágiles deben ser flex­i­bles en su apli­cación — adap­tán­dose a las necesi­dades del equipo de proyec­to específico.

esc
Compartir en
или
Escuela PM
Por qué el rastreador de tiempo de Worksection es la mejor opción para controlar los recursos del proyecto Las horas se registran de memoria y a menudo con retrasos. Las hojas de tiempo no están vinculadas...
2 mayo 2025   •   8 min read
Escuela PM
Las tareas dispersas en chats y tableros dificultan el control de la ejecución del proyecto. La dirección tiene que gastar la mayor parte de su tiempo sincronizando al equipo para averiguar el estado...
1 mayo 2025   •   8 min read
Escuela PM
La falta de comprensión de los plazos del proyecto, retrasos constantes, dificultad para coordinar procesos con los contratistas. El presupuesto está creciendo y el resultado se pospone constantemente...
30 abril 2025   •   7 min read
Empieza ahora
Por favor ingrese su correo electrónico real 🙂