Pošaljite svoj dobar rad u bazu znanja je jednostavno. Koristite obrazac ispod

Dobar posao na stranicu">

Studenti, postdiplomci, mladi naučnici koji koriste bazu znanja u svom studiranju i radu biće vam veoma zahvalni.

Objavljeno na http://www.allbest.ru/

Sadržaj

• Uvod
• 1. Šta je XP?
• 3.1 Osnovne tehnikeXP
• 4. Prednosti i nedostaci
• 5. Istorija upotrebe
• Zaključak

Uvod

Ekstremno programiranje, često skraćeno XP, je disciplina razvoja softvera i softverskog poslovanja koja fokusira napore obje strane (programera i poslovnih ljudi) na zajedničke, ostvarive ciljeve. Timovi koji koriste XP proizvode kvalitetan softver vrlo brzim tempom. Tehnike koje čine disciplinu HR odabrane su jer se temelje na ljudskoj kreativnosti i prihvaćanju da su ljudi nestalna i pogrešiva ​​stvorenja.

XP se često predstavlja kao skup tehnika, ali sam XP nije ciljna linija. Nema potrebe sve bolje i bolje vježbati i razvijati HR kako biste na kraju ovog procesa dobili dugo očekivanu zlatnu zvijezdu. Naprotiv, XP je startna linija. XP postavlja pitanje: "Koliko minimalni mogu biti naši napori da bismo mogli nastaviti proizvoditi kvalitetan softver?"

Extreme Programming je pojednostavljena metodologija proizvodnje za male i srednje timove stručnjaka koji razvijaju softverski proizvod u uslovima nejasnih ili brzo promenljivih zahteva.

1. Šta je XP?

Extremamposteljinaprogrammroving(engleski) Ekstremno Programiranje, XP) je jedna od fleksibilnih metodologija razvoja softvera. Autori metodologije su Kent Beck, Ward Cunningham, Martin Fowler i drugi.

XP je pojednostavljen, efikasan, fleksibilan, predvidljiv, naučno zasnovan i veoma ugodan, niskorizičan način za razvoj softvera. HR se razlikuje od ostalih metoda na sljedeće načine:

Koristeći izuzetno kratke razvojne cikluse, XP nudi brze, stvarne i stalne povratne informacije.

XP koristi inkrementalno planiranje, što rezultira u ukupnom planu projekta koji se pojavljuje prilično brzo, ali se podrazumijeva da se ovaj plan razvija tokom trajanja projekta.

XP koristi fleksibilan raspored za implementaciju ove ili one funkcionalnosti, što poboljšava odgovor na promjenjivu prirodu poslovanja i promjenjive zahtjeve kupaca u vezi s tim.

XP je zasnovan na automatizovanim testovima koje su razvili i programeri i kupci. Zahvaljujući ovim testovima moguće je pratiti razvojni proces, osigurati ispravnu evoluciju sistema i pravovremeno otkriti postojeće nedostatke u sistemu.

XP je baziran na usmenoj komunikaciji, testovima i izvornom kodu. Ova tri alata se koriste za razmjenu informacija o strukturi i ponašanju sistema.

XP je zasnovan na razvoju procesa dizajna koji traje sve dok sam sistem postoji.

XP se zasniva na bliskoj interakciji između programera sa najčešćim veštinama i sposobnostima.

XP je zasnovan na tehnikama koje zadovoljavaju i kratkoročne instinkte pojedinačnih programera i dugoročne interese čitavog projekta.

XP je disciplina razvoja softvera. Ovo je disciplina jer unutar XP-a postoje određene stvari koje morate učiniti ako namjeravate koristiti XP. Ne biste trebali birati da li ćete pisati testove ili ne, jer ako to ne uradite, programiranje koje radite nije ekstremno.

XP metodologija je namijenjena za rad na projektima na kojima može raditi od dva do deset programera, koji nisu stisnuti u kruti okvir postojećeg računarskog okruženja i u kojem svi neophodan rad testiranje u vezi može biti završeno u roku od jednog dana.

2. Gdje počinje ekstremno programiranje?

Gdje počinje ekstremno programiranje? Uzimajući u obzir da tipična pozicija domaćeg programera softvera obavezuje da što više smanji troškove razvoja. A za to je potrebno intenzivno surađivati ​​s kupcem, razumjeti njegove interese i na kraju raditi upravo ono što on želi: ni više ni manje.

Ekstremno programiranje se ne zasniva na specifičnim tehnikama, kao što se obično veruje, već samo na četiri osnovna principa: komunikacija, jednostavnost, Povratne informacije i hrabrost. Ovdje morate početi.

Extreme Programming nudi gotovo rješenje: neka sve bude što jednostavnije, zadržite kupca za sebe ili ostanite uz kupca, pustite ga da aktivno prati proces razvoja, pozdravite promjenu - i uspjeh je gotovo zagarantovan.

U XP timovima se komunikacija uvijek podstiče – najbrži način za razmjenu informacija i iskustva. Ovo je veoma važno kada je potrebno maksimalna brzina razvoj. Ali komunikacija, kao i svaki drugi koristan poduhvat, zahtijeva stalnu podršku. Zato neko iz tima mora preuzeti odgovornost za praćenje komunikacije, postajući takozvani diplomata. Komunikacija i potreba da ostalim članovima tima objasnite svoje postupke tjera vas da sve radite što jednostavnije. Ako ne uspije prvi put, oni rade na pojednostavljenju iznova i iznova dok se to ne postigne. glavni cilj- maksimalna jasnoća koda za druge programere.

Bez obzira šta radimo – uvlačimo konac u iglu ili idemo na zabavu – uvijek težimo nekom cilju. Ako primijetimo da odstupamo od toga, prema tome prilagođavamo svoje postupke. Sada zamislite koliko je teže uvući konac u iglu zatvorenih očiju ili se lepo obucite bez ogledala! Ali kada razvijamo programe, često se dešava ovo: uradimo nešto, čiji rezultat ne vidimo. Stoga je u ekstremnom programiranju pravilo da što prije vidite rezultat svojih akcija. Ili, tehnički govoreći, pružiti povratnu informaciju što je brže moguće.

Ekstremno programiranje nas pita: zašto ne razviti hrabrost? Na kraju krajeva, ona je veoma važna u svom poslu. Bez hrabrosti, da li je moguće preuzeti odgovornost za izvršenje zadatka, i to u određenom vremenskom okviru? Bez hrabrosti, da li je moguće shvatiti da ste došli u ćorsokak, napraviti korak unazad i potražiti rješenje? I, konačno, šta će programeru omogućiti da prizna svoju grešku u procjeni zadatka i na vrijeme upozori druge na to, umjesto da ih stavi pred svršen čin tek kada isteknu svi rokovi? Prednosti hrabrosti su očigledne, a svaki uspjeh, čak i u najmanjem zadatku, može razviti tu hrabrost.

3. XP Techniques

Ekstremno programiranje (XP) se pojavilo kao evoluciona metoda razvoja softvera odozdo prema gore. Ovaj pristup je primjer takozvane metode agilnog razvoja. Grupa "živih" metoda uključuje, pored ekstremnog programiranja, metode SCRUM, DSDM (metoda razvoja dinamičkih sistema, metoda za razvoj dinamičkih sistema), Feature-Driven Development (razvoj vođen sistemskim funkcijama) itd.

Osnovni principi razvoja softvera uživo sadržani su u manifestu razvoja uživo, koji se pojavio 2000. godine.

· Ljudi uključeni u projekat i njihova komunikacija važniji su od procesa i alata.

· Radni program je važniji od sveobuhvatne dokumentacije.

· Saradnja sa kupcem je važnija od razgovora o detaljima ugovora.

· Rad na promjenama je važniji od pridržavanja planova.

“Žive” metode su se pojavile kao protest protiv pretjerane birokratizacije razvoja softvera, obilja sporednih dokumenata koji nisu neophodni za postizanje konačnog rezultata, a koji se moraju izraditi prilikom izvođenja projekta u skladu s većinom “teških” procesa , dodatni rad za podršku fiksnog procesa organizacije, kao što je ovaj potreban unutar, na primjer, CMM. Većina ovakvih poslova i dokumenata nije direktno vezana za razvoj softvera i osiguranje kvaliteta, već je namijenjena usaglašavanju sa formalnim klauzulama razvojnih ugovora, pribavljanju i potvrđivanju certifikata o usklađenosti sa različitim standardima.

Metode „uživo“ omogućavaju programerima da usredsrede većinu svojih napora na razvojne zadatke i zadovoljavanje stvarnih potreba korisnika. Odsustvo gomile dokumenata i potreba da ih održavate u koherentnom stanju omogućavaju vam da brže i efikasnije odgovorite na promjene u zahtjevima i okruženju u kojem će budući program morati da radi.

Međutim, XP ima svoj vlastiti dijagram razvojnog procesa (iako je, općenito govoreći, široko korišteno razumijevanje „procesa razvoja“ kao prilično krute šeme akcija u suprotnosti sa samom idejom „živog“ razvoja), prikazanom na slici 1. .

Prema autorima XP-a, ova tehnika ne prati toliko neke opšte šeme akcije, koliko koristi kombinaciju sljedećih tehnika. Međutim, svaka tehnika je važna, a bez njene upotrebe razvoj se smatra da nije XP, smatra Kent Beck, jedan od autora ovog pristupa zajedno sa Wardom Cunninghamom i Ronom Jeffriesom.

· Uživoplaniranje (planiranjeigra)

Njegov zadatak je da što brže odredi količinu posla koji treba obaviti prije sljedeće verzije softvera. Odluka se donosi, pre svega, na osnovu prioriteta kupca (tj. njegovih potreba, šta mu je potrebno od sistema da bi uspešnije poslovao) i, drugo, na osnovu tehničke procjene(tj. procjene složenosti razvoja, kompatibilnosti sa drugim elementima sistema, itd.). Planovi se mijenjaju čim počnu odstupati od stvarnosti ili želja kupca.

Rice.1 XP Dijagram toka rada

· ČestopromijenitiVverzije (malaizdanja)

Prva radna verzija treba da se pojavi što je pre moguće i da se odmah počne koristiti. Sljedeće verzije pripremaju se u prilično kratkim intervalima (od nekoliko sati za manje izmjene u malom programu, do mjesec ili dva za veću preradu velikog sistema). Verzije (izdanja) proizvoda treba puštati u upotrebu što je češće moguće. Svaka verzija treba da traje što je moguće manje vremena da se završi. Štaviše, svaka verzija mora imati dovoljno smisla u smislu korisnosti za poslovanje.

· Metafora (metafora) sistemima

Metafora, u prilično jednostavnoj i razumljivoj formi za tim, treba da opiše osnovni mehanizam sistema. Ovaj koncept podsjeća na arhitekturu, ali bi trebao opisati glavnu suštinu tehničkih odluka donesenih mnogo jednostavnije, u samo jednoj ili dvije fraze.

Arhitektura je neka ideja o komponentama sistema i kako su one međusobno povezane. Programeri koriste arhitekturu da razumiju gdje se neka nova funkcionalnost dodaje sistemu i sa čime će neka nova komponenta komunicirati.

Metafora sistema je analog onoga što se u većini tehnika naziva arhitektura. Metafora sistema daje timu uvid u to kako sistem trenutno funkcioniše, gde se dodaju nove komponente i kakav oblik treba da poprime.

· Jednostavnodizajnrješenja (jednostavnodizajn)

U svakom trenutku, sistem treba da bude dizajniran što jednostavnije. Nema potrebe za dodavanjem funkcija unaprijed - samo nakon eksplicitnog zahtjeva za to. Sva nepotrebna složenost se uklanja čim se otkrije.

XP polazi od činjenice da se tokom procesa rada uslovi problema mogu više puta mijenjati, što znači da proizvod koji se razvija ne treba unaprijed dizajnirati u cijelosti. Ako pokušate da dizajnirate sistem do detalja od početka do kraja kada prvi put počnete, gubite vrijeme. XP pretpostavlja da je dizajn takav važan proces da se mora izvoditi kontinuirano tokom cijelog trajanja projekta. Dizajn se mora izvoditi u malim koracima, uzimajući u obzir zahtjeve koji se stalno mijenjaju. U svakom trenutku pokušavamo koristiti najjednostavniji dizajn koji je pogodan za rješavanje trenutnog problema. Istovremeno ga mijenjamo kako se mijenjaju uslovi problema.

· Razvojonosnovutestiranje (test- drivenrazvoj)

Programeri prvo pišu testove, a zatim pokušavaju implementirati svoje module kako bi testovi funkcionirali. Kupci unapred pišu testove koji demonstriraju glavne mogućnosti sistema kako bi mogli da vide da sistem zaista radi.

U XP-u Posebna pažnja Postoje dvije vrste testiranja:

ʹ jedinično testiranje;

b testiranje prihvatljivosti.

ekstremni softver za programiranje

Programer ne može biti siguran u ispravnost koda koji je napisao sve dok apsolutno svi testovi modula sistema koji razvija ne prorade. Jedinični testovi omogućavaju programerima da potvrde da njihov kod radi ispravno. Oni također pomažu drugim programerima da shvate zašto je potreban određeni dio koda i kako funkcionira. Jedinični testovi takođe omogućavaju programeru da refaktorira bez ikakvih briga.

Testovi prihvatanja osiguravaju da sistem zaista ima navedene mogućnosti. Osim toga, testovi prihvatljivosti vam omogućavaju da provjerite ispravno funkcioniranje proizvoda koji se razvija.

Za XP je veći prioritet pristup koji se zove TDD (Test Driven Development), prvo se napiše test koji ne prolazi, zatim se napiše kod da test prođe, a tek onda se kod refaktoriše.

· Konstantnoreciklaža (refaktoring)

Nije tajna da dodavanje svake nove funkcionalnosti i rast koda komplicira razvoj, identifikaciju grešaka i naknadne promjene. Jedan od trikova ekstremnog programiranja je kompenzacija dodavanja funkcionalnosti poboljšanjima koda. Ovo je obrada koda ili refaktoring.

Programeri stalno prerađuju sistem kako bi eliminisali nepotrebnu složenost, povećali razumljivost koda, povećali njegovu fleksibilnost, ali bez promjene njegovog ponašanja, što se potvrđuje pokretanjem nakon svake prerade testova. Istovremeno, prednost se daje elegantnijim i fleksibilnijim rješenjima u odnosu na ona koja jednostavno pružaju željeni rezultat. Neuspješno redizajnirane komponente treba identificirati tokom izvođenja testa i vratiti ih u posljednje netaknuto stanje (zajedno sa komponentama koje zavise od njih).

Refaktoring je tehnika za poboljšanje koda bez promjene njegove funkcionalnosti. XP znači da kada se kod jednom napiše, gotovo sigurno će biti prepisan nekoliko puta tokom projekta. XP programeri nemilosrdno prerađuju prethodno napisani kod kako bi ga poboljšali. Ovaj proces se zove refaktoring. Nedostatak pokrivenosti testom izaziva odbijanje refaktora zbog straha od razbijanja sistema, što dovodi do postepene degradacije koda.

· Programiranjeu parovima (parprogramiranje)

Iskusni programeri su primijetili da povremeno pregledavanje koda drugih ljudi pozitivno utiče na njegovu kvalitetu. Majstori ekstremnog programiranja razvili su ovaj pristup stalnim pregledom koda tokom razvoja kroz tehniku ​​zvanu programiranje u paru.

Kodiranje obavljaju dva programera na jednom računaru. Uparivanje je proizvoljno i varira od zadatka do zadatka. Onaj u čijim rukama tastatura pokušava na najbolji mogući način riješiti trenutni problem. Drugi programer analizira rad prvog i daje savjete, razmatra posljedice određenih odluka, novih testova, manje direktnih ali fleksibilnijih rješenja. Ako je potrebno, tastatura se slobodno prenosi s jedne na drugu. Dok radite na projektu, parovi nisu fiksni: preporučuje se da ih pomiješate tako da svaki programer u timu dobro razumije cijeli sistem. Na ovaj način, programiranje u paru poboljšava saradnju unutar tima.

· Kolektivnoposjedovanjekod (kolektivnovlasništvo)

Kolektivno posjedovanje znači da je svaki član tima odgovoran za sav izvorni kod. Dakle, svako ima pravo na izmjene bilo kojeg dijela programa. Programiranje u paru podržava ovu praksu: radeći u različitim parovima, svi programeri se upoznaju sa svim dijelovima koda sistema. Važna prednost zajedničkog vlasništva koda je da ubrzava proces razvoja, jer ako dođe do greške, svaki programer je može popraviti.

Dajući svakom programeru pravo da promijeni kod, rizikujemo od grešaka koje unose programeri koji misle da znaju šta rade, ali ne uzimaju u obzir određene zavisnosti. Dobro definisani UNIT testovi rešavaju ovaj problem: ako neispitane zavisnosti generišu greške, sledeće pokretanje UNIT testova neće uspeti.

· Konstantnointegracija (kontinuiranointegracija)

Sistem se sklapa i prolazi kroz integracijsko testiranje što je češće moguće, nekoliko puta dnevno, svaki put kada nekoliko programera završi implementaciju sljedeće funkcije.

Ako dovoljno često integrišete sistem koji razvijate, možete izbjeći većinu problema povezanih s njim. U tradicionalnim metodama, integracija se obično izvodi na samom kraju rada na proizvodu, kada se smatra da su sve komponente sistema koji se razvija potpuno spremne. U XP-u, integracija koda cijelog sistema se izvodi nekoliko puta dnevno, nakon što su programeri sigurni da se svi testovi jedinica pokreću ispravno.

Uprkos svojoj jednostavnosti, ova tehnika ima svoja pravila upotrebe, kao što su uspeh postojećih jediničnih testova za integrisanu funkcionalnost, prisustvo funkcionalnih ili testova prihvatanja i, naravno, mogućnost vraćanja na prethodno stanje. Tipično, integraciju i rješavanje povezanih poteškoća na zasebnom računaru izvodi nekoliko programera. To vam omogućava da minimizirate rizik od neželjenih posljedica integracije.

· 40 satiradisedmica

Prekovremeni rad se smatra znakom veliki problemi u projektu. Prekovremeni rad 2 sedmice zaredom nije dozvoljen - to iscrpljuje programere i čini njihov rad znatno manje produktivnim.

Čovek, pogotovo ako je programer, sposoban je da uradi mnogo radi posla: da ostane do kasno na poslu, da ide na posao vikendom, odustane od odmora, da bude budan nekoliko dana dok sedi za tastaturom... Općenito, šta možete učiniti za svoju omiljenu aktivnost. Ali ekstremno programiranje je kategorički protiv takvog samopožrtvovanja i kršenja prihvaćenih standarda radnog prava.

Ovo nije diktirano samo promišljanjima zakonitosti i humanosti, već, prije svega, potrebom povećanja efikasnosti rada i strože organizacije. Uostalom, ekstremno programiranje je kolektivna igra, dizajnirana ne za pojedince, već za cijelu grupu. A takvo što, na primjer, programiranje u paru moguće je samo kada se sinkroniziraju bioritmovi njegovih sudionika. A nemoguće je ako jedan dođe na posao u devet, a drugi u dvanaest, ili neko odluči da mu je bolje da radi subotom i nedeljom, a drugom je nezgodno.

Ali najvažnije je da je za održavanje zdravlja i performansi čovjeku potreban pravilan odmor. Osmosatni radni dan i petodnevna radna sedmica ustanovljeni su upravo iz razloga maksimalne produktivnosti. U mnogim zapadnim kompanijama, napuštanje posla kasno se smatra neuspehom u obavljanju poslova ili nesposobnošću da se pravilno upravlja svojim radnim vremenom. U većini slučajeva to je tačno. A sa medicinskog stajališta, kašnjenja na poslu dovode do stalnog umora, razdražljivosti i smanjene moždane aktivnosti. Da li je ovo efikasno? Kako u takvom timu organizovati stalnu otvorenu komunikaciju između programera i hoće li biti moguće programiranje u paru? Odgovor je negativan. Standardi su standardi i treba ih poštovati.

· InkluzijakupacVtim (on- sitekupac)

Glavni problem u razvoju softvera je nedostatak znanja programera u oblasti koja se razvija. Ekstremno programiranje pronašlo je izlaz iz ove situacije. Ne, ovo nije programska praksa u preduzeću kupca - tada on neće htjeti programirati. Naprotiv, to je učešće kupca u procesu razvoja.

Razvojni tim uvijek uključuje predstavnika kupaca koji je dostupan tokom cijelog radnog dana i može odgovoriti na sva pitanja o sistemu. Njegova odgovornost je da odmah odgovori na pitanja bilo koje vrste u vezi sa funkcijama sistema, njegovim interfejsom, potrebnim performansama, pravilan rad sistemi u složenim situacijama, potreba za održavanjem komunikacije sa drugim aplikacijama, itd.

Mnogi sumnjaju u mogućnost uključivanja kupca u proces razvoja. Zaista, kupci su različiti. Ako nije moguće privući kupca ili njegovog predstavnika, ponekad je preporučljivo privremeno angažirati stručnjaka u području koje se razvija. Ovaj korak će smanjiti nejasnoće u radu, povećati brzinu razvoja i približiti projekat onome što kupac želi da dobije. Ovo može biti korisno i s finansijske strane: na kraju krajeva, plata programera ponekad je znatno veća od plaće stručnjaka u drugim industrijama.

· UpotrebakodKakoobjekatakomunikacije

Kod se vidi kao najvažnije sredstvo komunikacije unutar tima. Jasnoća koda je jedan od glavnih prioriteta. Praćenje standarda kodiranja koji pružaju ovu jasnoću je imperativ. Takvi standardi, pored jasnoće koda, trebaju osigurati minimalan jezik (bez dupliranja koda i informacija) i trebali bi ih prihvatiti svi članovi tima.

· Otvoriradiprostor (otvorenradni prostor)

Tim je smješten u jednoj prilično prostranoj prostoriji kako bi se olakšala komunikacija i omogućila grupna diskusija prilikom planiranja i donošenja važnih tehničkih odluka.

· PromjenapravilaBynužnost (samopravila)

Svaki član tima mora prihvatiti navedena pravila, ali ako se ukaže potreba, tim ih može promijeniti ako se svi njegovi članovi slažu s tom promjenom.

Kao što se vidi iz tehnika koje se koriste, XP je dizajniran za upotrebu u malim timovima (ne više od 10 programera), što ističu i autori ove tehnike. Veća veličina tima uništava lakoću komunikacije neophodnu za uspjeh i onemogućava implementaciju mnogih od navedenih tehnika.

3.1 Osnovne XP tehnike

Dvanaest osnovnih tehnika ekstremnog programiranja (na osnovu prvog izdanja knjige Ekstremno programiranje objašnjeno) mogu se kombinovati u četiri grupe:

· Kratak ciklus povratne informacije (fina povratna informacija)

o Testom vođen razvoj

o Igra planiranja

o Kupac je uvijek u blizini (cijeli tim, kupac na licu mjesta)

o Programiranje u paru

Kontinuirani, a ne grupni proces

o Kontinuirana integracija

o Refaktoriranje (poboljšanje dizajna, preuređivanje)

o Česta mala izdanja

· Razumijevanje koje dijele svi

o Jednostavnost (Jednostavan dizajn)

o Sistemska metafora

o Kolektivno vlasništvo nad kodom ili odabrani obrasci dizajna (Kolektivno vlasništvo nad uzorcima)

o Standard kodiranja ili konvencije kodiranja

· Dobrobit programera:

o 40-satna radna sedmica (održivi tempo, četrdesetosatna sedmica)

IgraVplaniranje

Naš svijet je previše promjenjiv i nepredvidiv da bismo se oslanjali na postojanost situacije. Ista stvar se dešava u razvoju softvera: o rijetki sistem možemo reći da je njegov konačni oblik bio unaprijed do detalja poznat na samom početku razvoja. Obično se apetit kupca javlja dok jede: on stalno želi nešto promijeniti, poboljšati ili potpuno izbaciti nešto iz sistema. To je varijabilnost zahtjeva kojih se svi toliko boje. Na sreću, čovjeku je data sposobnost predviđanja moguće opcije i tako držati situaciju pod kontrolom.

U Extreme Programmingu planiranje je sastavni dio razvoja i činjenica da se planovi mogu mijenjati uzima se u obzir od samog početka. Uporište, tehnika koja vam omogućava da predvidite situaciju i bezbolno podnesete promjene, je igra planiranja. Tokom takve igre, poznati sistemski zahtjevi mogu se brzo prikupiti, procijeniti i planirati prema prioritetu.

Kao i svaka druga igra, planiranje ima svoje učesnike i svoj cilj. Ključna figura je, naravno, kupac. On je taj koji komunicira potrebu za ovom ili onom funkcionalnošću. Programeri daju približnu procjenu svake funkcionalnosti. Ljepota igre planiranja leži u jedinstvu svrhe i solidarnosti između programera i kupca: u slučaju pobjede svi pobjeđuju, u slučaju poraza svi gube. Ali u isto vrijeme, svaki učesnik ide svojim putem do pobjede: kupac odabire najvažnije zadatke u skladu s budžetom, a programer procjenjuje zadatke u skladu sa svojom sposobnošću da ih implementira.

Ekstremno programiranje pretpostavlja da programeri mogu sami da odluče koliko će im vremena trebati da završe svoje zadatke i ko bi od njih bio spremniji da reši jedan problem, a ko drugi.

U idealnoj situaciji, igra planiranja između kupca i programera bi se trebala igrati svakih 3-6 sedmica, sve dok ne počne sljedeća iteracija razvoja. Ovo čini prilično lakim prilagođavanje na osnovu uspjeha i neuspjeha prethodne iteracije.

4. Prednosti i nedostaci

Prednosti XP-a, ukoliko se može implementirati, su veća fleksibilnost, mogućnost brzog i preciznog unošenja izmjena u softver kao odgovor na promjenjive zahtjeve i individualne želje kupaca, visok kvalitet rezultirajućeg koda i odsustvo potrebe za uvjeriti kupce da rezultat ispunjava njihova očekivanja.

Nedostaci ovog pristupa su neizvodljivost dovoljno velikih i složenih projekata u ovom stilu, nemogućnost planiranja vremena i složenosti projekta na dovoljno dug rok i jasnog predviđanja rezultata dugoročnog projekta u smislu omjera kvaliteta rezultata i troškova vremena i resursa. Također se može primijetiti da XP nije pogodan za one slučajeve u kojima moguća rješenja se ne nalaze odmah na osnovu prethodno stečenog iskustva, već zahtijevaju preliminarno istraživanje.

5. Istorija upotrebe

XP kao skup opisanih tehnika prvi put je korišćen tokom rada na projektu C3 (Chrysler Comprehensive Compensation System, razvoj sistema za obračun beneficija zaposlenih u Daimler Chrysleru). Od 20 učesnika u ovom projektu, njih 5 (uključujući pomenuta 3 glavna autora XP-a) objavilo je 3 knjige i velika količinačlanci posvećeni XP-u. Sljedeći podaci ilustruju probleme s nekim XP tehnikama kada se primjenjuju na prilično složene projekte.

Projekat je započeo u januaru 1995. Od marta 1996. godine, nakon uključivanja Kenta Becka, koristi se XP. Do tada je već prevazišao budžet i planove za faznu implementaciju funkcija. Razvojni tim je skraćen, a nakon toga oko šest mjeseci projekat se prilično uspješno razvijao. U avgustu 1998. pojavio se prototip koji je mogao opsluživati ​​oko 10.000 zaposlenih. Prvobitno se očekivalo da će projekat biti završen sredinom 1999. godine, a nastali softver će se koristiti za upravljanje beneficijama za 87.000 zaposlenih u kompaniji. Zaustavljen je u februaru 2000. nakon 4 godine korištenja XP-a zbog potpunog neispunjavanja vremenskih okvira i budžeta. Napravljeni softver nikada nije korišćen za rad sa podacima o više od 10.000 zaposlenih, iako se pokazalo da može da obrađuje podatke o 30.000 zaposlenih u kompaniji. Osoba koja je imala ulogu naručioca uključenog u projektni tim dala je otkaz nakon nekoliko mjeseci takvog rada, ne mogavši ​​izdržati opterećenje, a do kraja projekta nikada nije dobila adekvatnu zamjenu.

Zaključak

Sve gore navedene metode nisu spojene slučajno. Njihova dosljedna kombinacija može dovesti proces razvoja u intelektualnu rezonancu, značajno povećavajući kvalitetu proizvoda i ubrzavajući vrijeme njegovog izdavanja. Glavna ljepota svakog ekstremnog programiranja je predvidljivost i minimiziranje troškova razvoja; pružanje kupcu proizvoda koji želi dobiti u trenutku puštanja u promet; i naravno, komunikacija i obuka programera na radnom mjestu.

Mišljenja o predloženoj metodologiji mogu se razlikovati. Važno je shvatiti da Extreme Programming nema za cilj zamjenu postojeće tehnologije razvoj. Naprotiv, XP može pružiti dodatni poticaj timovima koji koriste tradicionalne pristupe. Ne biste trebali ovdje tražiti odgovore na sva vaša pitanja. Ovo nije tehnologija programiranja, ali radije tehnologije organizaciju rada i upravo u tom obliku ima pravo na život.

Objavljeno na Allbest.ru

Slični dokumenti

Analiza faza i karakteristika razvoja optimalnog i funkcionalnog ARIS modela - softverskog proizvoda IDS Scheer za modeliranje poslovnih procesa kompanije. Proučavanje osnovnih koncepata, metodologija i pristupa ekstremnog programiranja.

test, dodano 04.06.2011


Glavne faze razvoja softvera (softverski paket), analiza sistemskih zahtjeva. Metoda detaljiranja korak po korak. Programski jezici niskog i visokog nivoa (imperativni, objektno orijentisani, funkcionalni, logički).

prezentacija, dodano 13.10.2013


Razvojni jezik, okruženje za implementaciju, razvojni alati. Posebnosti virtuelno okruženje implementacija programa i njihovo razmatranje u razvoju softverskog proizvoda. Sistemski makroi i njihova upotreba u razvojnim tekstovima. Alati za vizualno programiranje.

tutorial, dodano 26.10.2013


Problem pouzdanosti softvera, njegovi pokazatelji i faktori podrške. Metode praćenja procesa razvoja programa i dokumentacije, prevencija grešaka. Faze procesa otklanjanja grešaka u softveru, tehnike strukturiranog programiranja i princip modularnosti.

prezentacija, dodano 30.04.2014


Mašinski kodovi i asembler. Prvi programski jezici visokog nivoa. FORTRAN programski jezik. Prednosti i mane ALGOL-a. Naučni i računovodstveni programi. Osnovni principi koji su se držali prilikom kreiranja osnovnog programskog jezika.

kurs, dodato 21.06.2014


Koncept i ključna razlika razvoja distribuiranog softvera, njegove prednosti i nedostaci. Idejno rješenje i izbor vrste izrade. Karakteristike softvera otvorenog koda. Ideja i razvoj otvorenog koda.

kurs, dodan 14.12.2012


Koncept životni ciklus softver. Razlikuju se dvije vrste aktivnosti u tehnički projekti: dizajn i proizvodnja. Glavna načela manifesta sljedbenika fleksibilnih metodologija. Osnovni principi ekstremnog programiranja.

prezentacija, dodano 14.08.2013


Međunarodni standard u programskom jeziku Pascal. Tehnike objektno orijentisanog programiranja u Turbo Pascalu. Simboli jezika, njegovo pismo. Faze razvoja programa. Pojam algoritama i algoritamizacija. Struktura programa u Pascalu.

kurs, dodan 28.02.2010


Savremeni alati za razvoj softvera za upravljačke sisteme. Univerzalni programski jezici i njihovo poređenje sa SCADA sistemima. Razvoj softvera korištenjem više kanala mjerni pretvaračiŠ9327.

teza, dodana 13.07.2011


Osnovne tehnike rada u okruženju Delphi programiranje. Karakteristike tehnologije za kreiranje jednostavnih aplikacija. Rad sa komponentama okruženja za razvoj aplikacija. Unos, uređivanje, odabir i izlaz informacija. Aspekti korištenja strukture grananja.

Ekstremno programiranje (XP) je jedna od fleksibilnih metodologija razvoja softvera. Autori metodologije su Kent Beck, Ward Cunningham, Martin Fowler i drugi.

Igra planiranja

Naš svijet je previše promjenjiv i nepredvidiv da bismo se oslanjali na postojanost situacije. Ista stvar se dešava i u razvoju softvera: za rijetki sistem, može se reći da je njegov konačni oblik bio unaprijed poznat do detalja na samom početku razvoja. Obično se apetit kupca javlja dok jede: on stalno želi nešto promijeniti, poboljšati ili potpuno izbaciti nešto iz sistema. To je varijabilnost zahtjeva kojih se svi toliko boje. Na sreću, osoba ima sposobnost da predvidi moguće opcije i na taj način drži situaciju pod kontrolom.
U Extreme Programmingu planiranje je sastavni dio razvoja i činjenica da se planovi mogu mijenjati uzima se u obzir od samog početka. Uporište, tehnika koja vam omogućava da predvidite situaciju i bezbolno podnesete promjene, je igra planiranja. Tokom takve igre, poznati sistemski zahtjevi mogu se brzo prikupiti, procijeniti i planirati prema prioritetu.
Kao i svaka druga igra, planiranje ima svoje učesnike i svoj cilj. Ključna figura je, naravno, kupac. On je taj koji komunicira potrebu za ovom ili onom funkcionalnošću. Programeri daju približnu procjenu svake funkcionalnosti. Ljepota igre planiranja leži u jedinstvu svrhe i solidarnosti između programera i kupca: u slučaju pobjede svi pobjeđuju, u slučaju poraza svi gube. Ali u isto vrijeme, svaki učesnik ide svojim putem do pobjede: kupac odabire najvažnije zadatke u skladu s budžetom, a programer procjenjuje zadatke u skladu sa svojom sposobnošću da ih implementira.
Ekstremno programiranje pretpostavlja da programeri mogu sami da odluče koliko će im vremena trebati da završe svoje zadatke i ko bi od njih bio spremniji da reši jedan problem, a ko drugi.
U idealnoj situaciji, igra planiranja između kupca i programera bi se trebala igrati svakih 3-6 sedmica, sve dok ne počne sljedeća iteracija razvoja. Ovo čini prilično lakim prilagođavanje na osnovu uspjeha i neuspjeha prethodne iteracije.

Plan izdanja

