SlideShare une entreprise Scribd logo
1  sur  18
1
BOSNA I HERCEGOVINA
REPUBLIKA SRPSKA
VISOKA ŠKOLA ZA EKONOMIJU I INFORMATIKU
PRIJEDOR
SCRUM METODOLOGIJE
NASTAVNI PREDMET:
PROJEKTOVANJE INFORMACIONIH SISTEMA
MENTOR: STUDENT:
Doc.dr Radovan Vladisavljevic Semir Talic
Indeks br.: 09
U Prijedoru, juni 2021. Godine
2
SADRZAJ
Contents
UVOD........................................................................................................................................... 3
AGILNE METODE........................................................................................................................... 4
SCRUM......................................................................................................................................... 6
EKSTREMNO PROGRAMIRANJE.....................................................................................................10
SCRUMU NASTAVI PROGRAMSKOG INZINJERSTVA........................................................................11
SCRUMTIM .................................................................................................................................12
ZAKLJUCAK ..................................................................................................................................17
LITERATURA.................................................................................................................................18
3
UVOD
Programskoinženjerstvoobuhvaćaznanje,alate i metode zadefiniranje zahtjeva
programske podrške,i obavljanjazadatakadizajna,konstrukcije,testiranjai održavanja
programske podrške.
Informacijski sustavje skupmeđusobnopovezanihkomponenatakoje cijeli timmora
znati prikupiti izprikladnihizvoraupoznatihsdomenom, obrađivati uskladus
karakteristikamadomene te izdobivenihpodatakaznati vrednovati ključne elementei
pohraniti ihza buduće korištenje.
Pri izradi kvalitetne programske podrškeje moguće pogriješiti najakopunonačina,u
različitimfazamasamogprojekta.Upravozbogtoga svaki peti projektne dođe dosvogkraja
većpropadne u nekoj odfazarazvoja.Svaki drugi projektse nađe na kušnji baremjednom,
a često i više putatijekomprocesai ne završi u skladusa svimzahtjevima,dokse samooko
30 % projekatasmatrauspješnima.Najčešće projektiipakzavrše noprekorače ili rokili
planirani trošak,i to najčešće za otprilike dvostruki iznos.
Mnogi surazlozi te statistike,nonajčešće se ti uzroci mogupodijeliti unekolikoskupina.
Ponekadse radi o nespremnostinaručiteljazaosiguranjempotrebnihsredstavate tada
projektpropadne zbognezadovoljenihfinancijskih izdavanja.Sljedeći je razlogpropasti
projekatanespremnostnapromjene.Vrlorijetkoili gotovonikadaprojektne teče ucijelosti
kakoje u početkupretpostavljeno.Zbogtogaprojektnitimi načinizrade programskog
rješenjamorajubiti dovoljnofleksibilni i spremninastalne i svakodnevne promjenete se
prilagođavati svakoj novonastalojsituaciji.
Vrloveliki problemje i nedostatakkomunikacije i transparentnosti utimu.Članovi svih
odjelamorajubiti ustalnomkontaktui razmjenjivati iskustvai prijedloge,te takođerbiti u
kontaktus naručiteljemi krajnjimkorisnicimakakobi svi dionici sudjelovali uproizvodnom
procesu.
4
AGILNE METODE
Agilne metode su jako često korišten pojam koji se odnosi na mnoge pristupe i
metodologije koje se koriste u razvoju programske podrške. Njih razvijaju vodeći stručnjaci
u području razvoja programske podrške te navode osnovna načela koja, kada ih se timovi
pridržavaju, povećavaju vjerojatnost uspjeha na projektu.
Najveći problem konvencionalnih metoda poput vodopadnog modela je nedovoljna
fleksibilnost. Uz svoju krutu strukturu ne dopuštaju promjenu zahtjeva i okolnosti razvoja
proizvoda koji su utkani u samu srž razvoja programske podrške. Stoga agilne metode
prigrljuju stalne promjene, i oblikuju se tako da se upravo njima mogu prilagoditi.
Osnovna načela agilnih metoda su donesena 2001. godine na sastanku skupine vodećih
softverskih stručnjaka na skijalištu Snowbird u Saveznoj Državi Utah, te se taj sastanak
smatra začetkom agilne metodologije. U svom su proglasu naglašavali kako su pojedinci
i interakcije među njima važniji od procesa i alata koji se koriste u razvoju te kako je
funkcionalnost i ispravnost softvera važnija od sveobuhvatne dokumentacije. Također su
se složili da je suradnja s naručiteljem važnija od pregovora o ugovoru te kako je odziv na
promjene u cjelokupnom procesu važniji o d praćenja plana razvoja.
Svi principi navedeni u manifestu o agilnim metodama se mogu implementirati u
različitoj mjeri i na različite načine, stoga postoji mnogo vrsta agilnog razvoja. Neke od
popularnijih metoda su: Adaptivni razvoj softvera (ASD), Agilno modeliranje, Agilni
ujedinjeni proces(AUP), Ekstremno programiranje, Razvoj vođen karakteristika (FDD), Lean
razvoj softvera, Kanban, Rapidni razvoj aplikacija (RAD), Scrum i drugi.
U svom ću se radu posvetiti Kanbanu, Scrumu i Ekstremnom programiranju jer su oni
najzastupljeniji kako u poslovnom svijetu, tako i na studentskim projektima. Kako bi se
mogli što efikasnije koristiti na projektima potrebno je koristiti adekvatne alate. U nastavku
rada se nalazi osvrt na neke od najpopularnijih alata koji se koriste na malim
projektima te su time prikladni za studentske projekte, te također nešto složenije programe
s više mogućnosti koji se koriste u velikim kompanijama.
5
Kanban
Kanban svoje korijene vuče iz ranih 1940-ih kada je razvijen od strane inženjera Taiichija
Ohnoa u Japanskoj automobilskoj kompaniji Toyota. Naziv se može prevesti kao kartica ili
tablica, a razvijen je kako bi se poboljšala produktivnost rada u skladu s „Just-In-Time“
pristupom, tako da se cijeli distributivni lanac sa svim svojim elementima popiše i
standardizira, te se olakša upravljanje svim procesima.
David J. Anderson je 2004. primijenio Toyotina načela na IT industriju na način da je
kreirao danas široko korištenu Kanban ploču. Važno je napomenuti kako Kanban sam po
sebi nije metodologija, te ne definira nikakve načine izrade programskog rješenja. Njegovim
korištenjem se može unaprjeđivati razvojni proces članova tima te im pomoći da nauče
bolje raspoređivati posao i vlastito vrijeme.
Glavna značajka Kanbana je vizualizacija razvojnog procesa pomoću fizičke ili digitalne
ploče. Ona je podijeljena na stupce koji predstavljaju različite faze dovršenosti zadatka, od
kojih se najčešće koristi jednostavna podjela na zadatke koji se još nisu ni počeli izvršavati
(to do), one koji se izvršavaju (doing) i one koji su dovršeni (done). Iako je podjela
jednostavna, daje jako dobar uvid u trenutnu količinu posla te vrlo jednostavno omogućava
svim članovima tima te također i vanjskim promatračima da vide u kojoj je fazi projekt.
6
SCRUM
Scrum je naziv za skup procesa koji se koristi za inkrementalni razvoj softvera koji
propisuje mali broj artefakata koji se moraju formirati i održavati te događaja kojise moraju
slijediti kako bi se smanjilo vrijeme potrebno za upravljanje i ostalo više vremena za razvoj.
Svaka iteracija u Scrumu-u se naziva sprint i najčešće traje jedan ili dva tjedna.
Ovisno o vrsti projekta, rezultat svakog sprinta može biti neki modul rješenja, ili isporučiva
verzija proizvoda koja se šalje na testove prihvatljivosti.
Clanovi Scrum tima
Pokazalo se da su najefikasniji timovi veličine 7 +/- 2 člana. Scrum prati taj princip,
uz dodatak toga da na projektu može raditi više razvojnih ekipa, koje funkcioniraju kao
samoorganizirajući timovi, te svi zajedno rade na ostvarivanju istog zajedničkog cilja.
Najodgovorniju i najbitniju ulogu u Scrum timu ima vlasnik proizvoda (Product
owner). On je zadužen za izradu plana projekta, postavljanje prioriteta na zahtjeve i
zadatke, formiranje troškova te uspješan povrat investicije. On predstavlja klijenta odnosno
naručitelja te upravu, te u razgovoru s klijentom piše korisničke priče koje se pohranjuju u
popis stavki za proizvod, odakle se dalje posao razbija na manje zadatke.
Kako bi cijeli proces razvoja tekao što efikasnije i uspješnije, potrebno je imenovati
Scrum mastera. Njegova je uloga da koordinira sve timove te se brine o napretku projekta
i uključenosti vlasnika proizvoda u cijeli proces. On se ne bavi formiranjem zadataka timova
i pojedinaca, već oni sami raspodjeljuju posao među sobom. Također ne donosi tehničke
odluke, no pomaže vlasniku proizvoda u održavanju popisa stavki za proizvod i brine se da
je količina posla adekvatno raspodijeljena u svakom sprintu. Naposljetku Scrum tim čini
razvojni tim. Njihova je uloga pretvaranje kompleksnih
korisničkih priča u zadatke koji se mogu obaviti u razumnoj jedinici vremena. Tim se
zadatcima određuju težine i procjene potrebnog vremena za izradu, te se dalje raspoređuju
među članovima tima. Rad razvojnog tima nadgleda Scrum master koji im također mora
olakšati posao kroz efektivno usmjeravanje, te se pobrinuti da tim ima sva potrebna
sredstva za uspješno izvršavanje zadataka.
7
Scrum artefakti
Artefakti ključni za uvođenje Scrum metodologije su: popis stavki za proizvod
(product backlog), popis stavki za sprint (sprint backlog), zadatak (task) te inkrementi
rješenja (Potentially Shippable Increment, kraće PSI).
Zadatak je osnovna jedinica posla u razvoju softvera te predstavlja neku korisničku
priču ili neki njen dio ako je zbog svoje kompleksnosti dekomponirana. Svaki zadatak mora
biti jasno definiran svojim nazivom, kratkim opisom koji točno određuje način validacije
izvršenosti zadatka, prioritet, osobu kojoj je dodijeljen te procjenu vremena potrebnog za
njegovo izvršavanje. Neki od ovih atributa se ne dodjeljuju odmah prilikom formiranja, već
u trenutku kada se zadatak dodijeli članu tima te počne izvoditi. Kako bi se lakše pratio
napredak potrebno je formirati zadatke manjeg opsega koji traju najviše jedan dan posla.
U popisu stavki za proizvod se u svakom trenutku nalaze svi preostali i nedovršeni
poslovi te funkcionalnosti proizvoda koje još nisu implementirane. Prilikom inicijalizacije
projekta ga vlasnik proizvoda mora napuniti, te on postaje vidljiv svim dionicima projekta.
Tijekom razvoja se iz njega miču dovršeni poslovi, te se u njega dodaju dodatni poslovi koje
netko od dionika prepozna kao potrebne.
Svaka iteracija Scrum projekta, odnosno sprint, ima svoje ciljeve i zadatke. Oni su
reprezentirani popisom stavki za sprint u koji se dodaju zadatci iz popisa stavki za proizvod.
Prilikom prebacivanja zadatka u popis stavki za sprint potrebno je provjeriti je li procjena
vremena bila ispravna te član tima koji preuzima taj zadatak mora to naznačiti i brinuti se
da promijeni status zadatka s obzirom na njegov napredak na njemu. Za efikasniji pregled
nad svim zadatcima se najčešće koristi ploča na koju se upisuju svi zadatci, te koja je
podijeljena u sekcije koje reprezentiraju različite faze dovršenosti tih zadataka. Nema neke
obavezne i univerzalne podjele tih sekcija, no najčešće se koriste neka od stanja: za napraviti
(to do), dodijeljeno (assigned), u izradi (in progress), za potvrdu (to verify), testira
se (in testing) i dovršeno (done).
Rezultat svakog inkrementa projekta bi trebao biti isporučivi proizvod, PSI. Periode
u kojima bi tim trebao prezentirati PSI određuje vlasnik, dok je tim taj koji bi se morao
pobrinuti oko zadovoljavanja rokova kroz izvršavanje zadataka potrebnih za dovršavanje
dogovorenih zahtjeva u trenutnom inkrementu.
8
Zivotni ciklus Scrum projekta
Scrum projekt se dijeli u tri faze: prije igre (pre-game), razvoj (game) i poslije igre
(post-game). Tijekom prva faze se obavljaju planiranje, dizajn i izrada arhitekture. Također
se kreira i inicijalno puni popis stavki za proizvod koji se dalje modificira u sljedećoj fazi. Za
vrijeme tzv. igre se ispunjavaju svi zahtjevi dok se u potpunosti ne dovrše svi zadatci čime
završava inkrement projekta. Zatim je u trećoj fazi potrebno napraviti integraciju svih
napravljenih modula i testirati ispravnost izrađenog proizvoda.
Kako bi se sve faze projekta lakše pratile i vodile, napravljen je model timskih
sastanaka. Svaki sprint ima sastanak planiranja za sprint (sprint planning) na kojem se
određuje opseg sprinta, formira se popis stavki za sprint te se zadatci dodjeljuju članovima.
U praksi ovi sastanci traju oko sat vremena za sprintove duljine tjedan dana, te dva do tri
sata za dulje sprinteve.
Svaki dan se odrađuju 15-minutni dnevni scrum (daily scrum) sastanci na kojima
članovi tima iznose svoj trenutni napredak i dnevni plan te izvještavaju o potencijalnim
problemima. Ova vrsta sastanaka se ne odvija u konferencijskoj dvorani, već se članovi tima
okupe negdje unutar svog prostora i odrade ga na nogama, zbog čega se ovi sastanci još
nazivaju i standup sastanci.
Na kraju svakog sprinta se održava sastanak pod nazivom pregled sprinta (sprint
review) koji označava završetak inkrementa te se podnosi izvještaj obavljenog posla i
spremnosti proizvoda za prezentiranje kupcu. Vlasnik odrađene korisničke priče uklanja iz
popisa stavki za sprint, dok nedovršene prenosi u sljedeći sprint.
Nakon tog sastanka članovi tima bez prisustva vlasnika na sastanku osvrta na sprint
(sprint retrospective) odrađuju samo evaluaciju odrađenog posla i predlažu ideje za
povećanje učinkovitosti.
9
Usporedba Scruma sa vodopodadnim modelom
Istraživanja su pokazala kako su projekti na kojima se koristi Scrum metodologija
puno efikasnije i štede novac u odnosu na projekte na kojima se koriste konvencionalne
metode poput vodopadnog modela. Dok kod klasičnih metoda samo 14% projekata u
potpunosti uspije, a čak 29 % ih propadne i ne završi, kod Scruma čak 42 % projekata završi
uspješno, a samo 9 % propadne. Uz to, u čak 93% slučajeva su sudionici Scrum projekata
rekli da su lakše predviđali potrebno vrijeme te im je u 44% slučajeva korištenje Scruma
uštedjelo novac, a u 70% slučajeva vrijeme.
Scrum na studentskom projektu
Scrum se na studentskom projektu ne može u potpunosti implementirati. Razlog tome
je što se članovi tima ne nalaze na dnevnoj bazi pa ne mogu imati redovite dnevne sastanke.
Međutim, ostali aspekti poput planiranja i podjele posla na sprintove su svakako praksa
koja bi se mogla lako uvesti i od koje bi projekt imao brojne koristi. Studenti bi se što ranije
trebali upoznati sa Scrumom jer će ga u svojoj profesionalnoj karijeri gotovo sigurno
koristiti prije ili kasnije.
10
EKSTREMNO PROGRAMIRANJE
Ekstremno programiranje je metoda koja manju važnost daje strukturi rada, a veću
kvaliteti i brzini izrade proizvoda. Za svoj cilj ima, kao i ostale agilne metode, omogućiti timu
veću sposobnost prilagodbe na promjenjive zahtjeve projekta te brzu isporuku verzija
proizvoda kroz kontinuirano izbacivanje verzija programskog rješenja.
Faze ekstremnog programiranja
Ekstremno je programiranje definirano pomoću 6 osnovnih faza:
• Istraživanje
o korisnici bilježe svoje priče na kartice, svaka od njih sadrži jednu mogućnost
programa
o traje od nekoliko tjedana do nekoliko mjeseci pri čemu se skup priča
redovito nadopunjuje
o projektni tim se upoznaje s alatima, tehnologijom i postupcima projekata te
se izrađuje prototip sustava
o Planiranje - određuju se prioriteti priča, određuje se vrijeme potrebno za
implementaciju pojedine priče te se planira doseg prvog malog izdanja
o traje nekoliko dana, a rok za izdavanje prvog malog izdanja iznosi do dva
mjeseca
• Iteracije do izdanja
o klijent određuje kartice koje će se koristiti pri svakoj narednoj iteraciji
o svaka iteracija traje jedan do četiri tjedna, pri čemu se na kraju svake izvode
testovi prihvatljivosti
o svaka iteracija stvara sustav koji obuhvaća cjelokupnu arhitekturu sustava te
on mora biti spreman za produkciju
• Produkcija
o Vrši se dodatno testiranje i provjera performansi sustava prije isporuke
klijentu
o Razrješavaju se primjedbe na sustava te se odlučuje hoće li se primjedbe
riješiti u trenutnom izdanju
11
o Vrši se u iteracijama trajanja tri do sedam dana
• Održavanje
o Kreće od puštanja prvog izdanja u produkciju, do kraja projekta
o Može zahtijevati nove članove tima i promjenu njegove strukture
• Faza smrti
o Kada klijent više nema novih kartica s pričama te sustav zadovoljava sve
zahtjeve
o Vrijeme da se dovrši sva projektna dokumentacija
o Do nje dolazi i kada sustav ne ispunjava sva korisnička očekivanja ili postane
preskup za daljnji razvoj
SCRUM U NASTAVI PROGRAMSKOGINZINJERSTVA
S obzirom na godinu studija, od studenata su se očekivale različite razine znanja i
korištenje manjeg opsega Scruma za studente prve godine, te postupno sve veći na ostalim
predmetima. U prvoj je godini izvođenja predmeta sudjelovalo 15 timova veličine 3-5
članova. U narednim godinama je kapacitet predmeta bio 45-50 studenata s prve godine,
te 65 za studente druge godine.
Kolegij je bio organiziran za studente elektrotehnike te su oni izrađivali modele pomoću
3D printera, pri tome radeći prema načelima Scruma. Posao im je bio raspoređen u
dvotjedne sprinteve te su za praćenje rada koristili programski alat Trello. Sastajali su se od
2 do 4 puta tjedno da bi raspravili o trenutnom napretku, te su imali sastanke na početcima
i krajevima sprinteva gdje su ujedno prezentirali svoj rad i za njega bili ocjenjivani.
Profesor Pejčinović je rekao kako je prvotna ideja bila da on kao nositelji predmeta ima
ulogu vlasnika proizvoda, što se na kraju pokazalo prezahtjevnim s obzirom na broj timova
i raznovrsnosti njihovih zadataka. Drugi problem se pojavio na kolegiju za studente četvrte
godine, pošto se od njih očekivalo da su završili prethodni kolegij na nižim godinama,
međutim pokazalo se da je gotovo dvije trećine studenata bilo na međunarodnoj razmjeni,
ili su došli s nekog drugog sveučilišta, te nisu slušali kolegij koji ih je trebao pripremiti za tu
kompleksniju primjenu Scruma.
12
Spomenuti prostori za napredak kolegija su bili povezivanje studenata s nižih i viših
godina, pri čemu bi studenti nižih godina projektni timovi, dok bi studenti viših godina
preuzeli uloge vlasnika proizvoda i Scrum mastera te usko surađivali sa studentima i
profesorima i sudjelovali u ocjenjivanju rada studenata. Na taj bi se način mogao i povećati
broj timova te olakšati teret s profesora.
Studentske ankete su pokazale kako se studentima predmet pokazao kao vrlo koristan,
te su nakon njegovog dovršetka stekli korisna znanja o agilnim metodama i modernom
inženjerstvu.
Najvrjednija korist ovog predmeta je bilo praktično znanje koje su studenti dobili te
upoznavanje s profesionalnim okruženjem. Studenti su također razvijali prijeko potrebne
vještine timskog rada te raspoređivanja posla i organizacije vremena. Profesor je s druge
strane imao priliku vidjeti koliko korisni mogu biti alati za praćenje rada za kvalitetniji uvid
u rad studenata, te mogu li olakšati ocjenjivanje.
SCRUM TIM
Za razliku od klasičnih metoda upravljanja projektima, Scrum ne posjeduje i nema
potrebu za voditeljem projekta, projektnim menadžerom ili timskim voditeljem.
Scrum tim se sastoji od tri glavne uloge:
- Vlasnik proizvoda
- Scrum Master
- Razvojni tim
Vlasnik proizvoda
Jedna od najvažnijih uloga, kako bi Scrum metodologija bila uspješna u realizaciji i
stvaranju projekta, čini vlasnik proizvoda, koji čini sučelje između tima i drugih
zainteresiranih strana odnosno Stakeholder-a. Može se reći da u tvrtkama koje koriste
Scrum metodologiju zadaci i odgovornost koju ima vlasnik proizvoda nikada nisu isti.
Ulogu vlasnika proizvoda preuzimaju specifične osobe sa određenim vještinama koje
moraju proći i određeni trening, kako bi preuzeli veliku odgovornost na sebe. Uloga
vlasnika tima je ujedno i najkompleksnija uloga u izvedbi te procedure.
13
Vlasnik proizvoda se često nalazi u „borbama“ na dvije strane. Dok tim u određenom
vremenskom periodu radi na projektu zaštićeni od Scrum Master-a. Vlasnik projekta
se bavi marketingom, menadžmentom ili korisnicima od kojih izvlači razne informacije
(pogled korisnika na aplikativno rješenje te njegove potrebe) koje su mu potrebne kako
bi se mogli stvoriti preduvjeti za razvoj software-a koje zatim mora što preciznije
prenijeti timu. Vlasnik proizvoda također je i odgovoran o povratu uloženih sredstava.
Zatim potvrđuje gotova rješenje, provjerava kvalitetu te dali je prihvatljivo programsko
rješenje za krajnjeg korisnika ovisno o točki gledišta.
Također odlučuje o važnosti pojedinog svojstva u odnosu na prioritete kako bi što bolje
tim shvatio kako bi proizvod trebao izgledati te koja je konačna vizija krajnjeg projekta.
Budući da tim mora što učinkovitije raditi, to vlasnik proizvoda mora brzo reagirati sa
povratnim informacijama. Stoga on ispunjava ulogu komunikatora, te je stalno u
kontaktu sa svim Stakeholder-ima odnosno zainteresiranim stranama, sponzorima te
za kraj i sa projektnim timom. Uostalom to i je njegov zadatak da koordinira financijsku
stranu razvoja proizvoda, što uspješno provodi kroz kontinuiran rad i stvaranjem
prioriteta kroz određene radnje.
Svi ti raznovrsni zahtjevi pokazuju koliko ja važan odabir odnosno izbor prave osobe
za uspješnost projekta. Vlasnik proizvoda unutar Scrum-a nije samo menadžer, već je
i vlasnik zbog čega je on direktno odgovoran za cijeli proizvod.
Biti vlasnik proizvoda znači:
- Preuzeti odgovornost za uspjeh proizvoda koji mu dostavlja razvojni tim
- Donositi poslovne odluke velikih važnosti prema prioritetima
- Voditi projekt u pravom smjeru
- Izvrstan timski igrač
- Prenijeti viziju projekta prema Razvojnom timu (Eng. Scrum team)
- Brine o potrebama korisnika i poslovnim ciljevima
- Vlasnik proizvoda mora posjedovati znanja iz različitih domena
- Kontrolira rezultate i provjerava kvalitetu proizvoda
- Brzo reagira sa povratnim informacijama
- Komunicira na kontinuiranoj osnovi sa svim zainteresiranim stranama financijerima te
timom
- Također kontrolira i cijelu financijsku stranu proizvoda odnosno projekta.
- Ima važnu ulogu u izradi te održavanju liste ,
14
te se brine da svi koji sudjeluju u projektu i razumiju radne zadatke naznačene
na njemu.
- Njegova je konačna odluka o redoslijedu zadataka razvrstanih po prioritetima iz
Product Backlog liste, te procjenjuje koliko je napora potrebno uložiti za
izvršavanje pojedinih zadataka sa liste kako bi se zadatci mogli programski
implementirati od razvojnog tima u određenom vremenskom periodu.
Scrum master
Već samo ime nam govori kako Scrum Master zapravo nije voditelj tima. Voditelj tima
najčešće predstavlja osobu koja vodi tim i postavlja zadatke, dok Scrum Master
promatra da tim izvršava zadatke prema Scrum metodologiji.
On se ne miješa u razvoj proizvoda, već sudjeluje kao savjetnik Scrum timu. Aktivno
se uključuje ako netko od članova tima ili od zainteresiranih strana (Eng. Stakeholder)
ne poštuje u cijelosti pravila Scrum-a. Dok voditelji timova često dodjeljuje zadatke i
snosi odgovornost za njihovo provođenje, iskusni Scrum master unutar cijelog procesa
daje impulse i savijete timu kako bi ih usmjerio na pravi put da bi u konačnici koristili
najbolje metode i tehnologije za dobrobit proizvoda i projekta.
Njegovo djelovanje na tim je više usmjereno prema savjetniku tima nego voditelju tima.
Glavni zadatak mu je da vodi tim kroz Scrum process te pomaže općenito razvojnom
timu da u globalu stvore uspješnu dinamiku napretka. Također organizira i moderira
sastanke, kako bi mogao utjecati na samu motivaciju i produktivnost svih članova tima.
Vjestine i poslovi koje Scrum master mora imati :
- Izvrstan voditelj
- Nadgleda i prati posao
- Izvještava i komunicira sa svim članovima
- Izvrstan poznavatelj procesa
- Kontrolira kvalitetu
- Rješava raznovrsne prepreke
- Rješava sukobe ako se pojave
- Štiti razvojni tim
15
- Daje povratne informacije o napretku.
Vrlo važan zadatak koji obavlja jest da oslobodi cijeli tim od bilo kakvih prepreka koje
bi mogle poremetiti njihov nesmetani rad. Obično se problemi mogu svrstati u tri
različite kategorije. Prvi problem sa kojim se tim npr. može suočiti jest nedostupan ili
ne spreman Hardware za bilo kakva izvođenja ili testiranja proizvoda, IT odjel ne može
omogućiti Bug tracker, ili naručeni software još uvijek nije stigao do razvojnog tima.
Još jedna od mogućih prepreka npr. jest pojavljivanje marketinškog ili prodajnog
menadžera koji opet traži da se još jedno značajno svojstvo integrira na brzinu u
proizvod. Drugi problem nastaje kao rezultat loše organizacijske strukture ili unutar
loših strateških odluka.
Takve situacije znaju nastati kada tim nije u mogućnosti održavati važne sastanke ili
postoje trzavice u odnosu između pojedinih članova tima, pa smatraju da je Scrum
Master odgovoran za pojedine članove razvojnog tima. Učestalo se javljaju takvi
problemi zbog krivog shvaćanja da je Scrum Master klasičan voditelj tima, što dovodi
do sukoba interesa što je protiv glavnog principa Scrum-a.
Razvojni tim posjeduje menadžersku ulogu unutar Scrum metodologije te je
ravnopravan prema Scrum Master-u i Vlasniku proizvoda. A drugi aspekt kao problem
može predstavljati nedovoljna propusnost interneta za novi projekt. Treći problem se
pojavljuju individualno izazvani iz različitih primjera. Nekome je potrebna pomoć oko
debugging-a
13. Netko nije u mogućnosti odraditi određene zadatke sam pa mu je
potreban još jedan član za programiranje. Također i čisti banalni primjer gdje netko
drugi ne vezan za tim mora resetirati određeni server zbog značajnih promjena na
istome. Čak i u situacijama gdje Scrum Master nije u mogućnosti samostalno riješiti
određene zahtjeve, i dalje je on odgovorna osoba koja se brine o tome da razvojni tim
ima određene kriterije za nesmetani rad.
Takav posao često iziskuje jako puno vremena, veliki autoritet i jaku kralježnicu. Na
njemu je da omogući optimalne radne uvijete za razvojni tim, te ostane odgovoran na
održavanju tih uvjeta kako bi se svi ciljevi unutar sprinta ostvarili.
16
Razvojni tim
Za razliku od drugih razvojnih metodologija unutar Scrum-a, razvojni tim nije samo
izvršni organ koji prima svoje zadatke od voditelja projekta, već samostalno odlučuju
koje prohtjeve odnosno nadogradnje potrebne krajnjim korisnicima odrađuju unutar da
izrađuju proizvod, on im osigurava optimalne uvijete za samostalni rad te ih
savjetuje pazeći da se ne krše Scrum pravila. Promijenjena percepcija uloga je
najbitniji aspekt ovakve metodologije kada netko želi shvatiti Scrum kako bi ga uveo u
tvrtku koja se bavi razvojem. Razvojni tim se u idealnim uvjetima sastoji od 7 ± 2
članova.
Broj članova može biti i troje, ali nikako ispod tri člana jer postoji velika mogućnost da
nemaju dovoljno znanja ili vještina kako bi mogli na vrijeme do kraja sprinta izvršiti svoj
posao. U slučaju da je preko devet članova onda postoji vrlo velika mogućnost da se
pojavi problem oko koordinacije. Veliki broj članova unutar tima izaziva veliku
složenost za empirijski proces upravljanja. U ove brojke nisu uključeni Vlasnik
proizvoda niti Scrum Master.
Članovi tima posjeduju različite vještine te se međusobno podupiru kako nitko od njih
ne bi predstavljao usko grlo tokom razvoja proizvoda. Najčešći tipičan razvojni tim
uključuje mješavinu softverskih inženjera, arhitekata, programera, analitičara, eksperta
za osiguranje kvalitete, programski testeri, i dizajneri grafičkog sučelja. Vrlo čvrsti
Scrum timovi pristupaju svakom proizvodu sa čvrstim stavom „mi“. Između njih mora
vladati vrlo jaki kolegijalni odnos i kvalitetan timski rad kako bi bili što više usredotočeni
na proizvod koji tokom jednog sprinta moraju odraditi.
Kao što smo već spomenuli, Scrum tim sam upravlja planom za svaki sprint. Oni
predviđaju koliko posla imaju te koliko im je vremena potrebno za određeni razvoj
unutar jednog sprinta, koristeći se iskustvom iz vlastite povijesti u prethodnim
sprintevima. Zadržavajući iteracije sprinteva na jednakim duljinama razvojni tim dobiva
vrlo korisne povratne informacije o tome koliko vremena moraju potrošiti za razvoj
određenih funkcionalnosti proizvoda. Na taj način oni s vremenom sve preciznije mogu
prognozirati potrebno vrijeme i količinu posla koji moraju odraditi u toku sprinta.
17
ZAKLJUCAK
Scrum metodologija u današnjem modernom dobu predstavlja vrlo učinkovit pristup
razvoju kompleksnih proizvoda. Samim time što u kratkim vremenskim rokovima
nastaju funkcionalni inkrementi nekog proizvoda pa ih se ujedno može i isporučiti
krajnjim korisnicima. Pošto je razvoj koncipiran na manje iteracije razvoja dijelova
proizvoda, cijeli proces se sa lakoćom unutar kratkih vremenskih perioda može
prilagoditi potrebnom stanju na tržištu. Sam pristup ima najveći fokus prema članovima
tima koji uz veliku fleksibilnost u dinamičnoj okolini djeluju na sam proizvod.
Osim kod razvoja proizvoda ovaj se proces može integrirati i u kompleksne radne
okoline, gdje prevladava jako velika i brza dinamika na svako dnevnoj razini.
Korištenjem Scrum-a dobiva se mogućnost dobro organizirati jednu ili više skupina
ljudi koji rade na određenom projektu kako bi povećali efikasnost njihovog rada i bolje
organizirali cijeli pristup radu.
Velika prednosti metodologije leži u samom procesu gradnje koji se brzo prilagođava
okolini i promjenama, te se samoorganizirajući prilagodi nastalim promjenama kako bi
se sve problematike otklonile odnosno nadogradile.
U praktičnom primjeru Sistemske Administracije ovakav pristup radu se pokazao jako
pozitivnim sa velikim učinkom u kratkom vremenu. Članovi tima osim što se bave
svakodnevnim aktivnostima održavanja i nadgledanja kompleksnog informacijskog
sustava ovim pristupom dobili su povećani fokus na projektne zadatke koji ako budu
izvršeni, njima omogućavaju i lakše održavanje istog sustava. Dobili smo veliki rast
produktivnosti, prilagodljivosti, efikasnosti i automatizaciju.
18
LITERATURA
1. What isAgile?WhatisScrum?, https://www.cprime.com/resources/what-is-agilewhat-is-
scrum/
2. .Scrum općenito, https://www.atlassian.com/agile
3. Scrum Team, http://www.scruminstitute.org/Scrum_Roles_The_Scrum_Team.php,

