UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Griša Černe

ČLOVEŠKI FAKTORJI PRI RAZVOJU PROGRAMSKE OPREME

Diplomsko delo

Maribor, avgust 2016

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Griša Černe

ČLOVEŠKI FAKTORJI PRI RAZVOJU PROGRAMSKE OPREME

Diplomsko delo

Maribor, avgust 2016

I

ČLOVEŠKI FAKTORJI PRI RAZVOJU PROGRAMSKE OPREME

Diplomsko delo

Študent: Griša Černe

Študijski program: univerzitetni študijski program

Računalništvo in informacijske tehnologije

Mentor: red. prof. dr. Peter Kokol

Lektor: Drago Meglič, prof.

II

III

Človeški faktorji pri razvoju programske opreme

Ključne besede: človeški, faktorji, razvoj, programska, oprema.

UDK: 004.4'2/'6(043.2)

Povzetek

Človeški faktorji pri razvoju programske opreme pridobivajo vedno večji pomen. Sodobne

ideologije človeka uvrščajo v središče svojih temeljnih načel. Dosedanje študije na tem

področju se večinoma osredotočajo le na posamezne človeške faktorje v povezavi z

razvojem programske opreme, primanjkuje pa popolne literature, ki bi ponudila celovit

pregled nad vsemi faktorji. V nalogi je bila analizirana obstoječa literatura z namenom

predstavitve teh dejavnikov. Raziskani so bili tradicionalni pogledi na razvoj programske

opreme in vzroki, ki so privedli do razvoja sodobnih metodologij. Vključeni sta bili analiza

različnih metodologij ter njihova uporaba v sodobnih podjetjih. V sklopu projektnega in

timskega dela so bili predstavljeni razvoj timov, lastnosti in upravljanje timov ter vpliv

človeških faktorjev (npr. osebnostnih lastnosti) na timsko delo, prav tako pa tudi

najpomembnejše posledice razvojnega dela na zdravje ljudi in aktualna tehnika upravljanja

časa, imenovana pomodoro.

IV

Human factors in software development

Key words: human, factors, software, development.

UDK: 004.4'2/'6(043.2)

Abstract

Human factors are gradually gaining in importance in relation to software development.

People are becoming the heart of modern ideologies and their core principles. The studies

to date are mostly concerned with specific human factors in relation to software

development, but there is significant lack of complete studies which discuss and study all

human factors. In the present thesis I have analyzed the current literature available on this

topic with the sole intention of identifying and exploring the most important human aspects.

Through the study of the traditional ideas on software development I have identified the

major causes which inspired the development of modern methodologies. The review of agile

methodologies and modern companies who use them illustrates the current state of the

world of software development. From methodological views to more practical aspects of

software develoment work, projects and teamwork are the foundation of modern intelectual

work. I have studied the development stages of teams, characteristics of teams and modern

approaches to managing software development teams. My focus was also on different

factors, significant for the performance of software development teams (such as

personality) and actual health problems or disorders related to this kind of work. Lastly, the

time management technique called Pomodoro was also researched.

V

KAZALO VSEBINE

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

1.1 Splošen opis raziskovalnega področja ................................................................... 1

1.2 Namen in smisel dela ............................................................................................. 2

1.3 Kratek opis sestave/strukture dela .......................................................................... 3

2 RAZLIČNI POGLEDI NA RAZVOJ PROGRAMSKE OPREME .................................. 5

2.1 Spremembe, znanje in učenje ................................................................................ 5

2.2 Ostali vidiki RPO .................................................................................................... 6

3 TRADICIJA, VZROKI IN PREHOD NA SODOBNE IDEJE ......................................... 8

3.1 Tradicionalno razmišljanje ...................................................................................... 8

3.2 Kaskadni model ...................................................................................................... 8

3.3 Problemi in vzroki za razvoj novih idej .................................................................... 9

4 NASTANEK IN POMEN AGILNIH IDEJ ................................................................... 13

4.1 Začetki in Agilni manifest ...................................................................................... 13

4.2 Pomen.................................................................................................................. 13

4.3 Vidik razvijalcev in vidik stranke ........................................................................... 14

4.4 Lastnosti in pogoste prakse .................................................................................. 14

4.5 Prednosti in koristi ................................................................................................ 20

4.6 Slabosti in težave ................................................................................................. 21

4.7 Razlogi za neuspeh agilnih projektov (najpogostejše napake) .............................. 22

4.8 Pregled metodologij.............................................................................................. 23

VI

4.9 Najboljša metoda? ............................................................................................... 29

4.10 Uporaba v sodobnih podjetjih ............................................................................... 30

4.11 Uporaba v drugih industrijah ................................................................................. 32

4.12 Agile in lean – pojma, ki sta pogosto napačno interpretirana ................................ 33

5 TIMSKO DELO ........................................................................................................ 37

5.1 Kdo so razvijalci programske opreme? ................................................................. 37

5.2 Pomen timov ........................................................................................................ 37

5.3 Tuckmanove faze ustanovitve tima ...................................................................... 38

5.4 Potrebne lastnosti timov ....................................................................................... 41

5.5 Vpliv osebnosti ..................................................................................................... 42

5.6 Upravljanje timov .................................................................................................. 44

5.7 Komunikacija in zaupanje ..................................................................................... 49

5.8 Vpliv raznolikosti in avtonomnosti na agilnost timov ............................................. 50

5.9 Zdravje zaposlenih na področju razvoja programske opreme ............................... 50

5.10 Učinkovito upravljanje časa – pomodoro tehnika .................................................. 52

6 SKLEP ..................................................................................................................... 54

VII

KAZALO SLIK

SLIKA 3.1 – KASKADNI MODEL [47] ....................................................................................... 9

SLIKA 4.1 – SCRUM MODEL [66] ......................................................................................... 25

SLIKA 4.2 – KONCEPTUALNI PRIKAZ IDEJ IN METODOLOGIJ [22]............................................. 35

VIII

SEZNAM UPORABLJENIH KRATIC

RPO – razvoj programske opreme

PO – programska oprema

ČF – človeški faktorji

R-IT – računalništvo in informacijske tehnologije

IT – informacijske tehnologije

IČR – interakcija med človekom in računalnikom

ZVS – znanje, veščine, sposobnosti

XP – ekstremno programiranje (extreme programming)

DVI – delo v izvajanju (work in progress)

TDD – test driven development

FDD – feature driven development

RUP – rational unified process

EssUP – essential unified process

AUP – agile unified process

1

1 UVOD

1.1 Splošen opis raziskovalnega področja

Naslov diplomske naloge lahko razdelimo na dva smiselna dela, torej »človeški faktorji« in

»razvoj programske opreme«. Oba pojma sta računalniškim strokovnjakom tako teoretično

kot praktično dobro poznana, manj pojasnjen pa je odnos med njima. Za začetek bomo

predstavili vsakega posebej, nato pa se bomo posvetili povezavam.

»Človeški faktorji (ali ergonomija) predstavljajo znanstveno disciplino, ki se ukvarja z

razumevanjem interakcije med ljudmi in drugimi elementi sistema; ter poklic, ki uporablja

teorijo, načela, podatke in ostale metode za oblikovanje z namenom optimizacije dobrega

počutja ljudi in vsesplošne učinkovitosti sistemov.« [1]

Poenostavljeno povedano gre za uporabo informacij o fizičnih in psiholoških lastnostih ljudi

pri oblikovanju naprav in sistemov za človeško uporabo. [2] Predstavljena definicija je precej

splošna in vzbudi asociacije na različne vidike, ki bi jih omenjena stroka lahko obravnavala.

Slovenski veliki leksikon [3] ergonomijo opisuje kot sintezo bioloških, družboslovnih in

tehničnih ved, povezano z antropometrijo ter upoštevano v industrijskem oblikovanju.

Za ustrezno pojasnitev pojma RPO (razvoj programske opreme) je najprej treba razumeti

pojma »razvoj« in »programska oprema«. »Razvoj se nanaša na sistematično uporabo

znanstvenega ali tehničnega znanja za izpolnjevanje določenih zahtev ali ciljev.« [4] Gre za

»dejanje ali proces rasti oz. za povzročanje nečemu, da raste, se povečuje ali postaja bolj

napredno.« [5] Z rahlo drugačnega vidika predstavlja »proces ustvarjanja nekega produkta

v določeni časovni periodi.« [5]

Programsko opremo pa si lahko predstavljamo kot zbirko programov, procedur, pravil in z

njimi povezano dokumentacijo, ki uporabniku omogočijo interakcijo z računalnikom (strojno

opremo) in opravljanje raznovrstnih nalog. Brez PO (programske opreme) bi bili računalniki

popolnoma neuporabni. [6] [7] Poznamo dve poglavitni vrsti PO: sistemski PO in

uporabniški (aplikacijski) PO. Sistemski PO v glavnem služi za komunikacijo s strojno

opremo (npr. operacijski sistem), medtem ko uporabniški PO uporabnikom omogoča

opravljanje različnih nalog (npr. urejevalniki besedila). Obe vrsti PO skupaj določata

2

računalnikom (v fizičnem smislu) neprecenljivo vrednost tako za delo kot tudi za zabavo.

[8]

Naslednji pojem, ki ga je treba razjasniti, je proces razvoja programske opreme. Pojem se

nanaša na postopek izdelovanja funkcionalne računalniške programske opreme skozi

specializiran, sistematičen proces, ki je običajno sestavljen iz zaporednih faz. Te faze

vključujejo raziskave, prevajanje uporabniških potreb v programske zahteve, transformacijo

programskih zahtev v oblikovno zasnovo (dizajn), programiranje, izdelavo prototipov,

testiranje in vzdrževanje. [9] [10] [11] RPO je torej niz zapletenih procesov, ki potrebe

uporabnikov prevede v končni programski izdelek. [12]

Treba je omeniti, da so navedeni koraki zgolj najpogostejši in ne predstavljajo celotnega

procesa RPO, temveč le služijo za lažjo predstavitev omenjenega procesa. Prav tako je

pomembno dejstvo, da si omenjene faze ne sledijo nujno v tem zaporedju. RPO je zgolj

koncept, ki označuje proces od zamisli do končnega izdelka, medtem ko ostale lastnosti

procesa določajo posamezne metodologije in pristopi. [10] Metodologije RPO se ukvarjajo

z ustvarjanjem načrtov za RPO, določanjem posameznih korakov, aktivnosti in smernic, ki

jih je treba upoštevati. Posamezni koraki so strukturirani na način, ki omogoča merjenje

učinkovitosti. RPO je primarno človeška aktivnost oz. aktivnost, odvisna od ljudi [13], ki

zahteva uporabo sodobnih metodologij za razvoj robustne zasnove in uporabo sodobnih

tehnologij za implementacijo zasnove v končni izdelek, ki služi namenjeni uporabi. RPO je

torej proces »od ljudi za ljudi« [14], kar neposredno napeljuje na pomembnost upoštevanja

in raziskovanja povezave s človeškimi faktorji. Razumevanje ČF (človeških faktorjev) pri

RPO predstavlja temelj za učinkovit proces razvoja in posledično kakovosten in uporaben

končni izdelek. [15]

1.2 Namen in smisel dela

Namen diplomskega dela je identifikacija, raziskava in predstavitev ČF, ki na pomemben

način vplivajo na RPO. Po obsežnem študiju literature smo opazili, da je tema relativno

slabo raziskana. Obstajajo sicer študije, ki raziskujejo določene ČF v povezavi z RPO, a ne

upoštevajo vseh možnih faktorjev, temveč samo posamezne vidike. [16] [17] Kljub znanemu

dejstvu, da ČF na pomembne in raznolike načine vpliva na RPO, in zaradi mnogih neuspelih

projektov je potreba po poglobljenih raziskavah na tem področju izredno velika. Po dodatnih

raziskavah kličejo predvsem pozne faze RPO in z vzponom sodobnih metodologij tudi

medosebne interakcije. [18]

3

Vse večja aktualnost omenjenih problematik se pokaže tudi pri iskanju literature. Iskanje

besedne zveze »software development and human factors« je v letu 1989 vrnilo 15

zadetkov, leta 1992 35, leta 1995 84, leta 2007 pa 150,000. [19] Iskanje iste besedne zveze

po literaturi sistema UKM v letu 2016 je vrnilo 1,893,734 zadetkov. [20] Število raziskav

torej ustrezno raste, a kot smo že omenili, glavna težava tiči v pomanjkanju popolnih

raziskav, ki bi zajele vse faktorje in ustvarile ustrezno osnovo za nadaljnje študije. Težave,

povezane z ljudmi, igrajo osrednjo vlogo pri uspešnosti projektov RPO, kar še dodatno

utemeljuje potrebo po raziskavah, ki bi lahko ne samo izboljšale obstoječih procesov RPO

in mer uspešnosti projektov [21], temveč mnogim podjetjem zagotovile tekmovalno

prednost, kar je ena izmed glavnih gonilnih sil razvoja v poslovnem svetu. [22] Omenjeno

pomanjkanje raziskav in predvsem zanimanje za človeške vidike RPO sta glavna vzroka

izbire teme raziskovanja za diplomsko delo.

1.3 Kratek opis sestave/strukture dela

Človek se v konceptu RPO pojavlja v vlogi razvijalca, stranke, uporabnika ali upravitelja.

[18] Te vloge in povezave med njimi smo uporabili pri zasnovi diplomskega dela. V začetku

smo se osredotočili na lastnosti sodobne družbe in poslovnega sveta in na načine, kako se

ti odražajo v različnih ideologijah RPO. Da bi identificirali čim več povezav s ČF, smo iz

različnih vidikov poglobljeno raziskali pojem RPO.

Podali smo se do korenin metodologij RPO, ki ležijo v akumulaciji znanja in spremembah

(se pravi nenehnem učenju in oplajanju znanja), s kratkim zgodovinskim pregledom, in sicer

od tradicionalnega razmišljanja (kaskadni model) pa vse do agilnih in vitkih (lean) idej in

pristopov, ki temeljijo na njih. Osredotočili smo se na vzroke za vse manjšo uporabo

tradicionalnih pristopov in prihod sodobnih agilnih in vitkih konceptov, ki so s človekom v

središču v koraku s časom in sledijo hitrim spremembam modernega sveta. Odločili smo

se za poglobljeno analizo agilnih idej in različnih pogledov nanje ter raziskali pogostokrat

neustrezno interpretirano povezavo agilnega z vitkimi (lean) pristopi. [23]

Analizirali smo različne metode posameznih metodologij RPO, kot so npr. scrum,

ekstremno programiranje, kanban in druge, jih medsebojno primerjali in raziskali njihovo

učinkovitost in primernost za določene situacije ali okolja, v katerih razvoj poteka. Zanimale

so nas tudi trenutna uporaba in uspešnost agilnosti v sodobnih podjetjih ter možne

izboljšave, ki bi odpravile določene slabosti.

4

Nato smo se iz konceptualnih in metodoloških vidikov preusmerili na bolj praktično

upodobljene človeške faktorje s pojasnitvijo, kdo sploh so razvijalci programske opreme, in

na njihovo povezavo z intelektualnimi delavci. [22] Osredotočili smo se na time, projektno

delo in upravljanje projektov. Timi v sodobnem svetu predstavljajo temelj raziskovanja, saj

lahko skupina ljudi z znanjem različnih disciplin doseže veliko več kot posamezniki sami.

[24] Za boljše razumevanje smo na začetku pojasnili razlike med skupinami in timi. Nato

smo se podali skozi faze razvoja timov ter sproti naslovili faktorje, ki v posameznih fazah

igrajo ključne vloge. Pozornost smo posvetili zlasti različnim osebnostim posameznikov in

njihovemu vplivu na uspešnost projektnega dela. V nadaljevanju smo predstavili težave v

komunikaciji, konflikte, sodelovanje in razne rešitve, ki izboljšajo medosebno komunikacijo.

Analizirali smo tudi upraviteljski vidik, pomen avtoritete, vodenja in pooblaščanja tako

posameznikov kot timov. Izpostavili smo pomembne lastnosti, kot so poslušanje, razvoj

vodij in soočanje z multidisciplinarnostjo. Analizirali smo pojem visokoučinkovitih timov,

njihovih lastnosti in razloge za uspešnost. Analizirali smo tudi vpliv in posledice dolgoročne

in intenzivne uporabe računalnikov, ki pestijo tako razvijalce kot uporabnike PO. [25] [26]

Med temi smo se osredotočili zlasti na mišično-skeletna obolenja, težave z vidom in

mentalno izgorelost. [27] [28]

Analizirali smo trenutno aktualno orodje učinkovitega upravljanja časa, imenovano

»Pomodoro technique« (pomodoro tehnika) in njeno uporabnost pri posameznikih, timih in

organizacijah, ki se ukvarjajo z RPO.

5

2 RAZLIČNI POGLEDI NA RAZVOJ PROGRAMSKE OPREME

2.1 Spremembe, znanje in učenje

»RPO je v osnovi praksa učenja. Do učenja pride znotraj timov, upraviteljev in med ljudmi,

ki PO uporabljajo. S prepoznavanjem tega vidika izboljšamo razumevanje o procesu in ga

lahko posledično naredimo učinkovitejšega. Da prepoznamo vrednost učenja, je potrebno

uvesti spremembe: spremeniti moramo naše delo, način dela in razmišljanje. Brez

sprememb namreč ne more priti do učenja, kaj šele do polnega izkoristka znanja. Proces

učenja in spreminjanja je torej oblika ustvarjanja znanja; znanje v osnovi pa je učenje

povezano z dejanji – s spremembami.« [22]

Hitrim spremembam smo priče na vseh področjih sodobnega sveta, na področju tehnologije

pa še toliko bolj. S pomočjo tehnologije in programskih orodij si želimo osmisliti in obogatiti

vsakdanje življenje, olajšati komunikacijo in zagotoviti nenehen tok različnih informacij. [29]

RPO je intenzivna intelektualna aktivnost in spada v t. i. industrijo znanja. [30] Zato je za

potrebe razumevanja procesa RPO pomembno razumeti pojem znanja. [29] Znanje je

opredeljeno kot razumevanje oz. seznanjenost z dejstvi, resnico, znanimi načeli, s celoto

informacij in logičnih povezav med njimi, ki si jih človek vtisne v zavest z učenjem in/ali

izkušnjami. [3] [31] [32] Znanje je torej neekzakten koncept, odvisen od subjektivnih

lastnosti posameznika (ali organizacije) ter okolja, v katerem se razvija. [22] Ne more se

razvijati v neustreznem okolju; v kolikor ga želimo nadgrajevati, mora biti ustrezno podprto

in negovano. Prav tako se razlikuje od informacij; je rezultat naše interpretacije dogodkov

in kot tako vpliva na našo perspektivo in namene. [22] Informacija po drugi strani pa je

objektivnejša in predstavlja zgolj podatek, na osnovi katerega si posameznik izdela sliko o

svetu. [3] Neuporaba ali nevzdrževanje znanja lahko pomeni potencialno izgubo znanja.

Razmišljanje, aktivna uporaba in povezovanje znanja z dejanji ustvarjajo novo znanje. Brez

aktivnega, zavestnega razmišljanja znanje ostaja v mirujočem stanju. [22]

Učenje je človeški naravi imanentno. Sposobnost hitrejšega in učinkovitejšega učenja v

primerjavi z živalmi je eden izmed razlogov, da smo se ljudje razvili tako hitro in toliko bolje

v tako kratkem času. Enako velja za RPO. Tisti, ki uživajo v učenju in jih k učenju spodbuja

notranja motivacija, so uspešnejši kot tisti, ki se učenju upirajo oz. se učijo zgolj zaradi

zunanjih spodbud. Konstanten razvoj novih tehnologij in aplikacij zahteva aktivno in obširno

6

učenje. Notranje motivirani ljudje so produktivnejši in zadovoljnejši z opravljenim delom, kar

na splošno vpliva na boljše subjektivno počutje in samopodobo. [22]

Celoten proces RPO je poskus kodiranja znanja. Razvoj lahko predstavimo z znamenito

prispodobo »ledene gore« ‒ vrh predstavlja končen, uporaben del, ki ga vidi in uporablja

stranka oz. uporabnik, medtem ko je preostali, globlji, večji in zapletenejši del pod gladino

viden le razvijalcem PO. [22] Proces RPO nam omogoča prenos »vsakdana« v tehnologijo.

[29]

2.2 Ostali vidiki RPO

S sociološke perspektive lahko na RPO gledamo kot na aktivnost, na katero vplivajo osebni

[33] in skupinski [34] faktorji. Nekateri raziskovalci trdijo, da naj bi imeli socialni procesi večji

vpliv na kakovost PO, kot ga imajo metodologije razvoja ali avtomatizacija. Družbena

narava RPO in narava njene uporabe nakazujeta uporabnost sociologije pri razumevanju

vidikov RPO. Programerji ne delujejo izolirano, temveč med seboj komunicirajo o tehničnih

vidikih svojega dela. Razvijalci PO s tehničnimi povezavami tvorijo socialne mreže. Med

delom v timih medsebojno vplivajo drug na drugega z znanjem iz svoje domene (stroke,

discipline) in osebnimi programerskimi tehnikami in stili. [35] Na RPO lahko torej gledamo

kot na temeljni družbeni proces, vključen v organizacijskih in kulturnih strukturah. [36] Te

družbene strukture omogočajo, omejujejo in oblikujejo obnašanje, znanje, programske

tehnike in stile razvijalcev PO. [37]

Organizacijski vidiki RPO vključujejo strukturo organizacije, strukturo upravljanja, poslovni

model ... Za organizacijske faktorje velja, da so pogostokrat oblikovani kot Conwayev

zakon, ki pravi, da bodo »organizacije, ki oblikujejo sisteme, neizogibno proizvedle takšno

strukturno zasnovo, ki je kopija komunikacijske strukture te organizacije«. [38] V splošnem

Conwayev zakon razlaga, da vsak del PO zrcali organizacijsko strukturo, ki ga je proizvedla.

[36] To pomeni, da lahko na podlagi analize arhitekture PO sklepamo o organizacijski

strukturi in družbeni klimi razvojnega tima oz. organizacije. [36]

Odločitve o zasnovi PO so pogosto osnovane na psiholoških razlogih (utemeljitvah,

načelih), namesto da bi bile v celoti osnovane na računskih in fizičnih faktorjih. [39]

Razvijalci PO pogosto razmišljajo o obnašanju programov v mentalnem ali antropomorfnem

smislu (npr. kaj določena komponenta »ve« ali »hoče narediti«) ‒ v nasprotju s formalnim,

logičnim ali matematičnim pomenom. [34]

7

Za popolno razumevanje odnosa med PO in programerskimi mislimi in dejanji je najprej

treba razumeti odnos med PO in kulturo razvijalca/-ev. [40] Izboljšanje procesov RPO

zahteva razumevanje družbenega konteksta ter praks in občutljivosti, ki se nanj nanašajo.

[41] S prilagajanjem PO ostalim kulturam je bila osredotočenost večino časa pretežno na

uporabniškem vmesniku (internacionalizacija PO). Sodobne teorije pa kažejo, da

uporabniški vmesnik ni edini faktor, ki ga je treba prilagoditi, temveč je treba glede na kulturo

spremeniti tudi razvojne procese in metodologije. [42] Metode ali pristopi, ki so v neki kulturi

znani kot dobri in učinkoviti, so lahko v drugi popolnoma neučinkoviti ali za implementacijo

problematični. Pomembno vlogo igra tudi narodnost. Raziskovalci so s študijo primernosti

različnih metodologij PO za ameriške in japonske time ugotovili, da so ameriški timi

primernejši za iterativne, inkrementalne pristope, medtem ko japonski bolj za tradicionalne

pristope (kaskadni model). [43]

8

3 TRADICIJA, VZROKI IN PREHOD NA SODOBNE IDEJE

3.1 Tradicionalno razmišljanje

