UNIVERZA V LJUBLJANI

EKONOMSKA FAKULTETA

MAGISTRSKO DELO

UPORABA AGILNE METODOLOGIJE »SCRUM«

PRI RAZVOJU DRŽAVNEGA PORTALA

ZA POSLOVNE SUBJEKTE

Ljubljana, oktober 2011 MANJA ROJKO

IZJAVA

Študentka Manja Rojko izjavljam, da sem avtorica tega magistrskega dela, ki sem ga

napisala v soglasju s svetovalcem prof. dr. Mira Gradišarja in da v skladu s 1. odstavkom

21. člena Zakona o avtorskih in sorodnih pravicah dovolim njegovo objavo na fakultetnih

spletnih straneh.

V Ljubljani, dne 27.10.2011 Podpis:

i

KAZALO

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

1 IZBIRA IN UPORABA METODOLOGIJE RAZVOJA

INFORMACIJSKEGA SISTEMA .................................................................................. 5

1.1 Metodologija razvoja ................................................................................................. 5

1.2 Kaj vpliva na izbiro metodologije ............................................................................. 6

1.2.1 Delitev glede na tip metodologije ...................................................................... 7

1.2.2 Delitev glede na težo metodologije ................................................................. 10

1.2.3 Delitev glede na utežitev metodologije ........................................................... 11

2 AGILNE METODOLOGIJE ........................................................................................ 13

2.1 Glavna načela agilnih metodologij .......................................................................... 13

2.1.1 Posamezniki in njihova komunikacija so pomembnejši kot procesi in orodja 13

2.1.2 Delujoča programska oprema je pomembnejša kot popolna dokumentacija .. 14

2.1.3 Sodelovanje uporabnika je pomembnejše kot pogajanje na osnovi pogodb ... 14

2.1.4 Upoštevanje sprememb je pomembnejše od sledenja načrtu .......................... 14

2.2 Vrste agilnih metodologij ........................................................................................ 15

2.2.1 Ekstremno programiranje (XP) ....................................................................... 15

2.2.2 Metoda DSDM ................................................................................................ 17

2.2.3 Metoda FDD .................................................................................................... 19

2.2.4 Metoda ASD .................................................................................................... 20

2.2.5 Crystal Clear .................................................................................................... 21

2.2.6 Scrum ............................................................................................................... 21

3 PRIMERJAVA TRADICIONALNE Z AGILNIMI METODOLOGIJAMI ........... 22

3.1 Karakteristike tradicionalnih metodologij ............................................................... 23

3.2 Karakteristike agilnih metodologij .......................................................................... 24

3.3 Omejitve tradicionalnih metodologij ....................................................................... 25

3.4 Omejitve agilnih metodologij .................................................................................. 26

3.5 Primerjava tradicionalne z agilnimi metodologijami .............................................. 28

3.5.1 Velikost projekta ............................................................................................. 29

3.5.2 Ljudje ............................................................................................................... 31

3.5.3 Tveganje .......................................................................................................... 32

4 PREDSTAVITEV METODOLOGIJE SCRUM ......................................................... 33

4.1 Opis metodologije ................................................................................................... 34

4.2 Struktura metodologije Scrum ................................................................................. 37

4.2.1 Načrtovanje in določitev arhitekture sistema .................................................. 37

4.2.2 Iteracija sprinta (iteracija teka) ........................................................................ 38

4.2.3 Zaključek in priprava na naslednji projekt ...................................................... 39

4.3 Dostava končnega izdelka ....................................................................................... 39

4.4 Vloge in odgovornosti ............................................................................................. 39

4.5 Proces razvoja po metodologiji Scrum .................................................................... 40

ii

4.5.1 Vizija ............................................................................................................... 41

4.5.2 Seznam zahtev ................................................................................................. 41

4.5.3 Sprint ............................................................................................................... 42

4.5.4 Sestanki ............................................................................................................ 42

4.5.5 Izdelki Scrum ................................................................................................... 43

4.6 Prednosti in slabosti Scrum ..................................................................................... 45

4.6.1 Prednosti Scrum ............................................................................................... 46

4.6.2 Slabosti Scrum ................................................................................................. 47

5 DOSEDANJE VODENJE RAZVOJA DRŽAVNEGA PORTALA ZA

POSLOVNE SUBJEKTE ............................................................................................... 48

5.1 Projektna organiziranost .......................................................................................... 48

5.2 Življenjski cikel vodenja projektov ......................................................................... 50

5.2.1 Vzpostavitev projekta ...................................................................................... 50

5.2.2 Načrtovanje projekta........................................................................................ 50

5.2.3 Izvajanje projekta ............................................................................................ 50

5.2.4 Zaključevanje projekta .................................................................................... 51

5.3 Proces razvoja informacijskih rešitev ...................................................................... 52

5.3.1 Določitev zahtev .............................................................................................. 52

5.3.2 Analiza ............................................................................................................. 53

5.3.3 Zagotovitev pogojev za izvedbo ...................................................................... 53

5.3.4 Načrtovanje ...................................................................................................... 54

5.3.5 Izgradnja .......................................................................................................... 54

5.3.6 Integracija in testiranje .................................................................................... 55

5.3.7 Izvedba............................................................................................................. 56

6 UPORABA AGILNE METODE SCRUM PRI RAZVOJU DRŽAVNEGA

PORTALA ZA POSLOVNE SUBJEKTE .................................................................... 56

6.1 Organizacijske spremembe pri prevzemanju agilne prakse .................................... 56

6.1.1 Spremembe v organizacijski kulturi ................................................................ 56

6.1.2 Spremembe v načinu vodenja .......................................................................... 57

6.1.3 Spremembe glede upravljanja znanja .............................................................. 57

6.1.4 Sprememba razvojnega procesa ...................................................................... 57

6.2 Velikost projekta ..................................................................................................... 58

6.3 Praktični vidiki uporabe nove metodologije ............................................................ 58

6.4 Prenovljen proces metodologije razvoja državnega portala za

poslovne subjekte ..................................................................................................... 59

6.4.1 Začetek projekta .............................................................................................. 60

6.4.2 Analiza ............................................................................................................. 60

6.4.3 Oblikovanje ..................................................................................................... 62

6.4.4 Postopen razvoj programske rešitve ................................................................ 62

6.4.5 Mejniki in zaključek projekta .......................................................................... 67

6.4.6 Vzdrževanje in podpora uporabnikom ............................................................ 67

iii

6.5 Dokumentacija ......................................................................................................... 67

6.6 SWOT analiza vpeljave nove metodologije razvoja ............................................... 68

6.6.1 Prednosti vpeljave metodologije Scrum .......................................................... 69

6.6.2 Slabosti vpeljave metodologije Scrum ............................................................ 70

6.6.3 Priložnosti vpeljave metodologije Scrum ........................................................ 71

6.6.4 Nevarnosti vpeljave metodologije Scrum ....................................................... 71

SKLEP ................................................................................................................................ 73

LITERATURA IN VIRI ................................................................................................... 76

iv

KAZALO SLIK

Slika 1: Prisotnost dejavnikov, ki vplivajo na razvoj informacijskega sistema .................... 7

Slika 2: Delitev metodologij glede na tip .............................................................................. 8

Slika 3: Določitev teže metodologije................................................................................... 10

Slika 4: Življenjski cikel XP procesa .................................................................................. 17

Slika 5: Življenjski cikel procesa DSDM ............................................................................ 18

Slika 6: Aktivnosti metodologije FDD ................................................................................ 20

Slika 7: Življenjski cikel po metodologiji ASD .................................................................. 20

Slika 8: Problem velikosti projekta in vpliv metodologije na število ljudi ......................... 30

Slika 9: Učinki glede na velikost projekta ........................................................................... 31

Slika 10: Scrum proces ........................................................................................................ 37

Slika 11: Pregled procesa razvoja po metodologiji Scrum .................................................. 41

Slika 12: Sestava seznama zahtev ....................................................................................... 43

Slika 13: Padajoči graf Scrum ............................................................................................. 44

Slika 14: Primer plana sprinta Scrum .................................................................................. 45

Slika 15: Prenovljen razvojni proces programske rešitve ................................................... 59

Slika 16: SWOT analiza vpeljave metodologije Scrum ...................................................... 68

KAZALO TABEL

Tabela 1: Primerjava tradicionalne z agilnimi metodologijami .......................................... 29

Tabela 2: Projektne značilnosti agilnih in tradicionalnih metodologij ................................ 32

Tabela 3: Vloge na projektu in njihove odgovornosti ......................................................... 48

1

UVOD

Opredelitev problema. Metodologijo lahko na splošno opredelimo kot: »...skupek

postopkov, tehnik, orodij in pripomočkov za dokumentiranje, ki koristijo razvijalcem

sistema pri njihovem prizadevanju implementirati nov informacijski sistem. Metodologijo

sestavljajo faze, ki so same sestavljene iz podfaz in ki vodijo razvijalce sistema pri izbiri

tehnik, ki so primerne v vsaki fazi projekta, ter jim pomagajo načrtovati, upravljati,

kontrolirati in ocenjevati projekte razvoja informacijskih sistemov.« (Avison & Fitzgerald,

1996, str. 10).

V primeru razvoja informacijskega sistema ali programske opreme metodologija ne

pomeni zgolj postopkov, ki so neposredno povezani z razvojem (na primer. analiza,

načrtovanje itn.), temveč zajema tudi podporne postopke, načine kom

unikacije med sodelujočimi, pravila odločanja itn. Glede na to lahko metodologijo

opredelimo tudi kot množico dogovorov, ki jih sprejme projektna skupina/organizacija.

Obstajajo številne formalne metodologije, ki temeljijo na preizkušenih postopkih, ki so se

v praksi izkazali kot dobri. Vendar si jih organizacije pri prevzemu vedno prilagodijo po

svoji meri, tako da ustrezajo njihovemu načinu dela ter percepciji domene, za katero so

vzpostavljene (Bajec & Krisper, 2003, str. 2).

Skozi čas so se pojavile različne metodologije razvoja informacijskih sistemov in

programske opreme. Njihov namen je bil odpraviti prepad med kupci oziroma naročniki in

dobavitelji/izvajalci. Prve metodologije so temeljile na jasno definiranih postopkih, ki

vodijo delo razvijalcev tako, da poskušajo analizirati čim večji del potreb naročnika in jih

nato implementirati kot funkcionalnosti v informacijsko rešitev. Vendar se pri vseh

podjetjih takšen pristop ni izkazal za uspešnega. Vse bolj je postajalo jasno, da sledenje

okornim postopkom in ustvarjanje velikih količin dokumentov, ki opisujejo delovanje

sistema, ne more zagotoviti dobre rešitve v poslovnem okolju, v katerem se posamezni

parametri nenehno spreminjajo. Kljub kakovosti, ki jo takšne metodologije navadno

dosegajo, je njihova uporaba v praksi omejena, saj jim z željo po čimprejšnjih rezultatih

