Dërgoni punën tuaj të mirë në bazën e njohurive është e thjeshtë. Përdorni formularin e mëposhtëm

Punë e mirë në faqen">

Studentët, studentët e diplomuar, shkencëtarët e rinj që përdorin bazën e njohurive në studimet dhe punën e tyre do t'ju jenë shumë mirënjohës.

Postuar në http://www.allbest.ru/

përmbajtja

• Prezantimi
• 1. Çfarë është XP?
• 3.1 Teknikat bazëXP
• 4. Përparësitë dhe disavantazhet
• 5. Historia e përdorimit
• konkluzioni

Prezantimi

Programimi ekstrem, shpesh i shkurtuar XP, është një disiplinë e zhvillimit të softuerit dhe biznesit të softuerit që fokuson përpjekjet e të dyja palëve (programuesit dhe njerëzit e biznesit) në qëllime të përbashkëta dhe të arritshme. Ekipet që përdorin XP prodhojnë softuer cilësor me një ritëm shumë të shpejtë. Teknikat që përbëjnë disiplinën e HR janë zgjedhur sepse ato bazohen në krijimtarinë njerëzore dhe pranimin se njerëzit janë krijesa të paqëndrueshme dhe të gabueshme.

XP shpesh paraqitet si një grup teknikash, por vetë XP nuk është vija e përfundimit. Nuk ka nevojë të praktikoni dhe zhvilloni HR gjithnjë e më mirë në mënyrë që të merrni yllin e shumëpritur të artë në fund të këtij procesi. Përkundrazi, XP është vija e fillimit. XP shtron pyetjen: "Sa minimale mund të jenë përpjekjet tona në mënyrë që të vazhdojmë të prodhojmë softuer cilësor?"

Programimi ekstrem është një metodologji e thjeshtuar prodhimi për ekipe të vogla dhe të mesme specialistësh që zhvillojnë një produkt softuerësh në kushte kërkesash të paqarta ose që ndryshojnë me shpejtësi.

1. Çfarë është XP?

Ekstrememliriprogrammshëtitës(anglisht) Ekstreme Programimi, XP) është një nga metodologjitë fleksibël të zhvillimit të softuerit. Autorët e metodologjisë janë Kent Beck, Ward Cunningham, Martin Fowler dhe të tjerë.

XP është një mënyrë e thjeshtuar, efikase, fleksibël, e parashikueshme, e bazuar në shkencë dhe shumë e këndshme, me rrezik të ulët për të zhvilluar softuer. HR ndryshon nga metodat e tjera në mënyrat e mëposhtme:

Duke përdorur cikle jashtëzakonisht të shkurtra zhvillimi, XP ofron reagime të shpejta, reale dhe të vazhdueshme.

XP përdor planifikimin inkremental, i cili rezulton në një plan të përgjithshëm projekti që shfaqet mjaft shpejt, por kuptohet që ky plan evoluon gjatë gjithë jetës së projektit.

XP përdor një orar fleksibël për zbatimin e këtij apo atij funksionaliteti, i cili përmirëson reagimin ndaj ndryshimit të natyrës së biznesit dhe ndryshimit të kërkesave të klientëve në lidhje me këtë.

XP bazohet në teste të automatizuara të zhvilluara nga programuesit dhe klientët. Falë këtyre testeve, është e mundur të monitorohet procesi i zhvillimit, të sigurohet evolucioni i saktë i sistemit dhe të zbulohen menjëherë defektet ekzistuese në sistem.

XP bazohet në komunikimin gojor, testet dhe kodin burimor. Këto tre mjete përdoren për të shkëmbyer informacion në lidhje me strukturën dhe sjelljen e një sistemi.

XP bazohet në një proces projektimi në zhvillim që vazhdon për sa kohë që ekziston vetë sistemi.

XP bazohet në ndërveprimin e ngushtë midis programuesve me aftësitë dhe aftësitë më të zakonshme.

XP bazohet në teknika që kënaqin si instinktet afatshkurtra të programuesve individualë, ashtu edhe interesat afatgjata të të gjithë projektit.

XP është një disiplinë e zhvillimit të softuerit. Kjo është një disiplinë sepse brenda XP ka disa gjëra që duhet të bëni nëse do të përdorni XP. Ju nuk duhet të zgjidhni nëse do të shkruani ose jo teste, sepse nëse nuk e bëni, programimi që po bëni nuk është ekstrem.

Metodologjia XP synon të punojë në projekte që mund të punohen nga dy deri në dhjetë programues, të cilët nuk janë të ngjeshur në kornizën e ngurtë të mjedisit ekzistues kompjuterik dhe në të cilat të gjithë puna e nevojshme testimi i lidhur mund të përfundojë brenda një dite.

2. Ku fillon programimi ekstrem?

Ku fillon programimi ekstrem? Nga të kuptuarit se pozicioni tipik i një zhvilluesi vendas të softuerit detyron të zvogëlojë kostot e zhvillimit sa më shumë që të jetë e mundur. Dhe për këtë është e nevojshme të bashkëpunoni intensivisht me klientin, të kuptoni interesat e tij dhe, në fund, të bëni pikërisht atë që ai dëshiron: jo më shumë dhe as më pak.

Programimi ekstrem nuk bazohet në teknika specifike, siç besohet zakonisht, por vetëm në katër parime themelore: komunikim, thjeshtësi, Feedback dhe guxim. Këtu duhet të filloni.

Extreme Programming ofron një zgjidhje të gatshme: mbani gjithçka sa më të thjeshtë, mbajeni klientin pranë vetes ose qëndroni me klientin, lëreni të monitorojë në mënyrë aktive procesin e zhvillimit, mirëpret ndryshimin - dhe suksesi është pothuajse i garantuar.

Në ekipet XP, komunikimi inkurajohet gjithmonë - mënyra më e shpejtë për të shkëmbyer informacion dhe përvojë. Kjo është shumë e rëndësishme kur kërkohet shpejtesi maksimale zhvillimin. Por komunikimi, si çdo përpjekje tjetër e dobishme, kërkon mbështetje të vazhdueshme. Kjo është arsyeja pse dikush nga ekipi duhet të marrë përgjegjësinë për monitorimin e komunikimit, duke u bërë një i ashtuquajtur diplomat. Komunikimi dhe nevoja për t'u shpjeguar veprimet tuaja anëtarëve të tjerë të ekipit ju detyron të bëni gjithçka sa më thjesht të jetë e mundur. Nëse nuk funksionon herën e parë, ata punojnë në thjeshtimin përsëri dhe përsëri derisa të arrihet. objektivi kryesor- qartësia maksimale e kodit për zhvilluesit e tjerë.

Pavarësisht se çfarë bëjmë - duke fije një gjilpërë ose duke shkuar në një festë - ne gjithmonë përpiqemi të arrijmë një qëllim. Nëse vërejmë se po devijojmë prej tij, ne i rregullojmë veprimet tona në përputhje me rrethanat. Tani imagjinoni sa më e vështirë është të futësh një fije në një gjilpërë sytë e mbyllur ose vishuni bukur pa pasqyrë! Por kur zhvillojmë programe, shpesh ndodh kështu: ne bëjmë diçka, rezultatin e së cilës nuk mund ta shohim. Prandaj, në programimin ekstrem është një rregull që të shihni sa më shpejt rezultatin e veprimeve tuaja. Ose, duke folur teknikisht, për të dhënë komente sa më shpejt të jetë e mundur.

Programimi ekstrem na pyet: pse të mos zhvillojmë guxim? Në fund të fundit, ajo është shumë e rëndësishme në punën e saj. Pa guxim, a është e mundur të marrësh përgjegjësinë për përfundimin e një detyre dhe brenda një afati të caktuar kohor? Pa guxim, a është e mundur të kuptoni se keni arritur në një rrugë pa krye, të bëni një hap prapa dhe të kërkoni një zgjidhje? Dhe, së fundi, çfarë do t'i lejojë zhvilluesit të pranojë gabimin e tij në vlerësimin e detyrës dhe t'i paralajmërojë të tjerët për këtë në kohë, në vend që t'u paraqesë atyre një fakt të kryer vetëm kur të kenë skaduar të gjitha afatet? Përfitimet e guximit janë të dukshme dhe çdo sukses, qoftë edhe në detyrën më të vogël, mund ta zhvillojë këtë guxim.

3. Teknikat XP

Programimi ekstrem (XP) u shfaq si një metodë evolucionare e zhvillimit të softuerit nga poshtë-lart. Kjo qasje është një shembull i të ashtuquajturës Metoda e Zhvillimit Agile. Në grupin e metodave “live” përfshihen, përveç programimit ekstrem, edhe metodat SCRUM, DSDM (Dynamic Systems Development Method, një metodë për zhvillimin e sistemeve dinamike), Feature-Driven Development (zhvillimi i drejtuar nga funksionet e sistemit), etj.

Parimet themelore të zhvillimit të softuerit të drejtpërdrejtë janë të përfshira në manifestin e zhvillimit të drejtpërdrejtë, i cili u shfaq në 2000.

· Njerëzit e përfshirë në një projekt dhe komunikimi i tyre janë më të rëndësishëm se proceset dhe mjetet.

· Një program pune është më i rëndësishëm se dokumentacioni gjithëpërfshirës.

· Bashkëpunimi me klientin është më i rëndësishëm sesa diskutimi i detajeve të kontratës.

· Puna përmes ndryshimeve është më e rëndësishme sesa t'u përmbahesh planeve.

Metodat "Living" u shfaqën si një protestë kundër burokratizimit të tepruar të zhvillimit të softuerit, bollëkut të dokumenteve anësore që nuk janë të nevojshme për të marrë rezultatin përfundimtar, të cilat duhet të hartohen gjatë kryerjes së një projekti në përputhje me shumicën e proceseve "të rënda". , punë shtesë për të mbështetur procesin fiks të organizatës, siç kërkohet brenda, për shembull, CMM. Shumica e këtyre punëve dhe dokumenteve nuk janë të lidhura drejtpërdrejt me zhvillimin e softuerit dhe sigurimin e cilësisë, por synojnë të jenë në përputhje me klauzolat formale të kontratave të zhvillimit, të marrin dhe konfirmojnë certifikatat për përputhjen me standarde të ndryshme.

Metodat "Live" lejojnë zhvilluesit të përqendrojnë shumicën e përpjekjeve të tyre në detyrat e zhvillimit dhe përmbushjen e nevojave reale të përdoruesve. Mungesa e grumbujve të dokumenteve dhe nevoja për t'i mbajtur ato në një gjendje koherente ju lejon të përgjigjeni më shpejt dhe me efikasitet ndaj ndryshimeve në kërkesat dhe në mjedisin në të cilin do të duhet të funksionojë programi i ardhshëm.

Sidoqoftë, XP ka diagramin e tij të procesit të zhvillimit (megjithëse, në përgjithësi, kuptimi i përdorur gjerësisht i "procesit të zhvillimit" si një skemë mjaft e ngurtë veprimesh bie ndesh me vetë idenë e zhvillimit "të gjallë"), i paraqitur në Fig. 1 .

Sipas autorëve të XP, kjo teknikë nuk po ndjek aq shumë disa skemat e përgjithshme veprimet, sa përdorin një kombinim të teknikave të mëposhtme. Sidoqoftë, çdo teknikë është e rëndësishme dhe pa përdorimin e saj, zhvillimi konsiderohet të mos jetë XP, sipas Kent Beck, një nga autorët e kësaj qasjeje së bashku me Ward Cunningham dhe Ron Jeffries.

· Jetoniplanifikimi (planifikimilojë)

Detyra e tij është të përcaktojë sa më shpejt të jetë e mundur sasinë e punës që duhet bërë përpara versionit të ardhshëm të softuerit. Vendimi merret, para së gjithash, në bazë të prioriteteve të klientit (d.m.th. nevojat e tij, çfarë i nevojitet nga sistemi për të drejtuar më me sukses biznesin e tij) dhe, së dyti, në bazë të vlerësimet teknike(d.m.th. vlerësime të kompleksitetit të zhvillimit, përputhshmërisë me elementë të tjerë të sistemit, etj.). Planet ndryshojnë sapo fillojnë të ndryshojnë nga realiteti ose dëshirat e klientit.

Oriz.1 Diagrami i rrjedhës së punës XP

· Të shpeshtandryshimVversionet (të voglalëshon)

Versioni i parë i punës duhet të shfaqet sa më shpejt që të jetë e mundur dhe duhet të fillojë të përdoret menjëherë. Versionet e ardhshme përgatitur në intervale mjaft të shkurtra (nga disa orë për ndryshime të vogla në një program të vogël, deri në një muaj ose dy për një ripërpunim të madh të një sistemi të madh). Versionet (lëshimet) e produktit duhet të lëshohen në shërbim sa më shpesh të jetë e mundur. Çdo version duhet të marrë sa më pak kohë që të jetë e mundur për të përfunduar. Për më tepër, çdo version duhet të jetë mjaftueshëm kuptimplotë për sa i përket dobisë për biznesin.

· Metaforë (metaforë) sistemeve

Metafora, në një formë mjaft të thjeshtë dhe të kuptueshme për ekipin, duhet të përshkruajë mekanizmin bazë të sistemit. Ky koncept të kujton arkitekturën, por duhet të përshkruajë thelbin kryesor të vendimeve teknike të marra shumë më thjesht, në vetëm një ose dy fraza.

Arkitektura është një ide e komponentëve të një sistemi dhe se si ato janë të ndërlidhura. Zhvilluesit përdorin arkitekturën për të kuptuar se ku po shtohen disa funksione të reja në sistem dhe me çfarë do të ndërveprojnë disa komponentë të rinj.

Metafora e sistemit është një analog i asaj që quhet arkitekturë në shumicën e teknikave. Metafora e sistemit i jep ekipit një ndjenjë se si funksionon aktualisht sistemi, ku po shtohen komponentë të rinj dhe çfarë forme duhet të kenë.

· E thjeshtëdizajniZgjidhjet (thjeshtëdizajni)

Në çdo moment, sistemi duhet të projektohet sa më thjeshtë që të jetë e mundur. Nuk ka nevojë të shtoni veçori paraprakisht - vetëm pas një kërkese të qartë për të. I gjithë kompleksiteti i panevojshëm hiqet sapo të zbulohet.

