Pošaljite svoj dobar rad u bazu znanja je jednostavno. Upotrijebite obrazac u nastavku

Dobar posao na stranicu ">

Studenti, diplomanti, mladi znanstvenici koji koriste bazu znanja u svom studiju i radu bit će vam jako zahvalni.

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

Sadržaj

• Uvod
• 1. Što je XP?
• 3.1 Osnovne tehnikeXP
• 4. Prednosti i nedostaci
• 5. Povijest korištenja
• Zaključak

Uvod

Ekstremno programiranje, često nazivano XP, je softversko inženjerstvo i poslovna disciplina softvera koja usredotočuje programere i poslovne ljude na zajedničke, ostvarive ciljeve. XP timovi proizvode kvalitetan softver velikom brzinom. Tehnike koje su dio XP discipline odabrane su jer se temelje na ljudskoj kreativnosti i prihvaćanju da je osoba nestabilno stvorenje sklono pogreškama.

XP se često predstavlja kao skup tehnika, ali sam XP nije ciljna crta. Nije potrebno sve bolje vježbati i razvijati XP 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 proizvodna metodologija za male i srednje timove stručnjaka uključenih u razvoj softvera u okruženju nejasnih ili brzo promjenjivih zahtjeva.

1. Što je XP?

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

XP je pojednostavljen, učinkovit, fleksibilan, predvidljiv, znanstveno utemeljen i vrlo ugodan, niskorizičan način razvoja softvera. XP se razlikuje od ostalih tehnika na sljedeće načine:

Korištenjem iznimno kratkih razvojnih ciklusa, XP nudi brze, stvarne i trajne povratne informacije.

XP koristi inkrementalno planiranje, što rezultira prilično brzom pojavom cjelokupnog plana projekta, ali to implicira da se taj plan razvija tijekom trajanja projekta.

XP koristi fleksibilan vremenski okvir za isporuku funkcionalnosti za poboljšanje odziva na promjenjive tvrtke i zahtjeve kupaca.

XP se temelji na automatiziranim testovima koje su razvili i programeri i kupci. Zahvaljujući ovim testovima moguće je pratiti razvojni proces, osigurati ispravnu evoluciju sustava i odmah otkriti postojeće nedostatke u sustavu.

XP se temelji na usmenoj komunikaciji, testovima i izvornom kodu. Ova tri alata koriste se za razmjenu informacija o strukturi sustava i njegovom ponašanju.

XP se temelji na razvoju procesa dizajna koji traje koliko i sam sustav.

XP se temelji na bliskoj interakciji programera s najčešćim vještinama i sposobnostima.

XP se temelji na tehnikama koje zadovoljavaju i kratkoročne instinkte pojedinih programera i dugoročne interese projekta u cjelini.

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

XP tehnika je osmišljena za rad na projektima na kojima može raditi dva do deset programera koji nisu ograničeni krutim okvirom postojećeg računalnog okruženja i u kojem svi potrebnog posla povezano s testiranjem može se završiti u jednom danu.

2.Kako započeti ekstremno programiranje

Gdje počinje ekstremno programiranje? Uz shvaćanje da tipična pozicija domaćeg programera softvera obvezuje što je više moguće smanjiti troškove razvoja. A za to je potrebno intenzivno surađivati ​​s kupcem, razumjeti njegove interese i na kraju učiniti točno ono što želi: ni više ni manje.

Ekstremno programiranje ne temelji se na specifičnim tehnikama, kao što se obično vjeruje, već samo na četiri osnovna načela: komunikacija, jednostavnost, Povratne informacije i hrabrost. S njima morate početi.

Ekstremno programiranje nudi gotovo rješenje: neka sve bude što jednostavnije, zadržite kupca uz sebe ili se držite uz kupca sami, pustite ga da aktivno prati proces razvoja, pozdravite promjene - i uspjeh je gotovo zajamčen.

U XP timovima komunikacija je uvijek dobrodošla – najbrži način dijeljenja informacija i iskustva. Ovo je vrlo važno kada je potrebno maksimalna brzina razvoj. Ali komunikacija, kao i svaki drugi koristan pothvat, zahtijeva stalnu podršku. Zato netko iz tima mora preuzeti odgovornost za praćenje komunikacije, postajući takozvani diplomat. Komunikacija i potreba da ostalim članovima tima objasnite svoje postupke tjera vas da sve učinite što jednostavnije. Ako ne uspije prvi put, sve više rade na pojednostavljenju dok se to ne postigne glavni cilj- maksimalna razumljivost koda drugim programerima.

Što god da radimo – bilo da uvlačimo konac u iglu ili idemo na zabavu – uvijek težimo nekom cilju. Ako primijetimo da odstupamo od toga, onda prema tome prilagođavamo svoje postupke. Sada zamislite koliko je teže pogoditi iglu koncem. zatvorenih očiju ili se lijepo odjenuti bez ogledala! Ali kod razvoja programa to se često događa: radimo nešto, čiji rezultat nam nije vidljiv. Stoga je u ekstremnom programiranju pravilo što brže vidjeti rezultat svojih postupaka. Ili, tehnički govoreći, pružiti najbržu moguću povratnu informaciju.

Ekstremno programiranje nas pita: zašto ne kultivirati hrabrost? Uostalom, to je jako važno u radu. Je li moguće, bez hrabrosti, preuzeti odgovornost za provedbu zadatka, pa čak i unutar određenog vremenskog okvira? Je li moguće, bez hrabrosti, shvatiti da ste došli u slijepu ulicu, napraviti korak unatrag i tražiti rješenje? I, konačno, što će developeru omogućiti da prizna svoju pogrešku u procjeni zadatka i na vrijeme upozori druge na to, umjesto da ih suoči s činjenicom kada su svi rokovi istekli? Prednosti hrabrosti su očite, a svaki uspjeh, čak i u najmanjem zadatku, sposoban je razviti tu hrabrost.

3. XP Tehnike

Ekstremno programiranje (XP) pojavilo se kao evolucijska metoda razvoja softvera odozdo prema gore. Ovaj pristup je primjer takozvane metode agilnog razvoja. Skupina "živih" metoda uključuje, osim ekstremnog programiranja, metode SCRUM, DSDM (Dynamic Systems Development Method), Feature-Driven Development (razvoj kontroliran funkcijama sustava) itd.

Osnovni principi "živog" razvoja softvera zabilježeni su u "živom" razvojnom manifestu koji se pojavio 2000. godine.

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

· Radni program važniji je od opsežne dokumentacije.

· Suradnja s kupcem važnija je od pregovaranja o detaljima ugovora.

· Razrada promjena je važnija od praćenja planova.

"Žive" metode pojavile su se kao protest protiv pretjerane birokratizacije razvoja softvera, obilja popratnih dokumenata koji nisu potrebni za dobivanje konačnog rezultata, a koji se moraju izraditi tijekom projekta u skladu s većinom "teških" procesa, dodatnih rad na podršci fiksnom organizacijskom procesu, kao što je ovaj potreban u, na primjer, CMM-u. Većina takvih radova i dokumenata nije izravno povezana s razvojem softvera i osiguranjem kvalitete, već je namijenjena usklađivanju s formalnim klauzulama ugovora o razvoju, dobivanju i potvrđivanju certifikata o usklađenosti s različitim standardima.

Metode uživo omogućuju većinu napora programera da se usredotoče na stvarne razvojne zadatke i zadovoljavanje stvarnih potreba korisnika. Odsutnost hrpe dokumenata i potreba da ih održavate u koherentnom stanju omogućuje vam brži i učinkovitiji odgovor na promjene u zahtjevima iu okruženju u kojem će budući program morati raditi.

Ipak, XP ima svoj vlastiti dijagram razvojnog procesa (iako, općenito govoreći, široko korišteno shvaćanje "procesa razvoja" kao prilično krute sheme djelovanja proturječi samoj ideji "živosti" razvoja), prikazanom na slici 1. .

Prema autorima XP-a, ova tehnika nije toliko usmjerena na praćenje nekih opće sheme akcije, koliko primjena kombinacije sljedećih tehnika. Međutim, svaka tehnika je važna, a bez nje razvoj se smatra ne-XP-om, smatra Kent Beck, jedan od autora ovog pristupa zajedno s Wardom Cunninghamom i Ronom Jeffriesom.

· Uživoplaniranje (planiranjeigra)

Njegov je zadatak što brže odrediti količinu posla koji treba obaviti prije sljedeće verzije softvera. Odluka se donosi, prije svega, na temelju prioriteta kupca (tj. njegovih potreba, što mu je potrebno od sustava za uspješnije poslovanje) i, drugo, na temelju tehničke procjene(tj. procjene složenosti razvoja, kompatibilnosti s ostatkom sustava, itd.). Planovi se mijenjaju čim se počnu ne slagati sa stvarnošću ili željama kupca.

Riža.1 XP dijagram tijeka rada

· Čestopromijenitivverzija (maliizdanja)

Prva radna verzija trebala bi biti dostupna što je prije moguće i treba je odmah koristiti. Sljedeće verzije pripremaju se u prilično kratkim intervalima (od nekoliko sati s malim promjenama u malom programu, do mjesec-dva uz ozbiljnu obradu velikog sustava). Izdanja proizvoda trebaju se objavljivati ​​što je češće moguće. Rad na svakoj verziji trebao bi trajati što je manje moguće. Štoviše, svaka verzija treba biti dovoljno smislena sa stajališta korisnosti za poslovanje.

· Metafora (metafora) sustava

Metafora bi u prilično jednostavnom i razumljivom obliku za naredbu trebala opisati osnovni mehanizam sustava. Ovaj koncept podsjeća na arhitekturu, ali bi trebao biti puno jednostavniji, samo u obliku jedne ili dvije fraze, opisati glavnu bit usvojenih tehničkih rješenja.

Arhitektura je neko razumijevanje komponenti sustava i kako su one međusobno povezane. Programeri koriste arhitekturu kako bi razumjeli gdje je u sustavu dodana neka nova funkcionalnost i s čime će neka nova komponenta komunicirati.

Metafora sustava analogna je onome što većina tehnika naziva arhitekturom. Metafora sustava daje timu predodžbu o tome kako sustav trenutno radi, gdje se dodaju nove komponente i kakav oblik trebaju imati.

· Jednostavanoblikovatirješenja (jednostavanoblikovati)

U svakom trenutku, sustav bi trebao biti dizajniran što jednostavnije. Nema potrebe za dodavanjem funkcija unaprijed - tek nakon što se to izričito zatraži. Sva nepotrebna složenost uklanja se čim se pronađe.

