UVEDBA »SCRUM« METODOLOGIJE RAZVOJA APLIKACIJ V … · SCRUM: ACScrum in Atlassian Jira. V drugem...

Diplomsko delo visokošolskega strokovnega študija Organizacija in management delovnih procesov

UVEDBA »SCRUM« METODOLOGIJE RAZVOJA APLIKACIJ V PODJETJU PRONET KRANJ

D. O. O.

Mentor: red. prof. dr. Tomaž Kern Kandidatka: Lea Jerič

Kranj, junij 2016

ZAHVALA Za pomoč pri izdelavi diplomskega dela in podane pripombe in mnenja, predvsem pa za potrpežljivost pri nastajanju tega diplomskega dela se zahvaljujem mentorju red. prof. dr. Tomažu Kernu in lektorici Nataši Purkat. Pobudo za uvedbo metode SCRUM v podjetje je podal direktor podjetja Boštjan Berčič, ki je zaradi stalnega pomanjkanja časa zaposlenih v podjetju mene spodbudil, da prevzamem to nalogo. Ves čas študije metode in testiranj orodij za uporabo metode me je usmerjal in pomagal z nasveti in koristnimi pripombami. Hvala tudi drugim zaposlenim v podjetju Pronet, Kranj, d. o. o.

POVZETEK V diplomski nalogi smo se naprej posvetili spoznavanju najbolj razširjene agilne metode za razvoj programske opreme – metodi SCRUM. V prvem delu so bile narejene analize dveh izbranih orodij, ki podpirata metodo SCRUM: ACScrum in Atlassian Jira. V drugem delu smo se po proučitvi in predstavitvi obeh orodij vodstvu podjetja in razvojni skupini podjetja Pronet, Kranj, d. o. o., ter predstavljenih prednostih in slabostih obeh orodij odločili, da metodo razvoja programskih aplikacij SCRU M v podjetje uvedemo z orodjem Atlassian Jira. Da bi si podjetje zagotovilo konkurenčno prednost, dolgoročno učinkovitost, fleksibilnost in stabilnost podjetja, smo se odločili, da se postopoma opustijo klasične metode razvoja programske opreme in se uvede nov agilni pristop.

KLJUČNE BESEDE:

- agilne metode - Scrum - ACScrum - Atlassian Jira

ABSTRACT In the present thesis we will focus on the most widespread agile methods of software development - SCRUM methodology. The thesis is designed in three parts. In the first part we made analysis of two chosen tools that are supporting methodology SCRUM and Atlassian Jira. In the second part, we introduced both tools to management and development group of the company Pronet, Kranj, d. o. o. Then we discussed the advantages and disadvantages of tolls and finally decided for Atlassian Jira. We have decided to abandon the classical methods of software development and start using Atlassian Jira, to ensure stability, flexibility and long term effectiveness to the company.

KEYWORDS: - Agile methods - Scrum - ACScrum - Atlassian Jira

KAZALO

1. UVOD .................................................................................... 1

1.1. PREDSTAVITEV PROBLEMA ........................................................ 1

1.2. PREDSTAVITEV OKOLJA ............................................................ 1

1.3. PREDPOSTAVKE IN OMEJITVE ..................................................... 2

1.4. METODE DELA ....................................................................... 3

2. METODE RAZVOJA PROGRAMSKE OPREME .......................................... 4

2.1. AGILNE METODE .................................................................... 4

2.2. METODA WATERFALL – PRIMER KLASIČNE METODE ............................ 5

2.3. PREDNOSTI UPORABE AGILNIH METOD RAZVOJA APLIKACIJ V PRIMERJAVI S KLASIČNIMI METODAMI ..................................................................... 6

3. METODA SCRUM ........................................................................ 7

3.1. SCRUM ............................................................................... 7

3.1.1. POKER METODA ............................................................... 9

3.1.2. ESTIMATION METODA ........................................................ 10

3.2. KANBAN ............................................................................. 10

3.3. PRIMERJAVA METOD SCRUM IN KANBAN ........................................ 11

3.4. OBSTOJEČE STANJE ............................................................... 11

4. IZBIRA ORODJA ZA PODPORO RAZVOJA ............................................ 12

4.1. PRIKAZ FUNKCIONALNOSTI ORODJA ACSCRUM ................................ 12

4.2. PRIKAZ FUNKCIONALNOSTI ORODJA ATLASSIAN JIRA ......................... 23

4.3. ODLOČITEV O IZBIRI ORODJA .................................................... 33

4.4. NAJPOMEMBNEJŠE PREDNOSTI ORODJA ATLASSIAN JIRA .................... 35

4.5. NAJPOMEMBNEJŠE PREDNOSTI ORODJA ACSCRUM ............................ 35

4.6. RAZLOGI ZA IZBIRO ORODJA ATLASSIAN JIRA ................................. 36

5. UVEDBA METODE SCRUM RAZVOJA APLIKACIJ NA PODLAGI PRAKTIČNEGA PRIMERA ....................................................................................... 37

5.1. IZBIRA PROJEKTA ZA UVEDBO METODE SCRUM................................ 37

5.2. DOLOČITEV VLOG ................................................................. 37

5.3. UPORABNIŠKE ZGODBE ........................................................... 38

5.4. VREDNOTENJE UPORABNIŠKIH ZGODB .......................................... 39

5.5. VREDNOTENJE PREDNOSTNE VLOGE UPORABNIŠKIH ZGODB ................ 40

5.6. SESTANEK ZA NAČRTOVANJE ITERACIJE (SPRINT PLANNING MEETING) .... 41

5.7. DNEVNI SESTANEK (DAILY SCRUM) .............................................. 42

5.8. SESTANEK PO KONCU VSAKE ITERACIJE (SPRINT REVIEW MEETING) ....... 43

5.9. SESTANEK ZA REVIZIJO ITERACIJE (SPRINT RETROSPECTIVE MEETING) .... 43

5.10. MERJENJE IN NADZOR NAPREDKA ............................................ 43

5.11. PREDNOSTI IN SLABOSTI IZBRANEGA ORODJA .............................. 44

6. SKLEP ................................................................................... 45

6.1. PRESOJA UČINKOV ................................................................ 45

6.2. POGOJI ZA UVEDBO ............................................................... 47

6.3. MOŽNOSTI NADALJNJEGA RAZVOJA ............................................ 47

6.4. MNENJE UDELEŽENCEV V PROJEKTU ........................................... 47

6.5. SKLEP ............................................................................... 48

KAZALO SLIK ............................................................................... 50

KAZALO TABEL ............................................................................. 51

POJMOVNIK ................................................................................. 52

KRATICE IN AKRONIMI ..................................................................... 54

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Lea Jerič: Uvedba »SCRUM« metodologije razvoja aplikacij v podjetju Pronet Kranj d. o. o. stran 1

1. UVOD 1.1. PREDSTAVITEV PROBLEMA Zaradi čedalje večje konkurence in vse hitrejšega napredka na področju informatike, programiranja in razvoja programske opreme se v večini IT-podjetij pojavlja težnja k hitrejšemu in kakovostnejšemu (optimalnejšemu) načinu razvoja aplikacij. Uveljavljene metode, po katerih so taka podjetja dolga leta bolj ali manj uspešno razvijala programsko opremo, so za današnji čas postale preokorne, neprilagodljive in prepočasne. Podjetje Pronet, Kranj, d. o. o., je zaradi spoznanja, da jim zdajšnje metode razvoja ne omogočajo več želene konkurenčne prednosti, po predlogu direktorja podjetja in vodje razvoja oblikovalo razvojno skupino, v katero so bili vključeni zaposleni in zunanji partnerji z različnih področij in z različnimi kompetencami. Naloga skupine je bila dejanska in konkretna uvedba metode SCRUM v razvojni oddelek podjetja, in sicer na podlagi konkretnega projekta, razvoja nove aplikacije v oblaku. Gre za reševanje organizacijskih in tehničnih vprašanj, coachinga ljudi in prilagoditve procesov v podjetju zaradi uvedbe metode SCRUM. To vključuje ne samo razvojni oddelek, ampak intenzivno tudi druge oddelke v podjetju.

1.2. PREDSTAVITEV OKOLJA Podjetje Pronet, Kranj, d. o. o., s sedežem v Tehnološkem parku RK IKT Kranj, je uveljavljeno razvojno in informacijsko usmerjeno podjetje na področju razvoja sodobnih in uporabniku prilagojenih poslovnih aplikacij. Za podporo razvoju in inovativnih dejavnosti ima vzpostavljen sistem za inovativnost in opredeljene metode razvoja računalniških aplikacij. Ustanovljeno je bilo leta 1992 v Kranju. V podjetju je redno zaposlenih 18 ljudi. V zadnjih letih se veliko ukvarjajo tudi z medgeneracijskim prenosom znanja in študentom oziroma diplomantom pomagajo pri ustanavljanju zagonskih (start up) podjetij. Sodelujejo tudi z zunanjimi poslovnimi partnerji, katerih področje dela je prav tako informacijski razvoj (IJS, Cosylab, Iskratel itd.). Glavna dejavnost podjetja zajema razvoj in izvajanje informacijskih sistemov za podporo poslovanja v podjetjih. Razvijajo rešitve za podporo vseh vrst potreb uporabnikov, od prodaje, računovodstva, upravljanja človeških virov, distribucije in marketinga do vzdrževanja in nadgradnje informacijskih sistemov. Nudijo tudi svetovanje za učinkovitejše poslovanje, upravljanje informacij in skrajševanje časa za izvedbo posameznih poslovnih procesov. Od leta 2011 se je podjetje specializiralo tudi za razvoj umetne inteligence (prenos uporabe umetne inteligence v gospodarstvo). Pri svojem delu poudarjajo tesno sodelovanje s strankami, ki so ves čas od zasnove, izdelave, testiranja in postavitve informacijskega sistema tesno vpletene v proces. S takim pristopom gradijo poslovni odnos in tudi v nadaljevanju nudijo podporo poslovnim partnerjem v obliki vzdrževanja ali morebitne nadgradnje sistema



Slika 1: Organizacijska struktura podjetja

Produktni vodja oz. direktor, odgovoren za razvoj tehnologije, ima izvršno pozicijo v podjetju ter se ukvarja z znanstvenimi in tehnološkimi vsebinami. Odgovoren je za razvoj in implementacijo programskih produktov in odgovarja neposredno direktorju. V svoji skupini ima sedem razvijalcev. Dva splošna programerja za razvoj poslovnih aplikacij, dva programerja, specializirana za razvoj produktov umetne inteligence, in enega za razvoj mobilnih aplikacij za pametne telefone. Poleg tega sta v skupini še dva sistemska arhitekta, dva dizajnerja aplikacij in grafični oblikovalec. Vodja oddelka marketinga in prodaje je izvršni vodja, odgovoren za marketinške in prodajne aktivnosti v podjetju in poroča neposredno direktorju. Njegove glavne naloge so vodenje prodaje, raziskava trga, upravljanje distribucijskih kanalov, tržno komuniciranje, cenovna politika produktov in podpora strankam. V svoji skupini ima dva pomočnika za spletni marketing, tri produktne vodje za neposredno prodajo programske opreme in asistentko za podporo tržnikom. Vodja tehnične podpore s svojo skupino skrbi za tehnično pomoč strankam pri odpravljanju težav, ki se jim pojavljajo pri uporabi informacijskih sistemov. Vodja financ je odgovoren za upravljanje finančnega poslovanja podjetja. Odgovoren je tudi za finančno načrtovanje, knjigovodstvo in računovodstvo ter analizo podatkov. Odgovarja neposredno direktorju podjetja.

1.3. PREDPOSTAVKE IN OMEJITVE Zdajšnja razvojna skupina je navajena uveljavljenega načina dela in je zadovoljna z njim, zato se poraja vprašanje, ali bo pripravljena sprejeti nove pristope in metode dela. Predpostavljamo, da bomo z dobro predpripravo (pridobljenim potrebnim teoretičnim in praktičnim znanjem), kakovostno predstavitvijo (kratko in jedrnato) nove metode in orodja, prenosom pridobljenega znanja in jasno obrazložitvijo argumentov za uvedbo novega načina dela zdajšnjo razvojno skupino dovolj močno zainteresirali za spremembe, da bo motivirana za delo pri projektu. Predpostavljamo, da bo projekt uspešno izveden in bo metoda SCRUM ustrezna za nadaljnji razvoj programske opreme v podjetju Pronet, Kranj, d. o. o.



1.4. METODE DELA

- Pridobitev teoretičnih osnov – študija metod, pristopov in dosedanjih praktičnih primerov na podlagi spletnih virov in predavanj,

- udeležba in sodelovanje na rednih tedenskih delovnih (SCRUM) sestankih v podjetju,

