La programació extrema —extreme programming en anglès, XP— és un mètode o una aproximació a l'enginyeria de programari, formulat per en Kent Beck, que va escriure el primer llibre sobre la matèria, Extreme Programming Explained: Embrace Change (). És un dels diversos processos àgils de desenvolupament.
Característiques fonamentals de la programació extrema Desenvolupament iteratiu i incremental: petites millores, una rere l'altra. Proves unitàries contínues, sovint repetides i automàtiques, incloent proves de regressió. S'aconsella d'escriure el codi de la prova abans de la codificació. Per exemple, JUnit. Programació per parelles: es recomana que les tasques de desenvolupament es duguin a terme per dues persones en un mateix lloc. Se suposa que la major qualitat del codi escrit d'aquesta forma (el codi és revisat i discutit mentre s'escriu) és més important que la possible pèrdua de productivitat immediata. Freqüent interacció de l'equip de programació amb el client o usuari. Es recomana que un representant del client treballi juntament amb l'equip de desenvolupament. Correcció de tots els errors abans d'afegir una nova funcionalitat. Fer entregues freqüents. Refactoreig del codi, és a dir, reescriure certes parts del codi per tal d'augmentar la seva llegibilitat i manteniment però sense modificar el seu comportament. Les proves han de garantir que en el refactoreig no s'ha introduït cap errada. Propietat del codi compartida: en lloc de dividir la responsabilitat en el desenvolupament de cada mòdul en grups de treball diferents, aquest mètode promou que tot el personal pugui corregir i estendre qualsevol part del projecte. Les freqüents proves de regressió garanteixen que els possibles errors seran detectats. Simplicitat en el codi: és la millor manera de què les coses funcionin. Quan tot funcioni es podrà afegir funcionalitat si cal.
Valors Per a garantir l'èxit d'un projecte, es consideren fonamentals els següents valors: Comunicació. La majoria de problemes són causats per manca de comunicació. Per aquesta raó, la comunicació entre els membres d'un equip i entre equip i clients s'ha de maximitzar. Un altre tipus de comunicació és entre els desenvolupadors i el codi. El codi ha d'expressar una intenció, no un algorisme. D'aquesta manera, no importarà qui hagi escrit cap funció perquè es podran llegir i modificar amb facilitat. Simplicitat. Esforç en fer que les coses més simples funcionin. No obstant això, aconseguir-ho és molt difícil. Requereix experiència, idees i treballar de valent. La simplicitat afavoreix la comunicació, redueix el codi i millora la qualitat. La principal pauta és no planejar futures possibles necessitats (noves característiques, quan realment es necessiten, seran fàcils d'afegir en un sistema simple). Realimentació. Les eines fonamentals de realimentació són l'estret contacte amb el client i la disponibilitat d'un conjunt de proves automatitzades, desenvolupades amb el mateix sistema. Requereix moltes i contínues proves per assegurar que el sistema funciona en tot moment. Així, quan es fan errors es troben immediatament. Coratge. Totes les metodologies i processos són eines que redueixen els temors. Com més por faci un projecte, majors i més dures seran les metodologies que es necessitaran. Comunicació, simplicitat i realimentació permeten afrontar amb coratge fins a grans canvis en requeriments. El coratge sol és perillós, però amb altres valors es converteix en una poderosa eina per afrontar canvis. Humilitat. Aquest valor deriva dels quatre anteriors. Si els membres d'un equip no es preocupen per ells ni pel seu treball, cap metodologia funcionarà. S'ha de ser respectuós amb els companys i les seves aportacions, amb l'empresa i amb aquells que estan implicats en el codi que s'està tocant. Amb aquests cinc valors, XP assegura dissenys i codis simples, mètodes eficients i clients contents. Els cinc valors no donen consells específics sobre com portar un projecte o com escriure programari. Per això, es necessiten unes pràctiques, i abans de les pràctiques, uns principis.
Principis Humanitat. El programari el desenvolupen persones, per tant els factors humans són la principal clau de la qualitat del programari. XP assigna els objectius a la gent i les seves organitzacions, pel benefici d'ambdós. Però és necessari trobar un equilibri entre objectius: Si se sobreestimen les necessitats de la gent, no es treballarà adequadament, amb la conseqüent baixa productivitat i pèrdues en el negoci. I si se sobreestimen les necessitats de l'organització, hi haurà inquietud, excés de treball i conflictes. Economia. En XP es diu que un dòlar avui val més que un dòlar demà. Aleshores, quant més aviat guanyi diners el desenvolupament de programari i més tard el gasti, més benefici crea el software. És molt útil poder endarrerir les despeses de disseny fins que siguin òbvies. Benefici mutu. Qualsevol activitat hauria de beneficiar a tota la gent i organitzacions implicades. Potser és aquest el principi de XP més important i el més difícil de mantenir. Sempre hi ha solucions senzilles per a qualsevol problema, on uns guanyen i altres perden. Sovint, aquestes solucions són dreceres temptadores. No obstant això, sempre suposen pèrdues perquè desmunten relacions personals i deterioren l'ambient de treball. Serà necessari solucionar més problemes dels que es creen. Per tant, són necessàries pràctiques que beneficiïn tant al treballador com al client, ara i al futur. Similitud en si mateixa. S'ha de ser capaç de reutilitzar solucions similars en diferents contextos. Per exemple, un patró bàsic de XP és escriure proves que fallen, i escriure codi que passi les proves. Això és cert en diverses escales de temps: en 15 minuts, s'enumeren els temes a resoldre, i llavors s'escriuen les històries que els descriuen; en una setmana, s'enumeren les històries a implementar, s'escriuen les proves d'acceptació i finalment s'escriu el codi que passi les proves; en poques hores, s'escriuen proves unitàries i després el codi capaç de passar-les. Millora. La clau són les contínues millores. La perfecció no existeix però s'ha de fer un esforç continu per aconseguir-la. A la pràctica, en cada iteració el sistema millora en qualitat i funcionalitats, utilitzant realimentació del client, de proves automatitzades i de l'equip en si. Diversitat. Els equips on tothom és del mateix estil són agradables, però no efectius. S'han d'incloure diferents coneixements, habilitats i caràcters per descobrir i solucionar problemes. D'altra banda, ser diferents porta a conflictes potencials, que han de ser controlats i resolts. Tenir diferents opinions i proposar distintes solucions és molt útil en desenvolupament de programari si es poden controlar i resoldre els conflictes i escollir la millor alternativa. Reflexió. Un equip efectiu no només fa el seu treball. Els membres de l'equip es qüestionen com treballen i per què treballen així. No amaguen errors i els fan explícits e intenten aprendre d'ells. Durant iteracions de 15 minuts i setmanals, es prenen un temps per reflexionar sobre com està funcionant el projecte i quines són les possibles millores. No obstant això, no s'ha de pensar en excés. L'enginyeria del programari té gent tan ocupada pensant sobre la millora del procés que ja no escriuen programari. La reflexió va després de l'acció, i abans de la següent acció. Flux. XP assumeix un continu flux d'activitats, no una seqüència de diferents fases amb llançament del programari només després de l'última. Només el flux continu permet la realimentació per assegurar que el sistema evoluciona en la direcció correcta i evita problemes relacionats amb la integració final big-bang. Oportunitat. Els problemes han de veure's com una oportunitat per a millorar. Sempre poden experimentar-se problemes, però per obtenir qualitat no es pot simplement corregir-los, sinó convertir-los en oportunitats d'aprendre i millorar. Per exemple, si un únic desenvolupador comet massa errors se'l posa a programar en parella. Redundància. Els problemes crítics i difícils haurien de resoldre's de diverses maneres. Així, si una solució falla, les altres eviten el desastre. El cost de la redundància és fàcilment amortitzat en aquests casos. Els defectes en programari han de buscar-se, trobar-se i reparar-se de moltes formes (programació en parelles, proves automatitzades, seure junts, implicació del client, etc.). Error. Si no es pot tenir èxit, falla. Si no se sap com implementar una història, llavors cal implementar-la de 3 o 4 formes. Encara que totes fallin, s'haurà après molt. L'error és útil sempre que t'ensenyi quelcom. Per tant, no s'ha de tenir por a fallar perquè és millor provar alguna cosa i fallar que endarrerir massa una acció intentant fer-la bé des del principi. Qualitat. La qualitat ha d'estar sempre al màxim. Acceptar una qualitat més baixa no produeix ni estalvis ni desenvolupaments més ràpids. En canvi, millorar la qualitat millora per força les característiques del sistema com la productivitat i l'eficiència. A més a més, la qualitat no és només un factor econòmic. Els membres de l'equip han d'estar orgullosos del seu treball perquè millora l'autoestima de l'equip i la seva efectivitat. Passos petits. Grans canvis en un llarg període són perillosos. És millor procedir iterativament en passos petits, el pas més petit que pugui ser apreciat en la direcció correcta. Aquests passos no tenen per què procedir lentament. Se’n poden fer molts en poc temps. Una de les raons per les quals XP dona suport als passos petits és perquè un pas petit en la direcció equivocada produeix petits danys, mentre que un gran pas que falli pot danyar el projecte de forma severa. Responsabilitat acceptada. És fàcil ordenar als desenvolupadors "fes això" o "fes allò altre", però aquest mètode no funciona. Inevitablement, demanes menys del que es podria aconseguir o, sovint, més del que es podria complir. De totes maneres, la persona que rep l'ordre decidirà realment si ser responsable i acceptar l'ordre, o bé no ser responsable i passar la pilota a algú altre.
Chrysler Comprehensive Compensation El primer cop que s'usa la programació extrema (XP) és en el projecte de Chrysler Chrysler Comprehensive Compensation (C3), un sistema per gestionar tots els pagaments dels quasi 90000 empleats de la Chrysler de l'any 1995. El projecte va començar com qualsevol altre, usant una metodologia tradicional, però un equip de 26 membres no va aconseguir cap resultat en els 15 primers mesos. Al març del 1996 Kent Beck es va fer càrrec del projecte i aprofità aquesta oportunitat per proposar i implementar canvis en la manera que hi havia de programar, basats en la feina que havien estat fent juntament amb Ward Cunningham. A més, convidà a Ron Jeffries a formar part del projecte per ajudar a desenvolupar i refinar aquests mètodes i ensenyar aquestes pràctiques a l'equip de C3. En tan sols 3 setmanes ja s'havia imprès el primer xec dels quasi 90000 empleats. Després d'això només calia preparar el sistema per imprimir els xecs restants. L'agost del 1998 C3 ja pagava els xecs de 10000 empleats, tot i que finalment va ser cancel·lat a principis del 2000 perquè el projecte ja no calia. El sistema anterior havia superat l'efecte 2000 i el nou projecte estava resultant massa car.
Tot i això el projecte C3 havia fet un canvi, era el primer gran projecte que utilitzava una metodologia àgil, i havia donat resultats, parcialment. Temps després Jawed Siddiqi va explicar:"Els problems que el projecte C3 va acabar trobant-se, per problemes de comuniació entre l'equip de desenvolupament i els dos equips d'accionistes administradors (el departament IS era el client i el departament de nòmines era l'usuari), va presentar una preocupació significativa perquè la comunicació entre els clients i l'equip es troba en el cor de l'aproximació XP."Amb aquest projecte varen quedar diverses coses demostrades sobre la XP: