Temeljita ekonomska opravdanost svih radnji - radi se samo ono što kupac treba i ne dovodi do neisplativosti projekta.

Formiranje osnovne arhitekture što je ranije moguće.

Korištenje arhitekture komponenti.

Izrada prototipova, inkrementalni razvoj i testiranje.

Redovite procjene postojećeg stanja.

Upravljanje promjenama, stalni razvoj promjena izvan projekta.

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

Usredotočite se na kvalitetu.

Prilagodba procesa potrebama projekta.

Ekstremno programiranje

Ekstremno programiranje (XP) pojavio se kao evolucijska metoda razvoja softvera"dolje gore". Ovaj pristup je primjer metode tzv razvoj “uživo” (Agilna razvojna metoda) . U grupu “živih” metoda spadaju, osim ekstremnog programiranja, metode SCRUM, DSDM (Dynamic Systems Development Method, metoda razvoja dinamičkih sustava), Usmjeren na značajke Razvoj (razvoj potaknut funkcijama sustava) itd.

Osnovna načela razvoja softvera uživo sadržana su u manifestu razvoja uživo koji se pojavio 2000. godine.

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

Radni program je važniji od sveobuhvatne dokumentacije.

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

Provođenje promjena važnije je od pridržavanja 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 prilikom izvođenja projekta u skladu s većinom „teških“ procesa , dodatni rad za podršku fiksnom procesu organizacije, poput ovog potrebnog unutar, na primjer, CMM-a. Većina takvih poslova i dokumenata nije izravno povezana s razvojem softvera i osiguranjem kvalitete, već je namijenjena ispunjavanju formalnih klauzula razvojnih ugovora, dobivanju i potvrđivanju certifikata o usklađenosti s različitim standardima.

“Live” metode omogućuju programerima da većinu svojih napora usmjere na razvojne zadatke i zadovoljavanje stvarnih potreba korisnika. Odsutnost gomile dokumenata i potreba za njihovim održavanjem u koherentnom stanju omogućuje vam da brže i učinkovitije odgovorite na promjene u zahtjevima i okruženju u kojem će budući program morati raditi.

Međutim, XP ima svoj vlastiti dijagram procesa razvoja (iako, općenito govoreći, široko korišteno razumijevanje "procesa razvoja" kao prilično krute sheme radnji proturječi samoj ideji "živahnog" razvoja), prikazano na Sl. 15.

Prema autorima XP-a, ova tehnika ne slijedi toliko neke opće sheme radnje, koliko koristi kombinaciju sljedećih tehnika. No, svaka tehnika je važna, a bez njezine upotrebe razvoj se ne smatra XP-om, smatra Kent Beck, jedan od autora ovog pristupa, uz Warda Cunninghama i Rona Jeffriesa.

Igra planiranja uživo

Njegova je zadaća što je brže moguće odrediti količinu posla koju je potrebno obaviti prije sljedeće verzije softvera. Odluka se donosi prije svega na temelju prioriteta korisnika (tj. njegovih potreba, što mu od sustava treba za uspješnije

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

"Ubacivanje" rješenja

Slika 15. Dijagram tijeka rada u XP-u.

Česte promjene verzija (mala izdanja)

Prva radna verzija trebala bi se pojaviti što je prije moguće i trebala bi se odmah početi koristiti. Naknadne verzije pripremaju se u prilično kratkim vremenskim razmacima (od nekoliko sati za male izmjene u malom programu, do mjesec ili dva za veliku preradu velikog sustava).

Metafora sustava

Metafora bi u prilično jednostavnom i timu razumljivom obliku trebala opisati osnovni mehanizam sustava. Ovaj koncept podsjeća na arhitekturu, ali bi trebao opisati glavnu bit tehničkih odluka koje se donose mnogo jednostavnije, u samo jednoj ili dvije fraze.

Jednostavna dizajnerska rješenja

U svakom trenutku, sustav bi trebao biti dizajniran što je jednostavnije moguće. Nema potrebe dodavati značajke unaprijed - samo nakon izričitog zahtjeva za to. Sva nepotrebna složenost uklanja se čim se otkrije.

Testom vođen razvoj(razvoj vođen testom)

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

Kontinuirano refaktoriranje

Programeri neprestano prerađuju sustav kako bi eliminirali nepotrebnu složenost, povećali razumljivost koda, povećali njegovu fleksibilnost, ali bez promjene njegovog ponašanja, što se provjerava pokretanjem nakon svake prerade testova. Istovremeno, prednost se daje elegantnijim i fleksibilnijim rješenjima, u odnosu na ona koja jednostavno daju željeni rezultat. Neuspješno redizajnirane komponente treba identificirati tijekom izvođenja testa i vratiti ih u zadnje netaknuto stanje (zajedno s komponentama koje o njima ovise).

Programiranje u parovima

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

prvi i daje savjete, razmatra posljedice određenih odluka, nove testove, manje izravna, ali fleksibilnija rješenja.

Kolektivno vlasništvo koda

U Svaki član tima može promijeniti bilo koji dio koda u bilo kojem trenutku. Nitko ne bi trebao imati svoje područje odgovornosti; cijeli tim kao cjelina odgovoran je za sav kod.

Kontinuirana integracija

Sustav se sastavlja i podvrgava integracijskom testiranju što je češće moguće, nekoliko puta dnevno, svaki put kad par programera završi implementaciju sljedeće funkcije.

40 satni radni tjedan

Prekovremeni rad se vidi kao znak većih problema u projektu. Prekovremeni rad 2 tjedna zaredom nije dopušten – to iscrpljuje programere i čini njihov rad znatno manje produktivnim.

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

U U razvojnom timu uvijek je i predstavnik korisnika koji je dostupan tijekom cijelog radnog dana i može odgovoriti na sva pitanja o sustavu. Njegova je odgovornost promptno odgovoriti na pitanja bilo koje vrste u vezi s funkcijama sustava, njegovim sučeljem, potrebnim performansama, pravilan rad sustava u složenim situacijama, potreba za održavanjem komunikacije s drugim aplikacijama itd.

Korištenje koda kao sredstva komunikacije

Kodeks se smatra najvažnijim sredstvom komunikacije unutar tima. Jasnoća koda jedan je od glavnih prioriteta. Slijeđenje standarda kodiranja koji pružaju ovu jasnoću je imperativ. Takvi bi standardi, uz jasnoću koda, trebali osigurati minimalan jezik (bez dupliciranja koda i informacija) i trebali bi ih prihvatiti svi članovi tima.

Otvoreni radni prostor

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

Mijenjanje 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 je vidljivo iz korištenih tehnika, XP je namijenjen za korištenje u malim timovima (ne više od 10 programera), što naglašavaju i autori ove tehnike. Veća veličina tima uništava lakoću komunikacije potrebnu za uspjeh i onemogućuje primjenu mnogih navedenih tehnika.

Prednosti XP-a, ako se može implementirati, su veća fleksibilnost, mogućnost brzih i točnih promjena u softveru kao odgovor na promjenjive zahtjeve i individualne želje korisnika, visoka kvaliteta rezultirajućeg koda i nepostojanje potrebe za uvjeriti kupce da rezultat ispunjava njihova očekivanja.

Nedostaci ovakvog pristupa su neizvedivost 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 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 ne nalaze se odmah na temelju prethodno stečenog iskustva, već zahtijevaju prethodna istraživanja

XP kao skup opisanih tehnika prvi put je 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 gore spomenuta 3 glavna autora XP-a) objavilo je 3 knjige i ogroman broj članaka posvećenih XP-u tijekom samog projekta i kasnije. Ovaj projekt se više puta spominje u raznim izvorima kao primjer korištenja ove tehnike. Sljedeći podaci sastavljeni su iz spomenutih članaka, bez anegdotskih dokaza, i ilustriraju probleme s nekim XP tehnikama kada se primjenjuju na prilično složene projekte.

Projekt je započeo u siječnju 1995. Od ožujka 1996., nakon uključivanja Kenta Becka, pokreće se pomoću XP-a. Do tog vremena već je prešao proračun i planove za postupnu provedbu funkcija. Razvojni tim je smanjen, a nakon toga oko šest mjeseci projekt se prilično uspješno razvijao. U kolovozu 1998. pojavio se prototip koji je mogao poslužiti oko 10.000 zaposlenika. Prvotno se očekivalo da će projekt biti dovršen sredinom 1999. godine, a softver koji će rezultirati koristit će se za upravljanje pogodnostima za 87.000 zaposlenika tvrtke. Zaustavljen je u veljači 2000. nakon 4 godine pokretanja XP-a zbog potpunog nepoštivanja vremenskih okvira i budžeta. Izrađeni softver nikada nije korišten za rad s podacima o više od 10.000 zaposlenika, iako se pokazalo da može baratati podacima o 30.000 zaposlenika tvrtke. Osoba koja je bila u ulozi naručitelja uključena u projektni tim nakon nekoliko mjeseci takvog rada dala je otkaz, ne izdržavši opterećenje, te do kraja projekta nije dobila adekvatnu zamjenu.

