Ekstreemprogrammeerimine – äärmuslik programmeerimine. Tarkvaraarenduse metoodikad

Jäta kommentaar 6,950

Saada oma head tööd teadmistebaasi on lihtne. Kasutage allolevat vormi

Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.

Postitatud aadressil http://www.allbest.ru/

Sisu

Sissejuhatus
1. Mis on XP?
3.1 PõhitehnikadXP
4. Eelised ja miinused
5. Kasutuslugu
Järeldus

Sissejuhatus

Extreme Programming, sageli lühendatult XP, on tarkvaraarenduse ja tarkvaraäri distsipliin, mis koondab mõlema poole (programmeerijad ja ärimehed) jõupingutused ühistele saavutatavatele eesmärkidele. XP-d kasutavad meeskonnad toodavad kvaliteetset tarkvara väga kiiresti. HR-distsipliini moodustavad tehnikad on valitud, kuna need põhinevad inimese loovusel ja aktsepteerimisel, et inimesed on muutlikud ja ekslikud olendid.

XP-d esitatakse sageli tehnikate kogumina, kuid XP ise ei ole finišijoon. Selleks, et selle protsessi lõpus kauaoodatud kuldtäht kätte saada, pole vaja HR-i järjest paremaks harjutada ja arendada. Vastupidi, XP on stardijoon. XP esitab küsimuse: "Kui minimaalsed saavad olla meie jõupingutused, et saaksime jätkata kvaliteetse tarkvara tootmist?"

Extreme Programming on lihtsustatud tootmismetoodika väikestele ja keskmise suurusega spetsialistide meeskondadele, kes arendavad tarkvaratoodet ebaselgete või kiiresti muutuvate nõuete tingimustes.

1. Mis on XP?

Extremamlinaneprogrammmhulkuv(Inglise) Ekstreemne Programmeerimine, XP) on üks paindlikke tarkvaraarenduse metoodikaid. Metoodika autorid on Kent Beck, Ward Cunningham, Martin Fowler jt.

XP on lihtsustatud, tõhus, paindlik, prognoositav, teaduspõhine ja väga nauditav madala riskitasemega viis tarkvara arendamiseks. HR erineb teistest meetoditest järgmistel viisidel:

Äärmiselt lühikesi arendustsükleid kasutades pakub XP kiiret, reaalset ja pidevat tagasisidet.

XP kasutab järkjärgulist planeerimist, mille tulemuseks on projekti üldine plaan üsna kiiresti, kuid on arusaadav, et see plaan areneb kogu projekti eluea jooksul.

XP kasutab selle või teise funktsionaalsuse juurutamiseks paindlikku ajakava, mis parandab reageerimist äri muutuvale olemusele ja sellega seoses muutuvatele klientide nõudmistele.

XP põhineb automatiseeritud testidel, mille on välja töötanud nii programmeerijad kui ka kliendid. Tänu nendele testidele on võimalik jälgida arendusprotsessi, tagada süsteemi korrektne areng ning koheselt tuvastada süsteemis esinevad defektid.

XP põhineb suulisel suhtlusel, testidel ja lähtekoodil. Neid kolme tööriista kasutatakse teabe vahetamiseks süsteemi struktuuri ja käitumise kohta.

XP põhineb areneval disainiprotsessil, mis kestab seni, kuni süsteem ise eksisteerib.

XP põhineb tihedal suhtlusel kõige levinumate oskuste ja võimalustega programmeerijate vahel.

XP põhineb tehnikatel, mis rahuldavad nii üksikute programmeerijate lühiajalisi instinkte kui ka kogu projekti pikaajalisi huve.

XP on tarkvaraarenduse distsipliin. See on distsipliin, sest XP-s on teatud asju, mida peate tegema, kui kavatsete XP-d kasutada. Te ei tohiks valida, kas kirjutada teste või mitte, sest kui te seda ei tee, pole programmeerimine äärmuslik.

XP metoodika on loodud töötama projektidega, mille kallal saavad töötada kaks kuni kümme programmeerijat, mida ei piira olemasoleva arvutikeskkonna jäigad piirangud ja milles kõik vajalikud testimistööd on ühe päeva jooksul tehtud.

2. Kust algab ekstreemprogrammeerimine?

Kust algab ekstreemprogrammeerimine? Arusaamisest, et kodumaise tarkvaraarendaja tüüppositsioon kohustab arenduskulusid nii palju kui võimalik vähendama. Ja selleks on vaja kliendiga intensiivset koostööd teha, tema huvidest aru saada ja lõpuks teha täpselt seda, mida ta tahab: ei rohkem ega vähem.

Äärmuslik programmeerimine ei põhine konkreetsetel tehnikatel, nagu tavaliselt arvatakse, vaid ainult neljal põhiprintsiibil: suhtlus, lihtsus, tagasiside ja julgus. Siit tulebki alustada.

Extreme Programming pakub valmislahendust: hoidke kõik võimalikult lihtne, hoidke klient omaette või jääge kliendiga koos, laske tal aktiivselt arendusprotsessi jälgida, tervitage muutust – ja edu on peaaegu garanteeritud.

XP meeskondades on suhtlemine alati soodustatud – see on kiireim viis info ja kogemuste jagamiseks. See on väga oluline, kui on vaja maksimaalset arenduskiirust. Kuid suhtlemine, nagu iga teinegi kasulik ettevõtmine, nõuab pidevat tuge. Seetõttu peab keegi meeskonnast võtma vastutuse kommunikatsiooni jälgimise eest, saades n-ö diplomaadiks. Suhtlemine ja vajadus oma tegevust teistele meeskonnaliikmetele selgitada sunnib kõike tegema võimalikult lihtsalt. Kui see esimesel korral ei õnnestu, töötavad nad ikka ja jälle lihtsustamise kallal, kuni saavutatakse peamine eesmärk - koodi maksimaalne arusaadav teistele arendajatele.

Ükskõik, mida me ka ei teeks – nõelasid või peole läheme –, püüdleme alati mingi eesmärgi poole. Kui märkame, et kaldume sellest kõrvale, kohandame oma tegevusi vastavalt. Kujutage nüüd ette, kui palju raskem on kinnisilmi nõelale niidi tõmmata või ilma peeglita kaunilt riietuda! Kuid programme arendades juhtub sageli nii: me teeme midagi, mille tulemust me ei näe. Seetõttu on äärmusliku programmeerimise puhul reegel näha oma tegevuse tulemust võimalikult kiiresti. Või tehniliselt öeldes anda võimalikult kiiresti tagasisidet.

Extreme Programming küsib meilt: miks mitte arendada julgust? Lõppude lõpuks on ta oma töös väga oluline. Kas ilma julguseta on võimalik võtta vastutus ülesande täitmise eest ja seda kindla aja jooksul? Kas ilma julguseta on võimalik mõista, et olete jõudnud ummikusse, astuda samm tagasi ja otsida lahendust? Ja lõpuks, mis võimaldab arendajal tunnistada oma viga ülesande hindamisel ja hoiatada sellest õigel ajal teisi, selle asemel, et esitada neile fait accompli alles siis, kui kõik tähtajad on möödas? Julguse eelised on ilmsed ja iga õnnestumine, isegi kõige väiksemas ülesandes, võib seda julgust arendada.

3. XP tehnikad

Extreme Programming (XP) tekkis alt-üles tarkvaraarenduse evolutsioonilise meetodina. See lähenemine on näide nn agiilse arendusmeetodist. “Live” meetodite rühma kuuluvad lisaks äärmuslikule programmeerimisele meetodid SCRUM, DSDM (Dynamic Systems Development Method, meetod dünaamiliste süsteemide arendamiseks), Feature-Driven Development (süsteemi funktsioonidest juhitud arendus) jne.

Reaalajas tarkvaraarenduse põhiprintsiibid on kirjas 2000. aastal ilmunud reaalarengu manifestis.

· Projektiga seotud inimesed ja nende suhtlus on olulisemad kui protsessid ja tööriistad.

· Tööprogramm on olulisem kui põhjalik dokumentatsioon.

· Lepingu üksikasjade läbirääkimisest olulisem on koostöö kliendiga.

· Muudatuste läbi töötamine on olulisem kui plaanidest kinnipidamine.

“Elavad” meetodid ilmnesid protestina tarkvaraarenduse liigse bürokratiseerimise, lõpptulemuse saamiseks mittevajalike kõrvaldokumentide rohkuse vastu, mis tuleb projekti teostamisel koostada enamiku “raskete” protsesside järgi. , lisatööd organisatsiooni fikseeritud protsessi toetamiseks, nagu see on vajalik näiteks CMM-is. Suurem osa sellistest töödest ja dokumentidest ei ole otseselt seotud tarkvaraarenduse ja kvaliteedi tagamisega, vaid on mõeldud arenduslepingute formaalsete punktide täitmiseks, erinevatele standarditele vastavuse sertifikaatide hankimiseks ja kinnitamiseks.

"Live" meetodid võimaldavad arendajatel keskenduda suurema osa oma jõupingutustest arendusülesannetele ja kasutajate tegelike vajaduste rahuldamisele. Dokumendihunnikute puudumine ja vajadus neid ühtses olekus hoida võimaldab kiiremini ja tõhusamalt reageerida muutustele nõuetes ja keskkonnas, milles tulevane programm toimima peab.

XP-l on aga oma arendusprotsessi diagramm (kuigi üldiselt on laialt levinud arusaam "arendusprotsessist" kui üsna jäigast tegevusskeemist vastuolus "elava" arengu ideega), mis on näidatud joonisel 1. .

XP autorite sõnul ei järgi see tehnika mitte niivõrd mõnda üldist tegevusmustrit, kuivõrd järgmiste tehnikate kombinatsiooni. Iga tehnika on aga oluline ja ilma selle kasutamiseta ei peeta arendust XP-ks, väidab Kent Beck, kes on üks selle lähenemise autoreid koos Ward Cunninghami ja Ron Jeffriesiga.

· Otseplaneerimine (planeeriminemängu)

