UNIVERZA V LJUBLJANI FAKULTETA ZA RAČUNALNIŠTVO IN INFORMATIKO Uroš Smolnik ORODJE ZA VODENJE PROJEKTOV PO METODI SCRUM DIPLOMSKO DELO NA UNIVERZITETN

Velikost: px
Začni prikazovanje s strani:

Download "UNIVERZA V LJUBLJANI FAKULTETA ZA RAČUNALNIŠTVO IN INFORMATIKO Uroš Smolnik ORODJE ZA VODENJE PROJEKTOV PO METODI SCRUM DIPLOMSKO DELO NA UNIVERZITETN"

Transkripcija

1 UNIVERZA V LJUBLJANI FAKULTETA ZA RAČUNALNIŠTVO IN INFORMATIKO Uroš Smolnik ORODJE ZA VODENJE PROJEKTOV PO METODI SCRUM DIPLOMSKO DELO NA UNIVERZITETNEM ŠTUDIJU Ljubljana, 2011

2

3

4 UNIVERZA V LJUBLJANI FAKULTETA ZA RAČUNALNIŠTVO IN INFORMATIKO Uroš Smolnik ORODJE ZA VODENJE PROJEKTOV PO METODI SCRUM DIPLOMSKO DELO NA UNIVERZITETNEM ŠTUDIJU Mentor: izr. prof. dr. Viljan Mahnič Ljubljana, 2011

5

6 Rezultati diplomskega dela so intelektualna lastnina Fakultete za računalništvo in informatiko Univerze v Ljubljani. Za objavljanje ali izkoriščanje rezultatov diplomskega dela je potrebno pisno soglasje Fakultete za računalništvo in informatiko ter mentorja. Besedilo je oblikovano z urejevalnikom besedil L A TEX.

7

8

9

10 IZJAVA O AVTORSTVU diplomskega dela Spodaj podpisani Uroš Smolnik, z vpisno številko , sem avtor diplomskega dela z naslovom: ORODJE ZA VODENJE PROJEKTOV PO METODI SCRUM S svojim podpisom zagotavljam, da: sem diplomsko delo izdelal samostojno pod mentorstvom izr. prof. dr. Viljana Mahniča so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek (slov., angl.) ter ključne besede (slov., angl.) identični s tiskano obliko diplomskega dela soglašam z javno objavo elektronske oblike diplomskega dela v zbirki Dela FRI. V Ljubljani, dne Podpis avtorja:

11

12 Zahvala Zahvalil bi se svojemu mentorju, izr. prof. dr. Viljanu Mahniču, ki mi je bil s svojo potrpežljivostjo in odzivnostjo na moja vprašanja v neizmerno pomoč pri dokončanju diplomskega dela.

13

14 Kazalo Povzetek 1 Abstract 3 1 Uvod 5 2 Metoda Scrum Pregled Razvoj kompleksne programske opreme Ogrodje procesa Scrum Vloge pri procesu Scrum Tok pri procesu Scrum Struktura procesa Scrum Seznam zahtev (angl. Product Backlog) Seznam zahtev iteracije (angl. Sprint Backlog) Izdaja (angl. Release) Vpeljava meritev v metodo Scrum Vzpostavitev merskih ciljev Določitev meritev Zbiranje podatkov Izpeljane meritve Izračuni Uporabniške zgodbe Pregled Kaj je uporabniška zgodba Kje so podrobnosti Skupina stranke Kaj so sprejemni testi

15 4.2 Pisanje uporabniških zgodb Neodvisnost Možnost dogovora Koristnost za uporabnike ali stranko Ocenljivost Majhnost Primernost za testiranje Povzetek Testiranje sprejemljivosti uporabniških zgodb Pisanje testov pred začetkom kodiranja Testiranje je del procesa Vrste testiranja Povzetek Zahtevane funkcionalnosti aplikacije Vsi uporabniki Skrbnik metodologije Produktni vodja Član razvojne skupine Podatkovni model 37 6 Aplikacija Uporabniški vmesnik Kreiranje projekta Kreiranje skupin Dodeljevanje vlog na projektu Kreiranje uporabniških zgodb Kreiranje iteracije Kreiranje nalog zgodbe Vpisovanje dela na nalogi Prikaz meritev Sklepne ugotovitve 51 A Namestitev aplikacije 53 Literatura 55

16 Povzetek Za diplomsko nalogo sem naredil aplikacijo za vodenje projektov po metodologiji Scrum. Namen je bil narediti aplikacijo, ki jo bodo lahko študentje uporabljali pri delu na projektu ob uporabi metodologije Scrum. Aplikacija naj bi poleg vnosov in urejanja podatkov projekta omogočala tudi prikaz rezultatov meritev v obliki tabel, pa tudi v obliki raznih diagramov. V teoretičnem delu diplomske naloge sem se usmeril v predstavitev metodologije Scrum, opis vpeljave meritev v to metodologijo in nato bolj detajlno predstavitev uporabniških zgodb, ki so ena od osnovnih struktur metodologije. V zadnjem delu sem predstavil še funkcionalnosti implementirane aplikacije in nekaj primerov njene uporabe. Ključne besede: Scrum, uporabniške zgodbe, meritve v programski opremi, agilne metodologije, razvoj aplikacij 1

17

18 Abstract For this thesis I made an application that will help manage projects using Scrum methodology. The objective was to make an application that students will use to work on their projects when using Scrum methodology. The application should enable managing project data by displaying measurement results in tabular form and also in the form of various diagrams. The theoretical part of the thesis is focused on presenting Scrum methodology by describing the introduction of measurements in methodology, and then giving a more detailed presentation of user stories that are one of the basic structures of the methodology. In the last part I have introduced the functionality of the implemented application and some examples of its use. Key words: Scrum, user stories, software metrics, agile methodologies, application development 3

19

20 Poglavje 1 Uvod Agilne metodologije se vse bolj uporabljajo pri razvoju programske opreme. Ena izmed tistih, ki se je v zadnjih letih najbolj razširila, je metoda Scrum [1]. V raziskavi, ki jo je naredilo podjetje VersionOne leta 2010 [6], vidimo, da že več kot 58 odstotkov uporabnikov agilnih metodologij razvoja uporablja ravno metodo Scrum. Ker v času pisanja diplome ni obstajala nobena prosto dostopna programska oprema za vodenje projekta po metodi Scrum, ki bi omogočala prikaz indikatorjev, opisanih v nadaljevanju, smo se odločili, da bomo to naredili mi. Poleg vstavljanja in urejanja osnovnih podatkov, ki so definirani po metodi Scrum, naj bi aplikacija omogočala tudi prikaz rezultatov našega dela na projektu. Odločili smo se prikazati nekaj rezultatov meritev, ki temeljijo na praksah modela CMMI (Capability Maturity Model Integration) [4]. V obliki diagramov bomo tako prikazali terminski indeks (angl. Schedule performance index - SPI ), stroškovni indeks (angl. Cost performance index - CPI ), indeks učinkovitosti (angl. Work effectiveness - WE), diagram za analizo trenda (angl. Burndown chart) in razmerje med planiranim in dejanskim delom v obliki tortnega diagrama. Več o tem, kaj posamezna meritev je, kasneje. V drugem poglavju, ki sledi, bomo najprej opisali metodo Scrum. Ta je dokaj enostavna, tako da nima veliko pravil. Verjetno je ravno to razlog za njen uspeh, saj njeni uporabniki, razvijalci, ne porabijo veliko časa za uvajanje. Naslednje poglavje bomo začeli z opisom, kako smo se lotili vpeljave meritev v metodo Scrum, nadaljevali pa s tem, kako so meritve realizirane. V četrtem poglavju bomo napisali več o uporabniških zgodbah. Te so osrednja in najpomembnejša struktura metode Scrum. V naslednjem poglavju bomo na kratko opisali podatkovni model, v zadnjem, šestem poglavju, pa opisali funkcionalnosti implementirane aplikacije. 5

21 Poglavje 2 Metoda Scrum Zaradi poplave različnih orodij, arhitektur, komponent, podatkovnih baz ter razmaha interneta v današnji informacijski tehnologiji se kompleksnost razvoja programske opreme eksponentno veča. Posledica tega je vse večja nepredvidljivost v tem procesu. Metode, kot je Scrum, poskušajo kljub kaosu razvoj programske opreme obdržati pod kontrolo. Ravno kontrola oziroma uporaba meritev, s katerimi izvajamo kontrolo, je ključni element do uspeha. Scrum skrajša čas povratne informacije, ki jo dobimo od stranke, med seznamom želj in implementacijo ter med investicijo in donosom investicije. Če je sistem enostaven, ni težko vedeti, kaj hočemo, če pa je sistem kompleksen in se zahteve s časom spreminjajo ter tehnologija napreduje, se agilen sistem, kot je Scrum, dosti bolje obnese kot sistem z izrazitim načrtovanjem vnaprej. Scrum je sestavljen iz 30-dnevnih ciklov, na koncu katerih je produkt pripravljen za produkcijo. Če že vse vemo in nimamo več ničesar odkriti, ne rabimo uporabljati Scruma. Če pa se moramo o problemu še kaj naučiti, nas Scrum z vztrajnostjo o izdajah inkrementov produkta nauči o pravilnosti in kompletnosti opravljenega. Ob delu lahko mislimo, da naš pristop deluje, vendar se na koncu izkaže, da je bil popolnoma napačen. To izvemo šele, ko je programska oprema testirana in integrirana v produkcijo. Scrum nas sili, da to opravimo za vsak cikel, oziroma čim pogosteje. Dodaten razlog, zakaj Scrum deluje, je zato, ker skupaj deluje več ljudi in je tako večja verjetnost, da bo nekdo opazil, če gre kaj narobe. Scrum spremeni majhne skupine v kovalce svoje usode. Skupina sprejme izziv in je nato sama odgovorna ugotoviti način, kako izziv rešiti. Tako je lahko veliko bolj kreativna in načrtuje stvari, ki vnaprej ne bi mogle biti načrtovane. Majhnost skupine spodbuja člane k sodelovanju in k občutku pripadnosti 6

22 2.1 Pregled 7 ter k temu, da sami odločajo o svoji usodi. Počutijo se, kot da imajo nadzor v svojih rokah, kar je tudi res. Ko si člani delijo skupen cilj, v katerega vsak verjame, bodo tega tudi dosegli, če jim bo le na voljo dovolj virov. Prednost Scruma nasproti tradicionalnim metodam, kjer sistem najprej popolnoma analizirajo in začrtajo, lahko pokažemo tudi na naslednjem primeru. Recimo, da imamo sistem, ki bo nekemu podjetju prinesel EUR dohodka v prvih dveh letih po implementaciji. Z uporabo tradicionalnih metod bi razvoj trajal eno leto, stal pa bi EUR. Iterativni pristop pa nam omogoča selektivni in inkrementalni razvoj in implementacijo funkcionalnosti sistema. V primeru, da za upravljanje razvoja uporabljamo eno izmed agilnih metod, bi na primer proces potekal na naslednji način: Izdela se seznam vseh funkcionalnosti, ki jim priredimo neko prioriteto. Razdelimo seznam funkcionalnosti na dva dela: prvega ocenjujemo, da bo pripravljen pol leta po začetku razvoja. Z uporabo iterativnega in inkrementalnega razvoja dokončamo prvo izdajo po pol leta za EUR. Tako lahko dobiček stranke prične rasti že čez pol leta. V tem primeru vidimo, da je stranka lahko začela dvigati dobiček, ki ji bo pokril stroške investicije pol leta prej, kot bi drugače, prav tako pa ima čez pol leta možnost, da se odloči, ali je pripravljena potrošiti še EUR za ostale funkcionalnosti. 2.1 Pregled Razvoj programske opreme je zelo kompleksen proces. Scrum je oblikovan tako, da strmi h kreiranju uporabnih produktov iz kompleksnih problemov. V preteklosti, v zadnjih petnajstih letih, je bil uporabljen že na tisočih projektih. Temelji na teoriji industrijskega procesnega krmiljenja, ki temelji na mehanizmih, kot so samoorganizacija. Po eni strani je Scrum zelo enostaven. Zelo malo je namreč praks in pravil, ki so povrhu še zelo enostavna. Po drugi strani pa je lahko enostavnost Scrum procesa zavajajoča. Scrum ni natančno določen proces. Ne opiše točno, kaj početi ob vsaki okoliščini. Uporablja se pri projektih, kjer zaradi kompleksnosti ne moremo natančno napovedati njihovega poteka. Scrum ponuja samo ogrodje in prakse, ki ponujajo pregled nad projektom in strmijo k načrtovanemu cilju. Večina ljudi, odgovornih za upravljanje s projekti, je

23 8 Poglavje 2: Metoda Scrum Slika 2.1: Graf odvisnosti uspeha od kompleksnosti naučenih determinističnih pristopov vodenja projekta, ki uporabljajo podrobne načrte in urnike dela. Scrum je pravo nasprotje. Za razliko od determinističnih pristopov, ki projekt blokirajo pred začetnim zagonom, Scrum pokaže, kako optimalno voditi proces, ki se razvija s tem, ko se projekt nadaljuje. 2.2 Razvoj kompleksne programske opreme Za oceno kompleksnosti razvoja programske opreme se omejimo samo na tri dimenzije: zahteve, tehnologijo in ljudi. Skoraj nikoli se ne srečujemo z enostavnimi zahtevami. Primer enostavne zahteve je, ko imamo enega samega naročnika, ki je hkrati edini uporabnik produkta in si lahko vzame dovolj časa z razvijalcem, da točno določita, kaj razviti, ob tem pa se tudi njegove zahteve s časom ne bodo spreminjale. Pogosteje se srečujemo z zahtevami, kjer imamo veliko uporabnikov, ki nimajo dovolj časa za določitev točne specifikacije in velikokrat tudi še točno ne vedo, kaj bi radi. Njihove zahteve se tudi pogosto spreminjajo skozi čas. Tudi pojem enostavna tehnologija le redko zasledimo pri razvoju programske opreme. Pogosto gre za skupek več nezanesljivih tehnologij, ki komunici-

24 2.3 Ogrodje procesa Scrum 9 Slika 2.2: Kompleksnost razvoja rajo med seboj in tako povečujejo verjetnost napake in komplekstnost razvoja. Na sliki 2.2 je prikazano, kako kompleksnost narašča in postaja neobvladljiva z naraščanjem kompleksnosti obeh mer, ki smo jih do sedaj predstavili. Če pademo v neobvladljiv del grafa, pomeni, da je potrebno nekatere kompleksnosti rešiti, preden nadaljujemo z delom. Tretja dimenzija kompleksnosti so ljudje, ki pri razvoju sodelujejo. Vsi imajo drugačne spretnosti, izkušnje, poglede, odnose in predsodke. Poleg tega je tudi vsakodnevno razpoloženje odvisno od drugih zunanjih dejavnikov. 2.3 Ogrodje procesa Scrum Scrum je iterativni, inkrementalni proces, kot je prikazano na sliki 2.3. Spodnji krog predstavlja iteracijo razvoja, katere izhod je inkrementiran produkt. Zgornji krog pa predstavlja dnevni pregled stanja, ki se izvaja med iteracijo in kjer se člani skupine dobijo na 15-minutnem sestanku. Tu pregledajo dejavnosti med seboj in po potrebi naredijo potrebne prilagoditve. Iteracija se ponavlja, dokler je projekt financiran. Proces poteka na način: Na začetku vsake iteracija skupina pregleda, kaj mora narediti. Nato izbere zahteve, za katere verjame, da jih lahko v času iteracije naredi in

25 10 Poglavje 2: Metoda Scrum Slika 2.3: Ogrodje procesa Scrum vgradi v potencialni produkt, ki lahko gre v produkcijo. Vsaka skupina ima proste roke med samo iteracijo. Na koncu vsake iteracije vsaka skupina predstavi na novo vključene funkcionalnosti tako, da lahko nadzorniki preverijo celotno funkcionalnost in po potrebi časovno prilagodijo projekt. Skupina na začetku iteracije pregleda zahteve in razpoložljive tehnologije ter oceni svoje sposobnosti in zmogljivosti. Na podlagi tega nato določi, kako bodo dano zahtevo izvršili. Ob naletu na nove težave in kompleksnosti lahko dnevno pristop spreminjajo. Tako je skupini prepuščena izbira, kaj in kako mora biti opravljeno. Ta kreativni proces je jedro Scrum produktivnosti Vloge pri procesu Scrum Scrum implementira to iterativno, inkrementalno ogrodje skozi tri vloge: produktni vodja (angl. Product Owner), razvojna skupina (angl. Team) in skrbnik metodologije (angl. Scrum master). Produktni vodja: Odgovoren je za predstavitev interesov vseh, ki imajo delež v projektu. Produktni vodja inicializira projekt s tem, ko