Contenu connexe

Similaire à Projektovanje informacionih sist

Business process maturity model
Business process maturity modelBusiness process maturity model
Business process maturity modelSlaven Brumec
 
UPD (2).pptx.oasfasfccccccccccccccccccccccccccccccccccccccc
UPD (2).pptx.oasfasfcccccccccccccccccccccccccccccccccccccccUPD (2).pptx.oasfasfccccccccccccccccccccccccccccccccccccccc
UPD (2).pptx.oasfasfcccccccccccccccccccccccccccccccccccccccBrankouljak
 
Dizajn Softvera.pptx
Dizajn Softvera.pptxDizajn Softvera.pptx
Dizajn Softvera.pptxBojanGrujic4
 
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapas
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapasKomparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapas
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapasTihana Lapas
 
Agilni pristup učenju i poučavanju.pptx
Agilni pristup učenju i poučavanju.pptxAgilni pristup učenju i poučavanju.pptx
Agilni pristup učenju i poučavanju.pptxLjubicaJerkovic1
 
Zašto nam treba PaaS u Srcu?
Zašto nam treba PaaS u Srcu?Zašto nam treba PaaS u Srcu?
Zašto nam treba PaaS u Srcu?Denis Kranjčec
 
Procesni pristup poslovanju-BPR ppt
Procesni pristup poslovanju-BPR pptProcesni pristup poslovanju-BPR ppt
Procesni pristup poslovanju-BPR pptsetuplinks
 
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptx
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptxPOSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptx
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptxLarlochLes
 
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-micamic
 