Plan izdanja definira datume izdanja i korisničke izjave koje će biti implementirane u svakom od njih. Na osnovu toga možete odabrati formulacije za sljedeću iteraciju. Tokom iteracije, testovi prihvatljivosti se proizvode i izvode unutar te iteracije i svih narednih kako bi se osiguralo da program radi ispravno. Plan se može revidirati ako postoji značajno kašnjenje ili prednost na kraju jedne od iteracija.
Iteracije. Iteracija čini razvojni proces dinamičnim. Nema potrebe da planirate svoje softverske zadatke mnogo unapred. Umjesto toga, bolje je održati sastanak o planiranju na početku svake iteracije. Nema smisla pokušavati implementirati nešto što nije planirano. I dalje ćete imati vremena da implementirate ove ideje kada budu objavljene prema planu izdanja.
Ako steknete naviku da ne dodajete funkcionalnost unapred i koristite planiranje unapred, lako se možete prilagoditi promenljivim zahtevima kupaca.

Planiranje iteracije

Planiranje iteracije počinje sastankom na početku svake iteracije radi razvoja plana koraka za rješavanje softverskih problema. Svaka iteracija bi trebala trajati od jedne do tri sedmice. Formulacije unutar iteracije se sortiraju prema njihovoj važnosti za kupca. Dodatno se dodaju zadaci koji nisu mogli proći testove prihvatanja i zahtijevaju daljnji rad. Testne izjave i rezultati se prevode u softverske probleme. Zadaci su zapisani na karticama koje čine detaljan plan iteracije. Za rješavanje svakog problema potrebno je od jednog do tri dana. Zadaci koji zahtijevaju manje od jednog dana mogu se grupirati, a veliki zadaci se mogu podijeliti u nekoliko manjih. Programeri procjenjuju zadatke i rokove za njihov završetak. Za programera je veoma važno da tačno odredi vreme izvršenja zadatka. Možda će biti potrebno ponovo procijeniti neki jezik i revidirati plan izdanja nakon svaka tri ili pet iteracija - to je potpuno prihvatljivo. Ako prvo implementirate najvažnije oblasti rada, uvijek ćete imati vremena da učinite maksimalno moguće za svoje klijente. Iterativni stil razvoja poboljšava proces razvoja.

Sastanak stojeći

Svako jutro se održava sastanak na kojem se razgovara o problemima, njihovim rješenjima i da se pojača koncentracija tima. Sastanak se održava stojeći kako bi se izbjegle duge rasprave koje nisu interesantne svim članovima tima.
Na tipičnom sastanku, većina učesnika ne doprinosi ništa, samo učestvuje da čuje šta drugi imaju da kažu. Veliki broj Vrijeme ljudi se gubi da bi dobili malu količinu komunikacije. Stoga, prisustvo svih na sastancima oduzima resurse projektu i stvara haos u planiranju.
Ova vrsta komunikacije zahtijeva stalni sastanak. Mnogo je bolje imati jedan kratak, obavezan sastanak nego mnogo dugih na kojima većina programera ionako mora prisustvovati.
Ako imate dnevne stalne sastanke, onda svim ostalim sastancima treba da prisustvuju samo oni ljudi koji su neophodni i koji će doneti nešto na sto. Štaviše, moguće je čak i izbjeći neke sastanke. Sa ograničenim brojem učesnika, većina sastanaka se može održati spontano pred monitorom, gdje je razmjena ideja mnogo intenzivnija.
Dnevni jutarnji sastanak nije još jedno gubljenje vremena. To će vam omogućiti da izbjegnete mnoge druge sastanke i uštedjete više vremena nego što ga potrošite na njega.

Jednostavnost

Jednostavan dizajn uvijek oduzima manje vremena od složenog. Zato uvijek radite najjednostavnije stvari koje će uspjeti. Uvijek je brže i jeftinije zamijeniti složeni kod odmah, prije nego što potrošite puno vremena radeći na njemu. Neka stvari budu što jednostavnije bez dodavanja funkcionalnosti prije planiranja. Imajte na umu: održavanje jednostavnosti dizajna je težak posao.

Sistem metafora

Izbor sistema metafora je neophodan da bi se tim zadržao u istom okviru prilikom imenovanja klasa i metoda. Način na koji imenujete svoje objekte je vrlo važan za razumijevanje cjelokupnog dizajna sistema i ponovne upotrebe koda. Ako je programer u stanju ispravno predvidjeti kako će postojeći objekat, ovo dovodi do uštede vremena. Koristite sistem imenovanja za svoje objekte koji svako može razumjeti bez specifičnog znanja o sistemu.

Kupac na gradilištu

Glavni problem u razvoju softvera je nedostatak znanja programera u oblasti koja se razvija. Ekstremno programiranje pronašlo je izlaz iz ove situacije. Ne, ovo nije programska praksa u preduzeću kupca - tada on neće htjeti programirati. Naprotiv, to je učešće kupca u procesu razvoja.
Može li programer, bez potpunog razumijevanja suštine problema i koji nije telepata, pogoditi šta korisnik želi? Odgovor je očigledan. Najlakši način da prevaziđemo ovu neugodnost – a Extreme Programming nas uči da pronađemo najjednostavnija rješenja – je da korisniku postavimo direktno pitanje. Rigorozniji pristupi zahtijevaju sveobuhvatnu preliminarnu analizu područja koje se razvija. IN određenim slučajevima Ovo je opravdano, iako je skuplje. Pravo iskustvo u vođenju svakodnevnih projekata pokazuje da je nemoguće prikupiti sve zahtjeve unaprijed. Štaviše, čak i ako pretpostavimo da su svi zahtjevi trenutno prikupljeni, ipak će postojati jedno usko grlo: programi, kao i sve u prirodi, ne nastaju trenutno, a u međuvremenu se poslovni procesi mogu promijeniti. Ovo treba uzeti u obzir.
Mnogi sumnjaju u mogućnost uključivanja kupca u proces razvoja. Zaista, kupci su različiti. Ako nije moguće privući kupca ili njegovog predstavnika, ponekad je preporučljivo privremeno angažirati stručnjaka u području koje se razvija. Ovaj korak će smanjiti nejasnoće u radu, povećati brzinu razvoja i približiti projekat onome što kupac želi da dobije. Ovo može biti korisno i s finansijske strane: na kraju krajeva, plata programera ponekad je znatno veća od plaće stručnjaka u drugim industrijama.
Korisnička priča. Korisnička priča (nešto poput korisničke priče) je opis kako sistem treba da radi. Svaka korisnička priča je napisana na kartici i predstavlja neki dio funkcionalnosti sistema koji ima logičan smisao sa stanovišta Kupca. Forma je jedan ili dva pasusa teksta koji je razumljiv korisniku (ne baš tehnički).
Korisničku priču piše Kupac. Oni su slični scenarijima korištenja sistema, ali nisu ograničeni na njih korisnički interfejs. Za svaku priču su napisani funkcionalni testovi kako bi se potvrdilo da je ova priča ispravno implementirana – nazivaju se i testovi prihvatanja.

Testiranje prije početka razvoja

Testiranje je, u svom klasičnom smislu, prilično dosadna procedura. Obično angažuju testera koji povremeno obavlja iste radnje i čeka dan kada konačno bude premješten na drugu poziciju ili se ukaže prilika za promjenu posla.
U ekstremnom programiranju uloga testiranja je interesantnija: sada je prvo test, a zatim kod. Kako testirati nešto što još ne postoji? Odgovor je jednostavan i banalan: testirajte svoje misli - što očekivati ​​od budućeg dijela programa ili funkcionalnosti. Ovo će vam omogućiti da bolje razumete šta programeri treba da urade i da proverite funkcionalnost koda čim se napiše.
Ali ni test možda neće raditi. Pa šta, napisati test za test? I onda test za test i tako dalje do beskonačnosti? Ne sve. Test za test će zamijeniti kod. Kako to? Ali pogledajte: zamislite da trebate popraviti maticu u sredini vijka tako da se ne okreće. Šta oni rade za ovo? Drugu maticu privijte blizu prve, tako da svaka matica spriječi da se susjedna zavrti. Isto je i u programiranju: test testira kod, a kod testira test.
Iskustvo pokazuje da ovaj pristup ne samo da ne usporava, već i ubrzava razvoj. Na kraju krajeva, znajući šta treba učiniti i potrebnu količinu posla uštedjet ćete vrijeme odbijanjem prodaje nepotraženih predmeta. ovog trenutka detalji.

Programiranje u paru

Sav kod za proizvodni sistem je napisan u parovima. Dva programera sjede jedan pored drugog. Jedan kuca, drugi gleda. Oni se s vremena na vrijeme mijenjaju. Nije dozvoljeno raditi sam. Ako je iz nekog razloga drugi iz para nešto propustio (bolestan, penzionisan, itd.), dužan je da pregleda sve promjene koje je prvi napravio.
Zvuči neobično, ali nakon kratkog perioda adaptacije, većina ljudi dobro radi u paru. Čak im se sviđa jer se posao obavlja znatno brže. Primjenjuje se princip „Jedna glava je dobra, a dvije su bolje“. Parovi obično pronalaze bolja rješenja. Osim toga, kvaliteta koda se značajno povećava, broj grešaka se smanjuje, a razmjena znanja između programera se ubrzava. Dok se jedna osoba fokusira na stratešku viziju objekta, druga implementira njegova svojstva i metode.

Menjanje položaja

Tokom sljedeće iteracije sve radnike treba premjestiti u nova područja rada. Takvi pokreti su neophodni kako bi se izbjegla izolacija znanja i eliminisali “ uska mjesta" Posebno je plodna zamjena jednog od programera u programiranju u paru.

Kolektivno vlasništvo koda

Zajedničko vlasništvo koda potiče programere da predaju ideje za sve dijelove projekta, a ne samo za svoje module. Svaki programer može promijeniti bilo koji kod kako bi proširio funkcionalnost i popravio greške.
Na prvi pogled izgleda kao haos. Međutim, uzimajući u obzir da je barem bilo koji kod kreirano od strane nekoliko programera, da testovi omogućavaju da provjerite ispravnost unesenih promjena, te da pravi zivot Iako i dalje morate razumjeti tuđi kod na ovaj ili onaj način, postaje jasno da kolektivno vlasništvo nad kodom uvelike pojednostavljuje promjene i smanjuje rizik povezan s visokom specijalizacijom jednog ili drugog člana tima.

Konvencija kodiranja

Vi ste dio tima koji već dugo radi na ovom projektu. Ljudi dolaze i odlaze. Niko ne šifrira sam i šifra pripada svima. Uvijek će biti trenutaka kada trebate razumjeti i prilagoditi tuđi kod. Programeri će ukloniti ili promijeniti duplirani kod, analizirati i poboljšati klase drugih ljudi, itd. Vremenom će biti nemoguće reći ko je autor određene klase.
Stoga svi moraju poštovati zajedničke standarde kodiranja - formatiranje koda, imenovanje klasa, varijabli, konstante, stil komentara. Na taj način ćemo biti sigurni da kada izvršimo promjene u tuđem kodu (što je neophodno za agresivan i ekstreman napredak naprijed), nećemo ga pretvoriti u Babel Pandemonium.
Gore navedeno znači da se svi članovi tima moraju složiti oko zajedničkih standarda kodiranja. Nije bitno koje. Pravilo je da ih svi poštuju. Oni koji ne žele da ih ispoštuju napuštaju tim.

Česta integracija

Programeri bi trebali integrirati i objaviti svoj kod svakih nekoliko sati ako je moguće. U svakom slučaju, nikada ne biste trebali zadržavati promjene duže od jednog dana. Česta integracija izbjegava otuđenje i fragmentaciju u razvoju, gdje programeri ne mogu komunicirati u smislu dijeljenja ideja ili ponovne upotrebe koda. Svako mora da radi sa najviše najnoviju verziju.
Svaki par programera trebao bi dati svoj kod čim je to razumno moguće učiniti. Ovo može biti kada svi UnitTestovi prođu 100%. Podnošenjem izmjena nekoliko puta dnevno smanjujete probleme integracije na gotovo nulu. Integracija je aktivnost „platite sada ili platite više kasnije“. Stoga, integracijom promjena u malim koracima svaki dan, nećete morati provesti sedmicu pokušavajući da povežete sistem neposredno prije nego što projekat bude isporučen. Uvijek radite na najnovijoj verziji sistema.