26 2.3 Ogrodje procesa Scrum 11 Slika 2.4: Pigs and chickens poda splošne zahteve in načrt izdaje, odgovoren pa je tudi, da se najpomembnejše funkcionalnosti izvršijo najprej. Razvojna skupina: Odgovorna je za razvoj funkcionalnosti. Skupina ja samoupravna, samoorganizirana in navzkrižno funkcionalna. Ugotoviti mora način, kako spremeniti seznam zahtev v nove funkcionalnosti v okviru iteracije. Člani skupine so skupaj odgovorni za uspeh projekta kot celote. Skrbnik metodologije: Odgovoren je za Scrum proces, za učenje Scrum procesa vseh, ki so vključeni v projekt, za implementiranje Scrum procesa in za zagotavljanje, da vsi sledijo pravilom in praksam Scrum procesa. Scrum jasno razlikuje ljudi, ki nastopajo v eni od teh treh vlog in ostalimi ljudmi, ki so nekako povezani s projektom. Uporabljata se izraza prašiči in kokoši (angl. Pigs and chickens), slika 2.4. To razlikovanje je pomembno, saj lahko tako povečamo produktivnost. Medtem ko so eni predani projektu in za njega tudi odgovorni (prašiči), so drugi v projekt samo vključeni (kokoši) Tok pri procesu Scrum Scrum projekt se začne z vizijo sistema, ki naj bi bil razvit. Vizija je lahko na začetku nejasna in navedena z marketinškimi pogoji, ampak bo postajala bolj jasna s tem, ko se bo projekt razvijal. Produktni vodja je odgovoren za tvorbo plana, ki bo kar najbolje vrnil investicijo, in del tega plana je tudi seznam zahtev (angl. Product backlog). Seznam zahtev je seznam funkcionalnih in nefunkcionalnih zahtev, ki predstavljajo začetno vizijo projekta. Seznam zahtev je prioritiziran, tako da so funkcionalnosti, ki bodo najverjetneje prinesle

27 12 Poglavje 2: Metoda Scrum vrednost, na vrhu seznama in razdeljene v predlagane izdaje (angl. release). Prioritiziran seznam zahtev je štartna točka, njegova vsebina pa se začne spreminjati s trenutkom, ko začnemo delati na projektu (kot je bilo pričakovano). Vse delo je opravljeno v iteracijah. Vsaka iteracija traja 30 zaporednih koledarskih dni. Število dni (dolžina iteracije) je lahko tudi drugačno, tako se pogosto uporabljajo tudi krajše dolžine. Vsaka iteracija se začne s sestankom načrtovanja iteracije (angl. Sprint planning meeting), kjer produktni vodja in razvojna skupina skupaj določijo, kaj bo opravljeno v naslednji iteraciji. Produktni vodja izbere zahteve z najvišjo prioriteto in nato skupina pove, kaj je v okviru iteracije možno narediti. Sestanek načrtovanja iteracije ne sme biti daljši od osmih ur. Čas je omejen, da se izognemu predolgemu premlevanju o tem, kaj je mogoče in kaj ne. Cilj je začeti delati, ne razmišljati, kako delati. Sestanek načrtovanja iteracije je sestavljen iz dveh delov: V prvih štirih urah produktni vodja predstavi razvojni skupini zahteve z najvišjo prioriteto in od skupin sprejema vprašanja o vsebini, namenu in njihovem pomenu. Pred potekom teh štirih ur skupina določi, koliko v okviru predstavljenega lahko naredi. Druge štiri ure razvojna skupina porabi za planiranje iteracije. Zahteve, ki se izberejo v okviru tega sestanka, se zapišejo v seznam zahtev iteracije (angl. Sprint Backlog). Nove naloge v seznamu zahtev iteracije se pojavljajo s tem, ko se iteracija izvaja. Na začetku drugih štirih ur se je iteracija že začela. Vsak dan se razvojna skupina dobi na 15-minutnem dnevnem Scrum sestanku (angl. Daily Scrum meeting). Tukaj vsak član skupine odgovori na tri vprašanja [1]: Kaj si naredil na tem projektu od zadnjega dnevnega sestanka? Kaj planiraš narediti na tem projektu do naslednjega dnevnega sestanka? Kaj te ovira pri doseganju tvojih pričakovanj na tem projektu, na tej iteraciji? Namen tega sestanka je dnevno usklajevanje del vseh članov razvojne skupine. Na koncu iteracije je še sestanek pregleda iteracije (angl. Sprint review meeting). To je štiriurni, časovno omejen sestanek, kjer razvojna skupina

28 2.4 Struktura procesa Scrum 13 zainteresiranim uporabnikom predstavi, kaj je razvila med to iteracijo. Na sestanku je lahko navzoča še kakšna druga oseba, ki je kako drugače povezana s projektom. Namen sestanka je določiti, kaj naj skupina naredi v naslednji iteraciji. Za sestankom pregleda iteracije in pred sestankom načrtovanja naslednje iteracije, se odvija še Retrospektivni sestanek Sprinta (angl. Sprint retrospective meeting) s skupino. Na tem triurnem, časovno omejenem sestanku, skrbnik metodologije spodbudi razvojno skupino k izboljšavam. Tema sestanka je [1]: Kaj je bilo uspešno? Kaj ni bilo uspešno? Kaj bi lahko izboljšali v naslednji iteraciji? To je še posebej pomembna priložnost za skupino, da se osredotoči na svoje splošne učinkovitosti in opredeli strategije za izboljšanje svojih postopkov. 2.4 Struktura procesa Scrum Seznam zahtev (angl. Product Backlog) Zahteve sistema, razvrščene po prioriteti, so podane v seznamu zahtev. Za vsebino tega seznama je odgovoren produktni vodja. Seznam zahtev ni nikoli končen in je samo začetna ocena o zahtevah projekta. Razvija se s tem, ko se projekt razvija. Je dinamičen Seznam zahtev iteracije (angl. Sprint Backlog) Definira tiste zahteve iz seznama zahtev, ki jih skupina izbere v drugem delu sestanka načrtovanja iteracije za izvedbo v trenutni iteraciji. Vsak element v seznamu zahtev je razdeljen še na naloge (angl. Task). Vsaka naloga naj ne bi trajala več kot 16 ur Izdaja (angl. Release) Scrum zahteva, da je na koncu vsake iteracije pripravljena verzija produkta, ki gre lahko v produkcijo. To zahteva, da je projekt temeljito testiran, dobro

29 14 Poglavje 2: Metoda Scrum strukturiran in dobro napisan. Zahteva tudi, da je funkcionalnost dokumentirana. Ker pa se po koncu vsake iteracije ne odločimo za novo verzijo produkta, govorimo o izdajah. Tako lahko izdaja obsega več iteracij.

30 Poglavje 3 Vpeljava meritev v metodo Scrum Za boljše spremljanje poteka projekta so nam v veliko pomoč razne meritve. Tako smo se poleg osnovnih meritev, ki so definirane že s samo metodo Scrum, odločili vpeljati še nekaj izpeljanih meritev. Te bodo v večini prikazane v obliki stolpčnih in tortnih diagramov. Nekatere od teh meritev so terminski indeks, stroškovni indeks, indeks učinkovitosti itd. Več o njih kasneje. 3.1 Vzpostavitev merskih ciljev CMMI [4] predstavlja različne primere ciljev merjenja, kot so: zmanjšaje časa dostave, zmanjšanje skupnih stroškov življenjskega cikla, zagotavljanje določene funkcionalnosti v celoti itd: Vsi ti cilji so lahko merjeni skozi stalno spremljanje procesa. Tako implementacija CMMI meritev, predstavljena v nadaljevanju, predpostavlja, da je glavni cilj meritev spremljanje in izboljšanje procesa razvoja programske opreme. Uspešnost procesa razvoja programske opreme lahko enačimo z zadovoljstvom interesnih skupin. Tako moramo upoštevati vidike vseh skupin, ki so navzoče v procesu. Najbolj smo uspešni, ko so vse skupine zadovoljne. Meritve pa morajo biti tako kvantitativne kot kvalitativne. Ob zaključku smo prišli do štirih interesnih skupin [3]: Vodstvo: Zasleduje tradicionalne vidike razvoja programske opreme, kot so porabljen čas, stroški in kvaliteta. Člani razvojne skupine: Glavni cilj članov skupine je zadovoljstvo pri delu. Člani so najbolj produktivni, če imajo dobre delovne pogoje. 15

31 16 Poglavje 3: Vpeljava meritev v metodo Scrum Skrbnik metodologije: Glavni cilj skrbnika metodologije je olajšanje uporabe Scruma in kreiranje pogojev za učinkovit razvoj. Naročnik: Glavni cilj naročnika je njegovo zadovoljstvo. 3.2 Določitev meritev V skladu s CMMI obstajata dve vrsti meritev. Osnovne in izpeljane. Medtem ko dobimo podatke za osnovne meritve direktno z merjenjem, so podatki za izpeljane meritve dobljeni tipično iz več osnovnih meritev. Prvotno je imel Scrum samo eno osnovno meritev: oceno količine preostalega dela, ki ga je potrebno opraviti, da končamo z zahtevo oziroma z nalogo. Na nivoju naloge se ta meritev izvaja dnevno, medtem ko se na nivoju zahteve izvaja na začetku vsake iteracije. Na podlagi teh meritev lahko dobimo diagram za analizo trenda iteracije (angl. Burndown chart), ki prikazuje preostanek dela skozi čas. Da bi lahko merili zadovoljitev vseh interesnih skupin, ki smo jih uvedli v prejšnjem poglavju, smo uvedli nekatere dodatne meritve [3]: Cilj: Pravočasne informacije o uspešnosti projekta. Preostalo delo na dan d za vsako nalogo v seznamu zahtev iteracije. Opravljeno delo na dan d za vsako nalogo v seznamu zahtev iteracije. Cilj: Izboljšanje kakovosti Število odkritih napak na sestanku pregleda iteracije. Za vsako zahtevo posebej. Število napak, ki nam jih sporoči uporabnik v določenem času po oddaji kode v produkcijo. Za vsako zahtevo posebej. Velikost kode. Za vsako zahtevo posebej. Število vseh zahtev, na katerih smo delali med iteracijo. Število vseh zahtev, ki smo jih dokončali med iteracijo. Število vseh nalog v iteraciji. Število vseh nalog, ki smo jih dokončali v iteraciji. Cilj: Zadovoljstvo pri delu

32 3.2 Določitev meritev 17 Rezultati raziskave zadovoljstva članov skupine. Cilj: Učinkovito odpravljanje ovir Število ovir, na katere smo naleteli na določeni nalogi/zahtevi/iteraciji. Datum, kdaj smo naleteli na oviro. Datum, kdaj smo oviro rešili. Cilj: Zadovoljstvo strank Rezultati raziskave zadovoljstva kupcev na koncu iteracija/izdaje Zbiranje podatkov Vse te meritve, ki smo jih pravkar določili, lahko zbiramo med predpisanimi sestanki Scruma. Edina izjema je število napak, ki nam jih sporoči uporabnik v določenem času po oddaji kode v produkcijo. Meritve po sestankih [3]: Sestanek načrtovanja iteracije. Dolžina iteracije (število delovnih dni v iteraciji). Število članov v skupini. Odstotek udeležbe vsakega člana v projektu. Cena ure dela vsakega člana. Dnevni Scrum sestanek. Preostalo delo na dan d za vsako nalogo v seznamu zahtev iteracije. Opravljeno delo na dan d za vsako nalogo v seznamu zahtev iteracije. Ovire, na katere smo naleteli. Sestanek pregleda iteracije Število odkritih napak na sestanku (za vsako zahtevo posebej). Rezultati raziskave zadovoljstva kupcev na koncu iteracije/izdaje. Retrospektivni sestanek Sprinta

33 18 Poglavje 3: Vpeljava meritev v metodo Scrum Velikost kode (za vsako zahtevo posebej). Število vseh zahtev, na katerih smo delali med iteracijo. Število vseh zahtev, ki smo jih dokončali med iteracijo. Število vseh nalog v iteraciji. Število vseh nalog, ki smo jih dokončali v iteraciji. Rezultati raziskave zadovoljstva članov skupine Izpeljane meritve Z grupiranjem več osnovnih meritev dobimo izpeljane meritve ali indikatorje, ki so nam v pomoč pri analizi procesa razvoja programske opreme. Za dosego cilja Pravočasne informacije o uspešnosti projekta uporabljamo nasledje indikatorje: Indeks učinkovitosti - se nanaša na razmerje med zmanjšanjem preostalega dela in opravljenim delom. Idealno bi bilo, da bi zmanjšanje preostalega dela med dnevi d1 in d2 bilo večje oziroma enako, kot opravljeno delo med tema dvema dnevoma. Tako je cilj obdržati to vrednost nad 1, čeprav vrednosti dosti višje kot 1 pomenijo slabo planiranje. Terminski indeks - se nanaša na razmerje med prisluženo vrednostjo (angl. Earned value - Vrednost vseh zaključenih nalog) in planirano vrednostjo (prvotna ocena vrednosti vseh nalog v določeni časovni točki). Tudi cilj tega indikatorja je vrednost nad 1. Vrednost nad 1 pomeni, da projekt prehiteva predvideni rok. Stroškovni indeks - se nanaša na razmerje med pridobljeno vrednostjo (merjeno v valuti) in dejanskimi stroški. Tudi cilj tega indikatorja je vrednost nad 1, kar pomeni, da je cena del skladna s planom oziroma nižja. Za dosego cilja Izboljšanje kakovosti uporabljamo naslednje indikatorje: Gostota napak - število napak na tisoč vrstic kode. Stroški predelave - zmnožek števila ur, porabljenih na predelavi s ceno ure dela razvijalca.

34 3.2 Določitev meritev 19 Izpolnjevanje ciljev - razmerje med številom zaključenih nalog v iteraciji in številom vseh nalog v iteraciji ali razmerje med številom zaključenih zahtev v verziji in številom vseh zahtev v verziji. Za dosego cilja Zadovoljstvo pri delu uporabljamo naslednje kvalitativne in kvantitativne indikatorje: Povprečno število projektov, na katerih razvijalci delajo vzporedno. Kakovostna ocena o delovnih pogojih (komunikacija, timsko delo, fizično neugodje, psihično dobro počutje, delovne obremenitve, nadzor, priložnosti za rast...). Za dosego cilja Učinkovito izogibanje ovir uporabljamo naslednje indikatorje: Povprečno število ovir na nalogo/zahtevo/iteracijo/skupino. Povprečni čas za rešitev ovir Izračuni V prejšnjem odseku smo podali meritve, kot so terminski indeks in stroškovni indeks. Ker Scrum ne predpostavlja nekega časovnega načrta, predpostavljamo, da je količina dela, ki mora biti opravljena do določene časovne točke, proporcionalna s časom, ki je pretekel od začetka iteracije. Meritve preostalo delo in opravljeno delo za vsak delovni dan nam omogočajo natančen izračun deleža prislužene vrednosti (angl. Earning rule), ki je definiran za vsako nalogo j, za vsak dan d iteracije. Izračunan je kot razmerje med količino že opravljenega dela na nalogi in celotno količino potrebnega dela [3]: ER d,j = d W S i,j i=1 d W S i,j + W R d,j i=1 W S i,j označuje količino že opravljenega dela (angl. Work spent) za nalogo j na dan i, medtem ko W R d,j označuje količino preostalega dela za nalogo j na dan d.