- izbira in uporaba izbranega orodja in aktivno sodelovanje v razvojni skupini kot pomočnik skrbnika metode v podjetju,

- priprava začetnega seznama zahtev v preglednici programa Excel.



2. METODE RAZVOJA PROGRAMSKE OPREME

2.1. AGILNE METODE Prve agilne metode so nastale že pred letom 2000, vendar so izkušeni inženirji programske opreme ime »agilne metode« prvič uporabili leta 2001 po zborovanju v ameriškem Snowbirdu. Nekateri izmed njih so pozneje ustanovili neprofitno organizacijo The Agille Alliance, ki spodbuja agilni razvoj. Ustvarili so manifest agilnih metod, ki predpisuje načela, ki bi jih morale upoštevati vse agilne metode. Manifest agilnih metod podaja štiri osnovna načela:

- posamezniki in njihova komunikacija so pomembnejši kot procesi in orodja, - delujoča programska oprema je pomembnejša kot obsežna dokumentacija, - sodelovanje stranke je pomembnejše kot pogajanje na podlagi pogodb, - hiter odziv na spremembe je pomembnejši od sledenja načrtu.

Upošteva se še 12 osnovnih načel, kot jih navajata Shore in Warden (2007):

- najpomembnejša prednostna naloga je zadovoljitev stranke s hitro in sprotno dostavo uporabne programske opreme;

- spremembe zahtev so skozi razvoj omogočene tako med razvojem kot proti koncu razvoja. Agilni proces upošteva spreminjanje zahtev naročnika in upoštevanje teh šteje kot konkurenčno prednost za naročnika;

- dostava delujoče programske opreme naj bo čim pogostejša, od nekaj tednov do največ nekaj mesecev, prednostno naj bi se delujoča oprema dostavljala v krajših intervalih;

- naročniki in razvijalci morajo pri razvoju vsakodnevno sodelovati; - pomemben del projekta je motivacija posameznih delavcev, ki jo

pridobimo z ustreznim okoljem in potrebnimi viri ter zaupanjem v njihove sposobnosti, da bo delo dobro in čim prej opravljeno;

- najprimernejši in najučinkovitejši način za posredovanje informacij razvojni skupini in obveščanje med člani skupine je osebni pogovor;

- najpomembnejše merilo napredka je količina delujoče programske kode; - agilni proces predvideva nenehni razvoj projekta. Naročniki, razvijalci in

sponzorji morajo biti sposobni vzdrževati neprekinjen tempo razvoja za nedoločen čas trajanja projekta;

- agilnost izboljšamo z dobrim dizajnom in izpopolnjeno tehnologijo; - ključna je preprostost, ki se kaže v sposobnosti maksimiranja razvoja, ki še

ni dokončan; - samoorganizirane in samovodene skupine podajajo najboljšo arhitekturo

zahtev in dizajna; - naloga skupine je, da intervalno preverja, kako bi lahko postala še

učinkovitejša, temu primerno prilagodi in sprejme ustrezne ukrepe. Agilni pristop razvoja se osredotoča na osebne, tehnične in organizacijske uspehe. Agilne metode dosegajo organizacijske uspehe s poudarkom na zagotavljanju vrednosti in zmanjševanju stroškov. Temeljijo na vodenju projektov s stalnim prilagajanjem in kontroliranjem, spodbujajo timsko delo, samoorganizacijo in odgovornost za opravljeno delo. Ključna je delujoča koda – programska oprema, ne pa popolna dokumentacija.



Prednosti agilnih metod so, da že zelo zgodaj in nepretrgoma končnemu uporabniku podajo delujočo kodo – delujočo programsko opremo. Ne glede na stopnjo razvoja programske opreme lahko kadar koli uporabi nove informacije in spremeni le del kode, kar je velika konkurenčna prednost pred klasičnimi metodami razvoja programske opreme. Pri razvoju ves čas tesno sodelujejo naročnik, končni uporabnik in razvojna skupina. Projekt se gradi okrog motiviranih posameznikov, ki se jim omogoči okolje, v katerem imajo vso podporo za svoje delo, in se jim zaupa, da bodo naloge kakovostno in pravočasno opravili. Informacije se posredujejo neposredno s pogovorom. Napredek se spremlja na rednih delovnih sestankih, na katerih se iščejo tudi poti za čim večjo učinkovitost. Temeljno merilo napredka je delujoča programska oprema. Najbolj znane metode agilnega programiranja so Ekstremno programiranje (XP – Extreme Programming), Scrum, Agilno modeliranje (Agile Modeling), Crystal Clear, Metoda dinamičnega razvoja sistemov (DSDM – Dynamic Systems Development Method), Razvoj, narekovan z lastnostmi (FDD – Feature Driven Development) (povzeto po Agilne metode razvoja programske opreme, 2015).

2.2. METODA WATERFALL – PRIMER KLASIČNE METODE Za metodo Waterfall je značilno, da je napredek med načrtovanjem stalno viden. Začne se s fazo zasnove, nadaljuje v analizo načrtovanja, gradnjo, testiranje, proizvodnjo/izvajanje in vzdrževanje. Metoda izvira iz predelovalne in gradbene industrije, kjer poznejše spremembe v razvoju niso bile mogoče ali so pomenile velik dodaten strošek. Ker v preteklosti ni bilo nobene boljše metode, so morali uporabljati to. Glavna značilnost metode je, da lahko v naslednjo fazo nadaljujemo le, ko je prejšnja faza uspešno končana. Seveda so izjeme, saj se v nekaterih različicah metode Waterfall lahko premikamo po eno fazo nazaj ali naprej, da bi odpravili pomanjkljivosti, vendar metoda še zdaleč ni tako fleksibilna kot SCRUM. Prav zato je pomembno, da pomanjkljivosti najdemo v zgodnjih fazah cikla, saj je tako za njihovo rešitev potrebnega veliko manj dela in stroškov kot v poznejših fazah. V povprečju je 20–40 odstotkov časa vloženega v prvo in drugo fazo, 30–40 odstotkov časa je namenjenega kodiranju, preostali čas pa je namenjen testiranju in implementaciji (povzeto po Waterfall model, 2015). Zelo pomembna sestavna dela metode Waterfall sta izvorna koda in dokumentacija (dokumenti z zahtevami ali projektna dokumentacija). Če se skupina, ki sodeluje pri projektu, spremeni, je zelo pomembno, da so celoten potek, dizajn in zahteve dovolj podrobno zapisani, da se novi udeleženci lahko poučijo o projektu. V nasprotnem primeru se lahko veliko podatkov izgubi in je tako projekt nemogoče končati ali ga je težje končati (povzeto po Waterfall model, 2015). Torej je metoda uporabna pri projektih, ki imajo vnaprej določene zahteve, poleg tega je produkt izdelave vnaprej določen in se ne spreminja. Ker odjemalci ne morejo določiti zahtev, dokler se ne seznanijo z delujočim programom, oziroma so te napačne ali nepopolne, lahko njihova reorganizacija in sprememba povzročita



dodatne stroške, ki so lahko zelo visoki. Prav zato je zelo pomembno, da za vsak posamezni projekt izberemo ustrezno metodo.

2.3. PREDNOSTI UPORABE AGILNIH METOD RAZVOJA APLIKACIJ V PRIMERJAVI S KLASIČNIMI METODAMI

Zaradi čedalje hitrejšega razvoja tehnologije moramo na vseh področjih slediti novostim, saj si le tako lahko zagotovimo konkurenčnost. Tradicionalne metode sledijo točno določenemu, vnaprej predpisanemu postopku, v katerem je vsak korak natančno načrtovan. Torej naročnik šele na koncu dobi izdelek - delujočo kodo, ki je načeloma ne more več spremeniti oziroma bi to razvijalcu vzelo veliko časa, kar pomeni tudi dodatne stroške, tako za razvijalca kot naročnika. Na drugi strani agilne metode prav z intenzivnim sodelovanjem med razvijalci in uporabniki v celotnem procesu zagotovijo zadovoljstvo strank, poleg tega omogočajo lažje ter sprotno reševanje in spremembe v kodi. Celoten projekt je med razvojem viden vsem razvijalcem, s čimer se izboljša komunikacija med člani razvojne skupine. Ker tradicionalne metode kot podlago uporabljajo obsežno dokumentacijo, imajo močno oteženo poznejše upoštevanje sprememb. Za agilne metode je značilen inkrementalen razvoj, kar pomeni, da uporablja kratke cikle, katerih rezultat je delujoča koda, ki gre takoj v uporabo. Prav zato je največja prednost agilnih metod prilagodljivost vsakokratnim spremembam, saj lahko kadar koli vključimo spremembe, ki jih zahteva naročnik. Ta ob dogovorjenih rokih dobiva posamezne dele rešitve, poleg tega ima s tem sprotni vpogled v to, kako programska oprema v resnici deluje. Prav s to komunikacijo se izboljšajo odnosi z naročnikom ter se poveča zaupanje in se vzpostavi ozračje, v katerem vsi verjamejo v uspeh projekta.



3. METODA SCRUM

3.1. SCRUM Ime scrum izvira iz ragbija in pomeni vrnitev žoge v igro. Metoda je nastala v prvi polovici devetdesetih let prejšnjega stoletja. Ta pristop razvoja programske rešitve predpisuje ponavljajoč se način dela. Projekt je časovno razdeljen na več iteracij (ponavljanj) in posamezna iteracija se imenuje Sprint. Vsaka iteracija traja enako število dni, njen končni rezultat pa mora biti delujoča programska koda. Nova programska koda mora prinašati novo funkcionalnost programske rešitve, ki mora biti preverjena, preden jo damo v uporabo naročniku. Tako naročnik postopoma dobiva posamezne dele končne delujoče programske opreme. Zelo pomembno je, da se med iteracijo ne spreminjajo naslednji pogoji: sestava članov, cilji, kakovost dela in vsebina iteracij (povzeto po Mahnič, Georgiev in Jarc, 2009). Metoda SCRUM predpisuje tri glavne vloge: Product Owner, Scrum Master in Scrum Team. Product Owner je predstavnik naročnika in lastnik izdelka, imenovan tudi produktni vodja, poda pobudo za izdelavo izdelka in priskrbi vsa potrebna sredstva za nemoten razvoj projekta. Izdela tudi seznam zahtev, določi prednostne naloge in načrtuje predajo posamezne delujoče kode v končno uporabo (povzeto po Mahnič et al., 2009). Scrum Master je skrbnik metode in skrbi, da je celotni proces skladen z metodo SCRUM. Druge udeležence (razvojno skupino) mora naučiti, kako deluje metoda SCRUM. Izvajati mora nadzor in skrbeti, da se upoštevajo pravila metode (povzeto po Mahnič et al., 2009). Scrum Team oziroma razvojna skupina skrbi za razvoj novih funkcionalnosti programske opreme v okviru posamezne iteracije. Razvojna skupina je samoorganizirana, člani si sami razdelijo naloge (zahteve), sami se odločijo, kako bodo izvedli izbrane zahteve in v katerem okolju bodo te zahteve izvajali. Tako prevzamejo popolno odgovornost za uspeh projekta (povzeto po Mahnič et al., 2009). Poleg glavnih vlog je še stranska, v tej nastopajo opazovalci. Opazovalci morajo imeti ustrezno dovoljenje, da lahko prisostvujejo pri projektu, se pa nikakor ne smejo vmešavati v projekt. Pri projektu sodelujejo zaradi lastnih interesov (povzeto po Mahnič et al., 2009). Product Backlog je seznam zahtev naročnika, sestavi se pred začetkom izvajanja projekta. Za seznam zahtev skrbi produktni vodja oziroma njegov predstavnik. Seznam zahtev ni dokončen, ampak se ves čas izvajanja projekta lahko dopolnjuje, lahko se dodajajo nove zahteve in se sočasno znova določajo prednostne naloge, odvisno od trenutnih potreb končnega uporabnika (povzeto po Mahnič et al., 2009).