XP rrjedh nga fakti se gjatë procesit të punës, kushtet e problemit mund të ndryshojnë në mënyrë të përsëritur, që do të thotë se produkti që po zhvillohet nuk duhet të projektohet paraprakisht në tërësinë e tij. Nëse përpiqeni të dizajnoni një sistem në detaje nga fillimi në fund kur filloni për herë të parë, po humbisni kohën tuaj. XP supozon se dizajni është i tillë proces i rëndësishëm se duhet të kryhet vazhdimisht gjatë gjithë kohëzgjatjes së projektit. Dizajni duhet të kryhet me hapa të vegjël, duke marrë parasysh kërkesat vazhdimisht në ndryshim. Në çdo moment ne përpiqemi të përdorim modelin më të thjeshtë që është i përshtatshëm për zgjidhjen e problemit aktual. Në të njëjtën kohë, ne e ndryshojmë atë pasi ndryshojnë kushtet e problemit.

· Zhvilliminëbazëduke testuar (provë- i shtyrëzhvillimin)

Zhvilluesit fillimisht shkruajnë teste, pastaj përpiqen të zbatojnë modulet e tyre në mënyrë që testet të funksionojnë. Konsumatorët shkruajnë teste paraprakisht që demonstrojnë aftësitë kryesore të sistemit në mënyrë që ata të mund të shohin se sistemi në të vërtetë funksionon.

Në XP Vëmendje e veçantë Ekzistojnë dy lloje të testimit:

ь testimi i njësisë;

b testimi i pranimit.

softuer programimi ekstrem

Një zhvillues nuk mund të jetë i sigurt për korrektësinë e kodit që ka shkruar derisa të kenë funksionuar absolutisht të gjitha testet e moduleve të sistemit që ai po zhvillon. Testet e njësisë i lejojnë zhvilluesit të verifikojnë nëse kodi i tyre funksionon saktë. Ata gjithashtu ndihmojnë zhvilluesit e tjerë të kuptojnë pse nevojitet një pjesë e veçantë e kodit dhe si funksionon. Testet e njësisë gjithashtu i lejojnë zhvilluesit të rifaktojë pa u shqetësuar.

Testet e pranimit sigurojnë që sistemi në të vërtetë ka aftësitë e deklaruara. Për më tepër, testet e pranimit ju lejojnë të verifikoni funksionimin e saktë të produktit që po zhvillohet.

Për XP, një prioritet më i lartë është qasja e quajtur TDD (Test Driven Development), fillimisht shkruhet një test që nuk kalon, pastaj kodi shkruhet në mënyrë që testi të kalojë dhe vetëm atëherë kodi rifaktorohet.

· Konstantericiklimi (rifaktorimi)

Nuk është sekret që shtimi i çdo funksionaliteti të ri dhe rritja e kodit e ndërlikon zhvillimin, duke identifikuar gabimet dhe duke bërë ndryshime të mëvonshme. Një nga truket e Programimit Ekstrem është të kompensoni për shtimin e funksionalitetit me përmirësime të kodit. Ky është përpunimi i kodit, ose rifaktorimi.

Programuesit po ripunojnë vazhdimisht sistemin për të eliminuar kompleksitetin e panevojshëm, për të rritur kuptueshmërinë e kodit, për të rritur fleksibilitetin e tij, por pa ndryshuar sjelljen e tij, gjë që verifikohet duke ekzekutuar pas çdo ripërpunimi të testeve. Në të njëjtën kohë, përparësi u jepet zgjidhjeve më elegante dhe fleksibile në krahasim me ato që thjesht ofrojnë rezultatin e dëshiruar. Komponentët e ridizajnuar pa sukses duhet të identifikohen gjatë ekzekutimit të provës dhe të kthehen në gjendjen e fundit të paprekur (së bashku me komponentët që varen prej tyre).

Rifaktorimi është një teknikë për përmirësimin e kodit pa ndryshuar funksionalitetin e tij. XP do të thotë që sapo të shkruhet kodi, ai pothuajse me siguri do të rishkruhet disa herë gjatë një projekti. Zhvilluesit e XP ripunojnë pa mëshirë kodin e shkruar më parë për ta përmirësuar atë. Ky proces quhet rifaktorim. Mungesa e mbulimit të testit provokon një refuzim të rifaktorimit për shkak të frikës së prishjes së sistemit, gjë që çon në degradimin gradual të kodit.

· Programiminë çifte (çiftprogramimit)

Zhvilluesit me përvojë kanë vënë re se rishikimi periodik i kodit të njerëzve të tjerë ka një efekt pozitiv në cilësinë e tij. Mjeshtrit e Programimit Ekstrem e kanë zhvilluar këtë qasje duke rishikuar vazhdimisht kodin gjatë zhvillimit përmes një teknike të quajtur programimi në çift.

Kodimi kryhet nga dy programues në një kompjuter. Çiftimi është arbitrar dhe ndryshon nga detyra në detyrë. Ai në duart e të cilit po përpiqet tastiera në mënyrën më të mirë të mundshme zgjidh problemin aktual. Programuesi i dytë analizon punën e të parit dhe jep këshilla, merr parasysh pasojat e vendimeve të caktuara, teste të reja, zgjidhje më pak të drejtpërdrejta por më fleksibël. Nëse është e nevojshme, tastiera transferohet lirisht nga njëra në tjetrën. Ndërsa punoni në një projekt, çiftet nuk janë fikse: rekomandohet t'i përzieni ato në mënyrë që secili programues në ekip të ketë një kuptim të mirë të të gjithë sistemit. Në këtë mënyrë, programimi në çift rrit bashkëpunimin brenda ekipit.

· Kolektiveposedimkodi (kolektivepronësinë)

Kolektive posedim do të thotë që çdo anëtar i ekipit është përgjegjës për të gjithë kodin burimor. Kështu, të gjithë kanë të drejtë të bëjnë ndryshime në çdo pjesë të programit. Programimi i çifteve mbështet këtë praktikë: duke punuar në çifte të ndryshme, të gjithë programuesit njihen me të gjitha pjesët e kodit të sistemit. Një avantazh i rëndësishëm i zotërimit të kodit të përbashkët është se ai përshpejton procesin e zhvillimit, pasi nëse ndodh një gabim, çdo programues mund ta rregullojë atë.

Duke i dhënë çdo programuesi të drejtën për të ndryshuar kodin, ne rrezikojmë nga gabimet e paraqitura nga programuesit që mendojnë se e dinë se çfarë po bëjnë, por nuk marrin parasysh disa varësi. Testet UNIT të mirëpërcaktuara zgjidhin këtë problem: nëse varësitë e paekzaminuara gjenerojnë gabime, atëherë ekzekutimi tjetër i testeve UNIT do të dështojë.

· Konstanteintegrimin (të vazhdueshmeintegrimin)

Sistemi montohet dhe i nënshtrohet testimit të integrimit sa më shpesh që të jetë e mundur, disa herë në ditë, sa herë që disa programues mbarojnë zbatimin e funksionit tjetër.

Nëse e integroni mjaft shpesh sistemin që po zhvilloni, mund të shmangni shumicën e problemeve që lidhen me të. Në metodat tradicionale, integrimi zakonisht kryhet në fund të punës në një produkt, kur konsiderohet se të gjithë komponentët e sistemit që po zhvillohet janë plotësisht gati. Në XP, integrimi i kodit i të gjithë sistemit kryhet disa herë në ditë, pasi zhvilluesit janë të bindur se të gjitha testet e njësisë po funksionojnë saktë.

Megjithë thjeshtësinë e saj, kjo teknikë ka rregullat e veta të përdorimit, si suksesi i testeve ekzistuese të njësisë për funksionalitetin e integruar, prania e testeve funksionale ose të pranimit dhe, natyrisht, aftësia për t'u kthyer në gjendjen e mëparshme. Në mënyrë tipike, integrimi dhe zgjidhja e vështirësive të lidhura kryhet në një kompjuter të veçantë nga disa programues. Kjo ju lejon të minimizoni rrezikun e pasojave të padëshiruara të integrimit.

· 40 orëduke punuarnje jave

Puna jashtë orarit konsiderohet një shenjë probleme të mëdha në projekt. Puna jashtë orarit për 2 javë rresht nuk lejohet - kjo i lodh programuesit dhe e bën punën e tyre dukshëm më pak produktive.

Një person, veçanërisht nëse është programues, është i aftë të bëjë shumë për hir të biznesit: të qëndrojë vonë në punë, të shkojë në punë gjatë fundjavave, të heqë dorë nga pushimet, të qëndrojë zgjuar për disa ditë duke u ulur në tastierë... Në përgjithësi, çfarë mund të bëni për hir të aktivitetit tuaj të preferuar. Por programimi ekstrem është kategorikisht kundër një vetëflijimi të tillë dhe shkeljes së standardeve të pranuara të ligjit të punës.

Kjo diktohet jo vetëm nga konsideratat e ligjshmërisë dhe humanizmit, por, para së gjithash, nga nevoja për të rritur efikasitetin e punës dhe organizimin e rreptë. Në fund të fundit, programimi ekstrem është një lojë kolektive, e krijuar jo për individët, por për të gjithë grupin. Dhe një gjë e tillë si, për shembull, programimi në çift është i mundur vetëm kur sinkronizohen bioritmet e pjesëmarrësve të tij. Dhe është e pamundur nëse një person vjen në punë në nëntë, dhe i dyti në dymbëdhjetë, ose njëri vendos që është më mirë për të të punojë të shtunën dhe të dielën, ndërsa tjetri është i papërshtatshëm.

Por gjëja më e rëndësishme është se për të ruajtur shëndetin dhe performancën, një person ka nevojë për pushim të duhur. Dita e punës tetë orëshe dhe java pesëditore e punës vendosen pikërisht për arsye të produktivitetit maksimal. Në shumë kompani perëndimore, lënia e punës me vonesë konsiderohet si dështim për të performuar mirë ose paaftësi për të menaxhuar siç duhet kohën e punës. Në shumicën e rasteve kjo është e vërtetë. Dhe nga pikëpamja mjekësore, vonesat në punë çojnë në lodhje të vazhdueshme, nervozizëm dhe ulje të aktivitetit të trurit. A është kjo efektive? Si mund të organizojmë komunikim të hapur të vazhdueshëm midis zhvilluesve në një ekip të tillë dhe a do të jetë i mundur programimi në çift? Përgjigja është negative. Standardet janë standarde dhe duhen ndjekur.

· PërfshirjaklientVekipi (në- faqeklient)

Problemi kryesor në zhvillimin e softuerit është mungesa e njohurive të programuesve në fushën lëndore që zhvillohet. Programimi ekstrem ka gjetur një rrugëdalje nga kjo situatë. Jo, kjo nuk është një praktikë e zhvilluesit në ndërmarrjen e klientit - atëherë ai nuk do të dëshirojë të programojë. Përkundrazi, është pjesëmarrja e klientit në procesin e zhvillimit.

Ekipi i zhvillimit përfshin gjithmonë një përfaqësues të klientit i cili është i disponueshëm gjatë gjithë ditës së punës dhe është në gjendje t'u përgjigjet të gjitha pyetjeve në lidhje me sistemin. Përgjegjësia e tij është t'u përgjigjet menjëherë pyetjeve të çdo lloji në lidhje me funksionet e sistemit, ndërfaqen e tij, performancën e kërkuar, funksionimin e duhur sistemet në situata komplekse, nevoja për të ruajtur komunikimin me aplikacione të tjera, etj.

Shumë dyshojnë në mundësinë e përfshirjes së klientit në procesin e zhvillimit. Në fakt, klientët janë të ndryshëm. Nëse nuk është e mundur të tërheqësh klientin ose përfaqësuesin e tij, ndonjëherë këshillohet të punësosh përkohësisht një specialist në fushën që po zhvillohet. Ky hap do të reduktojë paqartësitë në punë, do të rrisë shpejtësinë e zhvillimit dhe do ta afrojë projektin me atë që klienti dëshiron të marrë. Kjo mund të jetë gjithashtu e dobishme nga ana financiare: në fund të fundit, paga e një programuesi ndonjëherë është dukshëm më e lartë se paga e specialistëve në industri të tjera.

· PërdorimikodiSiobjektetkomunikimet

Kodi shihet si mjeti më i rëndësishëm i komunikimit brenda një ekipi. Qartësia e kodit është një nga prioritetet kryesore. Ndjekja e standardeve të kodimit që ofrojnë këtë qartësi është e domosdoshme. Standarde të tilla, përveç qartësisë së kodit, duhet të sigurojnë gjuhë minimale (pa dyfishim të kodit dhe informacionit) dhe duhet të pranohen nga të gjithë anëtarët e ekipit.

· Hapurduke punuarhapësirë (hapurhapësirën e punës)

Ekipi është i vendosur në një dhomë mjaft të gjerë për të lehtësuar komunikimin dhe për të mundësuar diskutime në grup kur planifikoni dhe merrni vendime të rëndësishme teknike.

· NdryshimirregullatNgadomosdoshmëri (vetëmrregullat)

Çdo anëtar i ekipit duhet të pranojë rregullat e listuara, por nëse lind nevoja, ekipi mund t'i ndryshojë nëse të gjithë anëtarët e tij bien dakord për këtë ndryshim.

Siç mund të shihet nga teknikat e përdorura, XP është projektuar për përdorim brenda ekipeve të vogla (jo më shumë se 10 programues), gjë që theksohet nga autorët e kësaj teknike. Një madhësi më e madhe e ekipit shkatërron lehtësinë e komunikimit të nevojshëm për sukses dhe e bën të pamundur zbatimin e shumë prej teknikave të listuara.

3.1 Teknikat bazë të XP

Dymbëdhjetë teknika bazë të programimit ekstrem (bazuar në botimin e parë të librit Ekstreme programimit shpjegohet) mund të kombinohen në katër grupe:

· Cikli i shkurtër i reagimit (reagime në shkallë të imët)

o Zhvillimi i drejtuar nga testi

o Lojë planifikuese

o Klienti është gjithmonë afër (I gjithë ekipi, klienti në vend)

o Programimi në çift

Procesi i vazhdueshëm dhe jo grupor

o Integrim i vazhdueshëm

o Rifaktorimi (Përmirësimi i Dizajnit, Refaktori)

o Lëshime të shpeshta të vogla

· Kuptimi i përbashkët nga të gjithë

o Thjeshtësia (Dizajn i thjeshtë)