35 20 Poglavje 3: Vpeljava meritev v metodo Scrum Z uporabo deleža prislužene vrednosti izračunamo terminski indeks na dan d po naslednji formuli [3]: SP I d = n ER d,j W R init,j j=1 n W R init,j j=1 SL d kjer W R init,j označuje začetno oceno potrebnega dela na nalogi j, SL dolžino iteracije (angl. Sprint length) in d dan, za katerega računamo indikator. Medtem ko računanje terminskega indeksa dovoli, da je pridobljena vrednost izražena v poljubni enoti (mi uporabljamo prvotno oceno v urah), računanje stroškovnega indeksa zahteva, da je pridobljena vrednost izražena v valuti [3]. n ER d,j W R init,j CEH j j=1 CP I d = d n W S i,j CEH j i=1 j=1 kjer CEH j predstavlja ceno ure razvijalca, ki dela na nalogi j, d pa število preteklih dni (delovnih) od začetka iteracije (angl. Days elapsed).

36 Poglavje 4 Uporabniške zgodbe Za specifikacijo zahtev naročnika se v metodi Scrum, vedno bolj uveljavljajo uporabniške zgodbe (angl. User stories) [2]. Začeli bomo s predstavitvijo, kaj uporabniške zgodbe so ter kako so uporabljene, nadaljevali pa z več podrobnostmi, kako uporabniške zgodbe pisati in kako napisati teste, s katerimi testiramo uspešnost implementacije uporabniške zgodbe. 4.1 Pregled Kaj je uporabniška zgodba Uporabniška zgodba predstavlja funkcionalnost, ki je pomembna za končnega uporabnika oziroma kupca programske opreme. Zgodbe so sestavljene iz treh vidikov: Pisni opis zgodbe, ki se uporablja za načrtovanje in kot opomnik. Pogovor o zgodbi, ki nam služi za natančnejšo opredelitev zgodbe. Testi, ki posredujejo podatke, ki jih uporabljamo za ugotavljanje, kdaj je zgodba končana. Ker so ponavadi te zgodbe napisane na karticah, so ti trije vidiki poimenovani Kartica, Pogovor in Potrditev. Kartice so najvidnejša oblika uporabniške zgodbe, vendar niso najpomembnejše. Medtem ko kartica vsebuje besedilo zgodbe, so podrobnosti razjasnjene skozi pogovore in zabeležene v potrditvi. Primeri uporabniških zgodb, ki jih bomo podajali, se nanašajo na spletno posredovalnico dela, ki naj bi delodajalcem omogočala prikaz oglasa za delovno mesto, zainteresiranim kandidatom pa oddajo prošnje za to delovno mesto. 21

37 22 Poglavje 4: Uporabniške zgodbe Primer kartice uporabniške zgodbe je lahko: Uporabnik lahko vstavi svoj življenjepis. Ker pa uporabniške zgodbe predstavljajo funkcionalnosti, ki so vrednotene s strani končnega uporabnika, nasledji primeri zgodb niso primerni: Programska oprema bo napisana v programskem jeziku C++. Program se bo povezal z bazo podatkov preko bazena povezav. Ta dva primera ne predstavljata dobre uporabniške zgodbe, ker končnega uporabnika ne zanima, v kakšnem programskem jeziku je aplikacija napisana in ga na splošno ne zanimajo tehnične podrobnosti aplikacije. Ob branju teh zgodb nam lahko pride na misel: Počakajte, uporaba bazena povezav je zahteva v našem sistemu. Ob tem moramo pomisliti, da morajo uporabniške zgodbe biti napisane tako, da jih lahko uporabniki vrednotijo. Obstajajo načini, kako napisati zgodbe tako, da jih lahko uporabnik vrednoti. Kako, bomo videli kasneje. Zakaj uporabniške zgodbe piše stranka Stranka piše zgodbe raje kot razvijalec iz dveh glavnih razlogov. Prvi razlog je, da mora biti vsaka zgodba napisana v poslovnem jeziku, ne pa v tehničnem žargonu, tako da lahko stranka prioritizira zgodbe, kar potrebuje pri vključevanju zgodb v iteracijo. Drugi razlog pa je, da je kot glavni vizionar proizvoda v najboljšem položaju, da opiše obnašanje produkta Kje so podrobnosti Da bi lahko začeli s kodiranjem in testiranjem, potrebujemo več podrobnosti o uporabniški zgodbi. Enostavno je reči Uporabnik lahko išče prosta delovna mesta. Kje so pa odgovori na vsa neodgovorjena vprašanja, kot so: Katere atribute lahko uporabniki uporabljajo pri iskanju? Mesto? Naziv delovnega mesta? Mora biti uporabnik član spletnega mesta? Lahko iskalne parametre shranimo? Katere informacije prikažemo o najdenih delovnih mestih? Veliko podrobnosti se lahko izrazi kot dodatne zgodbe.

38 4.1 Pregled 23 Kakšne naj bodo dolžine zgodb? Dolžina zgodbe naj bi bila taka, da bi jo lahko izvedli in testirali v obdobju od polovice dneva do dveh tednov. Tukaj upoštevamo, da na zgodbi dela en oziroma največ dva razvijalca. Predolge zgodbe lahko razdelimo na več krajših zgodb. Na primer, zgodbo Uporabnik lahko išče delovna mesta lahko razdelimo na zgodbe: Uporabnik lahko išče delovna mesta po atributih, kot so: naziv delovnega mesta, ime podjetja. Uporabnik lahko vidi informacije o vsakem delovnem mestu, ki ga vrne iskanje. Uporabnik lahko vidi podrobne informacije o podjetju, za katero je razpisano delovno mesto. Z delitvijo zgodbe pa ne nadaljujemo, ko imamo zgodbo, ki pokriva vse podrobnosti. Na primer, zgodbe Uporabnik lahko vidi informacije o vsakem delovnem mestu, ki ga vrne iskanje, ni potrebno deliti na zgodbe: Uporabnik lahko vidi opis delovnega mesta. Uporabnik lahko vidi lokacijo delovnega mesta. Raje kot pisati vse te podrobnosti v uporabniške zgodbe, lahko do teh podrobnosti pridemo s pogovorom, na točki v času, ko postanejo te podrobnosti pomembne. Nič ni narobe, če na kartico uporabniške zgodbe dodamo nekaj pripomb, ki temeljijo na razpravi. Na primer, na kartico Uporabnik lahko vidi informacije o vsakem delovnem mestu, ki ga vrne iskanje, lahko dodamo pripombo, Marko pravi, da prikažemo opis, lokacijo in razpon možne plače. Vendar je ključen pogovor, ne pa pripombe na kartici uporabniške zgodbe. Niti razvijalec, niti stranka, ne smeta čez tri mesece pokazati na kartico in reči Glej, saj sem jaz tako rekel tam. Zgodbe niso pogodbene obveznosti. Kot bomo videli kasneje, so sporazumi dokumentirani kot testi, ki dokazujejo, da je bila zgodba razvita pravilno. Opisi testov naj bi bili kratki in nepopolni. Dodaja ali odstranjuje se jih lahko v vsaki časovni točki med projektom. Cilj je posredovati dodatne informacije o uporabniški zgodbi, tako da razvijalci vedo, kdaj so končali z delom na njej.

39 24 Poglavje 4: Uporabniške zgodbe Skupina stranke Na idealnem projektu bi imeli samo eno osebo, ki opredeljuje prednostne zgodbe za razvijalce, odgovarja na njihova vprašanja, uporablja programsko opremo, ko je končana in piše vse zgodbe. To je skoraj nemogoče, zato vzpostavimo skupino stranke. Ta vsebuje tiste ljudi, ki zagotavljajo, da bo programska oprema odgovarjala ciljnim uporabnikom. To pomeni, da ta skupina lahko vsebuje testerje, vodjo produkta, prave uporabnike in oblikovalce Kaj so sprejemni testi Sprejemno testiranje (angl. acceptance testing) je proces preverjanja uporabniških zgodb. Testi preverijo, če implementacija zgodb deluje na tak način, kot skupina stranke pričakuje. Ko se iteracija prične, razvijalci pričnejo s kodiranjem, skupina stranke pa začne pripravljati teste. Odvisno od tehničnega znanja skupine stranke, so lahko ti testi v pisni obliki na hrbtni strani kartice uporabniške zgodbe, oziroma avtomatski testi. Testi naj bi bili napisani karseda zgodaj v iteraciji. Lahko se jih prične pisati tudi pred začetkom iteracije, s tem da moramo v tem primeru ugibati, katere zgodbe bodo vključene v prihajajočo iteracijo. Zgodnje napisani testi so v veliko pomoč razvijalcem, saj tako pridejo do natančnih pričakovanj skupine stranke. Vzemimo za primer zgodbo Uporabnik lahko plača izdelke v svojem nakupovalnem vozičku s kreditno kartico. Za njo so kasneje napisani naslednji testi: Preveri z Visa, MasterCard in American Express. Test mora uspeti. Preveri z Diner s Club. Test mora pasti. Preveri z Visa debit card. Test mora pasti. Preveri s poteklo kartico. Test mora pasti. Test z različnimi zneski nakupa (vključno z enim čez mejo kartice). S tem, ko dobi programer te teste zgodaj, skupina stranke ne izrazi samo pričakovanja, ampak lahko programerja spomnijo na situacije, ki bi jih drugače spregledal.

40 4.2 Pisanje uporabniških zgodb Pisanje uporabniških zgodb Za kreiranje dobrih uporabniških zgodb se moramo osredotočiti na šest stvari [2]: neodvisnost možnost dogovora koristnost za uporabnike ali stranko ocenljivost majhnost primernost za testiranje Neodvisnost Kolikor je mogoče, zmanjšamo odvisnosti med zgodbami. Odvisnosti med zgodbami namreč vodijo k težavam pri planiranju in prioritiziranju. Predvidimo, da je stranka določila visoko prioriteto zgodbi, ki je odvisna od zgodbe z nizko prioriteto. Na primer zgodbe: Podjetje lahko plača za objavo oglasa za delo s kartico Visa. Podjetje lahko plača za objavo dela s kartico MasterCard. Podjetje lahko plača za objavo dela s kartico American Express. Recimo, da razvijalci ocenjujejo, da bo trajalo tri dni, da bodo podprli prvo vrsto kreditne kartice (ne glede na to, katera je), nato pa en dan za vsako od preostalih. S tako odvisnostjo zgodb, kot pri tem primeru, se ne ve, kakšno oceno dati kateri zgodbi. Katera zgodba naj dobi oceno treh dni? Ko pride do takih odvisnosti, lahko to rešimo na dva načina: Z združitvijo odvisnih zgodb v eno večjo, vendar neodvisno uporabniško zgodbo. Z drugačnim razbitjem problema na zgodbe. Združevanje zgodb se v tem primeru obnese dobro, saj je skupna zgodba dolga samo pet dni. Če pa bi bila skupna zgodba dosti daljša, je ponavadi boljši pristop ta, da najdemo drugačno razbitje problema. Na primer:

41 26 Poglavje 4: Uporabniške zgodbe Stranka lahko plača s kreditno kartico enega izdajatelja. Stranka lahko plača s kreditnimi karticami ostalih izdajateljev. Če pa zgodb ne želimo združiti in ne najdemo drugačnega primernega razbitja, lahko zgodbi priredimo dve oceni. Ena, če je zgodba izvedena pred drugo odvisno zgodbo, in ena, če je izvedena za njo Možnost dogovora Uporabniške zgodbe niso zapisane pogodbene obveznosti. So samo opisi funkcionalnosti, ki naj bi jih aplikacija podprla, katerih podrobnosti bodo določene skozi vrsto pogovorov med razvijalci in stranko. Tako zgodbe ne vsebujejo vseh podrobnosti. Vendar, če so v času pisanja zgodbe te podrobnosti že poznane, se jih lahko napiše na kartico kot opombe. Izziv predstavlja napisati zgodbe, ki vsebujejo ravno prav podrobnosti. Primer dobre zgodbe je Podjetje lahko plača za objavo oglasa za delo s kreditno kartico. Zgodbi pa je še dodana opomba Sprejmemo Viso, MasterCard in American Express. Mogoče Discover. Ko bo razvijalec bral to zgodbo, bo opomnjen, da mora podpreti tri že izbrane kreditne kartice, za četrto pa mora vprašati stranko, če je bila že sprejeta odločitev. Opombe pomagajo razvijalcu in stranki nadaljevati pogovor od tam, kjer se je prejšnjič končal. To naj bi bilo možno tudi, če na zgodbi sodeluje drug razvijalec (ali stranka) kot prej. Če bi pa bil prejšnji zgodbi, kot opomba, dodan naslednji tekst: Sprejmemo Viso, MasterCard in American Express. Mogoče Discover. Ob znesku nad 100 vprašaj za ID kartice. Sistem lahko prepozna kartico iz prvih dveh številk številke kartice. Sistem lahko shrani kartico za naslednje uporabe. Uporabnik mora vnesti tudi leto in mesec izteka kartice. Taka zgodba vsebuje preveč podrobnosti in vsebuje tudi informacije, ki bi bile lahko zapisane kot samostojna zgodba: Sistem lahko shrani kartico za naslednje uporabe. Delo na takih zgodbah je zelo težko. Bralec zgodbe lahko misli, da je zgodbi pripisanih dovolj podrobnosti, da pogovor s stranko sploh ni potreben. Tako je kot opombe zgodbi dobro napisati težave, na katere smo naleteli pri pisanju zgodbe. Te nam služijo tudi kot opozorilo, da moramo o tej zgodbi imeti še razpravo. Podrobnosti, ki so bile že določene med pisanjem zgodbe, pa napišemo kot teste uporabniške zgodbe. Te ponavadi pišemo na zadnjo stran kartice uporabniške zgodbe, če gre za tako obliko testa.

42 4.2 Pisanje uporabniških zgodb Koristnost za uporabnike ali stranko Narobe bi bilo reči, da mora biti vsaka uporabniška zgodba koristna za uporabnika. Veliko projektov vsebuje zgodbe, ki za uporabnika niso pomembne. Moramo razlikovati med uporabnikom (nekdo, ki bo aplikacijo uporabljal) in naročnikom. Vzemimo za primer aplikacijo, ki bo uporabljena v velikem podjetju. Naročnika na primer zanima, da bo aplikacija podpirala možnost centralne konfiguracije, medtem ko končnega uporabnika ta podatek ne zanima. Podobno se spodnje zgodbe vrednotijo s strani naročnika, končnega uporabnika pa ne zanimajo: Med razvojem programske opreme bodo razvijalci pripravili ustrezno dokumentacijo za ISO 9001 revizijo. Razvijalci bodo razvili aplikacijo v skladu s CMM stopnjo 3. Čemur pa se želimo izogniti, so zgodbe, ki bodo vrednotene samo s strani razvijalca: Vse povezave do podatkovnih baz uporabljajo bazen povezav. Vsa obravnavanja napak se izvajajo preko skupnih razredov. Kot že napisano, so te zgodbe usmerjene k razvijalcu. Velikokrat je možno, da ideja, ki stoji za temi zgodbami, ni slaba. Tako lahko te zgodbe napišemo na način, usmerjen naročniku. Tako dobimo naslednje variante zgornjih zgodb: Več kot petdesetim uporabnikom bi moralo biti omogočeno uporabljanje aplikacije, z licenco za pet uporabnikov za dostop do baze. Vse napake so predstavljene uporabniku in redno beležene. Najboljši način za zagotovitev, da je vsaka zgodba dragocena za uporabnika oziroma kupca je, da kupec (stranka) piše uporabniške zgodbe. Stranki je ponavadi na začetku to početje neprijetno. Večina strank pa začne s pisanjem zgodb, ko verjamejo v koncept, da so zgodbe na kartici samo opomniki za pogovor, ki bo potekal kasneje, ne pa formalne obveze Ocenljivost Za razvijalca je zelo pomembno, da je sposoben oceniti dolžino zgodbe. Torej, koliko časa bo potreboval za njeno implementacijo. Obstajajo pa trije pogosti razlogi, ko zgodba ni dobro ocenljiva:

43 28 Poglavje 4: Uporabniške zgodbe Razvijalčevo pomanjkanje znanja o domeni. Razvijalčevo pomanjkanje tehničnega znanja. Predolga uporabniška zgodba. Če razvijalec napisane zgodbe ne razume dobro, naj se o njej pomeni s stranko, ki je to zgodbo napisala. Ni potrebno razumeti vseh podrobnosti o zgodbi, vendar mora razvijalec imeti splošno razumevanje o njej. V primeru predolgih zgodb lahko zgodbo razdelimo na manjše zgodbe, ki jih nato lažje ocenimo Majhnost Zgodbe so lahko prekratke, predolge ali pa so ravno prave dolžine. Dolžina zgodbe je pomembna, saj s prekratkimi oziroma predolgimi zgodbami težko planiramo. Deljenje zgodbe Dolge zgodbe ponavadi sodijo v enega od naslednjih tipov: sestavljene zgodbe ali kompleksne zgodbe. Sestavljena zgodba je zgodba, ki je sestavljena iz več manjših zgodb. Med začetnim planiranjem je normalno, da so zgodbe dolge in sestavljene, vendar pa nato te zgodbe pred začetkom dela na njih ponavadi razdelimo na več manjših zgodb. Vendar moramo paziti, da ne gremo v drugo skrajnost in sestavljeno zgodbo razdelimo na veliko premajhnih zgodb. Za razliko od sestavljene zgodbe je kompleksna zgodba dolga zgodba, ki pa jo težje razdelimo na več manjših zgodb. Če je zgodba kompleksna zaradi negotovosti, povezane z njo, lahko tako zgodbo razdelimo na dve zgodbi: eno preiskovalno in eno razvojno. Za primer vzemimo zgodbo Podjetje lahko plača za oglas s kreditno kartico. V primeru, ko noben od razvijalcev še ni delal ničesar s kreditnimi karticami, lahko izberemo naslednje razbitje zgodbe: Raziskovanje procesiranja kreditnih kartic preko spleta. Podjetje lahko plača za oglas s kreditno kartico.

44 4.2 Pisanje uporabniških zgodb 29 V takih primerih je dobro raziskovalno zgodbo, ki nastane iz kompleksne zgodbe, uvrstiti v iteracijo pred iteracijo, v kateri so ostale zgodbe nastale iz te iste kompleksne zgodbe Primernost za testiranje Uporabniške zgodbe morajo biti napisane na takšen način, da se jih da testirati. Uspešno opravljeni testi potrjujejo uspešnost implementacije zgodbe. Zgodbe, ki jih je težko testirati, se pojavljajo pri nefunkcionalnih zahtevah, kot so: Aplikacija mora biti prijazna uporabniku. Uporabnik ne sme nikoli čakati predolgo na odzivnost aplikacije. Če je le mogoče, morajo biti testi avtomatizirani. To je predvsem pomembno pri inkrementalnem razvoju. Produkt se skozi inkremente spreminja, tako se lahko zgodi, da nekaj, kar je v preteklosti že delovalo, zdaj ne deluje več. Tako lahko z avtomatiziranimi testi hitro odkrijemo tovrstne napake. Obstaja pa podmnožica testov, ki se jih ne da avtomatizirati. Vzemimo na primer zgodbo Nov uporabnik lahko izpolni enostaven vnos brez predhodnega usposabljanja. Ta zgodba je lahko testirana, ne moremo pa za njo napisati avtomatskih testov. Testiranje take zgodbe bo najverjetneje vključevalo druge ljudi. Taki tipi testov so dragi in časovno potratni Povzetek Zgodbe naj bodo neodvisne med seboj (če je le možno). Če to ni možno, naj bodo vsaj napisane tako, da se jih lahko razvija v poljubnem vrstnem redu. Podrobnosti zgodbe so pridobljene skozi pogajanja razvijalca in stranke. Zgodbe naj bodo napisane na tak način, da so dragocene za stranko. Najboljši način za dosego tega je, da stranka piše uporabniške zgodbe. Zgodbam so lahko dodane opombe. Vendar nas lahko preveč opomb zavede, da pogovor s stranko ni potreben. Najboljši način za dodajanje podrobnosti zgodbi je pisanje testov.

45 30 Poglavje 4: Uporabniške zgodbe Sestavljene in kompleksne zgodbe lahko razdelimo na več manjših zgodb. Premajhne zgodbe lahko združimo v večje. Zgodbe morajo biti primerne za testiranje. 4.3 Testiranje sprejemljivosti uporabniških zgodb Eden glavnih razlogov za pisanje testov je način, kako zapisati vse podrobnosti ob pogovoru s stranko. Testiranje najbolje predstavimo v dveh korakih: Zapis opomb o prihodnjih testih, ki jih ponavadi dobimo med pogovorom s stranko. Ti testi so nato zapisani do podrobnosti in jih lahko uporabimo za dokaz, da je bila uporabniška zgodba uspešno realizirana. Drugi razlog za pisanje testov je, kot smo že omenili, določitev kriterija uspešnosti uporabniške zgodbe. Tako imamo nekaj, kar nam pove, kdaj smo z delom zaključili. Na ta način se najbolje izognemo primerom, ko naredimo preveč oziroma premalo Pisanje testov pred začetkom kodiranja Sprejemni testi posredujejo veliko informacij, ki jih lahko programer uporabi v svojo korist. Vzemimo na primer Test z različnimi zneski nakupa (vključno z enim čez mejo kartice). Če ima programer test na voljo, preden začne s kodiranjem, bo opomnjen obravnavati primere, ko je nakup zavrnjen zaradi nezadostnega kredita na kartici. Nekateri programerji bi lahko brez predhodnega videnja testa na to pozabili. Da lahko ti testi koristijo programerju, morajo biti napisani, preden ta začne z delom na zgodbi. Navadno so testi napisani ob enem od naslednjih dogodkov: Ko imata programer in stranka pogovor o uporabniški zgodbi in hočeta zapisati podrobnosti le tega. Kot del prizadevanj na začetku iteracije, vendar pred začetkom programiranja. Kadar so odkriti novi testi, med ali po začetku dela na zgodbi.

46 4.3 Testiranje sprejemljivosti uporabniških zgodb 31 Ko stranka in razvijalci razpravljajo o zgodbi, se pridobljene podrobnosti o zgodbi odražajo kot testi. Vendar mora stranka na začetku iteracije iti skozi zgodbe, ki so izbrane za trenutno iteracijo, in napisati morebitne dodatne teste. Pomaga si lahko z naslednjimi vprašanji: Kaj še morajo razvijalci vedeti o tej zgodbi? Kaj predpostavljam o tem, kako bo zgodba implementirana? Ali obstajajo okoliščine, ko se zgodba obnaša drugače? Kaj gre lahko narobe med razvojem zgodbe? Testiranje je del procesa Ko programer razvije novo funkcionalnost aplikacije, jo razloži testerju in ta nato pove, če aplikacija deluje po opisu. V takih primerih se velikokrat zgodi, da aplikacija prestane test, vendar se pojavijo napake, ko končni uporabnik začne z uporabo aplikacije. Težava je seveda bila v tem, da je tester testiral, če je programer naredil to, kar je rekel, da je naredil. Nihče pa ni testiral, če aplikacija naredi to, kar je stranka oziroma uporabnik pričakoval. Za uporabniške zgodbe je ključno, da je testiranje videno kot del razvojnega procesa, ne pa nekaj, kar se zgodi, ko je kodiranje zaključeno. Specifikacija testov je mnogokrat skupna zadolžitev produktnega vodje in testerja Vrste testiranja Pri večini sistemov gre večinoma za funkcionalno testiranje, ki zagotavlja, da aplikacija deluje po pričakovanjih. Seveda pa obstajajo tudi druge vrste testov: Testiranje uporabniškega vmesnika, ki zagotavlja, da se vse komponente vmesnika obnašajo po pričakovanjih. Testiranje uporabnosti, ki zagotavlja preprosto uporabo aplikacije. Performančno testiranje. S tem testiramo, kako se aplikacija odziva ob različnih obremenitvah. Testiranje izjemnih situacij.

47 32 Poglavje 4: Uporabniške zgodbe Povzetek Sprejemne teste uporabljamo za zapis podrobnosti o zgodbi, ki jih dobimo med pogovorom s stranko. Sprejemni testi predstavljajo osnovne kriterije, ki določajo, če je zgodba končana. Sprejemne teste naj napiše stranka, ne pa razvijalec. Sprejemni testi naj bodo zapisani, preden razvijalec prične s kodiranjem. Če z dodajanjem novih testov ne dosežemo dodatnega pojasnjevanja podrobnosti zgodbe, to opustimo. 4.4 Zahtevane funkcionalnosti aplikacije Kot del diplomske naloge smo morali narediti aplikacijo za pomoč pri vodenju projektov po metodi Scrum. Zahtevane funkcionalnosti te aplikacije bomo tako podali v obliki uporabniških zgodb. Uporabniške zahteve so bile podane v obliki Kot <vloga>, želim <cilj> tako da bom imel <koristi> (angl. As a <role>, I want <goal/desire> so that <benefit>). Taka oblika podajanja zahtev se je izkazala za zelo učinkovito, ne glede na obliko in velikost projekta. V podpoglavjih bomo najprej našteli funkcionalnosti, ki naj bi jih imeli: vsi uporabniki, skrbnik metodologije, produktni vodja in član razvojne skupine Vsi uporabniki Prijava v sistem Kot uporabnik se želim prijaviti v sistem z uporabniškim imenom in geslom, da bi ga lahko uporabljal pri razvoju projektov po metodi Scrum. Nato moram imeti za delo na projektu eno od vlog opisanih v naslednjih sekcijah Skrbnik metodologije Vnos novega projekta Kot skrbnik metodologije želim vnesti podatke o novem projektu, da bi lahko pričeli s spremljanjem dela na tem projektu.

48 4.4 Zahtevane funkcionalnosti aplikacije 33 Spreminjanje podatkov o projektu Kot skrbnik metodologije želim spremeniti podatke o projektu, da bi lahko vnesel morebitne spremembe, ki so nastale po začetnem vnosu. Brisanje projekta Kot skrbnik metodologije želim odstraniti projekt, ki je bil pomotoma vnesen ali se ne bo izvajal. Brisanje projekta, ki že teče (ali je končan) in zanj obstajajo podatki, ni dovoljeno. Vnos novega razvijalca Kot skrbnik metodologije želim vnesti podatke o sodelavcu, ki lahko sodeluje pri razvoju projekta, da bi jih potem uporabil pri sestavljanju razvojnih skupin za posamezne projekte. Spreminjanje podatkov o razvijalcu Kot skrbnik metodologije želim spremeniti podatke o razvijalcu, da bi lahko vzdrževal podatke o spremembah, ki se pojavijo v času, ko je sistem v uporabi. Brisanje razvijalca Kot skrbnik metodologije želim odstraniti razvijalca, ki je bil pomotoma/narobe vnesen. Brisanje podatkov o razvijalcu, ki je že delal na nekem projektu, ni dovoljeno. Vnos nove iteracije Kot skrbnik metodologije želim vnesti podatke o novi iteraciji, da bi lahko pričeli s spremljanjem podatkov, ki se nanašajo na to iteracijo. Spreminjanje podatkov o iteraciji Kot skrbnik metodologije želim spremeniti podatke o iteraciji, da bi lahko vnesel morebitne spremembe, ki so nastale po začetnem vnosu. Brisanje iteracije Kot skrbnik metodologije želim odstraniti iteracijo, ki je bila pomotoma/narobe vnešena. Brisanje iteracije, za katero že obstajajo podatki, ni dovoljeno. Dodajanje zgodbe iteraciji Kot skrbnik metodologije želim dodati zgodbo v iteracijo, da bi izdelal plan naslednje iteracije. Če zgodba v prejšnji iteraciji ni bila realizirana, se lahko uvrsti v eno izmed naslednjih iteracij z novo oceno zahtevnosti in novim statusom (nedokončana zgodba, popravki sprejete zgodbe).

49 34 Poglavje 4: Uporabniške zgodbe Odvzemanje zgodbe iz iteracije Kot skrbnik metodologije želim izločiti zgodbo iz iteracije, da bi izdelal plan naslednje iteracije. Odvzemanje zgodbe, za katero že obstajajo podatki (naloge, opravljeno delo), ni dovoljeno. Uvoz iz Agila Kot skrbnik metodologije želim uvoziti podatke iz Excelove preglednice (ki predstavlja izhod iz Agila), da bi lahko analiziral delo na študentskih projektih. Diagram za analizo trenda iteracije Kot skrbnik metodologije želim izrisati diagram za analizo trenda iteracije, da bi lahko ugotovil, ali iteracija poteka v skladu s planom. Diagram za analizo trenda produkta (izdaje) Kot skrbnik metodologije želim izrisati diagram za analizo trenda produkta (izdaje), da bi lahko ugotovil, ali projekt poteka v skladu s planom. WE, SPI in CPI diagram Kot skrbnik metodologije želim izrisati diagrame indeksa učinkovitosti, terminskega indeksa in stroškovnega indeksa, da bi lahko ugotovil, ali iteracija poteka v skladu s planom. Delež posameznih razvijalcev v izbrani iteraciji/vseh iteracijah Kot skrbnik metodologije želim izrisati diagram, ki bo prikazoval planiran in dejanski delež posameznih razvijalcev v posameznih iteracijah, da bi lahko zasledoval obremenitve in učinkovitost posameznih razvijalcev. Planirano in dejansko opravljeno delo v izbrani iteraciji/vseh iteracijah Kot skrbnik metodologije želim izpis seznama vseh zgodb skupaj z oceno zahtevnosti in dejansko vloženim delom, da bi lahko analiziral točnost ocenjevanja Produktni vodja Vnos nove uporabniške zgodbe Kot produktni vodja želim vnesti novo uporabniško zgodbo, da bi lahko sestavil seznam zahtev projekta.

50 4.4 Zahtevane funkcionalnosti aplikacije 35 Spreminjanje uporabniške zgodbe Kot produktni vodja želim spremeniti podatke o uporabniški zgodbi, da bi lahko vnesel spremembe, ki so se pojavile po začetnem vnosu. Ocene zahtevnosti in komentarje lahko vnaša samo razvijalec. Paziti je treba na vzdrževanje podatka, ali je zgodba veljavna. Brisanje uporabniške zgodbe Kot produktni vodja želim brisati uporabniško zgodbo, ki se izkaže kot nepotrebna. Brisanje zgodbe, za katero že obstajajo podatki (razporeditev v iteracijo, razbitje na naloge, opravljeno delo), ni dovoljeno. Razdelitev uporabniške zgodbe na več manjših Kot produktni vodja želim razdeliti preveč obsežno zgodbo na več manjših. Razbitje zgodbe je možno, samo preden je zgodba uvrščena v iteracijo Član razvojne skupine Vnos ocene zahtevnosti uporabniške zgodbe Kot član razvojne skupine želim vnesti oceno zahtevnosti uporabniške zgodbe, da bi lahko (upoštevajoč predvideno hitrost) izdelal plan izdaje in plan iteracije. Začetne ocene zahtevnosti ni moč spreminjati potem, ko je izdelava plana končana. Vnos komentarjev k uporabniški zgodbi Kot član razvojne skupine želim vnašati komentarje k izbrani uporabniški zgodbi, da bi tako zabeležil dodatna pojasnila in dogovore glede realizacije, do katerih sem prišel v razgovorih s produktnim vodjo. Vnos opravljenega in preostalega dela Kot član razvojne skupine želim vnesti število ur vloženega in število ur preostalega dela (za vse svoje naloge), da bi lahko izdelali diagram za analizo trenda in razne analize poteka dela na projektu. Spreminjanje vloženega in preostalega dela Kot član razvojne skupine želim spremeniti število ur vloženega in število ur preostalega dela na neki nalogi, da bi popravil podatke, ki sem jih predhodno vnesel. Spreminjanje podatkov je možno samo na dan dnevnega Scrum sestanka (za nazaj ni dovoljeno).

51 36 Poglavje 4: Uporabniške zgodbe Brisanje vloženega in preostalega dela Kot član razvojne skupine želim brisati (pomotoma narobe vnesene) podatke o številu ur vloženega in preostalega dela na neki nalogi. Vnos nove naloge Kot član razvojne skupine želim vnesti novo nalogo, ki je potrebna za realizacijo zgodbe. Spreminjanje naloge Kot član razvojne skupine želim popraviti podatke o nalogi, če so se le-ti spremenili. Začetna ocena se ne sme več spremeniti, ko je izdelava seznama nalog končana. Brisanje naloge Kot član razvojne skupine želim brisati nalogo, ki se izkaže kot nepotrebna. Brisanje naloge, za katero že obstajajo podatki o vloženem delu, ni dovoljeno. Razdelitev naloge na več manjših Kot član razvojne skupine želim razdeliti preobsežno nalogo na več manjših, da bi lahko natančneje ocenil in načrtoval svoje delo. (Mogoče samo spreminjanje obstoječe, z oznako, da odslej ni več veljavna, in vnos več novih nalog z veljavnostjo od tega dne dalje).