Selle ülesandeks on võimalikult kiiresti kindlaks määrata töömaht, mis tuleb teha enne järgmist tarkvaraversiooni. Otsus tehakse esiteks kliendi prioriteetidest (st tema vajadustest, sellest, mida ta süsteemist oma äri edukamaks ajamiseks vajab) ja teiseks tehniliste hinnangute (st keerukuse hinnangud) põhjal. arendus, ühilduvus süsteemi teiste elementidega jne). Plaane muudetakse kohe, kui need hakkavad tegelikkusest või kliendi soovidest erinema.

Riis.1 XP töövoo diagramm

· SagemuutaVversioonid (väikevabastab)

Esimene tööversioon peaks ilmuma võimalikult kiiresti ja seda tuleks kohe kasutama hakata. Järgnevad versioonid valmistatakse ette üsna lühikeste ajavahemike järel (alates mitmest tunnist väikese programmi väikeste muudatuste korral kuni kuu või kaheni suure süsteemi suuremaks ümbertöötamiseks). Toote versioonid (väljalasked) tuleks kasutusele võtta nii sageli kui võimalik. Iga versiooni valmimine peaks võtma võimalikult vähe aega. Pealegi peab iga versioon olema ettevõtlusele kasulikkuse mõttes piisavalt sisukas.

· Metafoor (metafoor) süsteemid

Metafoor, üsna lihtsal ja meeskonnale arusaadaval kujul, peaks kirjeldama süsteemi põhimehhanismi. See kontseptsioon meenutab arhitektuuri, kuid peaks kirjeldama tehniliste otsuste põhiolemust palju lihtsamalt, vaid ühe või kahe fraasiga.

Arhitektuur on mingi ettekujutus süsteemi komponentidest ja nende omavahelistest seostest. Arendajad kasutavad arhitektuuri, et mõista, kuhu süsteemi uusi funktsioone lisatakse ja millega mõni uus komponent suhtleb.

Süsteemi metafoor on analoog sellele, mida enamikus tehnikates nimetatakse arhitektuuriks. Süsteemi metafoor annab meeskonnale aimu, kuidas süsteem praegu töötab, kuhu lisatakse uusi komponente ja millisel kujul need peaksid olema.

· Lihtnedisainlahendusi (lihtnedisain)

Süsteem peaks igal ajahetkel olema võimalikult lihtne. Funktsioone pole vaja eelnevalt lisada – ainult pärast selgesõnalist taotlust. Kogu ebavajalik keerukus eemaldatakse kohe pärast selle avastamist.

XP lähtub sellest, et töö käigus võivad probleemi tingimused korduvalt muutuda, mis tähendab, et arendatavat toodet ei tohiks tervikuna ette kujundada. Kui proovite süsteemi esmakordsel käivitamisel algusest lõpuni üksikasjalikult kavandada, raiskate oma aega. XP eeldab, et projekteerimine on nii oluline protsess, et seda tuleb teha pidevalt kogu projekti vältel. Projekteerimine peab toimuma väikeste sammudena, arvestades pidevalt muutuvaid nõudeid. Püüame igal hetkel kasutada kõige lihtsamat kujundust, mis praeguse probleemi lahendamiseks sobib. Samal ajal muudame seda probleemi tingimuste muutudes.

· Arengpealalustestimine (test- sõidetudarengut)

Arendajad kirjutavad esmalt testid, seejärel proovivad oma mooduleid juurutada, et testid töötaksid. Kliendid kirjutavad eelnevalt testid, mis demonstreerivad süsteemi peamisi võimalusi, et nad näeksid, kas süsteem ka tegelikult töötab.

XP paneb erilist rõhku kahte tüüpi testimisele:

ь ühikutestimine;

b vastuvõtutest.

äärmuslik programmeerimistarkvara

Arendaja ei saa olla kindel enda kirjutatud koodi õigsuses enne, kui absoluutselt kõik tema arendatava süsteemi moodulite testid on toiminud. Ühikutestid võimaldavad arendajatel kontrollida, kas nende kood töötab õigesti. Samuti aitavad need teistel arendajatel mõista, miks konkreetset koodiosa on vaja ja kuidas see toimib. Ühiktestid võimaldavad arendajal ka muretult ümber töötada.

Vastuvõtutestid tagavad, et süsteemil on tegelikult märgitud võimalused. Lisaks võimaldavad vastuvõtutestid kontrollida arendatava toote nõuetekohast toimimist.

XP puhul on kõrgema prioriteediga lähenemine nimega TDD (Test Driven Development), kõigepealt kirjutatakse test, mis ei läbi, seejärel kirjutatakse kood nii, et test läheb läbi ja alles siis kood refaktoreeritakse.

· Püsivringlussevõtt (refaktoreerimine)

Pole saladus, et iga uue funktsionaalsuse lisamine ja koodi kasv raskendab arendust, vigade tuvastamist ja hilisemate muudatuste tegemist. Üks Extreme Programmingi nippe on kompenseerida funktsionaalsuse lisamist kooditäiustustega. See on kooditöötlus ehk refaktoreerimine.

Programmeerijad töötavad pidevalt süsteemi ümber, et kõrvaldada tarbetu keerukus, suurendada koodi arusaadavust, suurendada selle paindlikkust, kuid muutmata selle käitumist, mida kontrollitakse pärast iga testide ümbertöötamist käivitades. Samas eelistatakse elegantsemaid ja paindlikumaid lahendusi, võrreldes nendega, mis annavad lihtsalt soovitud tulemuse. Ebaõnnestunud ümberkujundatud komponendid tuleks testimise käigus tuvastada ja viia tagasi viimasesse puutumatusse olekusse (koos nendest sõltuvate komponentidega).

Refaktoreerimine on tehnika koodi täiustamiseks ilma selle funktsionaalsust muutmata. XP tähendab, et kui kood on kirjutatud, kirjutatakse see peaaegu kindlasti projekti käigus mitu korda ümber. XP arendajad töötlevad varem kirjutatud koodi halastamatult ümber, et seda täiustada. Seda protsessi nimetatakse refaktoreerimiseks. Testi katvuse puudumine kutsub esile refaktoreerimisest keeldumise, kuna kardetakse süsteemi purunemist, mis viib koodi järkjärgulise halvenemiseni.

· Programmeeriminepaarides (paarprogrammeerimine)

Kogenud arendajad on märganud, et teiste inimeste koodi perioodiline ülevaatamine mõjutab selle kvaliteeti positiivselt. Ekstreemse programmeerimise meistrid on selle lähenemisviisi välja töötanud, vaadates arenduse ajal koodi pidevalt üle paarisprogrammeerimiseks kutsutava tehnika abil.

Kodeerimist teostavad kaks programmeerijat ühes arvutis. Sidumine on meelevaldne ja erineb ülesandeti. See, kelle käes olev klaviatuur püüab praegust probleemi parimal viisil lahendada. Teine programmeerija analüüsib esimese tööd ja annab nõu, arvestab teatud otsuste tagajärgedega, uute testidega, vähem otseste, kuid paindlikumate lahendustega. Vajadusel kandub klaviatuur vabalt ühelt teisele. Projekti kallal töötades pole paarid fikseeritud: soovitatav on need omavahel segada, et igal meeskonna programmeerijal oleks kogu süsteemist hea arusaam. Sel moel tõhustab paarisprogrammeerimine meeskonnasisest koostööd.

· Kollektiivomaminekood (kollektiivneomandiõigus)

Kollektiiv omamine tähendab, et iga meeskonnaliige vastutab kogu lähtekoodi eest. Seega on igaühel õigus teha muudatusi programmi mis tahes osas. Paarprogrammeerimine toetab seda praktikat: erinevates paarides töötades saavad kõik programmeerijad tuttavaks kõigi süsteemi koodi osadega. Jagatud koodiomandi oluline eelis on see, et see kiirendab arendusprotsessi, kuna vea ilmnemisel saab iga programmeerija selle parandada.

Andes igale programmeerijale õiguse koodi muuta, riskime vigadega, mille on sisse toonud programmeerijad, kes arvavad, et teavad, mida nad teevad, kuid ei arvesta teatud sõltuvustega. Täpselt määratletud UNIT-testid lahendavad selle probleemi: kui uurimata sõltuvused tekitavad vigu, siis järgmine UNIT-testide käitamine ebaõnnestub.

· Püsivintegratsiooni (pidevintegratsiooni)

Süsteem pannakse kokku ja läbib integratsioonitesti nii sageli kui võimalik, mitu korda päevas, iga kord, kui paar programmeerijat lõpetab järgmise funktsiooni juurutamise.

Kui integreerite arendatavat süsteemi piisavalt sageli, saate vältida enamikku sellega seotud probleemidest. Traditsiooniliste meetodite puhul viiakse integreerimine läbi tavaliselt tootega töötamise lõpus, kui arvestatakse, et kõik arendatava süsteemi komponendid on täielikult valmis. XP-s toimub kogu süsteemi koodiintegratsioon mitu korda päevas pärast seda, kui arendajad on kindlad, et kõik seadmetestid käivituvad õigesti.

Vaatamata oma lihtsusele on sellel tehnikal omad kasutusreeglid, nagu integreeritava funktsionaalsuse olemasolevate ühikutestide edukus, funktsionaalsus- või vastuvõtutestide olemasolu ja loomulikult võimalus naasta eelmisesse olekusse. . Tavaliselt teostavad integreerimise ja sellega seotud raskuste lahendamise eraldi arvutis paar programmeerijat. See võimaldab teil minimeerida integratsiooni soovimatute tagajärgede riski.

· 40 tunditöötavadnädal

Ületunnitöös nähakse märki suurematest probleemidest projektis. Ületunnitöö 2 nädalat järjest ei ole lubatud – see kurnab programmeerijaid ja muudab nende töö oluliselt vähem tootlikuks.

Seda ei dikteeri mitte ainult seaduslikkuse ja inimlikkuse kaalutlused, vaid ennekõike töö efektiivsuse tõstmise ja range korralduse vajadus. Ekstreemprogrammeerimine on ju kollektiivne mäng, mis on mõeldud mitte üksikisikutele, vaid kogu rühmale. Ja selline asi nagu näiteks paarisprogrammeerimine on võimalik ainult siis, kui selles osalejate biorütmid on sünkroniseeritud. Ja see on võimatu, kui üks inimene tuleb tööle kell üheksa ja teine kell kaksteist või üks otsustab, et tal on parem laupäeval ja pühapäeval töötada, samal ajal kui teisel on ebamugav.