težko sledimo.

Kot rezultat in odgovor na celovite, večinoma težko obvladljive metodologije, ki proces

razvoja predpišejo do vsake najmanjše podrobnosti, se pojavi nov pojem »agilnost«. Novi

trendi priporočajo zasnovo in uporabo prilagodljivih metodologij, ki so predpisljive v

ravno pravšnji meri ter so hitro in enostavno prilagodljive. Tudi agilni razvoj ni

univerzalna rešitev mnogih težav pri razvoju informacijskih sistemov. Le-ta deluje najbolje

tam, kjer je poslovno okolje turbulentno, kjer se specifikacije in zahteve naročnika

nenehno spreminjajo in tam, kjer so razvojne skupine razmeroma majhne (Bajec &

Krisper, 2003, str. 1).

2

Pobudniki in razvijalci agilne metodologije so sestavili seznam skupnih značilnosti, ki

uvrščajo določeno metodologijo med agilne. Te značilnosti so iteracija (vključuje poskus

in napako); kratek cikel razvoja (nekaj dni do nekaj tednov); minimalno delo in

preprostost; preglednost (Emergence) – sinergija, samoorganizacija, podporno okolje;

dojemanje rizika kot priložnosti; osredotočenost na ljudi (uporabnik, tim, dobri ljudje);

sodelovanje in komunikacija ter dovolj velika agilnost za odziv na turbulentno in

spreminjajoče se okolje (Dalcher, 2006, str. 12). Čeprav se agilni pristop najbolje odziva

pri projektih, kjer so težave, ki nastajajo, hitre, spremenljive in nestanovitne (Highsmith &

Cockburn, 2002), agilni manifest podpira tudi dokumentiranje, vendar le v obsegu

uporabnosti. Agilni manifest prav tako bolj poudarja ljudi kot zgolj proces in orodja

razvoja; delujoč program bolj kot popolno dokumentacijo; sodelovanje z naročnikom bolj

kot pogajanja na osnovi pogodb in prožnost pri spremembah bolj kot slepo sledenje

začrtanemu planu (Agile manifesto, 2010).

Med agilne metodologije uvrščamo tudi Scrum, ki se je razvila za uspešnejše upravljanje

projektnega dela razvojnega procesa. Scrum poudarja prožnost, prilagodljivost,

ustvarjalnost in ne določa uporabe specifične tehnike pri razvoju. Omejuje se le na delo

posameznika v skupini za doseg nekega cilja, ki je agilni razvoj v stalno spreminjajočem se

okolju zahtev. Scrum je empirična tehnika vodenja, za katero je realnost pomembnejša od

načrtov in pri kateri je potrebno nenehno sodelovanje, zaupanje v ljudi in napredek.

Metodologija združuje vse skupne lastnosti agilnih metodologij, njena posebnost pa je

organizacija ter izvajanje vodenja in hkrati obvladovanje projektnega tima. Uporaba

metode Scrum temelji na realizaciji realno mogočega, dnevnega preverjanja napredka in

pogostih korektur. Bistvo metode so majhni projektni timi z največ deset ljudi, serija

sprintov, vidne in uporabne nadgradnje ter časovno omejevanje (Schwaber & Beedle,

2002).

Državni portal za poslovne subjekte je projekt, ki ga je razpisala Državna uprava. To

pomeni, da mora razvoj omenjenega informacijskega sistema oziroma informacijske

rešitve potekati po metodologiji, ki je določena s strani Državne uprave Republike

Slovenije. Le-ta je v letu 2000 določila enotno metodologijo za razvojne projekte

informacijskih sistemov, poimenovano EMRIS. EMRIS je nastal iz potrebe po enotnem,

urejenem, sistematičnem in celovitem pristopu k razvoju informacijskih sistemov v okviru

državne uprave. Skupaj z Metodologijo vodenja projektov v državni upravi za področje

informacijske tehnologije (MVPDU/IT) predstavlja podlago za obvladovanje projektov

izdelave strateških planov informacijskih sistemov in projektov razvoja informacijskih

sistemov. EMRIS je referenčna metodologija, ki poleg metodoloških opisov predstavlja

tudi podrobno opisani proces razvoja. Ta preko faz, aktivnosti in opravil podrobno

predstavlja bogat nabor izdelkov, ki morajo nastati v okviru razvoja informacijskega

sistema. S tem pa tudi opozarja na vse elemente, za katere je potrebno poskrbeti v okviru

razvoja informacijskega sistema. Metodologija EMRIS nudi celovito metodološko podporo

3

za celoten življenjski cikel informacijskega sistema, ki poteka v smeri: zasnova, razvoj,

vpeljava in vzdrževanje. Seveda pa je od posameznega projekta odvisno kakšen pristop,

kateri postopki, opravila in kako podrobno bodo na konkretnem projektu uporabljeni.

Uporabo agilnih konceptov tako priporoča tudi EMRIS, saj se s tem lahko doseže, da se

bodo v okviru projekta razvoja izvajala le tista opravila in v takšnem obsegu, ki bodo v

trenutnih okoliščinah projekta dejansko prispevala h končnemu rezultatu (Zrnec, Vavpotič,

Rupnik, Bajec & Krisper, 2004, str. 1–2).

Odločitev glede izbire metodologije vodenja projekta pred začetkom njegovega izvajanja

je zelo pomembna, saj je od izbire metodologije odvisen predvsem način vodenja in

poročanja tako naročniku kot tudi upravi podjetja. V našem primeru je izbira metodologije

pogojena z metodologijo naročnika projekta in z ustaljenim načinom dela v organizaciji.

Izbira metodologije vodenja ni odločitev vodje projekta, saj bi bilo za podjetje

neobvladljivo, če bi vsak vodja projekta vodil projekt po svoji izbrani metodologiji. To bi

predvsem povzročilo neenotnost poročanja vodstvu podjetja ter težave v primeru

nadomeščanja odsotnosti. Poleg tega se projekti razlikujejo tudi glede organizacije in

vodenja ter imajo tudi različne cilje.

V podjetju SRC d.o.o. je vodja projekta pri izbiri metodologije projekta pri razvoju sistema

e-VEM omejen tudi z metodologijo vodenja, ki se uporablja v podjetju in je za vse projekte

obvezujoča. Metodologija se imenuje Metodologija vodenja projektov (v nadaljevanju

MVP) in sloni na temeljih institucije Project management Institute (v nadaljevanju PMI) in

Project Management Body of Knowledge (v nadaljevanju PMBOK) kot osnovnem viru. Iz

tega razloga je metodologija MVP tudi najbolj podobna in primerljiva z metodologijo

PMBOK. Na drugi strani pa vodjo omenjenega projekta obvezuje tudi enotna metodologija

razvoja informacijskih sistemov (v nadaljevanju EMRIS), ki jo je določil naročnik.

Izvedba projekta je običajno vezana na kratek rok in jo zaznamuje precejšnje število

neznank. Iz tega razloga je potrebno izbrati metodologijo, ki bo omogočala čim boljše in

hitrejše prilagajanje, ter čim bolj zadovoljila zahteve naročnika.

Namen in cilji dela. Z magistrskim delom želim analizirati stanje in trenutni način vodenja

razvoja informacijskih projektov in predstaviti razloge, ki vodijo k vpeljavi nove, agilne

metodologije razvoja informacijskega sistema. Prav tako pa želim tudi predstaviti način

uporabe nove metodologije na konkretnem projektu.

Namen magistrskega dela je predstaviti teoretične osnove in različne metode razvoja

informacijskih sistemov in programskih rešitev ter ugotoviti, ali se lahko prvine in metode

agilnega razvoja uporabijo na primeru nadaljnjega razvoja Državnega portala za poslovne

subjekte (e-VEM). Z uvedbo oziroma sintezo agilnega razvoja in sedanje standardne

4

metodologije želim namreč doseči boljšo zadovoljitev naročnika, večjo prilagodljivost,

hitrejši razvoj in boljšo upravičenost stroškov, povezanih z razvojem informacijskega

sistema oz. programske rešitve.

Končni cilj magistrskega dela je vpeljava metodologije razvoja Državnega portala za

poslovne subjekte (e-VEM), ki temelji na agilnem pristopu SCRUM.

Metode dela. Pri izdelavi magistrske naloge bom uporabila znanje, pridobljeno med

študijem in znanje, ki sem ga pridobila na delovnem mestu. Teoretično znanje bom tako

podprla z lastnimi izkušnjami, ki sem jih glede izbrane tematike pridobila pri izvajanju

vsakodnevnih nalog na delovnem mestu. V pomoč mi bo tudi trenutno dostopna tiskana in

spletna literatura ter interni viri podjetja z obravnavanega področja.

Pri pripravi magistrskega dela se bom v praktičnem delu omejila na konkretni projekt

razvoja portala za poslovne subjekte (e-VEM).

V prvem delu bom uporabila deskriptivno metodo na podlagi domače in tuje literature ter

člankov in na podlagi lastnih izkušenj. V pomoč mi bodo tudi interni viri, ki so nastali v

podjetju, ki je predstavljeno v magistrskem delu.

S komparativno metodo in metodo kritične analize bom primerjala klasične in agilne

metodologije razvoja programske opreme. Primerjala bom tudi obstoječo metodo vodenja

razvoja programske opreme, ki se trenutno uporablja v podjetju, z agilno metodo Scrum.

Uporabila bom tudi metodo sinteze, s katero bom oblikovala način vpeljave nove

metodologije.

Celotna magistrska naloga bo razdeljena na tri dele.

V prvem delu bom podala teoretična izhodišča, temelječa na podlagi prebiranja strokovne

domače in tuje literature ter prispevkih in člankih na temo obstoječih metodologij razvoja

informacijskega sistema in programske opreme.

V drugem delu bom predstavila metodologijo razvoja portala za poslovne subjekte (e-

VEM), ki se v podjetju uporablja sedaj.

V tretjem delu bom obravnavala praktični primer uvedbe nove metodologije razvoja

programske rešitve preko vseh potrebnih faz. Na koncu bom podala še ugotovitve glede

prednosti, slabosti, priložnosti in nevarnosti uporabe nove metodologije vodenja razvoja

programske opreme.

5

1 IZBIRA IN UPORABA METODOLOGIJE RAZVOJA

INFORMACIJSKEGA SISTEMA

1.1 Metodologija razvoja

Metodologija je skupek vsega kar počnemo s ciljem doseči želeni rezultat. V primeru

razvoja metodologija predstavlja postopke, ki so neposredno povezani z razvojem (sem

spadajo analiza, načrtovanje,...) kakor tudi podporne postopke, komunikacijo med

sodelujočimi, pravila odločanja, itn. Metodologija vsebuje tudi sociološko komponento, ki

se izkazuje preko filozofije, načel, idej in pogledov organizacije in njenih zaposlenih.

Metodologija je namreč odvisna tudi od ljudi (Bajec, & Krisper, 2003, str. 2).