52 Poglavje 5 Podatkovni model Naj še predstavimo podatkovni model, ki smo ga uporabili za shranjevanje podatkov. Podatkovni model izhaja iz modela iz članka [3]. Prikazan je na sliki 5.1. Ta model je zelo splošen in ne predpisuje vrste in števila meritev, ki jih hrani. Pri načrtovanju podatkovnega modela smo se omejili in tako ta ne podpira zapisa rezultatov vseh meritev, naštetih v poglavju 3, ki se začne na strani 15. Lahko pa model, z dodatkom kakšne tabele, zlahka nadgradimo, tako da bi podpiral širšo množico meritev. Osredotočili smo se na meritve, ki nam omogočajo pravočasne informacije o uspešnosti projekta. To so indeks učinkovitosti (angl. Work effectiveness), terminski indeks (angl. Schedule performance index - SPI ) oziroma stroškovni indeks (angl. Cost performance index - CPI ). Podatovni model je predstavljen na sliki 5.2. S kreiranjem novega projekta naredimo nov zapis v tabeli PROJECT. Shranimo samo ime projekta in morebiten opis. Pred začetkom dela na projektu pa moramo uporabnikom aplikacije še določiti uporabniške vloge na tem projektu (Skrbnik metodologije, Produktni vodja ali Član razvojne skupine). Ko smo to naredili, lahko pričnemo z določanjem uporabniških zgodb. Te shranjujemo v tabeli PBI (Product backlog item). Vnesemo ime uporabniške zgodbe, njen opis in njeno prioriteto. Lahko določimo tudi točke (zahtevnost uporabniške zgodbe), vendar to ponavadi naredimo kasneje, ob prenosu zgodbe v iteracijo. Naj še povemo, zakaj je tabeli ime PBI. Kratica PBI je, kot smo že omenili, kratica za Product backlog item, kar prevedeno pomeni element seznama zahtev. V našem primeru je seznam zahtev množica uporabniških zgodb. 37

53 38 Poglavje 5: Podatkovni model Ob vsakem začetku cikla določimo podatke iteracije, njen začetek, konec in dolžino. Ti podatki so vidni v tabeli SPRINT. Pred pričetkom iteracije določimo zgodbe, nad katerimi bomo v tej iteraciji delali in jim določimo njihovo zahtevnost (točke). Ti podatki se zapišejo v tabeli SP RINT P BI. Nato vsako izbrano zgodbo razdelimo na naloge. Določimo ime in opis naloge ter število ur, ki bodo potrebne za dokončanje le-te (tabele TASK in T ASK SP RINT P BI). Ob delu na nalogah iteracije dnevno zapisujemo, koliko smo ta dan porabili na tej nalogi in koliko dela nam je še preostalo na tej nalogi. To se zapiše v tabelo T ASK W ORK. S tem smo na kratko opisali glavne poslovne tabele naše aplikacije. Več podrobnosti je videnih na sliki 5.2, kjer je predstavljen celoten podatkovni model.

54 Slika 5.1: Podatkovni model, na katerega smo se sklicevali pri kreiranju našega podatkovnega modela [3] 39

55 40 Poglavje 5: Podatkovni model Slika 5.2: Podatkovni model

56 Poglavje 6 Aplikacija Glavni del diplomske naloge se nanaša na aplikacijo za pomoč pri vodenju projektov po metodi Scrum. Poleg upravljanja s podatki o projektu (iteracije, zgodbe, naloge, delo na nalogah) naj bi aplikacija omogočala še prikaz rezultatov v obliki tabel ter stolpičnih in tortnih diagramov. Podatki za prikaz izhajajo iz meritev, predstavljenih v poglavju 3, ki se začne na strani 15. Odločili smo se narediti spletno aplikacijo, in sicer v tehnologiji ASP.NET MVC [7]. Odločitev za to tehnologijo je temeljila predvsem na dejstvu, da smo imeli že predhodno izkušnje z izbrano tehnologijo in smo tako poznali ogrodje. Zahtevane funkcionalnosti aplikacije smo že opisali v poglavju 4, na strani Uporabniški vmesnik Na kratko bomo predstavili uporabniški vmesnik. Tekst ni mišljen kot navodilo za uporabo aplikacije, ampak kot predstavitev funkcionalnosti aplikacije. Za uporabo aplikacije se je potrebno predhodno v aplikacijo prijaviti, oziroma registrirati, če uporabniškega računa še nimamo Kreiranje projekta Za kreiranje novega projekta moramo imeti zadostne privilegije v sami aplikaciji (vloga ProjectCreator). Ta vloga ni povezana z vlogami v metodi Scrum. Navezuje se na samo aplikacijo in nam kot prijavljenemu uporabniku dovoli kreiranje novega projekta. Na ekranu pregleda projektov izberemo povezavo Kreiranje novega projekta in izpolnimo formo. Ko ta korak uspešno naredimo, določimo vloge (privilegije) 41

57 42 Poglavje 6: Aplikacija uporabnikom, ki bodo sodelovali na tem projektu. Te vloge so vezane samo na ta projekt. Poznamo štiri vloge, in sicer Skrbnik metodologije, Produktni vodja, Član razvojne skupine in Dodaj. Pomeni prvih treh naštetih vlog so taki, kot so specificirani v metodi Scrum. Več v poglavju 2.3.1, ki se začne na strani 10. Z vlogo Dodaj, pa lahko ostalim uporabnikom dodajamo in odvzemamo vloge na projektu. To vlogo avtomatsko dobi kreator projekta. Po tem koraku moramo projektu še določiti skupino, ki bo na izbranem projektu delala. Brisanje projekta Projekta iz podatkovne baze fizično ni mogoče izbrisati (preko odjemalca). Je pa možno projektu spremeniti status na Izbrisan (angl. Deleted) in tako ta projekt ni več viden pri prikazu le-teh. Če smo se zmotili, lahko projektu ponovno spremenimo status. Do brisanega projekta pridemo tako, da pod iskalnimi pogoji izberemo še status projekta izbrisan Kreiranje skupin Vsakemu projektu, ki ga kreiramo, moramo določiti tudi skupino, ki bo delala na njem. Potrebni podatki so samo njeno ime in po želji še opis. Nato sledi dodajanje razvijalcev skupini. Če ti predhodno niso vnešeni, moramo storiti še ta korak. O razvijalcu nas zanima njegovo ime in priimek, poleg tega pa je pomemben še podatek o njegovi ceni na uro. Ta se kasneje uporablja pri izračunu stroškovnega indeksa Dodeljevanje vlog na projektu Po kreiranju projekta in dodelitvi projekta skupini, lahko pa tudi kasneje med delom na njem, lahko na ekranu za urejanje privilegijev, uporabnikom, ki bodo sodelovali na projektu, dodelimo določene vloge. To lahko počnemo, če imamo mi na tem projektu vlogo Dodaj (samodejno jo dobi kreator projekta). Vloge na projektu so lahko naslednje: Dodaj - uporabnik s to vlogo lahko drugim uporabnikom (in tudi sebi) dodeljuje vloge. Skrbnik metodologije - vloga je namenjena skrbniku metodologije projekta. Produktni vodja - vloga je namenjena produktnemu vodji projekta.

58 6.1 Uporabniški vmesnik 43 Član razvojne skupine - to vlogo imajo vsi ostali razvijalci na projektu (Člani razvojne skupine). Funkcionalnosti, ki so na voljo posameznim vlogam, smo že opisali v specifikaciji zahtev Kreiranje uporabniških zgodb Ob začetku projekta in pa tudi med samim projektom moramo kreirati uporabniške zgodbe (slika 6.1). Vloga, ki jo moramo imeti, da lahko to počnemo, je vloga Produktni vodja. Zgodbo lahko kreiramo brez določitve iteracije in jo kasneje dodamo določeni iteraciji ali pa ob že izbrani iteraciji. Na drugi način, ob že izbrani iteraciji, se tej zgodba avtomatsko doda. Brisanje uporabniških zgodb Uporabniško zgodbo lahko v primeru napake pri vnosu tudi izbrišemo. To nam aplikacija dovoli, če ta zgodba še ni bila dodeljena nobeni iteraciji. V kolikor je bila zgodba dodeljena iteraciji, moramo to zgodbo iz nje predhodno odstraniti. Šele nato jo lahko izbrišemo Kreiranje iteracije Ob začetku vsake iteracije moramo le-to kreirati. Pri njenem kreiranju moramo poznati njeno dolžino in njen začetni ter končni datum. Iteracije v istem projektu se ne smejo časovno prekrivati. Dolžina iteracije je mišljena kot število delovnih dni v njenem obdobju, na katerih bomo delali na izbranem projektu. Pomembna je, saj vpliva na meritev terminskega indeksa in zato, ker določa, koliko dnevnih Scrum sestankov bomo imeli v tej iteraciji. Na slednjih dnevno določamo naše delo na nalogah projekta in pa preostalo planirano delo na teh nalogah. Dodeljevanje zgodb iteraciji Kot smo že omenili, lahko že obstoječo zgodbo dodamo izbrani iteraciji. S tem dodamo tudi vse naloge, ki pripadajo izbrani uporabniški zgodbi. Ko zgodbo dodamo iteraciji, ji moramo določiti njeno zahtevnost (v točkah). Ena točka naj bi predstavljala približno en idealen delovni dan (6 ur dela). Tako število točk na zgodbi pomeni oceno števila delovnih dni, ki jih planiramo za njeno implementacijo.

59 44 Poglavje 6: Aplikacija Slika 6.1: Kreiranje uporabniške zgodbe

60 6.1 Uporabniški vmesnik 45 Slika 6.2: Delitev uporabniške zgodbe Delitev zgodbe Velikokrat so zgodbe na začetku napisane preobširno in se šele s podrobnejšim pogovorom vidi njena dejanska obsežnost. V takih primerih lahko zgodbo razdelimo na več manjših zgodb (slika 6.2). Pogoj, da lahko to naredimo je, da uporabniška zgodba ne pripada še nobeni iteraciji, kar posredno pomeni, da uporabniška zgodba še ni razdeljena na podnaloge Kreiranje nalog zgodbe Ob začetku vsake iteracije, lahko pa tudi med samo iteracijo, je potrebno uporabniške zgodbe natančneje definirati. Ob tem naredimo tudi razčlenitev teh zgodb na naloge. Vsaka dobljena naloga naj ne bi trajala več kot šestnajst ur. Ob kreiranju naloge moramo določiti tudi njeno začetno oceno v urah (koliko časa naj bi razvijalec porabil na tej nalogi). Delitev naloge Ko ob začetku iteracije razpravljamo o uporabniški zgodbi, velikokrat nimamo časa točno definirati vseh nalog, oziroma želimo raje kot razpravljati o vseh nalogah, začeti z delom na že definiranih. Tako ostalih funkcionalnosti ne

61 46 Poglavje 6: Aplikacija razbijemo na dokončne naloge, ampak kreiramo večje naloge. Te večje naloge nato, ob pravem času, razbijemo na podnaloge Vpisovanje dela na nalogi Med samim delom na nalogi moramo dnevno (ponavadi na dnevnem Scrum sestanku) vpisovati število ur, ki jih porabimo za delo na njej. Poleg datuma in števila ur, ki smo jih porabili z delom na nalogi in ocene preostanka dela na nalogi (v urah), ki so obvezni podatki, lahko tukaj zabeležimo še dodaten komentar, ki nam je lahko v pomoč kasneje. Urejamo lahko samo zadnji zapis in še tega samo, če je bil kreiran največ n dni nazaj. Število n je v aplikaciji nastavljivo kot parameter. Privzeto ima vrednost tri. Tri dni pa zato, da lahko uporabnik v ponedeljek, ko pride na delo, še popravi zadnji zapis, ki ga je ustvaril v petek. Mogoče bi bilo tukaj tudi smiselno omejiti vnos za več kot n dni nazaj, saj bi s tem razvijalca, ki je dolžan izpolnjevati te podatke, prisilili v sprotno izpolnjevanje. Tako bi prišli do bolj verodostojnih podatkov za meritve terminskega indeksa in ostalih meritev, ki jih izvajamo, saj lahko v obratnem primeru razvijalec z vnašanjem podatkov počaka do konca naloge, nato pa vnese podatke tako, da je njegovo planiranje prikazano kot idealno. Po drugi strani pa naj bi skupina imela dnevne Scrum sestanke, kjer bi se vnašali ti podatki, tako da smo se odločili, da te omejitve v aplikacijo ne vgradimo. Za brisanje zapisa veljajo enaki pogoji kot za njegovo urejanje. Brišemo lahko samo zadnji zapis in še ta ne sme biti starejši kot n dni. Seveda lahko nato izbrišemo še predzadnji zapis in tako naprej. Pogoj je le, da noben od njih ni starejši od n dni Prikaz meritev Glavni cilj diplomske naloge je bil, da iz podatkov, ki jih imamo o projektu (iteracije, uporabniške zgodbe, naloge in predvsem delo na nalogah), prikažemo različne uporabne rezultate. Ti rezultati naj bi bili v obliki, ki je hitro in lahko berljiva. Najprej bomo opisali prikaz rezultatov na nivoju projekta, nato pa še rezultate na nivoju iteracije, uporabniške naloge oziroma naloge. Rezultati na nivoju projekta Z dvoklikom na želen projekt v pregledu prikaza projektov se nam prikaže modalno okno s podrobnostmi projekta. Na tem oknu imamo tri povezave, ki nas vodijo do različnega prikaza rezultatov o projektu.

62 6.1 Uporabniški vmesnik 47 Slika 6.3: Diagram za analizo trenda projekta - na prvem diagramu je prikazano padanje števila preostalih ur na projektu, na drugem pa padanje števila točk Diagram za analizo trenda projekta V tem prikazu gre dejansko za dva diagrama (slika 6.3). Prvi prikazuje padanje preostanka dela na projektu v urah. Vzorci so vzeti samo na začetku vsake iteracije (oziroma na koncu, če gre za zadnjo iteracijo). Drugi pa prikazuje padanje preostanka točk. Točke so definirane na uporabniški zgodbi. Ko zgodbo zaključimo in je potrjena s strani produktnega vodje, se preostanek dela na projektu zmanjša za to število točk. Tako je ta podatek samo seštevek točk še ne zaključenih uporabniških zgodb. Privilegij za spreminjanje statusa uporabniške zgodbe ima samo produktni vodja, saj mora o uspešnosti realizacije zgodbe presoditi sam. Diagram članov skupine Ta prikaz je sestavljen iz dveh tortnih diagramov (slika 6.4). Prvi predstavlja delež načrtovanega dela na projektu, v številu ur, po razvijalcih, drugi pa predstavlja delež dejanskega dela na projektu po razvijalcih. S primerjavo obeh diagramov lahko vidimo kako dobro so posamezni razvijalci planirali svoje delo na projektu in pa koliko je bilo skupaj planiranega in dejanskega dela na projektu. Izvrševanje plana uporabniških zgodb Ob kreiranju oziroma dodajanju uporabniške zgodbe iteraciji smo ji morali določiti število točk. Kot smo že opisali, naj bi število točk predstavljalo zahtevnost zgodbe. In sicer na način,

63 48 Poglavje 6: Aplikacija Slika 6.4: Diagram članov skupine - na prvem diagramu je prikazano planirano delo po razvijalcih, na drugem pa dejansko delo da če točke pomnožimo s šest (efektivnih ur v delovnem dnevu), dobimo koliko ur naj nam bi vzelo delo na zgodbi. Tako točke direktno pomenijo, koliko dni naj bi delali na nalogi, če se posvečamo samo njej. Če se vrnemo na to, kaj izvrševanje plana uporabniških zgodb pomeni. Predstavlja nam absolutno in relativno napako med planiranim delom in dejanskim delom (slika 6.5). Slednje dobimo tako, da dejansko število ur, ki smo jih porabili na vseh nalogah uporabniške zgodbe, delimo s šest. Napaka (absolutna in relativna) pod vrednostjo nič pomeni, da smo za nalogo porabili manj kot smo planirani, nad vrednostjo nič pa obratno. Za prikaz te meritve se nismo odločili uporabiti grafične oblike. Predstavili smo jo kar v obliki tabele. Rezultati na nivoju iteracije, uporabniške zgodbe, naloge Naslednje meritve lahko opravimo na različnih nivojih strukture procesa. Ti nivoji so iteracija, uporabniška zgodba in posamezna naloga. Razlika je samo v tem, katere naloge vključimo v izračun kazalcev. Samo eno nalogo, vse naloge uporabniške zgodbe ali kar vse naloge iteracije. Na podmnožici nalog tako prikažemo naslednje meritve (slika 6.6): Delež prislužene vrednosti (angl. Earning rule)