Tradicionalna ideologija temelji na pristopu podrobnih vnaprejšnjih zavez, kot so letna

poročila, letne razporeditve proračuna, napovedi prodaje, poslovni načrti, marketinški načrti

in kadrovske strategije – vse to je v osnovi narejeno, preden se dejansko delo začne. Od

posameznih oddelkov v organizacijah se pričakujejo razumne in realne napovedi delovne

obremenitve, kadrovskih zahtev, uporabe proračuna in pričakovanih izidov takoj na začetku

cikla razvoja. Upravitelji in ostali nosilci odločitev so nato ocenjeni glede na to, kako dobro

ta pričakovanja izpolnijo. [44]

3.2 Kaskadni model

Kaskadni model (waterfall) je prva in najbolj poznana metoda RPO. Ustvarili so ga

programerji ameriške vojske v 70. letih prejšnjega stoletja, predstavlja pa enostaven pristop

k RPO [10], v katerem različne discipline delujejo koračno po principu štafete: strategija,

zasnova interakcije, zasnova izgleda (vizualni dizajn), kodiranje, testiranje in dostava (Slika

3.1). [45] Število faz je odvisno od specifične metode kaskadnega modela. [46] Ob zaključku

vsake posamezne faze nosilci odločijo, ali je rešitev za prehod v naslednjo fazo ustrezna.

To prepreči potencialno nazadovanje in ohranja projekt v smeri napredka. Prva koraka v

razvoju po kaskadnem modelu sta identifikacija funkcionalnih potreb, ki jih mora PO

izpolnjevati, in dokumentiranje osnovnega namena, ki mu bo PO služil. Nato se prične

analiza tehničnih zahtev, potrebnih za učinkovito opravljanje predvidenega namena. V

naslednjem koraku se izdela osnovna zasnova (dizajn) PO. Zatem se začne dejanski razvoj

oz. programiranje. Po ustrezni implementaciji programske kode se opravi testiranje in v

primeru uspešnosti izdaja končnega izdelka. Po dostavi PO morajo razvijalci zagotoviti

nadaljnjo učinkovitost in uporabnost s potrebnim vzdrževanjem. [10]

9

Slika 3.1 – kaskadni model [47]

Prednosti kaskadnega modela se kažejo predvsem v enostavnem načrtovanju

(obojesmernim) in implementaciji, pridobitvi oprijemljive rešitve ob koncu vsake faze in

sposobnosti vnaprejšnje vizualne predstave končnega produkta. [46] »Pristop bo deloval

brez večjih problemov v primeru, da stranka točno ve, kaj želi, da razvijalci točno vedo, kako

lahko to naredijo, in da se v času projekta nič ne spremeni.« [48]

3.3 Problemi in vzroki za razvoj novih idej

Tradicionalni pristop, imenovan kaskadni model, je prvi opisal W. W. Royce v svojem članku

z naslovom »Managing the Development of Large Software Systems« iz leta 1970. [49]

Royce v njem razloži, da čeprav bi bilo smiselno delovati po ustaljenem sekvenčnem

postopku (določanje sistemskih zahtev, razvoj programskih zahtev, analiza zahtev,

oblikovanje zasnove programa, programiranje in na koncu testiranje in dostava), takšen

pristop predstavlja veliko tveganje in teži k neuspehu. [49] Kot glavno tveganje izpostavi,

da se razlike med razvitim sistemom in pričakovanji na podlagi predhodne analize

razpoznajo šele v fazi testiranja, ki pride na vrsto na koncu razvojnega procesa. To pomeni,

da je v primeru večjih razlik med dejanskim in načrtovanim PO treba izvesti veliko in

zahtevno preoblikovanje. Lahko se spremenijo zahteve sistema ali pa je treba opraviti

bistvene spremembe v zasnovi PO. Če se v fazi testiranja ugotovi, da so nujne korenite

spremembe PO, se lahko pričakuje do 100-odstotna prekoračitev časa in proračuna. Royce

zato priporoča pričetek snovanja oblike pred analizo zahtev kljub tveganju, da bo ta

10

napačna. Zagovarja večkratno ustvarjanje sistema. Priporoča formalno vključevanje

stranke od začetnih faz projekta naprej, saj so lahko dejanske funkcionalnosti in zmogljivosti

PO v času razvoja različno interpretirane. [49] [50]

Tradicionalni projekti so se preveč zanašali na serijski oz. koračni razvoj. Ena aktivnost je

morala biti popolnoma zaključena, da se je lahko pričela druga. Dizajn se ni mogel pričeti,

če ni bila pred tem narejena analiza zahtev ali ni bilo opravljeno testiranje, preden je bilo

programiranje končano. Namen tradicionalnih pristopov v IT-industriji je bil zmanjšanje

poslovnega tveganja in časa dostave izdelka, tako da je vsak korak, preden se je lahko

pričel naslednji, odobril in opravil menedžment (tj. upravitelji). [44]

Industrija v 90. letih prejšnjega stoletja je bila prežeta z izredno visoko stopnjo neuspešnosti

projektov RPO. Najpogostejše težave, s katerimi so se organizacije soočale, so bile

predvsem [44]:

zamujeni roki,

prekoračeni proračuni,

pomanjkljivi (nizkokakovostni) rezultati/izdelki in

nezadovoljne stranke.

Strokovnjaki na področju R-IT so zato pričeli s prepoznavanjem in z raziskovanjem vzrokov

takšne mere neuspešnosti. Izkazalo se je, da kaskadni model vsebuje določene iluzorne

predpostavke, kot npr. prepričanje o tem, da so natančne zahteve v celoti znane v naprej,

da je dokumentacija popolna in da razna orodja, kot so »gantt« ali »pert« diagrami,

omogočijo kontrolo nad projektom. To tradicionalne prepričanje se je v večini primerov

izkazalo za napačno, kar je predstavljalo velike težave pri projektih vseh velikosti. [22] S

prepoznavo napačnih predpostavk oz. prepričanj so strokovnjaki lahko določili specifične

vzroke, odgovorne za tako obsežno neuspešnost. Kot glavne so prepoznali naslednje [44]:

pretirano načrtovanje (dokumentacija),

neustrezna in neučinkovita komunikacija,

zanemarjanje odzivnosti na tekoče/aktualne spremembe v času razvoja in

neupoštevanje uporabniških povratnih informacij v razvoju.

Prekomerna načrtovanje in dokumentacija

Prevelika količina dokumentacije in predvidevanj je dajala strankam lažne občutke varnosti

in jamstva za uspešen RPO. [44] Pisanje dokumentov je v nekaterih primerih predstavljalo

11

obliko »skrivanja« informacij in razpršenosti posameznih podatkov. Kupi dokumentacije so

ostajali neprebrani. Čas, ki je potreben za branje dokumentacije, je namreč pomenil

sorazmerno zakasnitev dejanskega dela. [22] Zaradi v naprej določenih lastnosti je

projektom primanjkovalo odzivnosti na tekoče spremembe v uporabniških potrebah,

zahtevah trga, razpoložljivosti notranjih sredstev in zmožnostih temeljnih tehnologij, kar je

resno vplivalo na čas razvoja, stroške in kakovost končnega izdelka. [44] [46] Npr. lahko se

zgodi, da se med izvajanjem projekta spremenijo deli prvotnega načrta − pojavijo se nova

poslovna pravila ali omejitve, spremeni se strategija podjetja ipd. [45]

Prav tako sta problem predstavljali nagnjenost deležnikov k nejasnim in nerealnim

zahtevam in na splošno neizogibna neskladnost tekstovnih opisov (predpostavk) z

dejansko razvitim PO. [44] Za določene funkcionalnosti in cilje se namreč pogosto izkaže,

da so odvisne od česa, kar prepoznamo šele v poznih fazah razvoja, npr. razvijalec ugotovi,

da je določena funkcionalnost v resnici izjemno zapletena (kompleksna) za

implementiranje, ali pa urednik opazi, da zasnova ne ustreza zahtevam. [45] Podjetja so

bila zato že v osnovi obsojena na neuspeh in so zaradi tega izgubljala milijonske posle. [44]

Neustrezna in neučinkovita komunikacija

Naslednji pomemben faktor je bila neustrezna in neučinkovita komunikacija. Ločevanje

tehnološkega sektorja od ostalih gospodarskih sektorjev je v tradicionalnem razmišljanju

predstavljalo normo. To je pomenilo slabo oz. nezadostno komunikacijo med obema

sektorjema ter posledično neustrezne tehnološke rešitve. Razvoj je torej potekal brez

sodelovanja naročnikov in IT-strokovnjakov − ti so zgolj prejeli podrobna navodila o

želenem izdelku in morali samostojno implementirati rešitev, ki je bila stranki predstavljana

šele v končni fazi. Omenjena izolacija je predstavljala enega izmed poglavitnih vzrokov, saj

so bile uporabniške zahteve skoraj v celoti prepuščene samostojni interpretaciji znotraj

timov, brez ustreznega razumevanja poslovnega okolja uporabe. Vse to je pripomoglo k

razvoju PO, ki je bil pogosto neusklajen s potrebami poslovnih uporabnikov/strank in je

vseboval neustrezne funkcionalnosti, sistemske napake in kritične napake v oblikovnih

lastnostih. Spremembe in popravila omenjenih posledic so bila draga in tudi časovno

neekonomična, zato je to pomenilo ali neuspeh projekta ali pa velike prekoračitve proračuna

in časovnih omejitev. [44]

Komunikacija pa ni bila problem samo med razvijalci in poslovnim sektorjem, temveč tudi

znotraj razvojnih timov. V tradicionalnih pristopih so temelj sodelovanja predstavljali številni

12

dokumenti (zahteve, oblike, specifikacije ...), kar pa se je izkazalo za dvoumen in

neučinkovit način. Dokumentacija je predstavljala vir različnih interpretacij različnih članov

tima ali članov različnih disciplin znotraj tima, kar je vodilo do konfliktov, slabega

sodelovanja in do neučinkovitega dela razvojnih timov. [28]

Vključevanje uporabnikov šele v poznih ali končnih fazah razvoja

Problem je ležal tudi v zanemarjanju uporabniških povratnih informacij. Uporabniki so

namreč svoje mnenje lahko prispevali šele v poznih fazah projekta, ko je bilo vse nared za

testiranje [29], kar pa je velikokrat privedlo do nekakovostnih, neuporabnih funkcionalnosti

ali celotnih izdelkov.

Ostale slabosti

Pomembno slabost kaskadnega modela je predstavljalo neustrezno upravljanje tveganj in

izdatkov v času poteka projektov. Na visoko mero neuspešnosti projektov so vplivali tudi

drugi faktorji, med temi izstopajo predvsem tehnološke omejitve in pomanjkanje tehničnih

sredstev. Vendar so podjetja nad temi imela večjo moč in nadzor kot nad faktorji, ki so bili

zakoreninjeni v tradicionalnem razmišljanju. [44]

13

4 NASTANEK IN POMEN AGILNIH IDEJ

4.1 Začetki in Agilni manifest

V prejšnjem poglavju analizirani problemi in vzroki so privedli do intenzivnega raziskovanja

področja R-IT in metodologij razvoja. Človeški faktorji so začeli pridobivati vedno večji

pomen in vedno večjo vrednost. Z identifikacijo poglavitnih faktorjev za neuspešne začetke

projektnega RPO so strokovnjaki pričeli z ustvarjanjem novih, sodobnih ideologij. Kot

odgovor na jasno izražene frustracije razvijalcev PO je v 90. letih prejšnjega stoletja nastalo

več alternativnih metodologij. Med njimi so bile scrum, ekstremno programiranje (XP),

dynamic system development method (DSDM), feature driven development (FDD) in

metode crystal. Omenjene metode so nosile podobne temeljne karakteristike, zato so jih

strokovnjaki začeli uvrščati »pod isto streho«. Agilni manifest [51], ustvarjen februarja 2001

po dvodnevni konferenci v Utahu, predstavlja rezultat sodelovanja miselnih vodij na

področju »lahkega« RPO. Glavni razlog nastanka je predstavljalo prioritiziranje

dokumentacije, načrtovanja, procedur, orodij, pogodb in hierarhij ljudi in izdelkov.

Sodelujoči so menili, da je takšno tradicionalno razmišljanje usmerjeno napak, zato so v

Agilnem manifestu s skupnimi močmi predstavili sodobno ideologijo, ki tradicionalne ideje

obrne na glavo. Zapisali so dvanajst načel agilnega RPO, ki povzemajo te nove ideje. [52]

Manifest [51]:

»posamezniki in interakcije« pred procesi in orodji,

»delujoča programska oprema« pred vseobsežno dokumentacijo,

»sodelovanje s stranko« pred pogodbenimi pogajanji in

»odziv na spremembe« pred togim sledenjem načrtom.

»Četudi cenimo dejavnike na desni, vseeno bolj cenimo tiste na levi.«

Agilni manifest torej v osnovi predpostavlja, da so osredotočenost na ljudi, ČF in delujoči

PO temeljnega pomena za uspeh. Vključene ideje in načela vrednotijo sodelovanje med

ljudmi in sprejemanje nenehnih sprememb višje kot orodja, dokumentacijo in ostalo

birokracijo. [53]

4.2 Pomen

»Agilnost je sposobnost ustvarjanja in odzivanja na spremembe z namenom izkoristka

turbulentnega poslovnega okolja.« [54] [22]

14

»Agilnost je ideologija, podprta z nizom vrednot in prepričanj, ki določa ciljno kulturo za

uspešen razvoj programske opreme.« [55]

Agilno predstavlja zbirko hevristik oz. splošnih prepričanj, ki so jih ljudje in podjetja

akumulirala iz izkušenj (učenje iz napak) [56] z namenom povečanja pomembnosti,

kakovosti, fleksibilnosti, učinkovitosti, enostavnosti in kot najpomembnejše rednega

dostavljanja delujočih programskih rešitev visoke poslovne vrednosti znotraj kratkih

časovnih okvirjev. [44] [52] Osnovano je na iterativnem, postopnem razvoju [57], ki se

načrtno izogiba vnaprejšnjemu določanju končnih podrobnosti. S sodelovanjem s strankami

in redno dostavo kakovostnih rešitev izdelka agilno zamenja tradicionalno vnaprejšnje

načrtovanje z inkrementalnim načrtovanjem, ki vključuje najsodobnejše tehnično, tržno in

poslovno znanje, ki je na voljo. To zagotavlja ustrezno vizijo (usmerjenost) izdelka skozi

celoten proces razvoja in hkrati redno dostavljanje visokokakovostnih delov končnega

izdelka. [44] Zahteve in rešitve se sproti razvijajo in izboljšujejo znotraj samoorganizirajočih

multidisciplinarnih timov. [57] Ideologija je osnovana na ideji konstantnega sodelovanja med

IT-strokovnjaki in poslovneži (strankami) – to je edini način, ki resnično zagotavlja ustrezno

sožitje med poslovnimi zahtevami in pobudami razvijalcev PO. [44] Agilno se odziva na

nepredvidljive spremembe z zanašanjem na ljudi in njihovo ustvarjalnost namesto na

procese in omeji razvoj striktno na aktivnosti, ki prinašajo poslovno vrednost strankam. [58]

4.3 Vidik razvijalcev in vidik stranke

Z agilnimi, sodobnimi pristopi se poslovni sektor zaveže k [22]:

tesnemu sodelovanju z razvojnimi timi,

zaupanju razvijalcem, da so sposobni opraviti dobro/kakovostno delo in

zagotavljanju sredstev za uspešno gradnjo/razvoj sistema.

V zameno za to se razvijalci zavežejo k [22]:

delu le na tistih funkcionalnostih, ki jih stranka dejansko želi in potrebuje,

prepuščanju prioritiziranja stranki na podlagi predlogov in dogovorov,

hitremu in rednemu dostavljanju delujočega PO in

delu v smeri najvišje poslovne vrednosti PO in rednemu upravljanju ter reševanju

tveganj.

4.4 Lastnosti in pogoste prakse

Sprejemanje hitrih (rapidnih) in pogostih sprememb v času razvoja

Ena izmed gonilnih sil agilnega so hitre in pogoste spremembe. Jasno je, da živimo v

obdobju, v katerem spremembe v tehnologiji, poslovanju, družbenih strukturah in človeških

15

odnosih dosegajo nepredstavljive nivoje. Hitre spremembe se dogajajo na vseh področjih

sodobnega življenja, še zlasti na področju RPO, ki je v modernih organizacijah vitalnega

pomena. Zato je jasno, da morajo nove ideje izkoriščati to lastnost in se boriti s hitro

spreminjajočim se načinom življenja. [28]

Vključevanje strank in uporabnikov v proces razvoja

Stranke so aktivno vključene v proces RPO. Napredek projektnega dela je za stranko zelo

pomemben, saj ona nosi odgovornost za posledice, ki bodo sledile uspešnosti projekta.

Stranke, ki sodelujejo s tradicionalnimi razvojnimi timi, so velikokrat neprepričane in slabo

informirane o dejanskem napredku razvoja. Agilne metode se soočajo s tem problemom z

aktivnim vključevanjem stranke v proces RPO in s konstantnim prilagajanjem

funkcionalnosti izdelka glede na spreminjajoče se zahteve, in sicer v nasprotju s

tradicionalnimi metodami, ki se zanašajo na nejasne predhodne abstrakcije, ki se velikokrat

izkažejo za napačne ali neustrezne. [28] Skozi razvoj ima naročnik jasen pregled nad

dejansko implementacijo in izgled funkcionalnosti, kar omogoča učinkovito sodelovanje in

ohranjanje izdelka na ustrezni poti proti končni, uporabni rešitvi. S konstantnim

pregledovanjem in z oblikovanjem funkcionalnosti v skladu s pričakovanji in mnenjem

stranke se razvijalci izognejo večjim in korenitim predelavam končnega produkta. [28]

Vključevanje uporabnikov v RPO je postalo neizogibna praksa za moderne razvijalce.

Programerji in matematiki ob zasnovi sodobnih programov ne zadostujejo več; nujno

potreben je tudi vnos človeških znanosti (npr. psihologija in sociologija) in faktorjev, ki PO

ustvarjajo na podlagi študij uporabnikov. [29] Uporabniki so prav tako aktivno vključeni v

pregledovanje in vrednotenje posameznih delov končnega izdelka ter s povratnimi

informacijami pomagajo ohranjati razvoj v pravi smeri.

Omenjeni praksi zagotavljata oblikovanje zahtev, prioritiziranje dela in

odobravanje/vrednotenje dostavljenih rešitev v iterativnih ciklih. Znotraj procesa je tim zato

bolje informiran o zahtevah, nejasnostih/dvoumnostih in je pripravljen na aktivno reševanje

sporov. [22] [52]

Optimiziranje preobsežne dokumentacije in ostale birokracije

Glavni razlog za zmanjšanje predhodnega pisanja dokumentacije leži predvsem v

predpostavki, da se bodo zahteve in pričakovanja v procesu razvoja spremenile. V

nasprotju s tradicijo agilno postopek dokumentiranja razporedi na celoten proces razvoja

16

[28] in se s tem izogne neskončnim kupom načrtovalne dokumentacije in specifikacijam, za

katere se na koncu pogosto izkaže, da stranki v dejanski implementaciji izdelka ne

ustrezajo. Kot posledica se prekoračijo časovne in proračunske omejitve. Še tako natančno

načrtovanje največjih strokovnjakov R-IT ne more predvideti vseh možnih sprememb in

situacij, do katerih lahko pride v razvoju. [44]

Agilni pristopi zato nadomestijo predhodno planiranje z inkrementalnim planiranjem,

osnovanim na sodelovanju med projektnim timom, stranko in uporabniki. To v času projekta

timu omogoča enostavno adaptacijo posameznih rešitev glede na mnenja strank in

uporabnikov. [44] S tem se izogne obširnim spremembam v poznih fazah projekta in

omogoči prilagodljivejšo in učinkovitejšo pisanje dokumentacije. [28] Ekipi v nasprotju s

pisanjem preobsežne dokumentacije prav tako omogoča osredotočenost vsakodnevnih

opravil na dejanski razvoj rešitev. [44] Ukvarjanje z dokumentacijo in ostalimi birokratskimi

procesi je namreč malokateremu razvijalcu v interesu, zato postopna razporeditev pisanja

dokumentacije predstavlja tudi izboljšano energijo znotraj tima. Veliko razvijalcev namreč

meni, da se z nujnimi birokratskimi procesi krati njihova ustvarjalna sposobnost, ki bi bila

lahko bolje izkoriščena v drugih procesih. Seveda je dokumentacija tisto »nujno zlo«, ki je

pomembno za uspešen in organiziran potek projektov, vendar to še ne pomeni, da jo je

treba zapisati vso naenkrat ali da je ni mogoče optimizirati. Agilni pristopi se aktivno soočajo

s to težavo in na ta način manjšajo demotivacijski vpliv na razvojno ekipo, prav tako pa tudi

izboljšajo vrednost dokumentacije in prihranijo čas in proračun. Dobra morala je vitalnega

pomena za visoko produktivnost ekipe in posledično kakovosten razvoj izdelka.

Dokumentacija je prav tako veliko odzivnejša na povratne informacije strank ali

uporabnikov, ki v procesu razvoja testirajo posamezne funkcionalnosti. Sam pojem

dokumentacije so tako agilni procesi prilagodili konstantnim in hitrim spremembam sodobne

družbe. [28]

Visoka produktivnost in hiter razvoj

Fokus agilnega predstavljata tudi visoka produktivnost in hiter razvoj. Konstantno razvijanje

polnofunkcionalnih, testiranih funkcionalnosti, pripravljenih za uporabo, omogoča

zaznavanje in reševanje uporabnostnih težav, kakor hitro je to mogoče. To predstavlja

preskok iz nenatančnega predvidevajočega razvoja na učinkovit iterativen razvoj. [44]

Osredotočenost na visokokakovostne rešitve

Pri visokokakovostnih sistemih je treba omeniti dva izstopajoča tipa težav [28]:

17

napake, povezane z zahtevami (računalniku naročimo napačno), in

operacijske napake (računalnik napačno interpretira tisto, kar smo mu naročili).

Obe težavi zahtevata kompleksno in zahtevno reševanje. Prva se navezuje na ključni

princip agilne ideologije − tesno sodelovanje in vključevanje stranke in uporabnikov v

proces RPO. Tekoča diskusija na podlagi iterativnih rešitev privede do nenehnih izboljšav

in ustrezno usmerjenega dela. Za dobro delo in izboljšave sta potrebna učinkovita

komunikacija in učinkovito sodelovanje. Le tako so spreminjajoče se zahteve stranke

pravilno razumljene. Agilni pristopi so sposobni prepoznavanja in vzdrževanja jasnega in

ustreznega razumevanja sistema v razvoju. Pravilen sistem pomeni nekaj, kar je ustrezno

in je stranka potrdila, ima ustrezne lastnosti in je razvito znotraj proračuna in časovne

omejitve. [28] Drugi problem kakovosti se nanaša na mero, do katere razvit sistem izpolnjuje

njene zahteve. Vzrok za to leži predvsem v prepoznem ali neustreznem testiranju in

vrednotenju izdelka. Primer pristopa, ki izboljšuje tradicionalen kaskadni model v smislu

rednega in učinkovitejšega testiranja, se imenuje »V-model«. [28]

Primer tehnike za izboljšanje kakovosti v agilnem pristopu ekstremnega programiranja (XP)

je »parno programiranje«, ki vključuje sprotno pregledovanje in vrednotenje kode.

Programiranje poteka v parih, po dva programerja si delita isti zaslon in tipkovnico.

Konstantno razpravljata o obliki in različnih pristopih ‒ medtem ko eden piše kodo, jo drugi

sproti pregleduje; nato periodično izmenjujeta vlogi. [22] [57] Treba je sicer izpostaviti, da