Kõige tähtsam on aga see, et tervise ja töövõime säilitamiseks vajab inimene korralikku puhkust. Kaheksatunnine tööpäev ja viiepäevane töönädal on kehtestatud just maksimaalse tootlikkuse huvides. Paljudes Lääne ettevõtetes peetakse töölt hiljaks jätmist suutmatus töös hästi toime tulla või suutmatust oma tööaega õigesti juhtida. Enamikul juhtudel on see tõsi. Meditsiinilisest vaatenurgast põhjustavad viivitused tööl pidevat väsimust, ärrituvust ja ajutegevuse vähenemist. Kas see on tõhus? Kuidas saaksime sellises meeskonnas korraldada pidevat avatud suhtlust arendajate vahel ja kas paarisprogrammeerimine on võimalik? Vastus on eitav. Standardid on standardid ja neid tuleks järgida.

· KaasamineklientVmeeskond (peal- saidileklient)

Arendusmeeskonda kuulub alati kliendiesindaja, kes on kättesaadav kogu tööpäeva jooksul ja suudab vastata kõikidele süsteemi puudutavatele küsimustele. Tema kohustuseks on kiiresti vastata mis tahes tüüpi küsimustele, mis puudutavad süsteemi funktsioone, selle liidest, nõutavat jõudlust, süsteemi õiget toimimist keerulistes olukordades, vajadust hoida sidet teiste rakendustega jne.

Paljud kahtlevad kliendi kaasamise võimalikkuses arendusprotsessi. Tõepoolest, kliendid on erinevad. Kui klienti või tema esindajat ei ole võimalik meelitada, on mõnikord soovitatav palgata ajutiselt arendatava ala spetsialist. See samm vähendab ebaselgust töös, suurendab arenduskiirust ja lähendab projekti sellele, mida klient soovib saada. Sellest võib kasu olla ka rahalise poole pealt: on ju programmeerija palk kohati oluliselt kõrgem kui teiste valdkondade spetsialistide palk.

· KasutaminekoodKuidasrajatisedside

Koodi peetakse meeskonnasiseseks kõige olulisemaks suhtlusvahendiks. Koodi selgus on üks peamisi prioriteete. Selle selguse tagavate kodeerimisstandardite järgimine on hädavajalik. Sellised standardid peaksid lisaks koodi selgusele tagama minimaalse keelekasutuse (koodi ja teabe dubleerimise puudumine) ning kõik meeskonnaliikmed peaksid neid aktsepteerima.

· Avatudtöötavadruumi (avatudtööruum)

Meeskond on paigutatud ühte küllalt avarasse ruumi, et hõlbustada suhtlemist ja võimaldada grupivestlusi planeerimisel ja oluliste tehniliste otsuste tegemisel.

· MuudareeglidKõrvalvajadus (lihtsaltreeglid)

Iga meeskonnaliige peab nõustuma loetletud reeglitega, kuid vajaduse korral saab meeskond neid muuta, kui kõik tema liikmed on selle muudatusega nõus.

Nagu kasutatud tehnikatest näha, on XP mõeldud kasutamiseks väikestes meeskondades (mitte rohkem kui 10 programmeerijat), mida selle tehnika autorid rõhutavad. Suurem meeskonna suurus hävitab edu saavutamiseks vajaliku suhtluslihtsuse ja muudab paljude loetletud tehnikate rakendamise võimatuks.

3.1 XP põhitehnikad

Kaksteist äärmusliku programmeerimise põhitehnikat (raamatu esimese väljaande põhjal Ekstreemne programmeerimine selgitas) saab ühendada nelja rühma:

· Lühike tagasiside tsükkel (peene skaala tagasiside)

o Testipõhine arendus

o Planeerimismäng

o Klient on alati läheduses (terve meeskond, kohapealne klient)

o Paarisprogrammeerimine

Pigem pidev kui partiiprotsess

o Pidev integratsioon

o Refactoring (disaini täiustamine, ümberehitamine)

o Sagedased väikesed väljaanded

· Kõigile jagatud arusaam

o Lihtsus (lihtne disain)

o Süsteemi metafoor

o Kollektiivne koodi omand või valitud kujundusmustrid (kollektiivsete mustrite omandiõigus)

o kodeerimisstandard või kodeerimise kokkulepped

· Programmeerija heaolu:

o 40-tunnine töönädal (jätkusuutlik tempo, neljakümnetunnine nädal)

MängVplaneerimine

Ekstreemprogrammeerimises on planeerimine arenduse lahutamatu osa ja seda, et plaanid võivad muutuda, võetakse arvesse juba alguses. Tugipunkt, tehnika, mis võimaldab olukorda ennustada ja muutustega valutult leppida, on planeerimismäng. Sellise mängu käigus saab teadaolevaid süsteeminõudeid kiiresti kokku koguda, hinnata ja prioriteedi järgi planeerida.

Nagu igal teisel mängul, on ka planeerimisel oma osalejad ja eesmärk. Võtmefiguur on loomulikult klient. Tema on see, kes teatab vajadusest selle või selle funktsionaalsuse järele. Programmeerijad annavad igale funktsioonile ligikaudse hinnangu. Planeerimismängu ilu seisneb eesmärgi ühtsuses ja solidaarsuses arendaja ja tellija vahel: võidu korral võidavad kõik, kaotuse korral kaotavad kõik. Kuid samas läheb iga osaleja oma teed võiduni: klient valib vastavalt eelarvele välja olulisemad ülesanded ning programmeerija hindab ülesandeid vastavalt oma võimekusele neid ellu viia.

Ekstreemprogrammeerimine eeldab, et arendajad saavad ise otsustada, kui kaua neil oma ülesannete täitmine aega võtab ja kumb neist oleks valmis rohkem lahendama üht ja kes teist.

Ideaalses olukorras tuleks planeerimismängu kliendi ja programmeerija vahel mängida iga 3-6 nädala tagant, kuni algab järgmine arendusiteratsioon. See muudab eelmise iteratsiooni õnnestumiste ja ebaõnnestumiste põhjal muudatuste tegemise üsna lihtsaks.

4. Eelised ja miinused

XP eelisteks, kui seda on võimalik rakendada, on suurem paindlikkus, võimalus kiiresti ja täpselt teha tarkvaras muudatusi vastavalt muutuvatele nõuetele ja kliendi individuaalsetele soovidele, saadud koodi kõrge kvaliteet ja vajaduse puudumine veenda kliente, et tulemus vastab nende ootustele.

Selle lähenemisviisi miinusteks on selles stiilis piisavalt suurte ja keerukate projektide teostamatus, suutmatus planeerida projekti ajastust ja keerukust piisavalt pikaks ajaks ning prognoosida selgelt pikaajalise projekti tulemusi suhte osas. tulemuse kvaliteedist ning aja- ja ressursside kuludest. Samuti võib märkida, et XP ei sobi nendeks puhkudeks, mille puhul ei leita koheselt võimalikke lahendusi varasemate kogemuste põhjal, vaid eeldavad eeluuringut.

5. Kasutuslugu

XP-d kui kirjeldatud tehnikate kogumit kasutati esmakordselt projekti C3 kallal (Chrysleri terviklik kompensatsioonisüsteem, Daimler Chrysleri töötajate hüvitiste arvestamise süsteemi väljatöötamine). Selle projekti 20 osalejast 5 (sealhulgas ülalmainitud 3 XP peamist autorit) avaldasid projekti enda ja hiljem XP-le pühendatud 3 raamatut ja tohutul hulgal artikleid. Järgmised andmed illustreerivad mõningate XP-tehnikate probleeme, kui neid kasutatakse üsna keerukate projektide puhul.

Projekt sai alguse 1995. aasta jaanuaris. Alates 1996. aasta märtsist, pärast Kent Becki kaasamist, on seda käitatud XP-ga. Selleks ajaks oli see juba ületanud eelarve ja funktsioonide etapiviisilise rakendamise plaanid. Arendusmeeskond kärbiti ja umbes kuus kuud pärast seda arenes projekt üsna edukalt. 1998. aasta augustis ilmus prototüüp, mis võiks teenindada umbes 10 000 töötajat. Projekt pidi algselt lõppema 1999. aasta keskpaigas ja sellest tulenevat tarkvara kasutataks ettevõtte 87 000 töötaja hüvitiste haldamiseks. See peatati 2000. aasta veebruaris pärast 4 aastat kestnud XP käitamist, kuna ajaraamid ja eelarve ei vastanud täielikult. Loodud tarkvara pole kunagi kasutatud rohkem kui 10 000 töötaja andmetega töötamiseks, kuigi on näidatud, et see suudab töödelda 30 000 ettevõtte töötaja andmeid. Projektimeeskonda kaasatud kliendi rolli täitnud inimene lahkus pärast mõnekuulist sellist tööd, suutmata töökoormust taluda, ega saanud enne projekti lõpuni adekvaatset asendust.

Järeldus

Kõik ülaltoodud meetodid ei ole juhuslikult kokku pandud. Nende järjekindel kombinatsioon võib viia arendusprotsessi intellektuaalsesse resonantsi, tõstes oluliselt toote kvaliteeti ja kiirendades selle väljalaskeaega. Kogu ekstreemse programmeerimise peamine ilu on prognoositavus ja arenduskulude minimeerimine; anda kliendile vabastamise hetkel toode, mida ta soovib saada; ja loomulikult suhtlemine ja arendajate koolitamine töökohal.

Arvamused pakutud metoodika kohta võivad erineda. Oluline on mõista, et äärmusliku programmeerimise eesmärk ei ole olemasolevate arendustehnoloogiate asendamine. Vastupidi, XP võib anda täiendavat tõuget traditsioonilisi lähenemisviise kasutavatele meeskondadele. Te ei tohiks siit otsida vastuseid kõigile oma küsimustele. See ei ole programmeerimistehnoloogia, vaid pigem töö organiseerimise tehnoloogia ja just sellisel kujul on tal õigus elule.

Postitatud saidile Allbest.ru

Sarnased dokumendid