XP polazi od činjenice da se u procesu rada uvjeti problema mogu više puta mijenjati, što znači da proizvod koji se razvija ne treba u potpunosti i potpuno projektirati unaprijed. Ako na samom početku svog rada pokušate detaljno osmisliti sustav od početka do kraja, gubite vrijeme. XP pretpostavlja da je dizajn toliko velik važan proces da se mora izvoditi stalno kroz cijelo vrijeme rada na projektu. Projektiranje treba provoditi u malim koracima, uzimajući u obzir zahtjeve koji se stalno mijenjaju. U svakom trenutku pokušavamo koristiti najjednostavniji dizajn koji odgovara trenutnom zadatku. Istodobno ga mijenjamo kako se mijenjaju uvjeti problema.

· Razvojnaosnovutestiranje (test- vođenrazvoj)

Programeri prvo pišu testove, a zatim pokušavaju implementirati svoje module kako bi testovi funkcionirali. Kupci unaprijed pišu testove koji pokazuju osnovne mogućnosti sustava kako bi mogli vidjeti da sustav stvarno radi.

U XP-u Posebna pažnja fokusira se na dvije vrste testiranja:

ispitivanje jedinica;

b testiranje prihvatljivosti.

softver za ekstremno programiranje

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

Testovi prihvaćanja osiguravaju da sustav doista radi onako kako se oglašava. Osim toga, testovi prihvaćanja omogućuju vam da provjerite ispravno funkcioniranje proizvoda koji se razvija.

Za XP, pristup koji se zove TDD (Test Driven Development) ima više prioriteta, prvo se napiše test koji ne prolazi, zatim se napiše kod kako bi test prošao, a nakon toga se kod refaktorira.

· Konstantnoobrada (refaktoriranje)

Nije tajna da dodavanje svake nove funkcionalnosti i rast koda komplicira razvoj, identificiranje pogrešaka i naknadne izmjene. Jedan od trikova ekstremnog programiranja je kompenzacija dodatka funkcionalnosti poboljšanjima koda. Ovo je prerada koda ili refaktoriranje.

Programeri neprestano prerađuju sustav kako bi eliminirali nepotrebnu složenost, povećali razumljivost koda, povećali njegovu fleksibilnost, ali bez promjena u njegovom ponašanju, što se provjerava izvođenjem nakon svake probne dorade. Istodobno, prednost se daje elegantnijim i fleksibilnijim rješenjima, u usporedbi s jednostavnim davanjem željeni rezultat... Neuspješno prerađene komponente trebale bi se otkriti tijekom izvođenja testa i vratiti u zadnje konzistentno stanje (zajedno s njihovim ovisnim komponentama).

Refaktoring je tehnika za poboljšanje koda bez promjene njegove funkcionalnosti. XP podrazumijeva da će se kod, jednom napisan, gotovo sigurno nekoliko puta prepisati tijekom projekta. XP programeri neumorno petljaju s prethodno napisanim kodom kako bi ga poboljšali. Taj se proces naziva refaktoring. Nedostatak pokrivenosti testom izaziva odbijanje refaktoriranja, zbog straha od razbijanja sustava, što dovodi do postupne degradacije koda.

· Programiranjeu parovima (parprogramiranje)

Iskusni programeri primijetili su da periodični pregled tuđeg koda ima pozitivan učinak na njegovu kvalitetu. Ekstremni majstori programiranja razvili su ovaj pristup: tijekom razvoja, kod se stalno revidira kroz tehniku ​​koja se naziva programiranje u paru.

Kodiranje rade dva programera na jednom računalu. Uparivanje je proizvoljno i razlikuje se od zadatka do zadatka. Onaj u čijim rukama tipkovnica pokušava najbolji način riješiti trenutni problem. Drugi programer analizira rad prvog i daje savjete, promišlja o posljedicama određenih odluka, novih testova, manje izravnih, ali fleksibilnijih rješenja. Ako je potrebno, tipkovnica se slobodno prenosi s jedne na drugu. Tijekom rada na projektu, parovi nisu fiksni: preporuča se miješati ih tako da svaki programer u timu dobro razumije cijeli sustav. Dakle, programiranje u paru poboljšava timsku komunikaciju.

· Kolektivnoposjedkodirati (kolektivnivlasništvo)

Kolektivno posjed znači da je svaki član tima odgovoran za cijeli izvorni kod. Dakle, svatko ima pravo mijenjati bilo koji dio programa. Programiranje u paru podržava ovu praksu: radeći u različitim parovima, svi programeri upoznaju se sa svim dijelovima koda sustava. Važna prednost zajedničkog vlasništva koda je da ubrzava proces razvoja, budući da kada dođe do greške, svaki programer je može popraviti.

Dajući svakom programeru pravo na promjenu koda, riskiramo pogreške koje unose programeri koji misle da znaju što rade, ali ne uzimaju u obzir neke ovisnosti. Dobro definirani UNIT testovi rješavaju ovaj problem: ako neadresirane ovisnosti generiraju pogreške, sljedeće izvođenje UNIT testova neće uspjeti.

· Konstantnointegracija (stalanintegracija)

Sustav se sklapa i testira za integraciju što je češće moguće, nekoliko puta dnevno, svaki put kada nekoliko programera završi implementaciju sljedeće funkcije.

Ako dovoljno često integrirate sustav u razvoju, možete izbjeći većinu povezanih problema. U tradicionalnim metodama integracija se obično izvodi na samom kraju rada na proizvodu, kada se smatra da su svi sastavni dijelovi sustava koji se razvija potpuno spremni. U XP-u se integracija koda u cijelom sustavu izvodi nekoliko puta dnevno, nakon što su se programeri uvjerili da svi testovi jedinica rade ispravno.

Unatoč svojoj jednostavnosti, ova tehnika ima svoja pravila korištenja, kao što su uspješnost postojećih jediničnih testova za integriranu funkcionalnost, prisutnost funkcionalnih ili testova prihvaćanja i, naravno, mogućnost vraćanja na prethodno stanje... Tipično, integraciju i rješavanje povezanih poteškoća na zasebnom računalu izvodi nekoliko programera. Time se smanjuje rizik od neželjenih posljedica integracije.

· 40 satiradećitjedan

Prekovremeni rad se smatra znakom velikih problema u projektu. Prekovremeni rad 2 tjedna za redom nije dopušten - to iscrpljuje programere i čini njihov rad mnogo manje produktivnim.

Osoba, pogotovo ako je programer, sposobna je za mnoge stvari zbog posla: ostati do kasno na poslu, otići na posao vikendom, odustati od godišnjeg odmora, ostati budan nekoliko dana sjedeći za tipkovnicom... Općenito , što ne možete učiniti zbog svoje omiljene aktivnosti. Ali ekstremno programiranje kategorički je protiv takvog samožrtvovanja i kršenja prihvaćenog zakona o radu.

To diktiraju ne samo zakonitost i humanost, već, prije svega, potreba poboljšanja učinkovitosti rada i stroge organizacije. Uostalom, ekstremno programiranje je kolektivna igra dizajnirana ne za pojedince, već za cijelu grupu u cjelini. A takvo što, na primjer, programiranje u paru moguće je samo kada se sinkroniziraju bioritmovi njegovih sudionika. A nemoguće ako jedna osoba dođe na posao do devet, a druga do dvanaest, ili jedna osoba odluči da joj je bolje da radi subotom i nedjeljom, dok je drugoj neugodno.

Ali najvažnije je da čovjek treba dobar odmor kako bi održao zdravlje i rad. Osmosatni radni dan i petodnevni radni tjedan postavljeni su upravo iz razloga maksimalne produktivnosti. U mnogim zapadnim tvrtkama kasno odlazak s posla smatra se lošim napretkom ili nesposobnošću pravilnog upravljanja svojim radnim vremenom. U većini slučajeva to je tako. A s medicinskog stajališta, kašnjenja na poslu dovode do stalnog umora, razdražljivosti i smanjene moždane aktivnosti. Je li djelotvorno? Kako u takvom timu organizirati stalnu otvorenu komunikaciju između programera i hoće li biti moguće programiranje u paru? Odgovor je negativan. Norme su norme i treba ih se pridržavati.

· Uključivanjekupacvnaredba (na- mjestokupac)

Glavni problem razvoja softvera je nedostatak znanja programera u razvijenom predmetnom području. Ekstremno programiranje pronašlo je izlaz i iz ove situacije. Ne, ovo nije praksa za razvojnog programera u poduzeću kupca - tada on neće htjeti programirati. Naprotiv, to je sudjelovanje kupca u procesu razvoja.

Razvojni tim uvijek uključuje predstavnika kupaca koji je dostupan tijekom cijelog radnog dana i u mogućnosti je odgovoriti na sva pitanja o sustavu. Njegova je odgovornost pružiti brze odgovore na pitanja bilo koje vrste u vezi s funkcijama sustava, njegovim sučeljem, potrebnim performansama, ispravan rad sustavi u teškim situacijama, potreba za komunikacijom s drugim aplikacijama itd.

Mnogi sumnjaju u mogućnost uključivanja kupca u proces razvoja. Doista, 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. Takav korak će smanjiti zbrku u radu, povećati brzinu razvoja i približiti projekt onome što kupac želi dobiti. To također može biti korisno s financijske točke gledišta: uostalom, plaća programera ponekad značajno premašuje plaću stručnjaka u drugim djelatnostima.

· Korištenjekodiratikakofondovikomunikacije

Kod se vidi kao najvažnije sredstvo komunikacije unutar tima. Jasnoća koda jedan je od naših glavnih prioriteta. Poštivanje standarda kodiranja koji pružaju ovu jasnoću je imperativ. Takvi standardi, osim jasnoće koda, moraju osigurati da se izrazi svedu na minimum (bez dupliciranja koda i informacija) i moraju ih prihvatiti svi članovi tima.

· Otvorenaradećiprostor (otvorenaradni prostor)

Tim je smješten u jednoj prostoriji koja je dovoljno velika da olakša komunikaciju i razmišljanje prilikom planiranja i donošenja važnih tehničkih odluka.