o Metafora e sistemit

o Pronësia e kodit kolektiv ose modelet e zgjedhura të dizajnit (Pronësia e modeleve kolektive)

o Standardi i kodimit ose konventat e kodimit

· Mirëqenia e programuesit:

o 40 orë në javë pune (ritëm të qëndrueshëm, dyzet orë në javë)

Nje lojeVplanifikimi

Bota jonë është shumë e ndryshueshme dhe e paparashikueshme për t'u mbështetur në qëndrueshmërinë e situatës. E njëjta gjë ndodh në zhvillimin e softuerit: o sistem i rrallë mund të themi se forma e tij përfundimtare ishte e njohur paraprakisht në detaje që në fillimet e zhvillimit. Në mënyrë tipike, oreksi i klientit vjen gjatë ngrënies: ai vazhdimisht dëshiron të ndryshojë diçka, të përmirësojë diçka ose të flakë fare nga sistemi. Kjo është ndryshueshmëria e kërkesave që të gjithë kanë kaq frikë. Për fat të mirë, njeriut i jepet aftësia për të parashikuar opsionet e mundshme dhe kështu të mbajë situatën nën kontroll.

Në Programimin Ekstrem, planifikimi është një pjesë integrale e zhvillimit dhe fakti që planet mund të ndryshojnë merret parasysh që në fillim. Pika mbështetëse, teknika që ju lejon të parashikoni situatën dhe të përballoni pa dhimbje ndryshimet, është loja e planifikimit. Gjatë një loje të tillë, kërkesat e njohura të sistemit mund të mblidhen shpejt, vlerësohen dhe planifikohen sipas përparësisë.

Si çdo lojë tjetër, planifikimi ka pjesëmarrësit dhe qëllimin e tij. Figura kryesore është, natyrisht, klienti. Është ai që komunikon nevojën për këtë apo atë funksionalitet. Programuesit japin një vlerësim të përafërt të secilit funksionalitet. Bukuria e lojës së planifikimit qëndron në unitetin e qëllimit dhe solidaritetin midis zhvilluesit dhe klientit: në rast fitoreje, të gjithë fitojnë, në rast humbjeje, të gjithë humbasin. Por në të njëjtën kohë, secili pjesëmarrës shkon në rrugën e tij drejt fitores: klienti zgjedh detyrat më të rëndësishme në përputhje me buxhetin, dhe programuesi vlerëson detyrat në përputhje me aftësinë e tij për t'i zbatuar ato.

Programimi ekstrem supozon se zhvilluesit janë në gjendje të vendosin vetë se sa kohë do t'u duhet për të përfunduar detyrat e tyre dhe cili prej tyre do të ishte më i gatshëm për të zgjidhur një problem dhe kush një tjetër.

Në një situatë ideale, loja e planifikimit midis klientit dhe programuesit duhet të luhet çdo 3-6 javë, derisa të fillojë përsëritja e ardhshme e zhvillimit. Kjo e bën mjaft të lehtë kryerjen e rregullimeve bazuar në sukseset dhe dështimet e përsëritjes së mëparshme.

4. Përparësitë dhe disavantazhet

Përparësitë e XP, nëse mund të zbatohet, janë fleksibiliteti më i madh, aftësia për të bërë ndryshime të shpejta dhe të sakta në softuer në përgjigje të ndryshimit të kërkesave dhe dëshirave individuale të klientit, cilësia e lartë e kodit që rezulton dhe mungesa e nevojës për të. bindin klientët se rezultati i plotëson pritshmëritë e tyre.

Disavantazhet e kësaj qasjeje janë praktikueshmëria e projekteve mjaft të mëdha dhe komplekse në këtë stil, pamundësia për të planifikuar kohën dhe kompleksitetin e projektit për një afat mjaftueshëm afatgjatë dhe për të parashikuar qartë rezultatet e një projekti afatgjatë në aspektin e raportit. të cilësisë së rezultatit dhe kostove të kohës dhe burimeve. Gjithashtu mund të theksohet se XP nuk është i përshtatshëm për ato raste në të cilat zgjidhjet e mundshme nuk gjenden menjëherë në bazë të përvojës së fituar më parë, por kërkojnë kërkime paraprake.

5. Historia e përdorimit

XP si një grup teknikash të përshkruara u përdor për herë të parë gjatë punës në projektin C3 (Chrysler Comprehensive Compensation System, zhvillimi i një sistemi për llogaritjen e përfitimeve të punonjësve në Daimler Chrysler). Nga 20 pjesëmarrësit në këtë projekt, 5 (përfshirë 3 autorët kryesorë të lartpërmendur të XP) botuan 3 libra dhe sasi e madhe artikuj kushtuar XP. Të dhënat e mëposhtme ilustrojnë problemet me disa teknika XP kur aplikohen në projekte mjaft komplekse.

Projekti filloi në janar 1995. Që nga marsi 1996, pas përfshirjes së Kent Beck, ai është drejtuar duke përdorur XP. Në këtë kohë, ajo tashmë kishte shkuar përtej buxhetit dhe planeve për zbatimin me faza të funksioneve. Ekipi i zhvillimit u ndërpre dhe për rreth gjashtë muaj më pas projekti u zhvillua me mjaft sukses. Në gusht 1998, u shfaq një prototip që mund t'u shërbente rreth 10,000 punonjësve. Projekti fillimisht pritej të përfundonte në mesin e vitit 1999 dhe softueri që do të rezultonte do të përdorej për të menaxhuar përfitimet për 87,000 punonjësit e kompanisë. Ai u ndërpre në shkurt 2000 pas 4 vitesh funksionim të XP për shkak të dështimit të plotë për të përmbushur kornizat kohore dhe buxhetin. Softueri i krijuar nuk është përdorur kurrë për të punuar me të dhëna për më shumë se 10,000 punonjës, megjithëse është treguar se mund të trajtojë të dhëna për 30,000 punonjës të kompanisë. Personi që luajti rolin e klientit të përfshirë në ekipin e projektit u largua pas disa muajsh punë të tillë, në pamundësi për të përballuar ngarkesën e punës dhe nuk mori kurrë një zëvendësim adekuat deri në fund të projektit.

konkluzioni

Të gjitha metodat e mësipërme nuk janë bashkuar rastësisht. Kombinimi i tyre i qëndrueshëm mund ta sjellë procesin e zhvillimit në rezonancë intelektuale, duke rritur ndjeshëm cilësinë e produktit dhe duke përshpejtuar kohën e lëshimit të tij. Bukuria kryesore e të gjithë programimit ekstrem është parashikueshmëria dhe minimizimi i kostove të zhvillimit; sigurimin e klientit me produktin që ai dëshiron të marrë në momentin e lëshimit; dhe sigurisht, komunikimi dhe trajnimi i zhvilluesve në punë.

Opinionet rreth metodologjisë së propozuar mund të ndryshojnë. Është e rëndësishme të kuptohet se Programimi Ekstrem nuk synon të zëvendësojë teknologjitë ekzistuese zhvillimin. Përkundrazi, XP mund të ofrojë shtysë shtesë për ekipet që përdorin qasjet tradicionale. Ju nuk duhet të kërkoni këtu për përgjigje për të gjitha pyetjet tuaja. Kjo nuk është një teknologji programimi, por më tepër teknologji organizimin e punës dhe pikërisht në këtë formë ka të drejtën e jetës.

Postuar në Allbest.ru

Dokumente të ngjashme

Analiza e fazave dhe veçorive të zhvillimit të një modeli ARIS optimal dhe funksional - një produkt softuer nga IDS Scheer për modelimin e proceseve të biznesit të kompanisë. Studimi i koncepteve bazë, metodologjive dhe qasjeve të programimit ekstrem.

test, shtuar 06/04/2011


Fazat kryesore të zhvillimit të softuerit (paketë softuerike), analiza e kërkesave të sistemit. Metoda e detajimit hap pas hapi. Gjuhë programimi të nivelit të ulët dhe të lartë (imperativ, i orientuar nga objekti, funksional, logjik).

prezantim, shtuar 13.10.2013


Gjuha e zhvillimit, mjedisi i zbatimit, mjetet e zhvillimit. Veçoritë mjedis virtual zbatimi i programeve dhe shqyrtimi i tyre në zhvillimin e një produkti softuer. Makrot e sistemit dhe përdorimi i tyre në tekstet e zhvillimit. Mjetet e programimit vizual.

tutorial, shtuar më 26/10/2013


Problemi i besueshmërisë së softuerit, treguesit e tij dhe faktorët mbështetës. Metodat për monitorimin e procesit të zhvillimit të programeve dhe dokumentacionit, parandalimin e gabimeve. Fazat e procesit të korrigjimit të softuerit, teknikat e programimit të strukturuar dhe parimi i modularitetit.

prezantim, shtuar 30.04.2014


Kodet e makinës dhe montuesi. Gjuhët e para të programimit të nivelit të lartë. Gjuha e programimit FORTRAN. Avantazhet dhe disavantazhet e ALGOL. Programet shkencore dhe të kontabilitetit. Parimet bazë që u ndoqën gjatë krijimit të gjuhës së programimit Basic.

puna e kursit, shtuar 21.06.2014


Koncepti dhe ndryshimi kryesor i zhvillimit të softuerit të shpërndarë, avantazhet dhe disavantazhet e tij. Zgjidhja konceptuale dhe zgjedhja e llojit të zhvillimit. Karakteristikat e softuerit me kod të hapur. Ideja dhe zhvillimi i Open Source.

puna e kursit, shtuar 14.12.2012


Koncepti cikli i jetes software. Dy lloje aktivitetesh, të dalluara në projektet teknike: projektimi dhe prodhimi. Parimet kryesore të manifestit të ndjekësve të metodologjive fleksibël. Parimet themelore të programimit ekstrem.

prezantim, shtuar 14.08.2013


Standard ndërkombëtar në gjuhën e programimit Pascal. Teknikat e programimit të orientuar nga objekti në Turbo Pascal. Simbolet e gjuhës, alfabeti i saj. Fazat e zhvillimit të programit. Koncepti i algoritmeve dhe algoritmi. Struktura e programeve në Pascal.

puna e kursit, shtuar 28/02/2010


Mjete moderne të zhvillimit të softuerit për sistemet e kontrollit. Gjuhët e programimit universal dhe krahasimi i tyre me sistemet SCADA. Zhvillimi i softuerit duke përdorur shumë kanale dhënës matësШ9327.

tezë, shtuar 13.07.2011


Teknikat bazë për të punuar në mjedis Programimi Delphi. Karakteristikat e teknologjisë për krijimin e aplikacioneve të thjeshta. Puna me komponentët e mjedisit të zhvillimit të aplikacionit. Futja, redaktimi, përzgjedhja dhe nxjerrja e informacionit. Aspektet e përdorimit të strukturës së degëzimit.

Programimi ekstrem (XP) është një nga metodologjitë fleksibël të zhvillimit të softuerit. Autorët e metodologjisë janë Kent Beck, Ward Cunningham, Martin Fowler dhe të tjerë.

Lojë e planifikimit

Bota jonë është shumë e ndryshueshme dhe e paparashikueshme për t'u mbështetur në qëndrueshmërinë e situatës. E njëjta gjë ndodh në zhvillimin e softuerit: me një sistem të rrallë, mund të thuhet se forma e tij përfundimtare ishte e njohur paraprakisht në detaje që në fillimet e zhvillimit. Në mënyrë tipike, oreksi i klientit vjen gjatë ngrënies: ai vazhdimisht dëshiron të ndryshojë diçka, të përmirësojë diçka ose të flakë fare nga sistemi. Kjo është ndryshueshmëria e kërkesave që të gjithë kanë kaq frikë. Për fat të mirë, një personi i jepet aftësia për të parashikuar opsionet e mundshme dhe, në këtë mënyrë, të mbajë situatën nën kontroll.
Në Programimin Ekstrem, planifikimi është një pjesë integrale e zhvillimit dhe fakti që planet mund të ndryshojnë merret parasysh që në fillim. Pika mbështetëse, teknika që ju lejon të parashikoni situatën dhe të përballoni pa dhimbje ndryshimet, është loja e planifikimit. Gjatë një loje të tillë, kërkesat e njohura të sistemit mund të mblidhen shpejt, vlerësohen dhe planifikohen sipas përparësisë.
Si çdo lojë tjetër, planifikimi ka pjesëmarrësit dhe qëllimin e tij. Figura kryesore është, natyrisht, klienti. Është ai që komunikon nevojën për këtë apo atë funksionalitet. Programuesit japin një vlerësim të përafërt të secilit funksionalitet. Bukuria e lojës së planifikimit qëndron në unitetin e qëllimit dhe solidaritetin midis zhvilluesit dhe klientit: në rast fitoreje, të gjithë fitojnë, në rast humbjeje, të gjithë humbasin. Por në të njëjtën kohë, secili pjesëmarrës shkon në rrugën e tij drejt fitores: klienti zgjedh detyrat më të rëndësishme në përputhje me buxhetin, dhe programuesi vlerëson detyrat në përputhje me aftësinë e tij për t'i zbatuar ato.
Programimi ekstrem supozon se zhvilluesit janë në gjendje të vendosin vetë se sa kohë do t'u duhet për të përfunduar detyrat e tyre dhe cili prej tyre do të ishte më i gatshëm për të zgjidhur një problem dhe kush një tjetër.
Në një situatë ideale, loja e planifikimit midis klientit dhe programuesit duhet të luhet çdo 3-6 javë, derisa të fillojë përsëritja e ardhshme e zhvillimit. Kjo e bën mjaft të lehtë kryerjen e rregullimeve bazuar në sukseset dhe dështimet e përsëritjes së mëparshme.

Plani i lëshimit

Plani i lëshimit përcakton datat e lëshimit dhe deklaratat e përdoruesve që do të zbatohen në secilën prej tyre. Bazuar në këtë, ju mund të zgjidhni formulimet për përsëritjen e ardhshme. Gjatë një përsëritjeje, testet e pranimit prodhohen dhe ekzekutohen brenda atij përsëritjeje dhe të gjithë atyre të mëvonshme për të siguruar që programi funksionon siç duhet. Plani mund të rishikohet nëse ka një vonesë ose epërsi të konsiderueshme në fund të njërit prej përsëritjeve.
Përsëritjet. Përsëritja e bën procesin e zhvillimit dinamik. Nuk ka nevojë të planifikoni detyrat tuaja të softuerit shumë përpara. Në vend të kësaj, është më mirë të keni një takim planifikimi në fillim të çdo përsëritjeje. Nuk ka kuptim të përpiqesh të zbatosh diçka që nuk ishte planifikuar. Ju do të keni ende kohë për t'i zbatuar këto ide kur ato të lëshohen sipas planit të lëshimit.
Duke u bërë zakon të mos shtoni funksionalitet përpara dhe duke përdorur planifikimin përpara, ju mund të përshtateni lehtësisht me ndryshimin e kërkesave të klientëve.