64 6.1 Uporabniški vmesnik 49 Slika 6.5: Izvrševanje plana uporabniških zgodb Terminski indeks (angl. Schedule performance index) Stroškovni indeks (angl. Cost performance index) Indeks učinkovitosti (angl. Work effectiveness) Diagram za analizo trenda (angl. Burndown chart) Kaj posamezna meritev pove in kako priti do nje, smo napisali že v enem od prejšnjih poglavij.

65 50 Poglavje 6: Aplikacija Slika 6.6: Rezultati na nivoju iteracije - prikazane so meritve terminski indeks, stroškovni indeks, indeks učinkovitosti in diagram za analizo trenda

Aleš Štempihar Agile in IIBA poslovni analitiki dodana vrednost za organizacijo in njene kupce Povzetek: Kaj je pravzaprav Agile? Je to metodologija z

Aleš Štempihar Agile in IIBA poslovni analitiki dodana vrednost za organizacijo in njene kupce Povzetek: Kaj je pravzaprav Agile? Je to metodologija z Aleš Štempihar Agile in IIBA poslovni analitiki dodana vrednost za organizacijo in njene kupce Povzetek: Kaj je pravzaprav Agile? Je to metodologija za izvajanje projektov, je to tehnika in orodje za razvoj

Prikaži več

Document ID / Revision : 0519/1.3 ID Issuer System (sistem izdajatelja identifikacijskih oznak) Navodila za registracijo gospodarskih subjektov

Document ID / Revision : 0519/1.3 ID Issuer System (sistem izdajatelja identifikacijskih oznak) Navodila za registracijo gospodarskih subjektov ID Issuer System (sistem izdajatelja identifikacijskih oznak) Navodila za registracijo gospodarskih subjektov Gospodarski subjekti Definicija: V skladu z 2. členom Izvedbene uredbe Komisije (EU) 2018/574

Prikaži več

Slide 1

Slide 1 Projektno vodenje PREDAVANJE 7 doc. dr. M. Zajc matej.zajc@fe.uni-lj.si Projektno vodenje z orodjem Excel Predstavitev Najbolj razširjeno orodje za delo s preglednicami Dva sklopa funkcij: Obdelava številk

Prikaži več

PowerPoint Presentation

PowerPoint Presentation Poslovni analitik v agilnem svetu Prenova spletne strani Uvedba podpore za mobilne naprave Ineor d.o.o. O meni poslovni analitik izkušnje s tehnologijo (programiranje, razhroščevanje, inštalacije, administracija,...)

Prikaži več

Event name or presentation title

Event name or  presentation title Marko Škufca Vodja programa BI, ADD d.o.o. Gorazd Cah Specialist področja Služba za informatiko, DARS d.d. Izziv Rešitev Rezultati... PROCESI + TEHNOLOGIJA + LJUDJE Poslanstvo: s sodobnimi pristopi in

Prikaži več

Vpeljava agilnega in vitkega razvoja programske opreme v majhnem podjetju

Vpeljava agilnega in vitkega razvoja programske opreme v majhnem podjetju Univerza v Ljubljani Fakulteta za računalništvo in informatiko Valneja Stojčič Vpeljava agilnega in vitkega razvoja programske opreme v majhnem podjetju DIPLOMSKO DELO UNIVERZITETNI ŠTUDIJSKI PROGRAM PRVE

Prikaži več

PowerPointova predstavitev

PowerPointova predstavitev SKLOP 1: EKONOMIKA KMETIJSKEGA GOSPODARSTVA Upravljanje kmetijskih gospodarstev Tomaž Cör, KGZS Zavod KR Vsem značilnostim kmetijstva mora biti prilagojeno tudi upravljanje kmetij. Ker gre pri tem za gospodarsko

Prikaži več

Microsoft Word - pravilnik diploma_1.doc

Microsoft Word - pravilnik diploma_1.doc Na podlagi Statuta Univerze v Ljubljani in 42. člena Pravil o organiziranosti in delovanju Visoke šole za zdravstvo je senat Univerze v Ljubljani Visoke šole za zdravstvo na 38. redni seji dne 16. 10.

Prikaži več

Stanje agilnosti v Sloveniji 2018 State of Agile 2018 Pripravil: Enej Gradišek, CorpoHub December 2018 CorpoHub, vse pravice pridržane 2018

Stanje agilnosti v Sloveniji 2018 State of Agile 2018 Pripravil: Enej Gradišek, CorpoHub December 2018 CorpoHub, vse pravice pridržane 2018 Stanje agilnosti v Sloveniji 2018 State of Agile 2018 Pripravil: Enej Gradišek, CorpoHub December 2018 Stran 2 Kazalo 1. O raziskavi 3 2. Povzetek ugotovitev 4 3. Kaj so agilne metode? 5 4. Rezultati 6

Prikaži več

Diapozitiv 1

Diapozitiv 1 Računalništvo in informatika Program: Mehatronika dr. Hubert Fröhlich, univ. dipl. el. Podatkovne baze 2 Podatkovne baze Podatki osnova za odločanje in izvajanje akcij tiskana oblika elektronska oblika

Prikaži več

DELEGIRANA UREDBA KOMISIJE (EU) 2018/ z dne 13. julija o dopolnitvi Uredbe (EU) 2016/ Evropskega parlamenta in S

DELEGIRANA  UREDBA  KOMISIJE  (EU)  2018/ z dne  13. julija o dopolnitvi  Uredbe  (EU)  2016/ Evropskega  parlamenta  in  S 5.11.2018 L 274/11 DELEGIRANA UREDBA KOMISIJE (EU) 2018/1639 z dne 13. julija 2018 o dopolnitvi Uredbe (EU) 2016/1011 Evropskega parlamenta in Sveta v zvezi z regulativnimi tehničnimi standardi, ki podrobneje

Prikaži več

Microsoft Word - 13-Selekcijski intervju.docx

Microsoft Word - 13-Selekcijski intervju.docx številka 13, 15. dec.2004, ISSN 1581-6451, urednik:radovan Kragelj Pozdravljeni! Danes nadaljujemo z vprašanji, s katerimi vrednotite konkretne lastnosti in sposobnosti posameznega kandidata. V prejšnjih

Prikaži več

PRIPOROČILA ZA OBLIKOVANJE KATALOGOV ZNANJA ZA MODULE V PROGRAMIH VIŠJEGA STROKOVNEGA IZOBRAŽEVANJA

PRIPOROČILA ZA OBLIKOVANJE KATALOGOV ZNANJA ZA MODULE V PROGRAMIH VIŠJEGA STROKOVNEGA IZOBRAŽEVANJA KATALOG ZNANJA 1. IME PREDMETA ZBIRKE PODATKOV I ZBIRKE PODATKOV II 2. SPLOŠNI CILJI Splošni cilji predmeta so: razvijanje sposobnosti za uporabo znanstvenih metod in sredstev, razvijanje odgovornosti

Prikaži več

Protokoli v računalniškem komuniciranju TCP, IP, nivojski model, paket informacij.

Protokoli v računalniškem komuniciranju TCP, IP, nivojski model, paket informacij. Protokoli v računalniškem komuniciranju TCP, IP, nivojski model, paket informacij. Protokoli - uvod Protokol je pravilo ali zbirka pravil, ki določajo načine transporta sporočil po računalniškem omrežju

Prikaži več

INDUSTRIJA 4.0: PRILOŽNOSTI DIGITALNE PREOBRAZBE PROCESA RAZVOJA BARV IN PREMAZOV TOMAŽ KERN, BENJAMIN URH, MARJAN SENEGAČNIK, EVA KRHAČ

INDUSTRIJA 4.0:  PRILOŽNOSTI DIGITALNE PREOBRAZBE PROCESA RAZVOJA BARV IN PREMAZOV TOMAŽ KERN, BENJAMIN URH, MARJAN SENEGAČNIK, EVA KRHAČ INDUSTRIJA 4.0: PRILOŽNOSTI DIGITALNE PREOBRAZBE PROCESA RAZVOJA BARV IN PREMAZOV TOMAŽ KERN, BENJAMIN URH, MARJAN SENEGAČNIK, EVA KRHAČ AGENDA IZZIV OZADJE RAZISKAVE POSNETEK STANJA ANALIZA STANJA in

Prikaži več

Turingov stroj in programiranje Barbara Strniša Opis in definicija Definirajmo nekaj oznak: Σ abeceda... končna neprazna množica simbolo