Literatura za predavanje 3

W. Royce. Upravljanje projektima stvaranja softver. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Unificirani proces razvoja softvera. Sankt Peterburg: Peter, 2002.

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

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

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler ide u “Extremes”. Distribuirano računarstvo, 10/1998.

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

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

G. Keefer. Ekstremno programiranje smatra se štetnim za pouzdan razvoj softvera. AVOCA tehničko izvješće, 2002.

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

Objavio srijeda, 25.1.2012. - 02:28

7. Modeli adaptivnih razvojnih procesa: Scrum

Trenutno postaju sve rašireniji adaptivni ili lagani e, "živi" (agilni) razvojni procesi
Oni ne zahtijevaju tako strogu regulativu, priznati mogućnost čestih i značajnih promjena u zahtjevima kupaca

Adaptivni procesi usredotočiti se na koristeći dobre programere, a ne dobro uhodane procese razvoja
Oni izbjegavajte fiksiranje jasnih obrazaca djelovanja pružiti veću fleksibilnost u svakom konkretnom projektu i ne zahtijevati izradu dodatnih međudokumenata

Principi živog razvoja

Osnovni principi živog razvoja softvera zabilježeno u manifestu koji se pojavio 2000.: =

1. Ljudi uključeni u projekt i njihova komunikacija važniji su od procesa i alata
2. Radni program je važniji od sveobuhvatne dokumentacije
3. Suradnja s kupcem važnija je od dogovora o detaljima ugovora
4. Provođenje promjena važnije je od pridržavanja planova

Ekstremno programiranje

Najčešće korišteni adaptivni model je model ekstremnog programiranja(eXtreme Programming, XP proces)
XP procesno orijentiran u male i srednje timove koji razvijaju softver u uvjetima neizvjesnih ili brzo promjenjivih zahtjeva

XP proces (ekstremno programiranje)

Osnovna ideja XP procesa – eliminirati visoke troškove uvođenja promjena. To se postiže naglim (do dva tjedna) smanjenjem trajanja pojedinih ponavljanja.
Osnovne akcije xp-a su:=

1. kodiranje,
2. testiranje,
3. slušanje kupca,
4. oblikovati

XP načela

Visoka dinamičnost razvoj osiguravaju sljedeći principi:=

1. kontinuirana komunikacija s kupcem,
2. jednostavnost odabranih rješenja,
3. brzo Povratne informacije na temelju operativnih ispitivanja,
4. prevencija rizika

XP razvojne prakse

Provedba ovih načela se postiže korištenjem sljedećih metoda:=

1. Metafora– sav razvoj temelji se na jednostavnoj, javno dostupnoj priči o tome kako sustav funkcionira
2. Jednostavan dizajn– usvojena su najjednostavnija moguća dizajnerska rješenja
3. Kontinuirano testiranje pojedinačni moduli i sustav u cjelini; ulazni kriterij za pisanje koda je neuspjeli testni slučaj
4. Reorganizacija(Refactoring) - poboljšanje strukture sustava uz zadržavanje njegovog ponašanja
5. Programiranje u parovima e – kod pišu dva programera na jednom računalu
6. Kolektivno vlasništvo koda– svaki programer može poboljšati kod bilo kojeg modula sustava
7. Kontinuirana integracija – sustav se integrira što je češće moguće; Kontinuirano regresijsko testiranje osigurava da funkcionalnost ostaje ista dok se zahtjevi mijenjaju
8. Lokalni kupac– u grupi cijelo vrijeme mora biti nadležni predstavnik kupca
9. Standardi kodiranja– pravila se moraju poštovati kako bi se osigurala ista prezentacija koda u svim dijelovima sustava

XP razvojni dijagram

XP slika (XP razvojni dijagram):

Scrum model

To je još jedan primjer procesa adaptivnog razvoja (prethodno smo gledali)
Glavne ideje modela formulirali su Hirotaka Takeuchi i Ikujiro Nonaka 1986.

Glavna ideja Scrum modela

Eksperimentalna činjenica: projekti na kojima rade mali, međufunkcionalni timovi imaju tendenciju da sustavno proizvode bolje rezultate

Takeuki i Nonata su to objasnili kao "ragbi pristup" i uveo sam termin

"ološ"- "simpatija; strka oko lopte (u ragbiju)"

Scrum metodu prvi put su u dokumentiranom obliku predstavili Sutherland i Schwaber 1996. godine

Uloge

1. ScrumMaster, onaj koji se bavi procesima i radi kao voditelj projekta,
2. Vlasnik proizvoda, osoba koja zastupa interese krajnjih korisnika i drugih zainteresiranih strana za proizvod,
3. Tim, koji uključuje programere

Faze razvoja

Razvojni proces je podijeljen na odvojene etape određenog trajanja – sprintevi(obično 15-30 dana)
Svaki sprint kojoj prethodi faza koja se naziva zaostatak proizvoda– dokumentiranje zahtjeva za rad

Planiranje sprinta

Radni zahtjevi određuju se tijekom faze Odbora za planiranje sprinta − sastanak za planiranje sprinta

Planiranje sprinta
Tijekom ovog sastanka, Product Owner informira o zadacima koje je potrebno izvršiti
Tim određuje koliko od onoga što žele postići kako bi dovršili potrebne dijelove tijekom sljedećeg sprinta

Izvođenje sprinta

Tijekom sprinta, tim završava određeni fiksni popis zadataka - neriješenih predmeta, povećavajući funkcionalnost softverskog proizvoda

Tijekom ovog perioda nitko nema pravo mijenjati popis uvjeta za posao, što treba shvatiti kao zahtjeve za smrzavanjem tijekom sprinta

Scrum dijagram =

tekst referentnog odgovora (ne postavljam ga kao obaveznog)

Ekstremno programiranje

Osnovne XP tehnike