Cockburn (2002) je izpeljal definicijo metodologije za razvoj programske opreme.

Metodologijo razvoja je tako opredelil kot skupek postopkov znotraj neke discipline, ki se

pri razvoju programske opreme uporabijo večkrat in zajemajo več področij (projektno

vodenje, analiza, specifikacija, razvoj, koordiniranje, testiranje, ipd.).

Avison in Fitzgerald (1995) ugotavljata, da je metodologija več kot le skupek njenih

sestavin in da je osnovana na nekem filozofskem pogledu. Sicer pa se metodologija ne

razlikuje od metode. Metodologije se lahko med seboj razlikujejo v posameznih tehnikah,

ki jih priporočajo, v postopkih, ki jih predpisujejo ali v vsebini posamezne faze. Včasih pa

gre celo za bolj fundamentalne razlike. Nekatere metodologije poudarjajo človeške vidike

razvoja informacijskih sistemov, druge so bolj osredotočene na znanstveni pristop.

Nekatere so pragmatične, spet druge skušajo avtomatizirati čim več dela pri razvoju

projekta. Različne metodologije lahko sledijo različnim ciljem, kot so na primer (Avison &

Fitzgerald, 1995, str. 11):

Natančno zabeležiti zahteve informacijskega sistema. Metodologija pomaga

uporabnikom določiti njihove zahteve in funkcionalne potrebe. Razvijalci sistema

preučujejo in analizirajo uporabniške zahteve.

Določiti sistematično metodo razvoja, kjer se lahko napredek učinkovito meri in

opazuje. Težave pri velikih projektih, ki niso izvedeni v rokih, lahko podjetju

povzročijo finančne stroške ali privedejo do drugih posledic za podjetje. K učinkovitosti

tehnik načrtovanja projekta pripomorejo dobro načrtovane faze razvoja in vmesni cilji v

metodologiji.

Izdelava informacijskega sistema v okviru časovnega roka pri sprejemljivih stroških.

Čas namenjen posameznim tehnikam naj bo omejen, sicer je mogoče iskanju popolnosti

posvetiti ogromno časa (Kovačič, 1998, str. 90).

Izdelava sistema, ki je dobro dokumentiran in ga je preprosto vzdrževati. Spremembe v

organizaciji in njenem okolju lahko posledično pomenijo nadaljnji razvoj in

6

modifikacijo informacijskega sistema. Dobra dokumentacija omogoča izvedbo

modifikacij sistema z najmanj vpliva na druge dele sistema.

Ugotoviti spremembe, ki jim bo potrebno slediti čim bolj zgodaj v procesu razvoja

sistema. S tem, ko razvoj sistema napreduje skozi faze analize in načrtovanja do faze

implementacije, se stroški, povezani s spremembami sistema, povečujejo. Prej ko

realiziramo spremembe, manjši so stroški projekta.

Izdelava sistema, ki ustreza ljudem, na katere sistem vpliva. Bolj verjetno je, da bo

sistem bolj uspešen in da se bo bolj uporabljal, če bo ustrezal naročnikom, strankam,

managerjem, uporabnikom.

Naštetih je le nekaj primerov ciljev, katerim lahko metodologija sledi. Metodologija se

lahko osredotoča na več ciljev ali zgolj na enega. Pomembno pa je razumevanje, da se v

ozadju vsake metodologije nahaja neka ideja, ki nas usmerja pri delu, tako da določi

kvalitete informacijskega sistema, ki jih skušamo pri razvoju doseči.

1.2 Kaj vpliva na izbiro metodologije

Pred vsakim začetkom razvoja informacijskega sistema se je potrebno zavedati, da se ni

dovolj le ukvarjati s samim razvojem programske rešitve, temveč je potrebno upoštevati še

mnogo drugih faktorjev, ki vplivajo na končni uspeh informacijskega sistema. Prav tako je

potrebno upoštevati nakup ustrezne strojne opreme in že obstoječo programsko opremo.

Vedeti moramo kako bo potekala uvedba rešitve in kako se bo sistem vzdrževal. Vili

Podgorelec (2008) opozarja na številne druge dejavnike, ki nas ne smejo presenetiti. Na

Sliki 1 je ponazorjena prisotnost dejavnikov, ki vplivajo na razvoj informacijskega sistema.

Iz njega je vidno, da ima komunikacija pri razvoju najpomembnejšo vlogo in da samo

programiranje nima tolikšnega pomena, kot se morda zdi.

7

Slika 1: Prisotnost dejavnikov, ki vplivajo na razvoj informacijskega sistema

Vir: V. Podgorelec , Informacijski sistemi, Osnove razvoja IS, 2008, str. 3.

Izbira ustrezne metodologije je lahko ključnega pomena, zato njena izbira ne predstavlja

lahke naloge. Metodologija je odvisna od njenih uporabnikov, zato so se pojavili različni

načini delitev metodologij, ki pomagajo pri izbiri najustreznejše. Krisper, Rupnik, Bajec,

Rožanec, Zrnec in Vavpotič (2003) so metodologije razdelili v tri skupine in sicer glede

na:

tip metodologije,

utežitev metodologije,

težo metodologije.

1.2.1 Delitev glede na tip metodologije

Delitev temelji na podlagi filozofije metodologije, kjer sta upoštevani sociološka

komponenta in cilji metodologije. Tehnične metodologije se na podlagi uporabljenih

tehnik in vrste procesa nato delijo še naprej. Delitev metodologij glede na njihov tip je

prikazana na Sliki 2.

8

Slika 2: Delitev metodologij glede na tip

Vir: M. Krisper, R. Rupnik, in M. Bajec, Enotna metodologija razvoja informacijskih sistemov,

2003, 1. zvezek.

V skupino socio-tehničnih metodologij spadajo tiste metodologije, katerih cilj je

organizacijska rešitev. Sem lahko uvrstimo organizacijsko usmerjene metodologije in

metodologije, usmerjene v človeka. Omenjene metodologije se ne ukvarjajo samo s

tehnično platjo razvoja, ampak vključujejo, upoštevajo in dajejo poudarek na ljudi in

njihove lastnosti. Cilj takih metodologij je lahko tudi samo organizacijska rešitev in ne

nujno le programska. Take metodologije se uvrščajo med organizacijsko usmerjene.

Obstajajo pa metodologije, ki dajejo poudarek sociološki komponenti in jih tako uvrščamo

med metodologije, usmerjene v človeka.

Vse ostale metodologije, katerih poglavitni cilj je izgradnja programske rešitve, uvrščamo

med tehnične metodologije. Le-te so na podlagi tehnik in življenjskih ciklov podrobno

razdeljene.

Procesno usmerjene metodologije temeljijo na modeliranju procesov, pri čemer se

uporablja vrsta procesnih (na primer diagrami podatkovnih tokov, odločitvena drevesa,

akcijski diagrami) in strukturnih tehnik (na primer strukturni diagrami) ter slapovni

(zaporedni) življenjski cikel oziroma model. Iz procesno usmerjenih metodologij so se

9

nadalje razvile podatkovno-procesne metodologije z razlikovanjem, da je pri teh

metodologijah poudarek na podatkovnih tehnikah in modeliranju podatkov, prav tako pa

vključujejo tudi modeliranje procesov. Tudi te metodologije večinoma uporabljajo

slapovni (zaporedni) življenjski cikel oz. model z modifikacijami.

Objektno usmerjene metodologije se od procesnih in procesno-podatkovnih metodologij

bistveno razlikujejo. Te metodologije uporabljajo objektne tehnike in vključujejo izdelavo

prototipov ter podatkovne tehnike, ki omogočajo uporabo relacijskih podatkovnih baz.

Objektno usmerjene metodologije uporabljajo drugačen pristop k analizi in načrtovanju,

prav tako je potrebna uporaba drugačnih programskih jezikov in orodij. Te metodologije

težijo k poenotenju razvoja in so povezane z inkrementalno-iterativnim razvojem, ki

omogoča izgradnjo sistemov na osnovi obstoječih in že preizkušenih gradnikov. To

pomeni, da se posamezni izdelki izdelujejo v več iteracijah, vsaka naslednja iteracija pa

temelji na predhodni iteraciji, ki se jo dopolni in nadgradi. Objektni proces razvoja je tako

sestavljen iz več faz, znotraj katerih se izvajajo aktivnosti, ki so nadalje razdeljene še na

opravila.

Metodologije za hiter razvoj (angl. Rapid Application Development, v nadaljevanju

RAD) so nastale kot reakcija na hiter prehod na informacijsko tehnologijo, kar je

povzročilo hitro spreminjanje zahtev. Te metodologije uporabljajo posebne tehnike dela z

ljudmi (npr. programiranje v parih) in temeljijo na uporabi iterativno-inkrementalnega

življenjskega cikla in prototipiranja. Večji poudarek se daje implementaciji in testiranju

kakor analizi in načrtovanju. Take metodologije lahko tudi uporabljajo podatkovne,

procesne in objektne tehnike.

Metodologije, usmerjene v človeka, so nastale kot odgovor na metodologije, ki so se

osredotočale le na tehnični vidik razvoja programske opreme in poleg tehnološke

upoštevajo tudi sociološko komponento. To pomeni, da se v načrtovanje in v razvoj

programske rešitve vključi vse vpletene. Namen te metodologije je vključiti tako

neposredne uporabnike sistema kot tudi posredne (vodstvo organizacije, stranke,

dobavitelje, …)v proces odločanja o programski rešitvi. Metodologije, usmerjene v

človeka, navadno modelirajo celotno organizacijo, zato pogosto vključujejo tudi lastnosti

organizacijsko usmerjenih metodologij.

Organizacijsko usmerjene metodologije imajo idejo modeliranja organizacije kot celote

kar pomeni, da je rezultat lahko le organizacijska rešitev, ki lahko vključuje tudi

programsko rešitev. Te metodologije pogosto vsebujejo tudi sociološko komponento

(lastnosti metodologij, usmerjenih v človeka). Organizacije poleg organizacijskih tehnik za

modeliranje organizacije uporabljajo tudi tehnike podatkovno in procesno usmerjenih

metodologij ali celo tehnike objektno usmerjenih tehnologij.

10

1.2.2 Delitev glede na težo metodologije

Zaradi obsežnih formalnih metodologij so se začeli uveljavljati novi pristopi k razvoju

programske opreme. S tem se je pojavila tudi delitev metodologij glede na utežitev, ki so

lahko težke ali lahke. Teža metodologije je določena z njenim obsegom (število različnih

elementov, ki jih metodologija opisuje: številom aktivnosti, vlog, izdelkov in standardov,

ki jih metodologija vključuje) in gostoto (zahtevani nivo podrobnosti in formalnosti) in se

jo definira kot zmnožek obsega in gostote. Način določitve teže metodologije prikazuje

Slika 3.

Slika 3: Določitev teže metodologije