Sprint Planning Meeting oziroma sestanek za načrtovanje iteracije je sestanek, na katerem sodelujeta naročnik oziroma predstavnik naročnika in razvojna skupina, poteka pa pred vsako iteracijo. Na sestanku se določijo tiste zahteve, ki bodo izvedene v naslednji iteraciji. Sestanek traja osem ur, dvakrat po štiri ure. V prvem delu sestanka se dogovorijo, katere zahteve s celotnega seznama zahtev imajo najvišjo prednost in bodo izvedene v prvi iteraciji. V drugem delu sestanka razvojna skupina naredi seznam nalog (Sprint Backlog), ki so potrebne za izvedbo izbranih zahtev. Tako kot se lahko v okviru iteracije dodajajo posamezne zahteve, se lahko dodajajo tudi naloge. V prvi fazi so naloge opredeljene zelo splošno, zato jih je treba v nadaljevanju razdeliti na več manjših. Za izvedbo posamezne naloge naj bi potrebovali od štiri do 16 delovnih ur (povzeto po Mahnič et al., 2009). Daily Scrum Meeting je dnevni sestanek razvojne skupine, traja 15 minut. Dnevni sestanki se odvijajo v okviru vsake iteracije. Na sestanku mora vsak član razvojne skupine dnevno odgovoriti na tri vprašanja: kaj si delal od prejšnjega sestanka, kaj nameravaš delati do naslednjega sestanka in s katerimi težavami se srečuješ pri delu (Mahnič et al., 2009). Tako se spremlja tekoče delo in se vrednoti preostanek še neopravljenega dela, poleg tega se hitro zaznajo morebitne težave in se lahko sproti odpravljajo. Sprint Review Meeting je sestanek, ki poteka vedno ob koncu iteracije. Na tem sestanku razvojna skupina naročniku oziroma njegovemu predstavniku in vsem zainteresiranim uporabnikom predstavi rezultate svojega dela. Ta sestanek uporabnikom omogoča, da podajo svoje pripombe in predloge za zahteve v naslednji iteraciji. Pred začetkom naslednje iteracije se razvojna skupina sestane še s skrbnikom metode (Scrum Master), da bi presodili, ali je potek dela v prejšnji iteraciji potekal v skladu s pravili metode SCRUM, in da bi se dogovorili za izboljšave, ki bi razvojni skupini omogočile, da postane še učinkovitejša (povzeto po Mahnič et al., 2009). Na sliki 2 je predstavljen prikaz projekta SCRUM. Najprej člani razvojne skupine določijo želene cilje oziroma kaj morajo opraviti v nekem intervalu, in s tem določijo naloge s seznamom zahtev (Product Backlog). Naloge nato dodelijo na seznam Sprint Backlog, v posamezen cikel. Člani se vsakodnevno oziroma po potrebi o sprotnih zadevah pogovorijo na kratkih dnevnih sestankih (Daily Scrum Meeting).



Slika 2: Potek procesa Scrum (Vir: Schwaber, 2004)

3.1.1. POKER METODA Poker metoda pomaga pri presojanju zahtevnosti posameznih zahtev in nalog. Poteka podobno kot igra s kartami, saj pri tej metodi razvijalci podajajo mnenje s kartami in tako iščejo glavno mnenje, s katerim se vsi strinjajo. Prvi pogoj je prisotnost celotne skupine, običajno od tri do deset razvijalcev, saj se bodo le tako lahko soglasno odločili za mnenje, s katerim se vsi strinjajo. Drugi pogoj je dogovorjen način razdeljevanja ocen. Najprej sta potrebni sestava lestvice ocen in določitev najvišje možne ocene. Vsak razvijalec ima na voljo določeno število kart, ki so namenjene vrednotenju. Igro vodi moderator oziroma skrbnik metode (Scrum Master), ki najprej prebere uporabniško zgodbo. Temu sledi razprava o zadevi in vprašanja o izdelku, skrbnik metode običajno ne podaja ocen. Nato sledi glavni del - vrednotenje. Vsak razvijalec subjektivno določi oceno, pri čemer je pomembno, da oceno pokažejo vsi naenkrat. S tem dosežemo, da ocene enega razvijalca ne vplivajo na drugega. Razvijalca, ki podata najvišjo in najnižjo oceno, morata svojo odločitev utemeljiti. Skrbnik metode poskrbi, da so člani skupine strpni, da ne kritizirajo odločitev sočlanov in da drugi mnenje sprejmejo, o njem premislijo in če se jim zdi primerno, ga upoštevajo pri naslednjem glasovanju.



Po kratkem premisleku se glasovanje ponovi in se ponavlja toliko časa, dokler člani ne menijo enako. Če se člani ne morejo dogovoriti za točno končno oceno, je naloga skrbnika metode, da poišče vmesno rešitev. Pomemben dejavnik pri vrednotenju je tudi čas. Člani skupine se morajo držati predhodno dogovorjenih časovnih rokov. Zanimiv pristop je uporaba peščene ure, ki jo razvijalec obrne, ko želi izraziti svoje mnenje. Časa ima natanko dve minuti. Če je uporabniških zgodb več ali so te obsežne, jih lahko razdelimo tudi na več sestankov. S tem člane skupine razdelimo na manjše skupine in tako dosežemo bolj interno in podrobno odločanje. Vsaka manjša skupina mora imeti vsaj tri člane. Poker metoda je tako ena izmed najbolj uspešnih metod odločanja, saj je mešanica vseh že znanih oblik, poleg tega je zabavna za razvijalce. O posameznih zadevah tako odločajo razvijalci, ki so bolj usposobljeni za neko področje. Najpomembnejši del je razprava, saj se razvijalci poučijo med seboj in tako dobijo nove ideje ali se seznanijo z novimi dejstvi, na katera prej niso bili pozorni. (povzeto po Cej, 2010). 3.1.2. ESTIMATION METODA Pri metodi Team Estimation Game kot orodje uporabljamo kartice z uporabniškimi zgodbami, ki so zložene na mizo. Tisti, ki prvi daje mnenje, dvigne prvo kartico in jo postavi na mizo. Naslednji ocenjevalec ima tri možnosti. Ko vzame naslednjo kartico, jo lahko položi v isti stolpec, levo ali desno od prve kartice, če pa bi bilo kartic že več, lahko tudi prestavi katero od kartic, ki je že položena na mizo, ali preskoči potezo. Ko zmanjka kartic ali nihče od ocenjevalcev ne želi več premakniti nobene kartice, se glasovanje konča. Vsak stolpec kartic na mizi nato ovrednotimo z vrednostmi: 1, 2, 3, 5, 8, 13, 20, pri katerih so pomembna razmerja, in ne ocene (povzeto po Mahnič, 2014a).

3.2. KANBAN Že v letu 1940 je Toyota optimizirala svoj proizvodni proces na podlagi podobnega modela, kot ga supermarketi še danes uporabljajo za polnjenje polic – na podlagi potreb potrošnikov. Iz tega je nastala metoda, ki se še danes uporablja v proizvodnji, znana pod imenom Just in time - JIT. Podobno danes uporabljajo metodo Kanban tudi skupine razvijalcev programske opreme. S primerjanjem količine dela v izvedbi in kapaciteto skupine. Kanban je metoda za upravljanje in razdeljevanje razvojnega dela s poudarkom na izdelavi »ravno ob pravem času«, pri čemer ne preobremenjuje članov razvojne skupine. Pri tem pristopu je proces od opredelitve naloge do njene izdelave prikazan vsem udeležencem. Uporablja se načelo odvzemanja, pri čemer razvijalci jemljejo (vsak) svoje delo iz vrste. Takoj ko je končana ena naloga, razvijalec s seznama vzame drugo in nadaljuje delo na naslednji nalogi.



3.3. PRIMERJAVA METOD SCRUM IN KANBAN

SCRUM KANBAN

Enako dolge iteracije. Ni nujno, da so iteracije enako dolge.

Razvojna skupina se obveže za obseg dela, ki ga bo opravila v eni iteraciji.

Razvojni skupini se ni treba obvezati za obseg dela v okviru ene iteracije.

Razvojna skupina pokriva vsa področja.

Za posamezna področja so lahko specializirane razvojne skupine.

Velikost opravil v eni iteraciji je predpisana.

Velikost opravil v eni iteraciji ni predpisana.

Obvezna uporaba diagrama Burndown.

Ni predpisov glede uporabe diagramov.

Predpisano je vrednotenje zahtevnosti.

Ni predpisano vrednotenje zahtevnosti.

Sredi iteracije ne smemo sprejeti nove naloge.

Sredi iteracije lahko sprejmemo novo nalogo, če so na razpolago proste zmogljivosti.

Vsaka razvojna skupina uporablja svoj Sprint Backlog.

Tablo lahko uporablja več razvojnih skupin.

Predpisane so tri različne vloge. Vloge niso predpisane.

Na začetku vsake iteracije se briše tabla.

Tabla obstaja ves čas projekta.

Zgodbe v Product Backlogu morajo biti razvrščene po prednosti.

Prednostne naloge se lahko določijo, ni pa nujno.

Tabela 1: Primerjava metod Scrum in Kanban (Vir: povzeto po Mahnič, 2014b)

3.4. OBSTOJEČE STANJE Podjetje je do zdaj pri svojem razvoju uporabljalo metode, postopke in procese dela t. i. RUP (Rational Unified Process). Načrtovanje in organizacija dela programerjev sta potekala po neki vmesni, samostojno prilagojeni različici med klasično metodo Waterfall in SCRUM-om. Za splošni načrt del in sledenje izvedbi sta se uporabljala orodji Microsoft Project in MS Team Manager. S tema orodjema so se vodili seznam nalog, predvideni obseg dela in dejanska količina opravljenega dela po posameznih razvijalcih. Orodji sta se uporabljali tudi za potrebe analiz opravljenega dela. Zahteve uporabnikov (User stories), tako notranje kot zunanje, so se zapisovale v Excelovo preglednico, shranjeno na Google Drivu, do katere so imele dostop vse ključne osebe v podjetju. Na tedenskih sestankih razvojne skupine so se uporabniške zgodbe dopolnjevale v Excelovi preglednici. Na sestanku so se natančneje opredelile in določila sta se njihova prednostna vloga in izvajalec. Naknadno so se vnesle v orodje Bugzilla, takoj za tem pa še v orodje MS Team Manager, ta se uporablja za pripravo poročil za vodstvo podjetja.



4. IZBIRA ORODJA ZA PODPORO RAZVOJA Podjetje Pronet, Kranj, d. o. o., se s svojo razvojno skupino že kar nekaj časa srečuje s problematiko čim bolj učinkovitega vodenja in načrtovanja razvoja nove programske opreme. Da bi našli čim bolj ustrezno in učinkovito metodo za razvoj novih programskih aplikacij, s katero bi bili hitreje odzivni na hitro se spreminjajoči trg in zahteve kupcev oziroma naročnikov, so se odločili, da v podjetje uvedejo metodo razvoja programske opreme SCRUM. Pred uvedbo metode smo se že posvetili teoretičnemu spoznavanju najbolj razširjene agilne metode za razvoj programske opreme. Po teoretični seznanitvi s to metodo pa se je pojavilo vprašanje, katero orodje bi bilo najustreznejše za uvedbo in spremljavo te metode. Na trgu je na voljo dokaj široka izbira orodij za podporo dela z metodo SCRUM. Nekatera orodja so zelo preprosta in zato primernejša za vodenje nezahtevnih projektov. Na voljo pa so tudi večfunkcionalna orodja, ki so zahtevnejša za uporabo, vendar omogočajo več funkcij, ki so koristne pri vodenju več sočasnih projektov z različnimi ali istimi razvijalci. Omogočajo tudi več poročil in s tem povezano lažje sledenje napredku posameznega projekta. Narejena je bila natančna analiza dveh izbranih orodij, ki podpirata tudi metodo SCRUM: ACScrum in Atlassian Jira.

4.1. PRIKAZ FUNKCIONALNOSTI ORODJA ACSCRUM Orodje ACScrum je bilo razvito na Univerzi v Ljubljani, na Fakulteti za računalništvo in informatiko leta 2011 (Mahnič, 2014a; ACScrum, vstopna stran, 2015). Orodje je namenjeno izključno za vodenje projektov po metodi SCRUM. Primerno je za manjše skupine in sočasno vodenje več, vendar manjših projektov. Uporabnikove prilagoditve orodja niso mogoče, niti ni mogoče povezovanje z drugimi programi, ki jih podjetje že uporablja.



Slika 3: Vstopna stran

(Vir: ACScrum, vstopna stran, 2015) Na sliki 3 je okno za prijavo v orodje ACScrum, do katerega se dostopa prek spletnega naslova http://ltpo2.fri1.uni-lj.si/pronet/. Za prijavo v orodje sta potrebna uporabniško ime in geslo. Po vnosu teh se ob kliku na gumb Login prikaže začetna stran programa. Meni ponuja naslednje opcije: Control panel, Project wall, Product backlog, My tasks in Progress reports. Na desni strani zgoraj je seznam vseh projektov in možnost za začetek novega projekta. Desno spodaj pa so razvidne zadnje aktivnosti na posameznem projektu. V nadaljevanju si bomo ogledali in pojasnili, kaj točno pomeni in zakaj se uporablja posamezna funkcija.

http://ltpo2.fri1.uni-lj.si/pronet/



Slika 4: Začetno okno z menijem

(Vir: ACScrum, vstopna stran, 2015)

Na sliki 4 je razvidno, da se ob kliku Control panel prikažejo podmeniji: Edit users, New users, Edit projects, Reports. Prek Edit users je jasen pregled nad vsemi uporabniki programa in omogoča, da se uporabnikom spreminjajo pravice, se jih dodaja ali odvzema.