· Promjenapravilanapotreba (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 možete vidjeti iz korištenih tehnika, XP je dizajniran za korištenje 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 nužnu za uspjeh i onemogućuje mnoge od ovih tehnika.

3.1 Osnovni XP trikovi

Dvanaest osnovnih tehnika ekstremnog programiranja (temeljenih na prvom izdanju knjige Ekstremno programiranje objasnio) mogu se kombinirati u četiri skupine:

Fina povratna informacija

o Razvoj vođen testom

o Igra planiranja

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

o Programiranje u paru

Kontinuirani, a ne skupni proces

o Kontinuirana integracija

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

o Česta mala izdanja

Razumijevanje koje dijele svi

o Jednostavnost (jednostavan dizajn)

o Metafora sustava

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-satni radni tjedan (održivi tempo, četrdesetosatni tjedan)

Igravplaniranje

Naš je svijet previše promjenjiv i nepredvidiv da bismo se mogli osloniti na postojanost situacije. Isto se događa i s razvojem softvera: o rijedak sustav možemo reći da je njegov konačni oblik bio unaprijed potanko poznat na samom početku razvoja. Kupčev apetit obično dolazi s jelom: on stalno želi nešto promijeniti, poboljšati, a nešto sasvim izbaciti iz sustava. To je volatilnost zahtjeva kojih se svi toliko boje. Na sreću, osoba ima sposobnost predviđanja moguće opcije i tako držati situaciju pod kontrolom.

U ekstremnom programiranju planiranje je sastavni dio razvoja i činjenica da se planovi mogu mijenjati uzima se u obzir od samog početka. Igra planiranja je ta uporišta, tehnika koja vam omogućuje da predvidite situaciju i bezbolno podnosite promjene. U takvoj igri možete brzo prikupiti poznate zahtjeve sustava, procijeniti i planirati njihov razvoj prema prioritetu.

Kao i svaka druga igra, planiranje ima svoje sudionike i svoju svrhu. Ključni igrač je, naravno, kupac. On je taj koji obavještava o potrebi za ovom ili onom funkcionalnošću. Programeri, s druge strane, daju grubu procjenu svake funkcionalnosti. Ljepota igre planiranja leži u jedinstvu svrhe i solidarnosti između programera i kupca: ako pobijede, svi pobjeđuju, ako izgube, svi gube. No, u isto vrijeme, svaki sudionik ide svojim putem do pobjede: kupac odabire najvažnije zadatke u skladu s proračunom, a programer ocjenjuje zadatke u skladu sa svojim mogućnostima za njihovu provedbu.

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

U idealnoj situaciji, igra planiranja koja uključuje kupca i programera trebala bi se provoditi svakih 3-6 tjedana, prije početka sljedeće razvojne iteracije. To olakšava prilagodbe na temelju uspjeha i neuspjeha prethodne iteracije.

4. Prednosti i nedostaci

Vrline XP-a, ako se može primijeniti, su velika fleksibilnost, mogućnost brze i točne izmjene softvera kao odgovor na promjenjive zahtjeve i individualne želje kupaca, visoka kvaliteta rezultirajućeg koda i nedostatak treba uvjeriti kupce da rezultat ispunjava njihova očekivanja.

Nedostaci ovog pristupa su nemogućnost dosta 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 kvalitete rezultata i troškova vremena i resursa. Također se može primijetiti da XP nije prikladan za one slučajeve u kojima moguća rješenja nisu odmah temeljene na prethodnom iskustvu, već zahtijevaju preliminarno istraživanje.

5. Povijest korištenja

XP kao zbirka opisanih tehnika prvi je put korišten tijekom rada na projektu C3 (Chrysler Comprehensive Compensation System, razvoj sustava obračuna naknada zaposlenicima za Daimler Chrysler). Od 20 sudionika u ovom projektu, 5 (uključujući 3 glavna autora XP-a spomenuta gore) objavljeno je tijekom samog projekta i kasnije 3 knjige i velika količinačlanci o XP-u. Podaci u nastavku ilustriraju izazove nekih XP tehnika kada se primjenjuju na prilično složene projekte.

Projekt je započeo u siječnju 1995. godine. Od ožujka 1996., nakon uključivanja Kenta Becka, radio je koristeći XP. Do tada je već prešao proračun i planove za faznu provedbu funkcija. Razvojni tim je smanjen, a otprilike pola godine nakon toga projekt se prilično uspješno razvijao. U kolovozu 1998. pojavio se prototip koji je mogao opsluživati ​​oko 10.000 zaposlenika. Prvotno se očekivalo da će projekt biti dovršen sredinom 1999. godine, a dobiveni softver će se koristiti za upravljanje isplatama za 87.000 zaposlenika tvrtke. Zaustavljen je u veljači 2000. nakon 4 godine korištenja XP-a zbog potpunog nepoštivanja rokova i proračuna. Softver nikada nije korišten za rad s podacima o više od 10.000 zaposlenika, iako se pokazalo da se nosi s podacima 30.000 zaposlenika tvrtke. Osoba koja je igrala ulogu kupca uključenog u tim u projektu dala je otkaz nakon nekoliko mjeseci takvog rada, nesposobna izdržati opterećenje, te nije dobila adekvatnu zamjenu do kraja projekta.

Zaključak

Sve gore navedene metode spojene su s razlogom. Njihova dosljedna kombinacija sposobna je uvesti proces razvoja u intelektualnu rezonancu, značajno povećati kvalitetu proizvoda i približiti vrijeme njegovog izlaska. Glavna čar 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 poslu.

Mišljenja o predloženoj tehnici mogu se razlikovati. Važno je razumjeti da ekstremno programiranje nema za cilj zamijeniti postojeće tehnologije razvoj. Naprotiv, XP vam omogućuje da date dodatni zamah timovima koji koriste tradicionalne pristupe. Ne biste trebali tražiti odgovore na sva pitanja koja se ovdje pojavljuju. Ovo nije tehnologija programiranja, ali nego tehnologija organizaciju rada, te upravo u tom obliku ima pravo na život.

Objavljeno na Allbest.ru

Slični dokumenti

Analiza faza i značajki razvoja optimalnog i funkcionalnog ARIS modela – softverskog proizvoda tvrtke IDS Scheer za modeliranje poslovnih procesa tvrtke. Proučavanje temeljnih koncepata, metodologija i pristupa ekstremnog programiranja.

test, dodano 04.06.2011


Glavne faze razvoja softvera (softverski paket), analiza zahtjeva sustava. Detaljna metoda korak po korak. Programski jezici niske i visoke razine (imperativni, objektno orijentirani, funkcionalni, logički).

prezentacija dodana 13.10.2013


Razvojni jezik, implementacijsko okruženje, razvojni alati. Osobitosti virtualno okruženje implementacija programa i njihovo računovodstvo u razvoju softverskog proizvoda. Makronaredbe sustava 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 kontrole procesa razvoja programa i dokumentacije, sprječavanje pogrešaka. Faze procesa otklanjanja pogrešaka u softveru, tehnike strukturiranog programiranja i princip modularnosti.

prezentacija dodana 30.04.2014


Strojni kodovi i asembler. Prvi programski jezici visoke razine. Programski jezik FORTRAN. Prednosti i nedostaci ALGOL-a. Znanstveni i računovodstveni softver. Osnovni principi koji su se držali pri izradi Osnovnog programskog jezika.

seminarski rad dodan 21.06.2014


Koncept i ključna razlika razvoja distribuiranog softvera, njegove prednosti i nedostaci. Idejno rješenje i izbor vrste razvoja. Značajke softvera otvorenog koda. Open Source ideja i razvoj.

seminarski rad dodan 14.12.2012


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

prezentacija dodana 14.08.2013


Međunarodni standard na programski jezik Pascal. Tehnike objektno orijentiranog programiranja u Turbo Pascalu. Simboli jezika, njegova abeceda. Faze razvoja programa. Pojam algoritama i algoritama. Struktura programa u Pascalu.

seminarski rad, dodan 28.02.2010


Suvremeni alati za razvoj softvera za SUTP. Univerzalni programski jezici i njihova usporedba sa SCADA sustavima. Razvoj softvera pomoću višekanalnog mjerni pretvaračiŠ9327.

rad, dodan 13.07.2011


Osnovne tehnike rada u okolišu Delphi programiranje... Značajke tehnologije za izradu najjednostavnijih aplikacija. Rad s komponentama okruženja za razvoj aplikacija. Unos, uređivanje, odabir i izlaz informacija. Aspekti korištenja strukture grananja.

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

Igra planiranja

Naš je svijet previše promjenjiv i nepredvidiv da bismo se mogli osloniti na postojanost situacije. Isto se događa i u razvoju softvera: o rijetkom sustavu možemo reći da je njegov konačni izgled bio unaprijed do detalja poznat na samom početku razvoja. Kupčev apetit obično dolazi s jelom: on stalno želi nešto promijeniti, poboljšati, a nešto sasvim izbaciti iz sustava. To je volatilnost zahtjeva kojih se svi toliko boje. Na sreću, osoba ima sposobnost predviđanja mogućih opcija i na taj način držati situaciju pod kontrolom.
U ekstremnom programiranju planiranje je sastavni dio razvoja i činjenica da se planovi mogu mijenjati uzima se u obzir od samog početka. Igra planiranja je ta uporišta, tehnika koja vam omogućuje da predvidite situaciju i bezbolno podnosite promjene. U takvoj igri možete brzo prikupiti poznate zahtjeve sustava, procijeniti i planirati njihov razvoj prema prioritetu.
Kao i svaka druga igra, planiranje ima svoje sudionike i svoju svrhu. Ključni igrač je, naravno, kupac. On je taj koji obavještava o potrebi za ovom ili onom funkcionalnošću. Programeri, s druge strane, daju grubu procjenu svake funkcionalnosti. Ljepota igre planiranja leži u jedinstvu svrhe i solidarnosti između programera i kupca: ako pobijede, svi pobjeđuju, ako izgube, svi gube. No, u isto vrijeme, svaki sudionik ide svojim putem do pobjede: kupac odabire najvažnije zadatke u skladu s proračunom, a programer ocjenjuje zadatke u skladu sa svojim mogućnostima za njihovu provedbu.
Ekstremno programiranje pretpostavlja da programeri mogu sami odlučiti koliko će im vremena trebati da završe svoje zadatke i tko bi od njih bio spremniji riješiti jedan zadatak, a tko drugi.
U idealnoj situaciji, igra planiranja koja uključuje kupca i programera trebala bi se provoditi svakih 3-6 tjedana, prije početka sljedeće razvojne iteracije. To olakšava prilagodbe na temelju uspjeha i neuspjeha prethodne iteracije.

Plan izdanja

Plan izdanja definira datume izdanja i korisnički jezik koji će biti utjelovljeni u svakom izdanju. Na temelju toga možete odabrati tekst za sljedeću iteraciju. Testovi prihvaćanja izrađuju se tijekom iteracije i izvode se unutar te iteracije i svih sljedećih iteracija kako bi se osiguralo da program radi ispravno. Plan se može revidirati u slučaju značajnog zaostajanja ili prednosti nakon rezultata jedne od iteracija.
Iteracije. Iteracija čini razvojni proces dinamičnim. Ne morate planirati svoje programske zadatke dugo unaprijed. Umjesto toga, najbolje je održati sastanak o planiranju na početku svake iteracije. Ne biste trebali ni pokušavati provesti ono što nije planirano. Još ćete imati vremena za implementaciju ovih ideja kada su u pitanju prema planu izdavanja.
Ako se naviknete da ne dodajete funkcionalnost unaprijed i koristite izravno planiranje, lako se možete prilagoditi promjenjivim zahtjevima kupaca.

Planiranje ponavljanja

Planiranje iteracije počinje sastankom na početku svake iteracije kako bi se izradio plan koraka za rješavanje problema programiranja. Svaka iteracija trebala bi trajati između jednog i tri tjedna. Izjave unutar iteracije razvrstane su prema njihovoj važnosti za kupca. Dodatno se dodaju zadaci koji nisu mogli proći testove prihvaćanja i zahtijevaju reviziju. Formulacije i rezultati testa prevode se u softverske zadatke. Zadaci se bilježe na karticama koje čine detaljan plan ponavljanja. Za rješavanje svakog od zadataka potrebno je od jednog do tri dana. Zadaci koji traju manje od jednog dana mogu se grupirati, a veliki zadaci mogu se podijeliti u manje. Programeri procjenjuju zadatke i rokove za njihovo dovršenje. Za programera je vrlo važno postaviti točno vrijeme izvršenja zadatka. Možda će biti potrebno ponovno procijeniti neke od formulacija i revidirati plan izdanja nakon svaka tri ili pet iteracija - to je sasvim prihvatljivo. Ako prije svega implementirate najvažnija područja rada, tada ćete uvijek imati vremena učiniti maksimalno moguće za svoje klijente. Stil razvoja koji se temelji na slijedu iteracija poboljšava proces razvoja.

Sastanak stojeći

Svako jutro održava se sastanak na kojem se raspravlja o problemima, njihovim rješenjima i radi povećanja koncentracije tima. Sastanak se održava stojeći kako bi se izbjegle duge rasprave koje nisu zanimljive svim članovima tima.
U tipičnom sastanku većina sudionika ne pridonosi ništa, samo sudjeluju kako bi čuli što drugi imaju za reći. Veliki broj vrijeme ljudi se gubi da bi dobili malu količinu komunikacije. Stoga sudjelovanje svih ljudi na sastancima oduzima resurse projektu i stvara kaos u planiranju.
Za ovu vrstu komunikacije potreban je 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 na sve ostale sastanke trebaju dolaziti samo oni ljudi koji su potrebni i koji će donijeti nešto. Štoviše, moguće je čak i izbjeći neke sastanke. Uz ograničen broj sudionika, većina sastanaka može se održati spontano pred monitorom, gdje je razmjena ideja mnogo intenzivnija.
Dnevni jutarnji sastanak nije još jedno gubljenje vremena. To će vam uštedjeti mnoge druge sastanke i uštedjet će vam više vremena nego izgubljenog.

Jednostavnost

Jednostavni dizajn uvijek oduzima manje vremena od složenih dizajna. Stoga uvijek radite najjednostavnije stvari koje mogu funkcionirati. Uvijek je brže i jeftinije zamijeniti složeni kod odmah prije nego što provedete puno vremena radeći s njim. Neka stvari budu što jednostavnije bez dodavanja funkcionalnosti prije nego što se planira. Imajte na umu: Održavanje jednostavnog dizajna težak je posao.

Sustav metafora

Odabir sustava metafora potreban je kako bi se tim zadržao u istom okviru pri imenovanju klasa i metoda. Način na koji imenujete svoje objekte vrlo je važan za razumijevanje cjelokupnog dizajna sustava i ponovne upotrebe koda. Ako je programer u stanju točno predvidjeti kako će postojeći objekt, to dovodi do uštede vremena. Koristite sustav imenovanja za svoje objekte koji svatko može razumjeti bez posebnog znanja o sustavu.

Kupac na licu mjesta

Glavni problem razvoja softvera je nedostatak znanja programera u razvijenom predmetnom području. Ekstremno programiranje pronašlo je izlaz i iz ove situacije. Ne, ovo nije praksa za razvojnog programera u poduzeću kupca - tada on neće htjeti programirati. Naprotiv, to je sudjelovanje kupca u procesu razvoja.
Kako programer, a da nije temeljito razumio bit problema i da nije telepat, može pogoditi što kupac želi? Odgovor je očit. Najlakši način za prevladavanje te neugodnosti – a ekstremno nas programiranje uči pronalaženju najjednostavnijih rješenja – je da korisniku postavimo izravno pitanje. Rigorozniji pristupi zahtijevaju sveobuhvatnu preliminarnu analizu područja u razvoju. V određenim slučajevima opravdano je, iako je skuplje. Stvarno iskustvo u vođenju svakodnevnih projekata pokazuje da je nemoguće prikupiti sve zahtjeve unaprijed. Štoviše, čak i ako pretpostavimo da su svi zahtjevi u ovom trenutku prikupljeni, ipak će postojati jedno usko grlo: programi, kao i sve ostalo u prirodi, ne nastaju trenutno, a u međuvremenu se poslovni procesi mogu promijeniti. To treba uzeti u obzir.
Mnogi sumnjaju u mogućnost uključivanja kupca u proces razvoja. Doista, 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. Takav korak će smanjiti zbrku u radu, povećati brzinu razvoja i približiti projekt onome što kupac želi dobiti. To također može biti korisno s financijske točke gledišta: uostalom, plaća programera ponekad značajno premašuje plaću stručnjaka u drugim djelatnostima.
Korisnička priča. Korisnička priča (nešto poput korisničke priče) je opis kako bi sustav trebao raditi. Svaka korisnička priča ispisana je na kartici i predstavlja dio funkcionalnosti sustava koji ima logičan smisao sa stajališta Kupca. Napravite jedan ili dva odlomka teksta koji je razumljiv korisniku (ne baš tehnički).
Korisničku priču piše Kupac. Oni su slični slučajevima korištenja sustava, ali nisu ograničeni na njih korisničko sučelje... Za svaku priču su napisani funkcionalni testovi koji potvrđuju da je priča ispravno implementirana – nazivaju se i testovi prihvaćanja.

Testiranje prije razvoja

Testiranje je, u svom klasičnom smislu, prilično dosadan postupak. Obično se zapošljava tester 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 zanimljivija: sada je na prvom mjestu test, a zatim kod. Kako možete testirati nešto što još ne postoji? Odgovor je jednostavan i trivijalan: testirajte svoje misli - što očekivati ​​od budućeg softvera ili funkcionalnosti. To će vam omogućiti da bolje razumijete što programeri trebaju učiniti i provjeriti funkcionalnost koda čim je napisan.
Ali ni test možda neće raditi. Što, pisanje testa za test? I onda test za test i tako u nedogled? Nikako. Test za test će zamijeniti kod. Kako to? Ali pogledajte: zamislite da trebate popraviti maticu u sredini vijka tako da se ne okreće. Što oni rade za ovo? Drugu maticu pričvrstite blizu prve, tako da svaka matica spriječi okretanje susjedne matice. Tako 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. Uostalom, znajući što treba učiniti i potrebnu količinu posla uštedjet će vrijeme odbijanjem implementacije nezatraženog u ovaj trenutak detaljima.

Programiranje u paru

Sav kod za proizvodni sustav je napisan u parovima. Dva programera sjede jedan pored drugog. Jedan bira, drugi gleda. Oni se s vremena na vrijeme mijenjaju. Nije dopušteno raditi sam. Ako je iz nekog razloga drugi iz para nešto propustio (razbolio se, otišao, itd.), dužan je pregledati sve promjene koje je prvi napravio.
Zvuči neobično, ali nakon kratkog razdoblja prilagodbe većina ljudi izvrsno radi u paru. Čak im se sviđa jer se posao obavlja puno brže. Princip "Jedna glava je dobra, ali dvije su bolje." Parovi obično pronađu bolja rješenja. Osim toga, značajno se povećava kvaliteta koda, smanjuje broj pogrešaka i ubrzava se razmjena znanja među programerima. Dok se jedna osoba usredotočuje na strateški pogled na objekt, druga provodi njegova svojstva i metode.

Promjena pozicija

Tijekom sljedeće iteracije sve radnike treba preseliti na nova područja rada. Takvi su pokreti nužni kako bi se izbjegla izolacija znanja i eliminirali" 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 njihove module. Svaki programer može izmijeniti bilo koji kod kako bi proširio funkcionalnost i ispravio greške.
Na prvi pogled izgleda kao kaos. Međutim, uzimajući u obzir da je barem bilo koji kod kreiralo nekoliko programera, da testovi omogućuju provjeru ispravnosti unesenih promjena i da u stvaran život svejedno, na ovaj ili onaj način, morate razumjeti tuđi kod, postaje jasno da kolektivno vlasništvo nad kodom uvelike pojednostavljuje izmjene i smanjuje rizik povezan s visokom specijalizacijom jednog ili drugog člana tima.

Konvencija kodiranja

U timu ste koji već dugo radi na ovom projektu. Ljudi dolaze i odlaze. Nitko ne šifrira sam i šifra pripada svima. Uvijek će biti trenutaka kada će biti potrebno razumjeti i ispraviti tuđi kod. Programeri će ukloniti ili promijeniti duplicirani kod, analizirati i poboljšati tuđe klase itd. S vremenom se neće moći reći tko je autor pojedinog razreda.
Stoga se svi moraju pridržavati zajedničkih standarda kodiranja – formatiranje koda, imenovanje klasa, varijabli, konstante, stil komentara. Tako ćemo biti sigurni da izmjenama tuđeg koda (što je neophodno za agresivno i ekstremno kretanje naprijed) nećemo pretvoriti u babilonski Pandemonium.
Gore navedeno znači da se svi članovi tima moraju složiti oko zajedničkih standarda kodiranja. Nije važno što. Pravilo je da ih svi slušaju. Oni koji ih ne žele ispoštovati napuštaju tim.

Česta integracija

Programeri bi trebali integrirati i objaviti svoj kod svakih nekoliko sati kad god je to moguće. U svakom slučaju, promjene se ne smiju čuvati dulje 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. Svatko bi trebao raditi od najviše Najnovija verzija.
Svaki par programera trebao bi objaviti svoj kod čim se ukaže razumna prilika. Može biti kada svi UnitTest prođu 100%. Podnošenjem promjena nekoliko puta dnevno probleme s integracijom smanjujete gotovo na nulu. Integracija je aktivnost plati sada ili plati kasnije. Dakle, integracijom promjena svaki dan u malim dijelovima, nećete morati provesti tjedan dana povezujući sustav neposredno prije predaje projekta. Uvijek radite na najnovijoj verziji sustava.

Radni tjedan od četrdeset sati

Čovjek, pogotovo ako je programer, sposoban je za mnoge stvari radi posla: ostati do kasno na poslu, otići na posao vikendom, odustati od godišnjeg odmora, ostati budan nekoliko dana, sjediti za tipkovnicom... općenito, što ne možete učiniti zbog svoje omiljene aktivnosti. Ali ekstremno programiranje kategorički je protiv takvog samožrtvovanja i kršenja prihvaćenog zakona o radu.
To diktiraju ne samo zakonitost i humanost, već, prije svega, potreba poboljšanja učinkovitosti rada i stroge organizacije. Uostalom, ekstremno programiranje je kolektivna igra dizajnirana ne za pojedince, već za cijelu grupu u cjelini. A takvo što, na primjer, programiranje u paru moguće je samo kada se sinkroniziraju bioritmovi njegovih sudionika. A nemoguće ako jedna osoba dođe na posao do devet, a druga do dvanaest, ili jedna osoba odluči da joj je bolje da radi subotom i nedjeljom, dok je drugoj neugodno.
Ali najvažnije je da čovjek treba dobar odmor kako bi održao zdravlje i rad. Osmosatni radni dan i petodnevni radni tjedan postavljeni su upravo iz razloga maksimalne produktivnosti. U mnogim zapadnim tvrtkama kasno odlazak s posla smatra se lošim napretkom ili nesposobnošću pravilnog upravljanja svojim radnim vremenom. U većini slučajeva to je tako. A s medicinskog stajališta, kašnjenja na poslu dovode do stalnog umora, razdražljivosti i smanjene moždane aktivnosti. Je li djelotvorno? Kako u takvom timu organizirati stalnu otvorenu komunikaciju između programera i hoće li biti moguće programiranje u paru? Odgovor je negativan. Norme su norme i treba ih se pridržavati.

Zaključak

Ove tehnike su spojene s razlogom. Njihova dosljedna kombinacija sposobna je uvesti proces razvoja u intelektualnu rezonancu, značajno povećati kvalitetu proizvoda i približiti vrijeme njegovog izlaska. Glavna čar 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 poslu.

Bibliografija:

Ekstremno programiranje - ili skraćeno XP (ekstremno programiranje) - odgovor je programske zajednice na napad formalnih pristupa razvoju softvera i osmišljen je da vrati kreativnost zajednici programera.

Svaka ideja dovedena do apsurda degenerira se u vlastitu suprotnost. Upravo je takva situacija u sjevernoameričkoj softverskoj industriji RAD. U nekom trenutku, alati dizajnirani za brzi razvoj aplikacija počeli su zamjenjivati ​​sve ostalo u glavama menadžera, uključujući programere, kupce i sam projekt. Neopravdana, pretjerana pažnja prema Procesu na štetu drugih razvojnih čimbenika potaknula je mnoštvo formalnih postupaka - no kvaliteta dobivenih proizvoda i broj uspješnih projekata pokazali su se razočaravajućim.

Oduprijeti se pritisku formalizma u radu programera poziva se na inicijativu grupe programera, udruženih pod sloganom Extreme Programming ili XP.

U srcu ekstremnog programiranja nalazi se nekoliko vrlo specifičnih, često kvantificiranih principa koji definiraju što, kada i kako to učiniti. Iako ove brojke ne doživljavamo kao dogmu, ipak treba imati na umu da su se pojavili kao rezultat analize brojnih uspješnih i neuspješnih projekata, pa bi barem trebali postojati dobri razlozi za vlastite izmjene.

Ekstremno programiranje ne temelji se na specifičnim tehnikama, kako se obično vjeruje, već samo na četiri osnovna principa: komunikacija, jednostavnost, povratna informacija i hrabrost. S njima morate početi.

Ekstremno programiranje nudi gotovo rješenje: neka sve bude što jednostavnije, zadržite kupca uz sebe ili se držite uz kupca sami, pustite ga da aktivno prati proces razvoja, pozdravite promjene - i uspjeh je gotovo zajamčen.

U XP timovima komunikacija je uvijek dobrodošla – najbrži način dijeljenja informacija i iskustva. Ovo je vrlo važno kada je potrebna maksimalna brzina razvoja. Ali komunikacija, kao i svaki drugi koristan pothvat, zahtijeva stalnu podršku. Zato netko iz tima mora preuzeti odgovornost za praćenje komunikacije, postajući takozvani diplomat. Komunikacija i potreba da ostalim članovima tima objasnite svoje postupke tjera vas da sve učinite što jednostavnije. Ako ne uspije prvi put, rade na pojednostavljenju iznova i iznova dok se ne postigne glavni cilj – maksimalna razumljivost koda drugim programerima.

Ekstremni ciklus

Ekstremno programiranje temelji se na vrlo kratkom, ponavljajućem razvojnom ciklusu od jednog do tri tjedna. Do kraja svakog ciklusa trebalo bi postojati potpuno funkcionalno, funkcionalno i testirano izdanje aplikacije. Ti bi ciklusi trebali biti ponavljani i neprekinuti tijekom cijelog projekta.

Preduvjet za takav način rada je dokazana činjenica da su zahtjevi rijetko potpuni, pravovremeni i ispravni. Drugim riječima, bez obzira na to koliko je aplikacija dobro planirana, morat će se 100% redizajnirati. Štoviše, možda će se morati ponoviti čak i u završnoj fazi. Ne biste trebali odgađati doradu do kraja rada, morate ih redovito raditi.

Kao posljedica stalno promjenjivih zahtjeva slijedi još jedno načelo – kasno odlučivanje.

Ekstremno programiranje je metodologija za brzi razvoj softvera. Sastoji se od skupa tehnika i principa koji omogućuju, kako pojedinačno tako i u kompleksu, optimizaciju procesa razvoja. Ovaj pristup također regulira prava programera i kupaca.

Prava i uloge

U ekstremnom programiranju sve su uloge jasno opisane. Svaka uloga ima poseban skup prava i odgovornosti. Ovdje su dvije ključne uloge: kupac i programer.

kupac

Osoba ili skupina ljudi zainteresirani za stvaranje određenog softverskog proizvoda. Ima sljedeća prava i obveze:

• popraviti datume izdanja za verzije proizvoda;
• donosi odluke o planiranim komponentama programa;
• znati procijenjeni trošak svake funkcionalne komponente;
• donositi važne poslovne odluke;
• znati Trenutna država sustavi;
• promijeniti zahtjeve sustava kada je to stvarno važno.

Da bi uspješno ostvario svoja prava, korisnik se mora osloniti na podatke koje su dali programeri.

Programer

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

• steći dovoljno znanja o problemima koje treba programirati;
• biti u stanju razjasniti detalje tijekom procesa razvoja;
• dati indikativne, ali iskrene procjene troškova rada za svaki funkcionalni dio ili korisničku priču;
• prilagoditi procjene u korist točnijih u procesu razvoja;
• dati procjenu rizika povezanih s korištenjem specifičnih tehnologija.

Uloge unutar uloge

Svaka od osnovnih uloga ekstremnog programiranja može se dotjerati manjim ulogama. U XP-u je dopušteno kombinirati uloge unutar iste osobe.

Na strani kupca

Story maker- stručnjak za predmetno područje, koji ima sposobnost jasno navesti i opisati zahtjeve za sustav koji se razvija. Ova osoba ili grupa ljudi odgovorna je za pisanje korisničkih priča i otklanjanje nesporazuma od strane programera.

Prijamnik- osoba koja kontrolira ispravno funkcioniranje sustava. Dobra naredba predmetno područje... Odgovornosti uključuju pisanje testova prihvatljivosti.

Veliki šef- prati rad svih linkova, od programera do krajnjim korisnicima... Nadzire implementaciju sustava i povezana organizacijska pitanja. Može biti i investitor u projekt.

Strana programera

Programer- osoba uključena u kodiranje i dizajn na niskoj razini. Dovoljno je kompetentan da rješava aktualne razvojne probleme i daje istinite procjene planiranih zadataka.

Instruktor- iskusan programer koji dobro vlada cijelim razvojnim procesom i njegovim metodama. Odgovoran za podučavanje timskih aspekata razvojnog procesa. Provodi i kontrolira ispravnu provedbu metodologija korištenog procesa. Skreće pozornost tima na važne, ali iz nekog razloga propuštene razvojne točke. U isto vrijeme, instruktor, kao i svaka druga osoba, nije sveznajući i pažljiv prema idejama drugih članova tima.

Posmatrač je član razvojnog tima kojemu vjeruje cijela grupa i prati napredak razvoja. On uspoređuje preliminarne procjene troškovi rada i stvarno utrošeni, prikazujući kvantitativne pokazatelje rada tima. To su prosječna brzina i postotak dovršenih i planiranih zadataka. Ova informacija pružena kupcu radi pravodobne kontrole nad situacijom. Neke od tih informacija nenametljivo se daju programerima, kako bi znali u kakvom je stanju projekt, gdje se pojavljuju poteškoće i što se još može učiniti.

Diplomata- komunikativna osobnost, iniciranje komunikacije između članova tima. Budući da je tijek rada minimiziran, važna je stalna komunikacija i prijenos iskustva unutar tima, kao i bolje razumijevanje zahtjeva sustava. Diplomat regulira i pojednostavljuje komunikaciju između kupaca i programera. To je važna karika na sastancima. Sprječava nesporazume, vrhunac strasti i nepotrebne svađe. Diplomat ne može nametati svoje mišljenje debatantu.

Vanjske uloge

Konzultant- stručnjak sa specifičnim tehničkim vještinama za pomoć programerima u teškim zadacima. Obično privučen izvana.

Ekstremna pravila programiranja

Konvencija kodiranja

U timu ste koji već dugo radi na ovom projektu. Ljudi dolaze i odlaze. Nitko ne šifrira sam i šifra pripada svima. Uvijek će biti trenutaka kada će biti potrebno razumjeti i ispraviti tuđi kod. Programeri će ukloniti ili promijeniti duplicirani kod, analizirati i poboljšati tuđe klase itd. S vremenom se neće moći reći tko je autor pojedinog razreda.

Stoga se svi moraju pridržavati zajedničkih standarda kodiranja – formatiranje koda, imenovanje klasa, varijabli, konstante, stil komentara. Tako ćemo biti sigurni da izmjenama tuđeg koda (što je neophodno za agresivno i ekstremno kretanje naprijed) nećemo pretvoriti u babilonski Pandemonium.

Gore navedeno znači da se svi članovi tima moraju složiti oko zajedničkih standarda kodiranja. Nije važno što. Pravilo je da ih svi slušaju. Oni koji ih ne žele ispoštovati 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 njihove module. Svaki programer može promijeniti bilo koji kod kako bi proširio funkcionalnost, ispravio bugove ili refaktorirao.

Na prvi pogled izgleda kao kaos. Međutim, uzimajući u obzir da je barem bilo koji kod kreiralo nekoliko programera, da Unit testovi omogućuju provjeru ispravnosti unesenih promjena i 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 uvođenje promjena i smanjuje rizik povezan s visokom specijalizacijom jednog ili drugog člana tima.

CRC sjednica

Koristite kartice Class, Responsibilities, Collaboration (CRC) da dizajnirate sustav kao tim. Korištenje kartica olakšava navikavanje na razmišljanje u objektima, a ne na funkcije i procedure. Također kartice dopuštaju više ljudi sudjeluju u procesu dizajna (idealno, cijeli tim), a što više ljudi napravi dizajn, to više zanimljive ideje bit će doveden.

Svaka CRC kartica je instanca objekta. Klasa objekata može biti napisana na vrhu, odgovornosti lijevo, interakcije desno. Kažemo "može se napisati" jer kada je CRC sjednica u tijeku, sudionici to obično trebaju mali broj kartice s nazivima razreda i ne moraju biti potpuno ispunjene.

CRC sesija ide ovako: svaki od sudionika reproducira sustav govoreći koje poruke kojim objektima šalje. Prolazi kroz cijeli proces poruku po poruku. Slabe točke i problemi se odmah identificiraju. Alternative dizajna također su jasno vidljive u simulaciji procesa.

Da bi se stvari dovele u red, često se koristi ograničenje broja dvoje koji istovremeno djeluju.

kupac

Jedan od zahtjeva XP-a je da je kupac uvijek dostupan. Ne bi trebao samo pomoći razvojnom timu, već i biti njegov član. Sve faze XP projekta zahtijevaju komunikaciju s kupcem, najbolje licem u lice - na licu mjesta. Najbolje od svega, samo dodijelite jednog ili više klijenata razvojnom timu. Pazite, kupac će morati Dugo vrijeme, a ured klijenta vam može pokušati dati pripravnika kao stručnjaka. Potreban vam je stručnjak.

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

Prilikom planiranja izdanja, korisnik treba raspraviti izbor korisničkih priča koje će biti uključene u planirano izdanje. Možda će biti potrebno dogovoriti i razdoblje samog izdavanja. Kupac donosi odluke vezane uz ciljeve poslovanja.

Odaberite najjednostavnije rješenje

Jednostavni dizajn je uvijek lakši za implementaciju od složenih dizajna. Stoga uvijek napravite najjednostavnije rješenje koje može funkcionirati. Ako vam je nešto teško, zamijenite to nečim jednostavnim. Uvijek je brže i jeftinije zamijeniti složeni kod jednostavnim kodom prije nego što počnete razumjeti složeni kod.

Refaktor tuđi kod ako vam se čini kompliciranim. Ako nešto izgleda komplicirano, to je siguran znak problema u vašem kodu.

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

Funkcionalni testovi

Testovi prihvaćanja (prije su se nazivali i funkcionalni testovi) napisani su na temelju korisničke priče. Na sustav gledaju kao na crnu kutiju. Kupac je odgovoran za provjeru ispravnosti funkcionalnih testova. Ovi testovi se koriste za provjeru ispravnosti sustava prije nego što se pusti u proizvodnju. Funkcionalni testovi su automatizirani tako da ih možete često izvoditi. Rezultat se priopćava timu, a tim je odgovoran za zakazivanje popravaka funkcionalnih testova.

Česta integracija

Programeri bi trebali integrirati i objaviti svoj kod svakih nekoliko sati kad god je to moguće. U svakom slučaju, promjene se ne smiju čuvati dulje 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 raditi s najnovijom verzijom.

Svaki par programera trebao bi objaviti svoj kod čim postoji razumna prilika za to. To može biti kada svi UnitTestovi prođu 100%. Podnošenjem promjena nekoliko puta dnevno probleme s integracijom smanjujete gotovo na nulu. Integracija je aktivnost plati sada ili plati kasnije. Stoga, svakodnevnom integracijom promjena u malim obrocima, nećete morati potrošiti tjedan dana da povežete sustav u jednu cjelinu neposredno prije isporuke projekta. Uvijek radite na najnovijoj verziji sustava.

Za upravitelja. Ako programer ne pošalje promjene dulje od jednog dana, to je jasan pokazatelj ozbiljnog problema. Morate odmah shvatiti u čemu je stvar. Sva iskustva XP timova govore da je razlog kašnjenja uvijek loš dizajn i uvijek se mora naknadno prepravljati.

Planiranje iteracije

Sastanak planiranja iteracije saziva se prije početka svake iteracije kako bi se zakazali zadaci koji će se izvršiti u toj iteraciji. Za ponavljanje odabiru se korisničke priče koje je kupac odabrao plan oslobađanja počevši od najvažnijeg za kupca i najgoreg (povezanog s rizikom) za programere. Neradni funkcionalni testovi također su uključeni u iteraciju.

Korisničke priče i neuspjeli funkcionalni testovi raščlanjeni su na zadatke. Zadaci se bilježe na kartice. Ove kartice su detaljan plan za iteraciju. Svaki zadatak trebao bi trajati između 1 i 3 idealna dana.

Programeri rastavljaju zadatke i procjenjuju koliko je vremena potrebno za njihovo dovršavanje. Dakle, svaki programer procjenjuje koliko će mu zadatak trajati. Važno je da sam programer napravi konačnu procjenu opsega posla.

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 na 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 od korisničkih priča na dvije kako bi dio uključio u tekuću iteraciju.

Odgađanje korisničke priče za sljedeću iteraciju može izgledati zastrašujuće, ali nemojte si dopustiti da žrtvujete refaktoriranje i jedinične testove kako biste učinili više. Dug u ovim kategorijama brzo će usporiti vašu brzinu. Nemojte činiti ono što mislite da je potrebno u sljedećim iteracijama – učinite samo ono što je potrebno za dovršenje trenutnih korisničkih priča.

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

Iteracija

Iterativni razvoj povećava fleksibilnost procesa. Podijelite svoj plan na ponavljanja u trajanju od 2 do 3 tjedna. Održavajte konstantno trajanje ponavljanja tijekom trajanja projekta. Neka iteracija bude puls vašeg projekta. To je ritam koji će mjerenje napretka i planiranje učiniti jednostavnim i pouzdanim.

Nemojte unaprijed planirati zadatke. Umjesto toga prikupiti Planiranje iteracije na početku svake iteracije planirati što će se učiniti. Također se smatra kršenjem pravila trčati naprijed i raditi ono što nije planirano u ovoj iteraciji. Tako postaje moguće držati pod kontrolom promjenjive zahtjeve kupaca.

Ozbiljno shvatite rokove završetka iteracije. Mjerite napredak dok radite. Ako vidite da ne možete dovršiti sve zakazane zadatke do roka, ponovno prikupite Planiranje ponavljanja i ponovno procijenite zadatke i odgodite neke od zadataka.

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

Promijenite zadatke

Potrebno je povremeno 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 na određenom području i ta osoba ode, ili jednostavno imate puno posla u ovom segmentu programa, vidjet ćete da vaš projekt jedva napreduje.

Cross Training je obično važan aspekt u tvrtkama koje pokušavaju izbjeći koncentriranje znanja na jednu osobu. Premještanje ljudi po kodu u kombinaciji sa programiranje u paru diskretno pravi Cross Training za vas. Umjesto jedne osobe koja zna sve o određenom dijelu koda, svi u vašem timu znaju puno o kodu u svakom modulu.

Tim postaje mnogo fleksibilniji ako svi znaju dovoljno o svakom dijelu sustava da počnu raditi na njemu. Umjesto čekanja da "guru" završi s radom na kritičnom dijelu koda, više programera može raditi na njemu u isto vrijeme.

Prilikom pokretanja novog iteracije svaki programer bi trebao ići novi zadatak... Uparivanje pomaže u prevladavanju problema prilagodbe (što znači da se novi programer može upariti s iskusnim programerom na terenu).

Ova praksa također potiče nove ideje i poboljšanja koda.

Spremi optimizaciju za kasnije

Nikada nemojte ništa optimizirati prije nego što završite s kodiranjem. Nikad ne pokušavajte pogoditi gdje će biti uska grla u izvedbi. Mjera!

Učinite to uspješnim, zatim ispravite, a zatim učinite to brzo.

Programiranje u paru

Sav kod za proizvodni sustav (što znači isključivanje probnih rješenja) je napisan u parovima. Dva programera sjede jedan pored drugog. Jedan bira, drugi gleda. Oni se s vremena na vrijeme mijenjaju. Nije dopušteno raditi sam. Ako je iz nekog razloga drugi iz para nešto propustio (razbolio se, otišao, itd.), dužan je pregledati sve promjene koje je prvi napravio.

Zvuči neobično, ali XP tvrdi da nakon kratkog razdoblja prilagodbe većina ljudi dobro radi u paru. Čak im se sviđa jer se posao obavlja puno brže. Vrijedi princip “Jedna glava je dobra, a dvije su bolje”. Parovi obično pronađu bolja rješenja. Osim toga, značajno se povećava kvaliteta koda, smanjuje broj pogrešaka i ubrzava se razmjena znanja među programerima.

Nemilosrdno refaktorirajte!

Mi programeri skloni smo se držati dizajna dugo nakon što postane neugodan. Nastavljamo ponovno koristiti nezgrapan kod jer još uvijek nekako funkcionira i bojimo se da ga zabrljamo. Ali je li to stvarno korisno? XP smatra da nije isplativ. Kada uklonimo suvišnost, poboljšamo zastarjeli dizajn, uklonimo neiskorištene dijelove - refaktoriramo. Refaktoriranje u konačnici štedi vrijeme i poboljšava kvalitetu proizvoda.

Nemilosrdno revidirajte bilo koji kod kako bi dizajn bio jednostavan dok razvijate. Neka vaš kod bude jasan i razumljiv kako bi ga bilo lako razumjeti, modificirati i proširiti. Provjerite je li sve napisano jednom i samo jednom. U konačnici, potrebno je manje vremena od podešavanja zamršenog sustava.

Plan izdanja

Plan puštanja u promet izrađuje se na sastanku planiranja izdavanja. Planovi izdanja opisuju prikaz cijelog projekta 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ćuju svakome da donosi vlastite odluke. Ova pravila definiraju metodu za izradu plana rada koji zadovoljava sve.

Bit sastanka za planiranje izdanja za razvojni tim je procijeniti svaku korisničku priču u idealnim tjednima. Idealan tjedan je koliko dugo mislite da će vam trebati da dovršite zadatak ako vas više ništa ne ometa. Bez ovisnosti, bez dodatnih zadataka, ali uključujući testove. Kupac tada odlučuje koji su zadaci najvažniji ili imaju veći prioritet.

Korisničke priče se snimaju na kartice. Programeri i korisnik miješaju karte zajedno na stolu dok ne dobiju skup korisničkih priča, koje će zajedno činiti prvo (ili sljedeće) izdanje. Svatko želi objaviti koristan sustav koji se može testirati što je prije moguće.

Izdanje se može zakazati prema vremenu ili volumenu. Kako bi se odredilo koliko se korisničkih priča može implementirati do određenog datuma ili koliko dugo će određeni skup zadataka trajati u stvarnom vremenu, koristi se brzina projekta. Ako planirate na vrijeme, pomnožite broj iteracija sa brzinom projekta kako biste saznali koliko se korisničkih priča može implementirati. Kada planirate po volumenu, podijelite ukupan broj idealnih tjedana potrebnih za sve korisničke priče s brzinom projekta i dobit ćete broj iteracija potrebnih za dovršetak izdanja.

Ako menadžment nije zadovoljan rokom za završetak, može biti primamljivo smanjiti procjene opsega. Ovo nikada ne biste trebali raditi. Podcijenjene ocjene će kasnije stvoriti mnogo problema. Umjesto toga, pregovarajte s menadžerima, programerima i kupcima dok ne dobijete prihvatljiv plan izdanja za sve.

Česta izdanja

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

Planiranje izdanja služi za pronalaženje malih funkcionalnih fragmenata koji imaju značajan poslovni smisao i koji se mogu pustiti u stvarno okruženje u ranim fazama razvoja. Važno je primiti na vrijeme korisne kritike kako bi mogli utjecati na razvojni proces. Što više odgađate objavljivanje važnog dijela sustava, manje ćete vremena imati da ga popravite.

Probno rješenje

Stvorite probna rješenja za složene odgovore tehnički problemi, opravdati određena tehnološka rješenja. U svakoj tehnološkoj odluci postoji rizik, a odluke o ispitivanju osmišljene su da ga ublaže.

Napravite program koji reproducira problem koji se istražuje i zanemaruje sve ostalo. Većina probnih rješenja nije namijenjena za buduću upotrebu, stoga očekujte da će se baciti. Svrha njihovog stvaranja je smanjiti rizik od prihvaćanja krivog tehničko rješenje ili točniju procjenu vremena za implementaciju korisničke priče.

Sastanak stojeći

Svako jutro održava se sastanak na kojem se raspravlja o problemima, njihovim rješenjima i radi povećanja koncentracije tima. Sastanak se održava stojeći kako bi se izbjegle duge rasprave koje nisu zanimljive svim članovima tima.

U tipičnom sastanku većina sudionika ne pridonosi ništa, samo sudjeluju kako bi čuli što drugi imaju za reći. Mnogo ljudi troši vrijeme da bi dobili malu količinu komunikacije. Stoga sudjelovanje svih ljudi na sastancima oduzima resurse projektu i stvara kaos u planiranju.

Za ovu vrstu komunikacije potreban je 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 na sve ostale sastanke trebaju dolaziti samo oni ljudi koji su potrebni i koji će donijeti nešto. Štoviše, moguće je čak i izbjeći neke sastanke. Uz ograničen broj sudionika, većina sastanaka može se održati spontano pred monitorom, gdje je razmjena ideja mnogo intenzivnija.

Dnevni jutarnji sastanak nije još jedno gubljenje vremena. To će vam uštedjeti mnoge druge sastanke i uštedjet će vam više vremena nego izgubljenog.

Metafora sustava

Uvijek odaberite Metaforu sustava - jednostavan i jasan koncept za članove tima da sve stvari nazivaju istim imenom. Za razumijevanje sustava i izbjegavanje dupliciranja koda, iznimno je važno kako nazivate objekte. Ako možete pogoditi kako se zove bilo koji objekt u sustavu (ako znate što radi) i stvarno se tako zove - uštedjet ćete puno vremena i truda. Napravite sustav imenovanja za svoje objekte tako da ga svi u timu mogu koristiti bez posebnog znanja o sustavu.

Jedinični testovi

Jedinični testovi igraju ključnu ulogu u XP-u. Omogućuju vam brzu promjenu koda bez straha od novih pogrešaka. Jedinični test je napisan za svaki razred, test treba provjeriti sve aspekte rada razreda - testirati sve što možda neće raditi.

Trik je u tome što test za klasu mora biti napisan prije samog razreda. To znači da će čim objavite prvi radni rezultat, on će biti podržan od strane sustava testiranja. Za provođenje testova napišite poseban sustav testiranje s vlastitim sučeljem.

Jedinični test za klasu pohranjen je u zajedničkom spremištu zajedno s kodom klase. Nijedan kod se ne može objaviti bez testa jedinice. Prije slanja koda, programer mora osigurati da svi testovi prođu bez grešaka. Nitko ne može dati šifru ako svi nisu prošli 100%. Drugim riječima, budući da su svi testovi prošli prije vaših promjena, ako imate greške, onda je to rezultat vaših promjena. Ti i popraviti. Ponekad je testni kod netočan ili nepotpun. U ovom slučaju, morate to ispraviti.

Veliko je iskušenje uštedjeti novac na jediničnim testovima kada je vremena kratko. Ali ovim 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ćuju zajedničko vlasništvo nad kodom. Oni olakšavaju reviziju lošeg koda. Također, testovi jedinica omogućuju vam da imate stabilan radni sustav u bilo kojem trenutku.

Korisnička priča

Korisnička priča (nešto poput korisničke priče) je opis kako bi sustav trebao raditi. Svaka korisnička priča ispisana je na kartici i predstavlja dio funkcionalnosti sustava koji ima logičan smisao sa stajališta Kupca. Forma - jedan ili dva odlomka teksta koji je razumljiv korisniku (ne baš tehnički).

Korisničku priču piše Kupac. Oni su slični slučajevima korištenja sustava, ali nisu ograničeni na korisničko sučelje. Za svaku priču su napisani funkcionalni testovi koji potvrđuju da je priča ispravno implementirana – nazivaju se i testovi prihvaćanja.

Svakoj korisničkoj priči tvrtka (korisnik, kupac, marketing) daje prioritet, a programeri procjenjuju vrijeme isporuke. Svaka priča je raščlanjena na zadatke i dodijeljeno joj je vrijeme kada će se početi provoditi.

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

Tipična korisnička priča traje 1-3 tjedna idealnog vremena. Priča koja zahtijeva manje od tjedan dana je previše detaljna. Priča koja zahtijeva više od 3 tjedna može se podijeliti na dijelove - zasebne priče.

Brzina projekta

Brzina projekta (ili jednostavno brzina) mjera je koliko brzo se posao obavlja u vašem projektu.

Da biste izmjerili brzinu projekta, jednostavno morate izračunati veličinu korisničkih priča ili koliko je (u vremenu) zadataka dovršeno u iteraciji. Samo izračunajte ukupno vrijeme za procjenu obima posla (idealno vrijeme).

Tijekom planiranja izdanja, brzina projekta se koristi za procjenu koliko se korisničkih priča može proizvesti.

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

Ovaj jednostavan mehanizam omogućuje programerima da se oporave od teške iteracije. Ako imate slobodnog vremena nakon oporavka, otiđite do kupca i zatražite više User Story. Kao rezultat toga, brzina će se ponovno povećati.

Nemojte koristiti ovaj parametar kao apsolutni. Nije prikladno za usporedbu produktivnosti dva projekta, jer svaki tim ima svoje karakteristike. Ovaj je parametar važan samo za momčad kako bi se držao na "ravnoj kobilici".

Trebali biste očekivati ​​male promjene u brzini projekta tijekom rada. Ali ako se brzina jako promijeni, morate ponovno zakazati izdanje. Jednom novi sustav ide korisnicima, očekujte promjenu u brzini projekta, jer ćete imati zadatke podrške.

Kada se pronađe greška

Ako se pronađe pogreška, kreira se test kako bi se spriječilo da se ponovi. Pogreška koja se pojavi na proizvodnom sustavu (već instaliranom) zahtijeva pisanje funkcionalnog testa. Izrada funkcionalnog testa neposredno prije dijagnosticiranja greške omogućuje korisnicima da jasno opišu problem i prenesu problem programerima.

Neuspjeli funkcionalni test zahtijeva kreiranje Jedinični test... To pomaže usredotočiti napore za otklanjanje pogrešaka i jasno pokazuje kada je bug ispravljen.

Ne treba ti

Suzdržite se od punjenja sustava stvarima koje će vam trebati u budućnosti. Samo 10% onoga što očekujete bit će zapravo potrebno u izvornom obliku, odnosno 90% vašeg vremena bit će izgubljeno.

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

Temeljito ekonomsko opravdanje svih radnji - radi se samo ono što je potrebno kupcu i ne dovodi do mana 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.

Usredotočite se na stvaranje proizvoda koji radi u stvarnom okruženju.

Posvećenost kvaliteti.

Prilagodba procesa potrebama projekta.

Ekstremno programiranje

Ekstremno programiranje (XP) nastao kao evolucijska metoda razvoja softvera"gore". Ovaj pristup je primjer metode tzv Razvoj "uživo" (metoda agilnog razvoja) ... Skupina "živih" metoda uključuje, osim ekstremnog programiranja, metode SCRUM, DSDM (Dynamic Systems Development Method), Pokrenut značajkama Razvoj (razvoj kontroliran funkcijama sustava) itd.

Osnovni principi "živog" razvoja softvera zabilježeni su u "živom" razvojnom manifestu koji se pojavio 2000. godine.

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

Radni program važniji je od opsežne dokumentacije.

Suradnja s kupcem važnija je od pregovaranja o detaljima ugovora.

Razraditi promjene važnije je nego slijediti planove.

"Žive" metode pojavile su se kao protest protiv pretjerane birokratizacije razvoja softvera, obilja popratnih dokumenata koji nisu potrebni za dobivanje konačnog rezultata, a koji se moraju izraditi tijekom projekta u skladu s većinom "teških" procesa, dodatnih rad na podršci fiksnom organizacijskom procesu, kao što je ovaj potreban u, na primjer, CMM-u. Većina takvih radova i dokumenata nije izravno povezana s razvojem softvera i osiguranjem kvalitete, već je namijenjena usklađivanju s formalnim klauzulama ugovora o razvoju, dobivanju i potvrđivanju certifikata o usklađenosti s različitim standardima.

Metode uživo omogućuju većinu napora programera da se usredotoče na stvarne razvojne zadatke i zadovoljavanje stvarnih potreba korisnika. Odsutnost hrpe dokumenata i potreba da ih održavate u koherentnom stanju omogućuje vam brži i učinkovitiji odgovor na promjene u zahtjevima iu okruženju u kojem će budući program morati raditi.

Ipak, XP ima svoj vlastiti dijagram razvojnog procesa (iako, općenito govoreći, široko korišteno shvaćanje "procesa razvoja" kao prilično krute sheme djelovanja proturječi samoj ideji "živosti" razvoja), prikazanom na Sl. 15.

Prema autorima XP-a, ova tehnika nije toliko praćenje neke opće sheme radnji koliko korištenje kombinacije sljedećih tehnika. Međutim, svaka tehnika je važna, a bez nje razvoj se smatra ne-XP, smatra Kent Beck, jedan od autora ovog pristupa, zajedno s Wardom Cunninghamom i Ronom Jeffriesom.

Igra planiranja

Njegov je zadatak što brže odrediti količinu posla koji treba obaviti prije sljedeće verzije softvera. Odluka se prije svega donosi na temelju prioriteta kupca (tj. njegovih potreba, što mu je potrebno od sustava za uspješniji rad).

vođenje vašeg poslovanja) i, drugo, na temelju tehničkih procjena (tj. procjene složenosti razvoja, kompatibilnosti s drugim elementima sustava itd.). Planovi se mijenjaju čim se počnu ne slagati sa stvarnošću ili željama kupca.

				Test
		korištenje		skripte
			Nova priča
	Zahtjevi		korištenje
			Brzina projekta
	Metafora		Plan verzije
		Planiranje		Iteracija	Primanje	Mali