· Kratki povratni ciklus (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 parovima

Kontinuirani, a ne serijski proces

o Kontinuirana integracija

o Refactoring (Poboljšanje dizajna, Refactor)

o Česta mala izdanja

· Razumijevanje koje dijele svi

o Jednostavnost (jednostavan dizajn)

o metafora sustava

o Kolektivno vlasništvo koda ili odabranih uzoraka dizajna (kolektivno vlasništvo uzoraka)

o Standard kodiranja ili konvencije kodiranja

· Dobrobit programera:

o 40-satni radni tjedan (održivi tempo, četrdesetosatni radni tjedan)

Testiranje

XP poseban naglasak stavlja na dvije vrste testiranja:

· jedinično testiranje;

· ispitivanje prihvatljivosti.

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

Testovi prihvaćanja osiguravaju da sustav stvarno ima navedene mogućnosti. Osim toga, testovi prihvaćanja omogućuju provjeru ispravnog rada 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, pa se tek onda kod refaktorira.

Igra planiranja

Glavni cilj igre planiranja je brzo formulirati okvirni plan rada i stalno ga ažurirati kako uvjeti problema postaju jasniji. Artefakti igre planiranja su set papirnatih kartica na kojima su zapisane želje kupaca (priče kupaca), te okvirni plan rada za puštanje sljedeće jedne ili više malih verzija proizvoda. Kritični čimbenik koji ovaj stil planiranja čini učinkovitim jest da je u ovom slučaju kupac odgovoran za donošenje poslovnih odluka, a razvojni tim odgovoran je za donošenje tehničkih odluka. Ako se ovo pravilo ne poštuje, cijeli proces pada u vodu.

Kupac je uvijek tu

"Kupac" u XP-u nije onaj koji plaća račune, već onaj koji stvarno koristi sustav. XP navodi da kupac mora biti u kontaktu u svakom trenutku i dostupan za pitanja.

Programiranje u parovima

Programiranje u paru uključuje sav kod koji stvaraju parovi programera koji rade na istom računalu. Jedan od njih radi izravno s programskim tekstom, drugi gleda na njegov rad i prati cjelokupnu sliku onoga što se događa. Ako je potrebno, tipkovnica se slobodno prenosi s jedne na drugu. Tijekom rada na projektu parovi nisu fiksni: preporučuje se miješati ih kako bi svaki programer u timu dobro razumio cijeli sustav. Na taj način programiranje u paru poboljšava suradnju unutar tima.

Kontinuirana integracija

Ako dovoljno često integrirate sustav koji razvijate, možete izbjeći većinu problema povezanih s njim. Kod tradicionalnih metoda integracija se obično izvodi na samom kraju rada na proizvodu, kada se smatra da su sve komponente sustava koji se razvija potpuno spremne. U XP-u se integracija koda cijelog sustava izvodi nekoliko puta dnevno, nakon što se programeri uvjere da se svi jedinični testovi pokreću ispravno.

Refactoring

Ovo je tehnika za poboljšanje koda bez promjene njegove funkcionalnosti. XP znači da će kod jednom kada je napisan gotovo sigurno biti ponovno napisan nekoliko puta tijekom projekta. XP programeri nemilosrdno prerađuju prethodno napisani kod 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.

Česta mala izdanja

Verzije (izdanja) proizvoda treba puštati u rad što je češće moguće. Svaka verzija trebala bi trajati što je moguće kraće. Štoviše, svaka verzija mora biti dovoljno smislena u smislu korisnosti za poslovanje.

Što prije objavimo prvu radnu verziju proizvoda, to će prije kupac početi dobivati ​​dodatni profit od toga. Zapamtite da novac zarađen danas vrijedi više od novca zarađenog sutra. Što prije kupac počne koristiti proizvod, programeri će prije od njega dobiti informaciju o tome što zadovoljava zahtjeve kupca. Ove informacije mogu biti od velike pomoći pri planiranju vašeg sljedećeg izdanja.

Jednostavnost dizajna

XP polazi od činjenice da se tijekom procesa rada uvjeti problema mogu višekratno mijenjati, što znači da proizvod koji se razvija ne treba unaprijed dizajnirati u cijelosti. Ako pokušate projektirati sustav do detalja od početka do kraja kada ga prvi put pokrenete, uzalud gubite vrijeme. XP pretpostavlja da je projektiranje toliko važan proces da se mora provoditi kontinuirano tijekom cijelog projekta. Dizajn se mora provoditi u malim koracima, uzimajući u obzir zahtjeve koji se stalno mijenjaju. U svakom trenutku pokušavamo koristiti najjednostavniji dizajn koji je prikladan za rješavanje trenutnog problema. Istovremeno ga mijenjamo kako se mijenjaju uvjeti problema.

Metafora sustava

Arhitektura je neka ideja o komponentama sustava i načinu na koji su one međusobno povezane. Programeri koriste arhitekturu kako bi razumjeli gdje se u sustavu dodaje neka nova funkcionalnost i s čime će neka nova komponenta komunicirati.

Metafora sustava analogna je onome što se u većini tehnika naziva arhitekturom. Metafora sustava daje timu uvid u to kako sustav trenutno funkcionira, gdje se nove komponente dodaju i kakav bi oblik trebale imati.

Odabirom dobre metafore svom timu olakšavate razumijevanje kako vaš sustav funkcionira. Ponekad to nije lako učiniti.

Standardi kodiranja

Svi članovi tima moraju se pridržavati zajedničkih standarda kodiranja tijekom rada. Time:

· članovi tima ne gube vrijeme na glupe prepirke o stvarima koje zapravo ne utječu na brzinu rada na projektu;

· osigurava učinkovitu provedbu drugih praksi.

Ako tim ne koristi dosljedne standarde kodiranja, razvojnim programerima postaje teže refaktorirati; kod mijenjanja partnera u parovima dolazi do više poteškoća; općenito, napredak projekta postaje težak. Unutar XP-a potrebno je osigurati da je teško razumjeti tko je autor ovog ili onog dijela koda - cijeli tim radi jedinstveno, kao jedna osoba. Tim mora formirati skup pravila, a zatim svaki član tima mora slijediti ta pravila tijekom procesa kodiranja. Popis pravila ne smije biti iscrpan niti predug. Zadatak je formulirati opće upute, zahvaljujući kojem će kod postati razumljiv svakom članu tima. Standard kodiranja trebao bi započeti jednostavno, a zatim bi se razvijao kako tim stječe iskustvo. Ne biste trebali trošiti previše vremena na preliminarni razvoj standarda.

Kolektivno vlasništvo

Kolektivno vlasništvo znači da je svaki član tima odgovoran za sav izvorni kod. Dakle, svatko ima pravo mijenjati bilo koji dio programa. Programiranje u parovima podržava ovu praksu: radeći u različitim parovima, svi programeri se upoznaju sa svim dijelovima koda sustava. Važna prednost zajedničkog vlasništva nad kodom je da ubrzava razvojni proces, jer ako se dogodi pogreška, svaki programer je može popraviti.

Dajući svakom programeru pravo da promijeni kôd, izlažemo se riziku bugova koje unose programeri koji misle da znaju što rade, ali ne uzimaju u obzir određene ovisnosti. Dobro definirani UNIT testovi rješavaju ovaj problem: ako neispitane ovisnosti generiraju pogreške, sljedeće pokretanje UNIT testova neće uspjeti

Scrum je skup načela na kojima je izgrađen razvojni proces, omogućujući, u strogo fiksnim kratkim vremenskim razdobljima (sprintovi od 2 do 4 tjedna), krajnjem korisniku pružiti radni softver s novim značajkama za koje je najveći prioritet odlučan. Mogućnosti softvera za implementaciju u sljedećem sprintu određuju se na početku sprinta u fazi planiranja i ne mogu se mijenjati tijekom cijelog njegovog trajanja. Istodobno, strogo fiksno kratko trajanje sprinta daje razvojnom procesu predvidljivost i fleksibilnost.

Glavne glumačke uloge u Scrumu: ScrumMaster je onaj koji vodi Scrum sastanke i osigurava da se poštuju svi Scrum principi (uloga ne podrazumijeva ništa osim ispravnog ponašanja samog Scruma, voditelj projekta je vjerojatnije Vlasnik proizvoda i ne bi trebao biti ScrumMaster); Vlasnik proizvoda – osoba koja zastupa interese krajnjih korisnika i drugih zainteresiranih strana za proizvod; i međufunkcionalni tim (Scrum tim), koji se sastoji od programera i testera, arhitekata, analitičara itd. (idealna veličina tima je 7±2 osobe). Tim je jedini potpuno uključeni sudionik u razvoju, te je odgovoran za rezultat kao jedinstvena cjelina. Nitko osim tima ne može ometati razvojni proces tijekom sprinta.

Tijekom svakog sprinta stvara se funkcionalni rast softvera. Skup značajki koje se isporučuju u svakom sprintu dolazi iz faze koja se naziva zaostatak proizvoda, koja ima najveći prioritet u smislu razine radnih zahtjeva koji se moraju dovršiti. Zaostale stavke identificirane tijekom sastanka za planiranje sprinta premještaju se u fazu sprinta. Tijekom ovog sastanka, Product Owner priopćava zadatke koje je potrebno izvršiti. Tim zatim određuje koliko od onoga što žele postići kako bi dovršili potrebne dijelove tijekom sljedećeg sprinta. Tijekom sprinta tim ispunjava određeni fiksni popis zadataka (tzv. sprint backlog). U tom razdoblju nitko nema pravo mijenjati popis radnih zahtjeva, što treba shvatiti kao zahtjeve smrzavanja tijekom sprinta.

_____________
Matematički fakultet VSU i drugi klasici =)

• Prijavite se za objavljivanje komentara

Ekstremno programiranje (XP) je pojednostavljena metodologija razvoja softvera za male do srednje velike razvojne timove koji stvaraju softverski proizvod u uvjetima nejasnih ili brzo promjenjivih zahtjeva.

Glavni ciljevi XP-a su povećanje povjerenja kupaca softverskom proizvodu pružajući stvarne dokaze o uspješnosti razvojnog procesa i oštro smanjenje vremena razvoja proizvoda . U isto vrijeme, XP je usmjeren na smanjenje pogrešaka u ranim fazama razvoja. To vam omogućuje postizanje maksimalna brzina puštanje gotovog proizvoda i omogućuje govoriti o predvidljivosti rada. Gotovo sve XP tehnike usmjerene su na poboljšanje kvalitete softverskog proizvoda.

XP načela

Glavna načela su:

• Iterativnost. Razvoj se odvija u kratkim iteracijama uz aktivan odnos s kupcem. Predlaže se da iteracije kao takve budu kratke, preporučeno trajanje je 2-3 tjedna i ne više od 1 mjeseca. U jednoj iteraciji, grupa programera mora implementirati nekoliko svojstava sustava, od kojih je svako opisano u korisničkoj priči. Korisničke priče (UI) u ovom su slučaju početne informacije na temelju kojih se kreira modul. Oni se razlikuju od slučajeva upotrebe (VI). Opis PI je kratak - 1-2 odlomka, dok su VI obično dovoljno detaljno opisani, s glavnim i alternativnim tokovima, te su dopunjeni modelom. UI-ja pišu sami korisnici, koji su u XP-u dio tima, za razliku od UI-ja koje opisuje sistemski analitičar. Nedostatak formalizacije opisa ulaznih podataka projekta u XP-u nastoji se nadoknaditi aktivnim uključivanjem korisnika u razvojni proces kao punopravnog člana tima.
• Jednostavnost rješenja. Usvojeno je prvo najjednostavnije radno rješenje. Ekstremnost metode povezana je s visokim stupnjem rizika odluke zbog površnosti analize i tijesnog vremenskog rasporeda. Minimalni skup glavnih funkcija sustava implementiran je u prvoj i svakoj sljedećoj iteraciji; funkcionalnost se proširuje sa svakom iteracijom.
• Intenzivan razvoj u malim grupama(ne više od 10 osoba) i programiranje u paru(kada dva programera zajedno kreiraju kod na jednom zajedničkom radnom mjestu), aktivna komunikacija unutar grupe i između grupa. Sve to ima za cilj što ranije otkrivanje problema (i grešaka i propuštenih rokova). Programiranje u parovima ima za cilj rješavanje problema stabilizacije projekta. Kod korištenja XP metodologije postoji veliki rizik od gubitka koda zbog odlaska programera koji se nije mogao nositi s intenzivnim radnim rasporedom. U ovom slučaju, drugi programer u paru igra ulogu "nasljednika" koda. Također je važno kako su točno grupe raspoređene u radnom prostoru - XP koristi otvoreni radni prostor, što podrazumijeva brz i slobodan pristup za svakoga svakome.
• Povratna informacija s kupcem, čiji je predstavnik zapravo uključen u razvojni proces.
• Dovoljan stupanj hrabrosti i spremnost na preuzimanje rizika.

XP tehnike (vježbe)

XP obično karakterizira skup od 12 pravila (vježbi) kojih se morate pridržavati da biste postigli dobar rezultat. Nijedna od ovih praksi nije suštinski nova, ali XP ih spaja.

1. Planiranje procesa. Cijeli razvojni tim se okuplja i donosi se kolektivna odluka o tome koja će svojstva sustava biti implementirana u sljedećoj iteraciji. Složenost implementacije svakog svojstva određuju sami programeri.
2. Bliska interakcija s kupcem. Predstavnik kupca mora biti član XP tima. On piše korisničko sučelje, odabire priče koje će se implementirati u određenoj iteraciji i odgovara na pitanja vezana uz poslovanje. Predstavnik kupca mora biti stručnjak u automatiziranom predmetnom području. Neophodna je stalna povratna informacija s predstavnikom kupaca.
3. Pravila imenovanja za cijeli sustav. Predlažu dobre konvencije imenovanja sustava jednostavnost imenovanja klase i varijable. Razvojni tim mora imati jedinstvena pravila imenovanje.
4. Jednostavna arhitektura. Svako svojstvo sustava treba implementirati što je jednostavnije moguće. Programeri u XP timu rade pod motom: “Ništa suvišno!” Usvojeno je prvo najjednostavnije radno rješenje, implementirana je potrebna razina funkcionalnosti ovaj trenutak. Ovo programeru štedi vrijeme.
5. Refactoring. Ovo je optimizacija postojećeg koda kako bi se on pojednostavio i na ovome treba raditi stalno. Održavajući kod transparentnim i definirajući elemente koda samo jednom, programeri smanjuju broj grešaka koje kasnije moraju popraviti. Prilikom implementacije svake nove značajke sustava, programer mora razmotriti je li moguće pojednostaviti postojeći kod i kako će to pomoći u implementaciji nove značajke. Osim toga, refaktoring se ne smije kombinirati s dizajnom: ako se stvara novi kod, refaktoring treba odgoditi.
6. Programiranje u parovima. Svi programeri moraju raditi u parovima: jedan piše kod, drugi gleda. Dakle, potrebno je smjestiti grupu programera na jedno mjesto. XP najuspješnije radi u neraspoređenim timovima programera i korisnika.
7. 40 satni radni tjedan. Programer ne bi trebao raditi više od 8 sati dnevno. Potreba za prekovremenim radom jasan je pokazatelj problema u tom području razvoja. Pronalaženje razloga za prekovremeni rad i njihovo što brže otklanjanje jedno je od osnovnih pravila.
8. Kolektivno vlasništvo koda. Svaki programer u timu mora imati pristup kodu bilo kojeg dijela sustava i pravo mijenjati bilo koji kod. Obvezno pravilo: ako programer napravi promjene i sustav nakon toga ne radi ispravno, tada je programer taj koji mora ispraviti pogreške.
9. Jedinstveni standardi kodiranja. Standardi kodiranja potrebni su za podršku drugim praksama: zajedničko vlasništvo nad kodom, programiranje u paru i refaktoriranje. Bez jedinstvenog standarda, barem je teže provoditi ove prakse, au stvarnosti je potpuno nemoguće: grupa će raditi u stalnom nedostatku vremena. Tim je dugo radio na projektu. Ljudi dolaze i odlaze. Nitko ne kodira sam i kod pripada svima. Uvijek će biti trenutaka kada ćete morati razumjeti i prilagoditi tuđi kod. Programeri će ukloniti dupli kod, analizirati i poboljšati tuđe klase itd. S vremenom će biti nemoguće reći tko je autor pojedine klase. Stoga svi moraju poštovati zajedničke standarde kodiranja - formatiranje koda, imenovanje klasa, varijabli, konstanti, stil komentara. Gore navedeno znači da se svi članovi tima moraju složiti oko zajedničkih standarda kodiranja. Nije bitno koje, ali svi su ih dužni poštovati.
10. Mala izdanja. Minimalna iteracija je jedan dan, maksimalna je mjesec dana; Što se češće izdaje, to će se identificirati više grešaka u sustavu. Prva izdanja pomažu identificirati nedostatke u najranijim fazama, zatim se funkcionalnost sustava proširuje na temelju korisničkog sučelja. Budući da je korisnik uključen u razvojni proces od prvog izdanja, on ocjenjuje sustav i daje korisničku povijest i komentare. Na temelju toga se određuje sljedeća iteracija, odnosno kakvo će biti novo izdanje. XP je usmjeren na pružanje stalnih povratnih informacija korisnicima.
11. Kontinuirana integracija. Integracija novih dijelova sustava treba se odvijati što je češće moguće, barem jednom svakih nekoliko sati. Osnovno pravilo integracije je sljedeće: integraciju je moguće provesti ako su svi testovi uspješno prošli. Ako testovi ne uspiju, programer mora izvršiti ispravke i zatim integrirati komponente sustava ili ih uopće ne integrirati. Ovo pravilo je strogo i nedvosmisleno. Ako postoji barem jedna greška u kreiranom dijelu sustava, tada se integracija ne može izvršiti. Česta integracija omogućuje brže dobivanje gotovog sustava, umjesto da trošite tjedan dana na sastavljanje.
12. Testiranje. Za razliku od većine drugih metodologija, testiranje u XP-u jedna je od najvažnijih komponenti. Ekstremni pristup pretpostavlja da testovi se pišu prije pisanja koda . Svaki modul mora imati jedinični test - test ovog modula. Stoga se u XP-u provodi regresijsko testiranje, "ne degradirajući kvalitetu" prilikom dodavanja funkcionalnosti. Većina pogrešaka ispravlja se u fazi kodiranja. Testove pišu sami programeri; svatko od njih ima pravo napisati test za bilo koji modul. Još važno načelo: test određuje kod, a ne obrnuto (test-driven development), odnosno dio koda se stavlja u repozitorij ako i samo ako su svi testovi uspješno prošli, u protivnom se ova promjena koda odbija.

XP proces je neformalan, ali zahtijeva visoka razina samodisciplina. Ako se ovo pravilo ne poštuje, XP se trenutno pretvara u kaotičan i nekontroliran proces. XP ne zahtijeva od programera da pišu puno izvješća i izrađuju mnogo modela. U XP-u se svaki programer smatra kvalificiranim radnikom koji svoje obveze preuzima profesionalno i s velikom odgovornošću. Ako tim to nema, onda je uvođenje XP-a apsolutno besmisleno - bolje je prvo početi s restrukturiranjem tima. Rizik razvoja smanjuje se samo u timu za koji je XP idealan, u svim ostalim slučajevima XP je razvojni proces s najvećim stupnjem rizika, jer jednostavno nema drugih metoda za smanjenje komercijalnih rizika, osim ljudskog faktora, u XP-u.

Extreme Programming ili XP, eXtreme Programming je fleksibilna metodologija razvoja softvera. Kao i druge agilne metodologije, ima specifične alate, procese i uloge. Iako autor XP-a nije smislio ništa novo, već je uzeo najbolje prakse agilnog razvoja i maksimalno ih ojačao. Zato se programiranje naziva ekstremnim.