Radna sedmica od četrdeset sati

Čovek, pogotovo ako je programer, sposoban je da uradi mnogo radi posla: da ostane do kasno na poslu, da ide na posao vikendom, odustane od godišnjeg odmora, da bude budan nekoliko dana dok sedi za tastaturom... Općenito, šta možete učiniti za svoju omiljenu aktivnost. Ali ekstremno programiranje je kategorički protiv takvog samopožrtvovanja i kršenja prihvaćenih standarda radnog prava.
Ovo nije diktirano samo promišljanjima zakonitosti i humanosti, već, prije svega, potrebom povećanja efikasnosti rada i strože organizacije. Uostalom, ekstremno programiranje je kolektivna igra, dizajnirana ne za pojedince, već za cijelu grupu. A takvo što, na primjer, programiranje u paru moguće je samo kada se sinkroniziraju bioritmovi njegovih sudionika. A nemoguće je ako jedan dođe na posao u devet, a drugi u dvanaest, ili neko odluči da mu je bolje da radi subotom i nedeljom, a drugom je nezgodno.
Ali najvažnije je da je za održavanje zdravlja i performansi čovjeku potreban pravilan odmor. Osmosatni radni dan i petodnevna radna sedmica ustanovljeni su upravo iz razloga maksimalne produktivnosti. U mnogim zapadnim kompanijama, napuštanje posla kasno se smatra neuspehom u obavljanju poslova ili nesposobnošću da se pravilno upravlja svojim radnim vremenom. U većini slučajeva to je tačno. A sa medicinskog stajališta, kašnjenja na poslu dovode do stalnog umora, razdražljivosti i smanjene moždane aktivnosti. Da li je ovo efikasno? Kako u takvom timu organizovati stalnu otvorenu komunikaciju između programera i hoće li biti moguće programiranje u paru? Odgovor je negativan. Standardi su standardi i treba ih poštovati.

Zaključak

Ove metode nisu spojene slučajno. Njihova dosljedna kombinacija može dovesti proces razvoja u intelektualnu rezonancu, značajno povećavajući kvalitetu proizvoda i ubrzavajući vrijeme njegovog izdavanja. Glavna ljepota svakog ekstremnog programiranja je predvidljivost i minimiziranje troškova razvoja; pružanje kupcu proizvoda koji želi dobiti u trenutku puštanja u promet; i naravno, komunikacija i obuka programera na radnom mjestu.

Bibliografija:

Ekstremno programiranje - ili, ukratko, XP (ekstremno programiranje) - je odgovor zajednice programera na napad formalnih pristupa kreiranju softverskih proizvoda i dizajniran je da vrati duh kreativnosti u okruženje programera.

Svaka ideja dovedena do apsurda degenerira se u vlastitu suprotnost. Upravo je takva situacija u sjevernoameričkoj softverskoj industriji s alatima za razvoj RAD-a. U nekom trenutku, alati dizajnirani za brzi razvoj aplikacija počeli su istiskivati ​​sve ostalo u glavama menadžera, uključujući programere, kupce i sam projekat. Neopravdana, hipertrofirana pažnja prema Procesu na štetu drugih faktora razvoja dovela je do velikog broja formalnih procedura – ali kvalitet rezultirajućih proizvoda i broj uspješnih projekata su se pokazali razočaravajućim.

Inicijativa grupe programera ujedinjenih pod sloganom Extreme Programming, ili XP, osmišljena je da se odupre pritisku formalizma u radu programera.

Ekstremno programiranje se zasniva na nekoliko vrlo specifičnih, često numerički izraženih principa koji definišu šta, kada i kako treba uraditi. Ne uzimajući ove brojke kao dogmu, treba, međutim, imati na umu da su se pojavili kao rezultat analize brojnih uspješnih i neuspješnih projekata, tako da u najmanju ruku moraju postojati dobri razlozi za izmjene i dopune.

Ekstremno programiranje se ne zasniva na specifičnim tehnikama, kao što se obično vjeruje, već samo na četiri osnovna principa: komunikaciji, jednostavnosti, povratnoj informaciji i hrabrosti. Ovdje morate početi.

Extreme Programming nudi gotovo rješenje: neka sve bude što jednostavnije, zadržite kupca za sebe ili ostanite uz kupca, pustite ga da aktivno prati proces razvoja, pozdravite promjenu - i uspjeh je gotovo zagarantovan.

U XP timovima se komunikacija uvijek podstiče – najbrži način za razmjenu informacija i iskustva. Ovo je veoma važno kada je potrebna maksimalna brzina razvoja. Ali komunikacija, kao i svaki drugi koristan poduhvat, zahtijeva stalnu podršku. Zato neko iz tima mora preuzeti odgovornost za praćenje komunikacije, postajući takozvani diplomata. Komunikacija i potreba da ostalim članovima tima objasnite svoje postupke tjera vas da sve radite što jednostavnije. Ako ne uspije prvi put, oni rade na pojednostavljenju iznova i iznova dok se ne postigne glavni cilj - maksimalna razumljivost koda za druge programere.

Ekstremni ciklus

Ekstremno programiranje se zasniva na vrlo kratkom, iterativnom razvojnom ciklusu od jedne do tri sedmice. Do kraja svakog ciklusa, trebalo bi da postoji potpuno funkcionalno, funkcionalno i testirano izdanje aplikacije. Ovi ciklusi se moraju ponavljati i neprekinuti tokom cijelog projekta.

Preduslov za ovakav način rada je više puta dokazana činjenica da su zahtjevi rijetko potpuni, pravovremeni i tačni. Drugim riječima, bez obzira na to koliko je dobro planirana aplikacija, ona će morati biti 100% redizajnirana. Štaviše, možda će morati da se prepravi čak iu završnoj fazi. Izmjene ne treba odlagati do kraja radova, već ih se mora raditi redovno.

Kao posljedica stalno mijenjanih zahtjeva, slijedi još jedan princip – kasno odlučivanje.

Ekstremno programiranje je metodologija za brzi razvoj softvera. Sastoji se od skupa tehnika i principa koji omogućavaju, kako pojedinačno, tako iu kombinaciji, optimizaciju procesa razvoja. Ovaj pristup također reguliše prava programera i kupaca.

Prava i uloge

U Ekstremnom programiranju sve uloge su jasno opisane. Svaka uloga dolazi sa karakterističnim skupom prava i odgovornosti. Ovdje su dvije ključne uloge: kupac i programer.

Kupac

Osoba ili grupa ljudi zainteresovana za kreiranje određenog softverskog proizvoda. Ima sledeća prava i obaveze:

• popraviti datume izdanja za verzije proizvoda;
• donosi odluke o planiranim programskim komponentama;
• znati procijenjenu cijenu svake funkcionalne komponente;
• donose važne poslovne odluke;
• znam Trenutna drzava sistemi;
• promijeniti sistemske zahtjeve kada je to zaista važno.

Da bi uspješno ostvario svoja prava, korisnik se mora osloniti na podatke koje je dao programer.

Developer

Jedan ili grupa od dva do deset ljudi direktno uključenih u programiranje i srodna inženjerska pitanja. Programer je obdaren sljedeća prava i odgovornosti:

• steći dovoljno znanja o temama koje treba programirati;
• biti u stanju da razjasni detalje tokom procesa razvoja;
• pružiti indikativne, ali iskrene procjene napora potrebnog za svaku karakteristiku ili korisničku priču;
• prilagoditi procjene u korist preciznijih tokom procesa razvoja;
• pružiti procjenu rizika povezanih s upotrebom specifičnih tehnologija.

Uloge unutar uloge

Svaka od osnovnih uloga Ekstremnog programiranja može se poboljšati manjim ulogama. XP omogućava kombinaciju uloga unutar jedne osobe.

Strana kupca

Story Compiler- specijalista za predmetnu oblast sa sposobnošću da jasno navede i opiše zahtjeve za sistem koji se razvija. Ova osoba ili grupa ljudi odgovorna je za pisanje korisničkih priča i otklanjanje nesporazuma od strane programera.

Prijemnik- osoba koja prati ispravno funkcionisanje sistema. Dobra komanda predmetna oblast. Odgovornosti uključuju pisanje testova prihvatljivosti.

Veliki šef- prati rad svih nivoa, od programera do krajnjim korisnicima. On kontroliše implementaciju sistema i povezana organizaciona pitanja. Može biti i investitor u projekat.

Developer side

Programer- osoba uključena u kodiranje i dizajn na niskom nivou. Dovoljno je kompetentan da rješava trenutne razvojne probleme i daje iskrene procjene planiranih zadataka.

Instruktor- iskusan programer sa dobrim poznavanjem cjelokupnog procesa razvoja i njegovih tehnika. Odgovoran za obuku tima u aspektima procesa razvoja. Implementira i prati ispravnu implementaciju korištenih procesnih metoda. Skreće pažnju tima na važne, ali iz nekog razloga propuštene razvojne tačke. Istovremeno, instruktor, kao i svaka druga osoba, nije sveznajući i obraća pažnju na ideje drugih članova tima.

Posmatrač- član razvojnog tima, od povjerenja cijele grupe, koji prati napredak razvoja. On poredi preliminarne procjene troškove rada i stvarno utrošene, prikazujući kvantitativne pokazatelje rada tima. To su prosječna brzina i postotak izvršenih i planiranih zadataka. Ove informacije dostavljena kupcu radi pravovremene kontrole situacije. Neke od ovih informacija se nenametljivo daju programerima, tako da znaju status projekta, gdje se pojavljuju poteškoće i šta se još može učiniti.

Diplomat- društvena osoba koja inicira komunikaciju između članova tima. Budući da je protok dokumenata minimiziran, važna je stalna komunikacija i prijenos iskustva unutar tima, bolje razumijevanje zahtjeva sistema. Diplomata regulira i pojednostavljuje komunikaciju između kupaca i programera. Važna je karika na sastancima. Sprečava propuste, pojačane strasti i nepotrebne svađe. Diplomata ne može nametati svoje mišljenje onima koji raspravljaju.

Vanjske uloge

konsultant- specijalista sa specifičnim tehničkim vještinama za pomoć programerima sa teško rješivim problemima. Obično se unose izvana.

Pravila ekstremnog programiranja

Konvencija kodiranja

Vi ste dio tima koji već dugo radi na ovom projektu. Ljudi dolaze i odlaze. Niko ne šifrira sam i šifra pripada svima. Uvijek će biti trenutaka kada trebate razumjeti i prilagoditi tuđi kod. Programeri će ukloniti ili promijeniti duplirani kod, analizirati i poboljšati klase drugih ljudi, itd. Vremenom će biti nemoguće reći ko je autor određene klase.

Stoga svi moraju poštovati zajedničke standarde kodiranja - formatiranje koda, imenovanje klasa, varijabli, konstante, stil komentara. Na taj način ćemo biti sigurni da kada izvršimo promjene u tuđem kodu (što je neophodno za agresivan i ekstreman napredak naprijed), nećemo ga pretvoriti u Babel Pandemonium.

Gore navedeno znači da se svi članovi tima moraju složiti oko zajedničkih standarda kodiranja. Nije bitno koje. Pravilo je da ih svi poštuju. Oni koji ne žele da ih ispoštuju napuštaju tim.

Kolektivno vlasništvo koda