arhitektura				Zadnji
						u redu
						korisnika
Nepouzdan			Uvjeren	Nova iteracija

"Ubacivanje" rješenja

Slika 15. Dijagram toka rada u XP-u.

Česte promjene verzija (mala izdanja)

Prva radna verzija trebala bi biti dostupna što je prije moguće i treba je odmah koristiti. Sljedeće verzije pripremaju se u prilično kratkim intervalima (od nekoliko sati s malim promjenama u malom programu, do mjesec ili dva s velikim remontom velikog sustava).

Metafora sustava

Metafora bi u prilično jednostavnom i razumljivom obliku za naredbu trebala opisati osnovni mehanizam sustava. Ovaj koncept podsjeća na arhitekturu, ali bi trebao biti puno jednostavniji, samo u obliku jedne ili dvije fraze, opisati glavnu bit usvojenih tehničkih rješenja.

Jednostavan dizajnerska rješenja(jednostavan dizajn)

U svakom trenutku, sustav bi trebao biti dizajniran što jednostavnije. Nema potrebe za dodavanjem funkcija unaprijed - tek nakon što se to izričito zatraži. Sva nepotrebna složenost uklanja se čim se pronađe.

Razvoj vođen testom(razvoj vođen testom)

Programeri prvo pišu testove, a zatim pokušavaju implementirati svoje module kako bi testovi funkcionirali. Kupci unaprijed pišu testove koji pokazuju osnovne mogućnosti sustava kako bi mogli vidjeti da sustav stvarno radi.