Slika 5: Vnos podatkov o novem uporabniku

(Vir: ACScrum, vstopna stran, 2015) Na naslednjem zavihku se vnesejo podatki o novem uporabniku, s tem se mu dodeli dostop do uporabe orodja.



Slika 6: Urejanje podatkov

(Vir: ACScrum, vstopna stran, 2015) Na zavihku Edit projects se lahko spreminjata ime in opis projekta, lahko se dodaja ali odvzemajo podatki o članih projekta in se izbriše celoten projekt.

Slika 7: Izdelava poročil

(Vir: ACScrum, vstopna stran, 2015) Ker je za pravilen potek projekta zelo pomemben neprestan nadzor nad delom, zavihek Reports omogoča izdelavo štirih vrst poročil: Team Involvement Report, Burn Down Report, Realisation Report, Decomposition Report. Poročila so zelo uporabna prav zaradi preprostega branja in razumevanja. Drugi zavihek v glavnem meniju je Project wall, ki je namenjen komentarjem in sporočilom uporabnikov. S klikom na zavihek se prikažejo podmeniji: Daily Scrum, Discussion, Documentation.



Slika 8: Oglasna tabla (Project Wall) in dnevni sestanek (Daily Scrum)

(Vir: ACScrum, vstopna stran, 2015) Na sliki 8 je razviden prvi zavihek, v katerega vsak član napiše, kaj je delal od zadnjega sestanka, kaj načrtuje, da bo naredil do naslednjega sestanka, in morebitne težave, ki jih je imel pri delu.

Slika 9: Razprava

(Vir: ACScrum, vstopna stran, 2015) Za uspešno in kakovostno opravljeno delo sta zelo pomembna pogovor med uporabniki in neprestana izmenjava podatkov. Vsak uporabnik ima možnost komunikacije z drugimi člani skupine preko ACScruma, kar je vidno na sliki 9. Uporabnik svoj komentar vpiše v prazno polje, vsi odgovori drugih članov pa so vidni spodaj.



Slika 10: Dokumentacija

(Vir: ACScrum, vstopna stran, 2015) Na sliki 10 je polje, prek katerega se lahko ustvari ali naloži dokumentacija v projekt.

Slika 11: Seznam zahtev (Product Backlog)

(Vir: ACScrum, vstopna stran, 2015) Naslednji zavihek v glavnem meniju je Product Backlog, ki je namenjen urejanju uporabniških zgodb. Ob kliku se pokažejo podmeniji: Unfinished stories, Finished user stories, Future releases, New user story. Prvi zavihek omogoča vnos nove zgodbe, ki se shrani s klikom na polje Save story, nato je razvidna v podmeniju Unfinished stories (nedokončane zgodbe).



Slika 12: Nedokončane uporabniške zgodbe

(Vir: ACScrum, vstopna stran, 2015) V zavihku, kot je razviden na sliki 12, so vidne le zgodbe, ki se še niso začele ali so se začele in še niso dokončane. Na sliki 12 je torej vidno, da so bile v drugo iteracijo uvrščene tri uporabniške zgodbe: pripravi predstavitev, seznam udeležencev in izvedba izobraževanja. Za vse zgodbe, ki niso v že začeti iteraciji, se v tem delu lahko ovrednoti vrednost posamezne zgodbe. Vrednost zgodbe lahko določajo člani projekta na podlagi dveh metod, Team Estimation in Planning Poker. Vrednost posamezne zgodbe se vrednoti v enoti Story points. Ko so zgodbe ovrednotene, se lahko dodajo v posamezno nekončano iteracijo.



Slika 13: Ustvarjanje iteracije

(Vir: ACScrum, vstopna stran, 2015) S klikom na gumb Manage Sprints spodaj desno se odpre novo okno, v katerega se lahko vnesejo podatki nove iteracije. Ko so vneseni vsi potrebni podatki, se potrdijo s klikom na gumb Create Sprint.

Slika 14: Dodajanje nalog

(Vir: ACScrum, vstopna stran, 2015) Sprint Backlog je predvsem namenjen dodajanju in urejanju nalog. Po izbiri menija se prikažejo podmeniji: All stories in My stories. V podmeniju All stories se lahko dodajo naloge za posamezne zgodbe. Po kliku na Edit tasks se odpre okno za vnos posamezne naloge, kot je vidno na sliki 14. Najprej se izbere naloga, nato se ta določi osebi, za katero želimo, da nalogo izvede, in določi se še čas, ki naj bi ga porabili za neko zadevo. Po kliku na gumb Save changes se naloga shrani.



Slika 15: Uporabnikovo sprejetje nalog

(Vir: ACScrum, vstopna stran, 2015) Ko so naloge shranjene, časovno ovrednotene in dodeljene posameznikom, se lahko začne delo na posamezni nalogi. Če uporabnik želi nalogo sprejeti, to naredi s klikom na gumb Accept task, s čimer se status spremeni v Assigned, kar pomeni, da mu je naloga uspešno dodeljena.

Slika 16: Pregled trenutnih nalog

(Vir: ACScrum, vstopna stran, 2015) Po kliku na gumb Start work program začne meriti čas vloženega dela do trenutka, ko je delo končano ali ustavljeno. To se označi s klikom na gumb Stop working. Na tej strani si je mogoče ogledati tudi celotno zgodovino dela. Če je naloga dokončno končana, se to označi s klikom na Release task. Ta gumb je v modrem oklepaju, poleg posamezne naloge.



Poročila o opravljenem delu so zelo pomemben del projekta, saj so najbolj pregleden prikaz napredka. Prikaz omenjenih poročil je razviden na spodnjih štirih slikah.

Slika 17: Poročilo Team Involvement Report

(Vir: ACScrum, vstopna stran, 2015) Poročilo na sliki 17 prikaže vloženo delo posameznega člana v posamezni iteraciji.



Slika 18: Poročilo Burndown Report (Vir: ACScrum, vstopna stran, 2015)

Poročilo na sliki 18 prikaže, koliko časa je še na razpolago za dokončanje posamezne iteracije in koliko dela je bilo izvedenega v okviru iteracije.

Slika 19: Poročilo Realisation Report (Vir: ACScrum, vstopna stran, 2015)

Za skrbnika metode (Scrum Master) je zelo pomemben napredek posameznega člana projekta. Iz poročila na sliki 19 se lahko razbere izvedba dokončanih zgodb po posameznikih.



Slika 20: Poročilo Decomposition Report

(Vir: ACScrum, vstopna stran, 2015) Da bi bil projekt čim bolj uspešno opravljen, je pomembno, da ima skrbnik metode pregled nad številom zgodb in nalogami posamezne iteracije.

4.2. PRIKAZ FUNKCIONALNOSTI ORODJA ATLASSIAN JIRA Scott Farquhar in Mike Cannon-Brookes sta leta 2002 ustanovila uspešno računalniško podjetje, ki ima sedež v Avstraliji. Njun prvi produkt je bil JIRA. Orodje Atlassian Jira je zasnovano tako za majhne kot velike skupine, omogoča integracije z drugimi programi, izvedljive so tudi nadgradnje orodja. Možno ga je uporabljati tudi za vodenje projektov, preprost razvoj programske opreme, metodo Kanban, dodeljevanje posameznih nalog itd.

Slika 21: Ustvarjanje novega projekta (Vir: Atlassian, Jira Software, 2015)

https://www.atlassian.com/company



Za ustvarjanje novega projekta se zgoraj levo v meniju izbere zavihek Projects. Odpre se spustni seznam, s klikom na Create project se lahko začne delo.

Slika 22: Izbira vrste projekta

(Vir: Atlassian, Jira Software, 2015) Odpre se funkcijsko okno, kot je razvidno na sliki 22. S tem se izbere vrsta projekta, v tem primeru zgoraj levo Scrum software development.

Slika 23: Vnos imena projekta

(Vir: Atlassian, Jira Software, 2015) V prvo okence se vnese ime projekta, v drugo Key oziroma ključ za ime projekta, v zadnjega pa se vnesejo podatki o skrbniku metode. Dejanje se potrdi s klikom na gumb Submit.



Slika 24: Seznam zahtev (Backlog)

(Vir: Atlassian, Jira Software, 2015) Odpre se prva stran projekta, imenovana Backlog. Tu se lahko vnesejo uporabniške zgodbe in zahteve, ki morajo biti opravljene, ter se razvrstijo v iteracije. Če želi

uporabnik v projekt dodati člane, desno zgoraj uporabi polje Administrations ( ) in izbere User management. Odpre se okno za vnos podatkov o članih projekta.

Slika 25: Ustvarjanje obsežnih uporabniških zgodb (Epic) in uporabniških zgodb

(Story) (Vir: Atlassian, Jira Software, 2015)

Celoten projekt je razdeljen na več nalog oziroma zadev (Issue). Ustvarijo se s klikom na gumb Create, ki je v zgornji glavni vrstici. Odpre se okno Create issue, v katerega se vnese ime projekta ter se izbira med več tipi nalog oziroma zadev (Issue), ki se razlikujejo po namenu, a so tematsko povezane: Epic, Story in Sub-task. V tem primeru se odločimo za Epic, jo označimo in v tretje polje vpišemo



kratek opis tega. V četrto polje se vpiše osebo, ki ji morajo uporabniki poročati o napredku, v peto se vnesejo natančne zahteve za posamezno nalogo in v šesto pomembnost oziroma prednostna vloga naloge. Dejanje se potrdi z gumbom Create spodaj desno.

Slika 26: Urejanje seznama zahtev (Vir: Atlassian, Jira Software, 2015)

Z desnim klikom na posamezno nalogo se na desni strani odpre okno, kjer so navedene podrobnosti izbrane naloge, torej presoja potrebne količine dela za posamezno nalogo, ki se vrednoti s časom in s točkami. Z orodjem se lahko ustvari tudi podnaloga (Sub-task), ki se uporablja takrat, ko je osnovna naloga (npr. Story) prevelika in jo je treba zaradi lažje obvladljivosti razdeliti na več delov.



Slika 27: Ustvarjanje podnalog (Subtask)

(Vir: Atlassian, Jira Software, 2015) S klikom na gumb Create Sub-task se ustvari nov del naloge. Odpre se podobno okno kot pri ustvarjanju Epica in Storyja. Po vnosu imena in opisa v polju Assignee se določi razvijalca, ki je odgovoren za nalogo. V polje Estimation time se vnese čas, ki je predviden za dokončanje neke naloge. Po vnosu vseh potrebnih podatkov se lahko iteracija aktivira.

Slika 28: Ustvarjanje iteracije

(Vir: Atlassian, Jira Software, 2015)



Kot je razvidno na sliki 28, se iz menija skrajno levo izbere polje Backlog. Poleg menija se odpre okno, v katerem je seznam vseh vnesenih zgodb. Iteracija se ustvari s klikom na gumb Create Sprint, ki je desno zgoraj.

Slika 29: Dodajanje zgodb v iteracijo (Vir: Atlassian, Jira Software, 2015)

S seznama v Backlogu se izberejo zgodbe, ki naj se uvrstijo v novo ustvarjeno iteracijo, in z miško se prestavijo v seznam Sprint, ki je nad seznamom Backlog.

Slika 30: Nadaljnje ustvarjanje iteracij in dodeljevanje zgodb v posamezno

iteracijo (Vir: Atlassian, Jira Software, 2015)



Velika prednost programa je, da se lahko iteracije ustvarijo vnaprej in tako se zgodbe razdelijo v posamezno iteracijo. Naslednjo oziroma novo iteracijo je mogoče v tem orodju izjemoma začeti tudi pred končanjem prejšnje.

Slika 31: Aktivne iteracije

(Vir: Atlassian, Jira Software, 2015) Za vse člane skupine je zelo pomemben pregled nad opravljenimi in neopravljenimi nalogami. Pri tem si lahko pomagajo s pregledom, kot je na sliki 31. Na seznamu skrajno levo se izbere polje Active Sprints. Tu so razvidne vse naloge - Stories in Sub-tasks - v aktivni iteraciji. V začetku iteracije so vse naloge v stolpcu To-Do, kar pomeni, da še niso v izvajanju oziroma še niso opravljene. Ko razvijalec začne delati na posamezni nalogi, to prenese v stolpec In Progress, kar pomeni, da se z nalogo nekdo že ukvarja, vendar je še ni končal. Ko nalogo opravi, jo prenese v stolpec Done. Ta oglasna tabla ves čas omogoča nadzor napredka v posamezni iteraciji.



Slika 32: Poročilo Burndown Chart

(Vir: Atlassian, Jira Software, 2015) Program ponuja več možnosti prikaza dela, posebej bomo omenili pet vrst pomembnih poročil. Prvi omogoča sledenje preostali količini dela in predvidevanje verjetnosti doseganja cilja iteracije. Skupini pomaga spremljati napredek dela in po potrebi ustrezno ukrepanje. Siva črta na diagramu predstavlja idealen, rdeča pa dejanski potek.