Planifikimi i përsëritjes

Planifikimi i përsëritjes fillon me një takim në fillim të çdo përsëritjeje për të zhvilluar një plan hapash për zgjidhjen e problemeve të softuerit. Çdo përsëritje duhet të zgjasë nga një deri në tre javë. Formulimet brenda një përsëritjeje janë renditur sipas rëndësisë së tyre për klientin. Përveç kësaj, shtohen detyra që nuk mund të kalojnë testet e pranimit dhe kërkojnë punë të mëtejshme. Deklaratat dhe rezultatet e testit përkthehen në probleme softuerike. Detyrat shkruhen në karta që formojnë një plan të detajuar përsëritjeje. Duhen nga një deri në tre ditë për të zgjidhur çdo problem. Detyrat që kërkojnë më pak se një ditë mund të grupohen së bashku dhe detyrat e mëdha mund të ndahen në disa më të vogla. Zhvilluesit vlerësojnë detyrat dhe afatet për përfundimin e tyre. Është shumë e rëndësishme që një zhvillues të përcaktojë me saktësi kohën e ekzekutimit të një detyre. Mund të jetë e nevojshme të rivlerësoni disa gjuhë dhe të rishikoni planin e lëshimit pas çdo tre ose pesë përsëritjesh - kjo është plotësisht e pranueshme. Nëse së pari zbatoni fushat më të rëndësishme të punës, atëherë do të keni gjithmonë kohë për të bërë maksimumin e mundshëm për klientët tuaj. Një stil zhvillimi përsëritës përmirëson procesin e zhvillimit.

Takimi në këmbë

Çdo mëngjes mbahet një takim për të diskutuar problemet, zgjidhjet e tyre dhe për të forcuar përqendrimin e ekipit. Takimi mbahet në këmbë për të shmangur diskutimet e gjata që nuk janë interesante për të gjithë anëtarët e ekipit.
Në një takim tipik, shumica e pjesëmarrësve nuk kontribuojnë asgjë, thjesht merrni pjesë për të dëgjuar atë që të tjerët kanë për të thënë. Nje numer i madh i Koha e njerëzve humbet për të marrë një sasi të vogël komunikimi. Prandaj, prania e të gjithëve në takime heq burimet nga projekti dhe krijon kaos në planifikim.
Ky lloj komunikimi kërkon një takim të qëndrueshëm. Është shumë më mirë të kesh një takim të shkurtër e të detyrueshëm sesa shumë takime të gjata në të cilat shumica e zhvilluesve duhet të marrin pjesë gjithsesi.
Nëse keni takime të përditshme në këmbë, atëherë të gjitha takimet e tjera duhet të marrin pjesë vetëm nga ata njerëz që janë të nevojshëm dhe do të sjellin diçka në tryezë. Madje, është e mundur të shmangni edhe disa takime. Me pjesëmarrje të kufizuar, shumica e takimeve mund të mbahen spontanisht përpara një monitori, ku shkëmbimi i ideve është shumë më intensiv.
Takimi i përditshëm i mëngjesit nuk është një tjetër humbje kohe. Kjo do t'ju lejojë të shmangni shumë takime të tjera dhe do t'ju kursejë më shumë kohë sesa shpenzoni për to.

Thjeshtësia

Një dizajn i thjeshtë kërkon gjithmonë më pak kohë se një dizajn kompleks. Pra, bëni gjithmonë gjërat më të thjeshta që do të funksionojnë. Është gjithmonë më e shpejtë dhe më e lirë për të zëvendësuar kodin kompleks menjëherë, përpara se të kaloni shumë kohë duke punuar në të. Mbajini gjërat sa më të thjeshta që të jetë e mundur pa shtuar funksionalitet përpara se të planifikoni. Mbani në mend: mbajtja e një dizajni të thjeshtë është punë e vështirë.

Sistemi i metaforës

Zgjedhja e një sistemi metaforash nevojitet për të mbajtur ekipin brenda të njëjtit kornizë kur emërtohen klasa dhe metoda. Mënyra se si i emërtoni objektet tuaja është shumë e rëndësishme për të kuptuar dizajnin e përgjithshëm të sistemit dhe ripërdorimin e kodit. Nëse zhvilluesi është në gjendje të parashikojë saktë se si objekt ekzistues, kjo çon në kursim të kohës. Përdorni një sistem emërtimi për objektet tuaja që të gjithë mund ta kuptojnë pa njohuri specifike të sistemit.

Klienti në vendin e punës

Problemi kryesor në zhvillimin e softuerit është mungesa e njohurive të programuesve në fushën lëndore që zhvillohet. Programimi ekstrem ka gjetur një rrugëdalje nga kjo situatë. Jo, kjo nuk është një praktikë e zhvilluesit në ndërmarrjen e klientit - atëherë ai nuk do të dëshirojë të programojë. Përkundrazi, është pjesëmarrja e klientit në procesin e zhvillimit.
A mundet një programues, pa e kuptuar plotësisht thelbin e çështjes dhe duke mos qenë telepat, të marrë me mend se çfarë dëshiron klienti? Përgjigja është e qartë. Mënyra më e lehtë për të kapërcyer këtë shqetësim - dhe Programimi Ekstrem na mëson të gjejmë zgjidhjet më të thjeshta - është t'i bëjmë klientit një pyetje të drejtpërdrejtë. Qasjet më rigoroze kërkojnë një analizë paraprake gjithëpërfshirëse të zonës që po zhvillohet. NË raste të caktuara Kjo është e justifikuar, megjithëse është më e shtrenjtë. Përvoja reale në drejtimin e projekteve të zakonshme tregon se është e pamundur të mblidhen të gjitha kërkesat paraprakisht. Për më tepër, edhe nëse supozojmë se të gjitha kërkesat janë mbledhur aktualisht, do të ketë ende një pengesë: programet, si çdo gjë në natyrë, nuk krijohen menjëherë, dhe ndërkohë proceset e biznesit mund të ndryshojnë. Kjo duhet të merret parasysh.
Shumë dyshojnë në mundësinë e përfshirjes së klientit në procesin e zhvillimit. Në fakt, klientët janë të ndryshëm. Nëse nuk është e mundur të tërheqësh klientin ose përfaqësuesin e tij, ndonjëherë këshillohet të punësosh përkohësisht një specialist në fushën që po zhvillohet. Ky hap do të reduktojë paqartësitë në punë, do të rrisë shpejtësinë e zhvillimit dhe do ta afrojë projektin me atë që klienti dëshiron të marrë. Kjo mund të jetë gjithashtu e dobishme nga ana financiare: në fund të fundit, paga e një programuesi ndonjëherë është dukshëm më e lartë se paga e specialistëve në industri të tjera.
Historia e përdoruesit. Historia e përdoruesit (diçka si historia e një përdoruesi) është një përshkrim se si duhet të funksionojë sistemi. Çdo histori përdoruesi është shkruar në një kartë dhe përfaqëson një pjesë të funksionalitetit të sistemit që ka kuptim logjik nga këndvështrimi i klientit. Forma është një ose dy paragrafë teksti që është i kuptueshëm për përdoruesin (jo shumë teknik).
Historia e Përdoruesit është shkruar nga Klienti. Këto janë të ngjashme, por pa u kufizuar në, skenarët e përdorimit të sistemit ndërfaqja e përdoruesit. Për çdo histori, testet funksionale shkruhen për të konfirmuar se kjo histori është zbatuar saktë - ato quhen gjithashtu teste pranimi.

Testimi para fillimit të zhvillimit

Testimi, në kuptimin e tij klasik, është një procedurë mjaft e mërzitshme. Zakonisht ata punësojnë një testues që kryen periodikisht të njëjtat veprime dhe pret ditën kur më në fund të transferohet në një pozicion tjetër ose të krijohet mundësia për të ndryshuar vendin e punës.
Në programimin ekstrem, roli i testimit është më interesant: tani së pari vjen testi dhe më pas kodi. Si të testoni diçka që nuk ekziston ende? Përgjigja është e thjeshtë dhe banale: provoni mendimet tuaja - çfarë të prisni nga një pjesë e ardhshme e programit ose funksionalitetit. Kjo do t'ju lejojë të kuptoni më mirë se çfarë duhet të bëjnë programuesit dhe të kontrolloni funksionalitetin e kodit sapo të shkruhet.
Por edhe testi mund të mos funksionojë. Pra, çfarë, shkruani një test për një test? Dhe pastaj test për provë dhe kështu me radhë ad infinitum? Aspak. Testi për testin do të zëvendësojë kodin. Si keshtu? Por shikoni: imagjinoni që duhet të rregulloni arrën në mes të bulonës në mënyrë që të mos kthehet. Çfarë po bëjnë për këtë? Vidhosni dadën e dytë afër të parës, në mënyrë që çdo arrë të parandalojë rrotullimin e ngjitur. Është e njëjta gjë në programim: testi teston kodin dhe kodi teston testin.
Përvoja tregon se kjo qasje jo vetëm që nuk ngadalëson, por edhe përshpejton zhvillimin. Në fund të fundit, duke ditur se çfarë duhet bërë dhe sasia e kërkuar e punës do të kursejë kohë duke refuzuar shitjen e artikujve të pakërkuar. ky moment detajet.

Programimi në çift

I gjithë kodi për sistemin e prodhimit është i shkruar në çifte. Dy zhvillues janë ulur pranë njëri-tjetrit. Njëri është duke shtypur, tjetri po shikon. Ato ndryshojnë herë pas here. Nuk lejohet të punosh vetëm. Nëse për ndonjë arsye i dyti i çiftit ka humbur diçka (i sëmurë, në pension, etj.), Ai është i detyruar të rishikojë të gjitha ndryshimet e bëra nga i pari.
Tingëllon e pazakontë, por pas një periudhe të shkurtër përshtatjeje, shumica e njerëzve punojnë mirë në çifte. Ata madje e pëlqejnë sepse puna kryhet dukshëm më shpejt. Zbatohet parimi "Një kokë është e mirë, por dy është më mirë". Çiftet zakonisht gjejnë zgjidhje më të mira. Për më tepër, cilësia e kodit rritet ndjeshëm, numri i gabimeve zvogëlohet dhe shkëmbimi i njohurive midis zhvilluesve është përshpejtuar. Ndërsa një person fokusohet në vizionin strategjik të objektit, i dyti zbaton vetitë dhe metodat e tij.

Ndryshimi i pozicioneve

Gjatë përsëritjes tjetër, të gjithë punëtorët duhet të zhvendosen në fusha të reja të punës. Lëvizje të tilla janë të nevojshme për të shmangur izolimin e njohurive dhe për të eliminuar " vende të ngushta" Veçanërisht i frytshëm është zëvendësimi i një prej zhvilluesve në programimin në çift.

Pronësia e kodit kolektiv

Pronësia e kodit të përbashkët inkurajon zhvilluesit të paraqesin ide për të gjitha pjesët e projektit, jo vetëm për modulet e tyre. Çdo zhvillues mund të ndryshojë çdo kod për të zgjeruar funksionalitetin dhe për të rregulluar gabimet.
Në pamje të parë duket si kaos. Sidoqoftë, duke marrë parasysh që të paktën çdo kod është krijuar nga disa zhvillues, testet ju lejojnë të verifikoni korrektësinë e ndryshimeve të bëra dhe jeta reale Edhe pse ju ende duhet të kuptoni kodin e dikujt tjetër në një mënyrë ose në një tjetër, bëhet e qartë se pronësia kolektive e kodit thjeshton shumë ndryshimet dhe zvogëlon rrezikun që lidhet me specializimin e lartë të një ose një anëtari tjetër të ekipit.

Konventa e kodimit

Ju jeni pjesë e një ekipi që punon për këtë projekt për një kohë të gjatë. Njerëzit vijnë e shkojnë. Askush nuk kodon vetëm dhe kodi i përket të gjithëve. Gjithmonë do të ketë raste kur ju duhet të kuptoni dhe rregulloni kodin e dikujt tjetër. Zhvilluesit do të heqin ose ndryshojnë kodin e kopjuar, do të analizojnë dhe përmirësojnë klasat e njerëzve të tjerë, etj. Me kalimin e kohës, do të jetë e pamundur të thuhet se kush është autori i një klase të caktuar.
Prandaj, të gjithë duhet t'u binden standardeve të zakonshme të kodimit - formatimi i kodit, emërtimi i klasave, variablat, konstantet, stili i komenteve. Në këtë mënyrë, ne do të jemi të sigurt që kur të bëjmë ndryshime në kodin e dikujt tjetër (i cili është i nevojshëm për përparimin agresiv dhe ekstrem përpara), ne nuk do ta kthejmë atë në Babel Pandemonium.
Sa më sipër do të thotë që të gjithë anëtarët e ekipit duhet të bien dakord për standardet e përbashkëta të kodimit. Nuk ka rëndësi se cilat. Rregulli është që të gjithë t'i binden. Ata që nuk duan t'i zbatojnë ato largohen nga ekipi.

Integrimi i shpeshtë

Zhvilluesit duhet të integrojnë dhe lëshojnë kodin e tyre çdo disa orë nëse është e mundur. Në çdo rast, nuk duhet t'i mbani kurrë ndryshimet për më shumë se një ditë. Integrimi i shpeshtë shmang tjetërsimin dhe fragmentimin në zhvillim, ku zhvilluesit nuk mund të komunikojnë në kuptimin e ndarjes së ideve ose ripërdorimit të kodit. Të gjithë duhet të punojnë me maksimumin Versioni i fundit.
Çdo palë zhvilluesish duhet të kontribuojë me kodin e tyre sa më shpejt që të jetë e mundur në mënyrë të arsyeshme për ta bërë këtë. Kjo mund të ndodhë kur të gjitha UnitTests kalojnë 100%. Duke paraqitur ndryshime disa herë në ditë, ju reduktoni problemet e integrimit pothuajse në zero. Integrimi është një aktivitet “paguani tani ose paguani më shumë më vonë”. Prandaj, duke integruar ndryshimet në rritje të vogla çdo ditë, nuk do ta gjeni veten që duhet të kaloni një javë duke u përpjekur të lidhni sistemin së bashku pak para se projekti të dorëzohet. Punoni gjithmonë në versionin më të fundit të sistemit.