Product Owner Kodokan by Kemal Bajramović
Product Owner Kodokan by Kemal BajramovićProduct Owner Kodokan by Kemal Bajramović
Product Owner Kodokan by Kemal BajramovićBosnia Agile
 
Računarski praktikum 1 - Razvoj softvera i dizajn
Računarski praktikum 1 - Razvoj softvera i dizajnRačunarski praktikum 1 - Razvoj softvera i dizajn
Računarski praktikum 1 - Razvoj softvera i dizajnGoran Igaly
 
Microsoft Community sastanak - Vođenje softverske imovine
Microsoft Community sastanak - Vođenje softverske imovineMicrosoft Community sastanak - Vođenje softverske imovine
Microsoft Community sastanak - Vođenje softverske imovineTomislav Lulic
 
Sastanak zajednice Microsoft prodavača - Sales readiness
Sastanak zajednice Microsoft prodavača - Sales readinessSastanak zajednice Microsoft prodavača - Sales readiness
Sastanak zajednice Microsoft prodavača - Sales readinessTomislav Lulic
 
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka p...
Da li je izvrstan Project Manager uvjet bez kojeg  nema uspješnog završetka p...Da li je izvrstan Project Manager uvjet bez kojeg  nema uspješnog završetka p...
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka p...Alan Mirko Poldrugac, MSc, PMP
 