je tehnika parnega programiranja predmet mnogih polemik. Skeptiki namreč ne verjamejo

v izboljšanje produktivnosti, ker bi lahko oba programerja pisala kodo naenkrat. Nasprotno

zagovorniki govorijo o velikem dvigu kakovosti izdelka, večji osredotočenosti in težnji k manj

prekinitvam med delom. [22] Rezultati študij [14] [59] so pokazali, da je kakovost kode XP-

timov veliko večja kot kakovost kode timov, ki prakticirajo tradicionalne pristope. Z uporabo

tehnik zagotavljanja kakovosti se razvijalci izognejo brezglavemu reševanju in odpravljanju

težav v končnih fazah procesa RPO ter soočanje s težavami in tveganje razporedijo na

celoten proces razvoja. To pripomore k učinkovitejši izrabi časa in zmanjša zamudnost

opravil. [22]

Časovni okviri

Fiksne časovno omejene iteracije od dveh tednov do več mesecev (najpogosteje od dva do

tri tedne) omogočajo razdelitev celotnega razvoja na manjše dele. Delo, ki presega eno

iteracijo, se razdeli na manjše dele in razporedi v več iteracij. V nekaterih primerih so

posamezni iterativni rezultati objavljeni na »živem serverju« za takojšno uporabo. V drugih

18

pa so posamezne rešitve na voljo za pregled in vrednotenje samo stranke, ki nudi povratne

informacije, prilagaja zahteve in prioritizira opravila. [22]

Komunikacija in povratne informacije

Sodobni timi so multidisciplinarni, kar zahteva učinkovito komunikacijo. Posamezniki morajo

biti sposobni ustvariti lahkoten in neoviran pretok informacij in znanja z namenom sinteze

različnih disciplin in doseganja konstantnih izboljšav PO.

Agilne skupine ciljajo k izboljšani komunikaciji na različne načine [22]:

z uporabo različnih vizualnih načinov za vodenje napredka in osredotočanje na delo

(npr. table z lepljivimi listki, kartice kanban),

s sestanki ob vsaki iteraciji, obogateni z dnevnimi »stand-up« sestanki, omogočajo

in zagotavljajo ustrezno informiranost o aktualnem delu vsem članov,

s kratkimi iteracijami, s katerimi omogočajo večjo osredotočenost na delo pri roki in

tako poenostavijo proces komunikacije,

s konstantnimi pregledi opravljenega dela omogočajo kolektivno vrednotenje in

izmenjavo mnenj o opravljenem delu, kar zagotavlja višjo kakovost in konstantne

izboljšave ter

z rednim pridobivanjem povratnih informacij od strank in uporabnikov.

Človeški faktorji v agilnih idejah

Agilni timi so osnovani na vodenju in motivaciji. Produktivnost in odprta komunikacija

dosežemo z odkritostjo in s transparentnostjo informacij, z medsebojnim spoštovanjem,

zaupanjem, s samokontrolo, predanostjo skupnim ciljem in z interakcijo iz oči v oči.

Organizacije spodbujajo identifikacijo in odpravo ovir ter prost pretok idej (tudi s konflikti) z

namenom spodbujanja inovacij. [52] Konstantno vzdrževanje medsebojnih odnosov tako

znotraj tima kot tudi s strankami, z upravitelji in uporabniki je temeljnega pomena. Tehnike,

ki to omogočajo, so pogovarjanje v živo, predstavljanje svojega dela sodelujočim članom,

razpravljanje o ciljih in smernicah, analiza opravljenega dela na čim bolj odkrit način,

nudenje pomoči ostalim v primeru težav; skratka tehnike za ohranjanje pozitivnih odnosov.

PO je v osnovi komunikacija človek-računalnik-človek, kar še posebej izpostavi

pomembnost ČF v agilnih idejah.

Pogum

19

Pogum se nanaša na samozavest in prepričanje o delu RPO, ki je polno različnih tveganj.

Agilni pristopi so pogosto doživeti kot radikalne novosti, zaradi česar se veliko organizacij

izogiba njihovi implementaciji in raje ostaja v udobnem območju tradicionalnih pristopov

kljub ogromnemu potencialu, ki ga sodobne ideje predstavljajo. Vključitev nečesa novega

in temeljite spremembe tradicionalnega razmišljanja, ki nas spremlja že število let,

zahtevajo veliko mero poguma. Organizacije, timi in ljudje kot posamezniki sčasoma

razvijejo določene navade, ki jih je težko spremeniti. Ljudem je lažje in udobneje delovati

po ustaljenih načelih, ki jim že dalj časa sledijo, kljub vsem slabostim, ki jih spremljajo. A

prilagajanje je za preživetje ključno, zato je treba razvijati in spreminjati razmišljanje v

koraku s spremembami in s hitrim razvojem na področju tehnologije in z njo povezanih

znanosti. [28]

Spoštovanje

Najpomembnejša lastnost vseh skupinskih aktivnosti je odnos med sodelujočimi. Ogromno

problemov, ki se pojavijo v času RPO, ima vzroke v človeških težavah. Te se v splošnem

nanašajo na razmerja med člani timov ter med timi in uporabniki, menedžerji ali strankami,

lahko pa izvirajo tudi iz osebnih krogov, kot so prijatelji ali družina. Spoštovanje je zato

temeljna lastnost in predpogoj za učinkovito sodelovanje. Upoštevanje mnenja ostalih

članov, zlasti med predstavniki različnih disciplin, dajanje možnosti za izražanje

posameznikovega mnenja na miren in pozitiven način, aktivno in razumno delegiranje

dolžnosti in zaupanje v sposobnosti ostalih članov so ključnega pomena. Ohranjanje

pozitivne energije in kolektivnega duha je prvi in glavni korak k zagotavljanju ustrezne

atmosfere za učinkovit agilni RPO. [28]

Pooblaščanje

Agilni pristopi se pogosto osredotočajo na pooblaščanje timov, kar jim daje moč pri

reševanju medsebojnih problemov, ki nastanejo v času projektov. To pa seveda zahteva

določeno mero zrelosti in ozaveščenosti posameznikov o ostalih sodelujočih disciplinah

(članih). Učinkovita komunikacija tako znotraj tima kot s stranko je temeljnega pomena.

Tako obstaja velika možnost, da pri projektnem delu pride do konfliktov ali nespodobnega

vedenja. Za takšne primere je treba imeti pripravljene mehanizme, ki hitro in učinkovito

razrešijo težave in omogočijo nadaljnje delo. Primeri takšnih mehanizmov vključujejo

športno »obarvane« tehnike, kot so: rumeni in rdeči kartoni, vsem poznani z nogometnih

tekem, ali uporaba »sin-bin« metode kazni, ki se uporablja pri hokeju. Takšne tehnike

zahtevajo skupinsko (večinsko) odločitev, usmerjeno k cilju večje učinkovitosti. [28]

20

4.5 Prednosti in koristi

Strateške prednosti in koristi [44] [46]:

tekoče obvladovanje tveganja (redno potrjevanje in prilagajanje zahtev glede na

tekočo interakcijo s stranko),

tekoč nadzor nad proračunom (priložnost pregleda in ocene poslovne vrednosti

funkcionalnosti v vsaki iteraciji),

hitra dostava delujočih rezultatov (redna dostava polnodelujočih, testiranih in

pripravljenih funkcionalnosti končnega programskega izdelka),

močna konsistenca/uskladitev s poslovnimi zahtevami (neposredna vključitev

stranke v razvoj),

osredotočenost na funkcionalnosti višje prioritete (konstantno sodelovanje s stranko

in vrednotenje pomembnosti opravil),

odzivnost na poslovne spremembe in učinkovito soočanje z njimi,

visokokakovostne in uporabne rešitve (testiranje uporabnosti skozi proces razvoja,

vključevanje stranke in uporabnikov v proces),

učinkovita timska interakcija (samokontrola, samoorganiziranost in komunikacija v

strukturiranih kanalih omogoča spremljanje napredka, sodelovanja in hitro

prepoznavanje ovir ali tveganj),

večje zadovoljstvo zaposlenih (učinkovita komunikacija, razvoj zaupanja,

spodbujanje inovativnosti, pooblaščanje),

minimizacija stroškov (vključevanje uporabnostnih testov in tekoče reševanje

problemov ter tveganj zmanjšuje možnost prekoračenih rokov ali proračuna) in

nenehne izboljšave (učenje in apliciranje novega znanja v nadaljnjih iteracijah).

Taktične prednosti in koristi [44] [46]:

večja produktivnost na časovno enoto (večji izkoristek časa zaposlenih),

hitrejša razpoznava tehničnih težav,

manj predelav in nekoristnega/neuporabnega dela,

zmanjšana potreba po ustvarjanju in vzdrževanju podrobne dokumentacije,

večja fleksibilnost,

večja avtonomija zaposlenih,

veče zadovoljstvo zaposlenih,

večja možnost inovacije in

zmanjšana odvisnost od birokracije in poročil.

21

4.6 Slabosti in težave

Kljub vsem pozitivnim lastnostim, prednostim in koristim agilnih pristopov moramo

izpostaviti tudi težave in slabosti, ki jih spremljajo. Treba je razumeti, da agilni pristopi niso

popolni, ampak ponujajo tudi prostor za izboljšave. Gre zgolj za korak (skok) v pravo smer,

spremembo oz. razvoj, ki človeka in končni izdelek postavi v središče. V nekaterih primerih

preveliko zanemarjanje načrtovanja in dokumentacije ni učinkovito. Naslednjo večjo težavo

predstavlja konstantno poslovno zastopanje. Agilni postopki zahtevajo redno prisostvovanje

predstavnikov stranke, ki ovrednotijo posamezne rešitve, nudijo potrditve in ustrezno

usmerijo opravila nadaljnjih iteracij. To pa seveda pomeni, da mora imeti stranka

ustreznega, dovolj pooblaščenega posameznika, ki bo na voljo vedno, ko ga bo razvojni tim

potreboval. Časovno gledano se to večkrat izkaže kot problematično. [46]

Kot smo že pojasnili, so agilne metode prilagojene za okolja, kjer so primarnega pomena

povratne informacije. V primeru dela, pri katerem povratne informacije niso pomembne,

agilne metode niso tako uporabne. Kot primer lahko vzamemo razvoj protokolarnih,

formalnih specifikacij/procesov ali razvoj PO, ki je tako globoko vgrajen v nek drug sistem,

da ni več v interakciji z ljudmi. V to kategorijo sodijo npr. programske knjižnice. Pri razvoju

določenih sistemov je verjetnost tekočih sprememb tako majhna, da se agilnih pristopov

enostavno ne splača uporabiti. [60]

Velikokrat ni dovolj zgolj poznavanje agilnega manifesta in v njem vključenih principov.

Potrebna je seznanjenost z agilno ideologijo, prav tako pa tudi razumevanje namena,

pomembnosti medsebojnih odnosov in pomena koračnega razvoja na sploh. Čeprav agilni

pristopi spodbujajo zdravorazumskost in enostavnost, so v osnovi zapleteni.

Natalie Sirina [61] zapiše, da je »agilnost kot zdravilo za sodobna podjetja; lahko je grenko

ali neokusno, vendar ga je vseeno vredno poizkusiti.«

Četudi je splošno sprejeta, agilnost še vedno ostaja rahlo kontroverzna, in sicer predvsem

zaradi neuspehov na visoki ravni, kot sta primer FBI (Federal Bureau of Investigation) z

upravljavskim sistemom Path Forward [62] ali program za pokojninsko reformo Pensions’

Universal Credit' v Združenem kraljestvu. [52] Kritiki trdijo, da agilne metodologije niso

sposobne izpolnjevati svojih obljub o zmanjšanju stroškov in preprečevanju prekoračenih

rokov, medtem ko zagovorniki trdijo, da je to zgolj posledica nepravilne implementacije,

napačne interpretacije osnovnih principov in slabega razumevanja. [52]

22

4.7 Razlogi za neuspeh agilnih projektov (najpogostejše napake)

Agilno morda res ne predstavlja najprimernejšega pristopa za vsako organizacijo, a treba

je razumeti, da vzrok za neuspeh v številnih primerih leži v neustrezni implementaciji teh

pristopov. [44] Težave v večini primerov izvirajo iz kulture organizacije. Uspeh agilnih metod

zahteva močno izvršilno vodstvo, ustrezno usposabljanje in inštruiranje. [63] [64]

Spodkopavanje temeljnih principov

Najpogostejša napaka je uporaba agilnih pristopov na način, ki spodkopava njihove

temeljne principe. To je lahko npr. organizacija, ki se odloči za agilni razvoj, osnovan na

iterativnem delu, a kljub temu zahteva, da je vso delo v naprej odobreno v dokumentiranih

specifikacijah. Inkrementalno načrtovanje ima vrednost zgolj takrat, ko se je organizacija

pripravljena prilagoditi na tekoče, fleksibilno delo. V nasprotnem primeru iterativno delo

predstavlja zgolj krajše dostavne cikle, ki so omejeni na enak način. Agilno je zatorej

potrebno implementirati v skladu s temeljnimi načeli. [44]

Nekateri strokovnjaki pa omenjeno »težavo« spodbujajo ravno zaradi velike raznolikosti

organizacij, kultur in okolja, v katerem delujejo. Agilnega ne bi smeli dojemati kot striktne

doktrine, pač pa ideje prilagoditi lastnostim organizacije. Za največji izkoristek agilnih

metodologij je potrebno prilagajanje in spreminjanje praks v skladu z lastnimi potrebami

organizacije ali razvojnega tima. Vendar je ključnega pomena, da s kakršnim koli

spreminjanjem ne ogrožamo temeljnih principov agilnosti. Zato predlagajo implementacijo

»mešanice« pristopov, ki posamezni organizaciji najbolj ustreza. V takšnih primerih je

potrebno razrešiti možne konflikte med temeljnimi načeli posameznih pristopov in tako

ustvariti sintezo pristopov, ki najbolj ustreza lastnostim in okolju organizacije. [44] Zanimiv

pojem, ki se je razvil z ustvarjanjem sinteze med agilnimi in tradicionalnimi idejami, je

»wagile« (agile + waterfall). [46]

Neustrezna komunikacija

Agilni pristopi bodo ustrezno aplicirani, le če so udeleženci (stranke, menedžerji in člani

tima) dobro izobraženi o uporabljenih metodologijah in praksah. Smiselno je, da so

informacije za predhodno in sprotno izobraževanje dostopne na lokalnem deljenem

strežniku (ali podobni tehnologiji). Obstajajo tudi alternativne, bolj formalne možnosti, kot

so npr. tečaji za učinkovito vključevanje agilnih metod, ki nudijo formalne certifikate.

Pomanjkanje izkušenj z agilnimi pristopi

23

44 % udeležencev v anketi State of Agile [64] meni, da vzrok za neuspeh leži v pomanjkanju

izkušenj z agilnimi pristopi. Timi, ki nimajo izkušenj ali imajo pomanjkljive izkušnje, tvegajo

neuspeh, zato obstajajo razna praktična usposabljanja, ki time pripravijo na učinkovito

implementacijo agilnih pristopov. Pomanjkanje izkušenj prav tako pomeni slabšo motivacijo

in energijo v timih, ki sta ključni za uspeh agilnih projektov. Lahko pride tudi do težav zaradi

določenih avtoritarnejših članov, ki bi želeli ohraniti svoj »vodilni položaj« v timu. Prevzem

agilnih metod bi tako pomenil »izgubo kontrole«, zaradi česar so takšni posamezniki

uspešen prehod na agilne metode pripravljeni zavirati ali ga onemogočati. [46]

Filozofija podjetja v nasprotju z agilnimi vrednotami

Predvsem v večjih podjetjih, ki že dalj časa (dovolj uspešno) poslujejo s tradicionalnimi

pristopi, glavno težavo predstavlja temeljna filozofija, ki je globoko zakoreninjena v strukturo

organizacije. V takšnih primerih so lahko agilna načela v nasprotju z načeli organizacije.

Podjetja morajo spremeniti temeljne načine razmišljanja ter se pripraviti na spremembe in

novosti, ki lahko veliko doprinesejo k nivoju uspešnosti. [46]

4.8 Pregled metodologij

Najpogostejše agilne metodologije [44] [65]:

iterativne strategije upravljanja razvoja programske opreme (scrum, dynamic

systems development method ‒ DSDM, feature driven development ‒ FDD, agile

unified process ‒ AUP, lean development, crystal),

strategije za optimizacijo razvoja programske opreme (ekstremno programiranje ‒

XP, rational unified process ‒ RUP) in

strategije za upravljanje vzdrževanja programske opreme in podpornih aktivnosti

(kanban).

DSDM ‒ dynamic systems development method

Pri DSDM je čas izvajanja projekta fiksen, zato so tudi sredstva, ki so na voljo, (relativno)

fiksna. DSDM je samostojen iterativni pristop upravljanja agilnih projektov RPO, ki izvira iz

hitrega razvoja aplikacij (RAD ‒ rapid application development) [44] in se lahko uporablja

tudi v povezavi z ostalimi pristopi (npr. XP). [65] Močno poudarja izdelavo prototipov in

potrjevanje rešitev stranke, in sicer pred začetkom polne razvojne dejavnosti. To je razvidno

iz postopkov, kot so delavnice deležnikov, poročila o izvedljivosti, prototipi izvedljivosti in

poslovne študije, ki morajo biti izvedene pred popolno implementacijo. Metoda je

osredotočena na temeljne agilne ideje, kot so aktivno vključevanje uporabnika v proces

razvoja, iterativen in inkrementalen razvoj, redna dostava oprijemljivih rezultatov in

24

pooblaščanje tima. Pomembni praksi predstavljata tudi konstantno testiranje in nadzor

kakovosti posameznih rešitev. V nasprotju s scrum DSDM zahteva vrsto artefaktov, ki jih je

treba izdelati v posameznih fazah projekta. Mednje spadajo razvojni načrti (analiza zahtev

in dizajna …) in funkcionalni modeli (razredni diagrami, UML-modeli …), ki zagotavljajo

redno potrjevanje in usklajevanje razvoja z zahtevami stranke. Po drugi strani pa imata

scrum in DSDM skupen cilj − dostavo visokokakovostnih rešitev v kontroliranih iterativnih

časovnih okvirjih. Scrum se zanaša na tekočo interakcijo s stranko, DSDM pa uvaja bolj

strukturiran pristop, ki zahteva več dokumentacije in redno potrjevanje dela. [44]

Crystal

»Komunikacija je osrednjega pomena crystal metode«, ki predstavlja razvoj kot

»kooperativno igro izuma in komunikacije.« [65] Glavni namen pristopa crystal je

premostitev problemov, ki nastanejo zaradi slabe komunikacije med deležniki, razvijalci,

strankami in uporabniki. Alistair Cockburn [65] si proces RPO predstavlja kot vrsto

ekosistema, v katerem vse fizične strukture, vloge in posamezniki z unikatnimi osebnostmi

na različne načine vplivajo drug na drugega. Pristop temelji na rednem dostavljanju vmesnih

rešitev, po katerih se ekipa orientira na naslednji korak v razvoju. Vmesne rešitve članom

tima omogočajo konstanten pregled nad težavami in tveganjem. Poleg tega pa tim ohranjajo

na ustrezni poti proti zadanim ciljem. Spodbujajo tudi iskanje novih idej in potencialnih

rešitev aktualnih problemov. Ni treba, da bi bili vmesni izdelki popolni, saj služijo predvsem

za usmerjanje in motiviranje tima. Konec razvoja predstavlja delujoča programska rešitev.

[65]

Scrum

Scrum je med agilnimi metodami najpogosteje uporabljena iterativna metodologija vodenja

projektov. Fokus metode predstavlja optimizacija donosnosti naložb s konstantnim

prioritiziranjem. [60] Pristop deluje po principu dostavljanja delujočih programskih

funkcionalnosti v omejenih časovnih iteracijah oz. »sprintih« (Slika 4.1). Prioritetno delo

predstavljajo funkcionalnosti, ki v posamezni iteraciji nosijo najvišjo poslovno vrednost.

25

Slika 4.1 – Scrum model [66]

Pristop neposredne interakcije z uporabniki in s stranko zagotavlja visoko uporabnost,

ustreznost in poslovno vrednost izdelka v celotnem procesu razvoja. Scrum timi so

multidisciplinarni in jih poleg razvijalcev sestavljajo še [44] [45]:

lastnik izdelka (product owner ‒ PO) ‒ predstavlja potrebe in zahteve stranke in je

zadolžen za dokumentiranje in prioritiziranje zahtev ter opravil;

»scrum master« ‒ povezovalec in motivator, ki zagotavlja, da se dogodki začnejo

ob določenih časih, rešuje konflikte in težave ter skrbi, da delo poteka po načrtu

(običajno član razvojnega tima);

deležniki – predstavljajo vse interesne skupine, ki so na kakršen koli način povezane

s projektom (stranke, uporabniki).

Temelj uspešnosti scrum metode predstavljajo redni sestanki in vrednotenje opravljenega

dela. Ti vključujejo načrtovalni sestanek ob začetku vsakega sprinta, na katerem

soudeleženci prediskutirajo in določijo prednostna opravila za trenutno iteracijo, in »sprint

review« ob koncu sprinta, ko se demonstrira in ovrednoti opravljeno delo. Scrum spodbuja

tudi dnevne »stand-up« sestanke, ki služijo kot dnevna posodobitev opravljenega dela,

težav in ostalih aktualnosti. Napredek scrum tima je deležnikom viden preko orodij za

spremljanje in merjenje napredka [44]:

voditeljska nadzorna plošča (poročilo, ki povzame delo znotraj agilne skupine za

lažje spremljanje napredka),

backlog izdelka (orodje, ki omogoča deležnikom in članom tima spremljanje

napredka projekta v primerjavi z dogovorjenimi zahtevami stranke) in

26

backlog sprinta (orodje za poročanje, ki skupinam omogoča nadzor in pregled nad

dnevnimi aktivnostmi in opravili).

FDD (feature driven development)

FDD je agilna metodologija, ki združuje elemente iterativnega upravljanja projektov s

specifičnimi praksami RPO. Temeljna lastnost FDD je dostava polnodelujočih izdelkov

znotraj vsake iteracije. Pristop deluje na podlagi t. i. domenskega modela ‒ poslovnega

problema, ki ga predlagan sistem namerava rešiti. Domenski model je sestavljen pred

dejanskim razvojem na podlagi tesnega sodelovanja s poslovnimi območji. Model se nato

razdeli na manjše enote oz. probleme, ki se razporedijo na posamezne iteracije. Člani tima

delajo na različnih funkcionalnostih, ki se po uspešnem testiranju sestavijo v končni sistem.

FDD podobno kot scrum poudarja sodelovanje s stranko in z uporabniki. Za razliko od

drugih agilnih pristopov FDD bolj poudarja predhodno načrtovanje – določanje specifičnih

vlog in dolžnosti posameznih članov ter načrtovanje obsega dela. Metoda se slabše odziva

na tekoče spremembe ravno zaradi neskladnosti teh z izvirnim (domenskim) modelom.

Prav tako poudarja konstantno zagotavljanje kakovosti posameznih rešitev. [44]

Ekstremno programiranje (XP)

XP je agilna metoda za RPO, ki spodbuja razvoj najenostavnejših tehničnih rešitev, ki

ustrezajo zahtevam stranke, s pričakovanjem, da se bodo zahteve spremenile, ko bo

stranka dobila priložnost preizkusa dostavljenega izdelka. Metoda spodbuja tekoče

izboljšave in optimizacijo PO glede na povratne informacije od stranke ali uporabnikov. XP

vključuje agilno prakso TDD (test driven development) − inovativen pristop merjenja

kakovosti, ki zahteva predhodno definiranje in dokumentiranje meril uspeha ter ustvarjanje

testov, ki se kasneje uporabijo za validacijo kode. Naslednja agilna praksa, uporabljena v