Dyzet orë punë në javë

Një person, veçanërisht nëse është programues, është i aftë të bëjë shumë për hir të biznesit: të qëndrojë vonë në punë, të shkojë në punë gjatë fundjavave, të heqë dorë nga pushimet, të qëndrojë zgjuar për disa ditë duke u ulur në tastierë... Në përgjithësi, çfarë mund të bëni për hir të aktivitetit tuaj të preferuar. Por programimi ekstrem është kategorikisht kundër një vetëflijimi të tillë dhe shkeljes së standardeve të pranuara të ligjit të punës.
Kjo diktohet jo vetëm nga konsideratat e ligjshmërisë dhe humanizmit, por, para së gjithash, nga nevoja për të rritur efikasitetin e punës dhe organizimin e rreptë. Në fund të fundit, programimi ekstrem është një lojë kolektive, e krijuar jo për individët, por për të gjithë grupin. Dhe një gjë e tillë si, për shembull, programimi në çift është i mundur vetëm kur sinkronizohen bioritmet e pjesëmarrësve të tij. Dhe është e pamundur nëse një person vjen në punë në nëntë, dhe i dyti në dymbëdhjetë, ose njëri vendos që është më mirë për të të punojë të shtunën dhe të dielën, ndërsa tjetri është i papërshtatshëm.
Por gjëja më e rëndësishme është se për të ruajtur shëndetin dhe performancën, një person ka nevojë për pushim të duhur. Dita e punës tetë orëshe dhe java pesëditore e punës vendosen pikërisht për arsye të produktivitetit maksimal. Në shumë kompani perëndimore, lënia e punës me vonesë konsiderohet si dështim për të performuar mirë ose paaftësi për të menaxhuar siç duhet kohën e punës. Në shumicën e rasteve kjo është e vërtetë. Dhe nga pikëpamja mjekësore, vonesat në punë çojnë në lodhje të vazhdueshme, nervozizëm dhe ulje të aktivitetit të trurit. A është kjo efektive? Si mund të organizojmë komunikim të hapur të vazhdueshëm midis zhvilluesve në një ekip të tillë dhe a do të jetë i mundur programimi në çift? Përgjigja është negative. Standardet janë standarde dhe duhen ndjekur.

konkluzioni

Këto metoda nuk bashkohen rastësisht. Kombinimi i tyre i qëndrueshëm mund ta sjellë procesin e zhvillimit në rezonancë intelektuale, duke rritur ndjeshëm cilësinë e produktit dhe duke përshpejtuar kohën e lëshimit të tij. Bukuria kryesore e të gjithë programimit ekstrem është parashikueshmëria dhe minimizimi i kostove të zhvillimit; sigurimin e klientit me produktin që ai dëshiron të marrë në momentin e lëshimit; dhe sigurisht, komunikimi dhe trajnimi i zhvilluesve në punë.

Bibliografi:

Programimi ekstrem - ose, shkurt, XP (Programimi eXtreme) - është përgjigja e komunitetit të programuesve ndaj sulmit të qasjeve formale për krijimin e produkteve softuerike dhe është krijuar për të kthyer frymën e krijimtarisë në mjedisin e zhvilluesve.

Çdo ide e çuar deri në absurd degjeneron në të kundërtën e saj. Kjo është pikërisht situata në industrinë e softuerit të Amerikës së Veriut me mjetet e zhvillimit të RAD. Në një moment, mjetet e krijuara për zhvillimin e shpejtë të aplikacioneve filluan të fshijnë gjithçka tjetër në mendjet e menaxherëve, duke përfshirë zhvilluesit, klientët dhe vetë projektin. Vëmendja e pajustifikuar, e hipertrofizuar ndaj Procesit në dëm të faktorëve të tjerë të zhvillimit shkaktoi shumë procedura formale - por cilësia e produkteve që rezultuan dhe numri i projekteve të suksesshme doli të ishte zhgënjyese.

Nisma e një grupi zhvilluesish të bashkuar nën sloganin Extreme Programming, ose XP, është krijuar për t'i rezistuar presionit të formalizmit në punën e programuesve.

Programimi ekstrem bazohet në disa parime shumë specifike, shpesh të shprehura numerikisht, që përcaktojnë se çfarë duhet bërë, kur dhe si duhet bërë. Megjithatë, pa i marrë këto shifra si dogmë, duhet të kihet parasysh se ato u shfaqën si rezultat i analizës së projekteve të shumta të suksesshme dhe të pasuksesshme, kështu që të paktën duhet të ketë arsye të mira për të bërë ndryshime.

Programimi ekstrem nuk bazohet në teknika specifike, siç besohet zakonisht, por vetëm në katër parime bazë: komunikim, thjeshtësi, reagime dhe guxim. Këtu duhet të filloni.

Extreme Programming ofron një zgjidhje të gatshme: mbani gjithçka sa më të thjeshtë, mbajeni klientin pranë vetes ose qëndroni me klientin, lëreni të monitorojë në mënyrë aktive procesin e zhvillimit, mirëpret ndryshimin - dhe suksesi është pothuajse i garantuar.

Në ekipet XP, komunikimi inkurajohet gjithmonë - mënyra më e shpejtë për të shkëmbyer informacion dhe përvojë. Kjo është shumë e rëndësishme kur kërkohet shpejtësia maksimale e zhvillimit. Por komunikimi, si çdo përpjekje tjetër e dobishme, kërkon mbështetje të vazhdueshme. Kjo është arsyeja pse dikush nga ekipi duhet të marrë përgjegjësinë për monitorimin e komunikimit, duke u bërë një i ashtuquajtur diplomat. Komunikimi dhe nevoja për t'u shpjeguar veprimet tuaja anëtarëve të tjerë të ekipit ju detyron të bëni gjithçka sa më thjesht të jetë e mundur. Nëse nuk funksionon herën e parë, ata punojnë në thjeshtim përsëri dhe përsëri derisa të arrihet qëllimi kryesor - kuptueshmëria maksimale e kodit për zhvilluesit e tjerë.

Cikli ekstrem

Programimi ekstrem bazohet në një cikël zhvillimi shumë të shkurtër, përsëritës prej një deri në tre javë. Deri në fund të çdo cikli, duhet të ketë një lëshim plotësisht funksional, funksional dhe të testuar të aplikacionit. Këto cikle duhet të përsëriten dhe të pandërprera gjatë gjithë projektit.

Parakusht për këtë mënyrë funksionimi është fakti i vërtetuar në mënyrë të përsëritur se kërkesat janë rrallë të plota, në kohë dhe të sakta. Me fjalë të tjera, pavarësisht se sa mirë është planifikuar një aplikacion, ai 100% duhet të ridizajnohet. Për më tepër, mund të duhet të ribëhet edhe në fazën përfundimtare. Ndryshimet nuk duhet të shtyhen deri në fund të punës, ato duhet të bëhen rregullisht.

Si pasojë e ndryshimit të vazhdueshëm të kërkesave, vijon një parim tjetër - vendimmarrja me vonesë.

Programimi ekstrem është një metodologji për zhvillimin e shpejtë të softuerit. Ai përbëhet nga një grup teknikash dhe parimesh që lejojnë, si individualisht ashtu edhe në kombinim, të optimizojnë procesin e zhvillimit. Kjo qasje rregullon gjithashtu të drejtat e zhvilluesve dhe klientëve.

Të drejtat dhe rolet

Në programimin ekstrem, të gjitha rolet përshkruhen qartë. Çdo rol vjen me një grup karakteristik të të drejtave dhe përgjegjësive. Këtu ka dy role kryesore: klienti dhe zhvilluesi.

Klienti

Një person ose grup njerëzish të interesuar në krijimin e një produkti specifik softuerësh. Ai ka të drejtat dhe detyrimet e mëposhtme:

• rregulloni datat e lëshimit për versionet e produktit;
• marrin vendime në lidhje me komponentët e planifikuar të programit;
• dinë koston e vlerësuar të secilit komponent funksional;
• merrni vendime të rëndësishme biznesi;
• e di Gjendja e tanishme sistemet;
• ndryshoni kërkesat e sistemit kur është vërtet e rëndësishme.

Për të ushtruar me sukses të drejtat e tij, klienti duhet të mbështetet në të dhënat e ofruara nga zhvilluesit.

Zhvilluesi

Një ose një grup prej dy deri në dhjetë persona të përfshirë drejtpërdrejt në programim dhe çështje të ndërlidhura inxhinierike. Zhvilluesi është i pajisur të drejtat e mëposhtme dhe përgjegjësitë:

• të marrë njohuri të mjaftueshme për çështjet që do të programohen;
• të jetë në gjendje të sqarojë detajet gjatë procesit të zhvillimit;
• jepni vlerësime indikative, por të sinqerta të përpjekjes së kërkuar për çdo veçori ose histori të përdoruesit;
• të rregullojë vlerësimet në favor të atyre më të sakta gjatë procesit të zhvillimit;
• të sigurojë një vlerësim të rreziqeve që lidhen me përdorimin e teknologjive specifike.

Rolet brenda një roli

Secili nga rolet bazë të Programimit Ekstrem mund të rafinohet nga role më të vogla. XP lejon kombinimin e roleve brenda një personi.

Ana e klientit

Përpiluesi i tregimeve- një specialist i çështjeve me aftësinë për të shprehur dhe përshkruar qartë kërkesat për sistemin që po zhvillohet. Ky person ose grup njerëzish është përgjegjës për shkrimin e historive të përdoruesve dhe pastrimin e keqkuptimeve nga ana e programuesve.

Marrësi- një person që monitoron funksionimin e duhur të sistemit. Komandim i mirë fusha lëndore. Përgjegjësitë përfshijnë shkrimin e testeve të pranimit.

Bosi i madh- monitoron punën e të gjitha niveleve, nga zhvilluesit tek përdoruesit përfundimtarë. Ai kontrollon zbatimin e sistemit dhe çështjet e lidhura organizative. Mund të jetë gjithashtu një investitor në projekt.

Ana e zhvilluesit

Programues- një person i përfshirë në kodim dhe dizajn të nivelit të ulët. Ai është mjaft kompetent për të zgjidhur problemet aktuale të zhvillimit dhe për të ofruar vlerësime të sinqerta të detyrave të planifikuara.

Instruktori- një zhvillues me përvojë me njohuri të mira të të gjithë procesit të zhvillimit dhe teknikave të tij. Përgjegjës për trajnimin e ekipit në aspekte të procesit të zhvillimit. Zbaton dhe monitoron zbatimin korrekt të metodave të procesit të përdorura. Tërheq vëmendjen e ekipit për pika të rëndësishme zhvillimi, por për disa arsye, të humbura. Në të njëjtën kohë, instruktori, si çdo person tjetër, nuk është i gjithëdijshëm dhe i kushton vëmendje ideve të anëtarëve të tjerë të ekipit.

Vëzhguesi- një anëtar i ekipit të zhvillimit, i besuar nga i gjithë grupi, i cili monitoron ecurinë e zhvillimit. Ai krahason vlerësimet paraprake kostot e punës dhe të shpenzuara në fakt, duke shfaqur tregues sasiorë të punës së ekipit. Këto janë të tilla si shpejtësia mesatare dhe përqindja e detyrave të kryera dhe të planifikuara. Ky informacion i jepet klientit për kontrollin në kohë të situatës. Një pjesë e këtij informacioni u jepet pa vëmendje zhvilluesve, kështu që ata e dinë statusin e projektit, ku lindin vështirësitë dhe çfarë tjetër mund të bëhet.

Diplomat- një person i shoqërueshëm që fillon komunikimin midis anëtarëve të ekipit. Meqenëse rrjedha e dokumenteve është minimizuar, komunikimi i vazhdueshëm dhe transferimi i përvojës brenda ekipit, një kuptim më i mirë i kërkesave për sistemin, janë të rëndësishme. Diplomati rregullon dhe thjeshton komunikimin midis klientëve dhe zhvilluesve. Është një lidhje e rëndësishme në takime. Parandalon lëshimet, pasionet e shtuara dhe grindjet e panevojshme. Një diplomat nuk mund të imponojë mendimin e tij ndaj atyre që diskutojnë.

Rolet e jashtme

konsulent- një specialist me aftësi specifike teknike për të ndihmuar zhvilluesit me probleme të vështira për t'u zgjidhur. Zakonisht sillen nga jashtë.

Rregullat e programimit ekstrem

Konventa e kodimit

Ju jeni pjesë e një ekipi që punon për këtë projekt për një kohë të gjatë. Njerëzit vijnë e shkojnë. Askush nuk kodon vetëm dhe kodi i përket të gjithëve. Gjithmonë do të ketë raste kur ju duhet të kuptoni dhe rregulloni kodin e dikujt tjetër. Zhvilluesit do të heqin ose ndryshojnë kodin e kopjuar, do të analizojnë dhe përmirësojnë klasat e njerëzve të tjerë, etj. Me kalimin e kohës, do të jetë e pamundur të thuhet se kush është autori i një klase të caktuar.

Prandaj, të gjithë duhet t'u binden standardeve të zakonshme të kodimit - formatimi i kodit, emërtimi i klasave, variablat, konstantet, stili i komenteve. Në këtë mënyrë, ne do të jemi të sigurt që kur të bëjmë ndryshime në kodin e dikujt tjetër (i cili është i nevojshëm për përparimin agresiv dhe ekstrem përpara), ne nuk do ta kthejmë atë në Babel Pandemonium.

Sa më sipër do të thotë që të gjithë anëtarët e ekipit duhet të bien dakord për standardet e përbashkëta të kodimit. Nuk ka rëndësi se cilat. Rregulli është që të gjithë t'i binden. Ata që nuk duan t'i zbatojnë ato largohen nga ekipi.

Pronësia e kodit kolektiv