Vir: M. Krisper, R. Rupnik, in M. Bajec, Enotna metodologija razvoja

informacijskih sistemov, 2003, 1. zvezek.

Lahke metodologije: med nje spadajo metodologije z manjšim obsegom in manjšo

gostoto. Lahke metodologije dajejo poudarek razvoju programske rešitve in sodelovanju

med udeleženci projekta. Nekoliko manj pa upoštevajo organizacijski, poslovni in

sociološki vidik. Takšne metodologije imajo visoko stopnjo prilagodljivosti, kar pomeni,

da so zelo odzivne na sprotne spremembe zahtev iz okolja. Temeljijo na izkušnjah,

disciplini in razumevanju ter so primerne za manjše projektne skupine, ki imajo nižjo

stopnjo formalnosti. Tem lažja je metodologija, manj je optimizirana in bolj je

prilagodljiva.

11

Lahke metodologije uporabimo v primeru, ko (Krisper et al., 2003):

je glavni cilj razvoj programske rešitve,

imamo odgovorne, disciplinirane, izkušene in motivirane razvijalce, ki so seznanjeni s

posebnimi tehnikami dela,

imamo stranko, ki razume bistvo lahkih metodologij in je pripravljena sodelovati,

imamo nepredvidljive in spreminjajoče se zahteve za programsko rešitev,

je cilj razvoja relativno majhen sistem z nižjo stopnjo kritičnosti, ki ga je mogoče razviti

z majhno razvojno ekipo.

Težke metodologije: med nje uvrščamo metodologije z večjim obsegom in gostoto.

Stopnja formalizacije in optimizacije je višja. Izdelava dokumentacije je opisana podrobno,

velikokrat predpisujejo tudi uporabo določenih tehnik in orodij. Nasprotno kot lahke, so te

metodologije primernejše za večje razvojne skupine. Nekatere izmed težkih metodologij se

ukvarjajo tudi z organizacijskimi in sociološkimi vidiki razvoja programske rešitve. Težja

je metodologija, bolj je optimizirana in manj prilagodljiva.

Težke metodologije uporabimo, kadar (Krisper et al., 2003):

cilj ni le razvoj programskega sistema ampak tudi prenova organizacijskega sistema,

imamo manj izkušene razvijalce, pri katerih točno opredeljena formalna pravila

nadomeščajo izkušnje in znanje,

naročnik zahteva visoko stopnjo formalizma (izdelovanje dokumentacije),

imamo relativno dobro definirane in stabilne zahteve,

je cilj razvoja obsežnejši sistem z višjo stopnjo kritičnosti, ki zahteva izdelavo ustreznih

načrtov in dokumentacije.

1.2.3 Delitev glede na utežitev metodologije

Iz zaporedja izvajanja aktivnosti razvoja programske rešitve se je rodila ideja o delitvi

metodologij glede na utežitev. Programsko rešitev je potrebno v prvi vrsti analizirati in

načrtovati, nato se izvaja kodiranje in na koncu testiranje. Iz slednjega izhaja, da so

metodologije, ki dajejo poudarek prvima aktivnostma, spredaj utežene. Tiste, ki pa dajejo

poudarek zadnjima dvema aktivnostima, se po drugi strani opredeljujejo kot zadaj utežene.

Metodologije, ki dajejo poudarek različnim aktivnostim (enkrat prvima, naslednjič

drugima aktivnostma), se označujejo kot uravnotežene metodologije. Praksa izkazuje, da

so metodologije, ki so spredaj utežene, navadno težke metodologije. Zadaj utežene

metodologije pa so navadno lahke metodologije.

12

Spredaj utežene metodologije: poudarek dajejo analizi in načrtovanju, ki se ju izvede

najprej. Rezultat teh postopkov so natančno opredeljene zahteve uporabnikov, natančni

načrti ter druge zahteve. Analiza in načrtovanje se deloma lahko izvajajo tudi kasneje,

vendar se načrt bistveno več ne spreminja. Izdelava programske rešitve predstavlja le še

»rutinsko« kodiranje metod, ki so opredeljene v načrtih. Zaradi dobrega načrtovanja pa je

potrebno tudi manj testiranja.

Spredaj utežene metodologije so primerne za razvoj (Krisper et al., 2003):

sistemov s stabilnimi zahtevami: sistemi, katerih zahteve so dobro specificirane in

stabilne in pri katerih kasneje ne prihaja do večjih sprememb;

kritičnih sistemov: sistemi, kjer moramo predvideti čim več alternativnih scenarijev

dogajanja in jih zajeti že v načrtu;

obsežnih in kompleksnih sistemov: ti sistemi so namenjeni velikim razvojnim

skupinam. Pri takšnih sistemih so potrebni podrobnejši načrti, ki omogočajo

usklajevanje in razdeljevanje dela med člani

Večina klasičnih metodologij je uteženih spredaj. Največ kritik takšnih metodologij se

navezuje na preveč porabljen čas, ki se posveti analizi in načrtovanju, saj rezultat

velikokrat zaradi hitrega spreminjanja zahtev ni več uporaben.

Zadaj utežene metodologije: dajejo poudarek postopku izvedbe in testiranju, v postopkih

analize in načrtovanja pa se ne ukvarjajo s podrobnostmi. Slednja postopka potekata

istočasno s samim kodiranjem. Po končani izvedbi pa se izvede obsežno testiranje in

morebitno popravljanje kode, na podlagi česar nastane relativno stabilen izdelek s

pomanjkljivostjo, da je arhitektura takšnega izdelka navadno manj robustna in razširljiva.

Zadaj utežene metodologije so primerne za razvoj (Krisper et al., 2003):

Manjših in bolj enostavnih sistemov, z majhnimi in izkušenimi razvojnimi skupinami.

Pomanjkanje načrta otežuje delitev dela med člane projekte skupine, zato tak pristop ni

primeren za velike razvojne skupine, hkrati pa podrobnosti načrta nadomešča znanje in

izkušenost članov projektne skupine.

Sistemov s slabo določenimi zahtevami, ki se bodo najverjetneje še spreminjale. Kadar

zahtev ni mogoče dobro definirati vnaprej.

Nekritičnih sistemov. Posledica manj podrobne analize in načrtovanja bo tudi manj

stabilna arhitektura, ki ni primerna za kritične sisteme. Hkrati je take sisteme pozneje

težje nadgrajevati in vzdrževati.

Sistemov, ki uporabljajo tehnologijo, s katero nismo seznanjeni. V primeru, da ne

poznamo tehnologije, lahko z uporabo zadaj utežene metodologije tehnologijo

preizkusimo in spoznamo.

13

Izpostavljena kritika takšnih metodologij je, da niso primerne za razvoj obsežnih sistemov.

Uravnotežene metodologije: analiza in načrtovanje se izvaja za dele sistema, ki so že

dovolj znani in stabilni, kodiranje in testiranje pa se izvaja za dele sistema, ki še niso

dovolj poznani, kar nam pomaga pri določanju uporabniških zahtev. Nekatere aktivnosti se

tako izvajajo po spredaj uteženih metodologijah, spet druge po zadaj uteženih

metodologijah. Uravnotežene metodologije niso vedno idealna izbira za vse primere.

Uteženi procesi namreč nimajo vseh značilnosti spredaj ali vseh značilnosti zadaj uteženih

procesov.

2 AGILNE METODOLOGIJE

Razvoj programske opreme se nenehno spreminja. Na podlagi tega se je izkazalo, da so

tradicionalne metodologije preveč okorne, kar je povzročilo potrebo po učinkovitejših

metodologijah razvoja. V ospredje so prihajale potrebe po učinkovitejšem in hitrejšem

obravnavanjem sprememb, ki so se pojavile med samim razvojem, vedno večja želja po

rezultatih v dogovorjenih rokih, čim natančnejšem sledenju željam naročnika in

inovativnih rešitvah.

2.1 Glavna načela agilnih metodologij

Leta 2001 se je zbralo sedemnajst strokovnjakov s področja lahkih metodologij z namenom

ugotoviti, kaj imajo »njihove« metodologije skupnega ter na tej podlagi postaviti skupne

metodološke osnove. Vseh sedemnajst strokovnjakov se je tako združilo v zvezo »Agile

Alliance«. Temeljni lastnosti te zveze sta učinkovitost in prilagodljivost, na podlagi katerih

so člani zveze opisali nov trend agilnih metodologij s ciljem »iskanja boljših prototipov

razvoja programske opreme, tako da pri tem sami sodelujejo in pomagajo drugim«. Na

podlagi tega so izpeljali štiri osnovna načela, na katera je potrebno pri agilni metodologiji

biti pozoren (Beck, 1999).

2.1.1 Posamezniki in njihova komunikacija so pomembnejši kot procesi in orodja

Več časa je potrebno posvetiti individualnim članom projekta, porazdelitev vlog med člane

projekta mora biti dinamična. Poudarek je na dobri komunikaciji, ki je ključna za

uspešnost projekta. Bolje je sodelovanje in dobra komunikacija med člani, pa tudi če se

člani ne držijo nobenega predpisanega procesa, kot pa sledenje predpisanim procesom in

slaba komunikacija med člani ekipe.

14

2.1.2 Delujoča programska oprema je pomembnejša kot popolna dokumentacija

Naročnik vse do konca projekta čaka na rešitev programske opreme, vendar vse do takrat

lahko dobi le dokumentacijo. Dokumentacija ima za naročnika sekundarni pomen.

Delujoča programska rešitev je tisto, kar naročnik pričakuje in kar mu je potrebno

predstaviti. Dokumentacija naj ima sekundarni pomen in naj bo napisana po sistemu

»ravno dovolj«, saj je kljub temu pomembna za vzdrževanje sistema, za komunikacijo med

naročnikom in izvajalcem, ipd.

2.1.3 Sodelovanje uporabnika je pomembnejše kot pogajanje na osnovi pogodb

Ujemanje naročnika in izvajalca ima velik vpliv na uspešnost projekta. Zato mora biti

vloga naročnika postavljena na visoko mesto. Nerazumevanje in strog pogodbeni odnos

med naročnikom in izvajalcem ima namreč lahko na uspešnost projekta velik negativen

vpliv.

2.1.4 Upoštevanje sprememb je pomembnejše od sledenja načrtu

Obvladovanje sprememb ima velik pomen. V projektnem planu mora biti prostor tudi za

spremembe. Sledenje in planiranje plana je koristno, vendar le do stanja, ko se to preveč ne

razlikuje od dejanskega stanja.

Iz naštetega lahko razberemo, da uporaba agilnih metodologij skrajšuje čas, znižuje stroške

in povečuje fleksibilnost razvoja implementacije programske rešitve.

Krisper in Bajec (2003, str. 68–76 ) navajata tudi priporočila oziroma principe, ki so v

pomoč gradnji in vrednotenju metodologij in jih je za uspešno uporabo agilnih metodologij

potrebno upoštevati. Ti principi so:

Zadovoljstvo naročnika je najvišja prioriteta. To pomeni, da je naročniku potrebno hitro

in neprestano dostavljati uporabno programsko rešitev. S tem se tudi zmanjša tveganje

neustreznosti končne programske rešitve.

Čim bolj pogosta izdaja in dostava delujoče programske rešitve.

Spodbuja naj se spremembe zahtev tudi v kasnejših fazah razvoja. Upoštevanje

morebitnih sprememb in vpeljava le-teh v programsko rešitev lahko naročniku

predstavlja pomembno konkurenčno prednost.

Vključitev motiviranih zaposlenih, katerim naj bodo omogočeni spodbudni in ustrezni

delovni viri in pogoji. Potrebno jim je zaupati, da bodo svoje delo opravili dobro.

Komunikacija med člani projekta naj poteka preko osebnih pogovorov, »iz oči v oči«.

15

Potrebno je stalno preverjanje in izboljševanje kakovosti programske rešitve, s katero se

povečuje tudi prilagodljivost.

Pripravljenost na nenehni razvoj. Razvoj projekta mora biti podprt tako s strani

naročnika kot s strani izvajalca.

Ključ do uspeha je enostavnost procesa, ki ga je potrebno opraviti s čim manj stranskih

nalog in izdelkov.

Nenehne prilagoditve in izboljšave naslednje iteracije. Pri vsaki iteraciji je potrebno

preveriti proces, ki se je uporabljal in ugotoviti, kaj je bilo pri tem dobrega in kaj je bilo

odveč. Projektna skupina mora večkrat preveriti, kako bi postala še učinkovitejša in na

podlagi predlogov tudi sprejeti ustrezne ukrepe.

2.2 Vrste agilnih metodologij

2.2.1 Ekstremno programiranje (XP)

Ekstremno programiranje je po mnenju Becka (1999) lahka, učinkovita, prilagodljiva in

napovedljiva metodologija razvoja programske opreme, ki ne prinaša tveganja. V

primerjavi z drugimi metodologijami prinaša hitre rezultate, tok povratnih informacij in

razvojnih ciklov je stalen in stvaren, zaradi inkrementalnega pristopa omogoča hiter razvoj

delujoče programske rešitve, ki je podlaga za nadgraditev. Ima agilno sposobnost razvoja

funkcionalnosti glede na spreminjajoče se zahteve naročnikov. Metodologijo zaznamujejo

tudi zanesljivi avtomatizirani testi razvijalcev in uporabnikov, zaradi česar je omogočeno

hitro odkrivanje napak. Evolucijski razvojni proces traja tako dolgo, kot traja projekt.

Metodologija ekstremnega programiranja se najbolje obnese na projektih z dvema do

največ desetih razvijalcev. Zahtevan je tudi pogoj razvojnega okolja, ki v kratkem času

omogoča zagon avtomatskih testov (Warden & Shore, 2007).

Warden in Shore (2007) navajata štiri glavne vrednote ekstremnega programiranja, katerim

je Kent (1999) dodal še peto (spoštovanje):

komunikacija: je nujno potrebna za razvoj sistema. Ekstremno programiranje vsebuje

zahtevo po stalni prisotnosti naročnika med razvojem, s čimer se pospešuje

komunikacija in sprotno odpravljajo ter rešujejo težave. Prednost se daje preprostosti,

sodelovanju med razvijalci in uporabniki ter verbalni komunikaciji. Za prenos

informacije o poteku razvoja programske rešitve je pomembna tudi komunikacija z

vodstvom;

preprostost: prične se z najpreprostejšo rešitvijo, dodatne funkcionalnosti pa se

dodajajo pozneje. Razvoj je osredotočen na trenutne potrebe, kar omogoča, da se ne

zgublja preveč časa na stvareh, ki še niso bistvene, tako se ne porabi virov na nečem,

16

kar mogoče v prihodnosti sploh ne bo potrebno. Zaradi preprostosti se porabi manj

trenutnega dela, sistem je preprostejši in fleksibilnejši ter lažje razumljiv;

povratne informacije: so ključne za uspeh projekta. Gre za povratne informacije od

sistema, naročnika, uporabnikov ali od razvojne skupine.

pogum: zagotavlja spremembo sistema na bolje, pa četudi pomeni zavrženje kode in

sestavljanje nove rešitve;

spoštovanje: gre za medsebojno spoštovanje med člani projekta, spoštovanje dela

drugih članov, ter stremenje k višji kvaliteti in boljšim rešitvam. To prinaša visoko

stopnjo motivacije članov projekta in spodbuja k lojalnosti.

Kent (1999) opisuje še dvanajst osnovnih principov ekstremnega programiranja:

igra planiranja,

majhne in pogoste izdaje,

metafora,

preprost načrt,

testiranje,

preoblikovanje,

programiranje v parih,

skupno lastništvo programske kode,

stalna integracija,

40-urni delovni teden,

stranka ob strani in

standardi kodiranja.

Ti principi so medsebojno povezani. Večina izmed njih samostojno celo ne more nastopati

(Jeffries, 2011).

Življenjski cikel metode razvoja ekstremnega programiranja sestavlja pet faz, kot kaže

Slika 4 (Beck, 1999b, str. 131):

faza raziskovanja,

faza načrtovanja,

faza ponovitev do objave,

faza priprave za produkcijo,

faza vzdrževanja in

faza smrti.

17

Slika 4: Življenjski cikel XP procesa

Vir: P. Abrahamsson, O. Salo in J. Ronkainen, Agile software development methods:

Review and analysis, 2002, str. 19.

2.2.2 Metoda DSDM

Metodologija DSDM (angl. Dynamic Systems Development Method) ali metodologija

razvijanja dinamičnih sistemov v iterativni razvoj stalno vključuje uporabnika in vodilne.

Tako je možna hitra odzivnost na spremenljive zahteve. Metodologija DSDM je navadno

usmerjena na razvoj projektov, za katere je značilen kratek razvojni čas in omejena

finančna sredstva (Rietman, 2008, str. 3–8)

Metodologija DSDM je sestavljena iz treh faz, kar je razvidno tudi iz Slike 5:

predprojektna faza,

faza življenjskega cikla projekta, ki se deli na pet stopenj: študija izvedljivosti, študija

poslovanja, iteracija funkcionalnega modela, iteracija izgradnje zasnove sistema in

implementacija ter

poprojektna faza.

18

Slika 5: Življenjski cikel procesa DSDM

Vir: Dynamic System Development Method Consortium, DSDM Tour, b.l..

Metodologija je v različnih pogledih podobna ostalim agilnim metodologijam, v drugih

pogledih pa celo nekaterim neagilnim metodologijam razvoja informacijskih rešitev. Za

doseganje zastavljenih ciljev ima točno določene in predpisane principe, vloge in tehnike

(Beynon-Davies, 2003, str. 29–46). Ponuja pa tudi ogrodje, ki ni odvisno od orodij in

tehnik. To pomeni, da lahko vsak uporabnik uporabi svoje. Spremenljivke v razvoju prav

tako niso vezane na vire in čas, temveč se navezujejo na zahteve uporabnikov. To projektu

zagotavlja ostati v obeh okvirih, časovnih in finančnih Za metodologijo je značilen velik

poudarek na komunikaciji med vsemi sodelujočimi, saj obravnava razvojni proces tako s

stališča razvijalcev kot tudi uporabnikov, projektnih vodij, osebja in ostalih vključenih v

projekt (Brinkkemper, 1998, str. 381–400).

DSDM podpira filozofijo, da nič ni prvič zgrajeno popolno in na razvoj programske

opreme gleda kot na raziskovanje že raziskanega (Alexandrou, b.l.).

DSDM se osredotoča na zagotavljanje poslovnih rešitev in ne le na aktivnosti ekipe. To

omogoča ukrepe, ki zagotavljajo izvedljivost in poslovni namen projekta, še preden bo le-

ta narejen (Clifton & Dunlap, 2003).

http://www.mariosalexandrou.com/http://www.codeproject.com/script/Membership/View.aspx?mid=36803http://www.codeproject.com/script/Membership/View.aspx?mid=317642

19

Metodologija DSDM temelji na naslednjih ključnih načelih (Alexandrou, b.l.; Clifton &

Dunlap, 2003):

a) aktivno vključevanje in sodelovanje uporabnikov,

b) tim mora biti pooblaščen za sprejemanje odločitev,

c) poudarek na pogosti dobavi rešitve (delne rešitve),

d) kriterij za kakovost je primernost uporabe programa,

a) z iterativnim in inkrementalnim razvojem se zagotovi bližanje natančni poslovni rešitvi,

b) reverzibilne spremembe v razvoju,

c) zahteve na začetku temeljijo na visoki ravni,

d) integrirano testiranje čez cel življenjski cikel,

e) sodelovanje vseh sodelujočih oseb,

f) pravilo 20 %/80 %.

2.2.3 Metoda FDD

Metodologija FDD (angl. Feature Driven Development, v nadaljevanju FDD ) je okreten in

prilagodljiv pristop za razvoj sistemov in programskih rešitev, ki ne zajema celotne

programske opreme in razvojnega procesa temveč se osredotoča na fazo načrtovanja in

izgradnje. Metodologija je bila zasnova za delo z drugimi aktivnostmi razvoja programske

opreme in za uporabo ne zahteva nobenega posebnega procesnega modela (Pekka; Outi;

Jussi & Juhani, 2002, str. 47–55).

FDD se zavzema za razvoj programske opreme, ki je funkcijsko voden. FDD metodologija

je primerna predvsem za modeliranje in razvoj, saj deluje na principu zaporednih procesov.

Najprej se celotni sistem razbije na več funkcionalnosti, ki so za stranko že uporabne. Vse

te posamezne funkcionalnosti pa lahko stranka že uporablja in testira, še preden je

poslovna rešitev v celoti končana. Posamezne funkcije pa pomagajo tudi razvijalcem, saj

lahko tako lažje pridejo do hitrega in kakovostnega razvoja (Jeff De Luca, 2008 ).

Pri FDD metodologiji obstaja pet glavnih aktivnosti, ki se razvijajo iterativno, kar

prikazuje tudi slika 6 (Ambler, 2007). Te aktivnosti so:

razvoj splošnega modela,

sestava seznama značilnosti,

načrtovanje po značilnostih,

snovanje po značilnostih in

izgradnja po značilnostih.

http://www.mariosalexandrou.com/http://www.codeproject.com/script/Membership/View.aspx?mid=36803http://www.codeproject.com/script/Membership/View.aspx?mid=317642

20

Slika 6: Aktivnosti metodologije FDD

Vir: S. R. Palmer in J. M Felsing, A Practical Guide to Feature-Driven Development, 2002.

2.2.4 Metoda ASD

Metoda ASD (angl. Adaptive Software Development, v nadaljevanju ASD) se predvsem

osredotoča na težave pri razvoju zapletenih, večjih sistemov. Bistvo ASD metodologije je