Slika 33: Poročilo Sprint Report




Naslednje poročilo je Sprint Report, ki prikazuje dokončano delo oziroma naloge, ki so vrnjene v Backlog. Pomaga določiti, ali je skupina naredila več ali manj od predvidenega.

Slika 34: Poročilo Epic Burndown

(Vir: Atlassian, Jira Software, 2015) Tretje poročilo omogoča sledenje načrtovanemu številu iteracij, potrebnih za izvedbo obsežnejše uporabniške zgodbe (Epic). Pomaga opazovati, ali bo neko obsežnejšo uporabniško zgodbo mogoče izvesti pravočasno, in s tem omogoča pravočasno ukrepanje, če delo zaostaja.



Slika 35: Poročilo Cumulative Flow Diagram

(Vir: Atlassian, Jira Software, 2015) Na sliki 35 je razviden diagram, ki prikazuje status (To Do, In Progress, Done) posameznih nalog skozi čas, kar lahko pomaga pri ugotavljanju ozkih grl, ki jih je treba podrobneje proučiti.

Slika 36: Poročilo Time Tracking Report

(Vir: Atlassian, Jira Software, 2015) Poročilo Time Tracking Report prikazuje prvotno predviden čas za dokončanje posamezne naloge in že porabljen čas za posamezno nalogo. Pomaga pri določitvi, ali posamezne naloge sledijo načrtovanim časom za dokončanje naloge v okviru ciljev.



4.3. ODLOČITEV O IZBIRI ORODJA Primerjava obeh zgoraj predstavljenih orodij in končna izbira med njima sta bili narejeni izključno za potrebe podjetja Pronet, Kranj, d. o. o. V diplomskem delu parametre odločitve podajamo kot primer, na podlagi katerega je mogoče proces odločanja in odločitev smiselno implementirati v podobnih poslovnih sistemih. Po seznanitvi podjetja (direktorja podjetja, vodje razvoja in razvojne skupine) z metodo SCRUM, orodjem ACScrum in orodjem Atlassian Jira smo s podjetjem določili seznam zahtev, ki se nanašajo na lastnosti in funkcionalnosti orodja in za katere je podjetje zahtevalo, da jih izbrano orodje vsebuje oziroma da jo podana funkcionalnost v orodju v največji možni meri vsebuje. Na podlagi zahtevanih lastnosti in funkcionalnosti posameznega orodja smo s podjetjem izoblikovali merila za primerjavo obeh orodij. Merila so razvidna iz prvega stolpca tabele 2. Pred začetkom vrednotenja smo določili lestvico za vrednotenje od 0 do 5, pri čemer posamezna ocena pomeni:

- 0 ni mogoče, - 1 neustrezno, - 2 delno ustrezno, - 3 ustrezno, - 4 zelo ustrezno, - 5 povsem ustrezno.

Na sestanku vrednotenja meril smo sodelovali direktor podjetja, skrbnik metode in razvojna skupina. O vsakem merilu smo razpravljali tako dolgo, da nihče od prisotnih ni imel več dodatnih vprašanj. Ko je bila razprava o posameznem merilu končana, je vsak od prisotnih podal subjektivno oceno in jo pokazal drugim ocenjevalcem. Tisti, ki je podal najnižjo oceno, in tisti, ki je podal najvišjo, sta utemeljila svojo odločitev. Po utemeljitvah se je presoja meril ponovila in tako se je ponavljalo, dokler se niso vsi strinjali o vrednosti posameznega merila. Končne ocene posameznih meril za orodji ACScrum in Atlassian Jira so razvidne iz tabele 2.



Tabela 2: Primerjava orodij ACScrum in Atlassian Jira

kriterij AC Scrum Atlassian Jira

spletna aplikacija (v oblaku) 5 5

možnost nakupa/dosegljivost 0 5

vsebuje navodila s primeri in pomoč uporabniku 0 5

možnost izobraževanja za uporabo orodja 2 5

enostavnost uporabe 3 4

moderen uporabniški vmesnik 2 5

možnost kreiranja in urejanja novega projekta 4 5

možnost vnosa in urejanja projektnega tima 4 4

možnost dodeljevanja novih vlog posameznikov 3 5

možnost izbire tipa projekta (SCRUM, KANBAN,

Busness, …) 1 5

možnost spremljanja več vzporednih projektov 5 5

Razvrščanje v širše tematske zgodbe od Story 0 5

možnost uporabe orodja za spremljanje hroščev 3 4

možnost označevanja oseb in nalog z različnimi

prepoznavnimi simboli in barvami 0 5

možnost določitev urnika za delo za posamezno osebo 0 5

obveščanje in opomniki preko uporabnikovega email-a 0 5

možnost vrednotenja nalog v točkah in/ali v času 3 5

možnost vnosa prvotne ocene časa za nalogo 0 5

možnost vnosa dejanske porabe časa za posamezno

nalogo 5 5

ocenjevanje obsega dela po metodi Planning poker 5 0

ocenjevanje obsega dela po metodi Team estimation

game 5 0

možnost razvrščanja nalog po prioritetah 5 5

možnost oblikovanja delovne table (Dashboard) 0 5

možnost uporabe hitrih tipk 0 5

podpora standardnim SCRUM poročilom 2 5

možnost izdelave poljubnih poročil 0 4

SKUPAJ: 57 116



4.4. NAJPOMEMBNEJŠE PREDNOSTI ORODJA ATLASSIAN JIRA V aplikaciji Atlassian Jira je pomoč uporabnikom dosegljiva v obliki natančnih navodil. To orodje omogoča, da si uporabnik poleg uporabniškega imena lahko doda fotografijo ali drug prepoznavni simbol, kar omogoča hitro vizualno razločevanje nalog med posamezniki. Zelo preprosto z različnimi barvami se lahko označijo tudi naloge, kar omogoča med drugim tudi hitri pregled na tem, katera naloga ima višjo prednostno vlogo. Za posameznike v orodju Atlassian Jira se lahko že vnaprej vnese urnik prisotnosti in tako se lažje načrtuje, kdaj bo iteracijo mogoče končati. Člani razvojne skupine so pri uporabi orodja Atlassian Jira o dodeljenih nalogah in spremembah pri posameznih nalogah samodejno obveščeni na svojem e-naslovu. Orodje ACScrum tega ne omogoča, zato se mora uporabnik vsakič znova prijaviti v aplikacijo in sam spremljati, ali je vodja projekta vnesel morebitne spremembe, ki bi vplivale na njegove naloge. Velika prednost tega orodja so tudi različne možnosti priprave poročil. Orodje vsebuje 22 standardnih poročil, pri vseh pa lahko uporabniki sami nastavijo merila, ki bodo zajeta v poročilo. V orodju Atlassian Jira je v meniju na levi strani polje Active Sprints, tu je nazoren pregled statusa posamezne naloge, ločene na To do, In Progress in Done. Poročilo je izdelano v obliki oglasne table, tako je z enim samim klikom na tej strani razviden napredek celotne iteracije.

4.5. NAJPOMEMBNEJŠE PREDNOSTI ORODJA ACSCRUM Metoda SCRUM za vrednotenje obsega dela posamezne naloge uporablja dve metodi. Prva metoda je Planning Poker in poteka tako, da vsi razvijalci vrednotijo vse naloge z vnaprej določenimi ocenami: ½, 1, 2, 3, 5, 8, 13, 20, 40 in 80. Naloge vrednotijo tako, da za isto nalogo sočasno vsak razvijalec na svojo kartico zapiše oceno in jo nato pokaže. Tista dva, ki sta določila najnižjo oziroma najvišjo oceno, to obrazložita. Vrednotenje naloge poteka toliko časa, da se vsi poenotijo. Druga metoda se imenuje Time Estimation Game in poteka, tako da vsi razvijalci vrednotijo vse naloge z vnaprej določenimi ocenami: 1, 2, 3, 5, 8, 13 in 20. Na začetku so vse naloge zložene druga na drugo, razvijalci jih po vrsti jemljejo s kupa in jih postavljajo levo ali desno od prve postavljene kartice ali na prvo postavljeno kartico. Vrednotenje je končano, ko poberejo vse kartice z osnovnega kupa in ko nihče več ne želi prestaviti nobene kartice. Na koncu se vsakemu stolpcu kartic določi število točk. Ti dve metodi sta sestavni del orodja ACScrum, kar omogoča, da se vrednotenje izvede s tem orodjem. Orodje Atlassian Jira te funkcije ne podpira in je treba vrednotenje narediti ročno pred vnosom ocen v orodje.



4.6. RAZLOGI ZA IZBIRO ORODJA ATLASSIAN JIRA Po predstavitvi obeh orodij in njunih prednosti direktorju podjetja, vodji razvoja v podjetju in razvojni skupini je bil sprejet končni sklep, da funkcionalnosti orodja Atlassian Jira povsem ustrezajo zahtevam in potrebam podjetja. Glede na to, da podjetje kot edino prednost orodja ACScrum vidi v že vgrajenem modelu vrednotenja v orodje po metodi Planning Poker in Time Estiamtion Game, to ne zmanjšuje prednosti, ki jih nudi izbrano orodje.



5. UVEDBA METODE SCRUM RAZVOJA APLIKACIJ NA PODLAGI PRAKTIČNEGA PRIMERA

5.1. IZBIRA PROJEKTA ZA UVEDBO METODE SCRUM Podjetje je v preteklosti že imelo razvito programsko opremo za podporo poslovanja v podjetjih, vendar je ta programska oprema za današnji trg postala zastarela in potrebna celovite prenove. Trend razvoja programske opreme se je v zadnjih letih usmeril predvsem v razvoj aplikacij v oblaku. Zato se je podjetje že pred dvema letoma intenzivno lotilo prenove programske opreme za podporo poslovanja v podjetjih. Prenovljena oziroma nova aplikacija, ki podpira poslovanje v podjetjih, se imenuje AccountingBox in je narejena kot aplikacija v oblaku. Podjetje se zaveda, da prenova programskega orodja pomeni zelo obsežen projekt, zato so se odločili, da se bo izvajala po korakih in se bo v vmesnem obdobju ves čas lahko tudi prilagajala zakonskim spremembam na področju poslovanja pravnih oseb in s tem potrebam uporabnikov. Zaradi uvedbe Zakona o davčnem potrjevanju računov, ki je začel veljati 1. 1. 2016, je bilo treba v letu 2015 aplikacijo nadgraditi v delu, ki podpira blagajniško poslovanje. Podjetje je zato začelo izvajati projekt Davčna blagajna, ki je del programske opreme, modul v sistemu AccountingBox. Za praktični primer uvedbe metode SCRUM razvoja programske opreme smo se zaradi časovne usklajenosti uvedbe novega zakona in odločitve o uvedbi metode SCRUM v podjetju Pronet, Kranj, d. o. o., odločili, da to uvedemo na podlagi projekta Davčna blagajna.

5.2. DOLOČITEV VLOG Metoda SCRUM predpisuje točno določene vloge posameznikov v projektu. Product Owner je produktni vodja, v našem primeru bo produktni vodja kar direktor podjetja, ki je dober poznavalec celotne obravnavane problematike. Interes produktnega vodja obravnavanega projekta je pravočasna in kakovostna izdelava programske opreme za podporo davčnega potrjevanja računov. Njegova naloga je skrb za zagotavljanje potrebnih sredstev za uspešno izvedbo projekta, določitev začetnega seznama zahtev in določanje prednostnih nalog po posameznih zahtevah. V vlogi skrbnika metode SCRUM (Scrum Master) v tem primeru nastopa vodja razvoja v podjetju. Njegova naloga je učenje vseh udeležencev projekta o tej metodi in skrb za upoštevanje pravil metode. Pri projektu Davčna blagajna sta sodelovala še dva razvijalca, ki nastopata v vlogi razvojne skupine (Scrum Team).



5.3. UPORABNIŠKE ZGODBE Uporabniška zgodba omogoča, da se neka zahteva zapiše le v taki meri, kot je potrebno, da se ve, kaj je treba narediti, in da zapis omogoča določitev obsega potrebnega dela. Na začetku smo z razvojno skupino in produktnim vodjem oblikovali seznam zahtev v obliki uporabniške zgodbe. Pomagali smo si z metodo viharjenja možganov (brainstorming), pri čemer je vsak od prisotnih poskušal opredeliti čim več uporabniških zgodb. Na koncu je produktni vodja sestavil začetno uporabniško zgodbo, ki je določala osnovne zahteve za projekt Davčna blagajna. V skladu z metodo SCRUM mora biti obseg dela posamezne uporabniške zgodbe v okviru polovice dneva do največ dveh tednov. Zato smo preobsežne uporabniške zgodbe razdelili na več manjših, da smo vsako zgodbo lahko dokončali v okviru ene iteracije. Oblika zapisa uporabniške zgodbe in oblika zahtev v metodi SCRUM nista predpisani, zato smo se zaradi preglednosti in nadaljnje uporabnosti za določitev obsega potrebnega dela in prednostnih nalog odločili, da začetni seznam zahtev (Story), ki je prikazan v tabeli 3, in v nadaljevanju tudi razdelitev teh na naloge, ki so prikazane v tabeli 4, zapišemo v Excelovi preglednici.