Optimaalse ja toimiva ARIS mudeli - IDS Scheeri tarkvaratoote ettevõtte äriprotsesside modelleerimiseks - väljatöötamise etappide ja iseärasuste analüüs. Ekstreemse programmeerimise põhimõistete, metoodikate ja lähenemisviiside õppimine.

test, lisatud 04.06.2011

Tarkvaraarenduse põhietapid (tarkvarapakett), süsteeminõuete analüüs. Samm-sammult detailide esitamise meetod. Madala taseme ja kõrgetasemelised programmeerimiskeeled (imperatiivsed, objektorienteeritud, funktsionaalsed, loogilised).

esitlus, lisatud 13.10.2013

Arenduskeel, teostuskeskkond, arendusvahendid. Virtuaalse keskkonna omadused programmide juurutamiseks ja nende arvestamine tarkvaratoote arendamisel. Süsteemimakrod ja nende kasutamine arendustekstides. Visuaalsed programmeerimise tööriistad.

õpetus, lisatud 26.10.2013

Tarkvara töökindluse probleem, selle näitajad ja tugitegurid. Programmide ja dokumentatsiooni arendusprotsessi jälgimise meetodid, vigade ennetamine. Tarkvara silumisprotsessi etapid, struktureeritud programmeerimise tehnikad ja modulaarsuse põhimõte.

esitlus, lisatud 30.04.2014

Masinakoodid ja komplekteerija. Esimesed kõrgetasemelised programmeerimiskeeled. FORTRAN programmeerimiskeel. ALGOLi eelised ja puudused. Teadus- ja raamatupidamisprogrammid. Põhiprintsiibid, millest lähtuti programmeerimiskeele Basic loomisel.

kursusetöö, lisatud 21.06.2014

Hajutatud tarkvaraarenduse kontseptsioon ja peamised erinevused, selle eelised ja puudused. Kontseptuaalne lahendus ja arendustüübi valik. Avatud lähtekoodiga tarkvara omadused. Avatud lähtekoodi idee ja areng.

kursusetöö, lisatud 14.12.2012

Tarkvara elutsükli mõiste. Tehnilistes projektides eristatakse kahte tüüpi tegevusi: projekteerimine ja tootmine. Paindlike metoodikate järgijate manifesti põhitõed. Ekstreemse programmeerimise põhiprintsiibid.

esitlus, lisatud 14.08.2013

Pascali programmeerimiskeele rahvusvaheline standard. Objektorienteeritud programmeerimise tehnikad Turbo Pascalis. Keele sümbolid, selle tähestik. Programmi arendamise etapid. Algoritmide mõiste ja algoritmiseerimine. Programmide struktuur Pascalis.

kursusetöö, lisatud 28.02.2010

Kaasaegsed tarkvaraarenduse tööriistad juhtimissüsteemide jaoks. Universaalsed programmeerimiskeeled ja nende võrdlus SCADA süsteemidega. Tarkvaraarendus mitmekanaliliste mõõtemuundurite Ш9327 abil.

lõputöö, lisatud 13.07.2011

Delphi programmeerimiskeskkonnas töötamise põhitehnikad. Lihtsate rakenduste loomise tehnoloogia omadused. Töö rakenduste arenduskeskkonna komponentidega. Info sisestamine, redigeerimine, valik ja väljastamine. Hargnemisstruktuuri kasutamise aspektid.

Extreme Programming või XP, eXtreme Programming on paindlik tarkvaraarenduse metoodika. Nagu teistelgi agiilsetel metoodikatel, on sellel spetsiifilised tööriistad, protsessid ja rollid. Kuigi XP autor ei tulnud välja millegi uuega, vaid võttis agiilse arenduse parimad tavad ja tugevdas neid maksimaalselt. Seetõttu nimetatakse programmeerimist äärmuslikuks.

Meetodi autor on Ameerika arendaja Kent Beck. 90ndate lõpus juhtis ta Chrysleri tervikliku kompensatsioonisüsteemi projekti ja oli seal äärmusliku programmeerimise teerajaja. Ta kirjeldas oma kogemust ja loodud kontseptsiooni 1999. aastal ilmunud raamatus Extreme Programming Explained. Sellele järgnesid teised XP tavasid kirjeldavad raamatud. Metoodika väljatöötamisse olid kaasatud ka Ward Cunningham, Martin Fowler jt.

XP erineb teistest agiilsetest metoodikatest selle poolest, et see kehtib ainult tarkvaraarenduse valdkonnas. Seda ei saa kasutada muus äris ega igapäevaelus, nagu scrum, kanban või lean.

XP metoodika eesmärk on tulla toime pidevalt muutuvate nõuetega tarkvaratootele ja parandada arenduse kvaliteeti. Seetõttu sobib XP hästi keeruliste ja ebakindlate projektide jaoks

XP metoodika on üles ehitatud nelja protsessi ümber: kodeerimine, testimine, kujundamine ja kuulamine. Lisaks on Extreme Programmingi väärtusteks lihtsus, suhtlemine, tagasiside, julgus ja austus.

1. Kogu meeskond

Kõik XP-d kasutavad projektis osalejad töötavad ühe meeskonnana. See peab sisaldama kliendi esindajat, parem, kui see on toote tegelik lõppkasutaja, kes mõistab äri. Klient esitab tootele nõuded ja seab prioriteediks funktsionaalsuse juurutamise. Ärianalüütikud saavad teda aidata. Täitmise poolel kuuluvad meeskonda arendajad ja testijad, mõnikord treener, kes juhendab meeskonda, ja juht, kes varustab meeskonda ressurssidega.

2. Planeerimismäng

Planeerimine XP-s toimub kahes etapis - väljalaske planeerimine ja iteratsiooni planeerimine.

Väljalaske planeerimise käigus kohtub programmeerimismeeskond kliendiga, et selgitada välja, millist funktsionaalsust ta soovib saada järgmiseks väljalaseks ehk 2-6 kuu pärast. Kuna klientide nõuded on sageli ebamäärased, täpsustavad arendajad need ja jagavad osadeks, mille elluviimine ei võta rohkem kui ühe päeva. Oluline on, et klient mõistaks töökeskkonda, milles toode töötab.

Tööülesanded kirjutatakse kaartidele ja klient määrab nende prioriteedi. Järgmisena hindavad arendajad, kui palju aega iga ülesanne võtab. Kui ülesanded on kirjeldatud ja hinnatud, vaatab klient dokumentatsiooni üle ja annab luba töö alustamiseks. Projekti õnnestumiseks on ülioluline, et klient ja programmeerimismeeskond mängiksid samal alal: klient valib eelarve piires välja reaalselt vajaliku funktsionaalsuse ning programmeerijad võrdlevad adekvaatselt kliendi nõudmisi oma võimalustega.

Kui XP-s pole meeskonnal aega väljalaskekuupäevaks kõiki ülesandeid täita, siis väljalaset ei lükata tagasi, vaid lõigatakse osa kliendi jaoks kõige vähem olulisest funktsionaalsusest.

Teostatakse iteratsiooni planeerimine iga kahe nädala tagant, mõnikord rohkem või vähem sageli. Klient on alati kohal: ta määrab järgmise iteratsiooni funktsionaalsuse ja teeb muudatusi tootenõuetes.

3. Sagedased versiooniväljaanded

XP-s avaldatakse versioone sageli, kuid vähese funktsionaalsusega. Esiteks on väikest funktsionaalsust lihtne testida ja kogu süsteemi funktsionaalsust hooldada. Teiseks saab klient iga iteratsiooni osa funktsionaalsusest, millel on äriline väärtus.

4. Kasutajatestid

Klient ise määratleb automaatsed vastuvõtutestid, et kontrollida toote järgmise funktsiooni funktsionaalsust. Meeskond kirjutab need testid ja kasutab neid valmis koodi testimiseks.

5. Kollektiivne omand

XP-s saab iga arendaja redigeerida mis tahes koodijuppi, kuna... Koodi ei ole selle autorile määratud. Kood kuulub kogu meeskonnale.

6. Pidev koodide integreerimine

See tähendab, et uued koodijupid on kohe süsteemi sisse ehitatud – XP meeskonnad laadivad iga paari tunni järel või sagedamini üles uue versiooni. Esiteks on kohe näha, kuidas viimased muudatused süsteemi mõjutavad. Kui uus koodijupp midagi rikub, on vea leidmine ja parandamine palju lihtsam kui nädal hiljem. Teiseks töötab meeskond alati süsteemi uusima versiooniga.

7. Kodeerimisstandardid

Kui kood on igaühel, on oluline järgida ühtseid disainistandardeid, et kood näeks välja nagu selle oleks kirjutanud üks professionaal. Saate välja töötada oma standardid või võtta vastu valmis.

8. Süsteemi metafoor

Süsteemi metafoor on süsteemi võrdlus millegi tuttavaga, et luua meeskonna vahel ühine nägemus. Tavaliselt mõtleb süsteemi metafoori välja isik, kes disainib arhitektuuri ja kujutab ette süsteemi kui tervikut.

9. Ühtlane tempo

XP meeskonnad töötavad maksimaalse tootlikkusega, säilitades samal ajal ühtlase tempo. Samas suhtub ekstreemprogrammeerimine ületundidesse negatiivselt ja propageerib 40-tunnist töönädalat.

10. Testipõhine arendus

Metoodika üks raskemaid praktikaid. XP-s kirjutavad testid programmeerijad ise, ENNE testimist vajava koodi kirjutamist. Selle lähenemisviisi korral on iga funktsionaalsus 100% testidega kaetud. Kui paar programmeerijat laadivad hoidlasse koodi üles, käivitatakse koheselt ühikutestid. Ja nad KÕIK peaksid töötama. Siis on arendajad kindlad, et liiguvad õiges suunas.

11. Paarisprogrammeerimine

Kujutage ette kahte arendajat ühes arvutis, kes töötavad ühe tootefunktsiooni kallal. See on paarisprogrammeerimine, XP kõige vastuolulisem praktika. Vana ütlus “üks pea on hea, kaks on parem” illustreerib suurepäraselt lähenemise olemust. Kahe probleemi lahendamise variandi hulgast valitakse parim, kood optimeeritakse kohe ja vead püütakse kinni enne nende tekkimist. Selle tulemusena on meil puhas kood, mida kaks arendajat on hästi kursis.