XP, je t. i. refactoring, ki timu omogoča redno pregledovanje in (po potrebi) spreminjanje

sistema z namenom lažje implementacije nadaljnjih programskih sprememb. Ta praksa

timu daje polno avtoriteto nad programskimi rešitvami, kar pomeni, da lahko zavrže vse

dosedanje rešitve v korist novejše, ki se bolje prilagaja novim zahtevam. XP vključuje tudi

druge agilne prakse, ki omogočajo redno dostavljanje visokokakovostnih rezultatov in

zmanjševanje stroškov vzdrževanja:

parno programiranje (dva člana delata isto opravilo) in

neprekinjeno integracijo novorazvitih delov kode v glavni sistem.

27

Narava XP-metode omogoča realizacijo večine strateških in taktičnih prednosti (več o tem

v poglavju 4.5) agilnega pristopa. Večinoma je uporabljena v kombinaciji z drugimi agilnimi

metodami, kot je npr. scrum. [44]

Lean

Lean je agilna metoda, ki združuje elemente iterativnega upravljanja projektov s praksami

oblikovanja in RPO. Lean izvira iz t. i. lean proizvodnega procesa, ki je nastal v zgodnjih

dvajsetih letih prejšnjega stoletja in je usklajen s principi v »kaizen«1 in »TQM« (total quality

managment)2. V središču lean pristopa se nahaja tehnika »value stream mapping«, ki se

osredotoča na [44]:

prepoznavanje in potrjevanje poslovne vrednosti strankinih zahtev,

dostavo programskih funkcionalnosti z najvišjo poslovno vrednostjo in

čim večjo učinkovitost RPO.

Lean spodbuja prepoznavanje in izločevanje t. i. odpadnih območij znotraj procesa RPO,

kar znatno poveča kakovost, produktivnost in učinkovitost. Naslednjo temeljno načelo lean

pristopa je hitra dostava rešitev, ki spodbuja člane tima k uporabi »pull« oz. »kanban« tehnik

za učinkovito odzivanje na strankine zahteve [67] in uskladitvi obsega in kompleksnosti

dela. Lean spodbuja odlašanje odločitev, kakor dolgo je to mogoče, z namenom

zagotavljanja maksimalne fleksibilnosti pri reševanju tekočih poslovnih zahtev. Vključuje

tudi stroge tehnike nadzora kakovosti na poslovnem in tehničnem nivoju. Lean timi se

osredotočajo na redno pregledovanje in vrednotenje iterativnega dela z namenom

konstantnih izboljšav izdelka. Pomembno prakso predstavlja tudi pooblaščanje timov, kar

omogoča rezultate z najvišjo možno poslovno vrednostjo. [44]

Kanban

Kanban je agilna metoda upravljanja delovnih obremenitev in sprememb, ki je lahko

uporabljena v povezavi z drugimi agilnimi pristopi ali samostojno. Metoda se je razvila kot

sestavni del lean proizvodnje za podporo v avtomobilski industriji. [61] Trenutno se

najpogosteje uporablja za upravljanje podpornih in vzdrževalnih IT-aktivnosti, pri katerih se

prioriteta opravil spreminja tedensko, dnevno ali celo na urni ravni. Pooblaščanje timov

predstavlja pomembno prakso tudi v tej metodi in omogoča redno doseganje rezultatov z

visoko poslovno vrednostjo. Kanban odlikuje učinkovita praksa, imenovana DVI (delo v

1 Kaizen (v japonščini pomeni »izboljšava«) je praksa nenehnih izboljšav. [148] 2 TQM je celovit in strukturiran pristop k upravljanju organizacij, ki se zavzema za izboljšanje kakovosti izdelkov in storitev z rednimi izboljšavami na podlagi povratnih informacij. [152]

28

izvajanju), ki preprečuje preobremenitev sistema. Če posel zahteva obravnavo opravila

višje prioritete, deležniki odločijo, katero opravilo v izvajanju se bo prestavilo, da bi se

sprostila ustrezna sredstva. Če se timu sprosti prostor v čakalni vrsti DVI, pomeni, da

deležniki določijo naslednje (najpomembnejše) opravilo, ki gre v postopek izvajanja. S tem

strankam omogoči prilagajanje aktivnosti glede na prioritete in aktualne poslovne zahteve.

Kanban potek dela ilustrira z uporabo centraliziranih kanban tabel, ki dajejo deležnikom

konstanten pregled nad naslednjimi informacijami [44]:

status vseh načrtovanih opravil (trenutnih in opravljenih),

razpoložljivost tima za delo in

težave, ki ovirajo napredek dela.

Kanban ustvarja okolje, odprto za komunikacijo, transparentnost in sodelovanje. Spodbuja

tudi kulturo konstantnega izboljševanja z naslavljanjem ozkih grl in ovir ter maksimiziranjem

produktivnosti v procesu razvoja. Medtem ko scrum predpisuje opravljanje dela v časovno

omejenih sprintih in FDD spodbuja dostavljanje oprijemljivih funkcionalnosti, je kanban

veliko manj osredotočen na to, kako je delo strukturirano in kdaj naj bo opravljeno. Namesto

tega timu omogoča vzpostavitev ciklov pregleda in časovnih okvirjev za dostavo, ki so

osnovani na specifičnih zahtevah oddelka. Kanban torej ne strukturira dela v časovno

omejenih iteracijah, kar omogoči večjo uporabnost za podjetja, ki se v nasprotju s

projektnimi aktivnostmi ukvarjajo s konstantnim tokom različnih opravil. Zaradi učinkovitosti

omenjenih metod so strokovnjaki začeli uporabljati hibridne pristope, kot je npr. scrum-ban

(kombinacija scruma in kanbana), da učinkovite dnevne »stand-up sestanke« scruma

obogatijo z izjemno odzivnostjo kanban pristopa. [44]

RUP (Rational Unified Proces)

RUP je »struktura najboljših praks« agilnih pristopov, ki so vključene v iterativno delo RPO,

z močno osredotočenostjo na prepoznavanje in reševanje tveganj v zgodnjih fazah

projekta. Pristop je prilagojen potrebam posameznih projektov, vendar njegov glavni fokus

vedno predstavlja ustrezno soočanje s tveganji. Pristop je sestavljen iz niza faz: ustanovitev

(načrtovanje obsega dela, proračuna in časovnega urnika), priprava (primeri uporabe,

arhitektura izdelka, naslavljanje tveganj in potrditev načrtov deležnikov), gradnja (dejanski

razvoj, uporaba objektno orientiranega okolja, vrednotenje iterativnih rešitev deležnikov) in

prehod (po potrditvi vseh funkcionalnosti so te skupaj z dokumentacijo predane

uporabnikom). Glavna razlika med RUP in ostalimi agilnimi metodami (npr. scrum) je v tem,

da je pri RUP iterativno delo opravljeno znotraj mej, ki so začrtane v ustanovitveni fazi. Za

podjetja, ki prehajajo s kaskadnega modela na agilne pristope, RUP predstavlja varno

29

odskočno desko, saj timu predstavi principe in prakse iterativnega dela brez dramatičnega

spreminjanja predhodnih specifikacij, ki so potrebne v kaskadnem modelu. RUP predstavlja

predvsem agilno prakso zmanjševanja tveganja znotraj določenih časovnih iteracij. Slabost

metode je v tem, da se zaradi natančnih začetnih načrtov slabo odziva na tekoče poslovne

spremembe. [44]

EssUP (essential unified process)

EssUP je razširitev metode RUP na več praks za uporabo v projektnih timih. Člani izberejo

prakso glede na svoje potrebe in želje. [44]

AUP (agile unified process)

Metoda AUP združuje disciplino RUP, fleksibilnost EssUP in prednosti XP-praks. Deluje po

poenostavljenem načinu štirih faz metode RUP. Zagotavlja razvoj, usmerjen k strankinim

najpomembnejšim zahtevam, in strogo strukturo upravljanja tveganj. Podobno kot pri

EssUP ni poudarjena dokumentacija, lahko pa se ta po potrebi razširi. AUP je prilagodljiv

pristop, tako da lahko timi uporabijo prakse, ki najbolje ustrezajo njihovim potrebam v

posameznih projektih. S številnih vidikov predstavlja idealen pristop za tradicionalne

organizacije, ki se nagibajo k prehodu na agilne metodologije, saj združuje ključne principe

agilnega, moč XP-praks z RUP-strukturo upravljanja tveganj in s standardnimi artefakti, ki

jih organizacije pričakujejo od tradicionalnega RPO. [44]

Hibridne agilne metodologije

Vse agilne metode imajo svoje prednosti in slabosti, zato se veliko sodobnih podjetij odloča

za pristope, ki združujejo različne metode. Največkrat uporabljena metoda za združevanje

je scrum, saj se lahko uporablja v povezavi z metodologijami RPO, kot sta npr. XP ali lean,

ali v povezavi z metodologijami upravljanja delovne obremenitve, kot je npr. kanban. [44]

4.9 Najboljša metoda?

Na spletu velikokrat naletimo na vprašanja o tem, katera agilna metoda je najboljša ali

katera zagotavlja največji uspeh. Pred izbiro metode je treba prepoznati prednosti, moči in

sredstva znotraj posamezne organizacije in glede na to izbrati prakso, ki je najustreznejša.

Vse agilne metode imajo svoje prednosti in slabosti, zato ni tako pomembno, katero

izberemo, temveč kako jo implementiramo. Težko oz. skoraj nemogoče je določeno

metodologijo označiti kot najboljšo, saj so med seboj težko primerljive – služijo različnim

namenom in so primerne za reševanje različnih problemov. Zato je najprej potrebno

prepoznati probleme in potrebe organizacije ter na podlagi tega določiti metode, ki najbolj

30

ustrezajo. [61] [68] Izbrana razvojna metoda mora prav tako zagotavljati pozitivno

skupinsko klimo in visoko produktivnost. Če želimo zagotoviti ustvarjalno delovno okolje,

moramo upoštevati mnenja, želje in potrebe članov tima. To najlažje dosežemo s

pridobivanjem in z upoštevanjem rednih povratnih informacij. Če mnenja zgolj pridobivamo,

ne da bi v skladu z njimi prilagodili metodologij razvoja, ima to lahko negativen učinek na

moralo in motivacijo tima. Vidimo, da so pozitivni odnosi in zadovoljne stranke za učinkovito

uporabo agilnih pristopov ključnega pomena. [68] Večjo učinkovitost omogoča predvsem

združevanje tehnik različnih agilnih metod (t. i. hibridni pristopi), ki najbolj ustrezajo

lastnostim organizacije ali tima. [69] Seveda pa je pri tem treba paziti, da so tehnike med

seboj združljive, torej da načela ene tehnike niso v nasprotju z načeli druge. [61] [68]

Jeff Sutherland [70], eden izmed ustvarjalcev metode scrum, meni, da je sinteza več

pristopov (scrum, kanban, XP in lean) nujna za visokoučinkovito projektno delo. Kanban

namreč poveča vidljivost stvari, minimizira trenutno delo in meri čas posameznih ciklov.

Scrum in lean zagotavljata hitrost in učinkovitost, hkrati pa uporaba XP-praks omogoča

večjo produktivnost. [70]

Podobno Woody Arnold [71] na sistemu Quora izpostavi prednosti uporabe scrum v sožitju

z XP. Prednosti metode scrum predstavljajo predvsem dnevni »stand-up« sestanki,

uporaba backlogov (izdelka in sprintov), sprinti ter vrednotenje in načrtovanje sprintov,

medtem ko XP ponuja moč predvsem s TDD-prakso, parnim programiranjem, konstantno

integracijo, z »refactoring«, enostavnim dizajnom (YAGNI – »You are not going to need it«),

s standardi programiranja in z vključeno stranko. [71]

4.10 Uporaba v sodobnih podjetjih

Agilne metode se uspešno uporabljajo predvsem po Evropi in ZDA. V svoj razvoj so jih

vključila nekatera izmed svetovno znanih podjetij, kot so Nokia Siemens Networks, Yahoo!,

Google, Microsoft, BT, Bankwest and SunCorp. Omenjene organizacije predstavljajo

vodilne sile na področjih tehnologije, financ in telekomunikacij. Pomembno je tudi, da so to

podjetja s trdnimi temelji in dolgo tradicijo in ne začetna. Te organizacije vključujejo agilne

pristope v svoje podjetniške strukture in jih uporabljajo za učinkovitejšo doseganje ciljev in

sledenje glavni viziji podjetja. [44] Agilne metode so se izkazale za enako uspešne v

organizacijah vseh velikost tako v javnem kot zasebnem sektorju. Eden najbolj uporabljanih

pristopov agilnih metodologij je scrum. Uporabljajo ga številne organizacije po svetu:

Adobe, Barclays Global Investors, BBC’s New Media Division, BellSouth, Bose, Capital

One®, GE, Google, Microsoft, Motorola, Nokia Siemens Networks, SAP®, State Farm® in

31

Yahoo! [44] [72] Nedavna študija, ki jo je opravil VersionOne [64], ugotavlja, da organizacije,

ki uporabljajo agilne pristope za RPO, dosegajo višjo produktivnost (tako meni 74 %

udeležencev), krajše čase izvedb projektov (66 % udeležencev) in izboljšano sposobnost

upravljanja in soočanja s spremembami med projektom (87 % udeležencev).

Zakaj agilnega ne uporablja več organizacij?

Kljub močni in glasni podpori prej omenjenih podjetij se veliko organizacij še vedno ne

odloča za uporabo agilne ideologije. Razlogi za to ležijo predvsem v [44]:

pomanjkanju ozaveščenosti − ignoranci do sodobnih t. i. radikalnih pristopov ali vpliv

poročanj določenih organizacij o neuspešnem implementiranju agilnih pristopov;

»bussiness as usual« pristopu − vztrajanju pri tradicionalnih pristopih (kaskadni

model); agilni pristopi zahtevajo drugačno delovanje in razmišljanje; nekateri jih

vidijo kot preradikalne in se bojijo uvajanja novosti in z njimi povezanih tveganj.

Rast agilnih pristopov

Vedno več organizacij poroča o takšni ali drugačni uporabi agilnih metodologij za RPO.

Glede na PWC Portfolio in Programme Management 2014 Global Survey [73] se je uporaba

agilnih metod od leta 2012 povečala za 11 %, hkrati pa vedno več organizacij poroča o

težavah z agilnimi idejami, in sicer predvsem zaradi izkušenosti zaposlenih zgolj v

tradicionalnih pristopih. [74] [73]

HP-jeva spletna raziskava [75], v kateri je sodelovalo 601 razvijalcev PO in IT-

strokovnjakov, je pokazala, da se več kot dve tretjini sodelujočih predstavljata kot »čisto

agilni« ali pa se nagibata k agilnim pristopom. Glavni faktorji, ki so jih uporabniki agilnih

pristopov navedli kot razlog za prestop na agilno, so naslednji [75]:

poveča sodelovanje med timi, ki po navadi ne delujejo skupaj,

poveča nivo kakovosti PO v organizacijah in

vpliva na povečano zadovoljstvo strank.

Človeški faktorji, ki vplivajo na uspešnost prestopa na agilno

Študija [76], v kateri je sodelovalo 32 strokovnjakov agilnih metodologij iz 13 različnih držav,

je razkrila, kako človeški faktorji vplivajo na prehod na agilne pristope. Rezultati so pokazali,

da lahko človeški odnos in načini obnašanja spodbujajo ali ovirajo prestop k agilnim idejam.

Vztrajanje pri tradicionalnem in poznanem, upiranje spremembam, pomanjkanje znanja in

nepripravljenost za sodelovanje ovirajo prehod na agilne metode. Istočasno pa nekatere

32

druge lastnosti na transformacijo vplivajo spodbudno, npr. »management buy-in« in

podporniki agilnega. Študija je razkrila, da imajo pomemben vpliv predvsem [76]:

reakcije udeležencev na spremembe (navdušenje, zaskrbljenost in

neopredeljenost),

(ne)realnost pričakovanj,

spodbujanje (motiviranje) in

informiranost o človeških faktorjih agilnega procesa.

Jeff Sutherland je leta 2014 v intervjuju [77] razkril primer dobre in slabe aplikacije agilnih

metod v sodobnih podjetjih in razloge, ki so vplivali na to:

Healthcare.gov – neuspešen primer:

o pomanjkanje koordinacije med front-end in back-end; uporaba scruma na

front-end-u, a neupoštevanje drugega principa Agilnega manifesta – dostave

delujočega PO;

o slabo vodenje.

Spotify – uspešen primer:

o uporaba agilnosti oz. natančneje metode scrum podjetju Spotify omogoča

konkuriranje največjim tehnološkim gigantom, kot so Google, Amazon in

Apple;

o vključevanje usposobljenih agilnih strokovnjakov;

o učinkovita koordinacija timov;

o sistematično odstranjevanje odpadnega materiala – upravljanje in nadzor

neučinkovitih timov (poglavitni elementi lean in agilnih idej).

4.11 Uporaba v drugih industrijah

Načrtovanje in upravljanje projektov predstavlja izziv ne zgolj na področju RPO, temveč tudi

v ostalih sektorjih, ki se ukvarjajo z razvojem novih izdelkov ali tehnologij. Za razliko od lean

razvoja, ki ima korenine v avtomobilski industriji (več o tem v poglavju 4.12), je fokus agilnih

pristopov od samega začetka predstavljal RPO. [78] [79] [80] [81] Moč agilnega je zaradi

številnih uspešnih primerov začela zanimati tudi druge industrije, zato so se pojavila

razmišljanja o posplošitvi agilnih praks, orodij in tehnik na širše področje. [82] [83] [84]

Pomanjkanje raziskav agilnega v povezavi z ostalimi industrijami je predstavljalo navdih za

raziskovalno študijo, ki je ugotavljala učinkovitost 19 srednje velikih in velikih podjetij, ki še

niso imela formalnega stika z agilnimi pristopi. Raziskovanje teh podjetij je omogočila

povezava oz. podobnost RPO z razvojem novih izdelkov, uporabo ustvarjalnosti in

cikličnega prototipiziranja ter s testiranjem. [85] Rezultati študije [85] so ugotovili ugodne

33

vidike izvajanja agilnih metodologij v drugih industrijah s podobnim razvojnim delom, kot se

opravlja v industriji RPO. Ti vključujejo prisotnost dejavnikov, kot so projektni timi, projektno

upravljanje in procesi razvoja novih izdelkov, ki jih neposredno povezujejo z dejavniki v

RPO, s katerimi se ubada agilna filozofija. V podjetjih so raziskovalci prav tako prepoznali

povezave z določenimi praksami agilnih pristopov, kot so zmanjševanje dokumentacije,

vključevanje strank v načrtovanje in tedensko posodabljanje načrtov v skladu s tekočimi

spremembami. Vsi omenjeni vidiki nakazujejo na zavesten ali nezaveden obstoj določenih

agilnih idej znotraj drugih, podobnih industrij. Študija je prav tako nakazala na morebitne

ovire ob prevzemu agilnih idej drugih industrijskih sektorjev. Te so zlasti težavnost

ustvarjanja multidisciplinarnih timov, izziv vključevanja vplivnih strank in dobaviteljev in

omejitve o polnem delovnem času projektnih skupin. Končni sklepi raziskave so prepričljivo

nakazali na možnost uporabe agilnih idej v drugih industrijah in tradicionalnejših sektorjih

ali vsaj v določenih inovativnih projektih znotraj teh, ki zahtevajo fleksibilne upravljavske

pristope. [85]

4.12 Agile in lean – pojma, ki sta pogosto napačno interpretirana

Lean metodologija predstavlja uporabo lean proizvodnje v RPO. Lean proizvodnja je

osnovana na Toyotinem proizvodnem sistemu [86] (imenovanem »The Toyota Way« [60]),

ki je nastal v poznih 40. in zgodnjih 50. na Japonskem [87], da bi zmanjšali izgube in si

zagotovili trajnostno proizvodnjo v avtomobilski industriji. [60] [88] Lean obsega ideje »JIT«

(just in time) proizvodnje3, »end-to-end continuous flow« ter »kanban kart«4 in »kaizen

procesa izboljšave«. Njegovo pravo središče pa predstavlja t. i. »lean skrivnost« – »all

hands on deck« mentaliteta, ki vključuje vsakega zaposlenega, upravitelja, vse dobavitelje

in vse partnerje. [60] [22] Vsesplošno prepoznavnost je vitki pristop pridobil šele v 90. letih

prejšnjega stoletja, z deli, ki so opisovali japonsko avtomobilsko industrijo in njene prednosti

v primerjavi z ameriško. [23] Povezava med vitkimi in agilnimi idejami je bila bolj eksplicitno

predstavljena v knjigi »Lean Software Development« [23] [88] Mary in Toma Poppendiecka.

[88] V zadnjem času so avtorji, odgovorni za predstavitev lean proizvodnje javnosti, prenesli

iste ideje še na druga področja. V knjigi »Lean Solutions« je predstavljeno, kako se lahko

vitke ideje uporabijo v zdravstvu, maloprodaji, transportu in ostalih poslovnih sektorjih. [22]

Vodilna sila lean razvoja je »odstranjevanje odpada« (removing waste) − prepričanje, da

odstranjevanje odpadnega materiala predstavlja konstantno izboljšavo (z razkrivanjem

3 JIT je strategija zalaganja, ki izboljša učinkovitost s prejemanjem blaga zgolj takrat, ko je to v procesu proizvodnje potrebno. [145] 4 Kanban (v japonščini pomeni »vizualen signal« ali »karta«) je tehnika vizualne predstavitve dela, ki izboljša vidljivost, pregled nad delom in komunikacijo. [147]

34

novih odpadkov). Odpadni material lean deli na 3 vrste [86] [89]: muda (neproduktivnost),

mura (neenakost, nekonsistenca) in muri (preobremenjenost, nerazumnost). Med načela

vitkega razvoja sodijo tudi spodbujanje učenja, sprejemanje odločitev, kolikor pozno je to

mogoče (z namenom zmanjševanja neodločenosti), dostavljanje, kolikor hitro je to mogoče

(z namenom pridobitve povratnih informacij in upoštevanja teh informacij), pooblaščanje

timov, razvoj kakovostnih rešitev v vsaki fazi ter pregled nad celotnim sistemom in okoljem,

v katerem ta deluje/obstaja. [87] Tipična lean organizacija opravlja ogromno testov, se

pogosto povezuje s strankami, razume njihove vrednote in je odprta za nenehne izboljšave.

[61]

Lean in agilno imata izredno podobni filozofiji. Oba visoko vrednotita prilagodljivo

načrtovanje in postavljanje človeka v središče. Lean je predstavljal navdih za razvoj agilnih

idej, npr. »value stream mapping« in poudarjal zmanjšanje časovnega obsega posameznih

ciklov. [23] Medtem ko agilni manifest [51] poudarja stranke, goriščno točko leana

predstavljajo deležniki. [60] »Odstranjevanje odpadnega materiala« v agilnih metodah

predstavlja konstantno analizo in vrednotenje opravljenih delov končnega izdelka −

iterativni proces učenja in nenehne tehnološke/poslovne izboljšave. [22]

Lean ideje predstavljajo način razlage agilnega RPO ljudem – predvsem starejšim

strokovnjakom znotraj IT-industrije in starejšim strankam. Lean in agilno sta globoko

prepleteni ideologiji znotraj sveta RPO. Govoriti o dveh različnih pristopih je nesmiselno, saj

ob prakticiranju agilnih metod prakticiramo tudi vitke in obratno. Oba pojma zajemata veliko

skupnih tehnik, orodij in vrednot. Tako ne moremo prakticirati agilnega ali lean, temveč zgolj

agilno in lean ideologijo. [23] Agilno zagotavlja intelektualna orodja za prenos vitkih

principov v agilne prakse. Vse lean organizacije so po definiciji učeče se organizacije, ker