Tabela 3: Seznam zahtev

Zgodbe z ID DPR-11, DPR-15, in DPR-16, ki so prikazane v tabeli 3, niso bile preobsežne, zato jih nismo razbili na manjše uporabniške zgodbe ali naloge in je vsaka izmed njih že samostojna naloga. Druge zgodbe smo razdelili na naloge, kot izhaja iz tabele 4.

ID STORY

DPR-10

Blagajna mora omogočati izdelavo računov: vnos, preverjanje na FURS, izpis, vnos storno

računov, posredovanje v elektronski obliki

DPR-11

Po prijavi uporabnika se mora prikazati začetna stran (tabla) na kateri je grafično prikazano

poslovanje podjetja: fakturirana realizacija po mesecih, tečajna lista, odprte obveznosti, odprte

terjatve, stanje na tekočem računu, finančni kazalniki

DPR-12

Blagajna mora imeti tri različne sezname za pregled podatkov: osnovni seznam mora prikazovati

seznam izdanih računov in storno računov, seznam dvigov in pologov, seznam blagajniških

zaključkov

DPR-13

Blagajna mora prikazati tri vrste poročil: blagajniški dnevnik za dan, seznam prodaje po artiklih,

stanje blagajne po različnih napravah/blagajnah z naslednjimi podatki: začetno stanje, prejeta

gotovina, pologi, dvigi, skupaj

DPR-14

Blagajna mora vsebovati ustrezne šifrante po skupinah: splošno, blagajna, artikli in storitve

Skupina splošno mora vsebovati: šifrant kupcev, šifrant davčnih skupin

Skupina blagajna mora vsebovati: šifrant poslovnih prostorov, šifrant elektronskih naprav,

šifrant blagajnikov, šifrant tipov plačil, šifrant načina plačila, šifrant dvigov in pologov

Skupina artikli in storitve mora vsebovati: šifrant artiklov in storitev, šifrant skupine artiklov in

šifrant maloprodajnega cenika

DPR-15Blagajna mora vsebovati meni za nastavitve, kjer se bodo lahko nastavili podatki o podjetju,

razni parametri in povezava na daljavo preko ISL

DPR-16 Blagajna mora omogočati hitro spremembo nastavitve naprave in spremembo blagajnika



Tabela 4: Seznam nalog

5.4. VREDNOTENJE UPORABNIŠKIH ZGODB Uporabniške zgodbe smo vrednotili z metodo Poker. Dogovorili smo se, da za relativno mero vrednotenja zahtevnosti upoštevamo enoto Story points, pri čemer smo se odločili, da ena točka pomeni en delovni dan (osemurni delovnik). Dogovorili smo se, da za vrednotenje uporabimo vrednosti od 1 do 20. Produktni vodja je predstavil prvo uporabniško zgodbo in odgovarjal na dodatna vprašanja razvijalcev. Vsak razvijalec je za uporabniško zgodbo podal oceno, ki jo je zapisal na svojo kartico. Ko so vsi končali vrednotenje, so sočasno pokazali svoje ocene. Tisti, ki je podal najnižjo, in tisti, ki je podal najvišjo oceno, sta to obrazložila, nato se je postopek vrednotenja ponovil. To se je ponavljalo tako dolgo, da so na koncu vsi sodelujoči za vsako uporabniško zgodbo podali enako vrednost. V tabeli 5 so v tretjem stolpcu prikazane podane ocene.

ID

STORY

ID SUB-

TASKSUB-TASK

DPR-10 DPR-17 Blagajna mora omogočati izdelavo vnosa računa

DPR-18 Blagajna mora vsebovati algoritem za preverjanje računa na FURS

DPR-19 Blagajna mora omogočati izpis računa

DPR-20 Blagajna mora omogočati vnos storno računa

DPR-21 Blagajna mora omogočati posredovanje računa v elektronski obliki

DPR-11 DPR-11




DPR-12 DPR-22 Blagajna mora vsebovati seznam izdanih računov in storno računov

DPR-23 Blagajna mora vsebovati seznam dvigov in pologov

DPR-24 Blagajna mora vsebovati seznam blagajniških zaključkov

DPR-13 DPR-25 Blagajna mora prikazati poročilo blagajniški dnevnik za dan

DPR-26 Blagajna mora prikazati poročilo seznam prodaje po artiklih

DPR-27 Blagajna mora prikazati poročilo stanje blagajne po različnih blagajnah/napravah

DPR-14 DPR-28 Blagajna mora vsebovati šifrant skupine splošno

DPR-29 Blagajna mora vsebovati šifrant skupine blagajna

DPR-30 Blagajna mora vsebovati šifrant skupine artikli in storitve

DPR-15 DPR-15Blagajna mora vsebovati meni za nastavitve, kjer se bodo lahko nastavili podatki o podjetju,

razni parametri in povezava na daljavo preko ISL

DPR-16 DPR-16 Blagajna mora omogočati hitro spremembo nastavitve naprave in spremembo blagajnika



Tabela 5: Seznam zahtev in ocene v Story points

5.5. VREDNOTENJE PREDNOSTNE VLOGE UPORABNIŠKIH ZGODB Vrednotenje prednostne vloge uporabniških zgodb je naloga produktnega vodje. Ker smo posamezne zgodbe razdelili na naloge, smo prednostne naloge določili za vsako posamezno nalogo. Prioritete v skladu z metodo SCRUM vrednotimo opisno z vrednostmi:

- MUST HAVE (mora vsebovati), pomeni prednostno vlogo 1, - SHOULD HAVE (bi moral vsebovati), pomeni prednostno vlogo 2, - COULD HAVE (lahko vsebuje), pomeni prednostno vlogo 3, - WON`T HAVE THIS TIME (tokrat ne bo vseboval), pomeni prednostno vlogo

4. Zaradi boljše preglednosti smo v Excelovi preglednici v tabeli 6 prednostne naloge označili z zaporednimi številkami od 1 do 4, pri čemer 1 pomeni najvišjo prednostno vlogo, 4 pa najnižjo. Prednostne vloge posamezne naloge so razvidne v petem stolpcu tabele 6. V projektu Davčna blagajna je bilo s prednostno vlogo 1 ovrednotenih pet nalog, s prednostno vlogo 2 šest nalog, s prednostno vlogo 3 pet nalog in s prednostno vlogo 4 ena naloga.

ID STORY Story points

DPR-10

Blagajna mora omogočati izdelavo računov: vnos, preverjanje na FURS, izpis, vnos storno

računov, posredovanje v elektronski obliki13

DPR-11




3

DPR-12

Blagajna mora imeti tri različne sezname za pregled podatkov: osnovni seznam mora prikazovati

seznam izdanih računov in storno računov, seznam dvigov in pologov, seznam blagajniških

zaključkov

6

DPR-13

Blagajna mora prikazati tri vrste poročil: blagajniški dnevnik za dan, seznam prodaje po artiklih,

stanje blagajne po različnih napravah/blagajnah z naslednjimi podatki: začetno stanje, prejeta

gotovina, pologi, dvigi, skupaj

5

DPR-14

Blagajna mora vsebovati ustrezne šifrante po skupinah: splošno, blagajna, artikli in storitve

Skupina splošno mora vsebovati: šifrant kupcev, šifrant davčnih skupin

Skupina blagajna mora vsebovati: šifrant poslovnih prostorov, šifrant elektronskih naprav,

šifrant blagajnikov, šifrant tipov plačil, šifrant načina plačila, šifrant dvigov in pologov

Skupina artikli in storitve mora vsebovati: šifrant artiklov in storitev, šifrant skupine artiklov in

šifrant maloprodajnega cenika

9

DPR-15Blagajna mora vsebovati meni za nastavitve, kjer se bodo lahko nastavili podatki o podjetju,

razni parametri in povezava na daljavo preko ISL 3

DPR-16 Blagajna mora omogočati hitro spremembo nastavitve naprave in spremembo blagajnika 1

S: 40



Tabela 6: Prednostne vloge, predvideni čas in razdelitev nalog

5.6. SESTANEK ZA NAČRTOVANJE ITERACIJE (SPRINT PLANNING MEETING)

Na podlagi začetnega seznama nalog, ki smo jih ovrednotili glede na zahtevnost in obseg dela (obseg dela posamezne naloge je razviden iz četrtega stolpca tabele 6) in za katere smo predhodno določili prednostne vloge, se je sklical prvi delovni sestanek - Sprint Planning Meeting. Na sestanku smo se dogovorili, da bo ena iteracija (Sprint) trajala 14 dni. Ugotovili smo, da je hitrost razvojne skupine 20 točk. Hitrost razvoja (Velocity) je število točk, ki jih je razvojna skupina sposobna izvesti v eni iteraciji. Glede na podane ocene uporabniških zgodb smo predvideli, da bo projekt končan v dveh iteracijah. Na sestanku smo pripravili prvi Sprint Backlog - seznam nalog, ki bodo dokončane v prvi iteraciji. Skupen obseg nalog prve iteracije je obsegal 20 Story points, kar je bila tudi predvidena hitrost razvojne skupine. Razvijalci so se sami odločili, kdo bo prevzel katero izmed nalog (razdelitev nalog med razvijalci je razvidna iz šestega stolpca tabele 6). Sprint Planning Meeting se je končal z vnosom vseh dogovorjenih podatkov v orodje Atlassian Jira in s tem je bila razvojna skupina v celoti pripravljena na začetek prve iteracije. Na sliki 37 je razviden vnos vseh zgodb (Story) v začetni seznam nalog (Product Backlog). V prvo iteracijo smo vnesli tri zgodbe:

- DPR-10 z nalogami: DPR-17, DPR-18, DPR-19, DPR-20 in DPR-21, - DPR-12 z nalogami: DPR-22, DPR-23, DPR-24, - DPR-16, ki ni bila razdeljena na naloge.

Vsota vseh Story points vnesenih zgodb prve iteracije je bila 20. V drugo iteracijo smo vnesli preostale štiri zgodbe:

- DPR-11, ni bila razdeljena na naloge,

ID

STORY

ID SUB-

TASKSUB-TASK

Začetna

ocena časa

v urah

PrioritetaOdgovorni

Razvijalec

DPR-10 DPR-17 Blagajna mora omogočati izdelavo vnosa računa 32 1 Tomaž

DPR-18 Blagajna mora vsebovati algoritem za preverjanje računa na FURS 32 1 Tomaž

DPR-19 Blagajna mora omogočati izpis računa 16 1 Aleš

DPR-20 Blagajna mora omogočati vnos storno računa 16 1 Tomaž

DPR-21 Blagajna mora omogočati posredovanje računa v elektronski obliki 8 1 Aleš

DPR-11 DPR-11




24 4 Tomaž

DPR-12 DPR-22 Blagajna mora vsebovati seznam izdanih računov in storno računov 16 2 Aleš

DPR-23 Blagajna mora vsebovati seznam dvigov in pologov 16 2 Aleš

DPR-24 Blagajna mora vsebovati seznam blagajniških zaključkov 16 3 Aleš

DPR-13 DPR-25 Blagajna mora prikazati poročilo blagajniški dnevnik za dan 16 2 Tomaž

DPR-26 Blagajna mora prikazati poročilo seznam prodaje po artiklih 16 3 Tomaž

DPR-27 Blagajna mora prikazati poročilo stanje blagajne po različnih blagajnah/napravah 8 2 Aleš

DPR-14 DPR-28 Blagajna mora vsebovati šifrant skupine splošno 16 3 Aleš

DPR-29 Blagajna mora vsebovati šifrant skupine blagajna 32 2 Aleš

DPR-30 Blagajna mora vsebovati šifrant skupine artikli in storitve 24 2 Aleš

DPR-15 DPR-15Blagajna mora vsebovati meni za nastavitve, kjer se bodo lahko nastavili podatki o podjetju,

razni parametri in povezava na daljavo preko ISL 24 3 Tomaž

DPR-16 DPR-16 Blagajna mora omogočati hitro spremembo nastavitve naprave in spremembo blagajnika 8 3 Aleš

S 320



- DPR-13 z nalogami: DPR-25, DPR-26, DPR-27, - DPR-14 z nalogami: DPR-28, DPR-29, DPR-30, - DPR-15, ni bila razdeljena na naloge.

Vsota vseh Story points vnesenih zgodb druge iteracije je bila 20.

Slika 37: Začetni seznam zahtev


5.7. DNEVNI SESTANEK (DAILY SCRUM) Metoda SCRUM predpisuje vsakodnevne kratke sestanke razvojne skupine, imenovane Daily Scrum. V skladu s tem so od začetka prve iteracije potekali vsakodnevni 30-minutni sestanki, ki so bili organizirani zjutraj, pred začetkom dela. Na teh sestankih je vsak član razvojne skupine na kratko predstavil, kaj je delal od zadnjega srečanja, kaj bo delal do naslednjega srečanja in s kakšnimi težavami se je pri delu srečal. Na prvih dveh sestankih sta razvijalca imela dodatna vprašanja le v zvezi z zahtevanim vsakodnevnim vnosom opravljenega dela v orodje Atlassian Jira, ki jima je pomenil dodatno administrativno delo. Po obrazložitvi skrbnika metode, da je to nujno potrebno za realno spremljanje napredka, smo to vprašanje razčistili. Že tretji dan pa je razvijalec, ki je prevzel nalogo DPR-19, zaostajal za prvotno predvidenim potrebnim časom za dokončanje naloge. Čas za dokončanje naloge je bil ocenjen na 16 ur, vendar v dveh delovnih dneh naloga ni bila končana. Razvijalec je ugotovil, da bo za končanje naloge potreboval še dve dodatni uri. Dogovorili smo se, da bo v naslednjem dnevu razvijalec delal dve uri dlje in tako poskusil nadoknaditi zamujeno. Tako se je na dnevni ravni spremljal napredek razvojne skupine.



5.8. SESTANEK PO KONCU VSAKE ITERACIJE (SPRINT REVIEW MEETING)

Na koncu vsake iteracije so potekali sestanki, imenovani Sprint Review Meeting; na tem sestanku je bil obvezno prisoten tudi produktni vodja in drugi zainteresirani za projekt. Razvojna skupina je na tem sestanku predstavila rezultate opravljenega dela v pretekli iteraciji. V prvo iteracijo je bilo vključenih devet nalog in skupni predvideni potrebni čas za dokončanje nalog je bil 160 ur. Kljub vsakodnevnim sestankom razvojni skupini v okviru prve iteracije ni uspelo dokončati vseh nalog. Naloga DPR-16 se je zato prestavila v drugo iteracijo. Predvideni potrebni čas za dokončanje naloge DPR-16 je bil 8 ur, v prvi iteraciji se je razvijalec z nalogo ukvarjal že 5 ur in 20 minut, vendar do konca iteracije te ni mogel končati. Glede na to, da je razvijalec predvideval, da bo to nalogo lahko končal v prvotno načrtovanem času, je produktni vodja zahteval, da se v drugi iteraciji končajo vse še nedokončane naloge projekta. V drugi iteraciji je bilo zato treba opraviti delo v obsegu zahtevnosti 21 Story points. Tudi v drugi iteraciji sta razvijalca naletela na podobne težave kot v prvi. Vsi so se strinjali, da je bil potrebni čas za dokončanje posameznih nalog v začetku predviden dokaj optimistično. Vendar za zdaj zaostanek ni ogrožal končnega roka za dokončanje projekta, saj je razvojna skupina zaostajala za približno 12 ur.

5.9. SESTANEK ZA REVIZIJO ITERACIJE (SPRINT RETROSPECTIVE MEETING)

Sestanki Sprint Retrospective Meeting so potekali v sklopu Sprint Review Meetinga, saj so bile pri projektu na obeh sestankih prisotne iste osebe. Na tem sestanku se je analiziralo opravljeno delo, predvsem smo se pogovorili o tem, kaj smo naredili dobro in kaj bi še lahko izboljšali. Strinjali smo se, da smo metodo usvojili, nismo pa spoznali še vseh funkcionalnosti, ki jih omogoča orodje. Strinjali smo se še, da so bili predvideni časi za dokončanje nalog dokaj dobro določeni, enako velja za zahtevnosti posameznih zgodb. Manjša odstopanja od načrtovanega se bodo vedno pojavljala, namen metode ni, da bi morali načrtovati do ene ure natančno. Pri ponavljanju vrednotenj pri novih projektih pa bodo tudi predvidevanja razvojne skupine vedno bolj natančna.

5.10. MERJENJE IN NADZOR NAPREDKA Merjenje napredka je potekalo dnevno in na ravni posamezne iteracije. Pregleden vpogled napredka je omogočalo uporabljeno orodje Atlassian Jira, ki ima že vgrajena sistemska poročila. Na dnevni ravni se je napredek spremljal s poročilom Burndown Chart (slika 32), ki je grafično sproti prikazovalo, koliko ur preostalega dela je še potrebnega za dokončanje nalog pred koncem iteracije.



S table Active Sprint (slika 31) smo na dnevni ravni videli, katere naloge v trenutni iteraciji še čakajo za obdelavo, katere so že v obdelavi, kdo je za njih odgovoren in katere naloge so že končane. Na ravni posamezne iteracije smo napredek spremljali z grafičnim poročilom Sprint Report (slika 33). Iz poročila je bilo razvidno, koliko dela smo opravili v okviru ene iteracije in ali smo katero izmed nalog, za katero smo načrtovali, da jo bomo opravili v okviru iteracije, pustili nedokončano in smo jo zato prestavili nazaj v seznam nalog, ki jih bomo vključili v naslednjo iteracijo. Za pravilen prikaz poročil je zelo pomembno, da se v orodje Atlassian Jira sproti vpisuje, koliko ur dela je bilo že opravljenega pri posamezni nalogi. Predvidenim časom in dejanski porabi časa za posamezne naloge in za celoten projekt smo lahko preprosto sledili s poročilom Time Tracking Report (slika 36).

5.11. PREDNOSTI IN SLABOSTI IZBRANEGA ORODJA Med uvedbo so na dnevnih sestankih udeleženci v projektu prispevali tudi podatke o prednostih in slabostih uporabljenega orodja. Prednosti:

- orodje omogoča vnos vseh opredeljenih nalog, ki jih je treba izvesti pri projektu, tudi če se ne bodo izvajale v prvi oziroma tekoči iteraciji,

- orodje omogoča vnos vnaprej določenih ocen zahtevnosti posameznih nalog,

- orodje omogoča vnos vnaprej določenega predvidenega potrebnega časa za dokončanje posameznih nalog,

- zelo jasno razvidne naloge vseh udeleženih pri projektu, - v celotnem poteku projekta je mogoče spremljati doseganje zastavljenih

ciljev, - med trajanjem projekta je mogoče prilagajati prednostne vloge

posameznih nalog, - med trajanjem projekta je mogoče kadar koli dodati ali odvzeti

nepotrebne naloge, - orodje omogoča natančno načrtovanje časa izdaje nove programske

opreme, - orodje podaja informacije o odstopanjih od zastavljenega cilja in s tem

omogoča hitro ukrepanje, - orodje omogoča izboljšano komunikacijo med člani razvojne skupine, - zaradi uporabe orodja Atlassian Jira je vse vidno vsem v vsakem trenutku, - vsi člani skupine se počutijo soodgovorni za uspeh oziroma neuspeh

projekta, - naročnik je ves čas seznanjen z napredkom pri projektu in z načinom

delovanja programske kode (poglobljeno zaupanje med naročnikom in izvajalcem).

Slabosti:

- zahteva po doslednem vpisovanju o začetku dela pri posamezni nalogi in prekinitvi dela pri posamezni nalogi v orodje je pomenila dodatno administrativno obremenitev.



6. SKLEP

6.1. PRESOJA UČINKOV Ugotovljena zahtevnost vseh zahtev projekta je bila 40 Story points, v prvi iteraciji so bile uspešno končane vse naloge, razen ene, tako da smo nalogo z ID DPR-16 prestavili v naslednjo iteracijo. V drugi iteraciji so bile uspešno končane vse naloge, razen naloge z ID DPR-11, ki je bila končana pozneje. Po končanem projektu smo z uporabljenim orodjem lahko ovrednotili hitrost razvoja razvojne skupine (Velocity, slika 38). Pri tem je treba upoštevati, da pri različnih projektih sodeluje različno število razvijalcev, odvisno od zahtevnosti projekta. Zato na enem praktičnem primeru ni mogoče podati splošnega mnenja o hitrosti razvoja v podjetju, ampak bo to podjetje lahko spremljalo ob več izvedenih projektih. Za projekt Davčna blagajna je bila izmerjena povprečna hitrost razvoja 18 točk, načrtovana hitrost razvoja pa 20 točk. Pri tem je treba upoštevati, da je bil projekt dokaj preprost in je imel malo nalog, ki jih je produktni vodja že na začetku na podlagi celostnega poznavanja problematike zelo dobro določil in zelo natančno ovrednotil. Predvideni potrebni čas za končanje vseh nalog je bil 320 ur. Naloge so bile končane z manjšim odstopanjem, in sicer v 332 urah. Končno merilo napredka je delujoča programska koda.



Slika 38: Vrednotenje hitrosti razvojne skupine (Velocity)




6.2. POGOJI ZA UVEDBO Za uvedbo metode SCRUM v podjetje Pronet, Kranj, d. o. o., je bilo treba zagotoviti tudi vse ustrezne vire. »Vir je vse, kar je potrebno za izvajanje dejavnosti: živo delo (delavci, izvajalci) - žive kapacitete, sredstva dela (stroji, orodja) – mrtve kapacitete, predmeti dela in finančna sredstva.« (Rant, Jeraj in Ljubič, 1995: 16). Ker podjetje oziroma lastniki podjetja želijo slediti napredku na področju IT-tehnologije in dosegati vrhunske rezultate ter se zavedajo, kako zelo pomembna je stalna optimizacija delovnih procesov, so bili pripravljeni vlagati tudi potrebni čas za uvedbo nove metode. Uvedba jim je pomenila dodatno delo, predvsem zaradi pomanjkanja časa zaposlenih, ki so zaradi svojega rednega dela preobremenjeni, da bi si vzeli čas za samoiniciativno učenje o novi metodi. Podjetje se je zato odločilo, da bodo zaposleni sodelovali pri uvedbi nove metode ob pomoči zunanjih izvajalcev. Tehnična in finančna sredstva, ki so potrebna za nakup orodja, plačilo zunanjih izvajalcev in uvedbo nove metode, za podjetje niso bila ovira.

6.3. MOŽNOSTI NADALJNJEGA RAZVOJA V poglavju 3.4. smo opisali stanje v podjetju pred uvedbo metode SCRUM. Podjetje je za načrtovanje, vrednotenje potrebnega časa in prednostnih vlog za dodeljevanje nalog uporabljalo orodje Bugzilla. Glede na merila funkcionalnosti, ki jih podjetje pričakuje od orodja za podporo dela, se je pokazalo, da je orodje Bugzilla za podjetje manj uporabno kot novo izbrano orodje Atlassian Jira. To orodje tudi ni omogočalo sledenja metodi SCRUM. Ob tem jim je delo z obstoječim orodjem zaradi potrebnega predhodnega vnašanja nalog v Excelove preglednice pomenilo podvojeno delo. Podjetje se je zato odločilo, da bo uporabo Excelovih preglednic in orodja Bugzilla v celoti opustilo in v ta namen začelo uporabljati le orodje Atlassian Jira. Opustili bodo tudi orodje MS Project, saj jim novo orodje omogoča tudi vodenje drugih projektov.

6.4. MNENJE UDELEŽENCEV V PROJEKTU

Po končani izvedbi projekta Davčna blagajna z orodjem Atlassian Jira smo za kratko mnenje o poteku uvedbe metode SCRUM, delu z izbranim orodjem in našem sodelovanju zaprosili direktorja in vodjo razvoja v podjetju. Njuni mnenji sta podani v nadaljevanju. Direktor, odgovoren za razvoj tehnologije, Aleš Gašperšič: »V podjetju sem kot produktni vodja odgovoren tudi za sledenje novostim na področju informacijske tehnologije. Zavedam se, da je na trgu veliko konkurence, pred katero moramo biti vedno korak naprej, če želimo, da bo podjetje lahko uspešno poslovalo tudi v bodoče. Tudi v prihodnje si želimo na področju razvoja programske opreme dosegati izjemne rezultate.



Kot večina samostojnih podjetij se dnevno srečujemo s pomanjkanjem časa, žal, največkrat ravno na račun samoizobraževanja. Že kar nekaj časa smo se spogledovali z idejo uvedbe SCRUM metodologije razvoja programskih aplikacij, v prepričanju, da bi na ta način lahko s še bolj natančnim načrtovanjem in spremljanjem našega dela, dodatno izboljšali našo produktivnost in kakovost storitev. Rad bi se vam zahvalil, saj vem, da brez vašega vloženega dela in truda še do danes verjetno ne bi začeli z uvedbo SCRUM metodologije. Danes vsi razvijalci v podjetju in vodstveni delavci metodologijo poznamo, prav tako pa smo z vašo pomočjo osvojili izbrano orodje za podporo dela po SCRUM metodologiji Atlassian Jira. Po izvedbi projekta 'Davčna blagajna' smo se zavezali, da bomo v podjetju novo metodologijo uporabljali, tekom novih projektov pa bomo le to lahko prilagajali našim potrebam.« Generalni direktor Boštjan Berčič: »Najprej bi se vam rad najiskreneje zahvalil za ves vaš trud in podporo pri uvedbi SCRUM metodologije v našem podjetju. Uvedba novih metodologij in novih orodij v (ustaljena) dela in procese podjetje ni majhen zalogaj. Ne samo, da zahteva aktivno udeležbo, angažiranje in spremenjen pogled pri vseh članih razvojne ekipe, zahteva tudi pripravljenost in ogromen vložek časa s strani celotnega podjetja. Na primeru projekta 'Davčna blagajna' smo si nabrali precej novih izkušenj in končno zares spravili moderne metodologije organizacije dela ter 'proizvodnje' softwara tudi v prakso. Kljub temu, da je celotna uvedba trajala precej dlje časa, kot je bilo v začetku pričakovano, sem izredno zadovoljen. Prednosti vidim predvsem v:

- možnosti hitrejšega razvoja programske kode za projekte pri katerih ni časa za obsežno pripravo dokumentacije in podrobne pisane specifikacije zahtev (kar je danes že stalnica),

- poenostavitvi sodelovanja razvojne skupine in istočasno večji zavzetosti članov ekipe za dosego rezultatov,

- enostavnem sledenju napredovanju projekta, - možnosti enostavnega merjenja produktivnosti posameznika, kar se odrazi

v izboljšanju posameznikove kvalitete dela, - z eno besedo, v prihranku časa in denarja za razvoj produktov in na drugi

strani večjemu zadovoljstvu zaposlenih.«

6.5. SKLEP Uvedba metode SCRUM razvoja aplikacij se je izkazala za bolj učinkovito celovito rešitev za načrtovanje, spremljanje, vrednotenje in vodenje celotnega razvoja programske opreme v opazovanem podjetju. V kombinaciji s spletnim orodjem Atlassian Jira se je skupina v podjetju zaradi izboljšane komunikacije še bolj medsebojno povezala in pridobila večjo odgovornost za izvedbo projekta. Z uvedbo nove metode je podjetje doseglo zastavljeni cilj – usvojiti metodo SCRUM. Z uspešno izvedbo projekta Davčna blagajna pa je bil dosežen cilj razvitja nove delujoče programske opreme v zastavljenem roku v skladu z uvedeno metodo.



LITERATURA IN VIRI ACScrum, vstopna stran. (2015). Pridobljeno 22. 12. 2015 na http://ltpo2.fri1.uni-

lj.si/pronet/. Agilne metode razvoja programske opreme (2015). Pridobljeno 23. 6. 2015 na

https://sl.wikipedia.org/wiki/Agilne_metode_razvoja_programske_opreme. Agilne metode razvoja programe opreme, Najbolj poznane metode. (2015).

Pridobljeno 23. 6. 2015 na https://sl.wikipedia.org/wiki/Agilne_ metode_razvoja_programske_opreme.

Atlassian, About. (2015). Pridobljeno 21. 11. 2015 na https://www.atlassian.com/company.

Atlassian, Jira Software. (2015). Pridobljeno 23. 12. 2015 na https://www.atlassian.com.

Cej, A. (2010). Agilni razvoj programske opreme po metodologiji Scrum (Diplomsko delo). Ljubljana: Fakulteta za računalništvo in informatiko.

Kanban. (2016). Pridobljeno 28. 3. 2016 na https://en.wikipedia.org/wiki/Kanban.

Mahnič, V. (2014a). Agilni razvoj programske opreme in metode Scrum (gradivo za interno uporabo v podjetju Pronet, Kranj, d. o. o.). Kranj: Pronet, Kranj, d. o. o.

Mahnič, V. (2014b). Kanban (gradivo za interno uporabo v podjetju Pronet, Kranj, d. o. o.). Kranj: Pronet, Kranj, d. o. o.

Mahnič, V., Georgiev, S. in Jarc, T. (2009). Poučevanje metode Scrum v sodelovanju s podjetjem za razvoj programske opreme. Ljubljana: Univerza v Ljubljani, Fakulteta za računalništvo in informatiko.

Primerjava Kanbana in Scruma. (2016) Pridobljeno 28. 3. 2016 na https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf.

Pronet, O podjetju. (2015). Pridobljeno 21. 6. 2015 na http://www.pronet-kr.si. Rant, M., Jeraj, M. in Ljubič, T. (1995). Vodenje projektov. Radovljica: POIS

Radovljica. Schwaber, K.(2004). Agile Projekt Management with Scrum. Redmond: Microsoft

Press. Shore, J. in Warden, S. (2007). The Art of Agile Development. Sebastopol: O'Reilly

Media. Smith, S. I. (2003). Business Information Systems in Organization. New York: Book

Publishing. Waterfall model, Supporting arguments. (2015). Pridobljeno 29. 12. 2015 na

https://en.wikipedia.org/wiki/Waterfall_model.



KAZALO SLIK Slika 1: Organizacijska struktura podjetja ................................................ 2 Slika 2: Potek procesa Scrum ............................................................... 9 Slika 3: Vstopna stran ....................................................................... 13 Slika 4: Začetno okno z menijem .......................................................... 14 Slika 5: Vnos podatkov o novem uporabniku ............................................. 14 Slika 6: Urejanje podatkov ................................................................. 15 Slika 7: Izdelava poročil .................................................................... 15 Slika 8: Oglasna tabla (Project Wall) in dnevni sestanek (Daily Scrum) ............. 16 Slika 9: Razprava ............................................................................. 16 Slika 10: Dokumentacija .................................................................... 17 Slika 11: Seznam zahtev (Product Backlog) .............................................. 17 Slika 12: Nedokončane uporabniške zgodbe ............................................. 18 Slika 13: Ustvarjanje iteracije ............................................................. 19 Slika 14: Dodajanje nalog .................................................................. 19 Slika 15: Uporabnikovo sprejetje nalog .................................................. 20 Slika 16: Pregled trenutnih nalog .......................................................... 20 Slika 17: Poročilo Team Involvement Report ............................................ 21 Slika 18: Poročilo Burndown Report ....................................................... 22 Slika 19: Poročilo Realisation Report ..................................................... 22 Slika 20: Poročilo Decomposition Report ................................................. 23 Slika 21: Ustvarjanje novega projekta .................................................... 23 Slika 22: Izbira vrste projekta ............................................................. 24 Slika 23: Vnos imena projekta ............................................................. 24 Slika 24: Seznam zahtev (Backlog) ........................................................ 25 Slika 25: Ustvarjanje obsežnih uporabniških zgodb (Epic) in uporabniških zgodb (Story) ......................................................................................... 25 Slika 26: Urejanje seznama zahtev ....................................................... 26 Slika 27: Ustvarjanje podnalog (Subtask) ................................................ 27 Slika 28: Ustvarjanje iteracije ............................................................. 27 Slika 29: Dodajanje zgodb v iteracijo ..................................................... 28 Slika 30: Nadaljnje ustvarjanje iteracij in dodeljevanje zgodb v posamezno iteracijo ....................................................................................... 28 Slika 31: Aktivne iteracije .................................................................. 29 Slika 32: Poročilo Burndown Chart ........................................................ 30 Slika 33: Poročilo Sprint Report ........................................................... 30 Slika 34: Poročilo Epic Burndown .......................................................... 31 Slika 35: Poročilo Cumulative Flow Diagram ............................................. 32 Slika 36: Poročilo Time Tracking Report ................................................. 32 Slika 37: Začetni seznam zahtev .......................................................... 42 Slika 38: Vrednotenje hitrosti razvojne skupine (Velocity) ............................ 46



KAZALO TABEL Tabela 1: Primerjava metod Scrum in Kanban .......................................... 11 Tabela 2: Primerjava orodij ACScrum in Atlassian Jira ................................ 34 Tabela 3: Seznam zahtev ................................................................... 38 Tabela 4: Seznam nalog..................................................................... 39 Tabela 5: Seznam zahtev in ocene v Story points ....................................... 40 Tabela 6: Prednostne vloge, predvideni čas in razdelitev nalog ...................... 41



POJMOVNIK Accept task sprejeti nalogo Accounting box ime aplikacije ACScrum ime aplikacije Active Sprints tabla aktivne iteracije All stories vse zgodbe Assignee pooblaščenec Assigned dodeliti Atlassian Jira ime aplikacije Brainstorming: tehnika za skupinsko ustvarjanje veliko novih idej Bugzilla ime aplikacije Burndown Chart poročilo – prikazuje preostalo količino dela Burn Down Report poročilo – prikazuje preostalo količino dela Coaching trening (veščin) Control panel kontrolna plošča Create issue ustvari nalogo Create project ustvari projekt Create Sprint ustvari iteracijo Create Sub-task ustvari podnalogo Cumulative Flow Diagram poročilo – prikazuje status posameznih nalog skozi čas

(naredi/v izvajanju/končano) Daily Scrum dnevni kratek sestanek Daily Scrum Meeting dnevni kratek sestanek Dashboard delovna tabla Decomposition Report poročilo – pregled opravljenega dela po posameznih

iteracijah Discussion razprava Documentation dokumentacija Edit users urejanje uporabnika Edit projects urejanje projekta Edit tasks urejanje naloge Epic obsežna uporabniška zgodba, ki jo razdelimo na

posamezne uporabniške zgodbe Epic Burndown poročilo – prikazuje končane in nedokončane iteracije

v okviru širše zgodbe Estimation time časovno predvideni čas glede na količino dela (8-urni delovnik) Finished user stories končane uporabniške zgodbe Future releases izdaje v prihodnje Google Drive spletna aplikacija Issues pomembna tema, problem, težava Kanban agilna metoda razvoja programskih aplikacij Original Estimate prvotno predvideni čas, potreben za izvedbo zadeve

(zgodbe, naloge) Manage Sprints upravljanje, vodenje iteracij Microsoft Project ime aplikacije MS Team Manager ime aplikacije My stories moje zgodbe My tasks moje naloge



New user story nova uporabniška zgodba New users novi uporabniki Planning Poker metoda za predvidevanje potrebnega časa Product Backlog/Backlog seznam zahtev projekta, nalog za izvedbo Product Owner produktni vodja Progress Reports poročilo o dokončanih nalogah in končanih iteracijah Project wall oglasna tabla, namenjena sporočilom Project projekt Realisation Report poročilo – prikazuje dokončane zgodbe glede na

posamezne razvijalce Remaining Estimate predvideni preostali čas–, potreben za izvedbo naloge Report poročilo RUP (Rational Unified Process) klasična metoda razvoja programskih aplikacij SCRUM agilna metoda razvoja programskih aplikacij Scrum Master skrbnik metode Scrum Team razvojna skupina Sprint iteracija/ponovitev Sprint Backlog seznam nalog v iteraciji Sprint Planning Meeting sestanek za načrtovanje iteracije Sprint Report poročilo – prikazuje dokončane naloge in naloge,

vrnjene v seznam zahtev za naslednje iteracije Sprint Retrospective meeting sestanek za revizijo iteracije Sprint Review Meeting sestanek po koncu vsake iteracije Story uporabniška zgodba Story points relativna mera za presojo zahtevnosti (1 točka je

običajno 1 delovni dan) Sturt up podjetje: mlado podjetje z inovativnimi podjetniškimi idejami Sub-task podnaloga Submit oddati Team Estimation Game metoda za določitev predvidenega časa Team Involvement Report poročilo – prikazuje vloženo delo posameznega člana

v posamezni iteraciji Time Spent porabljen čas – količina porabljenega in

evidentiranega časa za neko nalogo Time Tracking Report poročilo - prikazuje prvotno predvideni čas in že

porabljeni čas za posamezno nalogo To-Do/In Progress/Done tabla s stolpci – naredi/v izvajanju/končano Unfinished stories nedokončane zgodbe Use case praktični primer User management upravljanje uporabnikov User stories uporabniške zgodbe Waterfall metoda klasična metoda razvoja programskih aplikacij



KRATICE IN AKRONIMI IS: informacijski sistem IT: informacijska tehnologija RK IKT: Razvojni center za informacijske in komunikacijske tehnologije JIT: Just in time, ravno v pravem času

Date post:	16-Aug-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

UVEDBA »SCRUM« METODOLOGIJE RAZVOJA APLIKACIJ V … · SCRUM: ACScrum in Atlassian Jira. V drugem...

Documents