Refaktoring

Programeri neprestano prerađuju sustav kako bi eliminirali nepotrebnu složenost, povećali razumljivost koda, povećali njegovu fleksibilnost, ali bez promjena u njegovom ponašanju, što se provjerava izvođenjem nakon svake probne dorade. Istodobno, prednost se daje elegantnijim i fleksibilnijim rješenjima, u usporedbi s jednostavnim davanjem željenog rezultata. Neuspješno prerađene komponente trebale bi se otkriti tijekom izvođenja testa i vratiti u zadnje konzistentno stanje (zajedno s njihovim ovisnim komponentama).

Programiranje u paru

Kodiranje rade dva programera na jednom računalu. Uparivanje je proizvoljno i razlikuje se od zadatka do zadatka. Onaj u čijim rukama tipkovnica pokušava na najbolji način riješiti trenutni problem. Drugi programer analizira rad

prvi i daje savjete, promišlja o posljedicama određenih odluka, novih testova, manje izravnih, ali fleksibilnijih rješenja.

Kolektivno vlasništvo

V bilo kada bilo koji član tima može promijeniti bilo koji dio koda. Nitko ne bi trebao imati svoje područje odgovornosti, cijeli tim je općenito odgovoran za sav kod.

Kontinuirana integracija

Sustav se sklapa i testira za integraciju što je češće moguće, nekoliko puta dnevno, svaki put kada nekoliko programera završi implementaciju sljedeće funkcije.