proces prepoznavanja in odstranjevanja odpadkov zahteva konstantno učenje. Niso pa vse

učeče se organizacije tudi vitke (Slika 4.2). [22]

35

Slika 4.2 – konceptualni prikaz idej in metodologij [22]

Lean in agilno ne predstavljata večjega, temveč bolj fokusirano in disciplinirano delo,

podprto z načeli zdravega razuma, ki ne zahtevajo univerzitetne izobrazbe ali formalnega

treninga. Lean vključuje previdno vnaprejšnje načrtovanje in udeležbo vseh sodelujočih od

začetka do konca, medtem ko nas agilno opominja na konstantno pridobivanje povratnih

informacij. Lean se prav tako osredotoča na dolgoročne rezultate [86] – »kaj je pomembno

v tem trenutku, da bo podjetje dolgoročno ostalo v igri.« [60] Lean in agilno se

komplementarno dopolnjujeta. Malokrat izpostavljena prednost agilnega je osredotočenost

na tekočo oskrbo projekta v nasprotju s samo začetno. Tako lean kot agilno stremita k

odstranjevanju pomanjkljivosti. Eden izmed izumiteljev scruma Jeff Sutherland [90] lean in

scrum pojmuje kot različna in komplementarna načina razvoja, ki sta se razvila iz

opazovanja kompleksnih in prilagodljivih sistemov. Lean ideje torej ležijo v središču

agilnega. Agilno poudarja sprejemanje sprememb, a to je nemogoče doseči s preveč

navlake oz. odpadnega materiala, za katerega poskrbi lean. [60] Če primerjamo pojme lean,

36

agilno in učeče se organizacije, lahko rečemo, da agilno predstavlja podmnožico vitkih

načel in praks, te pa so podmnožica t. i. učečih se organizacij oz. sistemskega razmišljanja

(Slika 4.2). [61] [88] [22]

37

5 TIMSKO DELO

5.1 Kdo so razvijalci programske opreme?

V današnjem svetu velja splošno prepričanje, da so razvijalci PO zgolj inženirji, ki se

ukvarjajo s pisanjem kode oz. programiranjem. Resda to spada v njihovo delo, vendar je

obseg v resnici veliko širši in vključuje multidisciplinarna znanja. Primeri nekaterih ostalih

funkcij, ki spadajo v sklop RPO, so testerji, poslovni analitiki, dizajnerji, arhitekti PO,

upravitelji projektov, upravitelji razvoja, programerji ipd. Razvijalci PO so visoko

usposobljeni posamezniki s specifičnim znanjem, ki vsakodnevno sprejemajo informirane

odločitve. [22] V osnovi razvijalci PO predstavljajo intelektualne delavce oz. delavce, ki

upravljajo z znanjem. Vrednost, ki jo ustvarjajo, je v znanju, ki ga posedujejo, posredujejo

in uporabljajo, ter v tem, kar to znanje omogoča. [91]

Glavna lastnost intelektualnega dela, ki je specifična za razvijalce PO, je sposobnost

ustvarjanja novih orodij za strojno opremo (računalnike), kar jim omogoča spreminjanje

načinov opravljanja intelektualnega dela. Zato je analiza dela razvijalcev PO s te

perspektive bistvenega pomena za razumevanje, kako bodo orodja (PO) v sedanjosti in

prihodnosti oblikovala in vplivala na delo in družbo.

5.2 Pomen timov

Timsko delo je v sodobnem času izjemnega pomena, saj ustvarja ustvarjalno

multidisciplinarno okolje in celovitejši končni izdelek, seveda ob pogoju dobre socialne

klime. Proces razvoja timov lahko opišemo po fazah, pri čemer se te med seboj prepletajo

in prehajajo ena v drugo. [92]

»Aktivnosti razvoja timov se osredotočajo predvsem na določanje vlog posameznih članov,

določanje timskih ciljev, reševanje problemov in na medsebojne procese.« [92]

Razlika med skupinami in timi

Vsaka skupina ljudi, ki skupaj opravlja določeno delo, še ne predstavlja tima. Kot primer

skupine lahko navedemo prodajno osebje v maloprodajni trgovini. Posamezniki v tej skupini

prakticirajo medsebojno interakcijo, se podpirajo, pomagajo drug drugemu in skupaj

opravljajo določena opravila. Skupino lahko torej definiramo kot »konfiguracijo dveh ali več

neodvisnih posameznikov, ki v določenem časovnem obdobju prakticirajo medsebojno

interakcijo.« [93] Skupine delujejo tako, da bi dosegle skupne cilje, imajo skupne dejavnosti,

vrednote in jih lahko formalno ali neformalno vodi en posameznik. Njihovo slabost

38

predstavlja predvsem nejasno določena in nestabilna kultura, kar je razlog za več konfliktov.

[93]

Timi po drugi strani predstavljajo posebno vrsto skupin. V timu obstaja diferenciacija veščin,

tako da vsak posameznik opravlja določen del skupnega opravila. Usoda končnega

produkta je odvisna od prispevka vsakega člana in vsi so zanj tudi odgovorni. Posledice

neuspešnega dela enega člana občutijo vsi člani tima. Timi pogosto tudi nimajo vodje, pač

pa si to funkcijo delijo člani. Zaradi navedenega načeloma v timih vladajo boljša socialna

klima, večje zaupanje in sodelovanje med člani in večja predanost skupinski viziji in ciljem.

[93]

5.3 Tuckmanove faze ustanovitve tima

»Kljub temu da se organizacije včasih vedejo, kot da so lahko timi ustvarjeni zgolj z

avtoritarno odločitvijo, razvoj timov v resnici predstavlja večstopenjski proces.« [94]

Leta 1965 je Dr. Bruce Tuckman izdal članek o fazah razvoja tima. Ta naj bi potekal v štirih

fazah: oblikovanje (forming), viharjenje (storming), normiranje (norming) in delovanje

(performing). Leta 1970 je dodal še peto ali zaključno fazo, imenovano zaključevanje

(adjourning). [95]

Oblikovanje (forming)

Prva faza, imenovana »forming«, predstavlja zbor ljudi z različnimi pričakovanji, zahtevami,

prepričanji in znanjem. Je najbolj uradna faza v celotnem razvoju tima. V tej fazi se formira

temeljni timski duh, ki je potreben za učinkovito nadaljnje sodelovanje. Če ta faza ni

izpeljana ustrezno, je pretok informacij v kasnejših fazah lahko oviran. [29] Člani se

poskušajo čim bolje spoznati, spoznati strokovna področja in izkušnje ostalih članov in

prepoznati, kateri načini obnašanja so sprejemljivi znotraj sveže formirane ekipe. [24] Če ta

korak poteka preko multimedijskih orodij (ne v živo), je treba potek komunikacije določiti v

naprej, da ne pride do nepotrebnih zapletov, ki bi otežili delo. V tej fazi se že pokažejo

potencialni člani z voditeljskimi tendencami. [29] Faza formiranja je zaključena takrat, ko se

člani skupine ne vidijo več zgolj kot naključen zbor posameznikov, temveč se prepoznavajo

kot člani tima. [24]

Viharjenje (storming)

39

Druga faza ustanovitve tima se imenuje »storming«. To je faza, v kateri se člani skupine

pogajajo v socialni interakciji. V tej fazi postanejo vidni procesi skupinskega učenja in

kognitivni konflikti5. Opazni so različni socialni procesi in aktivnosti [29] [96]:

diferenciacija vlog,

odpornost do nalog pri roki,

nihanja v motivaciji in v odnosu do skupine,

prepiri med člani skupine,

defenzivnost, tekmovalnost, izbiranje strani in

vzpostavitev nerealističnih ciljev, neenotnost, povečana napetost in ljubosumje.

Morebitni vodje, ki so skozi prvo fazo formiranja ostali tihi in mirni, se lahko v tej fazi odločijo

za nasprotovanje trenutnim vodjem in povzročijo nesoglasja. Nekateri člani lahko pokažejo

znake sovraštva in verbalnega nasilja. Pri večjih konfliktih ali nesoglasjih je treba zagotoviti

zunanje konzultacije. [29]

Sicer pri reševanju takšnih situacij težimo k doseganju kompromisa. Posamezniki se morajo

v dobrobit celotnega tima odreči določenim osebnim zahtevam. Prav tako morajo ustvariti

ustrezno hierarhijo vodenja. [24] Prej opisana obnašanja članov skupin imajo negativen

vpliv na razvoj, saj odvračajo pozornost od cilja.

Če člani tima za komunikacijo uporabljajo multimedijske pripomočke, lahko pride do

medosebnih konfliktov tudi zaradi nerazumevanja e-sporočil (t. i. internet flame wars) [97]

[29], ki imajo na delovanje tima lahko dolgoročne negativne vplive: stres, negativna

energija, neupoštevanje in ignoriranje … Včasih je potrebna zunanja intervencija, lahko pa

se tudi zgodi, da se ji najbolj problematični člani upirajo … Kakor koli že, pred prehodom v

naslednjo fazo je treba razrešiti takšne situacije in oceniti zrelost tima za napredovanje v

naslednjo razvojno fazo. [97] [29]

Normiranje (norming)

V tej fazi tim razvijejo norme – standardi ali vzorci obnašanja, ki so zaželeni znotraj skupine.

Pokaže se pozitivni preskok v vedenju, saj sodelujoči večinoma »prebolijo« napeto

»storming« fazo, dosežejo timsko kohezijo in začnejo z učinkovitim delom. [29] [24] Timi

5 Kognitivni konflikt je stanje miselnega ravnovesja, ki ga povzročijo nove informacije iz zunanjega okolja, ki se ne ujemajo z obstoječimi miselnimi strukturami osebe. Lahko ga razrešimo z asimilacijo (prilagoditvijo okolja osebi) ali z akomodacijo (prilagoditvijo osebe okolju). [146]

40

lahko večkrat prehajajo med fazo »storminga« in fazo »norminga«. Uspešen, stalen prehod

na fazo normiranja poveča samozavest tima ter ga naredi zrelejšega, saj si sodelujoči s tem

dokažejo, da so sposobni prebroditi težke čase z namenom realizacije zadanih ciljev. [29]

Člani tima imajo v tej fazi dokaj jasno postavljene vloge, ki jih ostali sprejmejo; prav tako se

tim dobro odziva na svoje vodje. Medsebojna interakcija postane sproščenejša in

zabavnejša, kar ustvari pozitivno energijo in ustrezno okolje za produktivno delo. [29]

Pogosto vedenje v tej fazi vključuje [96]:

kritike, izražene na konstruktiven način;

sprejemanje razlik med člani skupine;

poskuse uvedbe harmonije z izogibanjem konfliktom;

več prijateljskega odnosa, zaupljivosti in pogovorov o osebnih problemih;

povezanost med člani, skupni duh in cilje;

vzpostavitev in ohranjanje mej/omejitev znotraj tima in skupnih pravil, ki ohranjajo

harmonijo dela.

Delovanje (performing)

Četrta faza razvoja tima se imenuje »performing«. Člani skupine delujejo kot visoko zmogljiv

tim. Prišli so do stopnje, v kateri lahko svoje medosebne spretnosti uspešno preusmerijo v

nove projekte ali naloge. Prehodi na fazo »storming« so izjemno redki, saj se člani na tej

stopnji že zavedajo, da to predstavlja ogromno nazadovanje, ki bi povzročilo neželene

časovne zamude. Tim začne delovati samostojno in po potrebi vključi nove člane. Časovno

gledano timi za dosego te faze po navadi potrebujejo okoli šest mesecev ali več. [29] [95]

To fazo zaznamuje naslednje [96]:

člani dobro razumejo prednosti/slabosti ostalih sodelujočih;

člani vzpostavijo vpogled v osebne in skupinske procese;

pripravljenost na konstruktivne osebne spremembe;

vzpostavitev socialnih veščin, ki zagotavljajo hitre razrešitve problemov/konfliktov;

vzpostavi se globoka medsebojna povezanost med člani skupine.

Najboljši pokazatelj, da se skupina nahaja v fazi delovanja, je po navadi spoznanje, da

opravijo ogromno dela v kratkem času, tj. da je učinkovitost izjemna. Člani so prav tako bolj

strateško ozaveščeni. Zavedajo se delovanja skupine in poti, ki jo morajo opraviti, ter sledijo

skupni viziji. Vse omenjene lastnosti izboljšajo imidž skupine, dvigneta se raven

samozavesti in nivo prepričanja o skupnih sposobnostih. To pozitivno vpliva na energijo, ki

člane žene k uspehu in novim projektom. Še vedno se pojavljajo nesporazumi, vendar so v

41

večini primerov rešeni konstruktivno in brez večjih težav. Timi delujejo samozavestno in

avtonomno v smeri zastavljenih ciljev, ustrezno rešujejo težave v medsebojnih odnosih in

se konstruktivno soočajo s težavami v procesu dela. [29] V primeru trajnih timov se razvoj

konča na tem mestu, saj nadaljujejo s fazo »performinga« v vseh nadaljnjih projektih. [24]

Zaključevanje (adjourning)

V primeru začasnih timov obstaja še peta faza – »adjourning«, ki predstavlja proces

razpada tima. [24] [29] Po navadi se zgodi, ko tim uspešno zaključi vse svoje projekte in

doseže zadane cilje. [29] Tim se ne osredotoča več na izvedbo opravil, temveč na opravila,

ki so potrebna za ustrezen zaključek projekta in razpustitev skupine (končna poročila,

distribucija izdelkov). Na tej točki člani tima ponovno postanejo nepovezani posamezniki.

[24] Člani zaključijo določeno poslovno obdobje življenja in se podajo novim poslovnim

izzivom naproti, in to z višjo ravnijo samozavesti, ki so jo pridobili z uspešnim razvojem tima

in doseženimi cilji. Veliko profesionalnih odnosov, ki so se ustvarili med skupinskim delom,

se nadaljuje tudi po zaključenem delu. [96] Člani so se v tem času dobro medsebojno

spoznali, pridobili nova znanja, izkušnje in zaupanja v svoje kooperativne sposobnosti. Prav

tako so dobili nove poslovne stike z visokim nivojem zaupanja, ki imajo velik potencial za

sodelovanje v prihajajočih projektih. Profesionalni stiki se kasneje ohranjajo s pomočjo

socialnih mrež, kot so Facebook, Twitter, LinkedIn ipd. in predstavljajo veliko vrednost za

nadaljnjo poslovno pot vseh članov. [29]

Petstopenjski razvoj timov je priljubljen že od šestdesetih let preteklega stoletja, je pa v

nekaterih pogledih pretirano poenostavljen, npr. konec faze »storming« še ne pomeni

dejanskega konca konfliktov. V nasprotju s splošnim mišljenjem veliko strokovnjakov

verjame, da so konflikti za doseganje želene timske sinergije nujni. V nasprotnem primeru

se lahko soočimo s situacijo skupinskega razmišljanja, v kateri se člani nagibajo k enakim

stališčem kot ostali. Da bi se izognili konfliktom in medosebnim pritiskom, se prepustijo

uniformnemu mišljenju in vzdržujejo iluzijo enotnosti in povezanosti, kar pa negativno vpliva

na ustvarjalno reševanje problemov. Končni produkt je lahko slabši. [24] [94]

5.4 Potrebne lastnosti timov

Združevanje strokovnjakov z različnimi vrstami in nivoji znanja je lahko izjemno težka

naloga v kakršnem koli projektnem timu. Med sodelujočimi se nenehno pojavlja tekmovalna

napetost, ki lahko na proces razvoja vplivajo pozitivno ali negativno. Oblikovanje

ustreznega agilnega tima temelji na iskanju tako prave kombinacije tehničnih veščin kot tudi

prave skupinske dinamike. [44]

42

Člani agilne ekipe morajo biti [44]:

multikvalificirani (za opravljanje različnih vlog, ki jih delo zahteva),

odprti in prilagodljivi,

komunikativni (za spodbujanje inovacij, izmenjavo idej in tesnega sodelovanja),

motivirani (sposobnost samostojnega in kooperativnega dela) in

celostni misleci (razumevanje tehničnega in poslovnega konteksta dela).

Znanje, veščine & sposobnosti (ZVS)

Da bi se lahko učinkovito soočali z izzivi projektnega dela, morajo člani timov posedovati

(oz. jih je potrebno naučiti) znanja, veščine in sposobnosti (ZVS) za reševanje konfliktov.

Ločiti morajo konstruktivne konflikte od nekonstruktivnih, prve spodbujati, druge

preprečevati. Prepoznavati morajo vzroke konfliktov in obvladati strategije spoprijemanja z

njimi. [98] Obvladati morajo »integrativno (win-win) pogajalsko strategijo, ki je v nasprotju s

tradicionalno distributivno (win-lose) strategijo.« [98] Pomembna je tudi prisotnost

komunikacijskih veščin. To pomeni, da je treba komunicirati odprto in podpirajoče, poslušati

brez predsodkov in ustrezno uporabljati tehnike aktivnega poslušanja. [98] [24]

Visokoučinkoviti timi morajo poleg opisanih medosebnih ZVS prakticirati tudi ZVS za

samokontrolo tima, ki vključujejo zlasti sposobnosti in spretnosti nadzorovanja in

koordiniranja dela tima [24], pridobivanja in vrednotenja povratnih informacij o zmogljivosti

tima in posameznih članov, določanja ciljev ipd. [98]

5.5 Vpliv osebnosti

RPO temelji na kooperativnih in timsko osnovanih aktivnostih. Vključuje različne skupine

ljudi, od katerih se pričakuje učinkovita in tekoča komunikacija, z namenom reševanja

zapletenih problemov pod raznimi pritiski (čas, proračun, menedžment, stranke). Osebnosti

udeleženih posameznikov neposredno vplivajo na uspešnost tima. Kooperativno naravnani

posamezniki ustvarjajo harmonične in pozitivne medosebne odnose, nasprotno pa

egoistično naravnani osebne interese postavljajo pred skupinske cilje. Pomembna je tudi

stopnja zavedanja in sprejemanja medsebojnih razlik, odsotnost stereotipov in predsodkov

do drugačnosti. Ozaveščenost o osebnih lastnostih lahko pripomore k dolgoročni harmoniji

in pozitivni energiji, ki predstavlja osnovo za timsko delo in timski duh ter vpliva na večjo

uspešnost projektov. [28]

Različne osebnosti so primerne za različna opravila

43

Osebnost lahko definiramo kot celoto posameznikovih telesnih, vedenjskih in duševnih

značilnosti. Ta celota je relativno trajna, individualna in kompleksna. Dejavniki, ki vplivajo

na razvoj človekove osebnosti, so dednost, okolje in človekova lastna dejavnost, pri čemer

ti izvirajo iz posameznika samega, iz situacij, v katerih se nahaja, ali pa iz interakcije med

posameznikom in situacijo. Ker so ti vplivi in njihova interakcija pri vsakem posamezniku

drugačni, se razvijemo v edinstvene osebnosti. [99]

Ena izmed priljubljenih teorij osebnost deli na t. i. velikih pet (big five) [99] [100] karakteristik,

ki pa v resnici zajemajo značilnosti temperamenta posameznikov. Mednje spadajo [99]

[100]:

ekstravertnost oz. energičnost (toplina, družabnost, usmerjenost v zunanji svet,

samozavest, aktivnost, pozitivne emocije),

prijetnost oz. sprejemljivost (zaupanje, prijaznost, odkritost, altruizem, prilagojenost,

skromnost, blagost),

vestnost (kompetentnost, red, čut dolžnosti, storilnost, samodisciplina, odločnost),

nevroticizem oz. čustvena stabilnost (tesnobnost, sovražnost, depresivnost,

zaskrbljenost, nestrpnost, samokritičnost, impulzivnost) in

odprtost (domišljija, estetski čut, globoko doživljanje, akcije, ideje, vrednote;

odprtost do ljudi, novih izkušenj in idej).

V študiji [101] so raziskovalci ugotavljali, ali različne osebnosti vplivajo na ustreznost

opravljanja različnih nalog na področju RPO. Ugotovili so, da t. i. »top člani« v timih najbolj

prispevajo k difuziji znanja in prav tako izkazujejo najvišjo raven odprtosti za izkušnje. [101]

Izredno vestni programerji so se izkazali za produktivnejše v iterativnih načinih RPO. Prav

tako se je izkazalo, da vestnost pozitivno korelira z jasnejšo vizijo o skupnih ciljih. [102]

Najvišja raven ekstravertnosti je bila zaznana pri osebah, ki delujejo na razvoju, povezanim

z uporabniškimi izkušnjami. [101] Prav tako so ekstravertirani posamezniki pokazali višje

tendence do dela v timskem okolju. [103] Po drugi strani pa so posamezniki, ki se v RPO

ukvarjajo s kodiranjem oz. programiranjem, izkazovali največ nevroticizma in vestnosti.

[104] Rezultati so jasno pokazali, da imajo osebnostne lastnosti članov timov pomemben

vpliv na učinkovitost timov na področju RPO. [101] Zato je za doseganje večje motiviranosti

in uspešnosti tima pomembno, da pri razporejanju posameznikov na različna opravila v

RPO upoštevamo tudi njihove osebnostne lastnosti. [105] [103] V ta namen je zaželeno

predhodno psihološko testiranje z ustreznim osebnostnim testom. [103]

Vpliv osebnosti vodij na učinkovitost tima

44

V drugi študiji [106] so raziskovalci ugotovili, da vodje, ki posedujejo določene osebnostne

lastnosti, kot sta ekstravertnost in intuitivnost, pozitivno vplivajo na učinkovitost timov.

Ekstravertnost se je izkazala za pozitivno lastnost vodij moškega in ženskega spola,

medtem ko je introvertnost žensk negativno korelirala s timsko učinkovitostjo. Timi,

sestavljeni samo ali pretežno iz moških članov, so dosegali učinkovite rezultate pod vodjo

moškega spola, po drugi strani pa pretežno ženski timi kažejo izjemno sproščenost pod

vodenjem ženske. Večinsko ekstravertiran tim je pokazal boljše rezultate pod vodenjem

moškega. Prav tako se je osebnostna lastnost intuitivnosti izkazala za učinkovit faktor v

timih, sestavljenih pretežno iz članov moškega spola. Ekstravertirani člani ženskega spola

so kazali nelagodje in nesproščenost v pretežno moških timih. Iz izsledkov raziskave lahko

sklepamo, da igrajo spol, lastnosti temperamenta in značaja za uspešnost tima ključno

vlogo. [106]

Povezava osebnosti in klime s kakovostjo izdelka

Ekstravertnost in prijetnost oz. sprejemljivost pozitivno korelirata z učinkovito komunikacijo

znotraj tima in posledično s kakovostjo izdelka. [107] Raziskovalci so prav tako ugotovili,

da so zadovoljni timi sestavljeni pretežno iz prijaznih članov, kar poveča kohezijo tima. Če

so člani tima zaznavali timsko klimo kot varno za sprejemanje in oddajanje novih idej, je to

pozitivno vplivalo na kakovost izdelka. Enako se je izkazalo za klimo, ki spodbuja člane k

razvoju najboljšega možnega izdelka. [107]

5.6 Upravljanje timov

Upravljanje timov je izredno pomembna praksa projektnega upravljanja v RPO. [108]

Upravitelj mora člane različnih disciplin ustrezno usmeriti in zagotoviti, da se projekt zaključi

v predvidenem času in v sklopu predvidenega proračuna. [29] Izzivi, s katerimi se medtem

sooči, so predvsem upravljanje timov različnih vrst in v različnih fazah, komunikacijske

strategije in strategije vodenja. V splošnem smislu funkcija upravitelja obsega zagovarjanje

sprememb ter spremljanje in nadzorovanje dela tima. [109] Upravitelj tima mora upoštevati

vrsto tima, ki ga upravlja, in fazo razvoja, v kateri se tim nahaja. [109] Tuckmanove faze