Autor metode je američki programer Kent Beck. U kasnim 90-ima vodio je projekt Chrysler Comprehensive Compensation System i tamo je bio pionir u praksi ekstremnog programiranja. Svoje iskustvo i koncept koji je stvorio opisao je u knjizi Extreme Programming Explained, objavljenoj 1999. godine. Uslijedile su druge knjige koje detaljno opisuju XP prakse. U razvoju metodologije sudjelovali su i Ward Cunningham, Martin Fowler i drugi.

XP se razlikuje od ostalih agilnih metodologija po tome što se primjenjuje samo u području razvoja softvera. Ne može se koristiti u drugom poslu ili svakodnevnom životu kao što je scrum, kanban ili lean.

Cilj XP metodologije je nositi se sa stalno promjenjivim zahtjevima za softverski proizvod i poboljšati kvalitetu razvoja. Stoga je XP vrlo prikladan za složene i neizvjesne projekte

Metodologija XP izgrađena je oko četiri procesa: kodiranje, testiranje, dizajn i slušanje. Dodatno, Extreme Programming ima vrijednosti jednostavnosti, komunikacije, povratne informacije, hrabrosti i poštovanja.

1. Cijeli tim

Svi sudionici projekta koji koriste XP rade kao jedan tim. Mora uključivati ​​predstavnika kupca; bolje je da je to pravi krajnji korisnik proizvoda koji razumije posao. Kupac postavlja zahtjeve za proizvod i daje prioritet implementaciji funkcionalnosti. Poslovni analitičari mu mogu pomoći. Na strani izvršenja, tim uključuje programere i testere, ponekad trenera koji vodi tim i menadžera koji timu osigurava resurse.

2. Igra planiranja

Planiranje u XP-u provodi se u dvije faze - planiranje izdanja i planiranje ponavljanja.

Tijekom planiranja izdanja programski tim se sastaje s kupcem kako bi saznao koju funkcionalnost želi dobiti za sljedeće izdanje, odnosno za 2-6 mjeseci. Budući da su zahtjevi korisnika često nejasni, programeri ih specificiraju i rastavljaju u dijelove, čija implementacija ne traje više od jednog dana. Važno je da kupac razumije radno okruženje u kojem će proizvod raditi.

Zadaci se zapisuju na kartice, a kupac određuje njihov prioritet. Zatim programeri procjenjuju koliko će vremena oduzeti svaki zadatak. Kada su zadaci opisani i ocijenjeni, naručitelj pregledava dokumentaciju i daje zeleno svjetlo za početak rada. Za uspjeh projekta ključno je da kupac i programerski tim igraju na istom terenu: kupac odabire funkcionalnost koja mu je stvarno potrebna unutar proračuna, a programeri adekvatno uspoređuju zahtjeve kupca sa svojim mogućnostima.

U XP-u, ako tim nema vremena izvršiti sve zadatke do datuma izdavanja, tada se izdanje ne pomiče, ali se reže dio funkcionalnosti koji je najmanje važan za kupca.

Izvodi se planiranje ponavljanja svaka dva tjedna, ponekad više ili rjeđe. Kupac je uvijek prisutan: on određuje funkcionalnost za sljedeću iteraciju i mijenja zahtjeve proizvoda.

3. Česta izdanja verzije

U XP-u se verzije objavljuju često, ali s malo funkcionalnosti. Prvo, malu količinu funkcionalnosti lako je testirati i održavati funkcionalnost cijelog sustava. Drugo, svakim ponavljanjem kupac dobiva dio funkcionalnosti koji nosi poslovnu vrijednost.

4. Korisnički testovi

Kupac sam definira automatske testove prihvaćanja kako bi provjerio funkcionalnost sljedeće funkcije proizvoda. Tim piše te testove i koristi ih za testiranje gotovog koda.

5. Kolektivno vlasništvo koda

U XP-u svaki programer može uređivati ​​bilo koji dio koda, jer... Šifra nije dodijeljena autoru. Cijeli tim posjeduje kod.

6. Kontinuirana integracija koda

To znači da se novi dijelovi koda odmah ugrađuju u sustav - XP timovi postavljaju novu verziju svakih nekoliko sati ili češće. Prvo, odmah je jasno kako posljednje promjene utjecati na sustav. Ako novi dio koda nešto pokvari, tada je pronalaženje i popravljanje pogreške puno lakše nego tjedan dana kasnije. Drugo, tim uvijek radi sa Najnovija verzija sustava.

7. Standardi kodiranja

Kada svi posjeduju kod, važno je usvojiti dosljedne standarde dizajna tako da kod izgleda kao da ga je napisao jedan profesionalac. Možete razviti vlastite standarde ili usvojiti gotove.

8. Metafora sustava

Metafora sustava je usporedba sustava s nečim poznatim kako bi se stvorila zajednička vizija među timom. Obično metaforu sustava osmisli osoba koja dizajnira arhitekturu i zamišlja sustav kao cjelinu.

9. Ujednačen tempo

XP timovi rade uz maksimalnu produktivnost dok održavaju stabilan tempo. Istodobno, ekstremno programiranje ima negativan stav prema prekovremenom radu i promovira 40-satni radni tjedan.

10. Razvoj vođen testovima

Jedna od najtežih praksi metodologije. U XP-u, testove pišu sami programeri, PRIJE pisanja koda koji treba testirati. Ovim pristupom svaka će funkcionalnost biti 100% pokrivena testovima. Kada nekoliko programera učita kod u repozitorij, jedinični testovi se odmah pokreću. I SVI bi trebali raditi. Tada će programeri biti sigurni da se kreću u pravom smjeru.

11. Programiranje u paru

Zamislite dva programera za jednim računalom, koji rade na jednom dijelu funkcionalnosti proizvoda. Ovo je programiranje u paru, najkontroverznija XP praksa. Stara izreka “jedna glava je dobra, dvije su bolje” savršeno ilustrira bit pristupa. Od dvije opcije za rješavanje problema odabire se najbolja, kod se odmah optimizira, a greške se hvataju prije nego se dogode. Kao rezultat toga, imamo čist kod koji dva programera dobro poznaju.

12. Jednostavan dizajn

Jednostavan dizajn u XP-u znači raditi samo ono što vam je sada potrebno, bez pokušaja nagađanja buduće funkcionalnosti. Jednostavan dizajn i kontinuirano refaktoriranje imaju sinergijski učinak - kada je kod jednostavan, lako ga je optimizirati.

13. Refaktoriranje

Refactoring je proces stalnog poboljšavanja dizajna sustava kako bi se prilagodio novim zahtjevima. Refaktoriranje uključuje uklanjanje duplikata koda, povećanje kohezije i smanjenje spajanja. XP uključuje stalna refaktoriranja, tako da dizajn koda uvijek ostaje jednostavan.

XP prednosti i nedostaci

XP metodologija izaziva mnogo kontroverzi i kritika od onih koji je nikada nisu uspjeli implementirati u svoj tim.

Prednosti ekstremnog programiranja imaju smisla kada tim u potpunosti koristi barem jednu od XP praksi. Dakle, što vrijedi pokušati:

• kupac dobiva točno onakav proizvod koji mu treba, čak i ako na početku razvoja sam ne zamišlja točno njegov konačni oblik
• tim brzo mijenja kod i dodaje nove funkcije kroz jednostavan dizajn koda, često planiranje i izdanja
• kod uvijek radi zbog stalnog testiranja i kontinuirane integracije
• tim lako održava šifru, jer napisan je prema jedinstvenom standardu i stalno se refaktorira
• brz tempo razvoja zbog programiranja u paru, nedostatak prerade, prisutnost kupca u timu
• visoka kvaliteta koda
• rizici povezani s razvojem su smanjeni, jer odgovornost za projekt je ravnomjerno raspoređena i odlazak/dolazak člana tima neće pokvariti proces
• troškovi razvoja su manji jer tim je orijentiran na kod, a ne na dokumentaciju i sastanke

Unatoč svim prednostima, XP ne radi uvijek i ima niz slabosti. Dakle, ekstremno programiranje - nedostaci:

• uspjeh projekta ovisi o angažmanu korisnika, što nije tako lako postići
• Teško je predvidjeti vrijeme utrošeno na projekt, jer... na početku nitko ne zna puni popis zahtjevi
• uspjeh XP-a uvelike ovisi o razini programera; metodologija radi samo sa starijim stručnjacima
• menadžment ima negativan stav prema programiranju u paru, ne shvaćajući zašto bi trebao plaćati dva programera umjesto jednog
• Redoviti sastanci s programerima su skupi za kupce
• zahtijeva previše kulturnih promjena
• zbog nedostatka strukture i dokumentacije nije pogodan za velike projekte
• jer Agilne metodologije su funkcionalno orijentirane, a nefunkcionalne zahtjeve za kvalitetom proizvoda teško je opisati u obliku korisničkih priča.