12. Lihtne disain

Lihtne disain XP-s tähendab, et teete ainult seda, mida praegu vajate, ilma et prooviksite arvata tulevasi funktsioone. Lihtne disain ja pidev ümberkujundamine avaldavad sünergistlikku mõju – kui kood on lihtne, on seda lihtne optimeerida.

13. Refaktoreerimine

Refactoring on protsess, mille käigus täiustatakse pidevalt süsteemi disaini, et see vastaks uutele nõuetele. Refaktoreerimine hõlmab dubleeriva koodi eemaldamist, sidususe suurendamist ja sidumise vähendamist. XP hõlmab pidevat ümbertegemist, nii et koodikujundus jääb alati lihtsaks.

XP eelised ja puudused

XP metoodika tekitab palju poleemikat ja kriitikat nende poolt, kes pole seda kunagi oma meeskonnas rakendada suutnud.

Ekstreemse programmeerimise eelised on mõttekad, kui meeskond kasutab täielikult ära vähemalt ühe XP tavadest. Niisiis, mille nimel tasub proovida:

klient saab täpselt sellise toote, mida ta vajab, isegi kui ta arenduse alguses ise selle lõplikku vormi täpselt ette ei kujuta
meeskond teeb kiiresti koodimuudatusi ja lisab uusi funktsioone lihtsa koodikujunduse, sagedase planeerimise ja väljalaske kaudu
kood töötab alati tänu pidevale testimisele ja pidevale integreerimisele
meeskond hooldab koodi hõlpsalt, sest see on kirjutatud ühtse standardi järgi ja seda muudetakse pidevalt ümber
kiire arengutempo tänu paarisprogrammeerimisele, vähesele ümbertegemisele, kliendi kohalolekule meeskonnas
kõrge koodi kvaliteet
arenguga kaasnevad riskid vähenevad, sest vastutus projekti eest on jaotatud ühtlaselt ja meeskonnaliikme lahkumine/saabumine ei riku protsessi
arenduskulud on väiksemad, sest meeskond on koodile orienteeritud, mitte dokumentatsioonile ja koosolekutele

Vaatamata kõikidele eelistele ei tööta XP alati ja sellel on mitmeid nõrkusi. Niisiis, äärmuslik programmeerimine - puudused:

projekti edukus sõltub kliendi kaasamisest, mida pole nii lihtne saavutada
Projektile kuluvat aega on raske ennustada, sest... alguses ei tea keegi täielikku nõuete loetelu
XP edukus sõltub tugevalt programmeerijate tasemest, metoodika töötab ainult vanemspetsialistidega
juhtkond suhtub paarisprogrammeerimisse negatiivselt, mõistmata, miks peaks maksma ühe programmeerija asemel kaks
Regulaarsed kohtumised programmeerijatega on klientidele kulukad
nõuab liiga palju kultuurilisi muutusi
struktuuri ja dokumentatsiooni puudumise tõttu ei sobi suurprojektide jaoks
sest Agiilsed metoodikad on funktsionaalselt orienteeritud, mittefunktsionaalseid nõudeid tootekvaliteedile on kasutajalugude näol raske kirjeldada.

XP põhimõtted

Oma esimeses raamatus sõnastas Kent Beck äärmusliku programmeerimise põhimõtted: lihtsus, suhtlemine, tagasiside ja julgus. Raamatu uues väljaandes lisas ta viienda põhimõtte – austuse.

1. Lihtsus

XP-s algab arendus kõige lihtsamast lahendusest, mis rahuldab praeguse funktsionaalsuse vajaduse. Meeskonnaliikmed võtavad arvesse ainult seda, mida on vaja praegu teha, ega panusta koodi funktsionaalsusesse, mida läheb vaja homme, kuu aja pärast või mitte kunagi.

2. Suhtlemine

XP-s toimub arendajatevaheline suhtlus mitte dokumentatsiooni, vaid otseülekande kaudu. Meeskond suhtleb aktiivselt nii omavahel kui ka kliendiga.

3. Tagasiside

XP-s tagasisidet rakendatakse korraga kolmes suunas:

tagasiside süsteemist moodulite pideva testimise käigus
tagasiside kliendilt, sest ta on osa meeskonnast ja osaleb vastuvõtutestide kirjutamises
planeerimise ajal meeskonna tagasiside arendusaja kohta.

4. Julgus

Mõned äärmuslikud programmeerimistehnikad on nii ebatavalised, et nõuavad julgust ja pidevat enesekontrolli.

5. Austus

Ekstreemprogrammeerimises vaadeldakse austust meeskonna vastu ja eneseaustusena. Meeskonnaliikmed ei tohiks üles laadida muudatusi, mis rikuvad kompileerimist, ühikuteste või aeglustavad kolleegide tööd. Kõik püüdlevad kõrgeima kvaliteediga koodi ja disaini poole.

XP metoodika ja tööprotsessi rakendamise algoritm

Beck Kent soovitab projekti probleemide lahendamiseks rakendada XP-d. Meeskond valib kõige pakilisema probleemi ja lahendab selle ühe äärmusliku programmeerimise praktika abil. Seejärel liigub rohkem harjutades järgmise probleemi juurde. Selle lähenemise korral toimivad probleemid XP kasutamise motivatsioonina ja meeskond omandab järk-järgult kõik metoodika tööriistad.

XP juurutamiseks olemasolevasse projekti peate järk-järgult omandama selle tehnikad järgmistes valdkondades:

testimine
disain
planeerimine
juhtimine
arengut

Testimine.

Meeskond loob testid ENNE uue koodi kirjutamist ja töötab järk-järgult vana koodi ümber. Vana koodi puhul kirjutatakse testid vastavalt vajadusele: kui on vaja lisada uusi funktsioone, parandada viga või osa vanast koodist ümber töötada.

Disain.

Meeskond muudab vana koodi järk-järgult ümber, tavaliselt enne uute funktsioonide lisamist. Nagu testimise puhul, tehakse vana koodi ümberkujundamine ainult vajaduse korral. Samal ajal peaks meeskond sõnastama pikaajalised eesmärgid koodi ümbertöötamiseks ja neid järk-järgult saavutama.

Planeerimine.

Meeskond peab üle minema tihedale suhtlusele kliendiga. Selles etapis on oluline anda talle edasi arendajatega ühes meeskonnas töötamise eelised ja integreerida ta meeskonda.

Juhtimine.

Juhtide roll XP-le üleminekul on tagada, et kõik meeskonnaliikmed töötaksid uute reeglite järgi. Projektijuht otsustab, millal lahkuda meeskonnaliikmest, kes uues keskkonnas tööga toime ei tule, või leida uus ja ta korralikult töösse integreerida.

Areng.

Muutused arenduses saavad alguse tööjaamade organiseerimisest programmeerimiseks paarikaupa. Järgmine väljakutse on programmeerida enamasti paarikaupa, olenemata sellest, kui keeruline see arendajatele ka poleks.

XP metoodika järgi töötavas projektis on protsess üles ehitatud järgmiselt:

Kes kasutab XP-d

Versionone'i 2016. aasta uuringu kohaselt kasutab ainult 1% agiilsetest ettevõtetest ekstreemprogrammeerimist puhtal kujul. Veel 10% töötab hübriidse scrumi ja XP metoodika abil.

Huvitav on see, et kuigi XP ei ole puhtal kujul kaugeltki kõige levinum metoodika, kasutab selle tavasid enamik agiilsete metoodikate kallal töötavaid ettevõtteid. Seda tõendavad sama uuringu andmed:

XP-d kasutavate meeskondade kohta pole lihtne infot leida, kuid on neid, kes reklaamivad, et just see metoodika on nende edu põhjuseks. Ekstreemse programmeerimise näide on Pivotal Software, Inc.

Pivotal Software, Inc.

Ameerika tarkvarafirma, mis arendab suurandmetel põhinevat ärianalüüsi tarkvara ja pakub nõustamisteenuseid. Pivotal tooteid kasutavad Ford, Mercedes, BMW, GAP, Humana, suured pangad, riigiasutused, kindlustusfirmad jne.

Pivotal pooldab agiilseid metoodikaid kui ainuvõimalikke kaasaegses arengus. Kõigist paindlike metoodikate valikutest valis ettevõte XP kui klientidele ja programmeerimismeeskondadele kasulik lähenemisviis. Iga tööpäev algab koosolekuga liikvel olles ja lõpeb täpselt kell 18.00 – ületunde pole. Pivotal kasutab mängude planeerimist, paarisprogrammeerimist, pidevat testimist, pidevat integreerimist ja muid XP tavasid. Paljude tavade jaoks on neil oma tarkvara.

äärmuslik programmeerimine,
Äärmuslik programmeerimine: planeerimine,
Äärmuslik programmeerimine: katsepõhine arendus / Kent Beck

Ekstreemprogrammeerimisest metoodika loojalt Kent Beckilt. Alustage esimesest, mis kirjeldab XP kontseptsiooni näidetega ja põhjendab selle eeliseid. Hiljem avaldas autor veel mitu raamatut, kus kirjeldas üksikasjalikult üksikuid XP tavasid.

Refactoring: Improving Existing Code / Martin Fowler

Äärmuslik programmeerimine: protsessi formuleerimine. Esimestest sammudest kibeda lõpuni / Ken Auer, Roy Miller

Kuna Extreme Programming püüdleb puhta ja hõlpsasti hooldatava koodi poole, on raamatute loendis kõik väljaanded, mis õpetavad paremini programmeerima.

Rakendused XP juurutamiseks meeskonnas

XP metoodikat kasutavate projektidega töötavad meeskonnad kasutavad agiilsete projektide jaoks tegumihaldureid ja teenuseid. Selliseid tooteid on turul palju, vaatame paar näidet.

Tasuta ja avatud lähtekoodiga tegumihaldur. Põhifunktsioonid: töötamine mitme projektiga korraga, paindlik ülesannete haldussüsteem, Gantti diagramm, ajakontroll, töö dokumentatsiooniga, ülesannete loomine meili teel jne.