razvoja tima so opisane v poglavju 5.3, najpogostejše vrste timov pa so samoupraviteljski

timi, virtualni timi, delovne skupine, odbori idr. [109]

Avtoriteta in vodenje

Pri upravljanju timov RPO moramo razlikovati med pojmom avtoritete in vodenja. V agilnih

timih je boljše uveljavljanje vodenja kot prakticiranje avtoritete. Ljudje raje delajo po svoji

iniciativi kot tisto, kar se jim ukaže. Več navdušenja kažejo nad delom, ki je posledica

45

njihovih lastnih odločitev, zato ima uporaba avtoritete velikokrat nasproten učinek.

Avtoriteta namreč še ne ustvari vodje, temveč posamezniku zagotovi legitimnost, ki

predstavlja odskočni korak za razvoj vodje. Seveda pa se tudi avtoriteta občasno izkaže kot

pomembna praksa za zagotavljanje ustrezne klime in nivoja produktivnosti. Treba pa je

razumeti, da okolje, ki deluje zgolj na podlagi avtoritarnih odločitev, za razvoj novih idej ni

rodovitno. [22]

Vloga vodje

Sodobni timi zahtevajo sodobne vodje. V tradicionalnih idejah so vodje predstavljali

avtoritarne posameznike, ki so svojo moč nenehno držali pri sebi. Pomembna lastnost

sodobnih vodij pa v nasprotju z njimi predstavlja delegiranje avtoritete, kar vodji zmanjša

mero delovne obremenitve in s tem omogoči učinkovitejšo in kakovostnejšo izrabo časa.

Vloga sodobnega (agilnega) vodje se torej preusmeri iz konstantnega prakticiranja

avtoritete v delegirano usmerjanje in motiviranje podrejenih. [22] Eno izmed dolžnosti vodje

predstavlja zagotavljanje vseh potrebnih sredstev za uspešen in tekoč potek procesa RPO.

Agilni pristopi prepoznavajo pomembnost človeških faktorjev, zato je tudi v načinih

upravljanja agilnih timov potrebno zavedanje, da ljudje nismo stroji. Timom je treba

zagotoviti prijazno okolje, ki spodbuja produktivnost, in intelektualne procese, kot so

razmišljanje, razvoj novih idej in pozitivni kolektivni duh. [22] Vodje so prav tako zaslužni za

ustrezno nagrajevanje uspešnih idej. Nagrada za uspešno izvedene ideje ima dober vpliv

na moralo, spodbuja k razvoju in inovacijam. Po drugi strani pa lahko slabo prakticiranje

nagrajevanja uspeha pušča negativne posledice na morali in samoiniciativnosti članov tima.

[22]

Od vodje se prav tako pričakujejo ustrezna moralna podpora, motivacija in usmerjanje v

težkih in napetih časih. Pod pritiskom (roki, proračun, stranke) lahko izbruhnejo

neproduktivni konflikti in negativno vedenje, ki imajo za razvoj tima in kakovost končnega

izdelka lahko trajne posledice. [110] Raziskovalci menijo, da takšne situacije [110]

zahtevajo močno in odločno vodenje v nasprotju s slabotnim in z mehkim vodenjem. Vodje

morajo tudi v konfliktnih in stresnih trenutkih ohraniti racionalno mišljenje in trezno presojo,

neobarvano z negativnimi čustvi, neuspehe pa predstaviti kot možnost za učenje iz

izkušenj/napak. [22]

Motivacija

46

Raziskave (predstavljene v poglavju 5.5) so pokazale, da so ljudje učinkovitejši in

produktivnejši, ko opravljajo naloge, ki jih sami želijo opravljati, v nasprotju s tistimi, ki so

jim dodeljene. Agilne metode se zanašajo na posameznikovo in timsko predanost ter

entuziazem. Naloga in izziv vodij je spodbujanje delovnega zanosa6. Kelly [22] kot ključne

motivacijske faktorje dobrih razvijalcev PO prepoznava: kakovostno delo, ki vpliva na

ponos, uspešno opravljeno delo, ki povzroča zadovoljstvo, ter učenje in reševanje

problemov, ki predstavljajo nove izzive.

Poslušanje

Kot smo že poudarili v poglavju 4.4, je aktivno vključevanje posameznikov v razvoj

ključnega pomena. Potreben je konstruktiven pristop, ki vključuje manj avtoritarnosti in več

demokratičnosti – poslušanja in upoštevanja pogledov in mnenj posameznikov, pa naj bo

ta uporabnik, stranka ali član tima. Izkoristek in uporaba znanja vseh posameznikov sta

mogoča le z aktivnim poslušanjem in vključevanjem. [22] To pa ni vedno enostavno,

poslušanje namreč zahteva čas, odprtost in osredotočenost. V zameno za to upravitelji

pridobijo povratne informacije in se učijo o kolektivnem okolju, problemih ter priložnostih, ki

jih člani tima prepoznavajo. Vodje izkazujejo zanimanje za posameznika, željo po

pravičnosti, spoštovanju in zaupanju, istočasno pa pridobivajo dodatne informacije o

problemih in priložnostih znotraj sistema. Motivacija članov se poveča, če čutijo, da je

njihovo mnenje spoštovano in upoštevano. Predanost delu je večja, posredno pa je večja

tudi produktivnost. Treba je upoštevati tudi razlike med ljudmi, npr. nekateri lažje

komunicirajo za zaprtimi vrati, medtem ko drugi brez težav izražajo mnenje pred ostalimi.

[22]

Opolnomočenje oz. pooblaščanje

Ljudje na spremembe reagirajo različno; včasih na nepredvidljive načine. Agilnost zahteva

obravnavanje vsake osebe kot posameznika s specifičnimi psihičnimi lastnostmi, procesi in

stanji (interesi, potrebe, pričakovanja, strahovi ...). Vsak posameznik poseduje unikaten

potencial in k timu doprinese svoj niz talentov in spretnosti. [22] Agilni timi za uspešno in

učinkovito delovanje potrebujejo določeno mero avtonomnosti in pooblastil (več o tem v

poglavju 5.8). Posameznikom, ki aktivno sodelujejo v razvoju, mora biti omogočeno okolje,

ki jim zagotavlja neovirano prenašanje znanja in izkušenj v proces razvoja.

6 Zanos je močna čustvena vznemirjenost zaradi zelo pozitivnega odnosa do česa. [149]

47

Business Dictionary pooblaščanje oz. opolnomočenje definira kot »prakso deljenja

informacij, nagrad in moči z zaposlenimi, tako da ti lahko samoiniciativno sprejemajo

odločitve z namenom reševanja problemov, izboljšanja storitve in učinkovitosti.« [111]

Pooblaščanje v splošnem pomeni delegiranje7 avtoritete in opravil ter zaupanje v

sposobnosti članov tima. Z ustreznimi pooblastili timi prilagodijo delo psihološkim lastnostim

in posameznim članom, kar zagotavlja višjo motivacijo in produktivnost. [103] [101] [105]

[22] [112]

Upravitelji, ki ne prakticirajo pooblaščanja, tvegajo nepopoln vnos znanja in izkušenj v

sistem, onemogočajo polno učinkovitost timov in jih prisilijo v način dela, ki se morda ne

sklada s potrebami in z lastnostmi članov. [22] Študija [113], v kateri so strokovnjaki

raziskovali faktorje, ki ovirajo učinkovito sprejemanje odločitev v agilnem razvoju, je med

drugim razkrila, da ravno pomanjkanje pooblaščanja oz. pooblastil (vključno z drugimi

faktorji) v agilnih timih privede do pomanjkanja dolgoročnega, strateškega odločanja,

zakasnitve opravil iz predhodnih iteracij in do pomanjkanja sodelovanja znotraj tima. [113]

Opolnomočenje mora biti avtentično, ne zaigrano. Večjo pomembnost kot izrečene besede

predstavlja način vedenja. Posamezniki morajo dobiti vtis, da je avtoriteta avtentična in

dobronamerna. Prvi pogoj za to, da je avtoriteta upraviteljev tudi neformalna, ne zgolj

formalna (tj. da izvira iz osebnostnih lastnosti, ki jih člani spoštujejo, ne zgolj iz pozicije

moči), je, da si upravitelji za svoje podrejene vzamejo čas. Ko vodje članom naklonijo svoj

čas, jim pokažejo, da so cenjeni. Prav tako zagotavljanje ustreznega časa za premislek in

diskusijo o idejah izboljša kakovost rešitev in blokira neustrezne ali neučinkovite ideje. [22]

Konflikti v povezavi z opolnomočenjem

Opolnomočenje timov in posameznikov še ne pomeni, da se ustvari glasna atmosfera, v

kateri bo vsak član aktivno prispeval nove ideje. Posamezniki prejmejo določeno stopnjo

svobode pri odločanju o tem, kako bodo delo opravljali. Glede na različne osebnosti

posameznikov je treba razumeti, da se bodo različni člani na pooblastila odzvali različno.

Nekateri bodo to izkoristili za aktivnejši pristop k razvoju in uvajanju novih idej, drugi, bolj

introvertirani, pa se bodo odločili za tišji in umirjenejši pristop. Problem nastopi, kadar se

zaradi opolnomočenja večina posameznikov usmeri k neaktivnim vlogam, kar zavira

7 Delegiranje je dejanje predajanja določene naloge, dolžnosti ali pravice nekomu drugemu, ki jo opravi za vas. To pomeni, da osebe, ki jim je bila delegirana naloga, lahko delujejo z določeno stopnjo neodvisnosti in hkrati skupaj z vami prevzemajo soodgovornost za izvedbo določenih nalog. [150]

48

spremembe in aktiven razvoj. Lahko se zgodi, da posamezniki pričnejo izkoriščati

pooblastila ali jih interpretirajo na napačen način. Kelly [22] kot primer navede udeležbo na

sestankih. Večja pooblastila si lahko posameznik razlaga na način, da je njegovo delo

pomembnejše od dela ostalih, zaradi česar se npr. sestanka ne udeleži ob dogovorjeni uri.

V takšnih situacijah pooblastila posameznikov vplivajo na celoten tim in so lahko vir

konfliktov. Potencialne napetosti je treba aktivno spremljati in se z njimi ustrezno in hitro

soočiti, preden uidejo iz nadzora ali povzročijo resnejše in trajne negativne posledice na

funkcioniranju tima. Zato je opolnomočenje kljub pozitivnemu namenu izredno delikatna

praksa, ki zahteva veliko energije, izkušenj in znanja. Prav tako je ključnega pomena, da

se v začetku opolnomočenja jasno opredelijo obseg pooblastil, identificirajo potencialne

težave in se po možnosti v naprej razrešijo. [22]

Razvoj vodij

Morebitne kandidate za bodoče vodilne položaje predstavljajo tisti, ki aktivno sodelujejo pri

razvoju novih idej, so se pripravljeni soočati s tveganjem, se ne bojijo sprememb in dobro

razumejo delo, ki ga opravljajo. Naloga vodij je prepoznavanje takšnih posameznikov ter

ustrezno profesionalno razvijanje njihovih potencialov s promoviranjem in z višjimi

pooblastili (napredovanji). Zaradi širokega nabora obveznosti upravitelji timov niso vedno

prisotni v timu in razvojnem procesu na sploh. Zato se pojavi potreba po uvajanju t. i.

načelnikov, ki v odsotnosti upraviteljev usmerjajo člane. Takšni člani prav tako neposredno

komunicirajo z ostalimi člani tima in se udeležujejo konferenc ali sestankov, na katerih

predstavljajo interese organizacije. [22]

Problemi pri upravljanju

»Ljudje niso popolni, delajo napake, so neurejeni in ne sledijo ganttovim diagramom.« [53]

»Projektno upravljanje na področju RPO verjetno predstavlja območje z najvišjo stopnjo

neuspeha.« [114]

V knjigi Peopleware: Productive Projects and Teams [13] sta Mary in Tom Poppendieck kot

najpogostejši vzrok za neuspeh projektov prepoznala t. i. pisarniško politiko. Pojem se

nanaša na probleme z osebjem, nesoglasja z upravitelji ali s strankami, pomanjkanje

motivacije in visok promet. [13] Te težave so bolj socialne kot tehnične narave. Velik

problem tradicionalnih in tudi nekaterih sodobnih upraviteljskih praks predstavlja prenizko

vrednotenje človeških faktorjev. V omenjeni knjigi avtorja prav tako omenita pojem

49

»visokotehnološke iluzije«, ki pomeni, da večina ljudi uporablja visokotehnološka, sodobna

orodja z namenom razvoja izdelkov in organizacije odnosov [13] ter pri tem vlaga preveč

truda in skrbi v tehnične namesto v človeške vidike (dobri odnosi, učinkovita dvosmerna

komunikacija, jasno zastavljeni cilji, moralna podpora znotraj tima, demokratičnost vodenja,

spodbujanje strokovnega izpopolnjevanja …). [53]

»Ljudje so najpomembnejše sredstvo organizacij, osnovna naloga upravitelja je

usmerjenost k ljudem; v kolikor ni prisotnega ustreznega razumevanja človeških faktorjev,

bo upravljanje neuspešno. Slabo upravljanje ljudi vodi do neuspešnih projektov.« [115] [21]

5.7 Komunikacija in zaupanje

»Agilni pristopi temeljijo na zaupanju, učinkoviti komunikaciji in ustrezni osebni

organizaciji.« [60]

Da bi dosegli ustrezno sodelovanje med različnimi člani multidisciplinarnega tima, ki

delujejo v smeri določenega cilja, je nujno potrebna spretna komunikacija. [29] Zgodi se, da

se predstavniki različnih disciplin osredotočajo zgolj na pomen svoje stroke in ne upoštevajo

mnenja ostalih strokovnjakov v timu. Prav tako se lahko zgodi, da določeni člani izgubijo

občutek za skupno vizijo projekta in se egocentrično poglabljajo zgolj v probleme lastne

stroke. [116] Kakovostna komunikacija je neposredno povezana z učinkovitim razvojem

timov, prav tako pomembno vlogo pa igra zaupanje. Od zaupljivih članov se lahko pričakuje

izjemne rezultate v timskem delu. Prav tako se z zaupljivim okoljem podjetja izognejo

izkoriščanju delikatnih informacij. [117] V kolikor članom tima ne uspe razviti ustreznega

nivoja zaupanja, lahko to povzroči napetosti, ki vplivajo na ekonomske in tehnološke vidike.

[118] Razvoj zaupanja znotraj timov je najučinkoviteje dosežen z ustrezno komunikacijo.

Učinkovita komunikacija poveča medsebojno razumevanje in identifikacijo s skupino,

občutek varnosti znotraj skupine, samozavest in povzroči predvidljivejše interakcije. [117]

[29] Učinkovita multidisciplinarna komunikacija zahteva dobro poznavanje razlik med

posameznimi disciplinami, razlik v vrednotah in interesih, v verbalni, neverbalni in e-

komunikaciji, izogibanje predsodkom in stereotipom, kot predpogoj pa dobro poznavanje

samega sebe. [116] Upoštevati je treba tudi možnost, da pri nekaterih članih nove

tehnologije, ki še niso popolnoma ustaljene ali sprejete, vzbujajo skrbi, strahove, občutke

negotovosti ali zapostavljenosti. S primerno komunikacijo je treba preseči takšne občutke,

saj je za učinkovito timsko delo potrebno občutje varnosti vseh posameznih članov. [29]

[116]

50

5.8 Vpliv raznolikosti in avtonomnosti na agilnost timov

Rezultati študije [119] potrjujejo, da se bolj raznolike skupine bolje odzivajo na spremembe,

ker imajo člani različne izkušnje in spretnosti. Timi, ki niso raznoliki, lahko padejo v t. i.

tunelski vid – probleme rešujejo rutinirano, na vedno enake načine, ki niso nujno optimalni

in postanejo neodprti za druge možnosti. Kljub temu tudi raznolikost skriva svoje pasti, ki

so zlasti v večji možnosti konfliktov in težavnosti komunikacije. [119]

Rezultati študije [119] so pokazali, da ima avtonomnost tima v splošnem pozitiven učinek,

avtonomni tim je načeloma odzivnejši na spremembe, počuti se samostojnejšega in

kompetentnejšega ter lažje sprejema odločitve. Nasprotno so manj avtonomni timi bolj

vezani na sledenje avtoritarnim navodilom. Pokazala se je tudi izredna učinkovitost v

odzivanju na spremembe, delno zaradi notranje avtoritete (pooblastil) za sprejemanje

odločitev. Avtonomni timi RPO so občasno omejili svojo odzivnost na spreminjajoče se

zahteve z namenom dosege projektnih ciljev, ker so bili dovolj opolnomočeni, da so lahko

sami odločili, kako se bodo na spremembe odzvali, medtem ko manj avtonomni timi niso

imeli izbire in so morali sprejeti »ukaze« stranke/uporabnikov in jih implementirati. Zato v

nekaterih primerih avtonomnost lahko tudi zmanjša mero odzivnosti na spreminjajoče se

zahteve. [119]

5.9 Zdravje zaposlenih na področju razvoja programske opreme

Pomemben človeški vidik, na katerega je v sodobnem času usmerjena vse večja pozornost,

je tudi fizično zdravje ‒ telesne posledice, povezane z redno ali s pretirano uporabo

računalnika in računalniške opreme.

Mišično-skeletna obolenja in težave z vidom

Mišično-skeletna obolenja na delovnem mestu prestavljajo pogost vir zaskrbljenosti na IT-

področju. [120] Raziskovalci so v študiji [120] prepoznavali faktorje tveganja, ki lahko

povzročijo mišično-skeletna obolenja v IT-podjetjih v Indiji. Ugotovili so, da glavne faktorje

predstavljajo slaba ergonomska ureditev in opremljenost pisarne, pomanjkanje počival za

noge in kar v 80 % primerov neprimerna višina zaslona. Rezultati so razkrili tudi telesne

predele, ki so največkrat nosili posledice. Med temi so bili predvsem vrat, spodnji del

hrbtenice (križ) in ramena. [120]

V drugi študiji [121] so znanstveniki raziskovali mišično-skeletna obolenja v indijskih IT-

podjetjih ter ugotovili, da lahko problem leži tudi v pomanjkanju odmorov, socialnih pritiskih,

51

prekratkih rokih, preveliki ambicioznosti, v delu po načelu »čim več v čim krajšem času«.

Prav tako je 63 % sodelujočih (izmed 4500) poročalo o simptomih bolečine. Škodljiv način

dela zaradi izredno ambicioznih rokov je obsegal predvsem pomanjkanje odmorov,

družbeno odzivnost in pritiske. [121]

Naslednja raziskava [122], izvedena na vzorcu okrog 200 IT-strokovnjakih v Indiji, je

pokazala, da kar 77,5 % udeležencev poroča o simptomih mišično-skeletnih obolenj. Bolj

specifični izsledki so pokazali, da so udeleženci, ki niso uporabljali t. i. mat zaslonov ali niso

imeli dovolj svetlobe, pogosto razvili probleme z vidom. Kar 80 % jih ni imelo zaslona na

pravi višini. [122]

Še ena študija [25] iz Indije, ki je raziskovala razširjenost problemov z vidom in mišično-

skeletnimi obolenji, je pokazala, da jih je izmed 200 IT-strokovnjakov (med njimi tudi

razvijalci PO) kar 76 % imelo težave z vidom in 76,5 % mišično-skeletne težave. O

omenjenih težavah so udeleženci raziskave poročali predvsem po večurnem delu za

računalnikom. Podobno kot v prejšnji študiji so rezultati pokazali, da je bilo manj težav z

vidom med posamezniki, ki so uporabljali mat zaslone in zadostno osvetlitev v prostoru.

Raven mišično-skeletnih obolenj je upadla tudi z uporabo oblazinjenih stolov in nežne

tipkovnice. [25]

Jasno je torej, da so mišično-skeletna obolenja in težave z vidom na področju RPO izredno

pogoste težave, zato je treba zagotoviti ustrezno preventivo in kurativo. V študiji [123] so s

tem namenom znanstveno raziskali vpliv joge na mišično-skeletno nelagodje in motorične

funkcije strokovnjakov na področju R-IT. Ugotovili so, da je skupina, ki je prakticirala jogo

petkrat tedensko po eno uro, po šestdesetih dnevih kazala znaten upad v frekvenci in

intenzivnosti pojavitve mišično-skeletnih bolečin. Poleg tega je poročala tudi o boljših

motoričnih funkcijah in večji gibčnosti. V nasprotju z njo pa je kontrolna skupina, ki se z jogo

ni ukvarjala, kazala povečanje mišično-skeletnega nelagodja in poslabšanje motoričnih

funkcij. [123]

Mentalna izgorelost

»Nenehna in intenzivna izpostavljenost stresu na delovnem mestu rezultira v mentalno

izgorelost« [124] in »spodbudi neprijetno stanje duha.« [27]

52

Pojem mentalne izgorelosti je v disciplini človeških faktorjev oz. ergonomiji prisoten že kar

nekaj časa. Problem se širi na globalno raven in v sodobnem času dosega kritične nivoje.

[27] Mentalna izgorelost je posledica postopne erozije posameznikovih mentalnih zalog in

energije, ki se pokaže v obliki utrujenosti, ciničnosti in nizki strokovni učinkovitosti na

delovnem mestu. [27] Posledice pa ne vplivajo zgolj na kratkoročno poslabšano

učinkovitost, temveč lahko imajo trajen vpliv na fizično [125] in mentalno zdravje [126] ter

povzročajo vedenjske probleme. [127] [27]

Izgorelost v kontekstu dela oz. t. i. delovna izgorelost je večdimenzionalen konstrukt,

sestavljen iz čustvene utrujenosti, depersonalizacije, zmanjšane uspešnosti [27],

nespečnosti, motenj hranjenja, glavobolov in drugih psihosomatskih motenj (telesnih motenj

psihičnega izvora).

Mentalna izgorelost je dokaj obširno raziskan pojem, na področju RPO pa študij

primanjkuje. Najbolj so izpostavljeni predvsem razvijalci, in sicer zaradi dela na različnih

projektih naenkrat [27] ter zaradi časovnih, upravljavskih in proračunskih pritiskov, ki

vključujejo težko dosegljive roke, podaljšane delovne ure in nenehno spreminjajoče se

zahteve strank (več o tem v poglavju 4.4). Poleg tega so izpostavljeni tudi »ponavljajočim

in monotonim opravilom, konfliktom v timih, anksioznosti zaradi tekmovalne narave RPO-

področja, bremenu visokih pričakovanj in raznim negotovostim na delovnem mestu.« [27]

Znanstveniki [27] so prav tako poročali o tem, da so na posameznikovo lagodje vplivali

predvsem družbena podpora, pozitiven vpliv pa je imelo tudi prakticiranje joge in meditacije.

[128] Tveganje izgorelosti pa lahko zmanjšamo tudi z nižanjem obremenitev, dobro

organizacijo dela in prostega časa, ustrezno prehrano in redno rekreacijo. [28]

5.10 Učinkovito upravljanje časa – pomodoro tehnika

Učinkovit RPO zahteva visoko produktivnost in predvsem hitrost dela. To je še posebej

pomembno pri agilnih metodah (npr. scrum), kjer je v vsakem sprintu (časovnem okvirju)

treba dostaviti delujočo rešitev. Pri takšnem načinu razvoja dela ni mogoče prelagati ali

odlašati z njim, saj je časovni pritisk izjemno močan. Ena od aktualnih metod za

učinkovitejšo izrabo časa je »tehnika pomodoro«, ki svojo uporabnost kaže tudi na področju

agilnega RPO. Temeljne lastnosti metode pomodoro so blizu osnovnim principom agilnega

razvoja, kot so iterativno in inkrementalno delo ter prakticiranje časovnih okvirov. [129]

53

Med načeli agilnosti [51] najdemo besede, kot so »pogosto«, »hitro«, »dnevno«, »nekaj