2. projekti i upravljanje projektnim ciklusom 27.06.12. i dio
2. projekti i upravljanje projektnim ciklusom 27.06.12.   i dio2. projekti i upravljanje projektnim ciklusom 27.06.12.   i dio
2. projekti i upravljanje projektnim ciklusom 27.06.12. i diodoxikus
 
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.Combis ucm information age 2010 jeste li spremi za e poslovanje v2.
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.Oracle Hrvatska
 
Modeliranje poslovnih procesa: izvedbeni projekti
Modeliranje poslovnih procesa: izvedbeni projektiModeliranje poslovnih procesa: izvedbeni projekti
Modeliranje poslovnih procesa: izvedbeni projektiSlaven Brumec
 
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“goranvranic
 

Similaire à Projektovanje informacionih sist (20)

Business process maturity model
Business process maturity modelBusiness process maturity model
Business process maturity model
 
UPD (2).pptx.oasfasfccccccccccccccccccccccccccccccccccccccc
UPD (2).pptx.oasfasfcccccccccccccccccccccccccccccccccccccccUPD (2).pptx.oasfasfccccccccccccccccccccccccccccccccccccccc
UPD (2).pptx.oasfasfccccccccccccccccccccccccccccccccccccccc
 
Dizajn Softvera.pptx
Dizajn Softvera.pptxDizajn Softvera.pptx
Dizajn Softvera.pptx
 
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapas
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapasKomparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapas
Komparativna analiza poslovnih informacijskih sustava otvorenog koda_tlapas
 