Zajedničko vlasništvo koda potiče programere da predaju ideje za sve dijelove projekta, a ne samo za svoje module. Svaki programer može promijeniti bilo koji kod kako bi proširio funkcionalnost, popravio greške ili refaktorirao.

Na prvi pogled izgleda kao haos. Međutim, uzimajući u obzir da je barem bilo koji kod kreiralo nekoliko programera, da Unit testovi omogućavaju da provjerite ispravnost unesenih promjena, te da u stvarnom životu ipak morate na ovaj ili onaj način razumjeti tuđi kod, postaje jasno da kolektivno vlasništvo nad kodom uvelike pojednostavljuje unošenje promjena i smanjuje rizik povezan s visokom specijalizacijom jednog ili drugog člana tima.

CRC sjednica

Koristite kartice klase, odgovornosti, saradnje (CRC) da dizajnirate sistem kao tim. Korištenje kartica olakšava učenje razmišljanja u smislu objekata, a ne funkcija i procedura. Karte takođe dozvoljavaju više ljudi da učestvuju u procesu dizajna (idealno ceo tim), a što više ljudi radi dizajn, to više zanimljive idejeće biti donesena.

Svaka CRC kartica predstavlja instancu objekta. Klasa objekta se može napisati na vrhu, odgovornosti na lijevoj strani, interakcije na desnoj strani. Kažemo "može se napisati" jer kada je CRC sesija u toku, učesnici obično moraju mali broj kartice sa nazivima razreda i ne moraju biti potpuno popunjene.

CRC sesija ide ovako: svaki učesnik reprodukuje sistem govoreći koje poruke šalje kojim objektima. Prolazi kroz cijeli proces poruku po poruku. Slabe tačke i problemi se odmah identifikuju. Alternative dizajna su takođe jasno vidljive u simulaciji procesa.

Da bi se uspostavio red, često se koristi ograničavanje broja istovremenih interakcija na dva.

Kupac

Jedan od zahtjeva XP-a je da je kupac uvijek dostupan. On ne treba samo da pomaže razvojnom timu, već i da bude njegov član. Sve faze XP projekta zahtijevaju komunikaciju s kupcem, po mogućnosti licem u lice - na licu mjesta. Najbolje je jednostavno dodijeliti jednog ili više klijenata razvojnom timu. Pazite, kupac će morati dugo vrijeme, a kancelarija klijenta može pokušati da vam ponudi nekog pripravnika kao stručnjaka. Potreban vam je stručnjak.

Korisničke priče napisao korisnik uz pomoć programera. Korisnik pomaže osigurati da većina željenih funkcija sistema bude pokrivena korisničkom pričom.

Tokom planiranja izdanja, korisnik treba da razgovara o izboru korisničkih priča koje će biti uključene u planirano izdanje. Možda će biti potrebno dogovoriti i sam period izdavanja. Kupac donosi odluke vezane za poslovne ciljeve.

Odaberite najjednostavnije rješenje

Jednostavan dizajn je uvijek lakši za implementaciju od složenog. Zato uvijek idite na najjednostavnije rješenje koje može funkcionirati. Ako vam je nešto komplikovano, zamijenite to nečim jednostavnim. Uvijek se ispostavi da je brže i jeftinije zamijeniti složeni kod jednostavnim prije nego što počnete razumjeti složeni kod.

Refaktor tuđi kod ako vam se čini komplikovanim. Ako nešto izgleda komplikovano, to je siguran znak problema u kodu.

Neka rješenja budu što jednostavnija što je duže moguće. Nikada nemojte dodavati funkcionalnost za budućnost - prije nego što zatreba. Međutim, imajte na umu: održavanje jednostavnosti dizajna je težak posao.

Funkcionalni testovi

Testovi prihvatanja (ranije se zvali i funkcionalni testovi) su napisani na osnovu korisničke priče. Oni sistem posmatraju kao crnu kutiju. Kupac je odgovoran za provjeru ispravnosti funkcionalnih testova. Ovi testovi se koriste za provjeru funkcionalnosti sistema prije puštanja u proizvodnju. Funkcionalni testovi su automatizirani tako da se mogu često izvoditi. Rezultat se prijavljuje timu i tim je odgovoran za planiranje popravki funkcionalnog testa.

Česta integracija

Programeri bi trebali integrirati i objaviti svoj kod svakih nekoliko sati ako je moguće. U svakom slučaju, nikada ne biste trebali zadržavati promjene duže od jednog dana. Česta integracija izbjegava otuđenje i fragmentaciju u razvoju, gdje programeri ne mogu komunicirati u smislu dijeljenja ideja ili ponovne upotrebe koda. Svi bi trebali koristiti najnoviju verziju.

Svaki par programera treba da doprinese svom kodu što je pre moguće. Ovo može biti kada svi UnitTestovi prođu 100%. Podnošenjem izmjena nekoliko puta dnevno smanjujete probleme integracije na gotovo nulu. Integracija je aktivnost „platite sada ili platite više kasnije“. Stoga, svakodnevnom integracijom promjena u malim porcijama, nećete morati potrošiti tjedan dana da povežete sistem u jednu cjelinu neposredno prije nego što projekat bude isporučen. Uvijek radite na najnovijoj verziji sistema.

Za menadžera. Ako programer ne podnese promjene duže od jednog dana, to je jasan pokazatelj ozbiljnog problema. Morate odmah shvatiti šta se dešava. Cjelokupno iskustvo XP timova govori da je razlog kašnjenja uvijek loš dizajn i uvijek se mora naknadno prepravljati.

Planiranje iteracije

Sastanak za planiranje iteracije saziva se prije početka svake iteracije kako bi se planirali zadaci koji će se obaviti u toj iteraciji. Za ponavljanje se odabiru korisničke priče koje je odabrao kupac plan oslobađanja počevši od najvažnijeg za kupca i najgoreg (koji uključuje rizik) za programere. Takođe, pokvareni funkcionalni testovi su uključeni u iteraciju.

Korisničke priče i zaostaci Funkcionalni testovi su raščlanjeni na zadatke. Zadaci su ispisani na karticama. Ove kartice su detaljan plan za iteraciju. Svaki zadatak bi trebao trajati između 1 i 3 idealna dana.

Programeri rastavljaju zadatke i procjenjuju dužinu vremena potrebnog za njihovo dovršenje. Tako svaki programer procjenjuje koliko će mu zadatak trajati. Važno je da konačnu procjenu obima posla izvrši sam programer.

Brzina projekta određuje da li se vaši zadaci uklapaju u iteraciju ili ne. Ukupno trajanje zadataka planiranih za iteraciju ne smije premašiti brzinu postignutu u prethodnoj iteraciji. Ako ste upisali previše, tada korisnik mora odlučiti koje će korisničke priče odgoditi za sljedeću iteraciju. Ako ste upisali premalo, onda morate dodati sljedeću korisničku priču. U nekim slučajevima, možete zatražiti od kupca da podijeli jednu korisničku priču na dva dijela kako bi uključio dio u tekuću iteraciju.

Odlaganje korisničke priče za sljedeću iteraciju može izgledati zastrašujuće, ali ne dozvolite sebi da žrtvujete refaktoring i jedinične testove da biste učinili više. Dug u ovim kategorijama će brzo usporiti vašu brzinu. Nemojte raditi ono što mislite da će biti potrebno u sljedećim iteracijama – radite samo ono što je potrebno da dovršite trenutne korisničke priče.

Pratite brzinu projekta i korisničke priče na čekanju. Moguće je da će plan izdanja morati da se menja svakih tri do pet iteracija. Ovo je u redu. Na kraju krajeva, plan izdanja je pogled u budućnost i prirodno je očekivati ​​da će se vaša predviđanja morati prilagoditi.

Iteracije

Iterativni razvoj povećava fleksibilnost procesa. Podijelite svoj plan na iteracije od 2 do 3 sedmice. Održavajte konstantnu dužinu ponavljanja tokom trajanja projekta. Neka iteracija bude puls vašeg projekta. Ovo je ritam koji će mjerenje napretka i planiranje učiniti jednostavnim i pouzdanim.

Nemojte unaprijed planirati zadatke. Sakupite umjesto toga Planiranje iteracije na početku svake iteracije planirati šta će se raditi. Također se smatra kršenjem pravila preskočiti sebe i učiniti nešto što nije planirano u ovoj iteraciji. Na taj način postaje moguće držati pod kontrolom promjenjive zahtjeve Kupca.

Ozbiljno shvatite rokove završetka iteracije. Mjerite napredak dok radite. Ako je jasno da nećete moći dovršiti sve planirane zadatke do roka, ponovo prikupite Planiranje iteracije i ponovo procijenite zadatke i odgodite neke od zadataka.

Koncentrirajte napore na dovršavanje najvažnijih zadataka koje je odabrao Kupac, umjesto da programer odabere nekoliko nedovršenih zadataka.

Zamijenite zadatke

Potrebno je periodično mijenjati zadatke za programere kako bi se smanjio rizik koncentracije znanja i uskih grla u kodu. Ako samo jedna osoba u vašem timu može raditi u datom području i ta osoba ode, ili jednostavno imate puno posla u datom segmentu programa, otkrit ćete da vaš projekt jedva napreduje.

Cross Training je obično važan aspekt u kompanijama koje pokušavaju izbjeći koncentraciju znanja u jednoj osobi. Kretanje ljudi kroz kod u kombinaciji sa programiranje u paru tiho pravi Cross Training za vas. Umjesto da jedna osoba zna sve o datom dijelu koda, svi u vašem timu znaju mnogo o kodu u svakom modulu.

Tim postaje mnogo fleksibilniji ako svi znaju dovoljno o svakom dijelu sistema da počnu raditi na njemu. Umjesto čekanja da "guru" završi rad na kritičnom dijelu koda, nekoliko programera može raditi na njemu istovremeno.

Prilikom pokretanja novog iteracije svaki programer treba da se prebaci na novi zadatak. Programiranje u paru pomaže u prevazilaženju problema ugradnje (što znači da novi programer može početi raditi u paru sa iskusnim programerom na terenu).

Ova praksa također potiče nove ideje i poboljšani kod.

Ostavite optimizaciju za kasnije

Nikada nemojte ništa optimizirati dok se kodiranje ne završi. Nikada ne pokušavajte pogoditi gdje će biti uska grla u performansama. Mera!

Učinite to da radi, zatim neka radi ispravno, a zatim učinite da radi brzo.

Programiranje u paru

Sav kod za proizvodni sistem (a to znači sa izuzetkom probnih rešenja) je napisan u parovima. Dva programera sjede jedan pored drugog. Jedan kuca, drugi gleda. Oni se s vremena na vrijeme mijenjaju. Nije dozvoljeno raditi sam. Ako je iz nekog razloga drugi iz para nešto propustio (bolestan, penzionisan, itd.), dužan je da pregleda sve promjene koje je prvi napravio.

Zvuči neobično, ali XP tvrdi da nakon kratkog perioda adaptacije većina ljudi dobro radi u paru. Čak im se sviđa jer se posao obavlja znatno brže. Primjenjuje se princip „Jedna glava je dobra, a dvije su bolje“. Parovi obično pronalaze bolja rješenja. Osim toga, kvaliteta koda se značajno povećava, broj grešaka se smanjuje, a razmjena znanja između programera se ubrzava.

Refaktor nemilosrdno!

Mi programeri skloni smo da se držimo dizajna dugo nakon što postane nezgrapan. Nastavljamo ponovo koristiti neodrživ kod jer još uvijek nekako funkcionira i bojimo se da ga ne razbijemo. Ali da li je to zaista korisno? XP smatra da to nije isplativo. Kada uklonimo suvišnost, poboljšamo zastarjeli dizajn, uklonimo neiskorištene dijelove - radimo refaktoring. Refaktoriranje u konačnici štedi vrijeme i poboljšava kvalitetu proizvoda.