Pronësia e kodit të përbashkët inkurajon zhvilluesit të paraqesin ide për të gjitha pjesët e projektit, jo vetëm për modulet e tyre. Çdo zhvillues mund të ndryshojë çdo kod për të zgjeruar funksionalitetin, për të rregulluar gabimet ose për të rindërtuar.

Në pamje të parë duket si kaos. Sidoqoftë, duke marrë parasysh që të paktën çdo kod është krijuar nga disa zhvillues, testet e njësisë ju lejojnë të kontrolloni korrektësinë e ndryshimeve të bëra dhe që në jetën reale ju duhet të kuptoni kodin e dikujt tjetër në një mënyrë ose në një tjetër, bëhet e qartë se pronësia kolektive e kodit thjeshton shumë ndryshimet dhe zvogëlon rrezikun që lidhet me specializimin e lartë të një ose një anëtari tjetër të ekipit.

Sesioni i KDF

Përdorni kartat Klasa, Përgjegjësitë, Bashkëpunimi (CRC) për të hartuar një sistem si një ekip. Përdorimi i kartave e bën më të lehtë të mësosh të mendosh në terma objektesh sesa funksionesh dhe procedurash. Kartat gjithashtu lejojnë më shumë njerëzit të marrin pjesë në procesin e projektimit (idealisht i gjithë ekipi), dhe sa më shumë njerëz të bëjnë dizajnin, aq më shumë ide interesante do të sillen.

Çdo kartë CRC përfaqëson një shembull të një objekti. Klasa e një objekti mund të shkruhet sipër, përgjegjësitë në të majtë, ndërveprimet në të djathtë. Ne themi "mund të shkruhet" sepse kur një sesion CRC është në zhvillim e sipër, pjesëmarrësit zakonisht duhet numër i vogël karta me emrat e klasave dhe ato nuk duhet të plotësohen plotësisht.

Një seancë CRC shkon kështu: çdo pjesëmarrës riprodhon sistemin duke thënë se çfarë mesazhesh po dërgon në çfarë objektesh. Ai kalon nëpër të gjithë procesin mesazh me mesazh. Pikat e dobëta dhe problemet identifikohen menjëherë. Alternativat e projektimit janë gjithashtu qartë të dukshme në simulimin e procesit.

Për të rivendosur rendin, shpesh përdoret kufizimi i numrit të bashkëveprimit të njëkohshëm në dy.

Klienti

Një nga kërkesat e XP është që klienti të jetë gjithmonë në dispozicion. Ai nuk duhet vetëm të ndihmojë ekipin e zhvillimit, por të jetë anëtar i tij. Të gjitha fazat e një projekti XP kërkojnë komunikim me klientin, mundësisht ballë për ballë - në vend. Është më mirë që thjesht të caktoni një ose më shumë klientë në ekipin e zhvillimit. Kujdes, klientit do t'i duhet kohe e gjate, dhe zyra e klientit mund të përpiqet t'ju japë një praktikant si ekspert. Ju duhet një ekspert.

Historitë e përdoruesve shkruar nga klienti me ndihmën e zhvilluesve. Klienti ndihmon për t'u siguruar që shumica e funksioneve të dëshiruara të sistemit mbulohen nga Historia e Përdoruesit.

Gjatë planifikimit të lëshimit, klienti duhet të diskutojë zgjedhjen e Tregimeve të Përdoruesit që do të përfshihen në versionin e planifikuar. Mund të jetë gjithashtu e nevojshme të bihet dakord për vetë periudhën e lëshimit. Klienti merr vendime në lidhje me qëllimet e biznesit.

Zgjidhni zgjidhjen më të thjeshtë

Një dizajn i thjeshtë është gjithmonë më i lehtë për t'u zbatuar sesa një kompleks. Pra, gjithmonë shkoni për zgjidhjen më të thjeshtë që mund të funksionojë. Nëse gjeni diçka të ndërlikuar, zëvendësojeni me diçka të thjeshtë. Gjithmonë rezulton të jetë më e shpejtë dhe më e lirë për të zëvendësuar kodin kompleks me një të thjeshtë përpara se të filloni të kuptoni kodin kompleks.

Refaktori kodi i dikujt tjetër nëse ju duket i ndërlikuar. Nëse diçka duket e ndërlikuar, kjo është një shenjë e sigurt e një problemi në kod.

Mbajini zgjidhjet sa më të thjeshta që të jetë e mundur për aq kohë sa të jetë e mundur. Asnjëherë mos shtoni funksionalitet për të ardhmen - para se të nevojitet. Megjithatë, mbani në mend: mbajtja e një dizajni të thjeshtë është punë e vështirë.

Testet funksionale

Testet e pranimit (më parë të quajtura edhe teste funksionale) janë shkruar bazuar në Historinë e Përdoruesit. Ata e shohin sistemin si një kuti të zezë. Klienti është përgjegjës për verifikimin e korrektësisë së testeve funksionale. Këto teste përdoren për të verifikuar funksionalitetin e një sistemi përpara se ta lëshojnë atë në prodhim. Testet funksionale janë të automatizuara në mënyrë që ato të mund të kryhen shpesh. Rezultati i raportohet ekipit dhe ekipi është përgjegjës për planifikimin e rregullimeve të testeve funksionale.

Integrimi i shpeshtë

Zhvilluesit duhet të integrojnë dhe lëshojnë kodin e tyre çdo disa orë nëse është e mundur. Në çdo rast, nuk duhet t'i mbani kurrë ndryshimet për më shumë se një ditë. Integrimi i shpeshtë shmang tjetërsimin dhe fragmentimin në zhvillim, ku zhvilluesit nuk mund të komunikojnë në kuptimin e ndarjes së ideve ose ripërdorimit të kodit. Të gjithë duhet të përdorin versionin më të fundit.

Çdo palë zhvilluesish duhet të kontribuojë me kodin e tyre sa më shpejt të jetë e mundur. Kjo mund të ndodhë kur të gjitha UnitTests kalojnë 100%. Duke paraqitur ndryshime disa herë në ditë, ju reduktoni problemet e integrimit pothuajse në zero. Integrimi është një aktivitet “paguani tani ose paguani më shumë më vonë”. Prandaj, duke integruar ndryshimet çdo ditë në pjesë të vogla, nuk do t'ju duhet të shpenzoni një javë për të lidhur sistemin në një tërësi pak para dorëzimit të projektit. Punoni gjithmonë në versionin më të fundit të sistemit.

Për menaxherin. Nëse një zhvillues nuk paraqet ndryshime për më shumë se një ditë, ky është një tregues i qartë i një problemi serioz. Ju duhet menjëherë të kuptoni se çfarë po ndodh. E gjithë përvoja e ekipeve XP thotë se arsyeja e vonesës është gjithmonë dizajni i dobët dhe gjithmonë duhet të ribëhet më vonë.

Planifikimi i përsëritjes

Një takim i planifikimit të përsëritjes thirret përpara fillimit të çdo përsëritjeje për të planifikuar detyrat që do të kryhen në atë përsëritje. Për përsëritje, zgjidhen historitë e përdoruesve që janë zgjedhur nga klienti në plani i lëshimit duke filluar nga më e rëndësishmja për klientin dhe më e keqja (që përfshin rrezik) për zhvilluesit. Gjithashtu, testet funksionale të prishura përfshihen në përsëritje.

Historitë e përdoruesve dhe mbetjet e mbetura Testet funksionale ndahen në detyra. Detyrat shkruhen në karta. Këto karta janë plani i detajuar për përsëritjen. Çdo detyrë duhet të jetë nga 1 deri në 3 ditë ideale në kohëzgjatje.

Zhvilluesit zbërthejnë detyrat dhe vlerësojnë kohëzgjatjen e nevojshme për t'i përfunduar ato. Kështu, çdo zhvillues vlerëson se sa kohë do t'i marrë detyra. Është e rëndësishme që vlerësimi përfundimtar i fushës së punës të bëhet nga vetë zhvilluesi.

Shpejtësia e projektit përcakton nëse detyrat tuaja përshtaten në një përsëritje apo jo. Kohëzgjatja totale e detyrave të planifikuara për një përsëritje nuk duhet të kalojë shpejtësinë e arritur në përsëritjen e mëparshme. Nëse keni shtypur shumë, atëherë klienti duhet të vendosë se cilat Tregime Përdoruesi do të shtyjë për përsëritjen tjetër. Nëse keni shkruar shumë pak, atëherë duhet të shtoni Historinë tjetër të Përdoruesit. Në disa raste, mund t'i kërkoni klientit të ndajë një nga Historitë e Përdoruesit në dy, në mënyrë që të përfshijë një pjesë në përsëritjen aktuale.

Shtyrja e një historie përdoruesi për përsëritjen tjetër mund të duket e frikshme, por mos e lini veten të sakrifikoni rifaktorimet dhe testet e njësive për të bërë më shumë. Borxhi në këto kategori do të ngadalësojë shpejt shpejtësinë tuaj. Mos bëni atë që mendoni se do të jetë e nevojshme në përsëritjet e ardhshme - bëni vetëm atë që është e nevojshme për të përfunduar Tregimet aktuale të Përdoruesit.

Monitoroni shpejtësinë e projektit dhe Historitë e përdoruesve në pritje. Është e mundur që plani i lëshimit të duhet të ribëhet çdo tre deri në pesë përsëritje. Kjo është mirë. Në fund të fundit, një plan lëshimi është një vështrim në të ardhmen dhe është e natyrshme të presësh që parashikimet tuaja do të duhet të rregullohen.

Përsëritjet

Zhvillimi përsëritës rrit fleksibilitetin e procesit. Ndani planin tuaj në përsëritje prej 2 deri në 3 javë. Mbani një gjatësi të vazhdueshme përsëritjeje për kohëzgjatjen e projektit. Lëreni përsëritjen të jetë pulsi i projektit tuaj. Ky është ritmi që do ta bëjë matjen e progresit dhe planifikimin të thjeshtë dhe të besueshëm.

Mos i planifikoni detyrat paraprakisht. Mblidhni në vend Planifikimi i përsëritjes në fillim të çdo përsëritje për të planifikuar atë që do të bëhet. Gjithashtu konsiderohet shkelje e rregullave të dilni përpara dhe të bëni diçka që nuk është planifikuar në këtë përsëritje. Kështu, bëhet e mundur mbajtja nën kontroll e kërkesave në ndryshim të Klientit.

Merrni seriozisht afatet e përfundimit të përsëritjeve. Matni progresin ndërsa punoni. Nëse është e qartë se nuk do të jeni në gjendje të përfundoni të gjitha detyrat e planifikuara brenda afatit, atëherë mblidhni përsëri Planifikimin e Përsëritjes dhe rivlerësoni detyrat dhe shtyni disa nga detyrat.

Përqendroni përpjekjet në plotësimin e detyrave më të rëndësishme të zgjedhura nga Klienti, në vend që të zgjidhni disa detyra të papërfunduara nga zhvilluesi.

Ndërroni detyrat

Është e nevojshme të ndryshohen periodikisht detyrat për zhvilluesit për të zvogëluar rrezikun e përqendrimit të njohurive dhe pengesat në kod. Nëse vetëm një person në ekipin tuaj mund të punojë në një zonë të caktuar dhe ai person largohet, ose thjesht keni shumë për të bërë në një segment të caktuar të programit, do të zbuloni se projekti juaj mezi po ecën përpara.

Cross Training është zakonisht një aspekt i rëndësishëm në kompanitë që përpiqen të shmangin përqendrimin e njohurive në një person. Lëvizja e njerëzve përmes kodit në kombinim me programimi në çift bën në heshtje Cross Training për ju. Në vend që një person të dijë gjithçka për një pjesë të caktuar kodi, të gjithë në ekipin tuaj dinë shumë për kodin në secilin modul.

Ekipi bëhet shumë më fleksibël nëse të gjithë dinë mjaftueshëm për secilën pjesë të sistemit për të filluar punën në të. Në vend që të presin që "guru" të përfundojë punën në një pjesë kritike të kodit, disa programues mund të punojnë në të njëkohësisht.

Kur filloni një të re përsëritjetçdo zhvillues duhet të kalojë në detyrë e re. Programimi në çift ndihmon në kapërcimin e problemit të hyrjes (që do të thotë se një zhvillues i ri mund të fillojë të punojë në çift me një zhvillues me përvojë në këtë fushë).

Kjo praktikë inkurajon gjithashtu ide të reja dhe kod të përmirësuar.

Lëreni optimizimin për më vonë

Asnjëherë mos optimizoni asgjë derisa të përfundojë kodimi. Asnjëherë mos u përpiqni të merrni me mend se ku do të jenë pengesat e performancës. Masa!

Bëje të funksionojë, pastaj bëje të funksionojë siç duhet, pastaj bëje të funksionojë shpejt.

Programimi në çift

I gjithë kodi për sistemin e prodhimit (dhe kjo do të thotë me përjashtim të zgjidhjeve provë) është shkruar në çifte. Dy zhvillues janë ulur pranë njëri-tjetrit. Njëri është duke shtypur, tjetri po shikon. Ato ndryshojnë herë pas here. Nuk lejohet të punosh vetëm. Nëse për ndonjë arsye i dyti i çiftit ka humbur diçka (i sëmurë, në pension, etj.), Ai është i detyruar të rishikojë të gjitha ndryshimet e bëra nga i pari.

Tingëllon e pazakontë, por XP pretendon se pas një periudhe të shkurtër përshtatjeje, shumica e njerëzve punojnë mirë në çifte. Ata madje e pëlqejnë sepse puna kryhet dukshëm më shpejt. Zbatohet parimi "Një kokë është e mirë, por dy është më mirë". Çiftet zakonisht gjejnë zgjidhje më të mira. Për më tepër, cilësia e kodit rritet ndjeshëm, numri i gabimeve zvogëlohet dhe shkëmbimi i njohurive midis zhvilluesve është përshpejtuar.

Refactor pa mëshirë!

Ne programuesit priremi t'i përmbahemi një dizajni shumë kohë pasi ai bëhet i ngathët. Ne vazhdojmë të ripërdorim kodin e pambajtur sepse ai ende funksionon disi dhe kemi frikë se mos e thyejmë atë. Por a është vërtet e dobishme? XP mendon se kjo nuk është fitimprurëse. Kur heqim tepricën, përmirësojmë një dizajn të vjetëruar, heqim pjesët e papërdorura - ne bëjmë rifaktorim. Rifaktorimi përfundimisht kursen kohë dhe përmirëson cilësinë e produktit.