prilagajanje novim spoznanjem med samim razvijanjem programske rešitve. Metoda

močno spodbuja inkrementalni, iterativni razvoj, s konstantno izdelavo prototipov. Razvoj

projekta po metodologiji ASD poteka v trifaznem ciklu, prikazanem na sliki 7:

razmišljanje/načrtovanje, sodelovanje in učenje. ASD daje večji poudarek na rezultate in

njihovo kakovost, kot pa na naloge ali procese, ki se uporabljajo za razvoj rezultata (Pekka

et al., 2002, str. 68–71).

Slika 7: Življenjski cikel po metodologiji ASD

Vir: J. Stapleton, Dynamic systems development method – The method in practice, 1997.

21

Aktivnosti v vsakem razvojnem ciklu morajo biti utemeljene glede na skupno poslanstvo

projekta. Poslanstvo se lahko prilagodi le, če se razvoj nadaljuje. Razvojne dejavnosti

morajo biti osredotočene na razvoj delujoče programske opreme in ne usmerjene k

nalogam. Programska rešitev se sestavlja in izgrajuje po majhnih koščkih. Pomembneje je,

da se morebitne spremembe v programsko rešitev prilagodi, kot da se jih le nadzira. Za

izgradnjo prilagodljivega sistema pa morajo razvijalci nenehno ocenjevati, ali se lahko

vgrajene komponente kdaj spremenijo. Razvoj visoko tveganih postavk se mora začeti čim

prej (Pekka et al., 2002, str. 68–71).

2.2.5 Crystal Clear

Metodologija Crystal Clear spada v družino Crystal in je primer agilne oziroma lahke

metodologije in je aplicirana v skupine, v katerih deluje šest do osem ljudi, ki delujejo na

nekritičnih sistemih. Metodologija je usmerjena k ljudem in ne k izdelkom. Njene

značilnosti so (Pekka et al., 2002, str. 36–46):

pogostost izdaje kode v uporabo,

pregled in popravljanje napak,

dobra komunikacija v skupini, znotraj istega prostora,

osebna varnost,

fokus,

lahka dostopnost za ekspertne uporabnike,

avtomatizirani testi, pogosta integracija, upravljanje sestave (angl. Configuration

Management).

2.2.6 Scrum

Scrum uporablja iterativni in inkrementalni pristop in dovoljuje interakcijo z okoljem,

čeprav lahko to vpliva na stroške in obseg projekta, tehnologijo in njegovo funkcionalnost.

Metodologija Scrum sprejema dejstvo, da je lahko razvojni proces programske rešitve

nepredvidljiv.

Scrum povzema pravila, ki jih uporabljajo podjetja, ki se ukvarjajo z razvojem programske

opreme (Schwaber, 1996, str. 3):

Razbitje velikih produktov na obvladljive delčke – funkcije, ki jih lahko majhna skupina

ustvari v kratkem času;

Omogoča, da se projekt nadaljuje sistematično, čeprav člani skupine takoj na začetku ne

morejo določiti popolnega in stabilnega dizajna izdelka;

22

Velikim skupinam omogoča delo kot majhne skupinice, kar dosega s porazdelitvijo dela

na manjše dele oziroma postopke, z vzporednimi postopki in nenehno sinhronizacijo, s

stabilizacijo v korakih ter nenehnim iskanjem napak in sprotno odpravo le teh.

Ta pravila pospešujejo konkurenčnost, ki temelji na povratnih informacijah strank, na

funkcijah izdelka, na kratkem razvojnem času mehanizma vključevanja zahtev strank, ki

omogoča, da se lahko prioritetne funkcije izdelka implementirajo najprej.

Ključna načela razvojne metodologije Scrum so (Schwaber, 1996, str. 4):

Majhne razvojne skupine, saj to povečuje in izboljšuje komunikacijo, zmanjšuje

režijske stroške in povečuje izmenjavo tihega, neformalnega znanja;

Prilagodljivost na tržne in/ali tehnične spremembe, kar omogoča implementacijo

najboljšega možnega izdelka;

Pogosto kreiranje izdelka, ki ga lahko pregledamo, prilagodimo, testiramo,

dokumentiramo in zgradimo;

Razdelitev dela in nalog skupine v nizko povezane particije ali paketke;

Vedno imej produkt, ki ga lahko posreduješ stranki–sposobnost dostaviti produkt

kadarkoli (ko to zahteva stranka ali konkurenca).

Ključ uspeha metode Scrum je povečevanje prožnosti in tveganj ob hkratnem ohranjanju

nadzora. Podrobnejši opis metodologije Scrum je zajet v nadaljevanju, v točki 4.

3 PRIMERJAVA TRADICIONALNE Z AGILNIMI METODOLOGIJAMI

Veliko podjetij pri razvoju novih izdelkov dandanes deluje v negotovih, dinamičnih in

konkurenčnih okoljih. Obstaja veliko nemirov, ki izhajajo iz dejavnikov, ki se odražajo kot

intenzivna svetovna konkurenca, zmanjšanje prehodnega časa in pričakovane življenjske

dobe proizvodov, raznoliko povpraševanje ter nove tehnologije. Podjetja morajo biti

sposobna kljub temu konkurirati na trajnostni način. V ta namen so se v začetku

devetdesetih letih začeli razvijati koncepti agilnih metodologij. Ključ do uspeha podjetij je

namreč v obvladovanju neenakomernega in nepredvidljivega povpraševanja, česar

tradicionalne metodologije niso bile sposobne. Razvoj programske opreme se je srečeval s

podobnimi ovirami in izzivi, zato se je agilnost začela vpeljevati tudi na tem področju. Kot

odgovor na težave s tradicionalnimi modeli so se začele pojavljati lahke metodologije

razvoja programske opreme (Kettunen, 2009, str. 408).

Programska oprema je del sodobne družbe že več kot 50 let. Dandanes v uporabi obstaja

več metodologij razvoja programske opreme. Nekatera podjetja imajo svoje, prilagojene

23

metodologije za razvoj programske opreme, vendar večina govori o dveh vrstah

metodologij: težke in lahke. Težje metodologije razvoja programske opreme, imenovane

tudi tradicionalne, dajejo podporo celovitemu načrtovanju, podrobni dokumentaciji in

širokemu dizajnu. V zadnjih dvajsetih letih pa so s strani razvijalcev programske opreme,

veliko pozornost začele pridobivati predvsem lahke metodologije. Za razliko od

tradicionalnih metod se agilne metodologije poslužujejo kratkih iterativnih ciklov in se

zanašajo na tako imenovano tiho znanje ekipe.

Težke metodologije se štejejo kot tradicionalni način razvoja programske opreme. Te

metodologije temeljijo na zaporedju posameznih korakov kot so definiranje zahtev,

izgradnja rešitve, testiranje in uvedba. Te metodologije zahtevajo določitev in

dokumentiranje fiksnega sklopa zahtev že na začetku projekta. Obstaja veliko različnih

težkih metodologij. Najpomembnejše med njimi so Waterfall, Spiral Model in Unified

Process (Mars, 2002).

3.1 Karakteristike tradicionalnih metodologij

Pristop predvidevanja–nagnjenost k izvedbi večjega dela natančnega prvotnega načrta

programske opreme, ki je bil načrtovan za daljše obdobje. Ta pristop sledi inženirski

disciplini, kjer je razvoj predvidljiv in ponovljiv. Velik poudarek je na risbah s

fokusiranjem na potrebe sistema in na učinkovito reševanje teh potreb. Risbe se nato

prenesejo na drugo skupino, ki je odgovorna za oblikovanje in izgradnjo sistema. Skice

namreč predstavljajo temelj za izgradnjo, iz katerega se razbere, kako mora biti sistem

zgrajen. Prav tako pa načrt predvideva naloge za kreiranje izvedbene ekipe in razumno

predvideva načrt ter proračun za izgradnjo programske opreme/sistema.

Obsežna dokumentacija – ključni del dokumentacije predstavlja dokument zahtev. Glavni

proces težkih metodologij predstavlja velik dizajn vnaprej, znotraj katerega vlada

prepričanje, da je možno zbrati vse zahteve stranke, še preden se začne pisanje kode.

Procesna usmerjenost – cilj je opredeliti postopke, ki bodo delovali dobro, četudi se zgodi

karkoli. Proces mora biti sestavljen iz nalog, ki jih morajo opraviti vodje, oblikovalci,

programerji, testerji, itn. Za vsako od teh nalog obstaja tudi natančno opredeljen postopek.

Usmerjenost na orodja – orodja za upravljanje in vodenje projekta, urejanje kode,

primerjanje in podobno, morajo biti v uporabi za izpolnjevanje in dostavo vsake naloge.

24

3.2 Karakteristike agilnih metodologij

Highsmith in Cockburn (2001, str. 133–133) navajata naslednje karakteristike agilnih

metodologij:

Usmerjenost k ljudem – pri agilnih metodologijah v skupino »ljudje« uvrščamo stranke,

razvijalce, zainteresirane in končne uporabnike. Ljudje so najpomembnejši dejavnik pri

razvoju programske opreme. Vodje morajo dajati velik poudarek človeškim dejavnikom

kot so družabnost, talent, spretnost in komunikativnost. Če so ljudje na projektu dovolj

dobri, jih lahko uporabimo pri katerem koli postopku in bodo izpolnili vse naloge

(Highsmith &Cockburn, 2001).

Prilagodljivost – udeleženci se ne bojijo sprememb. Nasprotno, spremembe so dobrodošle

v katerikoli fazi projekta. Le-te predstavljajo dobro stvar, saj razvojna ekipa tako spozna

zahteve trga.

Skladno z dejanskim – agilni projekti niso nadzorovani s skladnostjo z načrtom ampak so

nadzorovani s skladnostjo s poslovno vrednostjo (Highsmith, 2002).

Uravnoteženje prilagodljivosti in načrtovanja – načrti so pomembni, vendar problem je,

da programske opreme ni mogoče napovedati daleč v prihodnost. Ker obstaja veliko

spremenljivk, je najboljša strategija načrtovanja takšna, da se pripravi podrobne načrte za

naslednjih nekaj tednov, zelo grobe načrte za naslednjih nekaj mesecev in zelo surove

načrte še dalje vnaprej (Highsmith, 2000).

Empirični procesi – agilni razvoj programske opreme je empiričen – nelinearen. Empirični

pristop predpostavlja, da je razvoj programske opreme nepredvidljiv in kaotičen. Za

upravljanje nepredvidljivosti in kontrolo tveganja se uporabljajo kontrole, kar zagotavlja

fleksibilnost, odzivnost in zanesljivost.

Decentralizirani ukrepi – vključitev decentraliziranega stila vodenja lahko vpliva na

razvoj projekta, saj se lahko prihrani precej časa kot avtokratsko obvladovanje procesov.

Naloga odločanja se tako razprostira tudi na razvijalce, kar pa ne pomeni, da razvijalci