Nemilosrdno pregledajte bilo koji kod kako bi vaš dizajn bio jednostavan dok ga razvijate. Neka vaš kod bude jasan i razumljiv tako da ga je lako razumjeti, modificirati i proširiti. Uvjerite se da je sve napisano jednom i samo jednom. Na kraju krajeva, potrebno je manje vremena od poliranja komplikovanog sistema.

Plan izdanja

Plan puštanja u promet se razvija na sastanku za planiranje izdavanja. Planovi izdanja opisuju pogled na cijeli projekat i kasnije se koriste za planiranje iteracija.

Važno je da tehnički ljudi donose tehničke odluke, a poslovni ljudi donose poslovne odluke. Planiranje izdanja definira skup pravila koja omogućavaju svima da donose svoje odluke. Ova pravila definiraju metodu izrade plana rada koji zadovoljava sve.

Suština sastanka za planiranje izdanja za razvojni tim je procijeniti svaku korisničku priču u idealnim sedmicama. Idealna sedmica je koliko mislite da će vam trebati da završite zadatak ako vas ništa drugo ne ometa. Bez zavisnosti, bez dodatnih zadataka, ali uključujući testove. Kupac tada odlučuje koji zadaci su najvažniji ili koji imaju veći prioritet.

Korisničke priče su napisane na karticama. Programeri i korisnik zajedno miješaju karte na stolu dok ne dobiju skup korisničkih priča koje će zajedno činiti prvo (ili sljedeće) izdanje. Svi žele da izdaju koristan sistem koji se može testirati što je ranije moguće.

Izdanje se može planirati prema vremenu ili količini. Da biste odredili koliko korisničkih priča može biti implementirano do određenog datuma ili koliko će realnog vremena trajati određeni skup zadataka, koristite brzinu projekta. Ako planirate po vremenu, pomnožite broj iteracija sa brzinom projekta da biste saznali koliko korisničkih priča se može implementirati. Kada planirate po obimu, podijelite ukupan broj idealnih sedmica potrebnih za sve korisničke priče sa brzinom projekta i dobit ćete broj iteracija potrebnih za završetak izdanja.

Ako menadžment nije zadovoljan datumom završetka, može biti primamljivo smanjiti procjene obima. Nikada ovo ne bi trebalo da radiš. Niske procjene će sigurno kasnije stvoriti mnogo problema. Umjesto toga, pregovarajte s menadžerima, programerima i kupcima dok ne smislite plan izdanja oko kojeg se svi mogu složiti.

Frequent Releases

Programeri bi trebali objavljivati ​​verzije sistema korisnicima (ili beta testerima) što je češće moguće.

Planiranje izdanja koristi se za pronalaženje malih dijelova funkcionalnosti koji imaju značajno poslovno značenje i koji se mogu pustiti u stvarno okruženje u ranim fazama razvoja. Ovo je ključno za blagovremeni prijem korisne kritike da mogu uticati na razvojni proces. Što duže odgađate oslobađanje važnog dijela sistema, manje ćete vremena imati da ga popravite.

Probno rješenje

Kreirajte rješenja s dokazom koncepta kako biste odgovorili na složena pitanja tehnička pitanja, da opravda određena tehnološka rješenja. Postoji rizik uključen u bilo koju tehnološku odluku i probna rješenja su dizajnirana da ublaže ovaj rizik.

Napravite program koji reprodukuje problem koji se istražuje i ignoriše sve ostalo. Većina probnih rješenja nije namijenjena za korištenje, pa očekujte da će biti bačena. Svrha njihovog stvaranja je smanjenje rizika od pogrešnih postupaka tehničko rješenje ili tačniju procjenu vremena za implementaciju korisničke priče.

Sastanak stojeći

Svako jutro se održava sastanak na kojem se razgovara o problemima, njihovim rješenjima i da se pojača koncentracija tima. Sastanak se održava stojeći kako bi se izbjegle duge rasprave koje nisu interesantne svim članovima tima.

Na tipičnom sastanku, većina učesnika ne doprinosi ništa, samo učestvuje da čuje šta drugi imaju da kažu. Velika količina vremena ljudi se gubi na primanje male količine komunikacije. Stoga, prisustvo svih na sastancima oduzima resurse projektu i stvara haos u planiranju.

Ova vrsta komunikacije zahtijeva stalni sastanak. Mnogo je bolje imati jedan kratak, obavezan sastanak nego mnogo dugih na kojima većina programera ionako mora prisustvovati.

Ako imate dnevne stalne sastanke, onda svim ostalim sastancima treba da prisustvuju samo oni ljudi koji su neophodni i koji će doneti nešto na sto. Štaviše, moguće je čak i izbjeći neke sastanke. Sa ograničenim brojem učesnika, većina sastanaka se može održati spontano pred monitorom, gdje je razmjena ideja mnogo intenzivnija.

Dnevni jutarnji sastanak nije još jedno gubljenje vremena. To će vam omogućiti da izbjegnete mnoge druge sastanke i uštedjete više vremena nego što ga potrošite na njega.

Metafora sistema

Uvijek izaberite System Metaphor - jednostavan i jasan koncept tako da članovi tima sve nazivaju istim imenom. Da biste razumjeli sistem i eliminisali duplikat koda, izuzetno je važno kako imenujete objekte. Ako možete pogoditi kako se zove neki objekat u sistemu (ako znate šta radi) i zaista se tako zove, uštedećete mnogo vremena i truda. Kreirajte sistem imenovanja za svoje objekte tako da ga svaki član tima može koristiti bez posebnog znanja o sistemu.

Jedinični testovi

Jedinični testovi igraju ključnu ulogu u XP-u. Omogućavaju vam da brzo promijenite kod bez straha od novih grešaka. Jedinični test je napisan za svaku klasu, test bi trebao provjeriti sve aspekte klase - testirati sve što možda neće raditi.

Trik je u tome što test za klasu mora biti napisan prije same klase. To znači da čim objavite prvi radni rezultat, on će biti podržan od strane sistema testiranja. Za izvođenje testova je napisano poseban sistem testiranje sa sopstvenim interfejsom.

Jedinični test za klasu je pohranjen u zajedničkom spremištu zajedno sa kodom klase. Nijedan kod se ne može objaviti bez testa jedinice. Prije puštanja koda, programer mora osigurati da svi testovi prođu bez grešaka. Niko ne može dati kod osim ako svi ne prođu 100%. Drugim riječima, pošto su svi testovi prošli prije vaših promjena, ako imate greške, onda je to rezultat vaših promjena. Na vama je da to popravite. Ponekad je testni kod netačan ili nepotpun. U ovom slučaju, morate to ispraviti.

Veliko iskušenje je uštedjeti novac na jediničnim testovima kada je vremena kratko. Ali time samo sebe obmanjujete. Što je teže napisati test, to će kasnije uštedjeti više vremena. To je dokazano i praksom.

Jedinični testovi omogućavaju kolektivno vlasništvo nad kodom. Oni olakšavaju pregled lošeg koda. Jedinični testovi takođe vam omogućavaju da imate stabilan radni sistem u bilo kom trenutku.

Korisnička priča

Korisnička priča (nešto poput korisničke priče) je opis kako sistem treba da radi. Svaka korisnička priča je napisana na kartici i predstavlja neki dio funkcionalnosti sistema koji ima logičan smisao sa stanovišta Kupca. Forma - jedan ili dva pasusa teksta koji je razumljiv korisniku (ne baš tehnički).

Korisničku priču piše Kupac. Oni su slični slučajevima upotrebe sistema, ali nisu ograničeni na korisnički interfejs. Za svaku priču su napisani funkcionalni testovi kako bi se potvrdilo da je ova priča ispravno implementirana – nazivaju se i testovi prihvatanja.

Svaka korisnička priča ima prioritet sa poslovne strane (korisnik, kupac, odjel marketinga) i procjenu vremena izvršenja od strane programera. Svaka priča je podijeljena na zadatke i određeno vrijeme kada će početi da se provodi.

Korisničke priče se koriste u XP-u umjesto tradicionalnih zahtjeva. Glavna razlika između korisničke priče i zahtjeva je nivo detalja. Korisnička priča sadrži minimalne informacije potrebne za razumnu procjenu koliko će vremena biti potrebno za njenu implementaciju.

Tipična korisnička priča traje 1-3 sedmice idealnog vremena. Priča koja zahtijeva manje od jedne sedmice je previše detaljna. Priča za koju je potrebno više od 3 sedmice može se podijeliti na dijelove - zasebne priče.

Brzina projekta

Brzina projekta (ili jednostavno brzina) je mjera kojom se brzo završava rad na vašem projektu.

Da biste izmjerili brzinu projekta, jednostavno morate izbrojati količinu korisničkih priča ili koliko je (u vremenu) zadataka završeno po iteraciji. Samo izračunajte ukupno vrijeme za procjenu količine posla (idealno vrijeme).

Tokom planiranja izdanja, brzina projekta se koristi za procjenu koliko korisničkih priča može biti proizvedeno.

Tokom planiranja iteracije, brzina projekta u prethodnoj iteraciji se koristi za određivanje koliko korisničkih priča treba planirati u trenutnoj iteraciji.

Ovaj jednostavan mehanizam omogućava programerima da se oporave od teške iteracije. Ako i dalje imate slobodnog vremena nakon oporavka, idite do kupca i zatražite drugu korisničku priču. Kao rezultat toga, brzina će se ponovo povećati.

Nema potrebe da se ovaj parametar koristi kao apsolutni parametar. Nije pogodno za poređenje produktivnosti dva projekta, jer svaki tim ima svoje karakteristike. Ovaj parametar je bitan samo za tim da bi se održao na ravnoj kobilici.

Trebali biste očekivati ​​male promjene u brzini projekta dok radite. Ali ako se brzina značajno promijeni, potrebno je odgoditi puštanje. Čim novi sistem ide korisnicima, očekujte promjene u brzini projekta jer imate zadatke podrške.

Kada se otkrije greška

Ako se pronađe greška, kreira se test kako bi se spriječilo da se ponovi. Greška koja se javlja na proizvodnom sistemu (već instaliranom) zahteva pisanje funkcionalnog testa. Kreiranje funkcionalnog testa neposredno prije dijagnosticiranja greške omogućava korisnicima da jasno opišu problem i prenesu problem programerima.

Neuspjeli funkcionalni test zahtijeva kreiranje Jedinični test. Ovo pomaže u fokusiranju napora za otklanjanje grešaka i jasno ukazuje kada je greška ispravljena.

Neće ti trebati

Uzdržite se od punjenja sistema stvarima koje će vam trebati u budućnosti. Samo 10% onoga što ste očekivali će biti potrebno u svom originalnom obliku, što znači da će 90% vašeg vremena biti izgubljeno.

Uvijek postoji iskušenje da se funkcionalnost doda sada, a ne kasnije, jer vidimo kako to dodati sada i osjećamo da će sistem biti mnogo bolji. Ali uvijek se moramo podsjećati da nam to nikada neće trebati. Dodatna funkcionalnost samo usporava napredak i jede resurse. Zaboravite na buduće zahtjeve i dodatnu fleksibilnost. Koncentrišite se na ono što sada treba uraditi.

Temeljna ekonomska opravdanost za sve radnje - radi se samo ono što je potrebno kupcu i ne dovodi do neisplativosti projekta.

Formiranje osnovne arhitekture što je prije moguće.

Korištenje arhitekture komponenti.

Izrada prototipa, inkrementalni razvoj i testiranje.

Redovne procjene trenutnog stanja.

Upravljanje promjenama, stalni razvoj promjena izvan projekta.

Fokusirajte se na stvaranje proizvoda koji radi u stvarnom okruženju.