XP načela

U svojoj prvoj knjizi Kent Beck artikulirao je principe ekstremnog programiranja: jednostavnost, komunikacija, povratna informacija i hrabrost. U novom izdanju knjige dodao je i peto načelo – poštovanje.

1. Jednostavnost

U XP-u razvoj počinje od samog početka. jednostavno rješenje, koji će zadovoljiti trenutnu potrebu za funkcionalnošću. Članovi tima vode računa samo o onome što treba napraviti sada, a ne stavljaju u kod funkcionalnosti koje će biti potrebne sutra, za mjesec dana ili nikada.

2. Komunikacija

U XP-u, komunikacija između programera ne provodi se kroz dokumentaciju, već uživo. Tim aktivno komunicira međusobno i s kupcem.

3. Povratne informacije

Povratne informacije u XP-u implementirane su u tri smjera odjednom:

1. povratne informacije iz sustava tijekom stalnog testiranja modula
2. povratne informacije od kupca, jer dio je tima i sudjeluje u pisanju prijamnih testova
3. povratne informacije od tima tijekom planiranja u vezi s vremenom razvoja.

4. Hrabrost

Neke ekstremne tehnike programiranja toliko su neobične da zahtijevaju hrabrost i stalnu samokontrolu.

5. Poštovanje

U Extreme Programmingu poštovanje se promatra u smislu poštovanja tima i samopoštovanja. Članovi tima ne bi trebali učitavati promjene koje će pokvariti kompilaciju, jedinične testove ili usporiti rad kolega. Svi teže za najviša kvaliteta kod i dizajn.

Algoritam za implementaciju XP metodologije i procesa rada

Beck Kent preporučuje implementaciju XP-a za rješavanje problema u projektu. Tim odabire najhitniji problem i rješava ga pomoću jedne od praksi ekstremnog programiranja. Zatim prelazi na sljedeći problem uz više vježbe. Ovim pristupom problemi djeluju kao motivacija za korištenje XP-a i tim postupno ovladava svim alatima metodologije.

Da biste implementirali XP u postojeći projekt, morate postupno savladati njegove tehnike u sljedećim područjima:

• testiranje
• oblikovati
• planiranje
• upravljanje
• razvoj

Testiranje.

Tim stvara testove PRIJE pisanja novog koda i postupno prerađuje stari kod. Za stari kod, testovi se pišu po potrebi: kada trebate dodati novu funkcionalnost, popraviti grešku ili preraditi dio starog koda.

Oblikovati.

Tim postupno prepravlja stari kod, obično prije dodavanja novih funkcija. Kao i kod testiranja, refaktoriranje starog koda vrši se samo kada je potrebno. U isto vrijeme, tim bi trebao formulirati dugoročne ciljeve za preradu koda i postupno ih ostvarivati.

Planiranje.

Tim mora prijeći na blisku interakciju s kupcem. U ovoj fazi važno mu je prenijeti prednosti rada u istom timu s programerima i integrirati ga u tim.

Upravljanje.

Uloga menadžera tijekom prijelaza na XP je osigurati da svi članovi tima rade u skladu s novim pravilima. Voditelj projekta odlučuje kada će se rastati od člana tima koji se ne snalazi u novoj sredini ili će pronaći novog i pravilno ga integrirati u posao.

Razvoj.

Transformacije u razvoju počinju organizacijom radnih stanica za programiranje u paru. Sljedeći zadatak— većinu radnog vremena programirajte u paru, koliko god to programerima bilo teško.

U projektu koji radi prema XP metodologiji, proces je strukturiran na sljedeći način:

Tko koristi XP

Prema studiji Versiononea iz 2016., samo 1% agilnih tvrtki koristi ekstremno programiranje u čistom obliku. Drugih 10% radi koristeći hibridnu scrum i XP metodologiju.

Zanimljivo, iako je XP daleko od najčešće metodologije u svom čistom obliku, njegove prakse koristi većina tvrtki koje rade na agilnim metodologijama. O tome svjedoče podaci iz iste studije:

Nije lako pronaći informacije o timovima koji koriste XP, ali ima onih koji reklamiraju da je upravo ta metodologija razlog njihovog uspjeha. Primjer ekstremnog programiranja je Pivotal Software, Inc.

Pivotal Software, Inc.

Američka softverska tvrtka koja razvija softver za poslovnu analizu na temelju veliki podaci te pruža konzultantske usluge. Ključne proizvode koriste Ford, Mercedes, BMW, GAP, Humana, velike banke, vladine agencije, osiguravajuća društva itd.

Pivotal je zagovornik agilnih metodologija kao jedine moguće u suvremenom razvoju. Od svih opcija za fleksibilne metodologije, tvrtka je odabrala XP kao pristup koji koristi svim klijentima i programerskim timovima. Svaki radni dan počinje sastankom u hodu, a završava točno u 18:00 - bez prekovremenih. Pivotal koristi planiranje igre, programiranje u paru, kontinuirano testiranje, kontinuiranu integraciju i druge XP prakse. Za mnoge ordinacije imaju vlastiti softver.

Ekstremno programiranje,
Ekstremno programiranje: planiranje,
Ekstremno programiranje: razvoj vođen testiranjem / Kent Beck

O ekstremnom programiranju od tvorca metodologije, Kenta Becka. Počnite s prvim, koji na primjerima opisuje koncept XP-a i opravdava njegove prednosti. Kasnije je autor objavio još nekoliko knjiga u kojima je detaljno opisao pojedine XP prakse.

Refactoring: Improving Existing Code / Martin Fowler

Ekstremno programiranje: formulacija procesa. Od prvih koraka do gorkog kraja / Ken Auer, Roy Miller

Budući da Extreme Programming teži čistom kodu koji se lako održava, popis knjiga uključuje sve publikacije koje vas uče kako bolje programirati.

Aplikacije za implementaciju XP-a u timu

Timovi koji rade na projektima koristeći XP metodologiju koriste task managere i servise za agilne projekte. Postoji mnogo takvih proizvoda na tržištu, pogledat ćemo nekoliko primjera.

Besplatni upravitelj zadataka sa otvoreni izvor. Glavne funkcije: rad na više projekata odjednom, fleksibilan sustav upravljanja zadacima, gantogram, kontrola vremena, rad s dokumentacijom, izrada zadataka putem e-pošte itd.

Jednostavna praktična usluga za suradnja na projektima. Uključuje upravitelj zadataka, oglasnu ploču, ugrađeni chat, pohranu datoteka, kalendar

Jira

Snažna usluga dizajnirana posebno za programere agilnih projekata. Kombinira alat za praćenje bugova i uslugu upravljanja projektima. Mnoge funkcije plus sinkronizacija s drugim uslugama. Rješenja za timove različitih veličina.

Za rad na projektima. Omogućuje vam da postavite zadatke i kontrolirate proces izvršenja, međusobno se dopisujete na zadatku, postavite filtre, uzmete u obzir utrošak vremena i financija te radite s datotekama.

Presuda

Extreme Programming je fleksibilna metodologija koja se usredotočuje na visokokvalitetan, funkcionalan kod s jednostavnom arhitekturom. Njegova je svrha smanjiti razinu neizvjesnosti u projektima i uistinu fleksibilno odgovoriti na promjene u zahtjevima proizvoda.

Ova metodologija je namijenjena isključivo za teren razvoj softvera te se ne može prilagoditi za drugu djelatnost.

Ovo je jedna od najtežih metodologija za provedbu jer uključuje čak trinaest vježbi!

Nekoliko tvrtki riskira rad na čistom XP-u, ali njegove razvojne prakse su najpopularnije u agilnim projektima. A ovo je snažan argument u prilog njihovoj učinkovitosti.

Nitko vas ne tjera da implementirate XP po principu sve ili ništa. Na kraju krajeva, agilne metodologije moraju biti fleksibilne u svojoj primjeni – skrojene prema potrebama određenog tima i projekta.

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

Prava i uloge

U Extreme Programmingu sve su uloge jasno opisane. Svaka uloga dolazi s karakterističnim skupom prava i odgovornosti. Ovdje postoje dvije ključne uloge: kupac i programer.

Kupac

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

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

Kako bi uspješno ostvario svoja prava, kupac se mora osloniti na podatke koje dostavljaju programeri.

Developer

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

• steći dovoljno znanja o temama koje treba programirati;
• moći razjasniti detalje tijekom procesa razvoja;
• pružiti indikativne, ali iskrene procjene truda potrebnog za svaku značajku ili korisničku priču;
• prilagoditi procjene u korist točnijih tijekom procesa razvoja;
• dati procjenu rizika povezanih s korištenjem određenih tehnologija.

Uloge unutar uloge