40-satni radni tjedan

Prekovremeni rad se smatra znakom velikih problema u projektu. Prekovremeni rad 2 tjedna za redom nije dopušten - to iscrpljuje programere i čini njihov rad mnogo manje produktivnim.

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

V Razvojni tim uvijek ima predstavnika kupaca koji je dostupan tijekom cijelog radnog dana i u mogućnosti je odgovoriti na sva pitanja o sustavu. Njegova je odgovornost pružiti brze odgovore na pitanja bilo koje vrste o funkcijama sustava, njegovom sučelju, potrebnim performansama, ispravnom radu sustava u teškim situacijama, potrebi održavanja komunikacije s drugim aplikacijama itd.

Korištenje koda kao sredstva komunikacije

Kod se vidi kao najvažnije sredstvo komunikacije unutar tima. Jasnoća koda jedan je od naših glavnih prioriteta. Poštivanje standarda kodiranja koji pružaju ovu jasnoću je imperativ. Takvi standardi, osim jasnoće koda, moraju osigurati da se izrazi svedu na minimum (bez dupliciranja koda i informacija) i moraju ih prihvatiti svi članovi tima.

Otvorena radni prostor(otvoreni radni prostor)

Tim je smješten u jednoj prostoriji koja je dovoljno velika da olakša komunikaciju i razmišljanje 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 s tom promjenom.