Fokusirajte se na kvalitet.

Prilagođavanje procesa potrebama projekta.

Ekstremno programiranje

Ekstremno programiranje (XP) nastao kao evolutivni metod razvoja softvera"dole gore". Ovaj pristup je primjer metode tzv„živi“ razvoj (metoda agilnog razvoja) . Grupa "živih" metoda uključuje, pored ekstremnog programiranja, metode SCRUM, DSDM (Dynamic Systems Development Method, metoda razvoja dinamičkih sistema), Funkcija-Driven Razvoj (razvoj vođen sistemskim funkcijama) itd.

Osnovni principi razvoja softvera uživo sadržani su u manifestu razvoja uživo, koji se pojavio 2000. godine.

Ljudi uključeni u projekat i njihova komunikacija važniji su od procesa i alata.

Program rada je važniji od sveobuhvatne dokumentacije.

Saradnja sa kupcem važnija je od razgovora o detaljima ugovora.

Raditi na promjenama važnije je od pridržavanja planova.

“Žive” metode su se pojavile kao protest protiv pretjerane birokratizacije razvoja softvera, obilja sporednih dokumenata koji nisu neophodni za postizanje konačnog rezultata, a koji se moraju izraditi prilikom izvođenja projekta u skladu s većinom “teških” procesa , dodatni rad za podršku fiksnog procesa organizacije, kao što je ovaj potreban unutar, na primjer, CMM. Većina ovakvih poslova i dokumenata nije direktno vezana za razvoj softvera i osiguranje kvaliteta, već je namijenjena usaglašavanju sa formalnim klauzulama razvojnih ugovora, pribavljanju i potvrđivanju certifikata o usklađenosti sa različitim standardima.

Metode „uživo“ omogućavaju programerima da usredsrede većinu svojih napora na razvojne zadatke i zadovoljavanje stvarnih potreba korisnika. Odsustvo gomile dokumenata i potreba da ih održavate u koherentnom stanju omogućavaju vam da brže i efikasnije odgovorite na promjene u zahtjevima i okruženju u kojem će budući program morati da radi.

Međutim, XP ima svoj vlastiti dijagram razvojnog procesa (iako je, općenito govoreći, široko korišteno razumijevanje „procesa razvoja“ kao prilično krute sheme djelovanja u suprotnosti sa samom idejom „živog“ razvoja), prikazano na Sl. 15.

Prema autorima XP-a, ova tehnika nije toliko praćenje nekih općih obrazaca djelovanja koliko korištenje kombinacije sljedećih tehnika. Međutim, svaka tehnika je važna, a bez njene upotrebe razvoj se smatra da nije XP, smatra Kent Beck, jedan od autora ovog pristupa, zajedno sa Wardom Cunninghamom i Ronom Jeffriesom.

Igra planiranja uživo

Njegov zadatak je da što brže odredi količinu posla koji treba obaviti prije sljedeće verzije softvera. Odluka se, prije svega, donosi na osnovu prioriteta kupca (tj. njegovih potreba, šta mu je potrebno od sistema za uspješniji

vođenje vašeg poslovanja) i, drugo, na osnovu tehničkih procjena (tj. procjene složenosti razvoja, kompatibilnosti sa drugim elementima sistema, itd.). Planovi se mijenjaju čim počnu odstupati od stvarnosti ili želja kupca.

				Test
		koristiti		scenariji
			Nova priča
	Zahtjevi		koristiti
			Brzina projekta
	Metafora		Plan verzije
		Planiranje		Iteracija	Prihvatanje	Mala
arhitektura				Last
						uredu
						korisnika
Nepouzdan			Samouvjereni	Nova iteracija

"Ubacivanje" rješenja

Slika 15. Dijagram toka rada u XP-u.

Česte promjene verzija (mala izdanja)

Prva radna verzija treba da se pojavi što je pre moguće i da se odmah počne koristiti. Naredne verzije se pripremaju u prilično kratkim intervalima (od nekoliko sati za male izmjene u malom programu, do mjesec ili dva za veće prerade velikog sistema).

Metafora sistema

Metafora, u prilično jednostavnoj i razumljivoj formi za tim, treba da opiše osnovni mehanizam sistema. Ovaj koncept podsjeća na arhitekturu, ali bi trebao opisati glavnu suštinu tehničkih odluka donesenih mnogo jednostavnije, u samo jednoj ili dvije fraze.

Jednostavno dizajnerska rješenja(jednostavan dizajn)

U svakom trenutku, sistem treba da bude dizajniran što jednostavnije. Nema potrebe za dodavanjem funkcija unaprijed - samo nakon eksplicitnog zahtjeva za to. Sva nepotrebna složenost se uklanja čim se otkrije.

Test Driven Development(razvoj vođen testom)

Programeri prvo pišu testove, a zatim pokušavaju implementirati svoje module kako bi testovi funkcionirali. Kupci unapred pišu testove koji demonstriraju glavne mogućnosti sistema kako bi mogli da vide da sistem zaista radi.

Kontinuirano refaktoriranje

Programeri stalno prerađuju sistem kako bi eliminisali nepotrebnu složenost, povećali razumljivost koda, povećali njegovu fleksibilnost, ali bez promjene njegovog ponašanja, što se potvrđuje pokretanjem nakon svake prerade testova. Pritom se prednost daje elegantnijim i fleksibilnijim rješenjima u odnosu na ona koja jednostavno daju željeni rezultat. Neuspješno redizajnirane komponente treba identificirati tokom izvođenja testa i vratiti ih u posljednje netaknuto stanje (zajedno sa komponentama koje zavise od njih).

Programiranje u paru

Kodiranje obavljaju dva programera na jednom računaru. Uparivanje je proizvoljno i varira od zadatka do zadatka. Onaj u čijim rukama tastatura pokušava da reši trenutni problem na najbolji način. Drugi programer analizira rad

prvo i daje savjete, razmatra posljedice određenih odluka, novih testova, manje direktnih, ali fleksibilnijih rješenja.

Kolektivno vlasništvo nad kodom

IN Svaki član tima može promijeniti bilo koji dio koda u bilo koje vrijeme. Niko ne bi trebao imati vlastito područje odgovornosti; cijeli tim u cjelini odgovoran je za sav kodeks.

Kontinuirana integracija

Sistem se sklapa i prolazi kroz integracijsko testiranje što je češće moguće, nekoliko puta dnevno, svaki put kada nekoliko programera završi implementaciju sljedeće funkcije.

Radna sedmica od 40 sati

Prekovremeni rad se smatra znakom većih problema u projektu. Prekovremeni rad 2 sedmice zaredom nije dozvoljen - to iscrpljuje programere i čini njihov rad znatno manje produktivnim.

Uključivanje kupca u tim(kupac na licu mjesta)

IN Razvojni tim uvijek uključuje predstavnika kupaca koji je dostupan tokom cijelog radnog dana i može odgovoriti na sva pitanja o sistemu. Njegova odgovornost je da ažurno odgovara na pitanja bilo koje vrste u vezi sa funkcijama sistema, njegovim interfejsom, potrebnim performansama, ispravnim radom sistema u teškim situacijama, potrebom održavanja komunikacije sa drugim aplikacijama itd.

Korištenje koda kao sredstva komunikacije

Kod se vidi kao najvažnije sredstvo komunikacije unutar tima. Jasnoća koda je jedan od glavnih prioriteta. Praćenje standarda kodiranja koji pružaju ovu jasnoću je imperativ. Takvi standardi, pored jasnoće koda, trebaju osigurati minimalan jezik (bez dupliranja koda i informacija) i trebali bi ih prihvatiti svi članovi tima.

Otvori radni prostor(otvoreni radni prostor)

Tim je smješten u jednoj prilično prostranoj prostoriji kako bi se olakšala komunikacija i omogućila grupna diskusija prilikom planiranja i donošenja važnih tehničkih odluka.

Promjena pravila po potrebi (samo pravila)

Svaki član tima mora prihvatiti navedena pravila, ali ako se ukaže potreba, tim ih može promijeniti ako se svi njegovi članovi slažu sa ovom promjenom.

Kao što se vidi iz tehnika koje se koriste, XP je dizajniran za upotrebu u malim timovima (ne više od 10 programera), što ističu i autori ove tehnike. Veća veličina tima uništava lakoću komunikacije neophodnu za uspjeh i onemogućava implementaciju mnogih od navedenih tehnika.

Prednosti XP-a, ukoliko se može implementirati, su veća fleksibilnost, mogućnost brzog i preciznog unošenja izmjena u softver kao odgovor na promjenjive zahtjeve i individualne želje kupaca, visok kvalitet rezultirajućeg koda i odsustvo potrebe za uvjeriti kupce da rezultat ispunjava njihova očekivanja.

Nedostaci ovog pristupa su neizvodljivost dovoljno velikih i složenih projekata u ovom stilu, nemogućnost planiranja vremena i složenosti projekta na dovoljno dug rok i jasnog predviđanja rezultata dugoročnog projekta u smislu omjera kvaliteta rezultata i troškova vremena i resursa. Također se može primijetiti da XP nije pogodan za one slučajeve u kojima se moguća rješenja ne pronalaze odmah na osnovu prethodno stečenog iskustva, već zahtijevaju preliminarno istraživanje

XP kao skup opisanih tehnika prvi put je korišćen tokom rada na projektu C3 (Chrysler Comprehensive Compensation System, razvoj sistema obračuna plaćanja

zaposlenici Daimler Chryslera). Od 20 učesnika u ovom projektu, njih 5 (uključujući i gore pomenuta 3 glavna autora XP-a) objavilo je 3 knjige i ogroman broj članaka posvećenih XP-u tokom samog projekta i kasnije. Ovaj projekat se više puta spominje u raznim izvorima kao primjer korištenja ove tehnike. Sljedeći podaci su sastavljeni iz spomenutih članaka, minus anegdotski dokazi, i ilustruju probleme s nekim XP tehnikama kada se primjenjuju na prilično složene projekte.

Projekat je započeo u januaru 1995. Od marta 1996. godine, nakon uključivanja Kenta Becka, koristi se XP. Do tada je već prevazišao budžet i planove za faznu implementaciju funkcija. Razvojni tim je skraćen, a nakon toga oko šest mjeseci projekat se prilično uspješno razvijao. U avgustu 1998. pojavio se prototip koji je mogao opsluživati ​​oko 10.000 zaposlenih. Prvobitno se očekivalo da će projekat biti završen sredinom 1999. godine, a nastali softver će se koristiti za upravljanje beneficijama za 87.000 zaposlenih u kompaniji. Zaustavljen je u februaru 2000. nakon 4 godine korištenja XP-a zbog potpunog neispunjavanja vremenskih okvira i budžeta. Napravljeni softver nikada nije korišćen za rad sa podacima o više od 10.000 zaposlenih, iako se pokazalo da može da obrađuje podatke o 30.000 zaposlenih u kompaniji. Osoba koja je imala ulogu naručioca uključenog u projektni tim dala je otkaz nakon nekoliko mjeseci takvog rada, ne mogavši ​​izdržati opterećenje, a do kraja projekta nikada nije dobila adekvatnu zamjenu.

Literatura za predavanje 3

W. Royce. Upravljanje softverskim projektima. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Jedinstveni proces razvoja softvera. Sankt Peterburg: Petar, 2002.

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

K. Beck. Ekstremno programiranje. Sankt Peterburg: Petar, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler ide u “Extremes”. Distributed Computing, 10/1998.

A. Cockburn. Odabir metodologije projekta. IEEE softver, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Jačanje razloga za programiranje u paru. IEEE softver 4/2000.

G. Keefer. Ekstremno programiranje se smatra štetnim za pouzdan razvoj softvera. AVOCA Technical Report, 2002.

Dostupno kao http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.