Svaka od osnovnih uloga Extreme Programminga može se poboljšati manjim ulogama. XP omogućuje kombinaciju uloga unutar jedne osobe.

Strana kupca

Sastavljač priča- stručnjak za predmet koji je sposoban jasno navesti i opisati zahtjeve za sustav koji se razvija. Ova osoba ili grupa ljudi odgovorna je za pisanje korisničkih priča i razjašnjavanje nesporazuma od strane programera.

Prijamnik- osoba koja prati ispravnost rada sustava. Dobra naredba predmetno područje. Odgovornosti uključuju pisanje testova prihvaćanja.

Veliki šef- prati rad svih razina, od programera do krajnjih korisnika. On kontrolira implementaciju sustava i povezana organizacijska pitanja. Može biti i investitor u projektu.

Strana programera

Programer- osoba uključena u kodiranje i dizajn niske razine. Dovoljno je kompetentan za rješavanje tekućih razvojnih problema i davanje poštenih procjena planiranih zadataka.

Instruktor- iskusan programer s dobrim poznavanjem cjelokupnog procesa razvoja i njegovih tehnika. Odgovoran za obuku tima u aspektima razvojnog procesa. Provodi i prati ispravnu provedbu korištenih procesnih metoda. 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 obraća pažnju na ideje ostalih članova tima.

Posmatrač- član razvojnog tima, od povjerenja cijele grupe, koji prati tijek razvoja. Uspoređuje preliminarne procjene troškova rada sa stvarno utrošenim, izvodeći kvantitativne pokazatelje učinka tima. Ovo su kao Prosječna brzina te postotak izvršenih i planiranih zadataka. Ova informacija dostaviti kupcu za pravovremenu kontrolu situacije. Neke od tih informacija nenametljivo se pružaju programerima, tako da oni znaju status projekta, gdje se pojavljuju poteškoće i što se još može učiniti.

Diplomata- druželjubiva 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 za sustav. Diplomat regulira i pojednostavljuje komunikaciju između kupaca i programera. Važna je poveznica na sastancima. Sprječava propuste, uzburkane strasti i nepotrebne svađe. Diplomat ne može nametati svoje mišljenje onima koji raspravljaju.

Vanjske uloge

Konzultant- stručnjak sa specifičnim tehničkim vještinama za pomoć programerima s problemima koje je teško riješiti. Obično se donosi izvana.

Pravila ekstremnog programiranja

Konvencija kodiranja

Dio ste tima koji već duže vrijeme radi na ovom projektu. Ljudi dolaze i odlaze. Nitko ne kodira sam i kod pripada svima. Uvijek će biti trenutaka kada ćete morati razumjeti i prilagoditi tuđi kod. Programeri će ukloniti ili promijeniti dvostruki kod, analizirati i poboljšati klase drugih ljudi itd. S vremenom će biti nemoguće reći tko je autor pojedine klase.