tednov«, »redni intervali« − vse te izpostavljajo pomembnost časa in njegove učinkovite

izrabe. V tradicionalnih začetkih RPO so projekti zaradi prekoračenih rokov in proračunov

doživljali velike neuspehe. Razvojni timi so tako pri tradicionalnih kot pri agilnih metodah v

času trajanja projekta težko izognejo stresu in anksioznosti (tesnoba, napetost,

zaskrbljenost). Leta 1975 je Brooks [130] zapisal, da je »več RPO projektov doživelo

neuspeh zaradi pomanjkanja koledarskega časa kot zaradi vseh ostalih dejavnikov skupaj.«

Tehnika pomodoro je bila prvotno namenjena optimizaciji osebnega dela in učenja/študija,

v zadnjem času pa so jo prevzeli italijanski agilni timi za RPO. [131] Pomodoro v italijanščini

pomeni paradižnik; tehnika je ime dobila po prvotni uporabi časovnikov v obliki paradižnika.

Delovni čas je razdeljen na petindvajsetminutne segmente osredotočenega,

neprekinjenega dela, ki jim sledijo petminutni odmori. Po štirih zaporednih segmentih sledi

petnajstminutni odmor. Teorija, na kateri temelji tehnika, razlaga, da se s takšno

porazdelitvijo dela in odmorov izognemo mentalni utrujenosti in posledično izgorelosti [132]

ter povečamo mentalno agilnost in produktivnost dela. [133]

S študijo [133] o uporabi pomodoro tehnike v agilnih timih so raziskovalci ugotovili, da ta

predstavlja dobrodošlo orodje, ki omogoči učinkovitejše soočanje s hitrimi spremembami in

agilnim delom. V raziskavi prav tako izpostavijo morebitne težave, s katerimi se lahko

soočijo timi, ki se odločijo za uporabo tega pristopa, npr. kako spodbuditi člane, da si

vzamejo odmor, in kakšne časovnike uporabljati v odprtih pisarnah. [133]

54

6 SKLEP

V nalogi smo raziskali in analizirali obstoječo literaturo, povezano s ČF v RPO. Prepoznali

smo psihološke, družbene, kulturne in organizacijske vidike RPO. Z analizo tradicionalnega

razmišljanja in kaskadnega modela smo ugotovili, da vzroki za neuspešnost projektov ležijo

predvsem v pretirani dokumentaciji, neustrezni komunikaciji (med člani tima, med timi in

strankami, med timi in upravitelji), nezadostni odzivnosti na tekoče spremembe in

neupoštevanju povratnih informacij med razvojem. Raziskali smo izvore agilne ideologije,

lastnosti agilnega in konceptualni pomen agilnosti in lean razvoja, ki je pogosto napak

razumljen. Z zgledi sodobnih podjetij smo predstavili prednosti agilnega razvoja in razkrili

območja potencialnih izboljšav. Izkazalo se je, da agilno v določenih primerih prenizko

vrednoti pomen predhodnega načrtovanja, da je konstantno vključevanje predstavnikov

strank lahko problematično in da način dela z rednim pridobivanjem povratnih informacij ni

vedno ustrezen. Analiza agilnih metodologij je razkrila, da najboljša metoda ne obstaja,

temveč da najučinkovitejši pristop predstavljajo združene tehnike različnih agilnih metod, ki

najbolj ustrezajo potrebam in lastnostim organizacije oz. razvojnega tima. Pri tem pa je

treba paziti, da si temeljna načela različnih tehnik ne nasprotujejo oz. da so združljiva. Prav

tako smo ugotovili, da se agilne ideje lahko prenesejo na podobne industrije, ki se ukvarjajo

z razvojem novih izdelkov ali tehnologij in zahtevajo fleksibilne upravljavske pristope.

V sklopu timskega dela smo analizirali temeljne lastnosti timov, ki jih razlikujejo od navadnih

skupin, predstavili razvoj timov, ki poteka v štirih fazah: oblikovanje, viharjenje, normiranje,

delovanje, in se v primeru začasnih timov zaključi v peti fazi, imenovani zaključevanje.

Prepoznali smo pomembna vedenja in situacije, s katerimi se timi soočijo v posameznih

fazah. Ugotovili smo, da imajo različne osebnosti (glede na »big five« model) pomembno

vlogo pri učinkovitosti timov. Predhodne analize osebnostnih lastnosti razvijalcev pozitivno

vplivajo na sestavo učinkovitih timov, saj s tem zagotovimo višjo primernost članov za

določena opravila.

Upravljanje timov se v sodobnih agilnih pristopih znatno razlikuje od tradicionalnega.

Aktivnosti, ki jih agilni upravljavci prakticirajo, so vodenje (nad avtoriteto), pooblaščanje

(opolnomočenje), aktivno poslušanje in razvoj novih vodij znotraj timov. Kot pomembna

faktorja timskega dela sta se izkazala predvsem komunikacija in zaupanje. Prav tako sta

se kot pomembni za delo v timih pokazali dve lastnosti: raznolikost in avtonomnost.

55

V sklopu vplivov na fizično in psihično zdravje razvijalcev PO smo ugotovili, da poglavitne

težave predstavljajo predvsem mišično-skeletna obolenja, poslabšan vid in mentalna

izgorelost. Mišično-skeletna obolenja in poslabšan vid sta bila v večini primerov povezana

z neustrezno ergonomsko ureditvijo delovnih mest (sedišča, višina zaslona, tip tipkovnice,

tip zaslona in neustrezna osvetlitev v prostoru). Pozitivni vpliv je predstavljala predvsem

uporaba mat zaslonov, nežnih tipkovnic, oblazinjenih stolov in prakticiranje joge. Mentalna

izgorelost pa je vzrok nenehnih pritiskov sodobnega RPO (pomanjkanje odmorov, socialni

pritiski, prekratki roki, prevelika ambicioznost) in jo lahko ustrezno zmanjšata predvsem

pozitivna socialna podpora ali uporaba tehnik sproščanja, kot je npr. joga.

»Tehnika pomodoro« se je izkazala za učinkovito metodo upravljanja časa, ki ima potencial

tudi na področju sodobnega RPO. Vendar pa slabo raziskana povezava te z RPO kliče po

novih raziskavah.

Ob pregledu literature smo ugotovili, da je izbrana tema izjemno široka in predmet različnih

interpretacij. Kljub temu da se pomen človeških faktorjev v RPO v sodobnem času veča, še

vedno obstaja veliko neraziskanih področij, ki jih je treba vzeti za predmet raziskovanja v

prihodnjih študijah. Med takšne primere sodijo predvsem raziskovanje povezav s »spletom

stvari« (internet of things) in z umetno inteligenco.

Zaradi prevelikega obsega celotne tematike smo se odločili, da predmet raziskovanja

omejimo na sodobne agilne ideje, timsko delo, upravljanje ter zdravje in produktivnost

razvijalcev. Tako nismo obdelali IČR (interakcije med človekom in računalnikom), aktualnih

problematik na področju tehnologije (zasebnost, zasvojenost, »digitalni razkorak«, vpliv

spola med zaposlenimi na področju RPO), urejenosti delovnega mesta (akustika, ureditev

pisarne …), dela v globalno razdeljenih timih, trenutno priljubljenega »outsourcinga« RPO

(zunanje izvajanje razvoja) in aktualne igre obogatene resničnosti - Pokemon Go.

Z ergonomijo pisarne oz. delovnega mesta bi pridobili aktualne informacije o faktorjih, ki

omogočajo prijetno in lagodno okolje za razvoj novih idej, tekočo komunikacijo in ustrezno

mero zasebnosti. Analiza področja IČR bi dodala vpogled v uporabniško perspektivo in z

uporabnikom povezanimi človeškimi faktorji. Med te sodijo zlasti načela oblikovanja, pojem

uporabnosti sistemov ter razvoj varnih in zanesljivih sistemov. Z raziskavo omenjenih

faktorjev bi pridobili informacije o tem, kako z ustreznim RPO nasloviti čim širšo množico

(glede na starost, kulturo …)

56

V sklopu aktualnih problematik se najpogosteje omenjajo zasvojenost, zasebnost, digitalni

razkorak in problem spola na področju RPO. Problem zasebnosti se s hitrim razvojem PO

znatno veča. Sodobni PO namreč izkorišča številne senzorje za pridobivanje raznovrstnih

informacij. Od teh največje tveganje predstavljajo lokacijski senzorji, ki nudijo podatke o

trenutni in preteklih lokacijah uporabe naprave oz. PO. Zasvojenost je prav tako problem,

ki ga je treba izpostaviti. Čeprav se v tolikšni meri ne nanaša na sam proces RPO, je ena

izmed njegovih neposrednih posledic. V sodobnih časih igra pomembno vlogo na področju

tehnologije tudi t. i. digitalni razkorak, ki pomeni »neenakost, ki jo povzroči nezmožnost

dostopa ali sposobnosti uporabe informacijskih tehnologij.« [134] Digitalni razkorak

predstavlja problem in pomemben faktor predvsem zaradi široke uporabe PO v sodobnem

življenju, kar pomeni, da so tisti, ki nimajo ustreznega stika s tehnologijo, prikrajšani za

informacije, ki so lahko ključne za njihovo preživetje (npr. obveščanje o naravnih

katastrofah) [29]. Zaradi tega je potreba po aktivnem soočanju s to problematiko vse

aktualnejša. Kot primer lahko navedemo organizacijo internet.org, ki si s soustanoviteljem

Facebooka Markom Zuckerbergom na čelu aktivno prizadeva za zagotavljanje spletne

povezave čim širši množici ljudi. [135] Problem spola izpostavi statistika LinkedIn [136], ki

priča o 16-odstotni ženski populaciji med zaposlenimi na področju RPO. Morebitna rešitev

omenjenega problema, ki bi lahko predstavljala osnovo za nadaljnje raziskave, je trženje z

uporabo vzornikov ženskega spola na področju RPO (npr. v filmih, serijah ali oglasih). [136]

Raziskovanje razlik v spolu med zaposlenimi na področju RPO bi omogočilo vpogled v

razloge za nizko prisotnost žensk in hkrati prepoznavo morebitnih opravil oz. funkcij,

primernejših za specifični spol. [29]

Globalno razdeljeni timi so zaradi zanesljivih programskih orodij in široke dostopnosti spleta

vedno bolj prisotni na področju RPO. Pregled študij na to temo bi omogočil vpogled v

procese zagotavljanja ustrezne klime, tekoče komunikacije in vzpostavljanja mehanizmov

za soočanje s konflikti. Z analizo »outsourcinga« RPO bi prepoznali prednosti in slabosti,

povezane s to aktivnostjo, identificirali najpopularnejše destinacije, odkrili, ali »outsourcing«

vpliva na kakovost PO, in raziskali, kako zagotoviti najustreznejše razmerje med ceno

podizvajalca in kakovostjo izdelka.

Analiza aktualne igre obogatene resničnosti, imenovane Pokemon Go, bi služila kot

aktualen primer za omenjeno problematiko zasebnosti in zasvojenosti. Prav tako bi

57

omogočila vpogled v lastnosti kakovostne opreme PO, v procese, ki so zagotovili takšno

mero uspešnosti in koristi, ki se kažejo predvsem v povečani telesni aktivnosti uporabnikov.

Za konec bi radi izpostavili nekaj napotkov za študij literature. Opazili smo, da je literatura

na področju RPO in metodologij dokaj slabo organizirana in lahko tudi različno

interpretirana. Različni viri do neke mere različno pojmujejo in razlagajo iste ideje. S

konceptualnega vidika obstaja veliko nejasnosti, ki jih je treba ustrezno razrešiti. Nekateri

viri npr. vitke pristope uvrščajo med agilne metode [44], medtem ko drugi agilno pojmujejo

kot podmnožico vitkih idej. [22] Predlagamo izdelavo dela, ki bi na jasen, organiziran in

konceptualno razumljiv način nudilo pregled nad procesom RPO in z njim povezanimi

metodologijami.

58

VIRI

[1] „Human Factors and Ergonomics Society,“ avgust 2000. [Elektronski]. Available:

https://www.hfes.org//Web/AboutHFES/about.html. [Poskus dostopa 3. avgust

2016].

[2] A. Chapanis in W. K. Holstein, „Human-factors engineering,“ v Encyclopædia

Britannica, 2014.

[3] M. Kocjan-Barle, D. Bajt, M. Bencina, D. Cuden, A. Janko, N. Slibar, M. Jamnik in N.

... Torelli, Slovenski veliki leksikon, Ljubljana: Mladinska knjiga Zalozba, 2006.

[4] „development,“ [Elektronski]. Available:

http://www.businessdictionary.com/definition/development.html. [Poskus dostopa 4.

avgust 2016].

[5] „development,“ 2016. [Elektronski]. Available: http://www.merriam-

webster.com/dictionary/development. [Poskus dostopa 4. avgust 2016].

[6] „Computer Hope,“ 2016. [Elektronski]. Available:

http://www.computerhope.com/jargon/s/software.htm. [Poskus dostopa 4. avgust

2016].

[7] „IBM Terminology,“ 2016. [Elektronski]. Available: https://www-

01.ibm.com/software/globalization/terminology/s.html. [Poskus dostopa 6. avgust

2016].

[8] M. Dziak, „Computer Software,“ v Salem Press Encyclopedia of Science, 2015.

[9] „New Product Development Glossary,“ 2016. [Elektronski]. Available:

http://www.npd-solutions.com/glossary.html. [Poskus dostopa 5. avgust 2016].

[10] J. Lasky, „Software development,“ v Salem Press Encyclopedia, 2015.

[11] L. Testa, Growing Software : Proven Strategies for Managing Software Engineers,

San Francisco: No Starch Press, 2009.

[12] „Glossary of Computer System Software Development Terminology (8/95),“ 2016.

[Elektronski]. Available:

http://www.fda.gov/iceci/inspections/inspectionguides/ucm074875.htm. [Poskus

dostopa 5. avgust 2016].

[13] T. DeMarco in T. Lister, Peopleware: productive projects and teams (Second

Edition), New York, NY: Dorset House Pub., 1999.

59

[14] M. John, F. Maurer in B. Tessem, „Human and social factors of software engineering:

workshop summary,“ v SIGSOFT Softw. Eng., 2005.

[15] S. Saeed, I. S. Bajwa in Z. Mahmood, Human Factors in Software Development and

Design, Hershey, PA: IGI Global, 2015.

[16] C. Amrit, M. Daneva in D. Damian, „Human factors in software development: On its

underlying theories and the value of learning from related disciplines. A guest

editorial introduction to the special issue.,“ Information And Software Technology 56,

no. Special issue: Human Factors in Software Development, Izv. 56(12), pp. 1537-

1542, 2014.

[17] O. Hazzan, „Putting Human Aspects of Software Engineering in University Curricula,“

IEEE Software, Izv. 27(4), pp. 90-91, 2010.

[18] L. Pirzadeh, „Human factors in software development: a systematic literature review,“

2010. [Elektronski]. Available:

http://publications.lib.chalmers.se/records/fulltext/126748.pdf. [Poskus dostopa 1.

avgust 2016].

[19] A. Cockburn, „Growth of human factors in application development,“ 1. oktober 1995.

[Elektronski]. Available:

http://alistair.cockburn.us/Growth+of+human+factors+in+application+development.

[Poskus dostopa 4. avgust 2016].

[20] „UM:NIK - univerzitetni iskalnik,“ 6 avgust 2016. [Elektronski]. Available:

http://www.ukm.um.si. [Poskus dostopa 6. avgust 2016].

[21] M. A. Othman, A. M. Sherif in E. Ehab, „Survey: Problems related to human in

software projects,“ IOSR Journal of Computer Engineering (OISR-JCE), pp. 67-70,

2013.

[22] A. Kelly, Changing Software Development: Learning To Become Agile, Chichester,

England: Wiley, 2008.

[23] M. Fowler, „Agile versus Lean,“ 26. junij 2008. [Elektronski]. Available:

http://martinfowler.com/bliki/AgileVersusLean.html. [Poskus dostopa 5. avgust

2016].

[24] R. A. Wienclaw, „Teams & Team Building,“ 2010. [Elektronski]. Available: Research

Starters: Business (Online Edition). [Poskus dostopa 28. julij 2016].

60

[25] R. Talwar, R. Kapoor, K. Puri, K. Bansal in S. Singh, „A Study of Visual and

Musculoskeletal Health Disorders among Computer Professionals in NCR Delhi,“

Indian Journal Of Community Medicine, Izv. 34(4), pp. 326-328, 2009.

[26] S. Berolo, R. P. Wells in B. C. Amick, „Musculoskeletal symptoms among mobile

hand-held device users and their relationship to device use: A preliminary study in a

Canadian university population,“ Applied Ergonomics, Izv. 42(2), pp. 371-378, 2011.

[27] P. Singh in D. Suar, „Health Consequences and Buffers of Job Burnout among Indian

Software Developers,“ Psychological Studies, Izv. 58(1), pp. 20-32, 2013.

[28] W. L. Holcombe, Running an Agile Software Development Project, Hoboken, N.J:

Wiley, 2008.

[29] E. McKay, The Human-dimensions of Human-computer Interaction: Balancing the

HCI Equation, Amsterdam: IOS Press, 2008.

[30] C. Wohlin, D. Šmite in N. B. Moe, „A general theory of software engineering:

Balancing human, social and organizational capitals,“ The Journal Of Systems &

Software, Izv. 109, pp. 229-242, 2015.

[31] „knowledge,“ 2016. [Elektronski]. Available: http://www.merriam-

webster.com/dictionary/knowledge. [Poskus dostopa 5. avgust 2016].

[32] „Longman Dictionary of Contemporary English,“ 2016. [Elektronski]. Available:

http://www.ldoceonline.com/dictionary/knowledge. [Poskus dostopa 5. avgust 2016].

[33] B. Curtis, „The impact of individual differences in programmers,“ Working with

computers: Theory versus outcome, pp. 279-294, 1988.

[34] S. N. K. Watt, „Syntonicity and the Psychology of Programming,“ v 10th Workshop

for the Psychology of Programming Interest Group (PPIG), UK, 1998.

[35] E. Trainer, S. Quirk, C. de Souza in D. F. Redmiles, „Bridging the Gap Between

Technical and Social Dependencies with Ariadne,“ v OOPSLA Workshop on Eclipse

Technology eXchange (eTX), San Diego, 2005.

[36] R. Damaševičius, „On the human, organizational, and technical aspects of software

development and analysis,“ v Information Systems Development, US, Springer,

2009, pp. 11-19.

[37] D. Hales in C. Douce, „Modelling Software Organisations,“ v PPIG 2002, UK, 2002.

[38] M. E. Conway, „How do committees invent?,“ april 1968. [Elektronski]. Available:

http://www.melconway.com/Home/Committees_Paper.html. [Poskus dostopa 5.

avgust 2016].

61

[39] G. M. Weinberg, The Psychology of Computer Programming, New York, NY, USA:

John Wiley & Sons, Inc., 1985.

[40] I. T. B. Ørstavik, „How Programming Language Can Shape Interaction and Culture,“

v Int. European Conf. on Computing and Philosophy, ECAP , Trondheim, Norway,

2006.

[41] H. C. Sharp, M. Woodman, F. Hovenden in H. Robinson, „The Role of Culture in

Successful Software Process Improvement,“ v 25th Euromicro Conf., Milan, Italy,

1980.

[42] M. V. Zelkowitz, D. Wallace in D. Binkley, „Culture Conflicts in Software Engineering

Technology Transfer,“ v NASA Goddard Software Engineering Workshop,

Greenbelt, MD, USA, 1998.

[43] G. Borchers, „The software engineering impacts of cultural factors on multi-cultural

software development teams,“ v ICSE: International Conference On Software

Engineering, 2003.

[44] J. L. Cooke, Everything You Want to Know About Agile : How to Get Agile Results in

a Less-than-agile Organization, Ely, Cambridgeshire, U.K.: IT Governance

Publishing, 2012.

[45] P. Jongerius, Get Agile: Scrum for Ux, Design & Development, Amsterdam: BIS

Publishers, 2004.

[46] D. Feher, „Feher, David 's Answer to What are the pros and cons of the waterfall and

agile/scrum project management approach?,“ 24. marec 2013. [Elektronski].

Available: https://www.quora.com/What-are-the-pros-and-cons-of-the-waterfall-and-

agile-scrum-project-management-approach. [Poskus dostopa 5. avgust 2016].

[47] „Kaskadni (waterfall) model,“ [Elektronski]. Available: http://esistemi.si/kaskadni-

model. [Poskus dostopa 22. avgust 2016].

[48] Y. Hanoulle, „Hanoulle, Yves's Answer to What is better to use: a waterfall model or

Agile?,“ 7. marec 2015. [Elektronski]. Available: https://www.quora.com/What-is-

better-to-use-a-waterfall-model-or-Agile. [Poskus dostopa 5. avgust 2016].

[49] W. W. Royce, „Managing the development of large software systems,“ v IEEE

WESCON, 1970.

[50] K. Braithwaite, „Braithwaite, Keith's Answer to Agile Software Development: Any

academic work on the weaknesses of Waterfall methodology?,“ 29. junij 2012.

[Elektronski]. Available: https://www.quora.com/Agile-Software-Development-Any-

62

academic-work-on-the-weaknesses-of-Waterfall-methodology. [Poskus dostopa 5.

avgust 2016].

[51] K. Beck, M. Beedle, J. Grenning, J. S. K. M. S. Sutherland, D. Thomas, B. Marick, J.

Highsmith, R. C. W. Jeffries in M. Fowler, „Manifest agilnega razvoja programske

opreme,“ 2001. [Elektronski]. Available:

http://agilemanifesto.org/iso/sl/manifesto.html. [Poskus dostopa 4. avgust 2016].

[52] C. Codington-Lacerte, „Agile software development,“ v Salem Press Encyclopedia,

2013.

[53] A. ElGebeely, „Rethink the Software Development Process, the Human Factor,“ 9.

oktober 2012. [Elektronski]. Available:

http://www.ibm.com/developerworks/rational/library/rethink-software-development-

process/. [Poskus dostopa 3. avgust 2016].

[54] J. Highsmith, Agile Software Development Ecosystems, Reading, MA: Addison-

Wesley, 2002.

[55] V. Kutnik, J. Dovžan in S. Vuksanović, „Manifest agilnega razvoja programske

opreme,“ 2015. [Elektronski]. Available: http://infosrc.editiondigital.com/infosrc-st-

79#!manifest-agilnega-razvoja-programske-opreme. [Poskus dostopa 3. avgust

2016].

[56] A. Blixt, „Blixt, Andreas's Answer to Why do we need agile software development?,“

3. november 2015. [Elektronski]. Available: https://www.quora.com/Why-do-we-

need-agile-software-development. [Poskus dostopa 5. avgust 2016].

[57] „Standard glossary of terms used in Requirements Engineering,“ 2011. [Elektronski].

Available:

http://en.gasq.org/fileadmin/user_upload/redaktion/en/Data/REQB_Standard_gloss

ary_of_terms_used_in_Requirements_Engineering_1.0.pdf. [Poskus dostopa 5.

avgust 2016].

[58] M. Brhel, H. Meth, A. Maedche in K. Werder, „Exploring principles of user-centered

agile software development: A literature review,“ Information And Software

Technology, Izv. 61, pp. 163-181, maj 2015.

[59] C. A. Wellington, T. Briggs in C. D. Girard, „Examining Team Cohesion as an Effect

of Software Engineering Methodology,“ v Workshop on Human and Social Factors

of Software Engineering - HSSE '05, New York, NY, USA, 2005.

63

[60] J. O. Coplien in G. Bjørnvig, Lean Architecture for Agile Software Development,

Chichester, West Sussex, UK: Wiley, 2010.