Lihtne ja mugav teenus projektidel koostööks. Sisaldab tegumihaldurit, teadetetahvlit, sisseehitatud vestlust, failide salvestusruumi, kalendrit

Jira

Võimas teenus, mis on loodud spetsiaalselt agiilsete projektide arendajatele. Ühendab veajälgija ja projektihaldusteenuse. Paljud funktsioonid ja sünkroonimine teiste teenustega. Lahendused erineva suurusega meeskondadele.

Projektidega töötama. Võimaldab seada ülesandeid ja juhtida täitmisprotsessi, pidada ülesandeid omavahel kirjas, seadistada filtreid, arvestada aja- ja rahakuluga ning töötada failidega.

Kohtuotsus

Extreme Programming on paindlik metoodika, mis keskendub kvaliteetsele, töötavale lihtsa arhitektuuriga koodile. Selle eesmärk on vähendada projektide ebakindlust ja tõeliselt paindlikult reageerida tootenõuete muutumisele.

See metoodika on mõeldud ainult valdkonna jaoks tarkvara arendus ja seda ei saa teise ettevõtte jaoks kohandada.

See on üks kõige raskemini rakendatavaid metoodikaid, sest see sisaldab tervelt kolmteist praktikat!

Vähesed ettevõtted riskivad töötada puhta XP kallal, kuid selle arendustavad on agiilsete projektide puhul kõige populaarsemad. Ja see on tugev argument nende tõhususe kasuks.

Keegi ei sunni teid XP-d juurutama kõik või mitte midagi põhimõttel. Lõppkokkuvõttes peavad agiilsed metoodikad olema oma rakendamisel paindlikud – kohandatud konkreetse meeskonna ja projekti vajadustele.

Arendus (süsteemi funktsioonidest juhitud areng) jne.

Reaalajas planeerimismäng
Selle ülesandeks on võimalikult kiiresti kindlaks määrata töömaht, mis tuleb teha enne järgmist tarkvaraversiooni. Otsus tehakse esiteks kliendi prioriteetidest (st tema vajadustest, sellest, mida ta süsteemist oma äri edukamaks ajamiseks vajab) ja teiseks tehniliste hinnangute (st keerukuse hinnangud) põhjal. arendus, ühilduvus süsteemi teiste elementidega jne). Plaane muudetakse kohe, kui need hakkavad tegelikkusest või kliendi soovidest erinema.
Sagedased versioonimuudatused (väikesed väljaanded)
Esimene tööversioon peaks ilmuma võimalikult kiiresti ja seda tuleks kohe kasutama hakata. Järgnevad versioonid valmistatakse ette üsna lühikeste ajavahemike järel (alates mitmest tunnist väikese programmi väikeste muudatuste korral kuni kuu või kaheni suure süsteemi suuremaks ümbertöötamiseks).
Süsteemi metafoor
Metafoor, üsna lihtsal ja meeskonnale arusaadaval kujul, peaks kirjeldama süsteemi põhimehhanismi. See kontseptsioon meenutab arhitektuuri, kuid peaks kirjeldama tehniliste otsuste põhiolemust palju lihtsamalt, vaid ühe või kahe fraasiga.
Lihtsad disainilahendused
Süsteem peaks igal ajahetkel olema võimalikult lihtne. Funktsioone pole vaja eelnevalt lisada – ainult pärast selgesõnalist taotlust. Kogu ebavajalik keerukus eemaldatakse kohe pärast selle avastamist.
Testipõhine arendus
Arendajad kirjutavad esmalt testid, seejärel proovivad oma mooduleid juurutada, et testid töötaksid. Kliendid kirjutavad eelnevalt testid, mis demonstreerivad süsteemi peamisi võimalusi, et nad näeksid, kas süsteem ka tegelikult töötab.
Pidev refaktoreerimine
Programmeerijad töötavad pidevalt süsteemi ümber, et kõrvaldada tarbetu keerukus, suurendada koodi arusaadavust, suurendada selle paindlikkust, kuid muutmata selle käitumist, mida kontrollitakse pärast iga testide ümbertöötamist käivitades. Samas eelistatakse elegantsemaid ja paindlikumaid lahendusi, võrreldes nendega, mis annavad lihtsalt soovitud tulemuse. Ebaõnnestunud ümberkujundatud komponendid tuleks testimise käigus tuvastada ja viia tagasi viimasesse puutumatusse olekusse (koos nendest sõltuvate komponentidega).
Paari programmeerimine
Kodeerimist teostavad kaks programmeerijat ühes arvutis. Sidumine on meelevaldne ja erineb ülesandeti. See, kelle käes olev klaviatuur püüab praegust probleemi parimal viisil lahendada. Teine programmeerija analüüsib esimese tööd ja annab nõu, arvestab teatud otsuste tagajärgedega, uute testidega, vähem otseste, kuid paindlikumate lahendustega.
Koodi kollektiivne omand
Iga meeskonnaliige saab igal ajal koodi mis tahes osa muuta. Kellelgi ei tohiks olla oma vastutusvaldkonda, koodi eest vastutab kogu meeskond tervikuna.
Pidev integreerimine
Süsteem pannakse kokku ja läbib integratsioonitesti nii sageli kui võimalik, mitu korda päevas, iga kord, kui paar programmeerijat lõpetab järgmise funktsiooni juurutamise.
40-tunnine töönädal
Ületunnitöös nähakse märki suurematest probleemidest projektis. Ületunnitöö 2 nädalat järjest ei ole lubatud – see kurnab programmeerijaid ja muudab nende töö oluliselt vähem tootlikuks.
Kliendi kaasamine meeskonda (kohapealne klient)
Arendusmeeskonda kuulub alati kliendiesindaja, kes on kättesaadav kogu tööpäeva jooksul ja suudab vastata kõikidele süsteemi puudutavatele küsimustele. Tema kohustuseks on kiiresti vastata mis tahes tüüpi küsimustele, mis puudutavad süsteemi funktsioone, selle liidest, nõutavat jõudlust, süsteemi õiget toimimist keerulistes olukordades, vajadust hoida sidet teiste rakendustega jne.
Koodi kasutamine suhtlusvahendina
Koodi peetakse meeskonnasiseseks kõige olulisemaks suhtlusvahendiks. Koodi selgus on üks peamisi prioriteete. Selle selguse tagavate kodeerimisstandardite järgimine on hädavajalik. Sellised standardid peaksid lisaks koodi selgusele tagama minimaalse keelekasutuse (koodi ja teabe dubleerimise puudumine) ning kõik meeskonnaliikmed peaksid neid aktsepteerima.
Avatud tööruum
Meeskond on paigutatud ühte küllalt avarasse ruumi, et hõlbustada suhtlemist ja võimaldada grupivestlusi planeerimisel ja oluliste tehniliste otsuste tegemisel.
Reeglite muutmine vastavalt vajadusele (ainult reeglid)
Iga meeskonnaliige peab nõustuma loetletud reeglitega, kuid vajaduse korral saab meeskond neid muuta, kui kõik tema liikmed on selle muudatusega nõus.

XP eelisteks, kui seda on võimalik rakendada, on suurem paindlikkus, võimalus kiiresti ja täpselt teha tarkvaras muudatusi vastavalt muutuvatele nõuetele ja kliendi individuaalsetele soovidele, saadud koodi kõrge kvaliteet ja vajaduse puudumine veenda kliente, et tulemus vastab nende ootustele.

XP-d kui kirjeldatud tehnikate kogumit kasutati esmakordselt projekti C3 kallal (Chrysleri terviklik kompensatsioonisüsteem, Daimler Chrysleri töötajate hüvitiste arvestamise süsteemi väljatöötamine). Selle projekti 20 osalejast 5 (sealhulgas ülalmainitud 3 XP peamist autorit) avaldasid projekti enda ja hiljem XP-le pühendatud 3 raamatut ja tohutul hulgal artikleid. Seda projekti mainitakse erinevates allikates korduvalt selle tehnika kasutamise näitena. Järgmised andmed on koostatud mainitud artiklitest, millest on maha arvatud anekdootlikud tõendid, ja illustreerivad mõningate XP-tehnikate probleeme, kui neid kasutatakse üsna keerukate projektide puhul.

Extreme Programming (XP) on üks paindlikke tarkvaraarenduse metoodikaid. Metoodika autorid on Kent Beck, Ward Cunningham, Martin Fowler jt.

Planeerimismäng

Meie maailm on liiga muutlik ja ettearvamatu, et loota olukorra püsivusele. Tarkvaraarenduses juhtub sama: haruldase süsteemi puhul võib öelda, et selle lõplik vorm oli juba arenduse alguses täpselt ette teada. Tavaliselt tekib kliendi isu söömise ajal: ta tahab pidevalt midagi muuta, täiustada või midagi süsteemist üldse välja visata. See on nõuete muutlikkus, mida kõik nii kardavad. Õnneks antakse inimesele võimalus võimalikke valikuid ette näha ja seeläbi olukord kontrolli all hoida.
Ekstreemprogrammeerimises on planeerimine arenduse lahutamatu osa ja seda, et plaanid võivad muutuda, võetakse arvesse juba alguses. Tugipunkt, tehnika, mis võimaldab olukorda ennustada ja muutustega valutult leppida, on planeerimismäng. Sellise mängu käigus saab teadaolevaid süsteeminõudeid kiiresti kokku koguda, hinnata ja prioriteedi järgi planeerida.
Nagu igal teisel mängul, on ka planeerimisel oma osalejad ja eesmärk. Võtmefiguur on loomulikult klient. Tema on see, kes teatab vajadusest selle või selle funktsionaalsuse järele. Programmeerijad annavad igale funktsioonile ligikaudse hinnangu. Planeerimismängu ilu seisneb eesmärgi ühtsuses ja solidaarsuses arendaja ja tellija vahel: võidu korral võidavad kõik, kaotuse korral kaotavad kõik. Kuid samas läheb iga osaleja oma teed võiduni: klient valib vastavalt eelarvele välja olulisemad ülesanded ning programmeerija hindab ülesandeid vastavalt oma võimekusele neid ellu viia.
Ekstreemprogrammeerimine eeldab, et arendajad saavad ise otsustada, kui kaua neil oma ülesannete täitmine aega võtab ja kumb neist oleks valmis rohkem lahendama üht ja kes teist.
Ideaalses olukorras tuleks planeerimismängu kliendi ja programmeerija vahel mängida iga 3-6 nädala tagant, kuni algab järgmine arendusiteratsioon. See muudab eelmise iteratsiooni õnnestumiste ja ebaõnnestumiste põhjal muudatuste tegemise üsna lihtsaks.