Rishikoni çdo kod pa mëshirë për ta mbajtur dizajnin tuaj të thjeshtë ndërsa e zhvilloni atë. Mbajeni kodin tuaj të qartë dhe të kuptueshëm në mënyrë që të jetë i lehtë për t'u kuptuar, modifikuar dhe zgjeruar. Sigurohuni që gjithçka të shkruhet një herë dhe vetëm një herë. Në fund të fundit, kërkon më pak kohë sesa lustrimi i një sistemi të komplikuar.

Plani i lëshimit

Plani i lëshimit zhvillohet në takimin e planifikimit të lëshimit. Planet e lëshimit përshkruajnë një pamje të të gjithë projektit dhe më pas përdoren për të planifikuar përsëritjet.

Është e rëndësishme që njerëzit teknikë të marrin vendime teknike dhe njerëzit e biznesit të marrin vendime biznesi. Planifikimi i lëshimit përcakton një sërë rregullash që i lejojnë të gjithë të marrin vendimet e tyre. Këto rregulla përcaktojnë metodën për zhvillimin e një plani pune që kënaq të gjithë.

Thelbi i takimit të planifikimit të lëshimit për ekipin e zhvillimit është të vlerësojë çdo Histori Përdoruesi në javë ideale. Një javë ideale është sa kohë mendoni se do të duhet për të përfunduar një detyrë nëse asgjë tjetër nuk ju shpërqendron. Asnjë varësi, pa detyra shtesë, por duke përfshirë teste. Më pas klienti vendos se cilat detyra janë më të rëndësishme ose kanë një prioritet më të lartë.

Historitë e përdoruesve shkruhen në karta. Zhvilluesit dhe Klienti së bashku i përziejnë kartat në tryezë derisa të marrin një grup Historish të Përdoruesit që së bashku do të përbëjnë publikimin e parë (ose të ardhshëm). Të gjithë duan të lëshojnë një sistem të dobishëm që mund të testohet sa më shpejt që të jetë e mundur.

Lëshimi mund të planifikohet sipas kohës ose vëllimit. Për të përcaktuar se sa histori përdoruesish mund të zbatohen deri në një datë specifike ose sa kohë reale do të marrë një grup i caktuar detyrash, përdorni shpejtësinë e projektit. Nëse planifikoni me kohë, shumëzoni numrin e përsëritjeve me shpejtësinë e projektit për të zbuluar se sa "Historia e përdoruesve" mund të zbatohet. Kur planifikoni sipas vëllimit, ndani numrin total të javëve ideale të nevojshme për të gjitha Historitë e përdoruesve me shpejtësinë e projektit dhe do të merrni numrin e përsëritjeve që kërkohen për të përfunduar publikimin.

Nëse menaxhmenti nuk është i kënaqur me datën e përfundimit, mund të jetë joshëse për të reduktuar vlerësimet e fushës. Nuk duhet ta bëni kurrë këtë. Vlerësimet e ulëta sigurisht që do të krijojnë shumë probleme më vonë. Në vend të kësaj, negocio me menaxherët, zhvilluesit dhe klientët derisa të dalësh me një plan lëshimi për të cilin të gjithë mund të bien dakord.

Lëshimet e shpeshta

Zhvilluesit duhet të lëshojnë versione të sistemit për përdoruesit (ose testuesit beta) sa më shpesh të jetë e mundur.

Planifikimi i lëshimit përdoret për të gjetur pjesë të vogla të funksionalitetit që kanë kuptim të rëndësishëm biznesi dhe që mund të lëshohen në mjedisin real në fazat e hershme të zhvillimit. Kjo është kritike për marrjen në kohë komente të dobishme të jetë në gjendje të ndikojë në procesin e zhvillimit. Sa më gjatë të vononi lëshimin e një pjese të rëndësishme të sistemit, aq më pak kohë do t'ju duhet për ta rregulluar atë.

Zgjidhje provë

Krijoni zgjidhje prova të konceptit për t'iu përgjigjur pyetjeve komplekse probleme teknike, për të justifikuar zgjidhje të caktuara teknologjike. Ekziston rreziku i përfshirë në çdo vendim teknologjik dhe zgjidhjet e provës janë krijuar për të zbutur këtë rrezik.

Bëni një program që riprodhon problemin nën hetim dhe injoron gjithçka tjetër. Shumica e zgjidhjeve provë nuk janë të destinuara për t'u përdorur, prandaj prisni që ato të hidhen tutje. Qëllimi i krijimit të tyre është të zvogëlojë rrezikun e bërjes së gabuar zgjidhje teknike ose një vlerësim më të saktë të kohës për të zbatuar një histori përdoruesi.

Takimi në këmbë

Çdo mëngjes mbahet një takim për të diskutuar problemet, zgjidhjet e tyre dhe për të forcuar përqendrimin e ekipit. Takimi mbahet në këmbë për të shmangur diskutimet e gjata që nuk janë interesante për të gjithë anëtarët e ekipit.

Në një takim tipik, shumica e pjesëmarrësve nuk kontribuojnë asgjë, thjesht merrni pjesë për të dëgjuar atë që të tjerët kanë për të thënë. Një sasi e madhe e kohës së njerëzve humbet për të marrë një sasi të vogël komunikimi. Prandaj, prania e të gjithëve në takime heq burimet nga projekti dhe krijon kaos në planifikim.

Ky lloj komunikimi kërkon një takim të qëndrueshëm. Është shumë më mirë të kesh një takim të shkurtër e të detyrueshëm sesa shumë takime të gjata në të cilat shumica e zhvilluesve duhet të marrin pjesë gjithsesi.

Nëse keni takime të përditshme në këmbë, atëherë të gjitha takimet e tjera duhet të marrin pjesë vetëm nga ata njerëz që janë të nevojshëm dhe do të sjellin diçka në tryezë. Madje, është e mundur të shmangni edhe disa takime. Me pjesëmarrje të kufizuar, shumica e takimeve mund të mbahen spontanisht përpara një monitori, ku shkëmbimi i ideve është shumë më intensiv.

Takimi i përditshëm i mëngjesit nuk është një tjetër humbje kohe. Kjo do t'ju lejojë të shmangni shumë takime të tjera dhe do t'ju kursejë më shumë kohë sesa shpenzoni për to.

Metafora e sistemit

Gjithmonë zgjidhni Metaforën e Sistemit - një koncept i thjeshtë dhe i qartë në mënyrë që anëtarët e ekipit të thërrasin gjithçka me të njëjtin emër. Për të kuptuar sistemin dhe për të eliminuar kodin e kopjuar, është jashtëzakonisht e rëndësishme se si i emërtoni objektet. Nëse mund të merrni me mend se si quhet një objekt në sistem (nëse e dini se çfarë bën) dhe quhet me të vërtetë kështu, do të kurseni shumë kohë dhe përpjekje. Krijoni një sistem emërtimi për objektet tuaja në mënyrë që çdo anëtar i ekipit ta përdorë atë pa njohuri të veçanta për sistemin.

Testet e njësive

Testet e njësisë luajnë një rol kyç në XP. Ato ju lejojnë të ndryshoni shpejt kodin pa frikë se mos bëni gabime të reja. Një test njësi është shkruar për secilën klasë, testi duhet të kontrollojë të gjitha aspektet e klasës - të testojë gjithçka që mund të mos funksionojë.

Truku këtu është se testi për klasën duhet të shkruhet para vetë klasës. Kjo do të thotë që sapo të lëshoni rezultatin e parë të punës, ai do të mbështetet nga sistemi i testimit. Për të kryer teste është shkruar sistem të veçantë testimi me ndërfaqen tuaj.

Testi Unit për një klasë ruhet në një depo të përbashkët së bashku me kodin e klasës. Asnjë kod nuk mund të lëshohet pa një test të njësisë. Para se të lëshojë kodin, zhvilluesi duhet të sigurohet që të gjitha testet të kalojnë pa gabime. Askush nuk mund të japë kodin nëse të gjithë nuk e kalojnë 100%. Me fjalë të tjera, meqenëse të gjitha testet kaluan para ndryshimeve tuaja, nëse keni gabime, atëherë ky është rezultati i ndryshimeve tuaja. Varet nga ju që ta rregulloni. Ndonjëherë kodi i testit është i pasaktë ose i paplotë. Në këtë rast, ju duhet ta korrigjoni atë.

Një tundim i madh është të kurseni para në testet e njësisë kur koha është e shkurtër. Por duke bërë këtë ju vetëm po mashtroni veten. Sa më e vështirë të jetë për të shkruar një test, aq më shumë kohë do të kursejë më vonë. Kjo është vërtetuar nga praktika.

Testet e njësisë lejojnë pronësinë kolektive të kodit. Ata e bëjnë relativisht të lehtë rishikimin e kodit të keq. Testet e njësisë ju lejojnë gjithashtu të keni një sistem të qëndrueshëm pune në çdo kohë.

Historia e përdoruesit

Historia e përdoruesit (diçka si historia e një përdoruesi) është një përshkrim se si duhet të funksionojë sistemi. Çdo histori përdoruesi është shkruar në një kartë dhe përfaqëson një pjesë të funksionalitetit të sistemit që ka kuptim logjik nga këndvështrimi i klientit. Forma - një ose dy paragrafë teksti që është i kuptueshëm për përdoruesin (jo shumë teknik).

Historia e Përdoruesit është shkruar nga Klienti. Këto janë të ngjashme me rastet e përdorimit të sistemit, por nuk kufizohen në ndërfaqen e përdoruesit. Për çdo histori, testet funksionale shkruhen për të konfirmuar se kjo histori është zbatuar saktë - ato quhen gjithashtu teste pranimi.

Secilit Histori të Përdoruesit i jepet një përparësi nga ana e biznesit (përdoruesi, klienti, departamenti i marketingut) dhe një vlerësim i kohës së ekzekutimit nga zhvilluesit. Çdo histori është e ndarë në detyra dhe i caktohet një kohë kur do të fillojë të zbatohet.

Historitë e përdoruesve përdoren në XP në vend të kërkesave tradicionale. Dallimi kryesor midis një historie përdoruesi dhe kërkesave është niveli i detajeve. Historia e Përdoruesit përmban informacionin minimal të nevojshëm për të bërë një vlerësim të arsyeshëm se sa kohë do të duhet për ta zbatuar atë.

Një histori tipike e përdoruesit kërkon 1-3 javë kohë ideale. Një histori që kërkon më pak se 1 javë është shumë e detajuar. Një histori që kërkon më shumë se 3 javë mund të ndahet në pjesë - histori të veçanta.

Shpejtësia e projektit

Shpejtësia e projektit (ose thjesht shpejtësia) është një masë se sa shpejt përfundon puna në projektin tuaj.

Për të matur shpejtësinë e një projekti, thjesht duhet të numëroni vëllimin e Historive të Përdoruesit, ose sa detyra (në kohë) janë përfunduar për përsëritje. Thjesht llogarisni kohën totale për të vlerësuar sasinë e punës (koha ideale).

Gjatë planifikimit të lëshimit, shpejtësia e projektit përdoret për të vlerësuar se sa histori përdoruesish mund të prodhohen.

Gjatë planifikimit të përsëritjes, shpejtësia e projektit në përsëritjen e mëparshme përdoret për të përcaktuar se sa histori përdoruesish duhet të planifikohen në përsëritjen aktuale.

Ky mekanizëm i thjeshtë i lejon zhvilluesit të rikuperohen nga një përsëritje e vështirë. Nëse keni ende kohë të lirë pas rikuperimit, shkoni te klienti dhe kërkoni një histori tjetër të përdoruesit. Si rezultat, shpejtësia do të rritet përsëri.

Nuk ka nevojë të përdoret ky parametër si parametër absolut. Nuk është i përshtatshëm për të krahasuar produktivitetin e dy projekteve, pasi secili ekip ka karakteristikat e veta. Ky parametër është i rëndësishëm vetëm për skuadrën që ta mbajë atë në një nivel të barabartë.

Ju duhet të prisni ndryshime të lehta në shpejtësinë e projektit ndërsa punoni. Por nëse shpejtësia ndryshon ndjeshëm, është e nevojshme të riplanifikoni lëshimin. Sapo sistemi i ri shkon te përdoruesit, prisni ndryshime në shpejtësinë e projektit pasi keni detyra mbështetëse.

Kur zbulohet një gabim

Nëse gjendet një gabim, krijohet një test për të parandaluar që ai të përsëritet. Një gabim që ndodh në një sistem prodhimi (të instaluar tashmë) kërkon shkrimin e një testi funksional. Krijimi i një testi funksional menjëherë përpara se të diagnostikohet një gabim i lejon klientët të përshkruajnë qartë problemin dhe t'ia komunikojnë problemin zhvilluesve.

Një test funksional i dështuar kërkon krijimin Testi i njësisë. Kjo ndihmon në fokusimin e përpjekjeve për korrigjimin e gabimeve dhe tregon qartë se kur është rregulluar një gabim.

Nuk do t'ju duhet

Përmbahuni nga mbushja e sistemit me gjëra që do t'ju nevojiten në të ardhmen. Vetëm 10% e asaj që prisnit në të vërtetë do të nevojiten në formën e saj origjinale, që do të thotë se 90% e kohës suaj do të humbet kot.

Ekziston gjithmonë një tundim për të shtuar funksionalitetin tani dhe jo më vonë, sepse ne shohim se si ta shtojmë atë tani dhe mendojmë se sistemi do të jetë shumë më i mirë. Por ne gjithmonë duhet t'i kujtojmë vetes se nuk do të na duhet kurrë. Funksionaliteti shtesë vetëm ngadalëson përparimin dhe konsumon burimet. Harroni kërkesat e ardhshme dhe fleksibilitetin shtesë. Përqendrohuni në atë që duhet bërë tani.

Një justifikim i plotë ekonomik për të gjitha veprimet - bëhet vetëm ajo që i nevojitet klientit dhe nuk çon në humbjen e projektit.

Formimi i arkitekturës bazë sa më shpejt të jetë e mundur.

Përdorimi i arkitekturës së komponentëve.

Prototipizimi, zhvillimi dhe testimi në rritje.

Vlerësime të rregullta të gjendjes aktuale.

Menaxhimi i ndryshimit, zhvillimi i vazhdueshëm i ndryshimeve nga jashtë projektit.