Stoga svi moraju poštovati zajedničke standarde kodiranja - formatiranje koda, imenovanje klasa, varijabli, konstanti, stil komentara. Na taj način ćemo biti sigurni da kada mijenjamo tuđi kod (š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 važno koje. Pravilo je da ih svi poštuju. Oni koji im se ne žele povinovati napuštaju momčad.

Kolektivno vlasništvo koda

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

Na prvi pogled izgleda kao kaos. Međutim, uzimajući u obzir da je barem bilo koji kod kreiran od strane nekoliko programera, da Unit testovi omogućuju provjeru ispravnosti unesenih promjena i da stvaran život U svakom slučaju, na ovaj ili onaj način morate 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.

Sjednica CRC-a

Upotrijebite kartice razreda, odgovornosti, suradnje (CRC) da biste dizajnirali sustav kao tim. Korištenje kartica olakšava učenje razmišljanja u smislu objekata, a ne funkcija i postupaka. Kartice također dopuštaju više ljudi koji će sudjelovati u procesu dizajna (idealno cijeli tim), a što više ljudi radi na dizajnu, to više zanimljive idejeće se donijeti.

Svaka CRC kartica predstavlja instancu objekta. Klasa objekta može se napisati na vrhu, odgovornosti na lijevoj strani, interakcije na desnoj. Kažemo "može biti napisano" jer kada je sesija CRC-a u tijeku, sudionici obično trebaju mali broj kartica s imenima razreda i ne moraju ih nužno potpuno ispuniti.

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

Kako bi se vratio red, često se koristi ograničavanje broja istodobnih interakcija na dva.

Kupac

Jedan od zahtjeva XP-a je da je korisnik uvijek dostupan. On ne bi trebao samo pomagati razvojnom timu, već biti 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 vam dugo trebati, a kupčev ured vam može pokušati dati nekog pripravnika kao stručnjaka. Trebate stručnjaka.

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

Tijekom planiranja izdanja, korisnik treba razgovarati o izboru korisničkih priča koje će biti uključene u planirano izdanje. Možda će biti potrebno dogovoriti i samo razdoblje puštanja. Kupac donosi odluke vezane uz poslovne ciljeve.

Odaberite najjednostavnije rješenje

Jednostavan dizajn uvijek je lakše implementirati od složenog. Stoga uvijek birajte najjednostavnije rješenje koje može funkcionirati. Ako vam je nešto komplicirano, zamijenite to nečim jednostavnim. Uvijek se ispostavi da je brže i jeftinije zamijeniti složeni kod jednostavnim prije nego 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 kodu.

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

Funkcionalna ispitivanja

Testovi prihvaćanja (prije zvani funkcionalni testovi) pišu se na temelju korisničke priče. Oni sustav promatraju kao crnu kutiju. Kupac je odgovoran za provjeru ispravnosti funkcionalnih testova. Ovi se testovi koriste za provjeru funkcionalnosti sustava prije njegovog puštanja u proizvodnju. Funkcionalni testovi su automatizirani tako da se mogu često pokretati. Rezultat se prijavljuje timu i tim je odgovoran za planiranje popravaka funkcionalnih testova.

Č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 držati promjene duže od jednog dana. Čestom integracijom izbjegava se otuđenje i fragmentacija u razvoju, gdje programeri ne mogu komunicirati u smislu razmjene ideja ili ponovno koristiti kodirati. Svi bi trebali imati najnoviju verziju.

Svaki par programera trebao bi doprinijeti svojim kodom što je prije moguće. To može biti kada svi UnitTestovi prođu 100%. Podnošenjem izmjena nekoliko puta dnevno, probleme integracije smanjujete gotovo na nulu. Integracija je aktivnost "plati sada ili plati više kasnije". Stoga, integracijom promjena dnevno u malim dijelovima, 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 izmjene dulje od jednog dana, to je jasan pokazatelj ozbiljnog problema. Morate odmah shvatiti što se događa. Cjelokupno iskustvo XP timova govori da je razlog kašnjenja uvijek loš dizajn i uvijek ga se kasnije mora ponovno raditi.

Planiranje ponavljanja

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

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

Programeri raščlanjuju zadatke i procjenjuju koliko je vremena potrebno za njihovo dovršenje. Dakle, svaki programer procjenjuje koliko će mu zadatak oduzeti. Važno je da konačnu ocjenu opsega radova donosi sam izvođač.

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

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

Pratite brzinu projekta i korisničkih priča na čekanju. Moguće je da će se plan izdanja morati ponovno izraditi svaka tri do pet ponavljanja. 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.

Ponavljanja

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

Ne planirajte zadatke unaprijed. Umjesto toga skupljajte Planiranje ponavljanja na početku svake iteracije planirati što će se učiniti. Također se smatra kršenjem pravila preduhitriti se i učiniti nešto što nije planirano u ovoj iteraciji. Tako postaje moguće držati promjenjive zahtjeve Kupca pod kontrolom.

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, tada ponovno prikupite planiranje ponavljanja i ponovno procijenite zadatke te odgodite neke od zadataka.

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

Zamijenite zadatke

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

Cross Training je obično važan aspekt u tvrtkama koje pokušavaju izbjeći koncentraciju znanja u jednoj osobi. Kretanje ljudi kroz kod u kombinaciji s programiranje u paru tiho radi Cross Training za vas. Umjesto da jedna osoba 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 da čekate da "guru" završi s radom na kritičnom dijelu koda, nekoliko programera može raditi na njemu istovremeno.

Prilikom pokretanja novog ponavljanja svaki programer mora prijeći na novi zadatak. Programiranje u paru pomaže u prevladavanju problema s uključivanjem (što znači da novi programer može početi raditi u paru s iskusnim programerom na terenu).

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

Ostavite optimizaciju za kasnije

Nikada ništa ne optimizirajte dok kodiranje nije dovršeno. Nikada ne pokušavajte pogoditi gdje će biti uska grla u izvedbi. Mjera!

Neka radi, zatim neka radi ispravno, a zatim neka radi brzo.

Programiranje u parovima

Sav kod za proizvodni sustav (a to znači s izuzetkom probnih rješenja) napisan je u parovima. Dva programera sjede jedan pored drugog. Jedan tipka, drugi gleda. Mijenjaju se s vremena na vrijeme. Nije dopušteno raditi sam. Ako je iz nekog razloga drugi u paru nešto propustio (bolovao, umirovljen i sl.), dužan je pregledati sve izmjene koje je napravio prvi.

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

Refactor Ruthlessly!

Mi programeri skloni smo se držati dizajna dugo nakon što postane nespretan. Nastavljamo ponovno koristiti neodrživi kod jer još nekako funkcionira i bojimo se da ćemo ga pokvariti. Ali je li to stvarno korisno? XP smatra da to nije isplativo. Kada uklonimo redundantnost, poboljšamo zastarjeli dizajn, uklonimo neiskorištene dijelove - radimo refaktoring. Refactoring u konačnici štedi vrijeme i poboljšava kvalitetu proizvoda.

Nemilosrdno pregledajte svaki kôd kako bi vaš dizajn bio jednostavan dok ga 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 nego poliranje kompliciranog sustava.

Plan izdanja

Plan izdanja razvija se na sastanku planiranja izdanja. Planovi izdanja opisuju pogled na cijeli projekt i kasnije se koriste za planiranje ponavljanja.

Važno je da tehnički ljudi donose tehničke odluke, a poslovni ljudi poslovne odluke. Planiranje izdanja definira skup pravila koja svima omogućuju donošenje vlastitih odluka. Ova pravila definiraju način izrade plana rada koji će zadovoljiti sve.

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

Priče korisnika ispisane su na karticama. Programeri i kupac zajedno miješaju karte 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.

Izdavanje se može planirati prema vremenu ili volumenu. Kako bi se odredilo koliko korisničkih priča može biti implementirano do određenog datuma ili koliko stvarnog vremena će trebati ovaj skup zadaci koriste brzinu projekta. Ako planirate prema vremenu, pomnožite broj ponavljanja s brzinom projekta kako biste saznali koliko se korisničkih priča može implementirati. Kada planirate prema 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 datumom završetka, moglo bi biti primamljivo smanjiti procjene opsega. Ovo nikada ne biste trebali učiniti. Niske procjene sigurno će kasnije stvoriti mnogo problema. Umjesto toga, pregovarajte s upraviteljima, programerima i kupcima dok ne smislite plan izdanja s kojim se svi mogu složiti.

Česta izdanja

Programeri bi trebali objavljivati ​​verzije sustava 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 dobivanje korisnih povratnih informacija na vrijeme kako bi se utjecalo na proces razvoja. Što dulje odgađate izdavanje važnog dijela sustava, to ćete manje vremena imati da ga popravite.

Probno rješenje

Stvorite rješenja s dokazom koncepta kako biste odgovorili na složena pitanja tehnički problemi, opravdati određena tehnološka rješenja. Rizik je uključen u svaku tehnološku odluku, a probna rješenja osmišljena su da umanje taj rizik.

Napravite program koji reproducira problem koji se istražuje i zanemaruje sve ostalo. Većina probnih otopina nije namijenjena za korištenje, stoga očekujte da budu bačene. Svrha njihove izrade je smanjiti rizik od donošenja pogrešne tehničke odluke ili točnije procijeniti vrijeme za implementaciju korisničke priče.

Sastanak stoji

Svako jutro održava se sastanak na kojem se razgovara o problemima, njihovim rješenjima i jačanju koncentracije tima. Sastanak se održava stojeći kako bi se izbjegle dugotrajne rasprave koje nisu zanimljive svim članovima tima.

Na tipičnom sastanku većina sudionika ne doprinosi ničemu, samo sudjeluju kako bi čuli što drugi imaju za reći. Velika količina vremena ljudi gubi se na primanje male količine komunikacije. Stoga prisustvo svih na sastancima oduzima resurse projektu i stvara kaos u planiranju.

Ovakva komunikacija zahtijeva stalni sastanak. Puno je bolje imati jedan kratki, obvezni sastanak nego mnogo dugih na koje većina programera ionako mora doći.

Ako imate svakodnevne stalne sastanke, onda bi na svim ostalim sastancima trebali biti prisutni samo oni ljudi koji su potrebni i koji će nešto iznijeti. Štoviše, moguće je čak i izbjeći neke sastanke. Uz ograničenje broja sudionika, većina sastanaka može se održati spontano ispred monitora, gdje je razmjena ideja mnogo intenzivnija.

Dnevni jutarnji sastanak nije još jedno gubljenje vremena. Omogućit će vam da izbjegnete mnoge druge sastanke i uštedjet ćete više vremena nego što na to potrošite.

Metafora Sustava

Uvijek odaberite Metaforu sustava - jednostavan i jasan koncept tako da članovi tima sve nazivaju istim imenom. Da biste razumjeli sustav i eliminirali dupli kod, iznimno je važno kako imenujete objekte. Ako možete pogoditi kako se neki objekt u sustavu zove (ako znate što radi) i zaista se tako zove, uštedjet ćete mnogo vremena i truda. Napravite sustav imenovanja za svoje objekte tako da ga svaki član tima može 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 bi trebao provjeriti sve aspekte razreda - testirati sve što možda ne radi.

Trik je u tome što se test za nastavu mora napisati prije same nastave. To znači da čim objavite prvi radni rezultat, on će biti podržan od strane sustava testiranja. Za provođenje testova je napisano poseban sustav testiranje s vlastitim sučeljem.

Jedinični test za klasu pohranjuje se u zajednički repozitorij zajedno s kodom klase. Nijedan kod se ne može objaviti bez testa jedinice. Prije objavljivanja koda, programer se mora uvjeriti da svi testovi prolaze bez grešaka. Nitko ne može dati kod ako svi ne prođu 100%. Drugim riječima, budući da su svi testovi prošli prije vaših promjena, ako imate grešaka, onda je to rezultat vaših promjena. Na vama je da to popravite. 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 nema vremena. Ali time samo obmanjujete sebe. Što je teže napisati test, to će kasnije uštedjeti više vremena. To je praksa dokazala.

Jedinični testovi dopuštaju kolektivno vlasništvo nad kodom. Oni olakšavaju pregled lošeg koda. Jedinični testovi također vam omogućuju da imate stabilan radni sustav u bilo kojem trenutku.

Korisnička priča

User Story (nešto poput korisničke priče) je opis kako bi sustav trebao funkcionirati. Svaka korisnička priča napisana je na kartici i predstavlja neki dio funkcionalnosti sustava koji ima logičan smisao s kupčeve točke gledišta. 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, ali nisu ograničeni na scenarije korištenja sustava korisničko sučelje. Za svaku priču napisani su funkcionalni testovi koji potvrđuju da je ta priča ispravno implementirana - nazivaju se i testovi prihvaćanja.

Svakoj korisničkoj priči daje se prioritet s poslovne strane (korisnik, kupac, marketinški odjel) i procjena vremena izvršenja od programera. Svaka je priča podijeljena na zadatke i određeno vrijeme kada će se početi provoditi.

Korisničke priče koriste se 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 minimum informacija potrebnih za razumnu procjenu koliko će vremena biti potrebno za njezinu implementaciju.

Za tipičnu korisničku priču potrebno je 1-3 tjedna idealnog vremena. Priča koja zahtijeva manje od 1 tjedna previše je detaljna. Priča koja traje više od 3 tjedna može se podijeliti na dijelove - zasebne priče.

Brzina projekta

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

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

Tijekom planiranja izdanja, brzina projekta koristi se 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 planirati u trenutnoj iteraciji.

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

Nema potrebe koristiti ovaj parametar kao apsolutni parametar. Nije prikladno za usporedbu produktivnosti dva projekta, jer svaki tim ima svoje karakteristike. Ovaj je parametar važan samo za tim kako bi ostao u ravnomjernoj kobilici.

Trebali biste očekivati ​​male promjene u brzini projekta tijekom rada. Ali ako se brzina značajno promijeni, potrebno je ponovno zakazati puštanje. Što prije novi sustav 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 ona ponovi. Pogreška koja se javlja na proizvodnom sustavu (već instaliranom) zahtijeva pisanje funkcionalnog testa. Stvaranje funkcionalnog testa neposredno prije dijagnosticiranja buga omogućuje korisnicima da jasno opišu problem i priopće problem programerima.

Neuspjeli funkcionalni test zahtijeva stvaranje Jedinični test. To pomaže usmjeriti napore u otklanjanju pogrešaka i jasno pokazuje kada je greška ispravljena.

Neće ti trebati

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

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