prevzemajo vloge upravljanja, temveč da o tehničnih odločitvah lahko odločajo razvijalci

brez dovoljenja vodje.

Preprostost – agilne ekipe ubirajo najpreprostejše poti, ki so v skladu z njihovimi cilji.

Agilne ekipe ne pričakujejo jutrišnjih problemov, ampak se pred njimi skušajo obraniti že

danes (Fowler, 2005). Nikoli ne izdelaj več, kot je potrebno in nikoli ne poskušaj pripraviti

dokumente za napovedovanje prihodnosti, saj bodo hitro zastareli (Wendorf, 2004,

str. 218).

25

Sodelovanje – redno vključevanje mnenj in povratnih informacij stranke. Stranka naj tesno

sodeluje z razvojno ekipo, saj zagotavlja povratne informacije o svojih prizadevanjih.

Bistvenega pomena je tudi stalno sodelovanje med člani ekipe in vodstvom projekta

(Fowler, 2005).

3.3 Omejitve tradicionalnih metodologij

Glavna razlika med tradicionalnimi in agilnimi metodologijami je sprejetje sprememb. Gre

za sposobnost odzivanja na spremembe, ki pogosto določa uspeh ali neuspeh projektov

programske opreme (Williams & Cockburn, 2003, 39–43). Tradicionalne metode

zamrznejo funkcionalnosti izdelka in ne dopuščajo sprememb. Zato je ključna prednost

agilnih metod dopuščanje sprememb izdelka v kateri koli fazi projekta. V tako

spreminjajočem okolju je namreč zelo težko implementirati in predvidevati nadaljnje

procese ali zagotavljati stabilne zahteve. Martin Fowler in Jim Highsmith, ustanovitelja

»Agil manifesto«, menita, da je omogočanje sprememb učinkovitejše, kot jih poskušati

preprečevati (Fowler, 2005).

Druga omejitev tradicionalnih metodologij je uravnavanje kompleksnosti. Pristop k

prvotnemu načrtovanju vsega in šele potem sledenje načrtu deluje le v stabilnih in manj

zapletenih okoljih. V večjih in kompleksnejših okoljih pa takšen pristop ne zdrži. Rešitev

tega problema leži v preprostosti. Pri agilnih projektih je zlasti pomembna uporaba

preprostih pristopov, ker jih je lažje spremeniti. Lažje je nekaj dodati procesu, ki je

preprost kot nekaj odvzeti procesu, ki je zapleten (The Standish Group International,

2005). Kathleed Eisenhardt predlaga, da se namesto zapletenih procesov uporabijo

preprosta pravila za komuniciranje strategije. To je najboljši način, da ljudje izkoristijo

minljive priložnosti v hitro spreminjajočih se trgih (Eisenhardt & Sull, 2001, str. 107–116).

Zaporedni v primerjavi z iterativnim razvojem je še en dokaz razlikovanja med

tradicionalnimi agilnimi metodologijami. Pri tradicionalnih metodah so povratne

informacije stranke in testiranje postavljene v zadnjo fazo življenjskega cikla projekta.

Agilne metode pa zagovarjajo, da bi to morala biti vsakodnevna praksa. Po Fowlerju

(2005) je ključ do iterativnega razvoja redna proizvodnja delujočih verzij končnega

sistema. Takšno delovanje sistema je sicer kratko po delovanju, vendar mora biti tudi

zvesto zahtevam končne rešitve. Za prikaz zahtev programske opreme uporabnikom

pripravljajo tradicionalne metode dokumentov. Agilisti pa menijo, da ne obstaja trdnejšega

dokaza uspešnega delovanja sistema kot je uspešno stestirana rešitev.

Standish Group International je v svoji študiji 23.000 projektov ugotovila, da zgodnja

dobava manjših komponent programske opreme v krajših časovnih intervalih povečuje

stopnjo uspešnosti projekta (The Standish Group International, 2005). Druga študija, ki jo

26

je opravil Alan MacCormack, Harvard Business School, je prav tako pokazala, da

predčasna rešitev oblikovanja razvijajočega se izdelka predstavlja uspešnost projekta.

MacCormack (2001) navaja, da je najbolj presenetljiv rezultat raziskave pomembnost, da

stranka prejme nizko uporabno različico v roke ob prvi priložnosti. Obe študiji tako močno

dokazujeta temelj agilnih procesov: kratek iterativni razvoj; redne in hitre povratne

informacije stranke ter testiranje in inkrementalni razvoj, kar občutno prispeva k

izboljšanju kakovosti končnega izdelka.

Druga pomembna kritika tradicionalnih metod je postopanje glede vključitve ljudi pri

sodelovanju razvojnega procesa. Cockburn in Highsmith (2001, str. 131–133) v prispevku

navajata, da so ljudje najpomembnejši dejavnik pri razvoju programske opreme. Prav tako

tudi Standish Group v svojem poročilu opravljenih raziskav navaja tri najpomembnejše

dejavnike uspešnega projekta: izvrševanje podpore, sodelovanje z uporabniki in izkušeno

projektno vodenje (The Standish Group International, 2005). Agilne metode se

osredotočajo na talente in sposobnosti posameznikov, na podlagi katerih se oblikujejo

procesi ter določijo posamezniki skupine. Pri tradicionalnih metodah je ravno nasprotno.

Vse naloge in vloge so dodeljene posameznikom, od katerih se pričakuje, da bodo vse

naloge opravljene skladno.

Agilne metodologije zagovarjajo dejstvo, da se lahko odzivajo in prenašajo ideje hitreje, če

se soočajo na štiri oči, kot je to možno pri tradicionalnih metodologijah, kjer se vse prebere

in zapisuje v obliki dokumentacije. Ko se razvijalci pogovarjajo s stranko lahko že

istočasno odpravljajo težave, prilagajajo prednostne naloge in preučujejo nadomestne poti

za naprej. Kar pa ni mogoče, če ljudje med seboj ne sodelujejo, kot je značilno za

tradicionalne metode (Cockburn, 1999).

Še en argument razlikovanja tradicionalne in agilne metodologije je merjenje uspešnosti

projekta. Agilisti merijo uspešnost projekta glede na vprašanje ali je stranka prejela rešitev,

ki zanjo predstavlja večjo vrednost kot so znašali vloženi stroški. Martin Fowler (2005)

navaja: »Dobro predviden projekt bo šel po planih, dober agilni projekt pa bo zgradil nekaj

drugačnega in boljšega kot je predvideval prvotni načrt.«

3.4 Omejitve agilnih metodologij

Največja omejitev agilnih metodologij je, kako ravnati z večjimi skupinami. Cockburn in

Highsmith (2001, str 131–133) sta prišla do zaključka, da je agilni razvoj za večje skupine

težji. Tudi Constantin in Fowler (2005) verjameta, da je komunikacija na štiri oči

pokvarljiva in postaja vse težja, če je razvijalcev že več kot 20. V nasprotju s tem je za

večje projekte in projektne skupine lažje in bolje uporabiti tradicionalne metodologije.

27

Vsakega problema ne moremo razbiti na manjše delčke in tako pohitriti primarnega

izboljšanja (Boehm, 2002, str. 64–69).

Boehm (2002, str. 64–69) se ne strinja z izjavo agilnosti (angl. agile manifesto), ki pravi,

da je največja prednost zadovoljiti kupca z zgodnjo in konstantno dostavo delčkov delujoče

programske opreme. Po njegovem mnenju pregled zgodnjih rezultatov lahko povzroči

večje predelave v kolikor se ne poviša arhitektura. Boehm tudi meni, da je načrtno

usmerjen proces najbolj potreben visoko zanesljivi programski opremi. Cilji tradicionalnih

metodologij, kot so npr. predvidljivost, ponovljivost in optimizacija so pogosto značilnosti

zanesljivih varnostno pomembnih razvojev programske opreme. Večina agilnih tehnik prav

tako ne podpira pregledov in inspekcijskih nadzorov kode v življenjskem ciklu projekta,

ampak je poudarek na programiranju v parih in neformalnih ocenah njihovih kontrolnih

mehanizmov kakovosti.

Boehm se prav tako ne strinja z agilno značilnostjo talentov, spretnostjo in komunikacijo

med ljudmi. Medtem ko agilne metodologije ne zahtevajo združitve visoko zmogljivih

ljudi, se opirajo na tiho znanje, ki se pooseblja v skupini, namesto da bi znanje zapisovali

kot dokumentacijo. Boehm opozarja, da bi to lahko vodilo do arhitekturnih napak, ki jih

zunanji pregledovalci zaradi pomanjkljive dokumentacije ne morejo zlahka odkriti.

Tradicionalne metode tako zmanjšujejo tveganje za vlaganje v arhitekturo. S tem zunanjim

strokovnim pregledovalcem olajšajo vpogled v planiranje in uporabo programske rešitve,

čeprav lahko ti načrti zastarajo ali se zaradi vpeljave sprememb celo podražijo.

Razprava o tem ali agilna metodologija zahteva ustvarjalne in spretne ljudi, da bi bili

učinkoviti, vodi k dodatnemu argumentu. Če delamo s »premium« ljudmi, ni pomembno, s

katerim tipom metodologije vodimo in razvijamo projekt. To pomeni, da bi bilo potrebno

uspeh agilnih metod pripisati ekipi dobrih ljudi ne pa načelom in praksi. Highsmith in

Cockburn (2001, str 131–133) se s to trditvijo strinjata in pojasnjujeta: »Če so ljudje na

projektu dovolj dobri, lahko uporabimo kateri koli postopek in izpolnili bodo vse naloge.

Če niso dovolj dobri, ne bo noben postopek popravil in prikril njihove neustreznosti«.

Agilne metodologije dajejo velik poudarek sodelovanju s strankami in se jih obravnava kot

del razvojne ekipe skozi celotni razvoj programske opreme. Boehm (2002, str. 64–69)

potrjuje, da je takšen način uporaben in uspešen, v kolikor strankino znanje zadostuje za

celotno razvojno obdobje. Vendar takšen način lahko privede do težav, kadar obstaja več

strank, med njimi pa obstajajo različni pogledi in konflikti. Takšne primere je najlažje in

najhitreje rešiti s pomočjo dokumentacije, planiranjem, ocenjevanjem arhitekture in

podajanjem ocene neodvisnih strokovnih izvedencev.

Še en dejavnik, ki bi lahko povzročil težave, je razlaga prednosti delujočega sistema pred

izčrpno dokumentacijo. Boehm (2002, str. 64–69) se sprašuje o uporabnosti poudarjanja

preprostosti. Prepričan je, da se z odpravljanjem arhitekturnih značilnosti, ki ne podpirajo

28

trenutne različice, lahko povzročijo dodatne delovne aktivnosti. To lahko povzroči napačne

predstave razvijalcem. Ta pristop je uporaben, kadar so prihodnje zahteve zelo

nepredvidljive. Vendar, kadar pa so zahteve v naprej zelo predvidljive, lahko takšen