Agilni pristup učenju i poučavanju.pptx
Agilni pristup učenju i poučavanju.pptxAgilni pristup učenju i poučavanju.pptx
Agilni pristup učenju i poučavanju.pptx
 
Zašto nam treba PaaS u Srcu?
Zašto nam treba PaaS u Srcu?Zašto nam treba PaaS u Srcu?
Zašto nam treba PaaS u Srcu?
 
Procesni pristup poslovanju-BPR ppt
Procesni pristup poslovanju-BPR pptProcesni pristup poslovanju-BPR ppt
Procesni pristup poslovanju-BPR ppt
 
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptx
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptxPOSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptx
POSLOVNE PROGRAMSKE APLIKACIJE I MIGRACIJE BAZA.pptx
 
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-
Poslovanje radionice za popravak vozila analiza poslovnog sustava -aps-
 
Product Owner Kodokan by Kemal Bajramović
Product Owner Kodokan by Kemal BajramovićProduct Owner Kodokan by Kemal Bajramović
Product Owner Kodokan by Kemal Bajramović
 
Seminar hipermedija
Seminar hipermedijaSeminar hipermedija
Seminar hipermedija
 
Računarski praktikum 1 - Razvoj softvera i dizajn
Računarski praktikum 1 - Razvoj softvera i dizajnRačunarski praktikum 1 - Razvoj softvera i dizajn
Računarski praktikum 1 - Razvoj softvera i dizajn
 
Microsoft Community sastanak - Vođenje softverske imovine
Microsoft Community sastanak - Vođenje softverske imovineMicrosoft Community sastanak - Vođenje softverske imovine
Microsoft Community sastanak - Vođenje softverske imovine
 
Sastanak zajednice Microsoft prodavača - Sales readiness
Sastanak zajednice Microsoft prodavača - Sales readinessSastanak zajednice Microsoft prodavača - Sales readiness
Sastanak zajednice Microsoft prodavača - Sales readiness
 
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka p...
Da li je izvrstan Project Manager uvjet bez kojeg  nema uspješnog završetka p...Da li je izvrstan Project Manager uvjet bez kojeg  nema uspješnog završetka p...
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka p...
 
2. projekti i upravljanje projektnim ciklusom 27.06.12. i dio
2. projekti i upravljanje projektnim ciklusom 27.06.12.   i dio2. projekti i upravljanje projektnim ciklusom 27.06.12.   i dio
2. projekti i upravljanje projektnim ciklusom 27.06.12. i dio
 
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.Combis ucm information age 2010 jeste li spremi za e poslovanje v2.
Combis ucm information age 2010 jeste li spremi za e poslovanje v2.
 
Modeliranje poslovnih procesa: izvedbeni projekti
Modeliranje poslovnih procesa: izvedbeni projektiModeliranje poslovnih procesa: izvedbeni projekti
Modeliranje poslovnih procesa: izvedbeni projekti
 
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“
Goran Vranić, InfoExpert Banja Luka: „BPM i Software Asset Management (SAM)“
 
Osnivanje Projektnog ureda PMO
Osnivanje Projektnog ureda PMOOsnivanje Projektnog ureda PMO
Osnivanje Projektnog ureda PMO
 

