Podijeli
Ekstremno programiranje (eng. extreme programming) postoji upravo zbog sustava koji se svakih nekoliko mjeseci trebaju mijenjati. To znači da je cilj isporučivati programe onda kad su potrebni. Ekstrimno programiranje stavlja naglasak na timski rad pa su tako i menadžeri i programeri i klijenti dio tima. Programeri su ovlašteni samostalno odgovarati na promjene u korisničkim zahtjevima, čak i u završnim fazama razvoja.
Vezano uz članove tima nalazi se i jedno ograničenje ekstremnog programiranja, a to je da je primjenjivo samo na projekte s manjim brojem zaposlenika. Idealna grupa kreće se od 2 do 12 zaposlenika. U pravilu, kod projekata s dinamičnom promjenom zahtjeva ili visokim rizicima, manja grupa koja primjenjuje principe ekstremnog programiranja može biti učinkovitija nego veliki tim.
Četiri glavna procesa razvoja sustava su: planiranje, dizajn, programiranje i testiranje.
Planiranje se odnosi na dva glavna pitanja u procesu razvoja: što će biti napravljeno do određenog dana, te određivanje što se treba sljedeće napraviti.
Kod planiranja se koriste korisničke priče (eng. user stories), koje su slične korisničkim scenarijma (eng. user scenarios), a služe za potrebe planiranja izlazaka pojedinih inačica programa. Koriste se umjesto dugih dokumenata sa zahtjevima, a u njima korisnici opisuju što bi sustav trebao raditi u par rečenica (korisnikova, a ne tehnička terminologija). Za svaku korisnikovu priču potrebno je izraditi najmanje jedan test kojim će se potvrditi ispunjenje korisnikove priče. Svrha ovih priča je da se procijeni trajanje implementacije, tj. prije same implementacije, programeri moraju dobiti detaljnije specifikacije. Svaka korisnička priča trebala bi prema procjeni trajati 3 tjedna, a ako traje dulje treba ju razdijeliti na više priča. Na kraju je potrebno imati 80 korisničkih priča (plus/minus 20) za planiranje.
Na zajedničkom sastanku kreira se raspored verzija sustava. Taj raspored služi da bi se kreirali planovi za svaku pojedinačnu iteraciju. Preporuka je često izdavanje verzija koje ne trebaju biti značajno poboljšane, samo je važno otkriti funkcionalnosti od koji korisnik ima koristi za poslovanje te ih isporučiti čim prije. Sustav se razvija u iteracijama koje traju 1 do 3 tjedna pri čemu one trebaju biti približno iste duljine. Sve programske aktivnosti nije potrebno planirati na samom početku projekta već se aktivnosti planiraju na početku pojedine iteracije. To je takozvano JIT (eng. Just In Time) planiranje iteracija koje omogućava brzo praćenje promjena korisničkih zahtjeva.
Svaki programer procjenjuje koliko mu je idealnih radnih dana potrebno za uspunjenje zadatka, a ako je procjena veća od 3 radna dana, zadatak je potrebno rasčlaniti na manje zadatke. U slučaju da unutar iteracije nije moguće izvršiti zadatke, rokovi se ne smiju pomicati, stoga treba izbaciti neke od zadataka.
Potrebno je mjeriti i brzinu razvoja projekta. Pri tome se procjenjuje trajanje ispunjenja korisničkih priča u pojedinim iteracijama na temelju prijašnjih iteracija.
Jednostavnost je jedan od glavnih ciljeva prilikom dizajniranja sustava jer je uz jednostavan dizajn projekt uvijek moguće brže izvršiti. U tu svrhu nikad se ne bi trebale dodavati nove funkcionalnosti prije za to predviđenog roka.
Prilikom dizajniranja potrebno je koristiti prikladne termine za konzistentno definiranje klasa i objekata. Za potrebe dizajniranja sustava poželjno je koristiti CRC (eng. Class-Responsiblity Collaboration) kartice. One se koriste za dizajniranje objektno orijentiranih programa i pomažu shvatiti koje su programske klase potrebne te kako će one međusobno djelovati.
U slučaju kompliciranih tehničkih ili dizajnerskih problema potrebno je kreirati potencijalna zamjenska rješenja. Cilj tomu je smanjiti rizik mogućih tehničkih problema ili povećati pouzdanost procjena korisničkih priča.
Prilikom dizajniranja potrebno je paziti da se ne dodaju nepotrebne funkcionalnosti, obzirom da se samo 10% funkcionalnosti dodanih na ovaj način ikada koristi. U konačnici, u procesu dizajna neophodan dio posla je i redizajn, odnosno, eliminacija nepotrebnih i suvišnih funkcionalnosti.
Tijekom razvoja sustava važan je preduvjet dostupnost krajnjeg korisnika, ne samo kako bi pomogao razvojnom timu, već bio i član razvojnog tima, budući da sve faze XP razvoja zahtjevaju komuniciranje s korisnicima.
Preporuka je da se unaprijed kreiraju osnovni testovi za provjeru funkcionalnosti prije same izrade programskog koda. Time se ne produžuje izrada samog osnovnog programskog koda, a kasnije nije potrebno trošiti dodatno vrijeme na izradu testova.
Još jedna od preporuka, koja programerima na početku može biti čudna, jest programiranje u parovima. To znači da jedna osoba piše programski kod dok ga druga kontrolira. U konačnici, to većinom rezultira višom razinom kvalitete sustava, te jednakom količinom funkcionalnosti kao da su programeri radili odvojeno.
Isto tako vrlo važno je da se u uključivanje novog programskog koda u cjeloukupni sustav koristi sekvencijalna integracija. To znači da se zabranjuju slučajevi u kojima bi različiti programeri istodobno uključivali svoj programski kod i testirali ga.
Što se tiče integracije programskog koda, pravilo je da se programski kod često integrira. Preporuka je da se programski kod uključuje u sustav svakih nekoliko sati te da se ne čeka duže od jednog dana, ali po principu sekvencijske integracije. Važno je da tijekom projekta postoji tzv. zajedničko vlasništvo nad programskim kodom. To znači da svi programeri mogu slobodno mijenjati gotovi programski kod koji nisu sami napisali, kako bi dodali novu funkcionalnosti ili ispravili pogreške.
Sve dodatne optimizacije treba ostaviti da budu završne aktivnosti, a zaposlenici na projektu bi trebali izbjegavati prekovremeni radi.
Jedna od temelja ekstremnog programiranja je korištenje osnovnih testova za provjeru ispravnosti implementiranih funkcija. Za samo testiranje potrebno je ili uzeti ili razviti vlastito programsko okruženje pomoću kojega će se moći kreirati automatizirani testovi. Testove je potrebno kreirati prije razvoja samog programskog koda sustava. Stoga razvijeni programski sustav ne može biti integriran u cjeloukupni sustav ako ga ne prate popratni testovi.
U slučajevima kada se u programskom kodu otkrije neki tip pogreške potrebno je kreirati testove za pogrešku kako se ne bi kasnije u drugim modulima ponovila. Iz definiranih korisničkih priča kreiraju se testovi za prihvaćanje sustava. Klijent definira scenarije koje je potrebno testirati na temelju definiranih korisničkih priča, a za jednu priču moguće je definirati jedan ili više testova.
Vezano uz testiranje kao osnovu razvoja programskog paketa, sve češće se spominje i princip razvoja testiranjem (eng. Test Driven Development), a princip je isti kao i kod ekstremnog programiranja. Prije samog razvoja, a na temelju definiranih funkcionalnosti, izrađuju se osnovni testovi koje sustav u razvoju mora zadovoljiti.
© 2024. INFO NOVITAS | EU FONDOVI I PROJEKTI
Privacy: Privatnost | Cookies: Kolačići