Turingov stroj in programiranje Barbara Strniša Opis in definicija Definirajmo nekaj oznak: Σ abeceda... končna neprazna množica simbolo Turingov stroj in programiranje Barbara Strniša 12. 4. 2010 1 Opis in definicija Definirajmo nekaj oznak: Σ abeceda... končna neprazna množica simbolov (običajno Σ 2) Σ n = {s 1 s 2... s n ; s i Σ, i =

Prikaži več

Microsoft Word - 021_01_13_Pravilnik_o_zakljucnem delu

Microsoft Word - 021_01_13_Pravilnik_o_zakljucnem delu Na podlagi 64. člena Pravil o organizaciji in delovanju Fakultete za humanistične študije, št. 011-01/13 z dne 27. 6. 2013, je Senat Univerze na Primorskem Fakultete za humanistične študije na svoji 4.

Prikaži več

DNEVNIK

DNEVNIK POROČILO PRAKTIČNEGA USPOSABLJANJA Z DELOM PRI DELODAJALCU DIJAKA / DIJAKINJE. ( IME IN PRIIMEK) Izobraževalni program FRIZER.. Letnik:.. oddelek:. PRI DELODAJALCU. (NASLOV DELODAJALCA) Šolsko leto:..

Prikaži več

Microsoft Word - M docx

Microsoft Word - M docx Š i f r a k a n d i d a t a : Državni izpitni center *M15245112* JESENSKI IZPITNI ROK Izpitna pola 2 / 90 minut Dovoljeno gradivo in pripomočki: Kandidat prinese nalivno pero ali kemični svinčnik in računalo.

Prikaži več

KONTINGENČNI PRISTOP K OBLIKOVANJU SISTEMA STRATEŠKEGA POSLOVODNEGA RAČUNOVODSTVA: EMPIRIČNA PREVERBA V SLOVENSKIH PODJETJIH

KONTINGENČNI PRISTOP K OBLIKOVANJU SISTEMA STRATEŠKEGA POSLOVODNEGA RAČUNOVODSTVA:  EMPIRIČNA PREVERBA V SLOVENSKIH PODJETJIH Temelji poslovodnega računovodstva(1) Uvod v poslovodno računovodstvo (kontroling) Prof. dr. Simon Čadež simon.cadez@ef.uni-lj.si 2 CILJI PREDMETA Opredeliti vlogo managerjev in poslovodnega računovodstva

Prikaži več

UNIVERZA V LJUBLJANI FAKULTETA ZA MATEMATIKO IN FIZIKO Katja Ciglar Analiza občutljivosti v Excel-u Seminarska naloga pri predmetu Optimizacija v fina

UNIVERZA V LJUBLJANI FAKULTETA ZA MATEMATIKO IN FIZIKO Katja Ciglar Analiza občutljivosti v Excel-u Seminarska naloga pri predmetu Optimizacija v fina UNIVERZA V LJUBLJANI FAKULTETA ZA MATEMATIKO IN FIZIKO Katja Ciglar Analiza občutljivosti v Excel-u Seminarska naloga pri predmetu Optimizacija v financah Ljubljana, 2010 1. Klasični pristop k analizi

Prikaži več

II-RIS-Primer Seminarske Naloge Redni-LJ

II-RIS-Primer Seminarske Naloge Redni-LJ UNIVERZA V LJUBLJANI FAKULTETA ZA UPRAVO Študijski program: Visokošolski strokovni program Uprava Prva stopnja (bolonjski) Način študija: redni ČIŠČENJE VOZIL V AVTOPRALNICI Seminarska naloga Predmet:

Prikaži več

Navodilo Struktura cene izdelka Št. dokumenta : Izdaja: 01 Datum spremembe: Stran: 1/5 NAVODILO STRUKTURA CENE IZDELKA 1. POVZETEK

Navodilo Struktura cene izdelka Št. dokumenta : Izdaja: 01 Datum spremembe: Stran: 1/5 NAVODILO STRUKTURA CENE IZDELKA 1. POVZETEK Stran: 1/5 NAVODILO STRUKTURA CENE IZDELKA 1. POVZETEK Splošne informacije Naročnik E-mail Telefonska številka Datum Dobavitelj Dobaviteljeva št. Projekt Referenca Naziv Indeks Verzija Varianta Odgovorna

Prikaži več

PowerPointova predstavitev

PowerPointova predstavitev INTRANET - DETEKTIV Detektivska zbornica Republike Slovenije Pozdravljeni, v kratki predstaviti in navodilih za delo z intranet sistemom Detektiv. Intranet članom Detektivske zbornice RS omogoča, da: -

Prikaži več

Univerza v Ljubljani Fakulteta za računalništvo in informatiko Peter Šfiligoj Analiza primernosti orodja za hiter razvoj aplikacij DIPLOMSKO DELO VISO

Univerza v Ljubljani Fakulteta za računalništvo in informatiko Peter Šfiligoj Analiza primernosti orodja za hiter razvoj aplikacij DIPLOMSKO DELO VISO Univerza v Ljubljani Fakulteta za računalništvo in informatiko Peter Šfiligoj Analiza primernosti orodja za hiter razvoj aplikacij DIPLOMSKO DELO VISOKOŠOLSKI STROKOVNI ŠTUDIJSKI PROGRAM PRVE STOPNJE RAČUNALNIŠTVO

Prikaži več

Microsoft Word - IPIN slovenska navodila za pridobitev

Microsoft Word - IPIN slovenska navodila za pridobitev IPIN MEDNARODNA IDENTIFIKACIJSKA ŠTEVILKA IGRALCA Spoštovani igralec tenisa! Vsak, ki želi igrati na tekmovanjih pod okriljem mednarodne teniške zveze (ITF), mora pridobiti mednarodno identifikacijsko

Prikaži več

1 MMK - Spletne tehnologije Vaja 5: Spletni obrazci Vaja 5 : Spletni obrazci 1. Element form Spletni obrazci so namenjeni zbiranju uporabniških podatk

1 MMK - Spletne tehnologije Vaja 5: Spletni obrazci Vaja 5 : Spletni obrazci 1. Element form Spletni obrazci so namenjeni zbiranju uporabniških podatk 1 MMK - Spletne tehnologije Vaja 5: Spletni obrazci Vaja 5 : Spletni obrazci 1. Element form Spletni obrazci so namenjeni zbiranju uporabniških podatkov in njihov prenos med spletnimi mesti. Obrazec v

Prikaži več

Microsoft Word - vprasalnik_AZU2007.doc

Microsoft Word - vprasalnik_AZU2007.doc REPUBLIKA SLOVENIJA Anketa o zadovoljstvu uporabnikov statističnih podatkov in informacij Statističnega urada RS 1. Kako pogosto ste v zadnjem letu uporabljali statistične podatke in informacije SURS-a?

Prikaži več

Microsoft Word - pravila Studentski dom.doc

Microsoft Word - pravila Studentski dom.doc Pravila o merilih za sprejem in podaljšanje bivanja v študentskem domu Nova Gorica, 25. julij 2008 Prejmejo: Študentska pisarna Komisija za študentske zadeve Študentski svet Predsednik Predstojnik Ime

Prikaži več

Razpis - podiplomski študij

Razpis - podiplomski študij RAZPIS ZA VPIS V DOKTORSKA ŠTUDIJSKA PROGRAMA 3. STOPNJE UNIVERZE NA PRIMORSKEM PEDAGOŠKE FAKULTETE V ŠTUDIJSKEM LETU 2016/2017 Za vpis v podiplomske doktorske študijske programe 3. stopnje v študijskem

Prikaži več

VSEBINSKI NASLOV SEMINARSKE NALOGE

VSEBINSKI NASLOV SEMINARSKE NALOGE Univerza v Ljubljani Naravoslovnoteniška fakulteta Oddelek za tekstilstvo VSEBINSKI NASLOV SEMINARSKE NALOGE TITLE IN ENGLISH Avtorja: Študijska smer: Predmet: Informatika in metodologija diplomskega dela

Prikaži več

Zbornica zdravstvene in babiške nege Slovenije Zveza strokovnih društev medicinskih sester, babic in zdravstvenih tehnikov Slovenije Stanje:

Zbornica zdravstvene in babiške nege Slovenije Zveza strokovnih društev medicinskih sester, babic in zdravstvenih tehnikov Slovenije Stanje: Zbornica zdravstvene in babiške nege Slovenije Zveza strokovnih društev medicinskih sester, babic in zdravstvenih tehnikov Slovenije Stanje: 17.07.2013 Ver. 2.9.1.2 Spletni portal članov uporabniška navodila

Prikaži več

ZELENA DOLINA

ZELENA DOLINA REPUBLIKA SLOVENIJA MINISTRSTVO ZA DELO, DRUŽINO IN SOCIALNE ZADEVE ZELENA DOLINA Evalvacija programa dr. Janez Drobnič Projekt se izvaja v okviru Operativnega programa razvoja človeških virov za obdobje

Prikaži več

Microsoft Word - 88_01_Pravilnik_o_znanstveno_raziskovalnem_razvojnem_svetovalnem_delu_na_FZJ_ docx

Microsoft Word - 88_01_Pravilnik_o_znanstveno_raziskovalnem_razvojnem_svetovalnem_delu_na_FZJ_ docx Na podlagi 22., 70., 71., 94., 95., 96., 97. člena Statuta Fakultete za zdravstvo Jesenice je Senat Fakultete za zdravstvo Jesenice na svoji na 5. redni seji v študijskem letu 2014/2015, dne 18. 2. 2015,

Prikaži več

TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM POGOSTA VPRAŠANJA IN ODGOVORI Ljubljana, Verzija 1.0

TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM POGOSTA VPRAŠANJA IN ODGOVORI Ljubljana, Verzija 1.0 TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM POGOSTA VPRAŠANJA IN ODGOVORI Ljubljana, 12.11.2018 Verzija 1.0 KAZALO 1 REGISTRACIJA... 3 1.1 Katere podatke potrebujem za registracijo/kreiranje

Prikaži več

PowerPoint slovenska predloga

PowerPoint slovenska predloga NSP/2019/010 Predstavitev predloga koncepta analize trga plačil Tina Vehovar Smole, Banka Slovenije 14. seja Nacionalnega sveta za plačila 4. julij 2019 Izhodišča za pripravo analize Aktivnost priprave

Prikaži več

Microsoft Word - Financni nacrt SSUL 2009 BREZOVAR.doc

Microsoft Word - Financni nacrt SSUL 2009 BREZOVAR.doc 1 FINANČNI NAČRT ŠTUDENTSKEGA SVETA UNIVERZE V LJUBLJANI ZA LETO 2009, ki ga je Študentski svet Univerze v Ljubljani sprejel na seji dne 14. 1. 2009 in ga pošilja Upravnemu odboru Univerze v Ljubljani

Prikaži več

Pravilnost podatkov, navedenih v vlogi, bo

Pravilnost podatkov, navedenih v vlogi, bo Pravilnost podatkov, navedenih v vlogi, bo Šolsko leto: 2019/2020 preverila komisija za sprejem otrok v vrtec pri upravljavcih zbirk osebnih podatkov, ki Datum oddaje vloge: / jih vodijo v skladu z zakonom.

Prikaži več

Vzpostavitev več nivojske varnostne infrastrukture S pomočjo Elektro Maribor, McAfee SIEM, CISCO ISE, NGFW Zorna Varga, Sfera IT d.o.o in Klemen Bačak

Vzpostavitev več nivojske varnostne infrastrukture S pomočjo Elektro Maribor, McAfee SIEM, CISCO ISE, NGFW Zorna Varga, Sfera IT d.o.o in Klemen Bačak Vzpostavitev več nivojske varnostne infrastrukture S pomočjo Elektro Maribor, McAfee SIEM, CISCO ISE, NGFW Zorna Varga, Sfera IT d.o.o in Klemen Bačak, Sfera IT d.o.o. 1 Priprava na: Vzpostavitev več nivojske

Prikaži več

Diapozitiv 1

Diapozitiv 1 Samoevalvacija: POČUTJE UČENCEV V ŠOLI IN OCENA RAZLIČNIH ŠOLSKIH DEJAVNOSTI TER POGOJEV ZA DELO Šolsko leto 2018/19 PREDSTAVITEV REZULTATOV ANKETNEGA VPRAŠALNIKA ZA UČENCE OD 4. DO 9. RAZREDA IN UGOTOVITVE

Prikaži več

Macoma katalog copy

Macoma katalog copy POSLOVNE APLIKACIJE PO ŽELJAH NAROČNIKA Poročilni sistem Finance in kontroling Poprodaja Podatkovna skladišča Prodaja Proizvodnja Obstoječi ERP Partnerji Implementacija rešitev prilagojena po željah naročnika

Prikaži več

ŠTEVCI PROMETA IN NJIHOVA UPORABA ZA NAMENE STATISTIK ČRT GRAHONJA

ŠTEVCI PROMETA IN NJIHOVA UPORABA ZA NAMENE STATISTIK ČRT GRAHONJA ŠTEVCI PROMETA IN NJIHOVA UPORABA ZA NAMENE STATISTIK ČRT GRAHONJA Navdih Poizvedovanje po BD podatkovnih virih, ki imajo časovno dimenzijo in so dostopni. Večji promet pomeni večje število dobrin in močnejšo

Prikaži več

IZVEDBENI SKLEP KOMISIJE - z dne marca o določitvi meril za ustanavljanje in vrednotenje evropskih referenčnih mrež in

IZVEDBENI  SKLEP  KOMISIJE  -  z  dne marca o  določitvi  meril  za  ustanavljanje  in  vrednotenje  evropskih  referenčnih  mrež  in 17.5.2014 L 147/79 IZVEDBENI SKLEP KOMISIJE z dne 10. marca 2014 o določitvi meril za ustanavljanje in vrednotenje evropskih referenčnih mrež in njihovih članov ter za lažjo izmenjavo informacij in strokovnega

Prikaži več

08_03

08_03 OBVESTILO O RAZPISU ZA OBLIKOVANJE REZERVNEGA SEZNAMA Naziv delovnega mesta Funkcionalna skupina/razred AD 6 Vrsta pogodbe Sklic Rok za prijavo Kraj zaposlitve Veljavnost rezervnega seznama do Število

Prikaži več

Javno posvetovanje o vodniku za ocenjevanje prošenj za pridobitev licence in o vodniku za ocenjevanje prošenj finančnotehnoloških kreditnih institucij

Javno posvetovanje o vodniku za ocenjevanje prošenj za pridobitev licence in o vodniku za ocenjevanje prošenj finančnotehnoloških kreditnih institucij Javno posvetovanje o vodniku za ocenjevanje prošenj za pridobitev licence in o vodniku za ocenjevanje prošenj finančnotehnoloških kreditnih institucij za pridobitev licence Pogosta vprašanja 1 Kaj je banka?

Prikaži več

Program dela NO za leto 2009

Program dela NO za leto 2009 Na podlagi 41. člena statuta občine Mirna Peč ter 12. in 13. člena Poslovnika nadzornega odbora občine Mirna Peč, je Nadzorni odbor občine Mirna Peč na svoji 9. seji, dne 15.12.2008 in 3. korespondenčni

Prikaži več

Priloga 1: Pravila za oblikovanje in uporabo standardiziranih referenc pri opravljanju plačilnih storitev Stran 4012 / Št. 34 / Uradni lis

Priloga 1: Pravila za oblikovanje in uporabo standardiziranih referenc pri opravljanju plačilnih storitev Stran 4012 / Št. 34 / Uradni lis Priloga 1: Pravila za oblikovanje in uporabo standardiziranih referenc pri opravljanju plačilnih storitev Stran 4012 / Št. 34 / 24. 5. 2019 Uradni list Republike Slovenije PRILOGA 1 PRAVILA ZA OBLIKOVANJE

Prikaži več

Poročilo o letnih računovodskih izkazih Izvajalske agencije za izobraževanje, avdiovizualno področje in kulturo za proračunsko leto 2010 z odgovori Ag

Poročilo o letnih računovodskih izkazih Izvajalske agencije za izobraževanje, avdiovizualno področje in kulturo za proračunsko leto 2010 z odgovori Ag 15.12.2011 Uradni list Evropske unije C 366/63 POROČILO o letnih računovodskih izkazih Izvajalske agencije za izobraževanje, avdiovizualno področje in kulturo za proračunsko leto 2010 z odgovori Agencije

Prikaži več

Microsoft Word - NAVODILA ZA UPORABO.docx

Microsoft Word - NAVODILA ZA UPORABO.docx NAVODILA ZA UPORABO VODILO CCM-18A/N-E (K02-MODBUS) Hvala ker ste se odločili za nakup našega izdelka. Pred uporabo enote skrbno preberite ta Navodila za uporabo in jih shranite za prihodnjo rabo. Vsebina

Prikaži več

LABORATORIJSKE VAJE IZ FIZIKE

LABORATORIJSKE VAJE IZ FIZIKE UVOD LABORATORIJSKE VAJE IZ FIZIKE V tem šolskem letu ste se odločili za fiziko kot izbirni predmet. Laboratorijske vaje boste opravljali med poukom od začetka oktobra do konca aprila. Zunanji kandidati

Prikaži več

Microsoft Word - eDenar - navodila za uporabo osebnega portala clana doc

Microsoft Word - eDenar - navodila za uporabo osebnega portala clana doc Navodila za uporabo osebnega portala člana 13.11.08 Pozor: Ta navodila so le v pomoč uporabnikom. V kolikor so navodila v nasprotju s splošnimi pogoji poslovanja kluba, veljajo splošni pogoji poslovanja

Prikaži več

Osnove statistike v fizični geografiji 2

Osnove statistike v fizični geografiji 2 Osnove statistike v geografiji - Metodologija geografskega raziskovanja - dr. Gregor Kovačič, doc. Bivariantna analiza Lastnosti so med sabo odvisne (vzročnoposledično povezane), kadar ena lastnost (spremenljivka

Prikaži več

2019 QA_Final SL

2019 QA_Final SL Predhodni prispevki v enotni sklad za reševanje za leto 2019 Vprašanja in odgovori Splošne informacije o metodologiji izračuna 1. Zakaj se je metoda izračuna, ki je za mojo institucijo veljala v prispevnem

Prikaži več

Microsoft PowerPoint - Predstavitev novosti COBISS_OPAC_V60_17-18_06_2010_za objavo.ppt

Microsoft PowerPoint - Predstavitev novosti COBISS_OPAC_V60_17-18_06_2010_za objavo.ppt Predstavitev novosti: COBISS/OPAC, V6.0 (1. del) Maribor, 17. junij 2010 Ljubljana, 18. junij 2010 Program predstavite Uvod v predstavitev Marta Seljak Predstavitev COBISS/OPAC, V6.0 Robert Vehovec Predstavitev

Prikaži več

REPUBLIKA SLOVENIJA SLUŽBA VLADE REPUBLIKE SLOVENIJE ZA RAZVOJ IN EVROPSKO KOHEZIJSKO POLITIKO NAVODILA ZA PRIJAVO LISTIN NA ZZI V PRIMERU PRO RATA V

REPUBLIKA SLOVENIJA SLUŽBA VLADE REPUBLIKE SLOVENIJE ZA RAZVOJ IN EVROPSKO KOHEZIJSKO POLITIKO NAVODILA ZA PRIJAVO LISTIN NA ZZI V PRIMERU PRO RATA V REPUBLIKA SLOVENIJA SLUŽBA VLADE REPUBLIKE SLOVENIJE ZA RAZVOJ IN EVROPSKO KOHEZIJSKO POLITIKO NAVODILA ZA PRIJAVO LISTIN NA ZZI V PRIMERU PRO RATA V IS e-ma Ljubljana, avgust 2019 1 Vsebina 1. UVOD...

Prikaži več

RAZLIKE MED MSRP 16 IN MRS 17 Izobraževalna hiša Cilj

RAZLIKE MED MSRP 16 IN MRS 17 Izobraževalna hiša Cilj 15. 10. 2018 RAZLIKE MED MSRP 16 IN MRS 17 Izobraževalna hiša Cilj MSRP 16 MRS 17 OPREDELITEV POJMA 'NAJEM' V skladu z MSRP 16 je najem pogodba ali del pogodbe, ki prenaša pravico do uporabe identificiranega

Prikaži več

PowerPoint Presentation

PowerPoint Presentation Napovedno oglaševanje Kombiniranje internih in eksternih podatkov za boljšo učinkovitost oglaševanja Miloš Suša, iprom Andraž Zorko, Valicon Mojca Pesendorfer, Atlantic Grupa Ljubljana, 22.10.2018 PREDIKTIVNO

Prikaži več

Datum in kraj

Datum in kraj Ljubljana, 5. 4. 2017 Katalog znanj in vzorci nalog za izbirni izpit za vpis na magistrski študij Pedagoško računalništvo in informatika 2017/2018 0 KATALOG ZNANJ ZA IZBIRNI IZPIT ZA VPIS NA MAGISTRSKI

Prikaži več

Navodilo za urejanje zavarovanj po šifri podlage za zavarovanje 033 prek portala e-vem Ljubljana, oktober 2015

Navodilo za urejanje zavarovanj po šifri podlage za zavarovanje 033 prek portala e-vem Ljubljana, oktober 2015 Navodilo za urejanje zavarovanj po šifri podlage za zavarovanje 033 prek portala e-vem Ljubljana, oktober 2015 Kazalo vsebine 1. Pooblastilo za izvajanje postopkov prek portala e-vem... 4 2. Prijava v

Prikaži več

Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 89/2015) Sporočanje

Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 89/2015) Sporočanje Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 89/2015) Sporočanje podatkov je obvezno. Vprašalnik za statistično raziskovanje

Prikaži več

EVROPSKA KOMISIJA Bruselj, C(2017) 5518 final IZVEDBENA UREDBA KOMISIJE (EU) / z dne o spremembi Izvedbene uredbe (EU) št. 615/2014

EVROPSKA KOMISIJA Bruselj, C(2017) 5518 final IZVEDBENA UREDBA KOMISIJE (EU) / z dne o spremembi Izvedbene uredbe (EU) št. 615/2014 EVROPSKA KOMISIJA Bruselj, 9.8.2017 C(2017) 5518 final IZVEDBENA UREDBA KOMISIJE (EU) / z dne 9.8.2017 o spremembi Izvedbene uredbe (EU) št. 615/2014 o podrobnih pravilih za izvajanje Uredbe (EU) št. 1306/2013

Prikaži več

%

% OSNOVNA ŠOLA NARODNEGA HEROJA RAJKA HRASTNIK PODRUŽNIČNA ŠOLA DOL PRI HRASTNIKU PODRUŽNICA LOG AKTIV TJA IN NI KRITERIJ OCENJEVANJA 2018/2019 0-44 % nzd (1) 45-64 % zd (2) 65-79 % db (3) 80-89 % pdb (4)

Prikaži več

N

N Državni izpitni center *N19141132* 9. razred FIZIKA Ponedeljek, 13. maj 2019 NAVODILA ZA VREDNOTENJE NACIONALNO PREVERJANJE ZNANJA v 9. razredu Državni izpitni center Vse pravice pridržane. 2 N191-411-3-2

Prikaži več

Microsoft Word - SEP, koncnaaaaaaaaaaaaaaaaaaaaaaaaaaa

Microsoft Word - SEP, koncnaaaaaaaaaaaaaaaaaaaaaaaaaaa Osnovna šola bratov Letonja telefon/fax: (03) 8965300, 8965304 Šmartno ob Paki 117 e-pošta: os-bl-smartno@guest.arnes.si 3327 Šmartno ob Paki spl. stran: www.ossmartno.si SAMOEVALVACIJSKO POROČILO SODELOVANJE

Prikaži več

Microsoft Word - P-2_prijava