Projektovanje informacionih sist

  • 1. 1 BOSNA I HERCEGOVINA REPUBLIKA SRPSKA VISOKA ŠKOLA ZA EKONOMIJU I INFORMATIKU PRIJEDOR SCRUM METODOLOGIJE NASTAVNI PREDMET: PROJEKTOVANJE INFORMACIONIH SISTEMA MENTOR: STUDENT: Doc.dr Radovan Vladisavljevic Semir Talic Indeks br.: 09 U Prijedoru, juni 2021. Godine
  • 2. 2 SADRZAJ Contents UVOD........................................................................................................................................... 3 AGILNE METODE........................................................................................................................... 4 SCRUM......................................................................................................................................... 6 EKSTREMNO PROGRAMIRANJE.....................................................................................................10 SCRUMU NASTAVI PROGRAMSKOG INZINJERSTVA........................................................................11 SCRUMTIM .................................................................................................................................12 ZAKLJUCAK ..................................................................................................................................17 LITERATURA.................................................................................................................................18
  • 3. 3 UVOD Programskoinženjerstvoobuhvaćaznanje,alate i metode zadefiniranje zahtjeva programske podrške,i obavljanjazadatakadizajna,konstrukcije,testiranjai održavanja programske podrške. Informacijski sustavje skupmeđusobnopovezanihkomponenatakoje cijeli timmora znati prikupiti izprikladnihizvoraupoznatihsdomenom, obrađivati uskladus karakteristikamadomene te izdobivenihpodatakaznati vrednovati ključne elementei pohraniti ihza buduće korištenje. Pri izradi kvalitetne programske podrškeje moguće pogriješiti najakopunonačina,u različitimfazamasamogprojekta.Upravozbogtoga svaki peti projektne dođe dosvogkraja većpropadne u nekoj odfazarazvoja.Svaki drugi projektse nađe na kušnji baremjednom, a često i više putatijekomprocesai ne završi u skladusa svimzahtjevima,dokse samooko 30 % projekatasmatrauspješnima.Najčešće projektiipakzavrše noprekorače ili rokili planirani trošak,i to najčešće za otprilike dvostruki iznos. Mnogi surazlozi te statistike,nonajčešće se ti uzroci mogupodijeliti unekolikoskupina. Ponekadse radi o nespremnostinaručiteljazaosiguranjempotrebnihsredstavate tada projektpropadne zbognezadovoljenihfinancijskih izdavanja.Sljedeći je razlogpropasti projekatanespremnostnapromjene.Vrlorijetkoili gotovonikadaprojektne teče ucijelosti kakoje u početkupretpostavljeno.Zbogtogaprojektnitimi načinizrade programskog rješenjamorajubiti dovoljnofleksibilni i spremninastalne i svakodnevne promjenete se prilagođavati svakoj novonastalojsituaciji. Vrloveliki problemje i nedostatakkomunikacije i transparentnosti utimu.Članovi svih odjelamorajubiti ustalnomkontaktui razmjenjivati iskustvai prijedloge,te takođerbiti u kontaktus naručiteljemi krajnjimkorisnicimakakobi svi dionici sudjelovali uproizvodnom procesu.
  • 4. 4 AGILNE METODE Agilne metode su jako često korišten pojam koji se odnosi na mnoge pristupe i metodologije koje se koriste u razvoju programske podrške. Njih razvijaju vodeći stručnjaci u području razvoja programske podrške te navode osnovna načela koja, kada ih se timovi pridržavaju, povećavaju vjerojatnost uspjeha na projektu. Najveći problem konvencionalnih metoda poput vodopadnog modela je nedovoljna fleksibilnost. Uz svoju krutu strukturu ne dopuštaju promjenu zahtjeva i okolnosti razvoja proizvoda koji su utkani u samu srž razvoja programske podrške. Stoga agilne metode prigrljuju stalne promjene, i oblikuju se tako da se upravo njima mogu prilagoditi. Osnovna načela agilnih metoda su donesena 2001. godine na sastanku skupine vodećih softverskih stručnjaka na skijalištu Snowbird u Saveznoj Državi Utah, te se taj sastanak smatra začetkom agilne metodologije. U svom su proglasu naglašavali kako su pojedinci i interakcije među njima važniji od procesa i alata koji se koriste u razvoju te kako je funkcionalnost i ispravnost softvera važnija od sveobuhvatne dokumentacije. Također su se složili da je suradnja s naručiteljem važnija od pregovora o ugovoru te kako je odziv na promjene u cjelokupnom procesu važniji o d praćenja plana razvoja. Svi principi navedeni u manifestu o agilnim metodama se mogu implementirati u različitoj mjeri i na različite načine, stoga postoji mnogo vrsta agilnog razvoja. Neke od popularnijih metoda su: Adaptivni razvoj softvera (ASD), Agilno modeliranje, Agilni ujedinjeni proces(AUP), Ekstremno programiranje, Razvoj vođen karakteristika (FDD), Lean razvoj softvera, Kanban, Rapidni razvoj aplikacija (RAD), Scrum i drugi. U svom ću se radu posvetiti Kanbanu, Scrumu i Ekstremnom programiranju jer su oni najzastupljeniji kako u poslovnom svijetu, tako i na studentskim projektima. Kako bi se mogli što efikasnije koristiti na projektima potrebno je koristiti adekvatne alate. U nastavku rada se nalazi osvrt na neke od najpopularnijih alata koji se koriste na malim projektima te su time prikladni za studentske projekte, te također nešto složenije programe s više mogućnosti koji se koriste u velikim kompanijama.
  • 5. 5 Kanban Kanban svoje korijene vuče iz ranih 1940-ih kada je razvijen od strane inženjera Taiichija Ohnoa u Japanskoj automobilskoj kompaniji Toyota. Naziv se može prevesti kao kartica ili tablica, a razvijen je kako bi se poboljšala produktivnost rada u skladu s „Just-In-Time“ pristupom, tako da se cijeli distributivni lanac sa svim svojim elementima popiše i standardizira, te se olakša upravljanje svim procesima. David J. Anderson je 2004. primijenio Toyotina načela na IT industriju na način da je kreirao danas široko korištenu Kanban ploču. Važno je napomenuti kako Kanban sam po sebi nije metodologija, te ne definira nikakve načine izrade programskog rješenja. Njegovim korištenjem se može unaprjeđivati razvojni proces članova tima te im pomoći da nauče bolje raspoređivati posao i vlastito vrijeme. Glavna značajka Kanbana je vizualizacija razvojnog procesa pomoću fizičke ili digitalne ploče. Ona je podijeljena na stupce koji predstavljaju različite faze dovršenosti zadatka, od kojih se najčešće koristi jednostavna podjela na zadatke koji se još nisu ni počeli izvršavati (to do), one koji se izvršavaju (doing) i one koji su dovršeni (done). Iako je podjela jednostavna, daje jako dobar uvid u trenutnu količinu posla te vrlo jednostavno omogućava svim članovima tima te također i vanjskim promatračima da vide u kojoj je fazi projekt.
  • 6. 6 SCRUM Scrum je naziv za skup procesa koji se koristi za inkrementalni razvoj softvera koji propisuje mali broj artefakata koji se moraju formirati i održavati te događaja kojise moraju slijediti kako bi se smanjilo vrijeme potrebno za upravljanje i ostalo više vremena za razvoj. Svaka iteracija u Scrumu-u se naziva sprint i najčešće traje jedan ili dva tjedna. Ovisno o vrsti projekta, rezultat svakog sprinta može biti neki modul rješenja, ili isporučiva verzija proizvoda koja se šalje na testove prihvatljivosti. Clanovi Scrum tima Pokazalo se da su najefikasniji timovi veličine 7 +/- 2 člana. Scrum prati taj princip, uz dodatak toga da na projektu može raditi više razvojnih ekipa, koje funkcioniraju kao samoorganizirajući timovi, te svi zajedno rade na ostvarivanju istog zajedničkog cilja. Najodgovorniju i najbitniju ulogu u Scrum timu ima vlasnik proizvoda (Product owner). On je zadužen za izradu plana projekta, postavljanje prioriteta na zahtjeve i zadatke, formiranje troškova te uspješan povrat investicije. On predstavlja klijenta odnosno naručitelja te upravu, te u razgovoru s klijentom piše korisničke priče koje se pohranjuju u popis stavki za proizvod, odakle se dalje posao razbija na manje zadatke. Kako bi cijeli proces razvoja tekao što efikasnije i uspješnije, potrebno je imenovati Scrum mastera. Njegova je uloga da koordinira sve timove te se brine o napretku projekta i uključenosti vlasnika proizvoda u cijeli proces. On se ne bavi formiranjem zadataka timova i pojedinaca, već oni sami raspodjeljuju posao među sobom. Također ne donosi tehničke odluke, no pomaže vlasniku proizvoda u održavanju popisa stavki za proizvod i brine se da je količina posla adekvatno raspodijeljena u svakom sprintu. Naposljetku Scrum tim čini razvojni tim. Njihova je uloga pretvaranje kompleksnih korisničkih priča u zadatke koji se mogu obaviti u razumnoj jedinici vremena. Tim se zadatcima određuju težine i procjene potrebnog vremena za izradu, te se dalje raspoređuju među članovima tima. Rad razvojnog tima nadgleda Scrum master koji im također mora olakšati posao kroz efektivno usmjeravanje, te se pobrinuti da tim ima sva potrebna sredstva za uspješno izvršavanje zadataka.
  • 7. 7 Scrum artefakti Artefakti ključni za uvođenje Scrum metodologije su: popis stavki za proizvod (product backlog), popis stavki za sprint (sprint backlog), zadatak (task) te inkrementi rješenja (Potentially Shippable Increment, kraće PSI). Zadatak je osnovna jedinica posla u razvoju softvera te predstavlja neku korisničku priču ili neki njen dio ako je zbog svoje kompleksnosti dekomponirana. Svaki zadatak mora biti jasno definiran svojim nazivom, kratkim opisom koji točno određuje način validacije izvršenosti zadatka, prioritet, osobu kojoj je dodijeljen te procjenu vremena potrebnog za njegovo izvršavanje. Neki od ovih atributa se ne dodjeljuju odmah prilikom formiranja, već u trenutku kada se zadatak dodijeli članu tima te počne izvoditi. Kako bi se lakše pratio napredak potrebno je formirati zadatke manjeg opsega koji traju najviše jedan dan posla. U popisu stavki za proizvod se u svakom trenutku nalaze svi preostali i nedovršeni poslovi te funkcionalnosti proizvoda koje još nisu implementirane. Prilikom inicijalizacije projekta ga vlasnik proizvoda mora napuniti, te on postaje vidljiv svim dionicima projekta. Tijekom razvoja se iz njega miču dovršeni poslovi, te se u njega dodaju dodatni poslovi koje netko od dionika prepozna kao potrebne. Svaka iteracija Scrum projekta, odnosno sprint, ima svoje ciljeve i zadatke. Oni su reprezentirani popisom stavki za sprint u koji se dodaju zadatci iz popisa stavki za proizvod. Prilikom prebacivanja zadatka u popis stavki za sprint potrebno je provjeriti je li procjena vremena bila ispravna te član tima koji preuzima taj zadatak mora to naznačiti i brinuti se da promijeni status zadatka s obzirom na njegov napredak na njemu. Za efikasniji pregled nad svim zadatcima se najčešće koristi ploča na koju se upisuju svi zadatci, te koja je podijeljena u sekcije koje reprezentiraju različite faze dovršenosti tih zadataka. Nema neke obavezne i univerzalne podjele tih sekcija, no najčešće se koriste neka od stanja: za napraviti (to do), dodijeljeno (assigned), u izradi (in progress), za potvrdu (to verify), testira se (in testing) i dovršeno (done). Rezultat svakog inkrementa projekta bi trebao biti isporučivi proizvod, PSI. Periode u kojima bi tim trebao prezentirati PSI određuje vlasnik, dok je tim taj koji bi se morao pobrinuti oko zadovoljavanja rokova kroz izvršavanje zadataka potrebnih za dovršavanje dogovorenih zahtjeva u trenutnom inkrementu.
  • 8. 8 Zivotni ciklus Scrum projekta Scrum projekt se dijeli u tri faze: prije igre (pre-game), razvoj (game) i poslije igre (post-game). Tijekom prva faze se obavljaju planiranje, dizajn i izrada arhitekture. Također se kreira i inicijalno puni popis stavki za proizvod koji se dalje modificira u sljedećoj fazi. Za vrijeme tzv. igre se ispunjavaju svi zahtjevi dok se u potpunosti ne dovrše svi zadatci čime završava inkrement projekta. Zatim je u trećoj fazi potrebno napraviti integraciju svih napravljenih modula i testirati ispravnost izrađenog proizvoda. Kako bi se sve faze projekta lakše pratile i vodile, napravljen je model timskih sastanaka. Svaki sprint ima sastanak planiranja za sprint (sprint planning) na kojem se određuje opseg sprinta, formira se popis stavki za sprint te se zadatci dodjeljuju članovima. U praksi ovi sastanci traju oko sat vremena za sprintove duljine tjedan dana, te dva do tri sata za dulje sprinteve. Svaki dan se odrađuju 15-minutni dnevni scrum (daily scrum) sastanci na kojima članovi tima iznose svoj trenutni napredak i dnevni plan te izvještavaju o potencijalnim problemima. Ova vrsta sastanaka se ne odvija u konferencijskoj dvorani, već se članovi tima okupe negdje unutar svog prostora i odrade ga na nogama, zbog čega se ovi sastanci još nazivaju i standup sastanci. Na kraju svakog sprinta se održava sastanak pod nazivom pregled sprinta (sprint review) koji označava završetak inkrementa te se podnosi izvještaj obavljenog posla i spremnosti proizvoda za prezentiranje kupcu. Vlasnik odrađene korisničke priče uklanja iz popisa stavki za sprint, dok nedovršene prenosi u sljedeći sprint. Nakon tog sastanka članovi tima bez prisustva vlasnika na sastanku osvrta na sprint (sprint retrospective) odrađuju samo evaluaciju odrađenog posla i predlažu ideje za povećanje učinkovitosti.
  • 9. 9 Usporedba Scruma sa vodopodadnim modelom Istraživanja su pokazala kako su projekti na kojima se koristi Scrum metodologija puno efikasnije i štede novac u odnosu na projekte na kojima se koriste konvencionalne metode poput vodopadnog modela. Dok kod klasičnih metoda samo 14% projekata u potpunosti uspije, a čak 29 % ih propadne i ne završi, kod Scruma čak 42 % projekata završi uspješno, a samo 9 % propadne. Uz to, u čak 93% slučajeva su sudionici Scrum projekata rekli da su lakše predviđali potrebno vrijeme te im je u 44% slučajeva korištenje Scruma uštedjelo novac, a u 70% slučajeva vrijeme. Scrum na studentskom projektu Scrum se na studentskom projektu ne može u potpunosti implementirati. Razlog tome je što se članovi tima ne nalaze na dnevnoj bazi pa ne mogu imati redovite dnevne sastanke. Međutim, ostali aspekti poput planiranja i podjele posla na sprintove su svakako praksa koja bi se mogla lako uvesti i od koje bi projekt imao brojne koristi. Studenti bi se što ranije trebali upoznati sa Scrumom jer će ga u svojoj profesionalnoj karijeri gotovo sigurno koristiti prije ili kasnije.
  • 10. 10 EKSTREMNO PROGRAMIRANJE Ekstremno programiranje je metoda koja manju važnost daje strukturi rada, a veću kvaliteti i brzini izrade proizvoda. Za svoj cilj ima, kao i ostale agilne metode, omogućiti timu veću sposobnost prilagodbe na promjenjive zahtjeve projekta te brzu isporuku verzija proizvoda kroz kontinuirano izbacivanje verzija programskog rješenja. Faze ekstremnog programiranja Ekstremno je programiranje definirano pomoću 6 osnovnih faza: • Istraživanje o korisnici bilježe svoje priče na kartice, svaka od njih sadrži jednu mogućnost programa o traje od nekoliko tjedana do nekoliko mjeseci pri čemu se skup priča redovito nadopunjuje o projektni tim se upoznaje s alatima, tehnologijom i postupcima projekata te se izrađuje prototip sustava o Planiranje - određuju se prioriteti priča, određuje se vrijeme potrebno za implementaciju pojedine priče te se planira doseg prvog malog izdanja o traje nekoliko dana, a rok za izdavanje prvog malog izdanja iznosi do dva mjeseca • Iteracije do izdanja o klijent određuje kartice koje će se koristiti pri svakoj narednoj iteraciji o svaka iteracija traje jedan do četiri tjedna, pri čemu se na kraju svake izvode testovi prihvatljivosti o svaka iteracija stvara sustav koji obuhvaća cjelokupnu arhitekturu sustava te on mora biti spreman za produkciju • Produkcija o Vrši se dodatno testiranje i provjera performansi sustava prije isporuke klijentu o Razrješavaju se primjedbe na sustava te se odlučuje hoće li se primjedbe riješiti u trenutnom izdanju
  • 11. 11 o Vrši se u iteracijama trajanja tri do sedam dana • Održavanje o Kreće od puštanja prvog izdanja u produkciju, do kraja projekta o Može zahtijevati nove članove tima i promjenu njegove strukture • Faza smrti o Kada klijent više nema novih kartica s pričama te sustav zadovoljava sve zahtjeve o Vrijeme da se dovrši sva projektna dokumentacija o Do nje dolazi i kada sustav ne ispunjava sva korisnička očekivanja ili postane preskup za daljnji razvoj SCRUM U NASTAVI PROGRAMSKOGINZINJERSTVA S obzirom na godinu studija, od studenata su se očekivale različite razine znanja i korištenje manjeg opsega Scruma za studente prve godine, te postupno sve veći na ostalim predmetima. U prvoj je godini izvođenja predmeta sudjelovalo 15 timova veličine 3-5 članova. U narednim godinama je kapacitet predmeta bio 45-50 studenata s prve godine, te 65 za studente druge godine. Kolegij je bio organiziran za studente elektrotehnike te su oni izrađivali modele pomoću 3D printera, pri tome radeći prema načelima Scruma. Posao im je bio raspoređen u dvotjedne sprinteve te su za praćenje rada koristili programski alat Trello. Sastajali su se od 2 do 4 puta tjedno da bi raspravili o trenutnom napretku, te su imali sastanke na početcima i krajevima sprinteva gdje su ujedno prezentirali svoj rad i za njega bili ocjenjivani. Profesor Pejčinović je rekao kako je prvotna ideja bila da on kao nositelji predmeta ima ulogu vlasnika proizvoda, što se na kraju pokazalo prezahtjevnim s obzirom na broj timova i raznovrsnosti njihovih zadataka. Drugi problem se pojavio na kolegiju za studente četvrte godine, pošto se od njih očekivalo da su završili prethodni kolegij na nižim godinama, međutim pokazalo se da je gotovo dvije trećine studenata bilo na međunarodnoj razmjeni, ili su došli s nekog drugog sveučilišta, te nisu slušali kolegij koji ih je trebao pripremiti za tu kompleksniju primjenu Scruma.
  • 12. 12 Spomenuti prostori za napredak kolegija su bili povezivanje studenata s nižih i viših godina, pri čemu bi studenti nižih godina projektni timovi, dok bi studenti viših godina preuzeli uloge vlasnika proizvoda i Scrum mastera te usko surađivali sa studentima i profesorima i sudjelovali u ocjenjivanju rada studenata. Na taj bi se način mogao i povećati broj timova te olakšati teret s profesora. Studentske ankete su pokazale kako se studentima predmet pokazao kao vrlo koristan, te su nakon njegovog dovršetka stekli korisna znanja o agilnim metodama i modernom inženjerstvu. Najvrjednija korist ovog predmeta je bilo praktično znanje koje su studenti dobili te upoznavanje s profesionalnim okruženjem. Studenti su također razvijali prijeko potrebne vještine timskog rada te raspoređivanja posla i organizacije vremena. Profesor je s druge strane imao priliku vidjeti koliko korisni mogu biti alati za praćenje rada za kvalitetniji uvid u rad studenata, te mogu li olakšati ocjenjivanje. SCRUM TIM Za razliku od klasičnih metoda upravljanja projektima, Scrum ne posjeduje i nema potrebu za voditeljem projekta, projektnim menadžerom ili timskim voditeljem. Scrum tim se sastoji od tri glavne uloge: - Vlasnik proizvoda - Scrum Master - Razvojni tim Vlasnik proizvoda Jedna od najvažnijih uloga, kako bi Scrum metodologija bila uspješna u realizaciji i stvaranju projekta, čini vlasnik proizvoda, koji čini sučelje između tima i drugih zainteresiranih strana odnosno Stakeholder-a. Može se reći da u tvrtkama koje koriste Scrum metodologiju zadaci i odgovornost koju ima vlasnik proizvoda nikada nisu isti. Ulogu vlasnika proizvoda preuzimaju specifične osobe sa određenim vještinama koje moraju proći i određeni trening, kako bi preuzeli veliku odgovornost na sebe. Uloga vlasnika tima je ujedno i najkompleksnija uloga u izvedbi te procedure.
  • 13. 13 Vlasnik proizvoda se često nalazi u „borbama“ na dvije strane. Dok tim u određenom vremenskom periodu radi na projektu zaštićeni od Scrum Master-a. Vlasnik projekta se bavi marketingom, menadžmentom ili korisnicima od kojih izvlači razne informacije (pogled korisnika na aplikativno rješenje te njegove potrebe) koje su mu potrebne kako bi se mogli stvoriti preduvjeti za razvoj software-a koje zatim mora što preciznije prenijeti timu. Vlasnik proizvoda također je i odgovoran o povratu uloženih sredstava. Zatim potvrđuje gotova rješenje, provjerava kvalitetu te dali je prihvatljivo programsko rješenje za krajnjeg korisnika ovisno o točki gledišta. Također odlučuje o važnosti pojedinog svojstva u odnosu na prioritete kako bi što bolje tim shvatio kako bi proizvod trebao izgledati te koja je konačna vizija krajnjeg projekta. Budući da tim mora što učinkovitije raditi, to vlasnik proizvoda mora brzo reagirati sa povratnim informacijama. Stoga on ispunjava ulogu komunikatora, te je stalno u kontaktu sa svim Stakeholder-ima odnosno zainteresiranim stranama, sponzorima te za kraj i sa projektnim timom. Uostalom to i je njegov zadatak da koordinira financijsku stranu razvoja proizvoda, što uspješno provodi kroz kontinuiran rad i stvaranjem prioriteta kroz određene radnje. Svi ti raznovrsni zahtjevi pokazuju koliko ja važan odabir odnosno izbor prave osobe za uspješnost projekta. Vlasnik proizvoda unutar Scrum-a nije samo menadžer, već je i vlasnik zbog čega je on direktno odgovoran za cijeli proizvod. Biti vlasnik proizvoda znači: - Preuzeti odgovornost za uspjeh proizvoda koji mu dostavlja razvojni tim - Donositi poslovne odluke velikih važnosti prema prioritetima - Voditi projekt u pravom smjeru - Izvrstan timski igrač - Prenijeti viziju projekta prema Razvojnom timu (Eng. Scrum team) - Brine o potrebama korisnika i poslovnim ciljevima - Vlasnik proizvoda mora posjedovati znanja iz različitih domena - Kontrolira rezultate i provjerava kvalitetu proizvoda - Brzo reagira sa povratnim informacijama - Komunicira na kontinuiranoj osnovi sa svim zainteresiranim stranama financijerima te timom - Također kontrolira i cijelu financijsku stranu proizvoda odnosno projekta. - Ima važnu ulogu u izradi te održavanju liste ,
  • 14. 14 te se brine da svi koji sudjeluju u projektu i razumiju radne zadatke naznačene na njemu. - Njegova je konačna odluka o redoslijedu zadataka razvrstanih po prioritetima iz Product Backlog liste, te procjenjuje koliko je napora potrebno uložiti za izvršavanje pojedinih zadataka sa liste kako bi se zadatci mogli programski implementirati od razvojnog tima u određenom vremenskom periodu. Scrum master Već samo ime nam govori kako Scrum Master zapravo nije voditelj tima. Voditelj tima najčešće predstavlja osobu koja vodi tim i postavlja zadatke, dok Scrum Master promatra da tim izvršava zadatke prema Scrum metodologiji. On se ne miješa u razvoj proizvoda, već sudjeluje kao savjetnik Scrum timu. Aktivno se uključuje ako netko od članova tima ili od zainteresiranih strana (Eng. Stakeholder) ne poštuje u cijelosti pravila Scrum-a. Dok voditelji timova često dodjeljuje zadatke i snosi odgovornost za njihovo provođenje, iskusni Scrum master unutar cijelog procesa daje impulse i savijete timu kako bi ih usmjerio na pravi put da bi u konačnici koristili najbolje metode i tehnologije za dobrobit proizvoda i projekta. Njegovo djelovanje na tim je više usmjereno prema savjetniku tima nego voditelju tima. Glavni zadatak mu je da vodi tim kroz Scrum process te pomaže općenito razvojnom timu da u globalu stvore uspješnu dinamiku napretka. Također organizira i moderira sastanke, kako bi mogao utjecati na samu motivaciju i produktivnost svih članova tima. Vjestine i poslovi koje Scrum master mora imati : - Izvrstan voditelj - Nadgleda i prati posao - Izvještava i komunicira sa svim članovima - Izvrstan poznavatelj procesa - Kontrolira kvalitetu - Rješava raznovrsne prepreke - Rješava sukobe ako se pojave - Štiti razvojni tim
  • 15. 15 - Daje povratne informacije o napretku. Vrlo važan zadatak koji obavlja jest da oslobodi cijeli tim od bilo kakvih prepreka koje bi mogle poremetiti njihov nesmetani rad. Obično se problemi mogu svrstati u tri različite kategorije. Prvi problem sa kojim se tim npr. može suočiti jest nedostupan ili ne spreman Hardware za bilo kakva izvođenja ili testiranja proizvoda, IT odjel ne može omogućiti Bug tracker, ili naručeni software još uvijek nije stigao do razvojnog tima. Još jedna od mogućih prepreka npr. jest pojavljivanje marketinškog ili prodajnog menadžera koji opet traži da se još jedno značajno svojstvo integrira na brzinu u proizvod. Drugi problem nastaje kao rezultat loše organizacijske strukture ili unutar loših strateških odluka. Takve situacije znaju nastati kada tim nije u mogućnosti održavati važne sastanke ili postoje trzavice u odnosu između pojedinih članova tima, pa smatraju da je Scrum Master odgovoran za pojedine članove razvojnog tima. Učestalo se javljaju takvi problemi zbog krivog shvaćanja da je Scrum Master klasičan voditelj tima, što dovodi do sukoba interesa što je protiv glavnog principa Scrum-a. Razvojni tim posjeduje menadžersku ulogu unutar Scrum metodologije te je ravnopravan prema Scrum Master-u i Vlasniku proizvoda. A drugi aspekt kao problem može predstavljati nedovoljna propusnost interneta za novi projekt. Treći problem se pojavljuju individualno izazvani iz različitih primjera. Nekome je potrebna pomoć oko debugging-a 13. Netko nije u mogućnosti odraditi određene zadatke sam pa mu je potreban još jedan član za programiranje. Također i čisti banalni primjer gdje netko drugi ne vezan za tim mora resetirati određeni server zbog značajnih promjena na istome. Čak i u situacijama gdje Scrum Master nije u mogućnosti samostalno riješiti određene zahtjeve, i dalje je on odgovorna osoba koja se brine o tome da razvojni tim ima određene kriterije za nesmetani rad. Takav posao često iziskuje jako puno vremena, veliki autoritet i jaku kralježnicu. Na njemu je da omogući optimalne radne uvijete za razvojni tim, te ostane odgovoran na održavanju tih uvjeta kako bi se svi ciljevi unutar sprinta ostvarili.
  • 16. 16 Razvojni tim Za razliku od drugih razvojnih metodologija unutar Scrum-a, razvojni tim nije samo izvršni organ koji prima svoje zadatke od voditelja projekta, već samostalno odlučuju koje prohtjeve odnosno nadogradnje potrebne krajnjim korisnicima odrađuju unutar da izrađuju proizvod, on im osigurava optimalne uvijete za samostalni rad te ih savjetuje pazeći da se ne krše Scrum pravila. Promijenjena percepcija uloga je najbitniji aspekt ovakve metodologije kada netko želi shvatiti Scrum kako bi ga uveo u tvrtku koja se bavi razvojem. Razvojni tim se u idealnim uvjetima sastoji od 7 ± 2 članova. Broj članova može biti i troje, ali nikako ispod tri člana jer postoji velika mogućnost da nemaju dovoljno znanja ili vještina kako bi mogli na vrijeme do kraja sprinta izvršiti svoj posao. U slučaju da je preko devet članova onda postoji vrlo velika mogućnost da se pojavi problem oko koordinacije. Veliki broj članova unutar tima izaziva veliku složenost za empirijski proces upravljanja. U ove brojke nisu uključeni Vlasnik proizvoda niti Scrum Master. Članovi tima posjeduju različite vještine te se međusobno podupiru kako nitko od njih ne bi predstavljao usko grlo tokom razvoja proizvoda. Najčešći tipičan razvojni tim uključuje mješavinu softverskih inženjera, arhitekata, programera, analitičara, eksperta za osiguranje kvalitete, programski testeri, i dizajneri grafičkog sučelja. Vrlo čvrsti Scrum timovi pristupaju svakom proizvodu sa čvrstim stavom „mi“. Između njih mora vladati vrlo jaki kolegijalni odnos i kvalitetan timski rad kako bi bili što više usredotočeni na proizvod koji tokom jednog sprinta moraju odraditi. Kao što smo već spomenuli, Scrum tim sam upravlja planom za svaki sprint. Oni predviđaju koliko posla imaju te koliko im je vremena potrebno za određeni razvoj unutar jednog sprinta, koristeći se iskustvom iz vlastite povijesti u prethodnim sprintevima. Zadržavajući iteracije sprinteva na jednakim duljinama razvojni tim dobiva vrlo korisne povratne informacije o tome koliko vremena moraju potrošiti za razvoj određenih funkcionalnosti proizvoda. Na taj način oni s vremenom sve preciznije mogu prognozirati potrebno vrijeme i količinu posla koji moraju odraditi u toku sprinta.
  • 17. 17 ZAKLJUCAK Scrum metodologija u današnjem modernom dobu predstavlja vrlo učinkovit pristup razvoju kompleksnih proizvoda. Samim time što u kratkim vremenskim rokovima nastaju funkcionalni inkrementi nekog proizvoda pa ih se ujedno može i isporučiti krajnjim korisnicima. Pošto je razvoj koncipiran na manje iteracije razvoja dijelova proizvoda, cijeli proces se sa lakoćom unutar kratkih vremenskih perioda može prilagoditi potrebnom stanju na tržištu. Sam pristup ima najveći fokus prema članovima tima koji uz veliku fleksibilnost u dinamičnoj okolini djeluju na sam proizvod. Osim kod razvoja proizvoda ovaj se proces može integrirati i u kompleksne radne okoline, gdje prevladava jako velika i brza dinamika na svako dnevnoj razini. Korištenjem Scrum-a dobiva se mogućnost dobro organizirati jednu ili više skupina ljudi koji rade na određenom projektu kako bi povećali efikasnost njihovog rada i bolje organizirali cijeli pristup radu. Velika prednosti metodologije leži u samom procesu gradnje koji se brzo prilagođava okolini i promjenama, te se samoorganizirajući prilagodi nastalim promjenama kako bi se sve problematike otklonile odnosno nadogradile. U praktičnom primjeru Sistemske Administracije ovakav pristup radu se pokazao jako pozitivnim sa velikim učinkom u kratkom vremenu. Članovi tima osim što se bave svakodnevnim aktivnostima održavanja i nadgledanja kompleksnog informacijskog sustava ovim pristupom dobili su povećani fokus na projektne zadatke koji ako budu izvršeni, njima omogućavaju i lakše održavanje istog sustava. Dobili smo veliki rast produktivnosti, prilagodljivosti, efikasnosti i automatizaciju.
  • 18. 18 LITERATURA 1. What isAgile?WhatisScrum?, https://www.cprime.com/resources/what-is-agilewhat-is- scrum/ 2. .Scrum općenito, https://www.atlassian.com/agile 3. Scrum Team, http://www.scruminstitute.org/Scrum_Roles_The_Scrum_Team.php,