Përqendrohuni në krijimin e një produkti që funksionon në një mjedis real.

Përqendrohuni te cilësia.

Përshtatja e procesit me nevojat e projektit.

Programim ekstrem

Programim ekstrem (XP) u shfaq si një metodë evolucionare e zhvillimit të softuerit"poshtë lart". Kjo qasje është një shembull i të ashtuquajturës metodë Zhvillimi "live" (Metoda e zhvillimit të shkathët) . Grupi i metodave "live" përfshin, përveç programimit ekstrem, metodat SCRUM, DSDM (Dynamic Systems Development Method, metoda e zhvillimit të sistemeve dinamike), E drejtuar nga tiparet Zhvillimi (zhvillimi i drejtuar nga funksionet e sistemit), etj.

Parimet themelore të zhvillimit të softuerit të drejtpërdrejtë janë të përfshira në manifestin e zhvillimit të drejtpërdrejtë, i cili u shfaq në 2000.

Njerëzit e përfshirë në një projekt dhe komunikimi i tyre janë më të rëndësishëm se proceset dhe mjetet.

Një program pune është më i rëndësishëm se dokumentacioni gjithëpërfshirës.

Bashkëpunimi me klientin është më i rëndësishëm sesa diskutimi i detajeve të kontratës.

Të punosh përmes ndryshimeve është më e rëndësishme sesa t'u përmbahesh planeve.

Metodat "Living" u shfaqën si një protestë kundër burokratizimit të tepruar të zhvillimit të softuerit, bollëkut të dokumenteve anësore që nuk janë të nevojshme për të marrë rezultatin përfundimtar, të cilat duhet të hartohen gjatë kryerjes së një projekti në përputhje me shumicën e proceseve "të rënda". , punë shtesë për të mbështetur procesin fiks të organizatës, siç kërkohet brenda, për shembull, CMM. Shumica e këtyre punëve dhe dokumenteve nuk janë të lidhura drejtpërdrejt me zhvillimin e softuerit dhe sigurimin e cilësisë, por synojnë të jenë në përputhje me klauzolat formale të kontratave të zhvillimit, të marrin dhe konfirmojnë certifikatat për përputhjen me standarde të ndryshme.

Metodat "Live" lejojnë zhvilluesit të përqendrojnë shumicën e përpjekjeve të tyre në detyrat e zhvillimit dhe përmbushjen e nevojave reale të përdoruesve. Mungesa e grumbujve të dokumenteve dhe nevoja për t'i mbajtur ato në një gjendje koherente ju lejon të përgjigjeni më shpejt dhe me efikasitet ndaj ndryshimeve në kërkesat dhe në mjedisin në të cilin do të duhet të funksionojë programi i ardhshëm.

Sidoqoftë, XP ka diagramin e vet të procesit të zhvillimit (megjithëse, në përgjithësi, kuptimi i përdorur gjerësisht i "procesit të zhvillimit" si një skemë mjaft e ngurtë veprimesh bie në kundërshtim me vetë idenë e zhvillimit "të gjallë"), të paraqitur në Fig. 15.

Sipas autorëve të XP, kjo teknikë nuk ndjek aq shumë disa modele të përgjithshme veprimi, sa duke përdorur një kombinim të teknikave të mëposhtme. Sidoqoftë, çdo teknikë është e rëndësishme dhe pa përdorimin e saj, zhvillimi konsiderohet të mos jetë XP, sipas Kent Beck, një nga autorët e kësaj qasjeje, së bashku me Ward Cunningham dhe Ron Jeffries.

Lojë e planifikimit të drejtpërdrejtë

Detyra e tij është të përcaktojë sa më shpejt të jetë e mundur sasinë e punës që duhet bërë përpara versionit të ardhshëm të softuerit. Vendimi merret, para së gjithash, në bazë të prioriteteve të klientit (d.m.th. nevojat e tij, çfarë i nevojitet nga sistemi për më të suksesshëm

drejtimin e biznesit tuaj) dhe, së dyti, në bazë të vlerësimeve teknike (d.m.th. vlerësimet e kompleksitetit të zhvillimit, përputhshmëria me elementë të tjerë të sistemit, etj.). Planet ndryshojnë sapo fillojnë të ndryshojnë nga realiteti ose dëshirat e klientit.

				Test
		përdorni		skenarë
			Histori e re
	Kërkesat		përdorni
			Shpejtësia e projektit
	Metaforë		Plani i versionit
		Planifikimi		Përsëritje	Pranimi	I vogël
arkitekturës				E fundit
						Ne rregull
						përdoruesit
E pabesueshme			Të sigurt	Përsëritje e re

"Hedhja" e zgjidhjeve

Figura 15. Diagrami i rrjedhës së punës në XP.

Ndryshime të shpeshta të versionit (lëshime të vogla)

Versioni i parë i punës duhet të shfaqet sa më shpejt që të jetë e mundur dhe duhet të fillojë të përdoret menjëherë. Versionet e mëvonshme përgatiten në intervale mjaft të shkurtra (nga disa orë për ndryshime të vogla në një program të vogël, deri në një muaj ose dy për një ripërpunim të madh të një sistemi të madh).

Metafora e sistemit

Metafora, në një formë mjaft të thjeshtë dhe të kuptueshme për ekipin, duhet të përshkruajë mekanizmin bazë të sistemit. Ky koncept të kujton arkitekturën, por duhet të përshkruajë thelbin kryesor të vendimeve teknike të marra shumë më thjesht, në vetëm një ose dy fraza.

E thjeshtë zgjidhjet e projektimit(dizajn i thjeshtë)

Në çdo moment, sistemi duhet të projektohet sa më thjeshtë që të jetë e mundur. Nuk ka nevojë të shtoni veçori paraprakisht - vetëm pas një kërkese të qartë për të. I gjithë kompleksiteti i panevojshëm hiqet sapo të zbulohet.

Zhvillimi i drejtuar nga testi(zhvillimi i drejtuar nga testi)

Zhvilluesit fillimisht shkruajnë teste, pastaj përpiqen të zbatojnë modulet e tyre në mënyrë që testet të funksionojnë. Konsumatorët shkruajnë teste paraprakisht që demonstrojnë aftësitë kryesore të sistemit në mënyrë që ata të mund të shohin se sistemi në të vërtetë funksionon.

Rifaktorim i vazhdueshëm

Programuesit po ripunojnë vazhdimisht sistemin për të eliminuar kompleksitetin e panevojshëm, për të rritur kuptueshmërinë e kodit, për të rritur fleksibilitetin e tij, por pa ndryshuar sjelljen e tij, gjë që verifikohet duke ekzekutuar pas çdo ripërpunimi të testeve. Në të njëjtën kohë, përparësi u jepet zgjidhjeve më elegante dhe fleksibile, krahasuar me ato që thjesht japin rezultatin e dëshiruar. Komponentët e ridizajnuar pa sukses duhet të identifikohen gjatë ekzekutimit të provës dhe të kthehen në gjendjen e fundit të paprekur (së bashku me komponentët që varen prej tyre).

Programimi në çift

Kodimi kryhet nga dy programues në një kompjuter. Çiftimi është arbitrar dhe ndryshon nga detyra në detyrë. Ai në duart e të cilit tastiera po përpiqet të zgjidhë problemin aktual në mënyrën më të mirë. Programuesi i dytë analizon punën

së pari dhe jep këshilla, merr parasysh pasojat e vendimeve të caktuara, teste të reja, zgjidhje më pak të drejtpërdrejta, por më fleksibël.

Pronësia kolektive e kodit

NË Çdo anëtar i ekipit mund të ndryshojë çdo pjesë të kodit në çdo kohë. Askush nuk duhet të ketë fushën e tij të përgjegjësisë; i gjithë ekipi në tërësi është përgjegjës për të gjithë kodin.

Integrim i vazhdueshëm

Sistemi montohet dhe i nënshtrohet testimit të integrimit sa më shpesh që të jetë e mundur, disa herë në ditë, sa herë që disa programues mbarojnë zbatimin e funksionit tjetër.

40 orë punë në javë

Puna jashtë orarit shihet si një shenjë e problemeve më të mëdha në projekt. Puna jashtë orarit për 2 javë rresht nuk lejohet - kjo i lodh programuesit dhe e bën punën e tyre dukshëm më pak produktive.

Përfshirja e klientit në ekip(klient në vend)

NË Ekipi i zhvillimit përfshin gjithmonë një përfaqësues të klientit i cili është i disponueshëm gjatë gjithë ditës së punës dhe është në gjendje t'u përgjigjet të gjitha pyetjeve në lidhje me sistemin. Përgjegjësia e tij është t'u përgjigjet menjëherë pyetjeve të çdo lloji në lidhje me funksionet e sistemit, ndërfaqen e tij, performancën e kërkuar, funksionimin korrekt të sistemit në situata të vështira, nevojën për të ruajtur komunikimin me aplikacione të tjera, etj.

Përdorimi i kodit si mjet komunikimi

Kodi shihet si mjeti më i rëndësishëm i komunikimit brenda një ekipi. Qartësia e kodit është një nga prioritetet kryesore. Ndjekja e standardeve të kodimit që ofrojnë këtë qartësi është e domosdoshme. Standarde të tilla, përveç qartësisë së kodit, duhet të sigurojnë gjuhë minimale (pa dyfishim të kodit dhe informacionit) dhe duhet të pranohen nga të gjithë anëtarët e ekipit.

Hapur hapësirë ​​pune(hapësira e hapur e punës)

Ekipi është i vendosur në një dhomë mjaft të gjerë për të lehtësuar komunikimin dhe për të mundësuar diskutime në grup kur planifikoni dhe merrni vendime të rëndësishme teknike.

Ndryshimi i rregullave sipas nevojës (vetëm rregulla)

Çdo anëtar i ekipit duhet të pranojë rregullat e listuara, por nëse lind nevoja, ekipi mund t'i ndryshojë ato nëse të gjithë anëtarët e tij bien dakord për këtë ndryshim.

Siç mund të shihet nga teknikat e përdorura, XP është projektuar për përdorim brenda ekipeve të vogla (jo më shumë se 10 programues), gjë që theksohet nga autorët e kësaj teknike. Një madhësi më e madhe e ekipit shkatërron lehtësinë e komunikimit të nevojshëm për sukses dhe e bën të pamundur zbatimin e shumë prej teknikave të listuara.

Përparësitë e XP, nëse mund të zbatohet, janë fleksibiliteti më i madh, aftësia për të bërë ndryshime të shpejta dhe të sakta në softuer në përgjigje të ndryshimit të kërkesave dhe dëshirave individuale të klientit, cilësia e lartë e kodit që rezulton dhe mungesa e nevojës për të. bindin klientët se rezultati i plotëson pritshmëritë e tyre.

Disavantazhet e kësaj qasjeje janë praktikueshmëria e projekteve mjaft të mëdha dhe komplekse në këtë stil, pamundësia për të planifikuar kohën dhe kompleksitetin e projektit për një afat mjaftueshëm afatgjatë dhe për të parashikuar qartë rezultatet e një projekti afatgjatë në aspektin e raportit. të cilësisë së rezultatit dhe kostove të kohës dhe burimeve. Mund të theksohet gjithashtu se XP nuk është i përshtatshëm për ato raste në të cilat zgjidhjet e mundshme nuk gjenden menjëherë në bazë të përvojës së fituar më parë, por kërkojnë kërkime paraprake.

XP si një grup teknikash të përshkruara u përdor për herë të parë gjatë punës në projektin C3 (Chrysler Comprehensive Compensation System, zhvillimi i një sistemi të kontabilitetit të pagesave

punonjës të Daimler Chrysler). Nga 20 pjesëmarrësit në këtë projekt, 5 (përfshirë 3 autorët kryesorë të XP të lartpërmendur) botuan 3 libra dhe një numër të madh artikujsh kushtuar XP gjatë vetë projektit dhe më pas. Ky projekt përmendet vazhdimisht në burime të ndryshme si shembull i përdorimit të kësaj teknike. Të dhënat e mëposhtme janë përpiluar nga artikujt e përmendur, minus dëshmitë anekdotike, dhe ilustron problemet me disa teknika XP kur aplikohen në projekte mjaft komplekse.

Projekti filloi në janar 1995. Që nga marsi 1996, pas përfshirjes së Kent Beck, ai është drejtuar duke përdorur XP. Në këtë kohë, ajo tashmë kishte shkuar përtej buxhetit dhe planeve për zbatimin me faza të funksioneve. Ekipi i zhvillimit u ndërpre dhe për rreth gjashtë muaj më pas projekti u zhvillua me mjaft sukses. Në gusht 1998, u shfaq një prototip që mund t'u shërbente rreth 10,000 punonjësve. Projekti fillimisht pritej të përfundonte në mesin e vitit 1999 dhe softueri që do të rezultonte do të përdorej për të menaxhuar përfitimet për 87,000 punonjësit e kompanisë. Ai u ndërpre në shkurt 2000 pas 4 vitesh funksionim të XP për shkak të dështimit të plotë për të përmbushur kornizat kohore dhe buxhetin. Softueri i krijuar nuk është përdorur kurrë për të punuar me të dhëna për më shumë se 10,000 punonjës, megjithëse është treguar se mund të trajtojë të dhëna për 30,000 punonjës të kompanisë. Personi që luajti rolin e klientit të përfshirë në ekipin e projektit u largua pas disa muajsh punë të tillë, në pamundësi për të përballuar ngarkesën e punës dhe nuk mori kurrë një zëvendësim adekuat deri në fund të projektit.

Literatura për Leksionin 3

W. Royce. Menaxhimi i projekteve softuerike. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Procesi i unifikuar i zhvillimit të softuerit. Shën Petersburg: Peter, 2002.

Kroll, Fryma e RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

K. Beck. Programim ekstrem. Shën Petersburg: Peter, 2002.

http://www.agilemanifesto.org/

K. Beck, etj. al. Chrysler shkon te "Extremes". Informatikë e shpërndarë, 10/1998.

A. Cockburn. Zgjedhja e Metodologjisë së Projektit. IEEE Software, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Forcimi i rastit për programimin në çift. IEEE Software 4/2000.

G. Keefer. Programimi ekstrem konsiderohet i dëmshëm për zhvillimin e besueshëm të softuerit. Raporti Teknik i AVOCA, 2002.

E disponueshme si http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.