Kao što možete vidjeti iz korištenih tehnika, XP je dizajniran za korištenje 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 nužnu za uspjeh i onemogućuje mnoge od ovih tehnika.

Vrline XP-a, ako se može primijeniti, su velika fleksibilnost, mogućnost brze i točne izmjene softvera kao odgovor na promjenjive zahtjeve i individualne želje kupaca, visoka kvaliteta rezultirajućeg koda i nedostatak treba uvjeriti kupce da rezultat ispunjava njihova očekivanja.

Nedostaci ovog pristupa su nemogućnost dosta 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 kvalitete rezultata i troškova vremena i resursa. Također se može primijetiti da XP nije prikladan za one slučajeve u kojima se moguća rješenja ne pronalaze odmah na temelju prethodnog iskustva, već zahtijevaju preliminarno istraživanje.

XP kao kombinacija opisanih tehnika prvi je put korišten tijekom rada na projektu C3 (Chrysler Comprehensive Compensation System, razvoj sustava obračuna plaćanja

zaposlenici Daimler Chryslera). Od 20 sudionika u ovom projektu, njih 5 (uključujući 3 glavna autora XP-a spomenuta gore) objavilo je 3 knjige i ogroman broj članaka o XP-u tijekom samog projekta i kasnije. Ovaj je projekt više puta spominjan u raznim izvorima kao primjer korištenja ove tehnike. Podaci u nastavku sastavljeni su iz referenciranih članaka, minus anegdotski dokazi, i ilustriraju probleme nekih XP tehnika kada se primjenjuju na prilično složene projekte.