Väljalaskeplaan

Väljalaskeplaanis on määratletud väljalaskekuupäevad ja kasutajaavaldused, mida kõigis neist rakendatakse. Selle põhjal saate valida järgmise iteratsiooni jaoks formulatsioonid. Iteratsiooni ajal koostatakse ja käitatakse aktsepteerimistestid selle iteratsiooni ja kõigi järgnevate jooksul, et tagada programmi korrektne toimimine. Plaani võib üle vaadata, kui mõne iteratsiooni lõpus on märkimisväärne viivitus või edumaa.
Iteratsioonid. Iteratsioon muudab arendusprotsessi dünaamiliseks. Pole vaja oma tarkvara ülesandeid pikalt ette planeerida. Selle asemel on parem korraldada planeerimiskoosolek iga iteratsiooni alguses. Pole mõtet püüda ellu viia midagi, mis polnud plaanis. Sul on veel aega nende ideede elluviimiseks, kui need vastavalt väljalaskeplaanile avaldatakse.
Kui omandate harjumuse mitte lisada funktsioone ette ja kasutades ette planeerimist, saate hõlpsasti kohaneda muutuvate klientide nõudmistega.

Iteratsiooni planeerimine

Iteratsiooni planeerimine algab iga iteratsiooni alguses toimuva koosolekuga, et töötada välja tarkvaraprobleemide lahendamise sammude plaan. Iga iteratsioon peaks kestma üks kuni kolm nädalat. Iteratsioonis olevad formulatsioonid sorteeritakse vastavalt nende tähtsusele kliendi jaoks. Lisaks lisanduvad ülesanded, mis ei saanud vastuvõtuteste läbi ja nõuavad edasist tööd. Testi avaldused ja tulemused tõlgitakse tarkvaraprobleemideks. Ülesanded kirjutatakse üles kaartidele, mis moodustavad üksikasjaliku iteratsiooniplaani. Iga probleemi lahendamiseks kulub üks kuni kolm päeva. Üle ühe päeva nõudvad ülesanded saab rühmitada ning suured ülesanded mitmeks väiksemaks. Arendajad hindavad ülesandeid ja nende täitmise tähtaegu. Arendaja jaoks on väga oluline ülesande täitmise aeg täpselt kindlaks määrata. Iga kolme või viie iteratsiooni järel võib osutuda vajalikuks mõni keel ümber hinnata ja väljalaskekava üle vaadata – see on täiesti vastuvõetav. Kui viid esmalt ellu kõige olulisemad töövaldkonnad, siis jääb alati aega teha oma klientide heaks maksimum. Iteratiivne arendusstiil parandab arendusprotsessi.

Koosolek seistes

Igal hommikul toimub koosolek, kus arutatakse probleeme, nende lahendusi ja tugevdatakse meeskonna keskendumisvõimet. Koosolek peetakse seistes, et vältida pikki arutelusid, mis kõiki meeskonnaliikmeid ei huvita.
Tavalisel koosolekul ei panusta enamik osalejaid mitte midagi, osaleb lihtsalt selleks, et kuulda, mida teistel on öelda. Suur hulk inimeste aega raisatakse väikese hulga suhtluse vastuvõtmiseks. Seetõttu võtab kõigi koosolekutel osalemine projektilt ressursse ja tekitab planeerimisel kaose.
Selline suhtlus nõuab alalist koosolekut. Palju parem on korraldada üks lühike kohustuslik koosolek kui palju pikki koosolekuid, millel enamik arendajaid nagunii osalema peab.
Kui teil on igapäevased seisvad koosolekud, siis kõigil teistel koosolekutel peaksid osalema ainult need inimesed, kes on vajalikud ja toovad midagi lauale. Pealegi on võimalik mõnda kohtumist isegi vältida. Kuna osalejaid on vähe, saab enamikku koosolekuid pidada spontaanselt monitori ees, kus mõttevahetus on palju intensiivsem.
Igapäevane hommikune koosolek ei ole järjekordne ajaraiskamine. See võimaldab teil vältida paljusid muid kohtumisi ja säästa rohkem aega, kui sellele kulutate.

Lihtsus

Lihtne disain võtab alati vähem aega kui keeruline. Seega tehke alati kõige lihtsamaid asju, mis toimivad. Alati on kiirem ja odavam asendada keeruline kood kohe, enne kui kulutate selle kallale palju aega. Hoidke asjad võimalikult lihtsad, ilma funktsionaalsust enne planeerimist lisamata. Pidage meeles: disaini lihtsana hoidmine on raske töö.

Metafoori süsteem

Metafoorisüsteemi valik on vajalik selleks, et meeskond püsiks klasside ja meetodite nimetamisel samas raamistikus. See, kuidas oma objekte nimetate, on süsteemi üldise disaini ja koodi taaskasutamise mõistmiseks väga oluline. Kui arendaja suudab õigesti ennustada, kuidas olemasolevat objekti nimetatakse, säästab see aega. Kasutage oma objektide jaoks sellist nimesüsteemi, millest igaüks saab aru ilma konkreetsete süsteemiteadmisteta.

Klient töökohal

Tarkvaraarenduse põhiprobleemiks on programmeerijate puudulikud teadmised arendatavas ainevaldkonnas. Ekstreemprogrammeerimine on leidnud sellest olukorrast väljapääsu. Ei, see ei ole arendaja praktika kliendi ettevõttes – siis ei taha ta programmeerida. Vastupidi, see on kliendi osalemine arendusprotsessis.
Kas programmeerija, ilma probleemi olemust põhjalikult mõistmata ja mitte telepaat, oskab arvata, mida klient tahab? Vastus on ilmne. Lihtsaim viis sellest ebamugavusest üle saada – ja Extreme Programming õpetab meid leidma kõige lihtsamaid lahendusi – on esitada kliendile otsene küsimus. Rangemad lähenemisviisid nõuavad arendatava piirkonna põhjalikku eelanalüüsi. Teatud juhtudel on see õigustatud, kuigi see on kallim. Reaalne kogemus igapäevaste projektide läbiviimisel näitab, et kõiki nõudeid ette koguda on võimatu. Veelgi enam, isegi kui eeldame, et kõik nõuded on hetkel kokku kogutud, jääb ikkagi üks kitsaskoht: programmid, nagu kõik looduses, ei teki koheselt ja vahepeal võivad äriprotsessid muutuda. Seda tuleks arvesse võtta.
Paljud kahtlevad kliendi kaasamise võimalikkuses arendusprotsessi. Tõepoolest, kliendid on erinevad. Kui klienti või tema esindajat ei ole võimalik meelitada, on mõnikord soovitatav palgata ajutiselt arendatava ala spetsialist. See samm vähendab ebaselgust töös, suurendab arenduskiirust ja lähendab projekti sellele, mida klient soovib saada. Sellest võib kasu olla ka rahalise poole pealt: on ju programmeerija palk kohati oluliselt kõrgem kui teiste valdkondade spetsialistide palk.
Kasutaja lugu. Kasutajalugu (midagi kasutaja loo taoline) on kirjeldus, kuidas süsteem peaks töötama. Iga kasutajalugu on kirjutatud kaardile ja esindab mõnda süsteemi funktsionaalsust, mis on Kliendi seisukohast loogiline. Vorm on üks või kaks lõiku teksti, mis on kasutajale arusaadav (mitte väga tehniline).
Kasutaja loo kirjutab Klient. Need on sarnased süsteemi kasutusjuhtumitega, kuid ei piirdu kasutajaliidesega. Iga loo jaoks kirjutatakse funktsionaalsed testid, mis kinnitavad selle loo korrektset rakendamist – neid nimetatakse ka vastuvõtutestideks.

Testimine enne arenduse algust

Testimine on selle klassikalises mõttes üsna igav protseduur. Tavaliselt palkavad nad testija, kes teeb perioodiliselt samu toiminguid ja ootab päeva, mil ta lõpuks teisele ametikohale üle viiakse või tekib võimalus töökohta vahetada.
Äärmuslikus programmeerimises on testimise roll huvitavam: nüüd on kõigepealt test ja seejärel kood. Kuidas testida midagi, mida veel pole? Vastus on lihtne ja banaalne: pange oma mõtted proovile – mida oodata tulevaselt programmilt või funktsioonilt. See võimaldab teil paremini mõista, mida programmeerijad peavad tegema, ja kontrollida koodi funktsionaalsust kohe pärast selle kirjutamist.
Kuid ka test ei pruugi töötada. Mis siis ikka, kirjutada testi jaoks test? Ja siis testi testimiseks ja nii edasi lõpmatuseni? Üldse mitte. Testi jaoks mõeldud test asendab koodi. Kuidas nii? Aga vaadake: kujutage ette, et peate kinnitama mutteri poldi keskele, et see ei keeraks. Mida nad selle nimel teevad? Kruvige teine mutter esimese lähedale, nii et iga mutter takistab külgneva mutteri pöörlemist. Programmeerimises on sama: test testib koodi ja kood testib.
Kogemused näitavad, et selline lähenemine mitte ainult ei pidurda, vaid ka kiirendab arengut. Teades, mida on vaja teha ja vajalikku töömahtu, säästab ju aega, keeldudes müümast osi, mille järele praegu nõudlust pole.

Paari programmeerimine

Kogu tootmissüsteemi kood on kirjutatud paarikaupa. Kaks arendajat istuvad kõrvuti. Üks kirjutab, teine vaatab. Need muutuvad aeg-ajalt. Üksi töötada ei tohi. Kui paarist teisel jäi mingil põhjusel midagi vahele (haige, pensionil vms), on ta kohustatud üle vaatama kõik esimese tehtud muudatused.
See kõlab ebatavaliselt, kuid pärast lühikest kohanemisperioodi töötab enamik inimesi hästi paaris. See neile isegi meeldib, sest töö saab märgatavalt kiiremini tehtud. Kehtib põhimõte “Üks pea on hea, aga kaks on parem”. Tavaliselt leiavad paarid paremaid lahendusi. Lisaks tõuseb oluliselt koodi kvaliteet, väheneb vigade arv ning kiireneb teadmiste vahetus arendajate vahel. Kui üks inimene keskendub objekti strateegilisele visioonile, siis teine rakendab selle omadusi ja meetodeid.