pristop povzroči težave s strankami, saj stranke verjamejo v razvijalce, da so njihove

prednostne naloge in razvojne zahteve vredne ustrežljivosti.

Produktna in projektna dokumentacija je zmeraj tema, ki pritegne veliko pozornost agilnih

metodologij. Ali je potrebna vsa dokumentacija? Če da, koliko je dovolj? Ambler (2002)

poudarja, Organizacije zahtevajo več dokumentacije, kot je potrebno, in ta dokumentacija

je slaba oblika komunikacije. Ambler prav tako pojasnjuje, da dokumentacija zastara in jo

je tako potrebno redno obnavljati. Zagovarja pa, da je dokumentacija ravno tako potrebna,

predvsem za ohranitev ključne informacije v daljšem časovnem obdobju. Boehm na

obširno dokumentacijo odgovarja, da dokumentirani projekti omogočajo zunanjim

strokovnim izvedencem lažje ugotavljanje težav. Predlog »nobene dokumentacije« pa

povečuje tveganje glede vzdrževanja in vidika uporabe. Agilisti pa zagovarjajo

predpostavko, da bodo skupine ostale skupaj do samega konca razvoja programske

opreme, na kar pa zagovorniki tradicionalnih metod odgovarjajo, da se v večini primerov

to ne zgodi.

Agilne metode dajejo manjšo težo uporabniški strani programske opreme kot je npr.

uporabniški vmesnik in uporabnost. Ko pride do uporabniškega vmesnika, agilni procesi

raje poenostavljajo oblike ali uporabijo iterativne papirne prototipe, kot zmodelirajo dizajn.

Agilisti zagovarjajo, da je testiranje uporabniškega vmesnika delovno intenzivno in

dolgotrajno. Vendar Cauwenberghe (2001) navaja, da uporabnikom orientirano

načrtovanje izpolnjuje pogoje za agilni proces, saj lahko tako ponuja uspešen in učinkovit

sistem za oblikovanje zelo uporabnega uporabniškega vmesnika.

3.5 Primerjava tradicionalne z agilnimi metodologijami

Tradicionalni pristopi razvoja so se uporabljali zelo dolgo časa. Najpogosteje se je

uporabljal model »Waterfall«, tako pri velikih kot tudi pri manjših projektih programske

opreme, ki se je izkazal kot zelo uspešen model pri mnogih projektih. Kljub uspehu je imel

veliko pomanjkljivosti, kot so linearnost, nefleksibilnost na spremembe potreb in visoko

formalizirane postopke, ne glede na velikost projekta. Kent Beck je te pomanjkljivosti

upošteval in uvedel »Extreme Programming«, prvo agilno metodologijo. Agilne metode

upoštevajo nestabilne in hitre spremembe z uporabo več tehnik, dajejo poudarek na

sodelovanju med razvijalci in kupci ter podpirajo hitro dobavo izdelkov. Povzetek razlik

med tradicionalnimi in agilnimi metodologijami je prikazan v Tabeli 1 (Awad, 2005,

str. 35):

29

Tabela 1: Primerjava tradicionalne z agilnimi metodologijami

Agilne metode Tradicionalne metode

Pristop prilagodljiv predvidljiv

Merjenje uspeha poslovna vrednost skladnost s planom

Velikost projekta majhni veliki

Način vodenja decentralizirani avtokratski

Pogled na spremembe prilagodljivost na spremembe nesprejemljivost sprememb

Kultura vodenje – sodelovanje ukazovanje – nadzor

Dokumentacija nizka stopnja in malo visoka stopnja in veliko

Usmerjenost na ljudi na procese

Cikličnost številna omejena

Domena nepredvidljivo/raziskovalno predvidljivo

Načrtovanje vnaprej minimalno celovito

Donosnost naložb na začetku projekta na koncu projekta

Velikost skupine majhna/kreativna velika

Vir: M. A. Awad, A Comparison between Agile and Traditional Software Development, 2005, str. 35.

Tako tradicionalne kot agilne metode imajo svoje prednosti in slabosti. Ljudje navadno

sledijo eni izmed metodologij ali pa si prilagodijo svojo metodologijo. Na odločitev in

izbiro metodologije, ki je primerna za različne pogoje, vplivajo različni dejavniki. Te

dejavnike lahko razdelimo v tri skupine in sicer velikost projekta, ljudje in tveganje.

3.5.1 Velikost projekta

Eno od omejitev agilnih metod predstavlja velikost projekta. Ključni elementi velikosti

projekta so omejen proračun, trajanje projekta in organizacija projektne skupine. Večja je

skupina, večji je proračun, večji je projekt. Tako sestavljanje zahtev zahteva več ljudi in

več koordinacije. Tradicionalne metodologije to zagotavljajo z načrti, dokumentacijo in

procesi za boljše komuniciranje in usklajevanje med velikimi skupinami. Kot je razvidno

iz Slike 8, Cockburn (1997), eden od ustanoviteljev agilne zveze, glede problema velikosti

trdi, da so ljudje manj potrebni, če se uporablja agilne metodologije in da je potrebnih več

ljudi, če se uporablja tradicionalne metodologije. Cockburn trdi, da je omejitev glede

problema velikosti mogoče rešiti z določenim številom ljudi.

30

Slika 8: Problem velikosti projekta in vpliv metodologije na število ljudi

Vir: M. A. Awad, A Comparison between Agile and Traditional Software Development, 2005, str. 36.

Velikost skupine vpliva tudi na komuniciranje znotraj projekta in na osebno učinkovitost.

Slika 9 prikazuje, da se komunikacijska obremenitev povečuje s povečevanjem števila ljudi

kar povzroča povečano upadanje osebne učinkovitosti. Cockburn navaja, da metodologija

usklajuje ljudi in upravlja komunikacijo, zato se mora raven metodologije dvigniti, ko se

povečuje število ljudi. To otežuje uporabo agilnih metodologij, kjer so skupine večje od 40

ljudi. V takih primerih se prednostno uporablja tradicionalne metodologije. Vendar se Ken

Schwaber s tem ne strinja in navaja, da se lahko velike skupine razčleni na manjše

skupinice (Schwaber &Beedle, 2002).

Trajanje projekta je še en dejavnik, ki vpliva na izbiro metodologije. Tradicionalne

metodologije vsebujejo veliko »izgube časa« kot npr. dokumentiranje, oblikovanje

dokumentacije, zapisovanje analiz, itn. Tako zaključimo, da kadar je čas omejen, je

uporaba agilnih metodologij primernejša.

31

Slika 9: Učinki glede na velikost projekta

Vir: M. .A Awad, A Comparison between Agile and Traditional Software Development, 2005, str. 36.

3.5.2 Ljudje

Agilne metodologije se veliko ukvarjajo s človeškimi dejavniki, posamezniki, njihovimi

interakcijami ter odnosi in sodelovanjem s strankami (Cockburn & Highsmith, 2001,

str. 131–133). Imeti spretne in izkušene ljudi v skupini predstavlja ključni dejavnik agilnih

metodologij. Spodbujanje strokovnjakov, da bi bili del skupine, daje razvijalcem hitro

povratno informacijo o možnih posledicah za uporabnike, do katerih lahko pride ob izbiri

njihovih odločitev. Prilagodljivost stranke je še en velik dejavnik. Kupec ima namreč

pooblastilo, da lahko v vsaki iteraciji preverja napredek in spremembe smeri razvoja

programske opreme. Pridobitev takšne ravni obveznosti stranke naredi agilne metodologije

veliko bolj privlačnejše kot tradicionalne. Tudi kultura organizacije je pomemben dejavnik

pri izbiri metodologije. Če je podjetje trdno, se ne odziva na spremembe in ima veliko

pravil in postopkov, potem ne more uspešno uporabljati agilne metodologije. In nasprotno,

podjetje, ki se odziva na spremembe in je prilagodljivo, mora v svojo kulturo sprejeti tudi

prilagodljivost za spremembe, če želi uporabljati agilne metode.

32

3.5.3 Tveganje

Najpomembnejša dejavnika tveganja pri razvoju programske opreme sta kritičnost projekta

in odzivnost na spremembe. Agilne metode se uporabljajo pri aplikacijah, ki jih je mogoče

hitro zgraditi in ne zahtevajo obsežnega zagotavljanja kakovosti. Kritični, zanesljivi in

varni sistemi so primernejši za tradicionalne metodologije. Če je projekt ključnega pomena

– kritičen, morajo biti vse zahteve dobro opredeljene že pred samim začetkom razvoja

programske opreme. Odgovor na spremembe je mogoče rešiti z uporabo agilnih načinov,

saj omogočajo boljše upravljanje sprememb s pomočjo povratnih informacij strank

(naročnika) in kratkim iterativnim razvojem.

Povzetek zapisanega je predstavljen v Tabeli 2, kjer so prikazani glavni razlogi za izbiro

agilnih ali tradicionalnih metodologij. Tabela vključuje sklop pogojev, pod katerimi je

uspeh verjetnejši.

Tabela 2: Projektne značilnosti agilnih in tradicionalnih metodologij

Projektne značilnosti Agilne metode Tradicionalne metode

Primarni cilj hitra vrednost visoka zanesljivost

Zahteve v veliki meri hitre,

nepričakovane,

neznane spremembe

zgodaj poznane in v veliki meri

stabilne zahteve

Velikost majhne skupine in projekti večje skupine in projekti

Arhitektura zasnovano za trenutne zahteve zasnovano za sedanje in

predvidljive zahteve

Planiranje in nadzor notranji načrti, nadzor

kakovosti

dokumentirani načrti,

količinski nadzor

Stranke posvečanje stranki, izobražene,

sodelujoče

interakcija strank, ko je

potrebno, osredotočenost na

pogodbena določila

Razvijalci agilni, izobraženi, sodelujoči načrtno usmerjeni, ustrezno

usposobljeni za dostopanje do

zunanjega znanja

Obnova poceni draga

Tveganje neznana tveganja, velik vpliv dobro znana tveganja, manjši

vpliv

Vir: M. A. Awad, A Comparison between Agile and Traditional Software Development, 2005, str. 38.

33

4 PREDSTAVITEV METODOLOGIJE SCRUM

Metodologija Scrum se je razvila za uspešnejše upravljanje projektnega dela razvojnega

procesa. Scrum se osredotoča na delo posameznika v skupini za doseg zastavljenega cilja,

obenem pa ne določa uporabe specifičnih tehnik in tehnologij pri samem razvoju. Scrum

poudarja prožnost, prilagodljivost in ustvarjalnost. Cilj metode Scrum je agilni razvoj v

spreminjajočem se okolju sprememb.

Zgodovina razvoja Scrum-a sega že v leto 1986, ko se je razvil nov pristop za hiter in

prilagodljiv razvoj novih izdelkov. Leta 1993 pa je bila metodologija dokončno oblikovana

s strani Ken Schwa