Microsoft Word - P-2_prijava PRIJAVA Naročnik Oznaka Ime posla NIJZ Trubarjeva cesta 2 1000 LJUBLJANA 49K040717 Javno naročilo Nakup novih diskovnih kapacitet Povsod, kjer obrazec P-2 uporablja izraz»ponudnik«, gre v postopkih, kjer

Prikaži več

PowerPoint Presentation

PowerPoint Presentation Zapisovanje učnih izidov Bled, 21.1.2016 Darko Mali ECVET ekspert, CPI Pojmi: Kvalifikacija Kompetenca Učni cilji Učni izidi Enote učnih izidov Kreditne točke Programi usposabljanja NE! 2 Učni cilji kompetence

Prikaži več

NEVTRIN d.o.o. Podjetje za razvoj elektronike, Podgorje 42a, 1241 Kamnik, Slovenia Telefon: Faks.: in

NEVTRIN d.o.o. Podjetje za razvoj elektronike, Podgorje 42a, 1241 Kamnik, Slovenia Telefon: Faks.: in NEVTRIN d.o.o. Podjetje za razvoj elektronike, Podgorje 42a, 1241 Kamnik, Slovenia Telefon: +386 1 729 6 460 Faks.: +386 1 729 6 466 www.nevtrin.si info@elektrina.si USB RFID READER Navodila za uporabo?

Prikaži več

UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA DIPLOMSKO DELO AGILNI RAZVOJ PROGRAMSKIH REŠITEV NA PRIMERU SISTEMA NAVISION Ljubljana, januar 2006 MARKO SRE

UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA DIPLOMSKO DELO AGILNI RAZVOJ PROGRAMSKIH REŠITEV NA PRIMERU SISTEMA NAVISION Ljubljana, januar 2006 MARKO SRE UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA DIPLOMSKO DELO AGILNI RAZVOJ PROGRAMSKIH REŠITEV NA PRIMERU SISTEMA NAVISION Ljubljana, januar 2006 MARKO SREBRE IZJAVA Študent Marko Srebre izjavljam, da sem avtor

Prikaži več

TEHNIČNA DOKUMENTACIJA

TEHNIČNA DOKUMENTACIJA TEHNIČNA DOKUMENTACIJA za OBNOVO EVIDENCE DEJANSKE RABE KMETIJSKIH IN GOZDNIH ZEMLJIŠČ (območje V in Z del SLO) Verzija 1.0 Ljubljana, marec 2016 KAZALO 1 UVOD... 3 1.1 OBMOČJE PROJEKTA... 4 1.2 ČASOVNICA

Prikaži več

Navodila za uporabo aplikacije mlist - neposredni mentorji za Zdravniško zbornico Slovenije pripravila Gooya, interaktivni mediji, d.o.o. Ljubljana, m

Navodila za uporabo aplikacije mlist - neposredni mentorji za Zdravniško zbornico Slovenije pripravila Gooya, interaktivni mediji, d.o.o. Ljubljana, m Navodila za uporabo aplikacije mlist - neposredni mentorji za Zdravniško zbornico Slovenije pripravila Gooya, interaktivni mediji, d.o.o. Ljubljana, marec 2019 Vsebina 1 Dostop do aplikacije... 3 1.1 Android...

Prikaži več

PRAVILNIK O TUTORSKEM SISTEMU NA FILOZOFSKI FAKULTETI

PRAVILNIK O TUTORSKEM SISTEMU NA FILOZOFSKI FAKULTETI PRAVILNIK O TUTORSKEM SISTEMU NA FILOZOFSKI FAKULTETI 1. SPLOŠNE DOLOČBE 1. člen S tem pravilnikom je urejeno organiziranje in delovanje tutorskega sistema na Filozofski fakulteti v Ljubljani (v nadaljevanju:

Prikaži več

DELEGIRANA UREDBA KOMISIJE (EU) 2016/ z dne 2. junija o dopolnitvi Uredbe (EU) št. 600/ Evropskega parlamenta i

DELEGIRANA  UREDBA  KOMISIJE  (EU)  2016/ z dne  2.  junija o dopolnitvi  Uredbe  (EU)  št.  600/ Evropskega  parlamenta  i L 313/6 DELEGIRANA UREDBA KOMISIJE (EU) 2016/2021 z dne 2. junija 2016 o dopolnitvi Uredbe (EU) št. 600/2014 Evropskega parlamenta in Sveta o trgih finančnih instrumentov v zvezi z regulativnimi tehničnimi

Prikaži več

Microsoft Word - PRzjn-2.doc

Microsoft Word - PRzjn-2.doc Na podlagi 24. člena Zakona o javnem naročanju (Ur. l. RS, št. 128/06) (v nadaljevanju ZJN-2), in 33. člena Statuta Občine Vrhnika (Ur. l. RS, št. 99/99, 39/00 36/01 in 77/06) izdajam naslednji P R A V

Prikaži več

PROJECT OVERVIEW page 1

PROJECT OVERVIEW page 1 N A Č R T P R O J E K T A : P R E G L E D stran 1 Ime projekta: Ustvarjanje s stripom Predmet/i: Slovenščina Avtorja/i projekta: Jasmina Hatič, Rosana Šenk Učitelj/i: Učitelji razrednega pouka Trajanje:

Prikaži več

Povzetek analize anket za študijsko leto 2012/2013 Direktor Andrej Geršak Povzetek letnega poročila je objavljen na spletni strani Celje,

Povzetek analize anket za študijsko leto 2012/2013 Direktor Andrej Geršak Povzetek letnega poročila je objavljen na spletni strani   Celje, Povzetek analize anket za študijsko leto 2012/2013 Direktor Andrej Geršak Povzetek letnega poročila je objavljen na spletni strani www.fkpv.si. Celje, marec 2014 Kazalo vsebine 1 UVOD... 1 1.1 Odzivnost

Prikaži več

Opozorilo: Neuradno prečiščeno besedilo predpisa predstavlja zgolj informativni delovni pripomoček, glede katerega organ ne jamči odškodninsko ali kak

Opozorilo: Neuradno prečiščeno besedilo predpisa predstavlja zgolj informativni delovni pripomoček, glede katerega organ ne jamči odškodninsko ali kak Opozorilo: Neuradno prečiščeno besedilo predpisa predstavlja zgolj informativni delovni pripomoček, glede katerega organ ne jamči odškodninsko ali kako drugače. Neuradno prečiščeno besedilo Pravilnika

Prikaži več

AKCIJSKO RAZISKOVANJE INOVACIJSKI PROJEKT ZA ZNANJE IN SPOŠTOVANJE Udeleženci: Učenci 2. c Razredničarka: Irena Železnik, prof. Učni predmet: MAT Učna

AKCIJSKO RAZISKOVANJE INOVACIJSKI PROJEKT ZA ZNANJE IN SPOŠTOVANJE Udeleženci: Učenci 2. c Razredničarka: Irena Železnik, prof. Učni predmet: MAT Učna AKCIJSKO RAZISKOVANJE INOVACIJSKI PROJEKT ZA ZNANJE IN SPOŠTOVANJE Udeleženci: Učenci 2. c Razredničarka: Irena Železnik, prof. Učni predmet: MAT Učna vsebina: Ustno seštevanje in odštevanje do 20 sprehodom

Prikaži več

Microsoft PowerPoint - Lapajne&Randl2015.pptx

Microsoft PowerPoint - Lapajne&Randl2015.pptx RAZISKAVA OB PREDVIDENI SELITVI KNJIŽNIC OHK Raziskava je potekala v okviru predmetov Raziskovalne metode in Uporabniki informacijskih virov in storitev pod mentorstvom treh profesorjev (dr. Pisanski,

Prikaži več

Diapozitiv 1

Diapozitiv 1 Ključne kompetence za uspešno delo knjižničarja Kako jih razvijati? Dr. Vlasta Zabukovec Oddelek za bibliotekarstvo, informacijsko znanost in knjigarstvo FF, UL Kompetence Študij, vseživljenjsko učenje

Prikaži več

Zbor vodnikov Planinske zveze Slovenije, je na podlagi 12

Zbor vodnikov Planinske zveze Slovenije, je na podlagi 12 Zbor vodnikov Planinske zveze Slovenije, je na podlagi 12. člena Pravilnika o organiziranosti vodnikov Planinske zveze Slovenije, dne 29. 11. 2003 sprejel in 21. 11. 2008 potrdil spremembe ter Zbor predstavnikov

Prikaži več

Komisija za Čopove diplome in priznanja pri ZBDS je na svoji seji dne 5

Komisija za Čopove diplome in priznanja pri ZBDS je na svoji seji dne 5 Na podlagi določil 33., 98. in 120. člena Statuta Zveze bibliotekarskih društev Slovenije (v nadaljevanju Zveza) je Občni zbor Zveze na svoji redni seji dne 10. 5. 2011 sprejel PRAVILNIK O PODELJEVANJU

Prikaži več

IND/L Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 97/2013) Spor

IND/L Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 97/2013) Spor IND/L Zakon o državni statistiki (Uradni list RS, št. 45/1995 in št. 9/2001) Letni program statističnih raziskovanj (Uradni list RS, št. 97/2013) Sporočanje podatkov je obvezno. Vprašalnik za statistično

Prikaži več

Microsoft Word - UP_Lekcija04_2014.docx

Microsoft Word - UP_Lekcija04_2014.docx 4. Zanka while Zanke pri programiranju uporabljamo, kadar moramo stavek ali skupino stavkov izvršiti večkrat zaporedoma. Namesto, da iste (ali podobne) stavke pišemo n-krat, jih napišemo samo enkrat in

Prikaži več

PowerPoint Presentation

PowerPoint Presentation DRŽAVNOZBORSKE VOLITVE Ljubljana, 3. 5. OGLAŠEVANJE MED INFORMATIVNIM PROGRAMOM 1 Naročnik: Stranka Ime akcije: Datum ponudbe: maj Časovni pas Št. 15'' oglasov Cena POP TV Med 24ur Popoldne 17h 10 Med

Prikaži več

Ime in priimek: Vpisna št: FAKULTETA ZA MATEMATIKO IN FIZIKO Oddelek za matematiko Verjetnost Pisni izpit 5. februar 2018 Navodila Pazljivo preberite

Ime in priimek: Vpisna št: FAKULTETA ZA MATEMATIKO IN FIZIKO Oddelek za matematiko Verjetnost Pisni izpit 5. februar 2018 Navodila Pazljivo preberite Ime in priimek: Vpisna št: FAKULTETA ZA MATEMATIKO IN FIZIKO Oddelek za matematiko Verjetnost Pisni izpit 5 februar 018 Navodila Pazljivo preberite besedilo naloge, preden se lotite reševanja Nalog je

Prikaži več

Microsoft Word - FREM-2010-prispevek-obratna-sredstva-oktober-2008

Microsoft Word - FREM-2010-prispevek-obratna-sredstva-oktober-2008 NAČRTOVANJE UREJENOSTI ORGANIZACIJE Mirko Jenko mirko.jenko@t-2.net 1. Povzetek Prispevek je poslovni projekt iz prakse, s katerim želimo prenoviti organizacijski ustroj organizacije in spremljanje stroškov.

Prikaži več

TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM NAVODILA ZA REGISTRACIJO IN PRIJAVO Ljubljana, Verzija 1.1

TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM NAVODILA ZA REGISTRACIJO IN PRIJAVO Ljubljana, Verzija 1.1 TRGOVSKI PORTAL SPLETNA APLIKACIJA NAMENJENA TRGOVCEM NAVODILA ZA REGISTRACIJO IN PRIJAVO Ljubljana, 14. 03.2019 Verzija 1.1 KAZALO 1 NAMEN...3 2 REGISTRACIJA...4 3 VNOS GESLA IN AKTIVACIJA RAČUNA...6

Prikaži več

Navodila za programsko opremo FeriX Namestitev na trdi disk Avtor navodil: Martin Terbuc Datum: December 2007 Center odprte kode Slovenije Spletna str

Navodila za programsko opremo FeriX Namestitev na trdi disk Avtor navodil: Martin Terbuc Datum: December 2007 Center odprte kode Slovenije Spletna str Navodila za programsko opremo FeriX Namestitev na trdi disk Avtor navodil: Martin Terbuc Datum: December 2007 Center odprte kode Slovenije Spletna stran: http://www.coks.si/ Elektronski naslov: podpora@coks.si

Prikaži več

PowerPoint Presentation

PowerPoint Presentation Upravljanje tveganj nabave VSEBINA predavanj Opredelitev TVEGANJ, njihovih OBLIK in VZROKOV Upravljanje tveganja PRISTOPI in STRATEGIJE upravljanja tveganj METODE ublažitve tveganj Primer analize tveganja.

Prikaži več

NAVODILA ZA IZPOLNJEVANJE OBRAZCA

NAVODILA ZA IZPOLNJEVANJE OBRAZCA NAVODILO ZA UPORABO PRIPOMOČKA ZA PRIPRAVO STROŠKOVNEGA NAČRTA PROJEKTA»Piano finanziario Stroskovni nacrt«dokument»piano finanziario Stroskovni nacrt«v Microsoft Excel obliki lahko uporabite kot pripomoček

Prikaži več

OD PROJEKTNE IDEJE DO NAČRTA Priročnik za pripravo projektnih načrtov študijsko leto 2011/2012 Pripravila: Romana Zidar

OD PROJEKTNE IDEJE DO NAČRTA Priročnik za pripravo projektnih načrtov študijsko leto 2011/2012 Pripravila: Romana Zidar OD PROJEKTNE IDEJE DO NAČRTA Priročnik za pripravo projektnih načrtov študijsko leto 2011/2012 Pripravila: Romana Zidar Uvod Za uspešno delo v socialnem delu morate osvojiti kompetence s področja projektnega

Prikaži več

KAKO NA BORZI TRGOVATI ON-LINE? Maksimiziranje potencialnega dobička skozi vsak posel na borzi

KAKO NA BORZI TRGOVATI ON-LINE? Maksimiziranje potencialnega dobička skozi vsak posel na borzi Blokchain in kriptovalute: naložbena priložnost ali balon? Domen Granda, finančni analitik 1 Bitcoin v praksi Janez uporabi bitcoin za nakup kave v kavarni. Informacija o transakciji je prek omrežja poslana

Prikaži več

Univerzitetni študijski program Fizika I

Univerzitetni študijski program Fizika I Medicinska fizika II. stopnja 1. Splošni podatki o študijskem programu Ime študija: Magistrski študijski program Medicinska fizika. Stopnja študija: Druga bolonjska stopnja. Vrsta študija: Enopredmetni

Prikaži več

20. andragoški kolokvij

20. andragoški kolokvij 21. andragoški kolokvij in sklepni dogodek projekta EPUO Neformalno izobraževanje odraslih kot strategija odzivanja na spremembe 3. in 4. oktober 2017 Stavba Vertikala (Pipistrel Vertical Solutions), Vipavska

Prikaži več

PKP projekt SMART WaterNet_Opis

PKP projekt SMART WaterNet_Opis PKP projekt SMART WaterNet Po kreativni poti do znanja (PKP) opis programa Program Po kreativni poti do znanja omogoča povezovanje visokošolskih zavodov s trgom dela in tako daje možnost študentom za pridobitev

Prikaži več

N

N Državni izpitni center *N15164132* 9. razred TEHNIKA IN TEHNOLOGIJA Ponedeljek, 11. maj 2015 NAVODILA ZA VREDNOTENJE NACIONALNO PREVERJANJE ZNANJA 9. razred RIC 2015 2 N151-641-3-2 SPLOŠNA NAVODILA Prosimo,

Prikaži več

Microsoft Word - navodila_k_ceniku_2005_06_cistopis-1.doc

Microsoft Word - navodila_k_ceniku_2005_06_cistopis-1.doc NAVODILA K CENIKU ZA ŠTUDIJSKO LETO 2005/2006 UL FAKULTETE ZA POMORSTVO IN PROMET Šolnine in prispevke za študijsko leto 2005/2006 je določil Upravni odbor Fakultete za pomorstvo in promet na svoji 22.

Prikaži več

Pravilnost podatkov, navedenih v vlogi, bo

Pravilnost podatkov, navedenih v vlogi, bo Pravilnost podatkov, navedenih v vlogi, bo Šolsko leto: / preverila komisija za sprejem otrok v vrtec pri upravljavcih zbirk osebnih podatkov, ki Datum oddaje vloge: / jih vodijo v skladu z zakonom. Šifra

Prikaži več