[61] N. Sirina, „How to choose between Agile and Lean, Scrum and Kanban - which

methodology is the best?,“ 1. julij 2016. [Elektronski]. Available:

https://realtimeboard.com/blog/choose-between-agile-lean-scrum-

kanban/#.V6SUvTV4o7x. [Poskus dostopa 3. avgust 2016].

[62] D. Ramel, „Report cites FBI's 'weaknesses' on Agile development,“ 11. januar 2011.

[Elektronski]. Available: https://gcn.com/Articles/2011/01/11/ECG-Problems-with-

FBI-Approach-to-Agile.aspx. [Poskus dostopa 6. avgust 2016].

[63] A. Howard Holt, „Howard Holt, Ann's Answer to In what ways can the SCRUM

methodology fail?,“ 8. februar 2016. [Elektronski]. Available:

https://www.quora.com/In-what-ways-can-the-SCRUM-methodology-fail. [Poskus

dostopa 5. avgust 2016].

[64] VersionOne, „11th Annual State of Agile Survey - The Largest, Longest-Running

Agile Survey,“ 7. oktober 2016. [Elektronski]. Available:

http://stateofagile.versionone.com/?utm_campaign=soa&utm_source=blog&utm_m

edium=referral. [Poskus dostopa 5. avgust 2016].

[65] J. Highsmith in A. Cockburn, „Agile software development: the business of

innovation,“ Computer, Izv. 34(9), pp. 120-127, 2001.

[66] I. Zgonik, „Uvajanje standarda ISO 9001 v podjetje z agilnim razvojem programske

opreme,“ april 2011. [Elektronski]. Available: http://www.cek.ef.uni-

lj.si/u_diplome/zgonik4511.pdf. [Poskus dostopa 22. avgust 2016].

[67] C. Walters, „Toyota Way Principle #3: "Pull" Systems,“ 8. maj 2012. [Elektronski].

Available: http://leanblitzconsulting.com/2012/05/toyota-way-principle-3-pull-

systems/. [Poskus dostopa 14. avgust 2016].

[68] N. Sirina, „Sirina, Natalie's Answer to What are the most pressing challenges in Agile

Project Management?,“ 24. marec 2016. [Elektronski]. Available:

https://www.quora.com/What-are-the-most-pressing-challenges-in-Agile-Project-

Management. [Poskus dostopa 5. avgust 2016].

[69] C. Gilley, „Gilley, Cliff's Answer to Which Agile methodology (Scrum, Lean, XP,

Kanban) is considered the best practice and why?,“ 2. februar 2012. [Elektronski].

Available: https://www.quora.com/Which-Agile-methodology-Scrum-Lean-XP-

Kanban-is-considered-the-best-practice-and-why. [Poskus dostopa 5. avgust 2016].

64

[70] J. Sutherland, „Sutherland, Jeff's Answer to Which Agile methodology (Scrum, Lean,

XP, Kanban) is considered the best practice and why?,“ 3. januar 2012. [Elektronski].

Available: https://www.quora.com/Which-Agile-methodology-Scrum-Lean-XP-

Kanban-is-considered-the-best-practice-and-why. [Poskus dostopa 5. avgust 2016].

[71] A. Woody, „Woody, Arnold's Answer to Why do people choose Scrum over extreme

programming when both are frameworks of Agile?,“ 2. junij 2015. [Elektronski].

Available: https://www.quora.com/Why-do-people-choose-Scrum-over-extreme-

programming-when-both-are-frameworks-of-Agile. [Poskus dostopa 5. avgust 2016].

[72] K. Silva in C. Doss, „The Growth of an Agile Coach Community at a Fortune 200

Company,“ v Agile Conference (AGILE), Washington, DC, 2007.

[73] „Portfolio and Programme Management 2014 Global Survey,“ 2014. [Elektronski].

Available: http://www.pwc.com/gx/en/services/advisory/consulting/portfolio-

programme-management/global-ppm-survey-2014.html. [Poskus dostopa 4. avgust

2016].

[74] D. Tilk, „5 Steps to Agile Project Success,“ 13. april 2016. [Elektronski]. Available:

https://iaonline.theiia.org/2016/Pages/5-Steps-to-Agile-Project-Success.aspx.

[Poskus dostopa 4. avgust 2016].

[75] J. Jeremiah, „Survey: Is agile the new norm?,“ 25. maj 2015. [Elektronski]. Available:

http://techbeacon.com/survey-agile-new-norm. [Poskus dostopa 4. avgust 2016].

[76] T. J. Gandomani, H. Zulzalil, A. A. Abdul Ghani, A. B. Md. Sultan in K. Yatim Sharif,

„How human aspects impress Agile software development transition and adoption,“

International Journal of Software Engineering and Its Applications, Izv. 8(1), pp. 129-

148, 2014.

[77] J. Sutherland, „A Tale of Two Scrums: Agile done right and Agile gone wrong,“ 16.

januar 2014. [Elektronski]. Available: http://labs.openviewpartners.com/agile-done-

right-agile-gone-wrong/#.V6pRDTV4o7w. [Poskus dostopa 5. avgust 2016].

[78] A. MacCormack, R. Verganti in M. Iansiti, „Developing Products on 'Internet Time':

The Anatomy of a Flexible Development Process,“ Institute for Operations Research

and the Management Sciences Language, Izv. 47(1), pp. 133-150, 2001.

[79] A. Qumer in B. Henderson-Sellers, „An evaluation of the degree of agility in six agile

methods and its applicability for method engineering,“ Information And Software

Technology, Izv. 50(4), pp. 280-295, 2008.

65

[80] F. Mafakheri, F. Nasiri in M. Mousavi, „Project agility assessment: an integrated

decision analysis approach,“ Production Planning & Control, Izv. 19(6), pp. 567-576,

2008.

[81] J. Sheffield in J. Lemétayer, „Factors associated with the software development

agility of successful projects,“ International Journal Of Project Management, Izv.

31(3), pp. 459-472, 2013.

[82] K. Schwaber, Agile project management with Scrum, Redmond, Washington:

Microsoft Press, 2004.

[83] J. A. Highsmith, Agile project management: creating innovative products, Upper

Saddle River: Addison-Wesley, 2010.

[84] M. Cohn, Agile Estimating and Planning, New York, NY: Prentice Hall, 2005.

[85] E. C. Conforto, F. Salum, D. C. Amaral, S. L. da Silva in L. F. Magnanini de Almeida,

„Can Agile Project Management Be Adopted by Industries Other than Software

Development?,“ Project Management Journal, Izv. 45(3), pp. 21-34, 2014.

[86] J. K. Liker, The Toyota Way, McGraw-Hill, 2004.

[87] T. Owens, „Owens, Thomas's Answer to What, if any, is the difference between Lean

and Agile Software Development?,“ 7. januar 2016. [Elektronski]. Available:

https://www.quora.com/What-if-any-is-the-difference-between-Lean-and-Agile-

Software-Development. [Poskus dostopa 5. avgust 2016].

[88] M. Poppendieck in T. Poppendieck, Lean Software Development: An Agile Toolkit,

Addison-Wesley Professional, 2003.

[89] K. Waters, „Lean Principle #1 - Eliminate Waste,“ 23. avgust 2010. [Elektronski].

Available: http://www.allaboutagile.com/lean-principles-1-eliminate-waste/. [Poskus

dostopa 4. avgust 2016].

[90] J. Sutherland, „The First Scrum: Was it Scrum or Lean?,“ 10. avgust 2008.

[Elektronski]. Available: https://www.scruminc.com/is-it-scrum-or-lean/. [Poskus

dostopa 5. avgust 2016].

[91] A. Kelly, „Software Developers: prototype of future knowledge workers?,“ 9. april

2014. [Elektronski]. Available: https://dzone.com/articles/software-developers-

prototype. [Poskus dostopa 10. avgust 2016].

[92] S. L. McShane in M. A. Y. Von Glinow, Organizational Behavior: Emerging Realities

for the Workplace Revolution, McGraw-Hill, 2003.

66

[93] A. Nahavandi, The art and science of leadership (2nd ed.), Upper Saddle River, NJ:

Prentice Hall, 2000.

[94] S. P. Robbins, Organizational behavior: Concepts, controversies, and applications,

Upper Saddle River, NJ: Prentice Hall, 1996.

[95] B. Tuckman, „Tuckman forming storming norming performing model,“ 1965.

[Elektronski]. Available:

http://www.businessballs.com/tuckmanformingstormingnormingperforming.htm.

[Poskus dostopa 20. julij 2016].

[96] G. B. Alleman, „Forming, Storming, Norming, Performing and Adjourning,“ 2004.

[Elektronski]. Available:

http://www.niwotridge.com/PDFs/FormStormNormPerform.pdf. [Poskus dostopa 25.

julij 2016].

[97] P. Wallace, The Psychology of the Internet, UK: Cambidge University Press, 1999.

[98] M. J. Stevens in M. A. Campion, „The knowledge, skill, and ability requirements for

teamwork: Implications for human resource management,“ Journal of Management,

1994.

[99] J. Musek, „Dimenzije in meje osebnosti,“ [Elektronski]. Available:

http://musek.si/Teksti/Dimenzije%20in%20meje%20osebnosti.pdf. [Poskus dostopa

19. avgust 2016].

[100] R. R. McCrae in P. T. Costa, „Validation of the five-factor model of personality across

instruments and observers,“ Journal of personality and social psychology, Izv. 52(1),

pp. 81-90, 1987.

[101] A. B. Soomro, N. Salleh, E. Mendes, J. Grundy, G. Burch in A. Nordin, „The effect of

software engineers’ personality traits on team climate and performance: A

Systematic Literature Review,“ Information And Software Technology, Izv. 73, pp.

52-65, 2016.

[102] Z. Karimi, A. Baraani-Dastjerdi, N. Ghasem-Aghaee in S. Wagner, „Links between

the personalities, styles and performance in computer programming,“ The Journal Of

Systems & Software, Izv. 111, pp. 228-241, januar 2016.

[103] M. V. Kosti, R. Feldt in L. Angelis, „Personality, emotional intelligence and work

preferences in software engineering: An empirical study,“ Information And Software

Technology, Izv. 56, pp. 973-990, 2014.

67

[104] S. A. Licorish in S. G. MacDonell, „Communication and personality profiles of global

software developers,“ Information And Software Technology, Izv. 64, pp. 113-131,

2015.

[105] L. F. Capretz, D. Varona in A. Raza, „Influence of personality types in software tasks

choices,“ Computers In Human Behavior, Izv. 52, pp. 373-378, 2015.

[106] A. R. Gila, J. Jaafa, M. Omar in M. Z. Tunio, „Impact of personality and gender

diversity on software development teams' performance,“ International Conference

On Computer, Communications & Control Technology (I4CT), pp. 261-265, 2014.

[107] S. T. Acuña, M. N. Gómez, J. E. Hannay, N. Juristo in D. Pfahl, „Are team personality

and climate related to satisfaction and software quality? Aggregating results from a

twice replicated experiment,“ Information And Software Technology, Izv. 57, pp. 141-

156, januar 2015.

[108] D. J. Paulish in A. D. Carleton, „Case studies of software-process-improvement

measurement,“ Computer, Izv. 27(9), pp. 50-57, 1994.

[109] J. D. Benson, „Team Management,“ 2015. [Elektronski]. Available: Research

Starters: Business (Online Edition). [Poskus dostopa 5. avgust 2016].

[110] L. M. Maruping, V. Venkatesh in S. B. &. P. P. C. Thatcher, „Folding under pressure

or rising to the occasion? Percieved time pressure and the moderating role of team

temporal leadership,“ Academy Of Management Journal, Izv. 58(5), pp. 1313-1333,

2015.

[111] „empowerment,“ [Elektronski]. Available:

http://www.businessdictionary.com/definition/empowerment.html. [Poskus dostopa

19. avgust 2016].

[112] B. Tessem, „Individual empowerment of agile and non-agile software developers in

small teams,“ Information And Software Technology, Izv. 56(8), pp. 873-889, 2014.

[113] M. Drury, K. Conboy in K. Power, „Obstacles to decision making in Agile software

development teams,“ The Journal Of Systems & Software, Izv. 85(Special Issue:

Agile Development), pp. 1239-1254, 2012.

[114] D. J. Paulish in A. D. Carleton, „Case Studies of Software-process-improvement

Measurement,“ IEEE, Izv. 27(9), pp. 50-57, 1994.

[115] I. Somerville, Software Engineering, Izv. 7th Edition, Pearson Addison Wesley, 2004.

68

[116] J. S. Karn in A. J. Cowling, „A study of the effect of disruptions on the performance

of software engineering teams,“ International Symposium on Empirical Software

Engineering, pp. 1-36, 2005.

[117] F. Tang, „When communication quality is trustworthy? Transactive memory systems

and the mediating role of trust in software development teams,“ R&D Management,

Izv. 45(1), pp. 41-59, 2015.

[118] F. Bidault in T. Cummings, „Innovating through alliances: expectations and

limitations,“ R&D Management, Izv. 24, p. 33–45, 1994.

[119] G. Lee in W. Xia, „Toward Agile: An Integrated Analysis Of Quantitative And

Qualitative Field Data On Software Development Agility,“ MIS Quarterly, Izv. 34(1),

pp. 87-114, 2010.

[120] M. M. Soares, K. Jacobs, D. Sharan, P. Ajeesh, R. Rameshkumar in J. Jose, „Risk

factors, clinical features and outcome of treatment of work related musculoskeletal

disorders in on-site clinics among IT companies in India,“ Work, Izv. 41, pp. 5702-

5704, 2012.

[121] D. Sharan, P. Parijat, A. Sasidharan, R. Ranganathan, M. Mohandoss in J. Jose,

„Workstyle Risk Factors for Work Related Musculoskeletal Symptoms Among

Computer Professionals in India,“ Journal Of Occupational Rehabilitation, Izv. 21(4),

pp. 520-525, 2011.

[122] K. Suparna, A. K. Sharma in J. Khandekar, „Occupational health problems and role

of ergonomics in information technology professionals in national capital region,“

Indian Journal Of Occupational & Environmental Medicine, Izv. 9(3), pp. 111-114,

2005.

[123] S. Telles, M. Dash in K. Naveen, „Effect of yoga on musculoskeletal discomfort and

motor functions in professional computer users,“ Work, Izv. 34(2), pp. 297-306, 2009.

[124] H. Freudenberger, „Staff burnout,“ Journal of Social Issues, Izv. 30(1), p. 159–165,

1974.

[125] S. Kahill, „Symptoms of professional burnout: A review of the empirical evidence,“

Canadian Psychology, Izv. 29(3), p. 284–297, 1988.

[126] S. E. Jackson in C. Maslach, „After-effects of job-related stress: Families as victims,“

Journal of Occupational Behavior, Izv. 3(1), p. 63–77, 1982.

[127] C. L. Cordes in T. W. Dougherty, „A review and integration of research on job

burnout,“ Academy of Management Review, Izv. 18(4), p. 621–656, 1. oktober 1993.

69

[128] S. Madhura, P. Subramanya in P. Balaram, „Job satisfaction, job stress and

psychosomatic health problems in software professionals in India,“ Indian Journal Of

Occupational & Environmental Medicine, Izv. 18(3), pp. 153-161, 2014.

[129] P. R. Olsen, „For Writing Software, a Buddy System,“ 19. september 2009.

[Elektronski]. Available: http://www.nytimes.com/2009/09/20/jobs/20pre.html?_r=2.

[Poskus dostopa 4. avgust 2016].

[130] F. P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-

Wesley, 1975.

[131] F. Gobbo in M. Vaccari, „The Pomodoro Technique for Sustainable Pace in Extreme

Programming Teams,“ v Proceedings of XP2008, Limerick, 2008.

[132] „What is the Pomodoro Technique?,“ 2016. [Elektronski]. Available:

https://www.quora.com/What-is-the-Pomodoro-Technique. [Poskus dostopa 2.

avgust 2016].

[133] X. Wang, F. Gobbo in M. Lane, „Turning Time From Enemy Into An Ally Using The

Pomodoro Technique,“ arXiv, 2014.

[134] „Vplivi informacijskih tehnologij na posameznika - digitalni razkorak,“ [Elektronski].

Available:

http://eucbeniki.sio.si/admin/documents/learning_unit/3767/1503_20150424_Vplivi_

informacijskih_tehnologij_na_posameznika_1429864892/index3.html. [Poskus

dostopa 22. avgust 2016].

[135] J. Hempel, „Inside Facebook’s Ambitious Plan to Connect the Whole World,“ 19.

januar 2016. [Elektronski]. Available: http://www.wired.com/2016/01/facebook-

zuckerberg-internet-org/. [Poskus dostopa 22. avgust 2016].

[136] S. Murthy, „Women in Software Engineering: The Sobering Stats,“ 20. marec 2014.

[Elektronski]. Available: https://business.linkedin.com/talent-

solutions/blog/2014/03/women-in-engineering-the-sobering-stats. [Poskus dostopa

22. avgust 2016].

[137] C. W. Axelrod, Engineering Safe and Secure Software Systems, Boston: Artech

House, 2013.

[138] P. F. Drucker, The Age of Discontinuity: Guidelines to Our Changing Society,

London: Heinemann, 1969.

70

[139] B. L. Kirkman, K. B. Lowe in D. P. Young, High-Performance Work Organizations:

Definitions, Practices, and an Annotated Bibliography, Center for Creative

Leadership, 1999.

[140] T. H. Davenport, Thinking for a Living: How to Get Better Performances And Results

from Knowledge Workers, Boston : Harvard Business School, 2005.

[141] J. Glaser, „Management's role in IT project failures,“ Healthcare Financial

Management, Izv. 58(10), 2004.

[142] W. S. Humphrey, „Why Big Software Projects Fail: The 12 Key Questions,“ Journal

Of The Quality Assurance Institute, Izv. 19(4), pp. 30-35, 2005.

[143] B. Singh, B. Singh, A. Chandra in K. Al-Haddad, „Digital Implementation of an

Advanced Static VAR Compensator for Voltage Profile Improvement, Power Factor

Correction and Balancing of Unbalanced Reactive Loads,“ Electric Power Energy

Research, Izv. 54(2), pp. 101-111, 2000.

[144] „5th Annual State of Agile Survery,“ 2010. [Elektronski]. Available:

http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Result

s.pdf. [Poskus dostopa 3. avgust 2016].

[145] „Just in Time - JIT,“ [Elektronski]. Available:

http://www.investopedia.com/terms/j/jit.asp. [Poskus dostopa 22. avgust 2016].

[146] „Termania,“ [Elektronski]. Available: http://www.termania.net/slovarji/terminoloski-

slovar-vzgoje-in-izobrazevanja/3474374/kognitivni-konflikt. [Poskus dostopa 22.

avgust 2016].

[147] „What is a kanban card?,“ [Elektronski]. Available:

https://leankit.com/learn/kanban/kanban-card/. [Poskus dostopa 22. avgust 2016].

[148] „What is Kaizen?,“ [Elektronski]. Available: https://www.kaizen.com/about-

us/definition-of-kaizen.html. [Poskus dostopa 22. avgust 2016].

[149] „zanos,“ [Elektronski]. Available: http://www.termania.net/slovarji/slovar-

slovenskega-knjiznega-jezika/2937998/zanos?query=zanos&SearchIn=All. [Poskus

dostopa 22. avgust 2016].

[150] Z. Mladenovič, „Delegiranje,“ 27. junij 2008. [Elektronski]. Available:

http://www.poslovni-bazar.si/?mod=articles&article=966. [Poskus dostopa 22.

avgust 2016].

[151] P. Paganini, „Companies Worldwide Are Adopting Agile Development Techniques,“

1. april 2015. [Elektronski]. Available:

71

https://www.veracode.com/blog/2015/03/companies-worldwide-are-adopting-agile-

development-techniques-sw. [Poskus dostopa 6. avgust 2016].

[152] M. Rouse, „Total Quality Management (TQM),“ september 2005. [Elektronski].

Available: http://searchcio.techtarget.com/definition/Total-Quality-Management.

[Poskus dostopa 22. avgust 2016].

[153] J. Sutherland, „Sutherland, Jeff 's Answer to Who should scrum team members

report to,“ 16. januar 2013. [Elektronski]. Available: https://www.quora.com/Who-

should-scrum-team-members-report-to. [Poskus dostopa 5. avgust 2016].

[154] R. Wilcox, „Wilcox, Ryan's Answer to Which Agile methodology (Scrum, Lean, XP,

Kanban) is considered the best practice and why?,“ 21. februar 2012. [Elektronski].

Available: https://www.quora.com/Which-Agile-methodology-Scrum-Lean-XP-

Kanban-is-considered-the-best-practice-and-why. [Poskus dostopa 5. avgust 2016].

72

I Z J A V A O A V T O R S T V U

Spodaj podpisani/-a

z vpisno številko

sem avtor/-ica diplomskega dela z naslovom:

(naslov diplomskega dela)

S svojim podpisom zagotavljam, da:

sem diplomsko delo izdelal/-a samostojno pod mentorstvom (naziv, ime in priimek)

in somentorstvom (naziv, ime in priimek)

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 DKUM.

V Mariboru, dne

Podpis avtorja/-ice:

73

IZJAVA O USTREZNOSTI ZAKLJUČNEGA DELA

Podpisani mentor :

_____________________________________________

(ime in priimek mentorja)

in somentor (eden ali več, če obstajata):

_____________________________________________

(ime in priimek somentorja)

Izjavljam (-va), da je študent

Ime in priimek:_________________________________

Vpisna številka:________________________________

Na programu:__________________________________

izdelal zaključno delo z naslovom:

_______________________________________________________________________

(naslov zaključnega dela v slovenskem in angleškem jeziku)

_______________________________________________________________________

v skladu z odobreno temo zaključnega dela, Navodilih o pripravi zaključnih del in mojimi (najinimi oziroma našimi) navodili. Preveril (-a, -i) in pregledal (-a, -i) sem (sva, smo) poročilo o plagiatorstvu. Datum in kraj: Podpis mentorja: Datum in kraj: Podpis somentorja (če obstaja): Priloga: - Poročilo o preverjanju podobnosti z drugimi deli.

74

IZJAVA O ISTOVETNOSTI TISKANE IN ELEKTRONSKE VERZIJE ZAKLJUČNEGA

DELA IN OBJAVI OSEBNIH PODATKOV DIPLOMANTOV Ime in priimek avtorja-ice:

Vpisna številka:

Študijski program:

Naslov zaključnega dela:

Mentor:

Somentor:

Podpisani-a izjavljam, da sem za potrebe arhiviranja oddal elektronsko verzijo zaključnega dela v Digitalno knjižnico Univerze v Mariboru. Zaključno delo sem izdelal-a sam-a ob pomoči mentorja. V skladu s 1. odstavkom 21. člena Zakona o avtorskih in sorodnih pravicah dovoljujem, da se zgoraj navedeno zaključno delo objavi na portalu Digitalne knjižnice Univerze v Mariboru. Tiskana verzija zaključnega dela je istovetna z elektronsko verzijo elektronski verziji, ki sem jo oddal za objavo v Digitalno knjižnico Univerze v Mariboru.

Zaključno delo zaradi zagotavljanja konkurenčne prednosti, varstva industrijske lastnine ali tajnosti podatkov naročnika: ne sme biti javno dostopno do (datum odloga javne objave ne sme biti daljši kot 3 leta od zagovora dela).

Podpisani izjavljam, da dovoljujem objavo osebnih podatkov, vezanih na zaključek študija (ime, priimek, leto in kraj rojstva, datum zaključka študija, naslov zaključnega dela), na spletnih straneh in v publikacijah UM.

Datum in kraj: Podpis avtorja-ice

Podpis mentorja: (samo v primeru, če delo ne sme biti javno dostopno)

Podpis odgovorne osebe naročnika in žig: (samo v primeru, če delo ne sme biti javno dostopno)