Projekt je započeo u siječnju 1995. godine. Od ožujka 1996., nakon uključivanja Kenta Becka, radio je koristeći XP. Do tada je već prešao proračun i planove za faznu provedbu funkcija. Razvojni tim je smanjen, a otprilike pola godine nakon toga projekt se prilično uspješno razvijao. U kolovozu 1998. pojavio se prototip koji je mogao opsluživati ​​oko 10.000 zaposlenika. Prvotno se očekivalo da će projekt biti dovršen sredinom 1999. godine, a dobiveni softver će se koristiti za upravljanje isplatama za 87.000 zaposlenika tvrtke. Zaustavljen je u veljači 2000. nakon 4 godine korištenja XP-a zbog potpunog nepoštivanja rokova i proračuna. Softver nikada nije korišten za rad s podacima o više od 10.000 zaposlenika, iako se pokazalo da se nosi s podacima 30.000 zaposlenika tvrtke. Osoba koja je igrala ulogu kupca uključenog u tim u projektu dala je otkaz nakon nekoliko mjeseci takvog rada, nesposobna izdržati opterećenje, te nije dobila adekvatnu zamjenu do kraja projekta.

Literatura za predavanje 3

W. Royce. Upravljanje projektima za razvoj softvera. M.: Lori, 2002.

A. Jacobson, G. Booch, J. Rambeau. Jedinstveni proces razvoja softvera. SPb .: Petar, 2002.

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

K. Beck. Ekstremno programiranje. SPb .: Petar, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler ide u "Extremes". Distribuirano računalstvo, 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 smatra se štetnim za pouzdan razvoj softvera. AVOCA Technical Report, 2002.

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