Ekstreemprogrammeerimine

Tegevus

Ekstreemprogrammeerimises on neli põhitegevust, mis kuuluvad tarkvaarenduse protsessi juurde: koodi kirjutamine, testimine, kuulamine ja disainimine.

Koodi kirjutamine

Ekstreemprogrammeerimise pooldajad väidavad, et ainus tõeliselt oluline süsteemi arendamise protsessi saadus on kood – tarkvara juhised, mida arvuti saab interpreteerida. Ilma koodita pole ka töötavat tulemust.
Koodi kirjutamist saab kasutada ka selleks, et jõuda sobivaima lahenduseni. Koodi kirjutamine võib aidata vahetada mõtteid programmeerimise probleemide kohta. Programmeerija, kes tegeleb keeruka programmeerimisprobleemiga või kellel on raskusi lahenduse seletamisega kaasprogrammeerijatele, võib seda kirjutada lihtsustatult ning kasutada seda koodi näitamaks, mida ta mõtleb. Kood, ütlevad selle seisukoha pooldajad, on alati selge ja lühike ning seda ei saa tõlgendada mitmel viisil. Teistel programmeerijatel on võimalik anda tagasisidet koodile samuti koodi kirjutades.

Testimine

Ekstreemprogrammeerimise lähenemisviis seisneb selles, et kui vähene testimine võib kõrvaldada mõned vead, siis testides palju võib kõrvaldada kõvasti rohkem vigu.
Üksustestid teevad kindlaks, kas antud funktsioon töötab nii nagu mõeldud. Programmeerijad kirjutavad võimalikult palju automatiseeritud teste, mis võimaldavad koodis olevaid vigu päevavalgele tuua. Kui kõik testid jooksevad edukalt, siis on koodi kirjutamine lõpule viidud. Igat kirjutatud koodiosa testitakse enne järgmiste funktsioonide juurde liikumist.
Kasutuselevõtu testid kontrollivad, kas nõuded, nii nagu programmeerijad neist aru on saanud, vastavad kliendi tegelikele vajadustele.

Kuulamine

Programmeerijad peavad kuulama, mida klient soovib, et süsteem teeks seda, mida äriloogika nõuab. Oluline on mõista kliendi vajadusi piisavalt hästi, et osata anda talle tagasisidet probleemi lahendamise tehniliste aspektide kohta. Ekstreemprogrammeerimises rakendatavat kliendi ja programmeerija vahelist suhtlust nimetatakse plaanimismänguks.

Disainimine

Lihtsustatult vaadates võib öelda, et süsteemiarendus ei vaja rohkemat kui koodi kirjutamist, testimist ja kuulamist. Kui need tegevused on edukalt läbi viidud, peaks süsteem töötama. Praktikas see siiski nii lihtne ei ole. Disainimiseta võib saada palju tehtud, kuid ühel hetkel jäädakse jänni. Süsteem muutub liiga keeruliseks ning süsteemi sees olevad sõltuvused ei ole enam nii selged. Seda on võimalik vältida, luues disaini struktuuri, mis organiseerib süsteemis olevat loogikat. Hea disain väldib paljusid süsteemis esinevaid sõltuvusi: see tähendab, et süsteemi ühe osa muutmine ei mõjuta enam teisi osasid.

Ajalugu

Ekstreemprogrammeerimise lõi Kent Beck ajal, mil ta töötas Chrysler Comprehensive Compensation System (C3) palgaarvestussüsteemi projekti kallal. Beck sai C3 projektijuhiks märtsis 1996. aastal. Ta hakkas projektis kasutatud arendusmetoodikat viimistlema ning kirjutas sellest metoodikast raamatu "Extreme programming explained", mis ilmus 1999. aasta oktoobris.
Paljusid ekstreemprogrammeerimise praktikaid on kasutatud juba mõnda aega. Ekstreemprogrammeerimise metoodika viib "parima praktika" äärmuslikule tasemele. Näiteks, testide planeerimist ja kirjutamist enne igat mikrojuurdekasvu kasutati juba NASA Mercury programmi ajal varajastel 1960ndatel. Et lühendada kogu arenduseks kuluvat aega, on mõned formaalsed testidokumendid (nagu näiteks kasutuselevõtu test) välja töötatud paralleelselt tarkvara valmimisega testimiseks (või vahetult enne seda, kui tarvara on testimiseks valmis). NASA sõltumatu katserühm saab kirjutada katsemeetodeid, mis põhinevad vorminõuetel ja loogilistel piiridel juba enne, kui tarkvara on valmis kirjutatud ja riistvaraga integreeritud. See kontseptsioon on viidud ekstreemprogrammeerimises äärmuslikule tasemele, kirjutades automatiseeritud teste (nt tarkvara moodulite sees), mis kinnitavad isegi väikeste tarkvara kirjutamise osade operatsioone, mitte ei testi ainult suuremaid tunnusjooni.

Päritolu

1990ndatel kujundasid tarkvaraarendust peamiselt kaks tegurit: sisemine ja välimine tegur. Sisemiselt mõjutas tarkvaraarendust see, et protseduurilise programmeerimise asendas objektorienteeritud programmeerimine. Välimiseks mõjuteguriks oli interneti kasutamise kasv ja punkt-com buum, mis rõhutasid toodete turule jõudmise kiirust ning ettevõtte kasvu kui konkurentsile orienteeritud majandustegevuse faktoreid. Kiiresti muutuvad vajadused nõudsid lühemaid toote elutsükleid ja olid tihti vastuolus traditsiooniliste tarkvaraarenduse meetoditega.
Chrysler Comprehensive Compensation System (C3) projekti otsustati sisse tuua Kent Beck, silmapaistev smalltalki praktikant, et ta teeks süsteemile jõudluse häälestust, kuid Kent Becki roll laienes, kuna ta märkas seoses arendusprotsessiga mitmeid probleeme. Ta haaras kinni võimalusest esitada ja rakendada mõningaid muudatusi.
Beck kutsus projekti Ron Jeffriesi, et ta aitaks neid meetodeid arendada ja viimistleda. Jeffries tegutses seejärel treenerina, püüdes muuta praktikaid C3 tiimile harjumuseks.
Informatsiooni ekstreemprogrammeerimise taga olevate põhimõtete ja tavade kohta jagati laiemale maailmale läbi arutelude algupärases wikis, Cunninghami WikiWikiWebis. Erinevad panustajad arutasid ja arendasid teemat edasi ning selle tulemusel tekkisid mõningad spinn-off metoodikad, nt agiilne tarkvaraarendus. Lisaks on ekstreemprogrammeerimise mõisteid selgitatud mitu aastat, kasutades hüperteksti süsteemi kaarti ekstreemprogrammeerimise veebilehel http://www.extremeprogramming.org ca 1999.
Beck on toimetanud mitmeid ekstreemprogrammeerimise teemalisi raamatuid, kaasa arvatud tema enda kirjutatud raamat "Extreme programming explained" (1999, ISBN 0-201-61641-6), levitades oma ideid laiema publiku hulgas. Raamatute autorid on käinud läbi erinevaid aspekte seoses ekstreemprogrammeerimise ja selle praktikatega, mõni neist on lähenenud ka kriitilisema poole pealt.
Ekstreemprogrammeerimine tekitas tarkvarakogukondades märkimisväärset huvi 1990ndate lõpus ja 2000ndate alguses.