Asendite muutmine

Järgmise iteratsiooni käigus tuleks kõik töötajad viia uutele tööaladele. Sellised liigutused on vajalikud teadmiste isolatsiooni vältimiseks ja kitsaskohtade kõrvaldamiseks. Eriti viljakas on paarisprogrammeerimisel ühe arendaja asendamine.

Kollektiivne koodi omand

Jagatud koodi omandiõigus julgustab arendajaid esitama ideid projekti kõigi osade, mitte ainult oma moodulite jaoks. Iga arendaja saab funktsioonide laiendamiseks ja vigade parandamiseks muuta mis tahes koodi.
Esmapilgul tundub see kaosena. Arvestades aga seda, et vähemalt suvalise koodi loovad paar arendajat, et testid võimaldavad kontrollida tehtud muudatuste õigsust ning et päriselus tuleb ikka nii või teisiti aru saada kellegi teise koodist, saab selgeks, et koodi kollektiivne omamine muudab muudatuste tegemise palju lihtsamaks ja vähendab riski, mis on seotud ühe või teise meeskonnaliikme kõrge spetsialiseerumisega.

Kodeerimise konventsioon

Olete osa meeskonnast, kes on selle projekti kallal juba pikka aega töötanud. Inimesed tulevad ja lähevad. Keegi ei kodeeri üksi ja kood kuulub kõigile. Alati on aegu, mil peate mõistma ja kohandama kellegi teise koodi. Arendajad eemaldavad või muudavad duplikaatkoodi, analüüsivad ja täiustavad teiste inimeste klasse jne. Aja jooksul on võimatu öelda, kes on konkreetse klassi autor.
Seetõttu peavad kõik järgima üldlevinud kodeerimisstandardeid – koodi vormindamine, klasside nimetamine, muutujad, konstandid, kommentaaristiil. Nii oleme kindlad, et kui teeme muudatusi kellegi teise koodis (mis on vajalik agressiivseks ja äärmuslikuks edasiliikumiseks), ei muuda me seda Babel Pandemoniumiks.
Eeltoodu tähendab, et kõik meeskonnaliikmed peavad kokku leppima ühtsetes kodeerimisstandardites. Pole tähtis, millised. Reegel on, et kõik järgivad neid. Need, kes neid täita ei taha, lahkuvad meeskonnast.

Sage integreerimine

Arendajad peaksid võimaluse korral oma koodi iga paari tunni järel integreerima ja välja andma. Igal juhul ei tohiks te kunagi muudatusi hoida kauem kui üks päev. Sage integreerimine väldib arenduses võõrandumist ja killustatust, kus arendajad ei saa suhelda ideede jagamise või koodi taaskasutamise mõttes. Kõik peaksid kasutama uusimat versiooni.
Iga arendajapaar peaks oma koodi lisama niipea, kui see on mõistlikult võimalik. See võib juhtuda siis, kui kõik UnitTestid läbivad 100%. Kui esitate muudatusi mitu korda päevas, vähendate integratsiooniprobleemid peaaegu nullini. Integratsioon on "maksa kohe või maksa hiljem rohkem" tegevus. Seetõttu ei pea te iga päev väikeste sammude kaupa muudatusi integreerides kulutama nädalat, et süsteem kokku siduda vahetult enne projekti elluviimist. Töötage alati süsteemi uusima versiooniga.

Neljakümnetunnine töönädal

Inimene, eriti kui ta on programmeerija, on võimeline äri nimel palju ära tegema: tööl hiljaks jääma, nädalavahetustel tööle minema, puhkusest loobuma, klaviatuuri taga istudes mitu päeva ärkvel... Üldiselt, mida saate oma lemmiktegevuse nimel teha. Kuid äärmuslik programmeerimine on sellise eneseohverduse ja aktsepteeritud tööõiguse normide rikkumise vastu kategooriliselt.
Seda ei dikteeri mitte ainult seaduslikkuse ja inimlikkuse kaalutlused, vaid ennekõike töö efektiivsuse tõstmise ja range korralduse vajadus. Ekstreemprogrammeerimine on ju kollektiivne mäng, mis on mõeldud mitte üksikisikutele, vaid kogu rühmale. Ja selline asi nagu näiteks paarisprogrammeerimine on võimalik ainult siis, kui selles osalejate biorütmid on sünkroniseeritud. Ja see on võimatu, kui üks inimene tuleb tööle kell üheksa ja teine kell kaksteist või üks otsustab, et tal on parem laupäeval ja pühapäeval töötada, samal ajal kui teisel on ebamugav.
Kõige tähtsam on aga see, et tervise ja töövõime säilitamiseks vajab inimene korralikku puhkust. Kaheksatunnine tööpäev ja viiepäevane töönädal on kehtestatud just maksimaalse tootlikkuse huvides. Paljudes Lääne ettevõtetes peetakse töölt hiljaks jätmist suutmatus töös hästi toime tulla või suutmatust oma tööaega õigesti juhtida. Enamikul juhtudel on see tõsi. Meditsiinilisest vaatenurgast põhjustavad viivitused tööl pidevat väsimust, ärrituvust ja ajutegevuse vähenemist. Kas see on tõhus? Kuidas saaksime sellises meeskonnas korraldada pidevat avatud suhtlust arendajate vahel ja kas paarisprogrammeerimine on võimalik? Vastus on eitav. Standardid on standardid ja neid tuleks järgida.

Järeldus

Need meetodid ei ole juhuslikult kokku pandud. Nende järjekindel kombinatsioon võib viia arendusprotsessi intellektuaalsesse resonantsi, tõstes oluliselt toote kvaliteeti ja kiirendades selle väljalaskeaega. Kogu ekstreemse programmeerimise peamine ilu on prognoositavus ja arenduskulude minimeerimine; anda kliendile vabastamise hetkel toode, mida ta soovib saada; ja loomulikult suhtlemine ja arendajate koolitamine töökohal.

Bibliograafia:

Reaalajas tarkvaraarenduse põhiprintsiibid on kirjas 2000. aastal ilmunud reaalarengu manifestis.

· Projektiga seotud inimesed ja nende suhtlus on olulisemad kui protsessid ja tööriistad.
· Tööprogramm on olulisem kui põhjalik dokumentatsioon.
· Lepingu üksikasjade läbirääkimisest olulisem on koostöö kliendiga.
· Muudatuste läbi töötamine on olulisem kui plaanidest kinnipidamine.

XP-l on aga oma arendusprotsessi diagramm (kuigi üldiselt on laialt levinud arusaam "arendusprotsessist" kui üsna jäigast tegevusskeemist vastuolus "elava" arengu ideega), mis on näidatud joonisel 1. .

· Otse planeerimine mäng)

Joonis 1

· Sage muuta versioonid (väikesed väljalasked)

· Süsteemi metafoor

Metafoor, üsna lihtsal ja meeskonnale arusaadaval kujul, peaks kirjeldama süsteemi põhimehhanismi. See kontseptsioon meenutab arhitektuuri, kuid peaks kirjeldama tehniliste otsuste põhiolemust palju lihtsamalt, vaid ühe või kahe fraasiga.

Arhitektuur on mingi ettekujutus süsteemi komponentidest ja nende omavahelistest seostest. Arendajad kasutavad arhitektuuri, et mõista, kuhu süsteemi uusi funktsioone lisatakse ja millega mõni uus komponent suhtleb.

Süsteemi metafoor on analoog sellele, mida enamikus tehnikates nimetatakse arhitektuuriks. Süsteemi metafoor annab meeskonnale aimu, kuidas süsteem praegu töötab, kuhu lisatakse uusi komponente ja millisel kujul need peaksid olema.

· Lihtne disain lahendused (lihtsad disain)

Süsteem peaks igal ajahetkel olema võimalikult lihtne. Funktsioone pole vaja eelnevalt lisada – ainult pärast selgesõnalist taotlust. Kogu ebavajalik keerukus eemaldatakse kohe pärast selle avastamist.

· Areng peal alus testimine (testipõhine areng)

Arendajad kirjutavad esmalt testid, seejärel proovivad oma mooduleid juurutada, et testid töötaksid. Kliendid kirjutavad eelnevalt testid, mis demonstreerivad süsteemi peamisi võimalusi, et nad näeksid, kas süsteem ka tegelikult töötab.

XP paneb erilist rõhku kahte tüüpi testimisele:

ь ühikutestimine;

b vastuvõtutest.

äärmuslik programmeerimistarkvara

Vastuvõtutestid tagavad, et süsteemil on tegelikult märgitud võimalused. Lisaks võimaldavad vastuvõtutestid kontrollida arendatava toote nõuetekohast toimimist.

· Püsiv refaktoreerimine

· Programmeerimine paarid programmeerimine)

· Kollektiiv omamine kood (kollektiiv omandiõigus)

· Püsiv integratsioon (pidev integratsioon)

Süsteem pannakse kokku ja läbib integratsioonitesti nii sageli kui võimalik, mitu korda päevas, iga kord, kui paar programmeerijat lõpetab järgmise funktsiooni juurutamise.

· 40 tundi töötavad nädal

· Kaasamine klient V meeskond (kohapeal klient)

· Kasutamine kood Kuidas rajatised side

· Avatud töötavad ruum (avatud tööruum)

Meeskond on paigutatud ühte küllalt avarasse ruumi, et hõlbustada suhtlemist ja võimaldada grupivestlusi planeerimisel ja oluliste tehniliste otsuste tegemisel.

· Muuda reeglid Kõrval vajalik (lihtsalt reeglid)

Iga meeskonnaliige peab nõustuma loetletud reeglitega, kuid vajaduse korral saab meeskond neid muuta, kui kõik tema liikmed on selle muudatusega nõus.