FYI by CROZ - broj 16 (SLO)

Tema številke - scaling agile.

Transcript

1. SCALING AGILE ANDREA TOMASINI: ENTERPRISE TRANSITION FRAMEWORK AGILIZACIJA V PRAKSI tema številke Edini integracijski izdelek, ki ga potrebujete TEHNOLOŠKI RADAR SENTIMENTER tehnologije in trendi Razvojni cikel 2.0 Internet ali intranet? Uspešen projekt v Albaniji projektne zgodbe Jurij Bertok: Reorganizacija informacijskega sistema državne uprave Slovenije QED pogovor reportaže oktober 2014
2. MED TRENUTNIMI TEČcAJI IZDVAJAMO: TEČAJI PO MERI LEARN@CROZ kontaktirajte nas na learn@croz.net IBM BUSINESS PROCESS MANAGER (BPM) UVOD V AGILNI PRISTOP PRI RAZVOJU PROGRAMSKE OPREME RAZVOJ MOBILNIH APLIKACIJ (IOS IN ANDROID) SPRING FRAMEWORK RAZVOJ REŠITEV NA ALFRESCO ECM SVETOVANJE IN VODENJE TRENINGOV management 3 . 0 (jurgen appelo) essentials of IBM rational performance tester CERTIFIED SCRUM PRODUCT OWNER (AGILE42)
3. FYI by CROZ / oktober 2014 | 3 nadnaslov | rubrika FYI by CROZ | Revija za informatiko | Urednik: Goran Kelečić | Izdajatelj: CROZ d.o.o., Lastovska 23, 10000 Zagreb, Republika Hrvaška | Tel.: +385 1 6184 831 | Faks: +385 1 6184 833 E-pošta: fyi@croz.net | Internet: www.croz.net | Grafično oblikovanje: SBD Shift Brand Design, www.sbd.bas | Oblikovanje naslovnice: Jelena Radmanović | Tisk: Tiskara Grafing d.o.o., Zagreb fyi by croz | uvodnik Piše: Krešimir Mudrovčić Urednik: Goran Kelečić Uporaba agilnih metodologij je že nekaj let zelo priljubljena tema v informacijskih krogih. Z agilnimi metodologijami, natančneje s SCRUM-om, sem se prvič srečal pred nekaj leti, seveda na konferenci QED. Zvone Križ iz PBZ-ja je imel zanimivo predavanje in me je takoj okužil. Kmalu sem odkril, da je na CROZ-u že precejšnje število privržencev, ki potihem uporabljajo agilne metodologije. Nato sem prebral nekaj člankov, se pogovoril z ljudmi, ki so nekaj tega preizkusili tudi v praksi, in sklepal, da mi je bolj ali manj vse jasno. Zdaj vem, da mi je takrat bilo jasno bolj malo. Vendar, vrnimo se v sedanjost. Prava izziva sta uporaba agilnih metodologij zunaj posameznih razvojnih skupin in širjenje na ravni celotne organizacije. Zlasti širjenje zunaj programerskih skupin in vključevanje poslovnih sektorjev ter upravljanje portfelja izdelkov in/ali projektov. To so resnični izzivi, vendar tudi pravi poslovni dobički. Upamo, da vam bodo članki v tej številki naše revije pomagali pri premagovanju teh izzivov. Nekaj uporabnikov je poiskalo našo pomoč in svetovanje pri uvajanju agilnih metodologij v svojih organizacijah. Nekateri so bili na začetku, nekateri pa so potrebovali pomoč pri širjenju. Izvedli smo nekaj takšnih projektov, kar nas je spodbudilo, da bolj resno strukturiramo ponudbo svojih svetovalnih storitev. Kmalu smo ugotovili, da je minil čas klasičnih svetovalcev, ki pridejo v dragih oblekah, vklopijo ”taksimeter” in po več mesecih analiz, delavnic ter sestankov začno dostavljati lepo oblikovane in obsežne dokumente (ki jih nato malokdo prebere). Fantje in dekleta iz skupine Consulting@CROZ so se odločili izklopiti števec in biti konkretni ter v kratkem roku zagotoviti otipljive rezultate (namesto priporočil na papirju). V tej številki predstavljamo nekaj zelo zanimivih projektov; pri družbi Renault- Nissan smo implementirali svojo rešitev cDocs za podporo postopkom nabave, v Iskratelu smo pomagali pri uvajanju orodja IBM Rational, v Albaniji pa smo implementirali sistem za zavarovanje bančnih vlog. Torej eden svetovalni projekt, eden sistemsko-integracijski projekt in dve implementaciji naših izdelkov. CROZ je, kot vedno, težko spraviti v samo en predal. Seveda, obvezno preberite tehnološki radar!
4. rubrika | nadnaslov sadržaj | fyi by croz tema številke: Scaling agile Andrea Tomasini Enterprise Transition Framework Agilizacija v praksi tehnologije in trendi: Merjenje uspešnosti na družabnih omrežjih ali Ni vse v všečkih Edini integracijski izdelek, ki ga potrebujete Integracija platforme IBM Connections in grafnih zbirk podatkov Tehnološki radar projektne zgodbe: Internet ali intranet? Kaj je pomembnejše? Postopek nabave, hiter kot PUMA Razvojni cikel 2.0 CROZ na novem trgu: uspešen projekt v Albaniji pogovor: Jurij Bertok Reorganizacija informacijskega sistema državne uprave Slovenije reportaže: Nogometni turnir za ženske v IT-ju QED – pot proti učinkoviti informacijski tehnologiji 6 12 18 28 34 9 38 21 23 32 36 26 17 30
5. FYI by CROZ / oktober 2014 | 5 nadnaslov | rubrika fyi by croz | vijesti fyi by croz | novice Pomoć stradalima od poplava Tudi naša družba se je pridružila veliki akciji za pomoč prizadetim v poplavah. Naši zaposleni so prispevali z zbiranjem stvari, ki so trenutno nujno potrebne ljudem v poplavljenih območjih v Slavoniji. Zbrali smo dva kombija stvari in smo jih 23. maja dostavili neposredno prebivalcem Gunje. Poleg tega smo v imenu družbe na račun Rdečega križa donirali zajetnejši znesek za pomoč ljudem na poplavljenih območjih. Pomoč prizadetim v poplavah Agile Lean Europe 2014 je redna evropska konferenca, ki je avgusta potekala v Krakowu. Davor Čengija iz CROZ-a je na konferenci sodeloval kot predavatelj, kjer je predstavil način uporabe načel lean in agilne metodologije pri uvajanju Enterprise arhitekture. ”Prepoznaj vrednost (value), omogoči neoviran pretok te vrednosti skozi sistem (value flow), nato pa se loti odpravljanja viškov in izgub (waste elimination). To so osnovna načela upravljanja lean, ki jih lahko in ki jih morate uporabiti pri projektih uvajanja Enterprise arhitekture. CROZ na konferenci Agile Lean Europe 2014 v Krakowu Začelo se je sodelovanje družb CROZ in agile42 Družba CROZ je 15. oktobra podpisala pogodbo o sodelovanju z ugledno svetovno družbo agile42. Znotraj tega partnerstva se bo CROZ-ova skupina strokovnjakov udeležila izobraževalnega procesa, kjer bo spoznala način dela, ki ga uporabljajo pri družbi agile42. Tako bodo bogate izkušnje družbe agile42 neposredno na voljo tudi strankam v naši regiji, družba CROZ pa bo strankam lahko ponudila storitev implementacije in nadzora načel agilne metodologije na vseh ravneh in v vseh oddelkih v organizaciji. Družba CROZ je v družbi agile42 našla najboljšega partnerja na področju agilne metodologije, ki v svojih podružnicah v ZDA, Kanadi, Nemčiji, na Nizozemskem, Danskem, v Italiji, na Finskem in na Hrvaškem zaposluje certificirane strokovnjake ter izvaja projekte tranzicije različnih organizacij na agilni način delovanja. Od svoje ustanovitve leta 2007 je ta družba uspešno vodila postopke tranzicije v različnih družbah, kot so Siemens, Sony, Mitsubishi, Ericsson Nikola Tesla, Ableton in Chip, pa tudi v zagonskih družbah, kot so Babbel, Juwelo in eBuddy. V tej številki objavljamo pogovor z enim izmed ustanoviteljev družbe agile42, Andreom Tomasinijem. Dva nova paketa Consulting@CROZ Naša pridna skupina iz oddelka Consulting@CROZ je v ponudbo vključila dva nova svetovalna paketa. Paket Uvajanje načel metodologije lean pri upravljanju poslovnih potreb, projektnega portfelja in implementacije projektov zagotavlja preprostejše načrtovanje in boljšo predvidljivost pri izvedbi, ob boljši koordinaciji in manjšim številom neprijetnih presenečenj, na podlagi metodologije lean. Paket Uvajanje Enterprise arhitekture bo zagotovil stabilno in predvidljivo informacijsko infrastrukturo, ki bo zadovoljila inženirske kriterije kakovosti, hkrati pa tudi hitre in kakovostne odgovore na zahteve po razširitvah in novih storitvah. Več o teh paketih si lahko preberete na spletni strani www.croz.net/ consulting. S takšnim pristopom veliko hitreje dosežete kakovostno, trajnostno in skladno poslovno-tehnično arhitekturo, hkrati pa v sami organizaciji postavite temelje za neprekinjeno izboljšanje sistema.” Testing in agile software development U ponedeljek, 29. septembra 2014 je v Plaza Hotelu v Ljubljani potekal dogodek “Testing in agile software development”. Na dogodku je sodelovalo približno 30 udeležencev, ki so imeli priložnost spoznati agilne metodologije razvoja programske opreme in dobili odgovore na vprašanja, kateri izzivi nas čakajo pri testiranju programske opreme v prihodnje.
6. 6 | FYI by CROZ / oktober 2014 tema številke | Agile Piše: Mihael Sedmak Scaling agile Če razvijate programsko opremo, ste vsaj malo pod vplivom hitrorastočega vala agilne metodologije, ki se širi v industriji, če si to priznate ali ne. Agilna metodologija je ideja, pojem, filozofija, niz vrednosti in načel, in šele nazadnje praks, ki podpirajo vrednosti in načela; vse to je opisano na nešteto različnih načinov, povedano na konferencah, tudi na naši konferenci QED, ali na predstavitvah, ki so jih pripravili naši CROZ-ovci, pa tudi seveda v drugih virih. Številne organizacije odločno zakorakajo v svet agilnih metodologij, včasih tudi nekoliko naivno, saj je prvi korak pogosto navidezno lahek in zavajajoč, tako da se že po nekaj mesecih konča z vzklikom – ”Mi smo agilni!”. Vendar, ali je res tako preprosto? Nato se začno težave. Razumeti morate, da ta prvi korak – ki je najpogosteje razglasitev, da (vsaj) ena vaša skupina zdaj uporablja ogrodje Scrum, oziroma ima Scrum Masterja, Scrum Product Ownerja, se samoorganizira, imajo tablo, vzdržu- jejo vse standarde obreda Scrum (vendar daily stand-up ne traja 15 minut, ampak približno eno uro, seveda zato, ker se še uvajajo) – pravzaprav šele odpira vrata daljši poti proti drugačnem, bolj agilnemu načinu dela organizacije. Prav tako mo- rate razumeti, da prakse, ki ste jih začeli uvajati v skupini, njenim članom pravza- prav ne pomagajo, pač pa jim prinašajo dodatno delo k že tako tesnim rokom, ker pa vloge v skupini zdaj ”ne obstajajo”, so njeni člani zgubljeni in se sprašujejo kdo je za kaj odgovoren. Poleg tega pristopajo k obredom samodejno in brez razmi- šljanja o njihovi vsebini ter poskušajo v vsaki ponovitvi povečati neko navidezno številko, t.i. velocity, – ne da bi se vprašali, čemu služi in kaj je pravzaprav cilj. Če ste iskreni do sebe, se zdaj zavedate, da takšen pristop ni koristen, in se sprašujete kako se lotiti zadeve, da bi na koncu imeli želeno agilnost. Priprave za širjenje Scenarij, opisan v uvodu, ni redek, lahko bi celo rekli, da je značilen. V številnih člankih, napisanih v angleščini, boste prebrali ”We are doing agile”. Da, uporabljamo prakse, vendar Agile Manifesto ne govori o praksah, pač pa o vrednotah in načelih. Tako je pri vsaki implementaciji, na primer Scruma, kot najbolj prepoznavnega predstavnika gibanja agile, treba začeti pri vrednotah in načelih, šele nato pa, da bi vrednote in načela zaživeli, uporabiti prakse, ki jih predpisuje Scrum. Poved ”We are agile” predpostavlja korenito spremenjeno organizacijo, ki v svojih temeljih ima vgrajene vrednote in načela, ki jih opisuje Agile Manifesto. Transformacija v takšno organizacijo je dolgotrajna, vsebuje številne različne poteke aktivnosti in iniciativ, ki morajo zajeti vse dele organizacije. Vzemite to kot širjenje kulture agilnosti v organizaciji. Trdno sem prepričan, da je kultura organizacije, ki vsebuje vrednote in načela, močnejša in vplivnejša od predpisanih postopkov, ki jih sestavljajo prakse, ter da na njej mora temeljiti osnovna (ena skupina, del organizacije) kot tudi razširjena, celovita agilnost (na ravni celotne organizacije). En Scrum, dva Scruma, trije … Vrnimo se na scenarij iz uvoda. Jasno je, da širjenja agilnosti ne bomo dosegli tako, da se odločimo za preprosto kopiranje tega scenarija na naslednjo skupino, nato na naslednjo itd. Tako bomo ustvarili niz skupin, ki implementirajo agilne prakse in jih mučijo iste dileme kot prvo
7. FYI by CROZ / oktober 2014 | 7 Agile | tema številke Large Scale Scrum, okvir za širjenje agilnih praks skupino. Na srečo so v industriji zaznali takšne situacije, zato so ustvarili nekaj različnih pristopov k kakovostnejšemu širjenju agilnih praks v celotni organizaciji. Kot smo že poudarili, širjenje praks pred ugotavljanjem vrednot in načel ni idealna situacija, vendar je bolj preprosto in poceni, zato se organizacije pogosto odločajo za enega izmed priznanih okvirjev za takšno širjenje. Omenili bomo dva priljubljena okvirja za upravljanje, pri katerih se agilne prakse skalirajo na veliko širšo raven od ene skupine. To sta okvirja, ki ju podpirajo Dean Leffingwell (www.scaledagileframework. com), oziroma Craig Larman (www. craiglarman.com) in Bas Vodde (www. odd-e.com). Oba okvirja sta kakovostna, sta dobro dokumentirana (na voljo so tudi kakovostne knjige), iz njiju se je mogoče veliko naučiti, lahko pa ju tudi kombinirate. Ne bomo se spuščali v podrobnosti teh okvirjev, ker pa ideje iz obeh okvirjev uporabljamo pri delu in menimo, da sta kakovostna, priporočamo, da preberete kaj več na spletnih straneh avtorjev in se oglasite na Lastovski 23 na klepet. Širjenje načel in vredot S širjenjem praks smo torej dosegli manjši del vrednosti širjenja agilne metodologije. Preostal nam je težji del: širjenje vrednot in načel. Takšno širjenje lahko dosežemo samo organsko, skozi vse dele organizaci- je. Da bi to dosegli, je pogosto treba trans- formirati organizacijo ali najti način, kako v enem majhnem segmentu organizacije posejati prave vrednote, začeti kakovo- stne pogovore (npr. stalne pogovore o zaostankih, prioritetah, vrednosti, ki jo do- stavite uporabniku, vizualizaciji postopka, ki ga uporabljate in nenehnem izboljšanju tega postopka, razumevanju, da je nujno nenehno napredovati, ne pa priti do določene točke absolutne agilnosti), nato pa to stanje razširiti na druge segmente organizacije. To širjenje je mogoče doseči na več načinov. V družbi CROZ smo lani izvedli poskus. Ustanovili smo majhno skupino (manj kot deset oseb), pri kateri se znanje dopolnjuje, tako da kot celota lahko rešijo tudi najzahtevnejše naloge na svojem osrednjem področju (v tem primeru sistem za upravljanje dokumentov Alfresco), pa tudi na drugih sorodnih področjih. Imajo poslovno in tehnično znanje, so samoorganizirani, v kontekstu svojega dela pa imajo pravico in obveznost poiskati najboljši način za doseganje najboljših rezultatov. To lahko pomeni tudi, da nimajo dnevnih 15-minutnih sestankov: v njihovem kontekstu niso potrebni, saj je praksa brez namena odvečna, vse, kar je odveč, pa obremenjuje skupino in postopek. Skupina je imela tudi zunanje svetovalce, osebe, ki so lahko pomagale pri procesnih, tehničnih in projektnih zadevah, ves čas so bili na voljo, vendar samo kot pomoč pri usmerjanju, na noben način pa niso določali način dela v skupini. Skupina je vzporedno reševala naloge pri več projektih, in četudi je to lahko kontraproduktivno, prednosti samoorganizacije in razpoložljivosti vseh potrebnih znanj v isti skupini so močno presegale to pomanjkljivost. Vsekakor je za takšen poskus morala obstajati ena velika predpostavka – da uprava družbe CROZ ima zaupanje v takšno skupino, svetovalce skupine in vizijo, da je prihodnost v takšnem načinu dela.
8. 8 | FYI by CROZ / oktober 2014 Enterprise Transition Framework Iz delavnice družbe agile42, je kot rezultat njihovih izkušenj pri delu z velikimi svetovnimi organizacijami na projektih agilnih transformacij prišel transformacijski okvir Enterprise Transition Framework (ETF). V tej številki revije FYI lahko preberete intervju z Andreom Tomasinijem, enim izmed ustanoviteljev družbe agile42, v katerem boste izvedeli več o samem ETF-u, enem izmed redkih pristopov k celovitem prehodu organizacije na agilni način dela; osredotoča se na širjenje agilnih vrednot in načel skozi celotno organizacijo s posebnim poudarkom na podporo vodilnim strukturam v organizaciji in njihovo izobraževanje. Širjenje agilnih vrednot skozi organizacijo – primer družbe Spotify Guild Guild Chapter Chapter Chapter Chapter Squad Squad Squad Squad Squad Ker je poskus s časom (ne tako kratkim, šlo je za več mesecev) začel kazati želene rezultate (kakovostne pogovore, nenehen napredek pri delu, itd.), je prišel čas, da te dobre vrednote in načela pokusimo prenesti naprej. Ustanovili smo naslednjo, tematsko popolnoma drugačno skupino, vendar z istimi vrednotami in enako razvezanimi rokami. Rezultati so bili: drugačen postopek dela, drugačna vizualizacija, nekaj različnih prilagoditev do točke, v kateri je skupina danes in, kar je najpomembnejše, veliko medsebojnega izmenjevanja zamisli med skupinama, da bi lahko naprej napredovali. Za nas je širjenje agilnosti pomenilo natanko to – skupini sta neodvisni, vendar med seboj izmenjujeta zamisli. Dva uspešna poskusa sta spodbudila načrtovanje novih skupin, ki bi delovale po podobnem modelu. Skozi te ”nove” skupine CROZ neguje tudi t.i. prakse, neformalne skupine za širjenje tehničnih in poslovnih znanj. Verjamemo, da bomo s kombiniranjem takšnih širjenj idej in znanj iz tedna v teden imeli kakovostnejše rezultate in izdelke ter bolj zadovoljne uporabnike. Seveda smo ideje črpali iz primerov, ki so bili na voljo, meni osebno pa je bil najbolj zanimiv primer družbe Spotify, internetne družbe, ki se ukvarja s posredovanjem glasbe. Povsem avtonomne skupine (imenovane Squads) in večje celote, plemena (Tribes), ki so sestavljene iz teh skupin, delajo na skupni temi in razširjajo ideje, povezane s to temo. O načinu dela, praksah in orodjih odloča izključno skupina, te pa se lahko poljubno pogosto spreminjajo, če skupina meni, da je primerno, in da se tako izboljša način dela. Cilj večje celote – dostava funkcionalnosti znotraj teme – je skupen, in vse skupine delajo zanj. Znotraj plemena se organizirajo svojevrstne skupnosti (Chapters), katerih namen je širjenje konkretnega znanja, tehnologije ali metodologije znotraj plemena. Za namen širjenja vrednot in načel (pa tudi praks) čez meje plemena, skozi celotno organizacijo, so ustanovljeni cehi (Guilds). Kot ”pravi” obrtniški cehi, so tudi ti združenja ljudi s podobnimi znanji in interesi, na primer ceh razvojnih inženirjev za ogrodje Rails, ceh spletnih oblikovalcev itd. Ključ širjenja agilnosti v družbi Spotify so cehi v kombinaciji z notranjimi izobraževalci, katerih naloga je izključno pomagati pri širjenju agilnih vrednot in načel v organizaciji. S takšnim modelom je družba Spotify uspešno zrasla iz majhnega startupa v globalno podjetje. Skupnosti v plemenih in cehi se še vedno pogosto sestajajo in izmenjujejo zamisli, iščejo nove načine dela kljub veliki rasti, ker je zanje to kultura organizacije, ki se edino tako lahko pravilno ohrani. Tak pristop lahko izkoristimo tudi v okvirjih domačega tržišča, če prepoznamo in uporabimo osnovne zamisli, seveda ob prilagoditvi svoji organizaciji. Glavne zamisli so širjenje vrednot, načel in znanj skozi neformalne skupine znotraj organizacije, avtonomnost skupin in popolna transparentnost vsega, kar se izvaja v organizaciji skozi največjo mogočo vizualizacijo posla in informacij. Agilnost je večplastna sprememba Skozi izkušnje pri delu z uporabniki vseh velikosti, naše osebne sedanje in prihodnje izkušnje, ter sodelovanje z drugimi družbami, izkušenimi pri agilnih pretvorbah in skaliranju, kot je agile42, smo ugotovili, da se agilnost organizacije zagotovo kaže skozi širjenje predvsem agilnih vrednot in načel, in šele nato praks. Čeprav so vse tri komponente pomembne, verjamem, da smo na dveh majhnih primerih pokazali, da so prakse samo majhen del celotne zgodbe. Prav tako agilnost ni samo domena IT-oddelka v organizaciji, ampak celotne organizacije kot celote, in včasih terja globoke organizacijske spremembe. Za širjenje agilnosti potrebujete čas in moč, da bi agilnost v resnici nehala biti zgolj točka v razvoju, k kateri težite, in postala način funkcioniranja organizacije, ki vključuje nenehno napredovanje, visoko raven avtonomije skupin in posameznikov, koncentriranje na uporabniške vrednosti, visokokakovostne izdelke in neprekinjeno sodelovanje z vsemi, ki so vključeni v postopek pretvorbe uporabniške vrednosti v programsko opremo. Pri izgradnji agilne organizacije obstajajo številne pasti, postavljajo se številna vprašanja, ob vseh razpoložljivih informacijah (že omenjeni transformacijski okvirji, knjige, članki) pa je včasih težko prepoznati odgovore in prave poti – verjamemo, da strokovnjaki iz družbe CROZ lahko pomagajo, da skupaj pripravimo najboljši pristop za agilno transformacijo in skaliranje v vaši organizaciji. tema številke | Agile
9. FYI by CROZ / oktober 2014 | 9 Enterprise Transition Framework Pogovarjal se je: Krešimir Musa Kaj je pravzaprav ETF? ETF (Enterprise Transition Framework) je v bistvu tri stvari: 1. strukturirani pristop k organizacijski spremembi, ki podpira agilne vrednote in načela, na katere se osredotočamo med kulturološko tranzicijo; 2. časovni vodnik s specifično oblikovanimi trenutki refleksije in sprejemanja odločitev; 3. velika zbirka orodij, praks in modulov izobraževanja za pospeševanje sprejemanja novih pristopov ter podpiranje dolgotrajne in rastoče agilne kulture znotraj organizacije. Povej nam nekaj o zgodovini ETF-a. Kako si prišel do tega koncepta? To je zelo dolga zgodba, omenil bom samo nekatere ključne točke evolucije. Vse se je začelo leta 2006, ko smo se lotili agilne transformacije velikega podjetja in zelo hitro ugotovili, da so orodja, ki so bila na voljo znotraj skupnosti agile, zelo slabo podpirala cikel izboljšanja agilnega procesa zunaj konteksta skupine. Skaliranje na več skupin je bilo zahtevno, čeprav so nekatere metode porodile zamisli, kako se premakniti v to smer. Videti je bilo, da se večina dostopnih tiskanih in elektronskih gradiv osredotoča predvsem na skaliranje modelov dostav, manj pa na agilen način razmišljanja. Obstajali so tudi številni poskusi skaliranja retrospektiv na velike organizacije: nekateri so bili sorazmerno uspešni, vendar še vedno nismo imeli občutka, da za dejansko organizacijsko stalno izboljšanje moramo uporabiti bolj strukturiran in manj reaktiven pristop. To ne pomeni, da smo želeli standarden pristop. Nasprotno, zelo smo se trudili poiskati sistem, v katerem bi lahko ponovili rezultate. Pri delu s strankami smo zbirali načela, orodja in prakse, ki so kazali določeno vrednost pri tranziciji v smeri agilne kulture. Ta zbirka je bila tako velika, da smo jo morali nekako strukturirati. Takrat smo začeli premišljevati o organizacijskih razsežnostih (npr. viziji in strategiji, strukturi in organizaciji, ljudeh in veščinah, izdelkih in storitvah, tehnologiji) kot bolj preprostemu načinu organizacije naših orodij. Na tej poti smo se veliko naučili – naučili smo se, da je raven vgrajene kompleksnosti v organizacija pogosto visoka, tudi takrat, ko ni zaželena. Število medsebojnih odvisnosti med oddelki, skupinami in lokacijami je bilo posebej nepredvidljiv dejavnik. Šele pozneje smo spoznali, kako veliko vlogo imajo te odvisnosti pri spremembi. Poglobili smo se v zgodovino agilne metodologije ter povezanih orodij, in z nekaj dodatnega raziskovanja ustvarili Priljubljenost agilnih metod razvoja programske opreme se je povsod po svetu, pa tudi v naši regiji, v zadnjih nekaj letih močno povečala. O tem smo veliko pisali tudi v naši reviji (v tej številki je to celo osrednja tema), saj je velik del našega vsakdanjega strokovnega življenja tesno povezan s tem področjem. Želja, ali bolje povedano, potreba po premiku proti agilnim metodam razvoja programske opreme, je pripeljala do resne vključitve in zanimanja celotnega IT-trga. S to temo se vedno bolj ukvarjajo tudi pogoni razvoja programske opreme v naši regiji: od startupa, prek družb, kot je naša (ki se ukvarja z razvojem programske opreme po potrebah naročnikov, pa tudi s svetovanjem na tem področju), do velikih IT-organiza- cij, ki dostavljajo programske rešitve internim poslovnim upo- rabnikom. Torej, očitno je, da želja po premiku proti agiln(ejš)im metodam razvoja programske opreme ni vprašljiva. Vendar je izvedba tega premika težja naloga. Kako organizirati in načrto- vati prehod proti agilnemu načinu dela? Kateri so predpogoji za uspeh tega prehoda? Koliko časa lahko traja prehod in kakšne težave lahko pričakujemo pri njegovi izvedbi? Številne organiza- cije na trgu se pri prehodu na agilni način dela srečujejo s temi vprašanji. Pri nekaterih tranzicijskih projektih na Hrvaškem in v širši regiji je sodelovala tudi naša svetovalna skupina. Na primer, sodelovali smo s specializirano svetovalno družbo agile42, ki ima obsežne izkušnje prav pri projektih organizacijske trans- formacije velikih IT-sistemov v smeri implementacije agilnih metod razvoja programske opreme. Glede na to, da je svetovni svetovalni trg trenutno nasičen s številnimi samostojnimi sve- tovalci in svetovalnimi družbami, ki se ukvarjajo s projekti agilne transformacije, oziroma tranzicije v smeri agilnih metod razvoja programske opreme, je v tej množici težko razbrati kakovost in izkušnje. Sodelovanje in partnerstvo z družbo agile42 smo vzpostavili prav zato, ker smo v njihovem pristopu prepoznali trajnost kot ključen dejavnik uspeha agilne transformacije, pa tudi zaradi obsežnih izkušenj pri realizaciji transformacijskih projektov. Agile42, globalna svetovalna družba s sedežem v Berlinu in podružnicami po vsem svetu, je osredotočena predvsem na svetovanje na področju uporabe agilnih metod razvoja in organizacije ter implementacije t.i. projektov agilne transformacije. V nadaljevanju bo Andrea Tomasini, eden izmed ustanoviteljev družbe agile42, predstavil njihov Enterprise Transition Framework (ETF), ki predstavlja pristop k organizaciji in implementaciji projektov agilne transformacije, s posebnim poudarkom na doseganje trajnosti transformiranega sistema. To pomeni, da bi realizacija transformacije skladno s koncepti ET- F-a morala organizaciji zagotoviti kakovostno delovanje sistema tudi po tem, ko svetovalna skupina konča svoje delo. Agile | tema številke
10. 10 | FYI by CROZ / oktober 2014 Andrea Tomasini Andrea je eden izmed ustanoviteljev družbe agile42. Že več kot dvajset let dela v industriji programske opreme na področjih razvoja programske opreme, upravljanja proizvodov in optimizacije procesov. Pri implementaciji načela agile je pomagal številnim družbam v različnih sektorjih. Zelo dejaven je v skupnosti agile na svetovni ravni, ob svetovalnem delu pa nenehno prispeva k razvoju novih in izboljšanju obstoječih tehnik izobraževanja na področju agilnosti, coachinga in implementacije. Je eden izmed redkih svetovnih strokovnjakov, ki so pridobili certifikata Certified Scrum Coach (CSC) in Certified Scrum Trainer (CST). Veliko delamo na tem, da ETF postane javno dostopno ogrodje, in da mrežo razširimo z drugimi organizacijami ter partnerji, ki lahko razširijo vpliv ETF-a na širšo skupnost. Interno ga uporabljamo nekaj let, pomagal pa nam je veliko bolje skalirati zelo distribuirano organizacijo, kot smo to sprva pričakovali. strukturo, ki smo jo objavili sorazmerno nedavno. Ko smo ugotovili, da to, kar imamo, več kot zadostuje za pomoč drugim organizacijam, smo se odločili to objaviti in skladno z vizijo družbe agile42, želimo, da bo ta proizvod razpoložljiv celotni skupnosti ter da pomaga čim več organizacijam pri poti do agilnosti. Kateri so najpomembnejši teorijski koncepti, na katerih ste zasnovali ETF? Začeli smo z osnovami teorije omejitev (Theory of Constraints) in teorije vrst (Queuing Theory), v to pa smo vključili zelo pragmatičen pristop, ki temelji na empirični metodi. Uporabili smo tudi veliko zamisli iz konceptov Cynefin Framework in System Thinking. Seveda, poskusili smo čim bolj vključiti tudi metodologije lean. Kako primerjaš ETF z drugimi ogrodji za tranzicijo in skaliranje ter pristopi na trgu? Kanban Method, SAFe in drugimi...? Kanban je metoda, ki smo jo integrirali v ETF-ovo zbirko orodij, ker jo vidimo kot zelo splošno metodologijo za upravljanje sprememb, ki temelji na poteku. Večina drugih metod, ki so na voljo na trgu, v bistvu zagotavlja samo model dostave programske opreme. Glede na naše izkušnje ta model ni kritičen pri doseganju dejanske agilnosti. Ravno nasprotno, pogosto smo videli, kako organizacije sprejemajo orodja in prakse, vendar ne razumejo in ne sprejemajo ustreznih načel. Z ETF-om smo dosegli to, da se osredotočimo na agilnost celotne organizacije ob nenehnem presojanju svoje strukture, vlog in opredelitev, hkrati pa smo se lahko osredotočili na vrednote. Tisto, zaradi česar so agilne skupine učinkovite, je samoorganizacija, zato smo poskusili poiskati način za nenehno in sistemsko samoorganizacijo podjetja. Eden izmed najbolj podcenjenih dejavnikov pri sprejemanju načela agilnosti je uporaba agilnega pristopa pri postopku spremembe, ki bi preprečil konflikte in omogočil, da vrednote in načela, zaradi katerih je agile uspešen sistem, zaživeli od samega začetka. Človeški dejavnik in naravna evolucija nastajanja novih stvari v metodologiji agilnega razvoja sta najpomembnejša dejavnika uspeha. Čeprav razumemo potrebo velikih družb po ”standardizaciji” kot načinu nadzora različnih delov organizacije in merjenja učinkovitosti, se zelo dobro zavedamo, da je bistvo agilne metodologije v nastajanju novih praks in eksperimentiranju, ki vodita v izboljšave in večjo učinkovitost. V ETF smo vgradili tudi te evolucijske prakse in element kolektivnega učenja skozi eksperimentiranje. Kakšen je značilen projekt ETF? Kateri so najpomembnejši dejavniki in predpogoji za uspeh? Kot lahko vidite na naši spletni strani (www.agile42.com/etf), moramo začeti s prvotno oceno in analizo organizacije, da bi razumeli začetni položaj in vrsto kulture znotraj organizacije. Glede na to, da kultura dobesedno požre procese, se želimo prepričati, da bo način, na katerega bomo uvedli agilna načela in vrednote, kulturo podprl, in da ne bo v konfliktu z njo. Ocena je strukturirana in je zgolj del ETF-a, da bi družba lahko pozneje sama sledila svojemu napredku v rednih intervalih. Rezultat začetne ocene je niz kratkoročnih, srednjeročnih in dolgoročnih predlogov za izboljšave. Analiza ponavadi traja dva ali tri dni, nato pa organizacija potrebuje nekaj tednov za analizo rezultatov in odločitve o naslednjih korakih. Po oceni ustvarimo strategijo tranzicije z orodjem Agile Strategy Map (TM), njen rezultat pa v dvodnevni delavnici združimo s poslovnimi cilji in strategijo družbe. Tako poskušamo poudariti, da biti agilen ni cilj sam po sebi, pač pa boljši način za doseganje ciljev, zato pa potrebujemo podporo vodstva organizacije. Cilj delavnice je skozi ustvarjanje strategije identificirati najugodnejšo priložnost za implementacijo agilnih metod – tisto, s katero lahko pokažemo učinkovitost z merljivimi poslovnimi rezultati. Ko prepoznamo priložnost, začnemo pilotski projekt in pomagamo organizaciji pri izobraževanju vključenih ljudi, usposabljanju na njihovih delovnih mestih, ter ponudimo podporo v težavnih trenutkih sprememb. Obenem gradimo tudi notranji sistem usposabljanja, za katerega menimo, da je ključni dejavnik za dolgotrajno agilnost. Podporo običajno zagotavljamo dva ali tri dni v tednu, nikoli ves delovni čas, da bi zagotovili okolje, v katerem se lahko pojavljajo napake, in v katerem zaposleni prevzamejo odgovornost za nov način dela, pa tudi da bi sorazmerno hitro lahko vplivali na proces in utrdili naučeno. Med trajanjem pilotskega projekta pomagamo tranzicijski skupini pri rasti in prevzemanju odgovornosti za tema številke | Agile
11. FYI by CROZ / oktober 2014 | 11 Enterprise Transition Framework™ Copyright 2007-2014, agile42 www.agile42.com The Enterprise Transition Framework™ for Continuous and Sustainable Improvement Leadership Team defines the Strategy Great Guideline: Agile Strategy Map Define the Pilot Project(s) Determine the Success and Failure Criteria Make Roll Out Decision Align with Strategy Map Implement the Change Analyse the four Organizational Dimensions Get the Big Picture Involve Teams Analyse and Understand the Business Status Quo Roll Out without Risk ASSES SMENT STR ATEGY PILOT PHASE Pilot Projects in a Safe-to-Fail Environment What can make Where are we now? What do we need to change? Is this working for us? This is working for us! Agile = Continuous Improvement Shematični prikaz Enterprise Transition Frameworka Imamo resnično veliko knjižnico praks in orodij, glavni izziv pa je stisniti bistvo, da bi drugim olajšali delo. Izziv je tudi ločiti lokalne izkušnje in posplošiti pristop, vendar smo v tem vedno boljši. Prav tako neprekinjeno pripravljamo retrospektive. spremembe in ”mazanju” starih zobnikov družbe, ki ustvarjajo trenje. Na koncu pilotskega projekta organizacija ima priložnost ovrednotiti začetne hipoteze in oceniti vpliv sprememb skozi vse dogodke. Tranzicijska skupina bo podelila izkušnje z drugimi deli organizacije in podprla postopno uvajanje. Na ta način vse, kar se je naučil majhen del organizacije, postane uporabno za celoto. Tako lahko pospešimo naravni ritem učenja in dosežemo največje izboljšanje v kratkem časovnem obdobju. Organizacija nato ponavlja ta cikel: opredeli pilotske projekte, postavlja merila uspeha in neuspeha, izvaja pilotske projekte, opredeli kdaj in kako podpreti uvedbo, tudi pri zelo majhnih projektih in objavlja pogoste izdaje. Ni to agilnost? Na tem potovanju sta izjemno pomembni podpora in volja vodstva družbe za sprejemanje agilnih načel. Med implementacijo obstaja potreba po ustvarjanju skupnega jezika in razumevanju načina, na katerega bo kultura organizacije podprla spremembe, zaradi česar je včasih treba eksperimentirati v začetnih fazah implementacije. Ali lahko sam implementiram ETF? Videti je preprosto. A Da, večinoma je preprosto, vendar potrebujemo trdno disciplino. Najtežje je razumeti, kakšen vpliv bo imela strukturna ali organizacijska sprememba na obnašanje znotraj organizacije, za kar potrebujemo veliko izkušenj in znanj o kompleksnih sistemih ter človeškem vedenju. Veliko delamo na tem, da ETF postane javno dostopno ogrodje, in da mrežo razširimo z drugimi organizacijami ter partnerji, ki lahko razširijo vpliv ETF-a na širšo skupnost. Interno ga uporabljamo nekaj let, pomagal pa nam je veliko bolje skalirati zelo distribuirano organizacijo, kot smo to sprva pričakovali. Se lahko spomniš kakšne referenčne implementacije? Na naših spletnih straneh imamo veliko referenc in projektnih zgodb, od majhnih startupov do velikih mednarodnih družb. Na konferenci Agile2012 sem skupaj s podpredsednikom oddelka predstavil Portfolio Management and Technology PDU Mobile Core & IMS Ericsson, to gradivo pa je, skupaj z videoposnetkom predavanja, na voljo na naših spletnih straneh in na spletnih straneh organizacije Agile Alliance. Kako se ETF razvija? Povej nam kaj o svojem ciklu izboljšav. A ETF se predvsem razvija skozi uporabo. A Vsaka nova stranka, ki vstopi v agilno tranzicijo, prejme najnovejša orodja in prakse ter prispeva k njihovem dvigu na višjo raven. Znotraj družbe imam skupine, ki z dokumentiranjem novih izkušenj neprekinjeno izboljšujejo ogrodje. Redno se sestajamo, vsaka dva meseca pripravimo evropski agile42 coach camp, ki traja dva do tri dni, na katerem delamo neposredno z vsemi evropskimi usposobljevalci, vsakih 6 mesecev pa organiziramo tudi mednarodni agile42 coach camp, na katerega pripeljemo tudi družino, in ki se razširi na ves konec tedna. Na teh dogodkih delimo izkušnje z različnimi strankami in poskušamo poiskati ključne elemente uspeha ter jih integrirati v ETF. Imamo resnično veliko knjižnico praks in orodij, glavni izziv pa je stisniti bistvo, da bi drugim olajšali delo. Izziv je tudi ločiti lokalne izkušnje in posplošiti pristop, vendar smo v tem vedno boljši. Prav tako neprekinjeno pripravljamo retrospektive. Še naprej spremljajte ETF in v naslednjih mesecih boste opazili številne spremembe, saj objavljamo vedno več uporabnih gradiv. Agile | tema številke
12. 12 | FYI by CROZ / oktober 2014 Vsi so nori na agilizacijo! Dobro, če ne ravno nori nanjo, so vsaj slišali nekaj o tej metodologiji in govorijo o tem, da je to najboljši način razvoja, ne samo programske opreme, da so rezultati odlični in da so pospešitve dostav neverjetne. Ta tema je priljubljena tudi pri nas. Ne nazadnje smo velik del zadnje številke tega tovarniškega časopisa posvetili prav agilni transformaciji, Scrumu in s tem povezanimi celotam. Za razliko od velikega dela našega okolja, ki o agilnih metodologijah samo govori (na žalost, moram poudariti), se v družbi CROZ aktivno ukvarjamo s širjenjem teh znanj in praks pri uporabnikih in tudi interno. Mogoče je začeti od znotraj Razvojni projekti lahko zaradi različnih razlogov gredo narobe. Najpogosteje gre za izgube zaradi preveč optimističnih ocen ali premalo jasnih zahtev, nekateri projekti pa kljub tem znanim težavam še naprej rinejo v prepad. To se lahko Agilizacija v praksi Tri kratke zgodbe v nadaljevanju govorijo o tem, kako na prvi pogled različna okolja ob uporabi podobnih načel rešujejo specifične, vendar vsem znane težave. Piše: Davor Čengija Projektna nadzorna plošča na platformi IBM Jazz zagotavlja hiter pregled stanja projekta iz več perspektiv, med trajanjem projekta pa se lahko spreminja in prilagaja Povzetek internega druženja na temo reševanja ogroženega projekta – dejanska ilustracija je posneta v moji kuhinji A zgodi vsakomur, tudi nam, vendar tisto, po čem se razlikujemo od večine drugih programskih hiš, je sposobnost prepoznavanja in, kar je še pomembnejše, reagiranja v takšnih situacijah. Nedavno smo našemu izkušenemu vodji projektov (podatki so na voljo v redakciji, op. a.) zaupali nehvaležno dolžnost reševanja ogroženega projekta pri dolgoletnemu uporabniku. Vse, kar gre lahko narobe na projektu, je že zašlo v to smer: niz nerešenih zahtev, tisto, kar se dela, močno zamuja, roki za dostavo so zapadli, preveč porabljenih dni glede na ocene, nezadovoljni ljudje na projektu.. Kako razrešiti težavo in rešiti projekt, spraviti uporabnika v dobro voljo in vrniti dober sloves? Naš sodelavec je že izkušen projektni volk, ki ve, kako ukrepati v takšnih težavah: nadaljevati z dosedanjim pristopom, vendar hitreje in bolj udarno ne bo spremenilo ničesar, samo bo povečalo primanjkljaj na projektu in dodatno razburilo uporabnika. Torej, sprememba drže. Ne samo sprememba drže, pač pa tudi sprememba organizacije projektne skupine, sprememba načina komuniciranja z uporabnikom, sprememba pri ocenjevanju, sprememba pri poročanju – v bistvu agilizacija projekta in uvedba Scruma. Na začetku je treba rešiti najpomembnejše, v našem primeru je to zamajano zaupanje uporabnika. Zakaj? Ker nenehno zamujamo in ne upoštevamo rokov. Zakaj? Ker nove zahteve prihajajo sproti, ali niso jasno opredeljene že na začetku, zato so tudi ocene datumov dostave zelo približne. To vsekakor ni dobro, niti za uporabnika, ker ima interne obveznosti do trženja in prodaje, niti za nas, ker ne moremo načrtovati človeških virov ali denarnih tokov. Takoj je treba razjasniti dejstvo, ki je držalo pri čisto vseh naših projektih, pri katerih sem sodeloval, upam si pa trditi, da velja tudi na splošno: uporabniki so zelo razumni ljudje, ki razumejo, da se stvari spreminjajo; tako se spreminjajo tudi poslovne zahteve, tema številke | Agile
13. FYI by CROZ / oktober 2014 | 13 Consulting@CROZ AGILE KICKSTART Skozi izkušnje pri delu s številnimi strankami iz različnih industrij (finance, telekomunikacije, elektronika, državna uprava) in z namenom pretvorbe svojih oddelkov za razvoj v agilnejše strukture smo razvili Agile Kickstart – ponudbo za vsa podjetja in organizacije, ki želijo skozi intenzivno delo s strokovnjaki iz skupine Consulting@CROZ postaviti trdne temelje za celovito transformacijo na agilnejši način dela, da bi izboljšali položaj na trgu, se lažje odzivali na zahteve naročnikov in se hitreje prilagodili vedno bolj dinamičnem informacijskem okolju, ki nas obdaja. V 20 dneh intenzivnega dela boste spoznali trenutne prakse, ki jih uporabljate, ugotovili stanje trenutne agilnosti v svoji organizaciji, bolj razumeli agilna načela in vrednote ter prejeli predlog uporabe naučenega za eno vašo razvojno skupino. Dodatne informacije na naslovu www.croz.net/consulting Platforma IBM Jazz: Burndown chart se ustvari samodejno, prikazuje pa razmerje med preostalim delom in razpoložljivim časom do konca projekta Vse, kar potrebujemo, je dovolj zgodaj prepoznati spremembo in razložiti njen vpliv na dinamiko projekta, to pa ni nič drugega kot izboljšati komunikacijo znotraj celotne skupine, od lastnika poslovnih zahtev, prek vodij projektov na obeh straneh, do same razvojne skupine. mehanizmi implementacije in okolje. Vse, kar potrebujemo, je dovolj zgodaj prepoznati spremembo in razložiti njen vpliv na dinamiko projekta, to pa ni nič drugega kot izboljšati komunikacijo znotraj celotne skupine, od lastnika poslovnih zahtev, prek vodij projektov na obeh straneh, do same razvojne skupine. Kako izboljšati komunikacijo? Nič lažjega, rekli bi: srečujte se pogosteje, vsak dan, če treba, pa četudi samo za 15 minut, da obdelate tisto, kar ste delali včeraj, ugotovite, ali so se pojavile nenadne težave, in kaj načrtujete postoriti danes – torej daily scrum meeting. Tu so se zadeve začele razpletati. Orodje IBM Rational Team Concert je omogočilo boljšo vidljivost nalog – odprtih, napovedanih, v testiranju, zaprtih; prav tako je omogočilo merjenje hitrosti, s katero skupina dostavlja končane kose programske opreme, ter s tem tudi boljše načrtovanje. Omogočilo je tudi jasen prikaz dopolnitev poslovnih zahtev v obliki skoka na grafu, ki prikazuje količino dela. Iz tega in iz dinamike razvojne skupine je vedno razvidno, kdaj bo delo končano – ni več slabe volje zaradi dvotedenske zamude pri dostavi, dodan pa je samo eden novi zaslon. Celotna skupina, vključno z lastniki poslovnih zahtev, se odloči, kaj je pomembnejše: dostava v predhodno določenem roku, ali dodatna funkcionalnost, vendar malo pozneje. Ali morda dodatna funkcionalnost namesto neke druge, vendar v predhodno dogovorjenem roku? Takšne podrobnosti se rešujejo takoj na začetku, ko se težava pojavi, ne pa na koncu, pri testiranju pred sprejetjem. Tako se tudi gradi zaupanje uporabnika. Osredotočite se na bistveno! Finančna agencija (FINA), naš dolgoletni uporabnik, s katerim zelo uspešno poslujemo na nekaj različnih področjih, od sistemskega vzdrževanja, prek razvoja programske opreme, do svetovanja, ima tudi pomembno interno razvojno skupino, ki je zmožna dostaviti zapletene projekte v različnih tehnologijah. Tudi metodološko so precej podkovani, vendar se ob razvoju industrije informacijske tehnologije tudi na tem področju kažejo pozitivni premiki, kar so prepoznali v FINA-i in nas prosili za pomoč. Ugotovili smo, da je za FINA-o ustrezen CROZ-ov svetovalni izdelek, ki ga imenujemo Agile Kickstart – skupina Agile | tema številke
14. 14 | FYI by CROZ / oktober 2014 Projektno nadzorno ploščo za lastnika izdelka je mogoče konfigurirati glede na specifične potrebe, tako da so ključne informacije vedno pri roki: katere so potekajoče aktivnosti, kje je potrebna intervencija, pregled po iteracijah… Učimo se osredotočati to, kar je bistveno, da bi v omejenem času storili tisto, kar bo imelo največjo uporabno vrednost in bi se vloženo čim prej povrnilo. Osmoza kot mehanizem širjenja agilizacije V srednji šoli smo vsi slišali za osmozo: polprepustna membrana, dve raztopini, ena raztopljena snov prehaja skozi membrano, druga ne, in tako dalje. Zelo zanimivo je, kako lahko podoben pojav, vendar brez raztopljenih snovi A, vidimo v skoraj vseh okoljih, v katerih začenjamo uvajati agilne metodologije (razvoj programske opreme, tržne akcije, oblikovanje, revizije za standard ISO...). Ena skupina v podjetju uvede na primer dnevna 15-minutna druženja vsako jutro. Ta druženja so seveda samo del celotne spremembe, vendar so za opazovalce zunaj skupine najbolj opazna aktivnost. Ko mine prvi val nezaupanja (samo izgubljajo čas) in ko se pokažejo kakovostni in zanesljivi rezultati, se člani drugih skupin začnejo nepovabljeni (!) pojavljati na dnevnih druženjih, že zato, da vidijo, za kaj gre. Novica o čarobnih druženjih se zelo hitro razširi tudi zunaj skupine Scrum in kmalu imamo srečanja stand-up v celotni organizaciji. Takšni dogodki in širjenje informacij so zelo dobre novice, vendar tisto, kar je ostalo prikrito - torej ni prestopilo skozi membrano - je strukturirana zgodba, ki je skrita za dnevnimi druženji: zakaj se sestajamo vsak dan, kaj se dogaja pred in za tem, zakaj se vedemo ravno tako. Lahko bi rekli, da pol dela pri sprejemanju agilnih metodologij razvoja opravi osmoza, vendar mora biti druga polovica jasna in strukturirana, da bi se ljudje naučili zakaj se nekaj počne prav na ta način, ne pa zgolj, kako se nekaj dela. nekaj tečajev, svetovanje, spremljanje in nadzor konkretne skupine na konkretnem projektu, da bi se veščine agilnega upravljanja projektov vgradile v samo osrčje organizacije in da bi se na koncu lahko širile naprej. Darko Špoljarić, član naše svetovalne skupine, je lepo povzel izkušnje: ”Učimo se osredotočati na to, kar je bistveno, da bi v omejenem času storili tisto, kar bo imelo največjo uporabno vrednost in bi se vloženo čim prej povrnilo.” Kaj pomeni, da je skupina osredotočena na bistveno? Darko nadaljuje: ”Najprej smo morali znova opredeliti skupino, oziroma vanjo vključiti vse osebe, ki sodelujejo pri razvoju izdelka – ne samo programske opreme, ne samo specifikacij, pač pa tudi celotnega izdelka, ki je sestavljen iz teh komponent. Šele, ko smo sprejeli dejstvo, da programska oprema brez dobrih specifikacij ni vredna prav veliko in da specifikacije niso same sebi namen, smo lahko začeli načrtovati zaporedje aktivnosti, tako da čim prej začnemo dostavljati vrednost končnemu uporabniku.” V pogovoru z Dariom Belićem iz FINA-e smo izvedeli, da so prvi vtisi odlični, vendar ne samo vtisi, tudi številke: že po prvem ciklu uvajanja agilnih metodologij smo lahko opazili pospešitev pri dostavljanju funkcionalnosti od 30% do 50% glede na tradicionalni pristop, kar pa je najpomembnejše, dostavljene so bile prav tiste funkcionalnosti, ki so morale biti, ker smo med izvajanjem projekta sklenili, da so pomembne, oziroma pomembnejše od drugih, zato so se znašle na vrhu seznama za razvoj. Ne nazadnje hitrost dostave ni tako zelo pomembna, če upoštevamo dejanski učinek takšne spremembe v pristopu. Vsak razumen sponzor projekta (takšni pa so vsi) bo sprejel tistih 20% funkcionalnosti, ki pokrivajo 80% potreb uporabnika, in s tem končal projekt, namesto da bi vztrajal pri 100-odstotnem peglanju vseh zahtev, vedoč, da te možnosti nikoli ne bodo uporabljene. Kaj pa, če razvijamo vdelano pro- gramsko opremo? V tej številki pišemo o uspešni implementaciji aplikacij Rational Requirements Composer in Rational Quality Manager v Iskratelu, slovenski družbi, ki deluje na mednarodnem trgu, in izdeluje precej kompleksne telekomunikacijske naprave ter programsko opremo. Tretji del tega projekta je vključeval uvajanje agilnih metodologij in orodij, predvsem Scruma, v razvojni cikel. Ta celota je zastavljena in izpeljana skladno z navodili, oziramo natanko po priporočilih: po tečaju o podrobnostih agilnega razvoja, posebnostih takšnega pristopa s stališča organizacije skupin, načina komuniciranja med razvojem in prednostnega vrstnega reda dela, smo izbrali pilotski tema številke | Agile
15. FYI by CROZ / oktober 2014 | 15 Vse pomembne informacije, prikazane na enem mestu, olajšajo spremljanje stanja projekta: odprte naloge, kritična pot, obremenjenost razvojne skupine in drugo Iskratel namreč razvija tudi vdelano programsko opremo, tj. programsko opremo, ki je ozko povezana s pripadajočo strojno opremo, na kateri bo delovala. projekt. Dobro izbran pilotski projekt je včasih ključen za uspeh celotnega podviga: naloga mora biti realna in izvedljiva, poleg tega pa mora biti tudi dovolj reprezentančna, oziroma mora predstavljati običajen projekt, podoben tistim, ki se tudi sicer implementirajo v tem okolju. Skratka, ne sme biti trivialna. Posebnost Iskratela v primerjavi z družbo CROZ je v vrsti programske opreme, ki jo razvijajo. Iskratel namreč razvija tudi vdelano programsko opremo, tj. programsko opremo, ki je ozko povezana s pripadajočo strojno opremo, na kateri bo delovala. V krogih, ki ne poznajo agilnih metod razvoja, pogosto menijo, da je vdelano programsko opremo zelo težko, skoraj nemogoče razvijati tako, da se na koncu vsakega sprinta dostavi tudi delujoča različica, zlasti pa, da na ta način ni mogoče razvijati strojne opreme. Ne prva, ne druga trditev nista resnični, kar dokazuje ta projekt. Kot pri vseh agilnih iniciativah smo začeli s tečaji, na katerih so vsi, ki so vključeni v projekt, spoznavali načela agilnega razvoja, s tem, da je skupina iz Iskratela že imela dobro osnovno znanje. Samo svetovanje in spremljanje razvojne skupine je imelo eno zanimivo značilnost. Razvoj namreč poteka v Mariboru, kakšnih 120 km stran od Zagreba. Vsakodnevno potovanje v Maribor in nazaj ni prišlo v poštev, tam bivati 6 tednov, kolikor smo načrtovali za pilotski projekt, pa še manj. Dobili smo se na pol poti: začetno načrtovanje (backlog grooming), načrtovanje sprintov (iteracija) in retrospektive bomo opravili skupaj, v Mariboru, dnevne stand-upe pa bomo izvajali prek Skypea. Ivan Krnić, naš glavni svetovalec na projektu, misli, da je tak pristop povsem sprejemljiv. ”Pomembno je da smo bili ves čas backlog groominga in načrtovanja sprintov skupaj, na lokaciji. Tako smo lahko bolj neposredno spreminjali vedenje sodelujočih pri projektu in jih usmerjali v pravo smer, kar je nazadnje cilj našega dela - naučiti uporabnika, kako lahko samostojno vodi projekte na agilni način. Pomagali so tudi tečaji pred začetkom pilotskega projekta, na katerih smo se bolje spoznali. Skype je za dnevna druženja povsem v redu: čeprav nismo bili fizično skupaj, smo uspeli ostati osredotočeni na tekoče naloge znotraj sprinta.” Janez Krušič iz Iskratela, product owner v času pilotskega projekta tudi hvali tak pristop. ”Zagon projekta, oziroma zbiranje vseh potrebnih informacij za začetek implementacije, je bistveno skrajšano. Včasih smo potrebovali tudi dva tedna za oceno velikosti projekta in določitev vrstnega reda implementacije. Preden vsi preberejo elektronsko pošto in odgovorijo, preden se vse zbere na enem mestu... Tokrat smo vse to naredili v enem dnevu. Zbrali smo se za backlog grooming in smo ostali, dokler nismo razjasnili, kaj, kako in kdaj je treba storiti. To je seveda bilo samo začetno druženje, nismo določili prav vseh podrobnosti, vendar smo implementacijo lahko začeli že naslednji dan.” Agile | tema številke
16. 16 | FYI by CROZ / oktober 2014 Za razliko od tradicionalnega pristopa, kjer na začetku običajno izvajamo obsežne analize obstoječega stanja poslovne, organizacijske in tehnične strukture, tukaj lahko takoj na začetku ustvarimo sliko idealnega, skoraj utopičnega sveta, v katerem se poslovne potrebe in tehnične zmožnosti brezhibno ujemajo, vse pa je začinjeno s popolnoma organiziranim Uradom za Enterprise arhitekturo. Agilni pristop tudi v Enterprise arhitekturi Dnevna druženja so ob opazni pospešitvi na začetku omogočila tudi ohranjanje usmeritve na poslovno vrednost, ki bo rezultat dostave projekta. Z drugimi besedami, vgradili smo mehanizem za spreminjanje prednostnih nalog pri implementaciji želenih funkcionalnosti. Razumljivo in zaželeno je, da se lastniki poslovnih zahtev v času trajanja projekta premislijo glede nekaterih zahtev; pomembno je, da te spremembe pravočasno opazimo in takoj vgradimo v projektni načrt. Lastnik izdelka se odloči, ali bo to vplivalo na čas implementacije, ali pa bomo manj pomembne podrobnosti izločili. V vsakem primeru se bomo izognili neugodnim presenečenjem na koncu. Še ena podrobnost iz tega projekta mi je bila všeč: uporaba fizične table, obešene v projektni sobi za načrtovanje in spremljanje napredka pri projektu. Res je, različna programska oprema za Kanban in podobne vizualizacije so odlična zadeva – kadar vemo, kaj delamo. Ko začenjate nov projekt, vzemite dvometrsko belo tablo in kup samolepilnih listkov ter začnite. Tako bodo vsi člani skupine imeli nekaj, okrog česar bodo stali med dnevnimi druženji, drugi sodelavci pa bodo videli pisani zid in jih bo zanimalo, kaj se dogaja. Osmoza pa je, kot piše v stranskem okvirju, močna sila. nterprise arhitektura je pogosta tema v reviji FYI. Do sedaj smo izvedli že več projektov na to temo, zato je naravno, da je vsak naslednji projekt malo boljši od prejšnjega, prav agilni pristop in metodologija lean pa sta omogočila bistven napredek pri razumevanju uporabnikovih potreb ter s tem tudi kakovostnejše rezultate. Osnovna postavka takšnega pristopa, ki ga uporabljamo v družbi CROZ, je iskanje idealnega stanja v prihodnosti. Nočem trditi, da je analiza obstoječega stanja nepotrebna, pač pa da je ni treba izvajati zgolj zato, da bi bila sama sebi namen. Pri realizaciji idealnega stanja bomo prepoznali kdaj in koliko se moramo ozreti nazaj in v pravi meri izdelati oceno točno tega dela. Kako doseči idealno stanje za neko okolje? Tu v igro vstopijo načela lean in agile, pri katerih je ključna podrobnost prepoznavanje vrednosti, ki jo sistem dostavlja. Na primer, katero vrednost dostavlja sistem okenc v banki: možnost, da uslužbenci na okencih zelo hitro vnašajo različne podatke, možnost, da občanom hitro in preprosto odobrijo kredit, ali možnost takojšnjega pregleda različnih podatkov, pomembnih za upravo? Odgovora sta seveda drugi in tretji. Ko prepoznamo vrednosti, ki jih je lahko zelo veliko, se trudimo omogočiti nemoten pretok teh vrednosti skozi sistem. Poslovne procese oblikujemo tako, da se vrednost, ki smo jo prepoznali, najhitreje ustvari. Pri tem se pogosto srečujemo z različnimi težavami, od interne organizacijske strukture – različni interni oddelki kar naenkrat sodelujejo pri istem procesu, vse so povsem tehničnih težav – več kopij istih podatkov je razmetanih vsepovsod po sistemu in nihče ne ve, katera različica je izvirnik, katere so kopije in tako dalje. Takšne oteževalne okoliščine imamo za izgube ali odpadke (izraz, ki ga najpogosteje uporabljamo je waste) in jih poskušamo v čim večji meri odstraniti. Idealno stanje je tisto, kar v Enterprise arhitekturi imenujemo stanje TO-BE, pri tem se pa zavedamo, da ga ne glede na to, koliko se trudimo, ne bomo mogli doseči, vsaj ne v prvem ciklu izgradnje arhitekture. Takšen pristop je vendar povsem sprejemljiv: Enterprise arhitektura je pot in ne cilj, kot to pesniško rečemo, načela lean in agile pa nam pomagajo, da se na tej poti srečujemo s čim manj težavami. Naslednji korak pri takšnem pristopu k izgradnji Enterprise arhitekture je fizično oblikovanje izbranega segmenta sistema, ko se spustimo v resnični svet, kjer že upoštevamo organizacijske, regulativne, tehnične in časovne omejitve. Na primer, v idealnem svetu si predstavljamo samo eno skupno zbirko podatkov za celoten sistem, v resnici pa imamo pomembno aplikacijo, ki deluje prav s to različico zbirke DB2 in je ne moremo preseliti vsaj še dve leti. Takšne omejitve so breme na idealni strukturi, kompenziramo pa jih skozi načrtovanje in dobro projektno organizacijo. Prednost Enterprise arhitekture lean je v zelo hitrem povračilu truda, vloženega v razvoj sistema, oziroma prepoznavanje vrednosti. Z omogočanjem širjenja vrednosti prek obstoječih meja dobimo novi, boljši in bolj uporaben sistem, ki deluje natanko tako, kot želimo. tema številke | Agile
17. Organizirali smo še eno srečanje žensk v informacijski industriji, ki so se, v nasprotju z uveljav- ljenim moškim mnenjem, da se soočajo samo z ogledalom, tokrat soočile v nogometu in pustile moške odprtih ust s svojo predanostjo, borbenostjo ter resnostjo v pristopu k turnirju, čeprav se je na koncu pokazal pravi pomen turnirja: zabava, druženje ter dobrodelna akcija za Centar za vzgojo in izobraževanje ”Goljak”, kar je tekmovanju dalo še lepšo Nogometni turnir za ženske v IT-ju razsežnost, in pokazalo, da stopimo skupaj, kadar je najbolj treba. Sam turnir, ki je že skoraj tradicionalen, je presegel vsa pričakovanja. Letos se je zbralo več kot 12 ekip, natančneje 13. Na koncu se je izkazalo, da je 13 srečna številka za ta turnir, ki pred našimi očmi raste iz lokalnega navdušenja v zelo resen dogodek, ob tradicionalnem pridihu zabave, ki jo je uprizorilo približno dvesto deklet. Čestitamo predvsem vsem udeleženkam turnirja, zlasti zmagovalkam – ekipi IN2, zahvaljujemo pa se tudi navijačem, ki so se odzvali v velikem številu, in prispevali k športnem ter zabavnem vzdušju. Vidimo se tudi naslednje leto, najmanj v istem številu, z upanjem, da bomo v prihajajočih letih videli vedno več ekip in navijačev, kar nam bo zagotovo povzročilo sladke skrbi pri organizaciji turnirja še večjih razsežnosti! Piše: Tomislav Majdančić Nogometni turnir za ženske v IT-ju | reportaže FYI by CROZ / oktober 2014 | 17
18. 18 | FYI by CROZ / oktober 2014 tehnologije in trendi | SentiMenter Viri podatkov SentiMenter je platforma, ki vsebuje integrirane storitve za dostop do podatkov z družabnih omrežij, kot so Facebook, Twitter, YouTube in najbolj priljubljenih forumov ter drugih virov. Orodje je source- in content- agnostic, kar v prevodu pomeni, da kot vir lahko nastavite tudi nek drug sistem, bodisi relacijsko zbirko podatkov, sistem upravljanja dokumentov, skladišče elektronske pošte, ki je naslovljena npr. na oddelek za podporo uporabnikom, ali kaj drugega. Piše: Luka Stepinac Merjenje uspešnosti na družabnih omrežjih ali Ni vse v všečkih Spoznajte SentiMenter – CROZ-ovo sodobno platformo za analizo družabnih omrežij, ki razume hrvaško. Kaj mislite, je podjetje uspešnejše od konkurence, če na svojem profilu na Facebooku ima več všečkov? Ali oboževalcev? Klikov? Je morda uspešnejše, če ima večje število sledilcev (followerjev) na Twitterju? Danes dostopna orodja za analizo družabnih omrežij omogočajo ocenjevanje števila novih strank ali uporabnikov. Kako je to povezano z uspešnostjo podjetja? Na primer: število ogledov na Facebooku lahko pomeni povečano vidljivost neke znamke, število klikov ali število oboževalcev pa lahko odraža zanimanje za nek izdelek. Če vsi ti elementi kažejo rast, lahko sklepamo, da smo verjetno na pravi poti do uspeha na trgu. Danes vodje trženja in odnosov z javnostmi najpogosteje uporabljajo neko kombinacijo omenjenih meritev. V tem načelno ni nič slabega. Vendar je dejstvo, da te meritve ne zadostujejo, ker samo delno kažejo angažiranost in povezave podjetja s spletno skupnostjo/kupci/ strankami. Tisto, kar je pomembno, je kakovost te povezave. To je tisto, na kar bi se vsi morali osredotočiti. Ko rečemo kakovost, mislimo moč povezave, ta pa zajema vsebino komunikacije in doseg ter pomen vsakega posameznega komentarja na kateremkoli družabnem omrežju ali internetnem forumu. Kateri uporabniki najpogosteje pišejo negativne komentarje? Zakaj? Ali lahko pravočasno prepoznamo vzroke in zmanjšano morebitno škodo? Pri katerih temah je število komentarjev, negativnih ali pozitivnih, veliko? Kje in kako se piše o naši blagovni znamki? Kaj dela konkurenca – o čem se piše na njihovih spletnih kanalih? Ko rečemo kakovost, mislimo moč povezave, ta pa zajema vsebino komunikacije in doseg ter pomen vsakega posameznega komentarja na kateremkoli družabnem omrežju ali internetnem forumu.
19. FYI by CROZ / oktober 2014 | 19 SentiMenter | tehnologije in trendi Začetna stran uporabniškega vmesnika aplikacije SentiMenter. Vmesnik je razdeljen na t.i. plošče, ki jih uporabnik lahko razporedi po lastni izbiri. Lahko spreminjate položaje plošč, vrste grafov, izbirate meritve, ki jih želite spremljati, in vnašate kriterije za iskanje ali filtriranje podatkov. Vmesnik je interaktiven, elementi so pa lahko kontekstno povezani, kar pomeni, da se ob izbiri katerega koli elementa na plošči (časovnega obdobja, rezine torte) lahko samodejno prilagodijo vse ostale plošče, tako da prikazujejo samo tiste vsebine, ki predstavljajo izbrano podmnožico podatkov. Na primer, če izberete modro rezino (tweet) na srednji spodnji plošči, se bo palični graf prilagodil, tako da bo prikazoval skupno komunikacijo v času, ki je potekala na Twitterju; prav tako bodo ažurirane meritve na vrhu strani in vsi ostali grafi, kot na primer distribucija sentimenta (razpoloženja), ki bo tokrat povezana samo s tweeti. PRILAGODLJIVA NADZORNA PLOŠČA Orodje omogoča izvrsten pregled nad informacijami, ki so pomembne za vaše podjetje, izdelek ali kampanjo. Izberite podrobne prikaze, vključno z raznimi vrstami grafov, preglednic in drugih oblik prikaza informacij. S preprostim klikom dostopite do podrobnejšega prikaza (pogled v globino) in odgovorite na vprašanje ”zakaj?”. UPRAVLJANJE KAMPANJ V REALNEM ČASU Ne čakajte na konec svoje spletne kampanje, da bi videli rezultate. Spremljajte kampanjo od samega začetka, da vidite njen vpliv in jo po potrebi sproti spreminjajte, da izboljšate rezultat! NAPREDNA ANALIZA SENTIMENTA Odkrijte ton pomembnih pogovorov – v hrvaščini in sorodnih jezikih – in spremljajte vpliv svoje družabne strategije skozi čas. Kaj govorijo o vas? Je to, kar govorijo negativno, pozitivno ali nevtralno? Vstopite globlje v področja s povečano aktivnostjo v izbranem Glavne funkcionalnosti aplikacije SentiMenter časovnem obdobju in preverite, kaj ljudje mislijo o vaših kampanjah, izdelkih ali storitvah. GEOGRAFSKI IN DEMOGRAFSKI PODATKI Ugotovite podrobnosti o uporabnikih, ki sodelujejo v pomembnih pogovorih, kot so lokacija, starost, spol in poklic. KONKURENČNI PRIMERJALNI TESTI Primerjajte doseg in vpliv vaše blagovne znamke v primerjavi s konkurenco. Spremljajte te kazalnike med trajanjem spletnih kampanj. ANALIZA BESEDILA, TRENDI IN TEME Prepoznajte teme, ki spodbujajo najpomembnejše razprave, in ugotovite, kako vplivajo na vaše podjetje, blagovno znamko ali izdelek. Naš inteligenten Google-like iskalnik vam omogoča dostop do vseh pomembnih informacij s preprostim vnosom ali kombinacijo naprednih kriterijev iskanja. Consulting@CROZ Testing team blueprint Dodatne informacije na naslovu www.croz.net/consulting Prepričani smo, da testiranje ni zgolj preverjanje dejstva, ali sistem vsebuje želene funkcionalnosti. Testna skupina strokovnjakov za testiranje funkcij, regresijsko testiranje, testiranje učinkovitosti, integracijsko testiranje in druge oblike testiranj lahko bistveno izboljša kakovost končnega izdelka, vendar je takšen pristop pogosto predrag in neučinkovit v dejanskem okolju. Strokovnjaki skupine Consulting@CROZ vam lahko pomagajo, da skozi niz delavnic spoznate najboljše prakse, ki jih uporabljajo učinkovite testne skupine, in oblikujete lastno strategijo testiranja, prilagojeno vrsti programske opreme, ki jo razvijate v svoji organizaciji, pa tudi orodjem in metodologijam, ki jih uporabljate. S skupnim delom bomo izgradili tudi nekaj načinov za ohranjanje svežine in dolgoročne uporabnosti nove testne strategije.
20. 20 | FYI by CROZ / oktober 2014 Kako obdelate besedilo v aplikaciji SentiMenter? Primer uporabniškega vmesnika aplikacije SentiMenter s prikazom najaktivnejših virov (npr. strani na Facebooku, računov na Twitterju ipd.), najaktivnejših uporabnikov (mogoče je razlikovati skrbnike od ”pravih” uporabnikov) in besedil. S klikom na ikono lupe je mogoče globlje analizirati izbrano postavko; npr. če izberete uporabnika, se v spodnji plošči prikažejo samo njegova besedila. Vsako ploščo je mogoče dodatno prilagoditi, tako da prikazuje dodatne atribute in jih razvrsti po želenih kriterijih. Družabne mreže tehnologije in trendi | SentiMenter Ali je aktivnost na katerem izmed njih večja? Ali vidimo priložnost za reakcijo v primeru konkurenčne kampanje z negativnimi komentarji? Kaj delamo dobro? To so vprašanja, na katera moramo poiskati odgovore. Če mislite, da je merjenje kakovosti komunikacije nemogoča misija, pomislite znova – ustvarili smo rešitev prav za to. V CROZ-u smo razvili SentiMenter – platformo za spremljanje in analizo družabnih omrežij v realnem času, ki zbira pomembno spletno komunikacijo in zagotavlja hitrejše odgovore na zgornja vprašanja. Dodatne podrobnosti o SentiMenteru, brošura in demonstracija so na voljo na naši spletni strani www.croz.net/sentimenter. Zagotovo vas zanima, kako lahko merimo razpoloženje s pregledom družabnih omrežij. Tukaj je primer. Začnimo z besedilom komentarja, ki smo ga prejeli z družabnega omrežja: ”kolko puta vam moram reci, Mamić je najbolji menader u eu. ajmoooooooooo :)” Glede na to, da je platforma orientirana regionalno, moramo pri vsakem besedilu najprej preveriti, ali je napisano v latinici ali cirilici; če je napisano v cirilici, ga moramo prečrkovati. Nato ugotovimo, ali je besedilo v hrvaščini ali enem izmed sorodnih regionalnih jezikov, kajti aplikacija ne obdela besedil v tujih jezikih (dopušča nekatere tuje besede :). To besedilo je prepoznala kot hrvaško. Besedilo naprej razdelimo na povedi, nato pa na posamezne besede in oznake. Spremenimo znake ali tipografske izraze, ki lahko označujejo razpoloženje v posebne žetone, ki se ne obdelujejo, npr. smeškote spremenimo v niz <HAPPY>. kolko | puta | vam | moram | reci || <COMMA> | Mamić | je | najbolji | menader | u | eu | <END> || ajmoooooooooo || <HAPPY> Popravimo besede, ki so napisane narobe ali nestandardno, ali pa jim manjkajo diakritični znaki (kolko → koliko), (menader → menadžer). Kratice spremenimo v polno besedilo (eu → europska unija). koliko | puta | vam | moram | reći || <COMMA> | Mamić | je | najbolji | menadžer | u | europska | unija | <END> || ajmoooooooooo || <HAPPY> Normaliziramo besede v povedi v njihovo osnovno obliko. koliko | puta | ti | morati | reći || <COMMA> | Mamić | biti | dobar | menadžer | u | europska | unija | <END> || ajmoooooooooo || <HAPPY> Zavržemo besede brez pomena. Dodamo kopije besed, ki so zelo poudarjene, in jih reduciramo na običajno obliko. morati | reći || <COMMA> | Mamić | dobar | menadžer | europska | unija | <END> || ajmo | ajmo || <HAPPY> Prepoznamo ključne fraze in te nize besed spremenimo v gramatično čitljivo obliko. ”Mamić”, ”menadžer”, ”europska”, ”unija” Razpoloženje ugotovimo na podlagi zapletenega sistema več modelov za napovedovanje, ki poskušajo ugotoviti, kako bi človek doživel ton besedila, oziroma naklonjenost avtorja tistemu, o čem piše: je to pozitivno, negativno ali nevtralno stališče? V tem primeru je algoritem ugotovil, da gre verjetno za pozitivno razpoloženje.
21. FYI by CROZ / oktober 2014 | 21 Intranet v banki SKB | projektne zgodbe V banki SKB so prepoznali to potrebo, intranet, ki bo za- poslenim zagotovil jasno predstavitev vseh izdelkov, ki jih banka ponuja končnim uporabnikom, hkrati pa bo deloval kot kanal in osrednje Internet ali intranet? Kaj je pomembnejše? Številni bodo pomislili ”javno spletno mesto, seveda”, saj ga vidijo končni uporabniki. Vendar, ali ni hiter, strukturiran in preprost dostop do informacij za zaposlene prav tako, če ne celo bolj pomemben? Primer vzpostavitve intraneta v banki SKB. Piše: Luka Podobnik mesto za prenos informacij o obvestilih ter aktualnih dogodkih. Poleg potrebe po sistemu, prek katerega bo mogoče upravljati spletne vsebine, je bila nujna tudi integracija z obstoječim sistemom za upravljanje dokumentov Alfresco, oziroma način, da se uporabnikom omogoči dostop do pomembnih dokumentov in njihovo iskanje. Liferay kot izbrana portalna platforma Kot portalna rešitev, ki izpolnjuje te in šte- vilne druge zahteve, je izbran portal Life- ray, odprtokodna portalna rešitev, ki poleg objavljanja vsebin omogoča tudi številne druge funkcionalnosti. Portal Liferay se v tem scenariju uporablja kot osrednja točka integracije različnih obstoječih storitev, zagotavlja pa tudi možnost integracije z morebitnimi prihodnjimi storitvami. Portal Liferay vsebuje več kot 60 vgrajenih portalnih gradnikov, ki podpirajo različne funkcionalnosti upravljanja vsebin, sode- lovanja in družbenih dejavnosti. Sistem Liferay poleg vgrajenih portalnih gradni- kov podpira tudi preprost razvoj portalnih gradnikov v programskem jeziku JAVA, kar omogoča nadgradnjo glede na uporabni- kove najzahtevnejše potrebe. Portal Liferay je na voljo v dveh različi- cah, Community in Enterprise, pri čemer je različica Community brezplačna, različica Enterprise pa je praviloma stabilnejša in s seboj prinaša prednosti uradne podpore Liferay Marketplace Portal Liferay vsebuje vgrajeno skupino portalnih gradnikov, tj. aplikacij, ki so pripravljene na vgraditev v strani portala in izpolnjujejo najpogostejše potrebe uporabnikov. Če za svoj portal potrebujete poseben, specifičen portalni gradnik, med vgrajenimi portalnimi gradniki portala Liferay pa ne najdete tistega, kar iščete, je odgovor morda v sistemu Liferay Marketplace. Med več kot 300 večinoma brezplačnimi portalnimi gradniki lahko najdete pripravljene rešitve s področja komunikacij, produktivnosti, varnosti in splošnih pripomočkov. Med bolj zanimivimi rešitvami sta portalni gradnik, ki omogoča klepet med uporabniki in portalni gradnik za integracijo z aplikacijo Google Maps. Želeni portalni gradnik lahko preprosto vgradite v obstoječo namestitev sistema Liferay. Večinoma zadostuje le nekaj klikov. Dodatne informacije so na voljo na naslovu https://www.liferay.com/ marketplace. Spletne aplikacije so kritičen, pa tudi ključen dejavnik uspešnega poslovanja v sodobnem okolju, vendar obenem ne posvečamo dovolj pozornosti njihovi varnosti, zaščiti podatkov in prepreče- vanju nepooblaščenega dostopa. Izkušena skupina naših strokovnja- kov vam bo s tem paketom svetovalnih storitev pomagala pravočasno opaziti varnostne spodrsljaje, zmanjšati tvega- nje in rešiti težave, ki spremljajo manj varne spletne aplikacije. Preverjanje varnosti spletnih aplika- cij vključuje podrobno analizo ranljivosti in penetracijski test izbranih aplikacij ter dvig ravni varnosti vaših spletnih aplikacij – od razvoja, prek testiranja, do izvedbenega okolja. Dodatne informacije na naslovu www.croz.net/consulting Consulting@CROZ Preverjanje varnosti v spletnih aplikacijah
22. 22 | FYI by CROZ / oktober 2014 projektne zgodbe | Intranet v banki SKB Značilna stran portala, usmerjena v strukturiranost in preglednosti vsebine. CROZ in Liferay Družba CROZ je že izkušena pri uvedbah portala Liferay; med uporabniki, pri katerih smo implementirali Liferay, bi izpostavili: • VIPnet d.o.o. - implementacija javnega spletnega mesta in intranetnega portala; • Croatia osiguranje d.d. - implementacija intranetnega portala; • Raiffeisen BANK Austria d.d Zagreb - implementacija javnega spletnega mesta. Poleg tega je družba CROZ edini uradni partner družbe Liferay v regiji, na kar smo posebej ponosni. družbe Liferay. Pri obeh različicah je mo- goče dostopati do izvorne kode. Pripravljeni, pozor, zdaj! Kot družba, ki ima za seboj veliko odi- granih internetnih tekem, smo sestavili ekipo za to srečanje in se pognali igrišče. Vgrajene funkcionalnosti portala Liferay so omogočile implementacijo velikega dela zahtev, vendar smo skozi pogovore s poslovnimi uporabniki prepoznali potrebo po nekaterih uporabnih in zanimivih funkcionalnostih, ki jih portalne rešitve ne podpirajo ”out of the box”. Koledar dejavnosti in specializirani slovar sta samo dva primera. Za te potrebe smo nadgradili sistem z našo kodo, končni rezultat pa se je estetsko vključil v temo portala in uporabnikom zagotovil dodatno pomoč pri delu s portalom. Obliko so izdelali profesionalni spletni oblikovalci glede na smernice in zamisli naročnikov iz banke SKB, rezultat pa je privlačna in pregledna oblika, ki je skladna s standardi Skupine Société Générale. Kot smo že omenili, banka SKB upo- rablja sistem za shranjevanje dokumentov Alfresco, v katerem so shranjeni pomemb- ni podatki za končne uporabnike portala, kot so dokumenti, ki opisujejo bančne pro- dukte in storitve, pravilniki in obrazci. Da bi uporabnikom omogočili preprost dostop do navedenih informacij prek intrane- tnega portala, smo razvili integracijo portalnega gradnika za iskanje po spletnih vsebinah in sistemu Alfresco in integracijo skladišča za dokumente v portalu Liferay s sistemom Alfresco. Na ta način portal Liferay postane ”okno” v sistem Alfresco, na način, ki je pregleden za uporabnike. Poleg tega najzahtevnejšega dela projekta smo vpeljali tudi druge funkcionalnosti: prikaz obvestil in aktualnih dogodkov v obliki vira RSS, konfiguracijo poteka dela za odobritev vsebin ter razširitev vgrajene- ga urejevalnika WYSIWYG z možnostmi, ki urednikom portala olajšajo vsakodnev- no delo. Omeniti moramo tudi preprostejši, a neizogiben del projekta, migracijo ob- stoječih informacij v portal. Informacije o izdelkih v dokumentih Word so prenesene v strukturo strani portala. Zaradi specifič- ne oblike vsebin, postopka ni bilo mogoče Tomaž Pevc SKB banka d.d. (IT-infrastruktura in arhitektura) Značilna stran portala, usmerjena v strukturiranost in preglednosti vsebine. Naslovnica portala, kombinacija klasičnih portalnih gradnikov platforme Liferay za prikaz vsebin in portalnih gradnikov, razvitih za potrebe banke. upravljanje, da zagotavlja podporo potekom dela, da omogoča nadzor različic dokumentov, da ima zmožnost urejanja intranetnih in internetnih strani. Zahteve oddelka Informacijska tehnologija pa so bile: platforma mora biti skladna s smernicami Skupine Société Générale, stroški implementacije in vzdrževanja morajo biti primerni, omogočati mora skalabilnost, nuditi možnost integracije s platformo za DMS, ki je v banki SKB že implementirana. Iskali smo kompetentnega poslovnega partnerja, ki je zmožen zagotoviti kakovostno storitev razvoja in vzdrževanja. Po opravljeni analizi se je za primerno izkazala platforma Liferay Portal CMS za izvedbo intranetnega portala v navezi s platformo Alfresco DMS za upravljanje dokumentov. V postopku izbora se je za najustreznejšega izvajalca izkazala družba CROZ d.o.o. iz Zagreba, ki je k izvedbi pristopila hitro in profesionalno ter v pol leta uspešno implementirala predstavljeno rešitev na infrastrukturi banke SKB. Od uvedbe intraneta na platformi Liferay družba CROZ nudi banki SKB strokovno vzdrževanje in razvoj na obeh odprtokodnih platformah, hkrati pa se pogosto izkaže tudi z učinkovitimi predlogi za nadaljnji razvoj poslovnih rešitev. V banki SKB smo se odločili za izvedbo programa RED (Retail Efficiency Development), projekta, s katerim smo izboljšali obstoječe procese pri prodajnih aktivnostih v poslovni mreži SKB. V sklopu projekta smo zamenjali zastarele rešitve (javne mape, mrežne diske) z novejšo, učinkovitejšo in bolj prilagodljivo platformo. Nova platforma omogoča jasno in enostavno strukturo prikazovanja informacij, uporabniku prijazno navigacijo ter učinkovito funkcijo iskanja, ki omogoča hitro razpoložljivost kakovostnih informacij. Dodatne zahteve pri prenovi so bile: da vsebino oblikuje in vzdržuje oddelek v diviziji Komercialno opraviti s samodejnimi skriptami. Skupina mlajših programerjev je zato ročno ustva- rila več kot 300 strani s statično vsebino. Prav tako smo prenesli več kot 1500 doku- mentov v sistem Alfresco DMS. Zaključek? Portal smo uspešno prestavili v proizvo- dno okolje, vsi zaposleni so ga zelo hitro sprejeli, vendar se tu sodelovanje med družbama SKB in CROZ ni končalo. Z novi- mi idejami in potrebami se portal spremi- nja, razvija ter raste. Kdo ve, mogoče nas v prihodnosti čaka SKB Intranet 2.0? A
23. Postopek nabave, hiter kot PUMA Kako je potekala implementacija CROZ-ove rešitve cDocs za potrebe postopka nabave v Renaultu. Piše: Ivana Skorupan Postopek nabave, hiter kot PUMA | projektne zgodbe Seznam nalog – po prijavi v aplikacijo se uporabniku prikaže seznam nalog, ki čakajo njegovo odobritev. Naloge so združene v skupine po postopkih in stanjih. Družba Renault Nissan Adriatic je osnovana leta 2008, ko so se združile podružnice Renault Nissana iz Slovenije, Hrvaške in Srbije, pridružili pa so se jim še uvozniki teh dveh znamk iz Bosne in Hercegovine, Črne Gore, Makedonije, s Kosova, iz Albanije, in od letos tudi Grčije. Osnovna dejavnost družbe je uvoz in distribucija avtomobilov in nadomestnih delov znamk Renault, Dacia in Nissan prek mreže pooblaščenih koncesionarjev na celotnem ozemlju. Sama družba Renault Nissan Adriatic ima trenutno 260 zaposlenih, FYI by CROZ / oktober 2014 | 23
24. 24 | FYI by CROZ / oktober 2014 Zaslon za vnos artiklov v naročilnico – obvezna polja so poudarjena, aplikacija pa pri vnosu količine in cene blaga sama preračuna druge podatke, povezane z zneski. projektne zgodbe | Postopek nabave, hiter kot PUMA razdeljenih v oddelke, ki so posebej zadolženi za znamke Renault, Dacia in Nissan (trženje, prodaja, post-prodaja), medtem, ko so službe kot so banka Renault, računovodstvo, finance, nabava, kadrovska služba in podobno, skupne za vse tri znamke. Za potrebe tako zapletene organizacije smo morali razviti sistem za postopek nabave. Način dela pred razvojem novega sistema je bila še ena pisarniška zgodba z dokumenti, ki so fizično krožili po pisarnah, zato ni bilo preprosto ugotoviti, koliko jih sploh je, kakšno je njihovo stanje in pri komu je kateri dokument, kar je neposredno in posredno vplivalo na delo in poslovne rezultate. Ko so za eno naročilo zbrali vse potrebne podpise, je oseba, odgovorna za naročila, dobavitelju po elektronski pošti poslala naročilnico v datoteki Excel. Pomembni podatki za izpolnjevanje dokumentov so bili shranjeni na različnih mestih, kar je povečalo možnost napake pri izpolnjevanju, manjkal pa je tudi strog nadzor. Bil je skrajnji čas za pospravljanje pisarne in uvajanje boljšega nadzora v celoten postopek nabave. Potek razvoja sistema Za potrebe analize smo od Renaultove skupine, zadolžene za razvoj sistema, prejeli podrobno funkcijsko specifikacijo sistema, ko pa smo izdelali analizo, smo organizirali delavnice z uporabniki. Dogovorili smo se za štiri delavnice, na katerih smo šli skozi specifikacije, stran po stran. Razpravljali smo o postopkih in o tem, kako jih izboljšati, odstranjevali smo odvečne in dodajali nujne funkcionalnosti. Po končanih delavnicah in velikem številu elektronskih sporočil smo imeli funkcijsko specifikacijo, na podlagi katere smo lahko začeli razvoj. Naša misija je bila v treh mesecih razviti sistem, ki bo popolnoma podprl postopek nabave in upošteval določena pravila pri naročilu blaga za Hrvaško, Slovenijo in Srbijo, ter omogočiti uporabnikom boljši vpogled v prihajajoče stroške. Aplikacija podpira štiri postopke. Prvi, ki smo ga razvili, je bil postopek rezervacije sredstev za naročanje blaga. Gre za postopek, pri katerem se na dokumentu opredeli dobavitelj in blago, ki bo naročeno pri njemu. Eden dokument lahko vsebuje več postavk za naročilo, tj. več artiklov, uporablja pa se kot rezervacija sredstev za naročilnice, pri katerih znesek presega 5000 evrov. Ta postopek smo izbrali za prvo iteracijo, ker je bil dovolj velik, da uporabniki takoj po dostavi dobijo vtis, kako aplikacija deluje, pa tudi poslovno je bilo logično razviti prav ta postopek, saj se postopek naročila, glede na poslovna pravila, navezuje nanj. Kot idealen kandidat za rešitev vseh izzivov tega projekta se je pokazala CROZ-ova platforma cDocs, ki uporablja tehnologijo Alfresco za shranjevanje dokumentov, medtem ko smo za upravljanje postopkov pri Renaultovih rešitvah uporabili odprtokodno platformo Acitivity BPM. Pri samem razvoju sistema, ki je šele tik pred koncem projekta dobil tudi svoje ime PUMA (Purchasing Management Application), in je trajal približno tri mesece, smo uporabili agilno metodologijo. Pred vsako iteracijo smo se o vseh vprašanjih posvetovali z uporabniki prek elektronske pošte, po potrebi pa smo imeli tudi dodatne sestanke. Razvoj je bil razdeljen v štiri iteracije. Po prvi iteraciji razvoja in testiranja smo dostavili en celoten postopek in ga demonstrirali uporabniku. Glede na pozitivne reakcije uporabnikov smo vedeli, da smo na pravi poti, tako da smo, skladno z načrtom, po preostalih treh iteracijah dostavili tudi preostale funkcionalnosti. Ugotovili smo, da je demonstracija za uporabnike po prvi iteraciji koristna, zato smo s to prakso nadaljevali tudi po koncu vseh ostalih iteracij. Med predstavitvami so uporabniki takoj testirali aplikacijo
25. FYI by CROZ / oktober 2014 | 25 Kateri so bili razlogi za uvajanje novega sistema in cilji projekta? Poslovni razlogi za uvajanje novega sistema so bili: • nizka učinkovitost in medsebojna ločenost postopkov načrtovanja stroškov, osnovnega postopka nabave in postopka validacije računov v podružnicah družbe Renault Nissan Adriatic (RNA); • implementacija korporativnega orodja za nabavo v družbi Renault Nissan Srbija (RNSRB) ni bila mogoča; • aplikacija za validacijo računov je bila že zastarela in ni več zadovoljevala potreb RNA; • omejena zmožnost izdelave podrobnih analiz nabave na ravni države ali teritorija. Cilji projekta so bili: • uskladitev s politiko nabave in postopki Skupine Renault; • vzpostavitev poteka dela, ki bo vodjam omogočil validacijo zahtev, ki jih pošiljajo Marko Anžič Renault Nissan Adriatic (notranji revizor/ notranji nadzor) uporabniki RNA iz katerekoli države; • boljša vidnost predmeta nabave za validatorje (vrsta in višina stroška, spremljanje proračuna); • omogočanje samodejnega nadzora in revizije v realnem času za vse postopke, povezane z nabavo; • podpora organizaciji, ki zajema več držav, različne jezike, oblike dokumentov, stopnje DDV, valute in druge dejavnike, ki so odvisni od lokalne zakonodaje posameznih držav RNA; • učinkovit in transparenten postopek validacije računov, skladen s pravili nabave v RNA; • možnost bistvenih prihrankov. Ste zadovoljni z realizacijo in kako je potekalo sodelovanje z družbo CROZ? Uresničitev ciljev lahko preprosto povzamemo: vsi cilji so že uresničeni, razen prihrankov, ki so bodo nedvomno pokazali s časom. Edini večji negativni vpliv na organizacijo je nekoliko povečana količina dela pri vnosu podatkov. To je ne nazadnje cena za kakovostne informacije, ki jih v preteklosti nismo imeli, vendar je prav zmanjšanje administrativnega dela (kolikor je mogoče brez ogrožanja kakovosti podatkov) prednostna naloga za naslednjo fazo razvoja. Aplikacija je živa stvar. Od začetka uvajanja smo v proizvodnjo vključili več kot 50 sprememb, ki uporabnikom olajšajo delo. Kljub temu mislimo, da smo zelo dobro zastavili scope creep, saj nobena izmed sprememb ni pomembno spremenila osnovnih postopkov ali vloge uporabnika. Družba CROZ je kot partner pokazala izjemno profesionalno držo v vseh fazah projekta - od ponudbe, predstavitve svoje platforme, sklenitve pogodbe, vodenja projektov, do delavnic, na katerih so se resnično potrudili razumeti naše težave, potrebe in vizijo rešitve. Tudi po začetku proizvodnje aplikacije so bili dovolj hitri, upoštevali so prednostne naloge, ki smo jih določili, in so bili aktivni pri opredelitvi rešitev sprotnih napak ter drugih težav. V projektni skupini je bilo nekaj oseb, ki so bile popolnoma zadolžene za projekt in seznanjene z aplikacijo, procesi ter zgodovino projekta, zato sta komunikacija in odpravljanje težav potekali zelo gladko. Postopek nabave, hiter kot PUMA | projektne zgodbe in se spoznavali z novim orodjem za naročanje sredstev, kar je veliko prispevalo k navajanju uporabnikov na sistem pred samo produkcijo. PUMA v akciji Poleg postopkov, ki se izvajajo pri naročilu blaga, platforma cDocs prinaša številne druge funkcionalnosti, ki Renaultovim uporabnikom olajšajo vsakodnevno delo. Takšna je na primer upravljanje uporabniških vlog, funkcionalnost, s katero uporabnik s skrbniškimi pooblastili drugim uporabnikom sistema dodeli vlogo, ki jim daje pravico do sodelovanja v določenem postopku, pa tudi pravico do pregledovanja dokumentov v aplikaciji. Razvili smo modul za upravljanje šifrantov, ki je izjemno pomemben za nadzor podatkov, ki se shranjujejo v dokumentih. V primeru aplikacije PUMA so šifranti pomembni za sam pretok dokumentov pri postopku, saj v njej sprejemamo odločitve na podlagi denarnih omejitev, te pa so določene v šifrantih. Pri tem modulu so občutljivi podatki, ki se shranjujejo v dokumentih, shranjeni na enem mestu, spreminjajo pa jih lahko samo uporabniki s skrbniškimi pooblastili, ki so zanje tudi odgovorni. Za vsak dokument v aplikaciji obstaja poseben pogled, v katerem lahko uporabniki, glede na svoja pooblastila, iščejo dokumente po različnih parametrih, kot so trenutno stanje, čas ustvarjanja dokumenta, zneski itd. Rezultate iskanja je mogoče razvrstiti ali jih izvoziti v Excel, vedno pa je mogoče tudi pregledati podrobnosti samega dokumenta in zgodovino podatkov. Če mora uporabnik na primer ustvariti nov dokument, pri katerem vnaprej ve, da bo podoben že obstoječemu, obstaja funkcionalnost kopiranja dokumenta v sistemu, ki bo bistveno skrajšala čas, potreben za to opravilo. Problem ročnega prestavljanja dokumentov na drugega uporabnika v času letnih ali bolniških dopustov je rešen z implementacijo delegiranja. Pri tej funkcionalnosti uporabnik prenese vse svoje trenutne naloge na uporabnika, ki ga nadomešča v obdobju, ki ga določi sam. Če jih izbrana oseba ne reši, se naloge po preteku delegiranja vrnejo uporabniku. Če smo že pri nalogah, ki čakajo odobritev posameznega uporabnika, PUMA vsakemu uporabniku že ob prijavi prikaže seznam njegovih trenutnih nalog. Naloge so združene v skupine glede na postopke in stanje, ob vsakem stanju pa je navedeno tudi število dokumentov, ki jih uporabnik mora odobriti. Tako uporabnik z enim klikom lahko vidi količino svojega dela, kot je razvidno na sliki. PUMA je po zadovoljivem uporabniškem testu brez težav prispela na svoj cilj in se elegantno pretihotapila v proizvodnjo, kjer na srečo drugih uporabnikov že nekaj časa prebiva in prede.
26. 26 | FYI by CROZ / oktober 2014 pogovor | Jurij Bertok Pogovarjal se je: Krešimir Mudrovčić Uporaba koncepta računalništva v oblaku v javni upravi je zelo aktualna evropska tema. Spremembe spodbujajo predvsem tehnološki napredek, želja po transformaciji (izčrpanega) evropskega gospodarstva in potreba javne uprave po boljših in cenejših informacijskih storitvah. Evropska komisija je že septembra 2012 objavila načrt za spodbujanje računalništva v oblaku, vendar so spremembe zelo zapletene in se zagotovo ne bodo zgodile čez noč. O tej temi smo se pogovarjali z Jurijem Bertokom, generalnim direktorjem Direktorata za informatiko in e-storitve pri Ministrstvu za notranje zadeve Republike Slovenije. Naš sogovornik je eden izmed začetnikov uvajanja ”oblaka” v javno upravo in gonilna sila ”kvantnega preskoka”, projekta reorganizacije državne informatike, ki ga pravkar pripravlja slovenska vlada. (opomba: pogovarjali smo se v aprilu 2014) Reorganizacija informacijskega sistema državne uprave Slovenije Kako je organizirana informatika v slo- venski javni upravi? Katere naloge izvaja Direktorat za informatiko in e-storitve? Slovenska javna uprava ima 12 mini- strstev s pripadajočimi organi v sestavi. Vsa ministrstva in večji organi imajo v svoji sestavi organizacijske enote, ki opravljajo storitve informacijske podpore. Za državno informatiko kot celoto je zadolžen Direktorat za informatiko in e-stortive znotraj Ministrstva za notranje zadeve, ki zagotavlja delovanje centralnega informacijsko-komunikacijskega sistema v najširšem smislu. To vključuje predvsem upravljanje in vzdrževanje poslovne infor- macijske arhitekture, s sodobnimi koncepti modeliranja poslovnih procesov in upo- števanje konceptov (zasebnega) računal- ništva v oblaku. Ena izmed pomembnejših nalog je zagotavljanje elektronskega poslovanja organov ter uvajanje izboljšav. Poleg tega izvajamo podporo upravnim ter drugim postopkom, ki jih v okviru svojih delovnih področij izvajajo organi. Direktorat skrbi za razvoj, nemoteno delovanje in vzdrževanje sistemov državnih organov na informacijsko-komunikacijski infrastruk- turi ministrstva, zagotavljanje povezlji- vosti registrov in integracijo podatkovnih virov s pospešeno informacijsko podporo upravljanja procesov. Izvajamo tudi naloge vladnega overitelja digitalnih potrdil SI*CA za občane, poslovne subjekte in državno upravo kot tudi za potrebe slovenskih bio- metričnih potnih listin ter naloge izdajatelja varnih časovnih žigov za SI-TSA za državne organe in poslovne subjekte. Na strateški ravni spremljamo razvoj informacijsko-komunikacijske tehnologije (IKT) in pripravljamo standarde ter smerni- ce na posameznih področjih informatizaci- je, skrbimo za normativni okvir, vključuje- mo pa se tudi v mednarodne aktivnosti na področju informacijskih tehnologij. Na Direktoratu za informatiko in e- storitve združujemo sodelavce z različ- nimi znanji in bogatimi izkušnjam, zato lahko zagotavljamo kakovostne storitve in uresničujemo zastavljene cilje. Skupni sta nam želja po ustvarjalnosti, znanju in raziskovanju ter iskanje vedno novih priložnosti. Septembra 2012 je Evropska komisija ob- javila načrt za spodbujanje računalništva v oblaku. Komisija je napovedala, da bo javna uprava v ospredju pri uvajanju teh- nologije oblaka? Kako po vašem mnenju napreduje realizacija te strategije? Na splošno v Evropi? V Sloveniji? Kdaj pričakujete ”kvantni preskok”? V EU se ocenjuje, da bomo ob ukre- pih znotraj digitalne agende do 2020 z računalništvom v oblaku zagotovili 3,1 milijona novih delovnih mest, dodali 940 milijard EUR-ov k EU GDP-ju, vzpostavili delovanje 370,000 novih podjetij (največji delež v sektorjih maloprodaje/veleprodaje, nepremičnin, finančne industrije), pocenili stroške IKT-ja za več kot 20%, spremenili strukturo stroškov iz investicijskega mode- la v stroškovni model (Capex v Opex) ter na ta način zmanjšali omejitve pri odpiranju novih podjetij in ustvarjanju novih delovnih mest. Značilnosti dostopa do storitev od kjerkoli, kadarkoli in z vsake naprave, ne- omejen dostop do poljubnih kapacitet IKT na zahtevo, nižanje stroškov lastne opreme IKT in stroškov vzdrževanja, enovite storitve IKT in standardi s tega področja ter zaupanja vredne in stroškovno učinkovite storitve so glavne pridobitve, ki jih lahko pričakujemo. V okviru EU smo zato zastavili tri osnov- ne aktivnosti, ki nam bodo omogočile lažje doseganje gornjih ciljev: ureditev področja standardizacije z namenom zagotavlja- nja večje povezljivosti med storitvami ter večanja zaupanja uporabnikov, enostavna pogodbena določila za določanje ravni storitve, ki jo zagotavljamo uporabnikom, bodisi državljanom ali javnim institucijam, ter vzpostavitev skupne platforme EU za podporo nastajanja novih, inovativnih storitev v okviru delovanja javne uprave posamezne države članice. V Sloveniji prip- ravljamo strategijo razvoja računalništva v oblaku 2015-2020.
27. FYI by CROZ / oktober 2014 | 27 Jurij Bertok | pogovor Jurij Bertok Prav tako poteka proces reorganizacije državne informatike (t.i. projekt kvantni preskok), katerega pomemben del pred- stavlja ravno model računalništva v oblaku. Gre za centralizacijo finančnih in kad- rovskih virov na področju komunikacijske infrastrukture, podatkovne infrastrukture, informacijske varnosti in horizontalnih aplikacij. Za javno upravo je oblak pogosto sinonim za varčevanje? Je to edini razlog za prehod na tehnologijo oblaka? Ne. Stroškovni vidik je pri tem sicer pomemben, nikakor pa ne edini dejavnik. Hiter razvoj informacijsko-komunika- cijskih tehnologij in politični, gospodarski, družbeni ter spremljajoči drugi dejavniki omogočajo in zahtevajo preobrazbo informatike tako, da ta postane cenovno sprejemljivejša, učinkovitejša ter uporab- niku prijaznejša. Računalništvo v oblaku je obetajoč model računalništva, ki lahko izpolni omenjena pričakovanja in ponudi dolgoročno stalnost informacijskega siste- ma. Podatkovni, aplikacijski in posledično organizacijski otoki ali silosi, ki so značilne paradigme sedanjega informacijskega sistema (državne) informatike so posle- dica nesistematičnega in neustreznega individualističnega pristopa k uvajanju informacijskih rešitev. Ugotovili smo, da so storitve za državljane prepogosto nepo- vezane, delujoči sistemi IKT pa med seboj nezdružljivi s preveliko zmogljivostjo, zlasti na ravni posameznih podatkovnih centrov posameznih ministrstev. Uvajanje računalništva v oblaku in izvajanje storitev računalniškega oblaka, ki bi bilo osnovano na izpostavljenih slabih paradigmah, ne bi prineslo želenih učinkov, ampak bi zagoto- vo stanje poslabšalo. Po drugi strani pa lahko metodološki prehod na oblačno ar- hitekturo s sledenjem ključnega koncepta ”Everything-as-a-Service” (XaaS) zagotovi boljšo poravnavo med poslovno-organiza- cijskimi in tehnološkimi vidiki, učinkovi- tejšo interoperabilnost in integracijo, lažjo zmožnost elektronske podpore subjektov v javni upravi in izven nje, enostavnejšo avtomatizacijo poslovnih procesov in delovnih tokov, učinkovitejše zagotavlja- nje razvoja novih in vzdrževanja obstoječih e-storitev, poenostavitev in znižanje stro- škov vzdrževanja aplikacij in infrastruk- ture ter večjo fleksibilnost uporabnikov IKT tehnologij in informacijskega sistema znotraj javne uprave in izven nje. Razvoj novih e-storitev (tudi odprtokodnih), za- gotavljanje standardov, povezovanje prek enotne storitvene platforme in ustvarjanje dobrih pogojev za obsežnejše inovacije, bodo Slovenijo znova pozicionirale med vodilne ponudnice e-storitev v javni upravi in širše. Katere so tiste ključne spremembe na področju informatike v naslednjih 5 letih, ki bodo zagotovo spremenile delovanje slovenske javne uprave? Informatika ne sme biti predvsem stro- šek, ampak bi morala postati mehanizem za doseganje prihrankov na finančnem, procesnem in kadrovskem področju, hkrati pa prevzeti vlogo katalizatorja inovacij na področju e-storitev znotraj javne uprave in navzven. Državna informatika je eden izmed največjih naročnikov informacijske opreme in informacijskih rešitev. Posledično ima tudi največji vpliv na tržišču ponudnikov razvoja informacijskih rešitev. Zato je uvajanje visokih standardov in najsodob- nejše poslovno informacijske arhitekture zelo pomembno za razvoj usposobljenosti programskih/razvojnih hiš in izvajalcev. V tej luči bo razvoj tržišča (preko meha- nizmov javnega naročanja) v smeri visoke konkurenčnosti našega gospodarstva, prinesel dolgoročne pozitivne učinke, tako na gospodarstvo kot na bilanco proračuna. Enotna arhitektura, virtualizacija in konsolidacija informacijske infrastrukture so temelj uporabe računalništva v oblaku in skupaj z avtomatizacijo postopkov, samooskrbo, večnajemniškim modelom in obračunom po uporabi predstavljajo enormen potencial za prihranke, izboljšanje učinkovitosti in inovacije. Opustiti moramo uporabo t.i. centralnih strežnikov, ker so neprimerni za predviden model računalni- štva in odločno predragi za zmogljivost, ki jo nudijo. Z vpeljavo kombinacije privatno- hibridnega oblačnega modela bi lahko s federacijo in konsistentno virtualizacijo vse računske centre po posameznih mini- strstvih konsolidirali v enoten, virtualizi- ran in razpršen računalniški oblak, ki bi pomembno zmanjšal stroške lastništva (vzdrževanja in upravljanja), pomembno izboljšal izkoriščenost virov ter omogočil postopno konsolidacijo na nivojih strojne opreme, shrambe in omrežja. Med posto- pno zamenjavo obstoječe strojne opreme (strežnikov, omrežja, diskovnih sistemov) pa bi izvedli konsolidacijo tudi na ravni strojne opreme. Kakšni so vaši načrti in prednostne naloge za naslednjih nekaj let? Naša vizija je doseči zmogljivosti komu- nikacijskih in informacijskih sistemov, ki bodo uporabnikom znotraj državne uprave nudile učinkovito podporo pri sprejemanju odločitev in optimalnemu izvajanju nalog v nacionalnem ter mednarodnem okolju na osnovi gospodarnega, zanesljivega in var- nega dostopanja do podatkov ter povezlji- vosti. Uporabnikom storitev državne upra- ve želimo omogočiti učinkovit, zanesljiv in enostaven dostop do storitev. Strateški cilji državne informatike v naslednjih 5 letih so: 1. vzpostaviti zanesljive, varne in visoko razpoložljive storitve KIS, ki omogočajo op- timalno izvajanje procesov državne uprave skladno z uveljavljenimi standardi EU; 2. zagotoviti enovito in celovito upravlja- nje (načrtovanje, razvoj, izvajanje, nadzor) KIS državne uprave; 3. zagotoviti zmogljivost informacijske varnosti in učinkovite obrambe pred napadi iz kibernetskega prostora za vse komu- nikacijsko informacijske sisteme državne uprave.
28. 28 | FYI by CROZ / oktober 2014 tehnologije in trendi | IBM Integration Bus V9 Edini integracijski izdelek, ki ga potrebujete Ali razčlenjujete datoteke? Implementirate spletne storitve? Se povezujete z zbirkami podatkov? Komunicirate s sporočili? IBM Integration Bus zagotavlja hitro ter učinkovito reševanje težav pri integraciji in veliko več. Preberite, kako lahko pomaga tudi vam. Piše: Miroslav Rešetar S prihodom izdelka IBM Integration Bus V9 (IIB) je izbira orodij za integracijo postala veliko preprostejša. Še nedavno so stranke družbe IBM lahko izbirale med izdelkoma WebSphere Enterprise Service Bus (WESB) in WebSphere Message Broker (WMB, skrajšano Broker). Glede na to, da se funkcionalnosti teh dveh izdelkov prekrivajo, so se pri družbi IBM odločili poenostaviti zadevo in nadaljevati z razvijem samo enega izdelka: WESB so ukinili, tako IIB ostaja edini IBM-ov izdelek Enterprise Service Bus (ESB). Glede na to, da je IIB neposredni naslednik Brokerja, lahko bi celo rekli, da je njegova različica, je mogoče izpeljati neposredno migracijo iz njegove 6., 7. ali 8. različice na IIB V9. Seveda niso pozabili na stranke, ki so uporabljale WESB. Izdelku IIB V9 je priložen WESB conversion tool, orodje za konverzijo izdelkov WESB. Družba IBM bo seveda še naprej zagotavljala podporo za WESB. Zakaj izbrati IBM Integration Bus? Obstoječe IBM-ove stranke bi lahko zanimalo, da je IBM Integration Bus IBM-ov strateški integracijski izdelek, kar pomeni, da bo za večino IBM-ovih izdelkov vmesne programske opreme zagotovljena integracija s IIB-om out- of-the-box. Za tiste, ki še ne uporabljajo IBM-ih izdelkov, proizvode, bi lahko IIB bil zanimiv zaradi preprostosti in kratkem času, potrebnem za učenje. Prav tako, če ste primarno usmerjeni v tehnologije .NET ali programski jezik Java, se IIB dobro ujema z obema svetovoma. Platforme Windows vključujejo tudi Common Language Runtime v4.5 (navidezni stroj CLR - .NET), ki omogoča razvoj vozlišč, na primer v programskem jeziku C#. Zaradi katerih funkcionalnosti je IIB izjemen integracijski izdelek? Heterogenost razvojnega okolja smo že omenili. V nadaljevanju predstavljamo nekatere izmed najbolj uporabnih značilnosti. DFDL – Data Format Description Language IIB ima implementiran razčlenjevalnik DFDL. Dokler se na trgu ni pojavil DFDL, ni obstajal industrijski standard za opise in obdelavo besedilnih ali binarnih datotek. Kaj to pomeni? Z razčlenjevalnikom DFDL lahko s prepoznavanjem glave, polj, dolžine in vrst opišemo svojo datoteko CSV, ASCIl, binarno datoteko ali npr. strukturo COBOL. Z modelom DFDL je mogoče brez ene same vrstice kode, zgolj z razčlenjevalnikom serializirati model v ciljno obliko ali razčleniti vstopno strukturo (datoteko). Kar je najpomembnejše, model DFDL-a lahko dobimo iz primera datoteke CSV. Z razčlenjevalnikom DFDL je delo z datotekami CSV ali drugimi slogovno orientiranimi datotekami zelo prijetna izkušnja v primerjavi z ročnim programiranjem razčlenjevalnika našega modela. Pomembno je omeniti, da DFDL na noben način ne narekuje strukture podatkov, ampak gre za standardizirani opis predhodno opredeljenih slogov. Heterogenost in povezljivost Skladno s tradicijo WMB-a je IIB dostopen za vse (IBM-ove) platforme, na katerih uporabniki poganjajo programsko opremo middleware: Windows, Linux (zLinux), z/OS, Solaris, AIX in HP-UX. Pomembno je omeniti, da so poleg platform, podprti tudi vsi aplikacijski protokoli, ki jih boste potrebovali, od TCP-a do spletnih storitev. Vse to omogoča, da se z istimi veščinami in orodji povežemo na podedovan zaledni sistem in razvijamo sodobne asinhrone storitve JSON REST. Spremljanje in analitika IIB vsebuje integrirani sistem za spremljanje in analitiko. Mar ne bi bilo imenitno, če bi lahko v vsakem trenutku vklopili spremljanje izvajanja
29. FYI by CROZ / oktober 2014 | 29 IBM Integration Bus V9 | tehnologije in trendi Zgodovinski pregled izdelkov ESB družbe IBM • 2005 – IBM WebSphere Message Broker V6.0 – podpora za spletne storitve • 2007 – IBM WebSphere Enterprise Service Bus V6.0 – WAS 6.0, SIBus, JAX-RPC • 2009 – IBM WebSphere Message Broker V7.0 – odstranjena odvisnost od DB2 • 2009 – IBM WebSphere Enterprise Service Bus V7.0 – WAS 7.0, JAX-WS, JEE5 • 2011 – IBM WebSphere Message Broker V8.0 – .NET, DFDL, Global Cache • 2013 – IBM Integration Bus V9.0 – BPM Integration, Rules Engine, Monitoring, WESB conversion tool Editor za model DFDL omogoča testiranje razčlenjevanja in serializacije brez zagona strežnika Statistike izvrševanja integracijskega toka integracijskih tokov? Morda se je pojavil zastoj z neznanim vzrokom. Morda želimo vedeti povprečno trajanje ene obdelave. Prav tako morda želimo vedeti, katera komponenta porabi največ časa pri obdelavi. Sistem spremljanja in analitike omogoča vse to, pa tudi več. Še bolje, ne potrebujemo nobene spremembe kode ali ponovnega uvajanja, pa tudi nikakršnega ponovnega zagona nobene izmed komponent. Pri uporabi orodja Integration Explorer ali spletnega vmesnika je vklop spremljanja preprosta funkcija vklopa/izklopa. Spletni vmesnik je posebej zanimiva možnost, saj ne potrebujemo namestitve odjemalca, ampak vse opravimo iz brskalnika. Po vklopu spremljanja lahko analizo izvajamo v realnem času. Rezultati so prikazani v obliki grafa (učinkovitost) ali preglednice (analiza po vozliščih). Upravljanje delovne obremenitve (throttling) Pogosto imamo potrebo po upravljanju delovne obremenitve sistema. Vsi sistemi programske opreme imajo določeno zmogljivost obdelave na časovno enoto. Če to zmogljivost presežemo, se lahko pojavijo težave, kot so sesutje sistema, nedosledno stanje ali blokiran proces. Da bi preprečili takšne situacije, je smotrno omejiti število vhodnih obdelav v sistemu. IIB nam omogoča prav tak nadzor. V prejšnjih različicah Brokerja in WESB-a smo to funkcionalnost morali implementirati sami, saj iz izkušenj vemo, da je pogosto potrebna, ali celo nujna. Seveda dobra implementacija omejevanja zmogljivosti ni preprosta, zato je ta možnost več kot dobrodošla. Kako jo uporabljamo? V nastavitvah uporabljanja delovnih obremenitev lahko nastavimo največje število obdelav v sekundi. Tako smo lahko prepričani, da se ne bodo pojavile neugodne nenadne največje obremenitve, ki presegajo zmogljivost našega transakcijskega sistema. Prav tako je mogoče nastaviti omejitev, ki sproži prikaz obvestila, kadar število sporočil v sekundi preseže nastavljeno mejno vrednost. Pri zmanjšanju števila vhodnih sporočil pod mejo praga se prav tako ustvari obvestilo. Zadnja, vendar tudi pomembna možnost tega mehanizma je samodejni ponovni zagon integracijskega strežnika, kadar sistem zazna, da nekateri izmed integracijskih tokov (message flow) trajajo predolgo. Navedene možnosti je mogoče nastaviti za vsak posamezen integracijski tok. Prav tako lahko določimo pravila. Na primer, s pravilom 10SporočilVSekundi lahko določimo omejitev na 10 vhodnih sporočil v sekundi. Pravilo, ki smo ga določili, lahko uporabimo pri poljubnem številu integracijskih tokov. V istem pravilu lahko določimo tudi druge parametre, kot je obvestilo o prekoračitvi mejne vrednosti vhodnih sporočil. Testiraj model s primerom sporočila Sheme DFDL lahko vključujejo tudi druge sheme (npr. COBOL) Model DFDL strukture COBOL Z modelom izdelaj primer sporočila Ustvari logični primerek modela (primer) 20 vhodnih sporočil/s Vklopljeno pravilo 10SporočilVSekundi Izklopljeno pravilo Napaka v sistemu Trajanje obdelave po vozliščih
30. 30 | FYI by CROZ / oktober 2014 reportaže | Konferenca QED Prvi dan konference se je začel z izvenšolskimi dejavnostmi – dirko in protistresno delavnico. Dan smo končali s koktejli in koncertom jazza v Zadru. Drugi dan konference je z delavnico na temo učinkovitosti odprl Niklas Modig, eden izmed vodilnih svetovnih govornikov na področju lean managementa, avtor najbolj prodajane knjige s tega področja – ”This is lean”. Niklas nam je posredoval svoje praktične izkušnje pri uvajanju načela lean in nas spodbudil k delovanju ter premišljevanju o tem, kako naš način dela, organizacijo, v kateri delamo, in procese pri delu narediti čim učinkovitejše. QED – pot proti učinkoviti informacijski tehnologiji Na konferenci QED že osem let zapovrstjo raziskujemo kakovost pri razvoju poslovne programske opreme. Na letošnji konferenci, ki je potekala od 18. do 20. maja v Zadru, pa smo raziskali razmerje med kakovostjo in učinkovitostjo. Piše: Goran Kelečić Tradicionalna konferenca družbe CROZ Quality in Enterprise Development (QED) je znana kot kraj, na katerem se pogo- varjamo o novih tehnoloških trendih in konceptih. Čeprav v industriji program- ske opreme lahko pogosto slišati pojem učinkovitosti, je ta v redkih podjetjih zaživel kot nekaj konkretnega in merlji- vega. Konferenca QED je od samega začetka bolj osredotočena na izkušnje, metodologijo in znanje, manj pa na spremljajoče tehnologije. Letos smo, ob standardnih predavanjih in delavnicah, uvedli tudi nove oblike predavanj, ki so omogočile kakovostnejši prenos in izmenjevanje informacij, kot so kratki bliskoviti pogovori, pri katerih so se predavatelji odlično prilagodili izzivu, da v samo osmih minutah predstavijo svoje projektne izkušnje in znanja, in seja Open Space, kjer ima vsak udele- ženec konference priložnost predlagati temo za razpravo ter izmenjati izkušnje z drugimi udeleženci, ki kažejo interes za to temo. In rezultati? Kot urednik konference, ki je to nalogo opravljal že petič, sem težko objektiven. A Uigrana organi- zacijska skupina, nasmejani obrazi udeležencev in gostiteljev, sproščeno, vendar kljub temu kakovostno delovno vzdušje – lahko sklepam, da je zmago- valni recept za izvrstno konferenco letos bil zadetek v polno z organizacijskega, strokovnega in zabavnega stališča. Glede na prejete povratne informacije in načrte, ki jih že zdaj pripravljamo, smo prepričani, da bo naslednja konferenca QED še boljša, kakovostnejša in prijet- nejša izkušnja.
31. FYI by CROZ / oktober 2014 | 31 Konferenca QED | reportaže Prvi dan je nadaljeval Hrvoje Veselko iz VIPneta, ki nam je predstavil zelo zanimivo miselnost, kombinacijo učinkovitosti in dejavnosti, ki jo uporablja pri izboljšanju učinkovitosti v svojem podjetju. Scott Bybee iz Avneta je eden izmed svetovnih pionirjev na področju DevOps, ki raziskuje sodelovanje med oddelkom za razvoj programske opreme in sistemskimi inženirji. Scott nas je spoznal s svetom DevOps, vključno s paradigmami, organizacijskimi Drugi dan konference se je začel z delavnico Mihaela Sedmaka iz družbe CROZ, ki je pokazal, kako upravljanje portfelja projektov pri vsakdanjem delu PMO-ja (Project Management Office) z uporabo orodja Kanban, enega izmed temeljev metodologije lean, lahko postane preprostejše in učinkovitejše. spremembami, najboljšimi praksami, ki pomagajo pri pospeševanju organizacijskega procesa upravljanja dostave končnega izdelka. Zvonimir Križ iz PBZ-a je predstavil zapiske iz prvih vrst agilnega bojišča, pri čemer je posredoval izkušnje retrospektive sprinta metode scrum iz enega izmed svojih projektov. Na konferencah pogosto nimamo priložnosti za daljše, temeljitejše in številčnejše pogovore o temi, ki nas zanima, zato smo se tokrat odločili to spremeniti. Zadnji del konference smo rezervirali za razpravo o obliki Open Space, ki jo je vodila Jasmina Nikolić iz Ministrstva za izobraževanje, znanost in tehnološki razvoja Republike Srbije. Reakcije udeležencev so bile odlične in prepričani smo, da bomo na naslednji konferenci QED odprli še več prostora za interakcije. Konferenca QED je bila popolna kombinacija dela in užitka. Poglobili smo se v zelo zanimive in aktualne teme, pri tem pa uživali v neverjetni gostoljubnosti – hrana in pijača sta bili več kot izvrstni, kopališče je bilo vrhunsko, zabavali in smejali smo se v ogromnih količinah. Imel sem vtis, da je konferenca družinski skup ustvarjalnih mislecev. Resnično sem užival in upam, da bom znova gost te konference. Niklas Modig Stockholm School of Economics avtor knjige “This is lean“
32. 32 | FYI by CROZ / oktober 2014 Odnos artefaktov v procesu zbiranja zahtev Focal Point Business Project HL Requirements Prioritizing ... RRC Project A Project A Project B Project B Project C Project D Project D + new requirements + new requirements New product Product 1 Product 2 Product 2.2 Product 3 Product 4 Requirement 1 Requirement 2 Requirement 3 Requirement 4 Projects Products Master Project HL Requirements HL Requirements HL Requirements projektne zgodbe | RRC in RQM v Iskratelu Razvojni cikel 2.0 Napredne tehnike zbiranja zahtev in nadzora kakovosti končnega izdelka niso nujno povezane zgolj z razvojem programske opreme, kar kaže tudi naša projektna zgodna iz Iskratela. Piše: Davor Čengija Slovenska družba Iskratel je ena izmed vodilnih svetovnih družb za proizvodnjo opreme in imple- mentacijo popolnih, integralnih telekomunikacijskih rešitev. V več kot 60 letih obstoja so se profilirali kot razisko- valno-razvojna pa tudi proizvodna družba, katere znanje in izkušnje uporabljamo praktično vsak dan, ne da bi o tem sploh razmišljali – preprosto dvignemo slušalko ali vzamemo mobilni telefon v roko in zavrtimo številko; naš klic je nekje na svoji poti skoraj zagotovo šel skozi kos opreme, ki je v bil celoti izdelan v Kranju v Sloveniji. Morda pa tudi v Rusiji, Ukrajini, Kaza- hstanu ali Makedoniji? Iskratel je namreč globalna družba s tisoč zaposlenimi v 20 državah, ob Sloveniji sta pa prav Rusija in Makedonija središči, v katerih oblikujejo in ustvarjajo rešitve: od širokopasovnih sistemov, prek hišnih modemov in me- dijskih centrov, vse do celovitih rešitev za komunikacijo med različnimi uporabniki na podlagi klicnega strežnika najnovejše generacije. Več o tem si lahko preberete na spletni strani www.iskratel.com. Slišati je vzpodbudno, da se taka družba iz sosedne države upira daljnovzhodnim izdelovalcem, vendar to hkrati pomeni, da mora Iskratel izstopati po kakovosti izdelkov, pa tudi hitrosti pretvorbe zamisli v končni izdelek. orodja za upravljanje testiranja, so ključne točke pri tej pobudi. Programska oprema, strojna oprema in vse vmes Sistemi za odpravnike v železniškem prometu ali širokopasovne centrale ne nastanejo čez podaljšani konec tedna: omejitve poleg dolgega razvojnega določajo tudi različni regulativni organi, ki višajo pogoje za dostop do tržišča. Konkurenčnih družb je vedno več, nekatere so vrhunske na svojem področju, druge, ki so sorazmerno maloštevilne, so resnično velike globalne družbe, ki delujejo na sorazmerno omejenem prostoru. Poleg tega se je spremenil tudi način, kako trg dojema dobavitelje: dostave novih različic pričakujejo ne samo enkrat na leto, ampak skoraj vsako četrtletje, število izdelkov se je nekajkrat povečalo, predvsem s kombiniranjem manjših celot v pakete, zahteve so postale tako spremenljive in inovativne, da jih imenujemo premične tarče. Klasični kaskadni razvojni cikel očitno ni več dovolj dober; ni časa, ljudi in virov za razvijanje internih aplikacij za podporo procesom, vse je stisnjeno in vidno hitreje ter bolj intenzivno kot v prejšnjih letih. Nikar ne mislite, da je stanje v Iskratelu tako grozno: vendar gre za zelo uspešno družbo, ki spremlja stanje na trgu in konkurenco, in ki je prepoznala potrebo po notranjih izboljšavah, da bi končni izid bil bolj gotov in uspešen. RRC in RQM na pomoč! Večina poslovnih potreb začenja svoj življenjski cikel kot besedilo – v prosti obliki na listu papirja, morda nekoliko strukturirano v elektronski pošti ali podrobno razčlenjeno glede na strogo opredeljene obrazce v Wordu. V Iskratelu Poleg uvajanja aplikacij Rational Requirements Composer in Rational Quality Manager v proizvodni proces, vlagamo veliko naporov tudi v agilizacijo samega razvoja z uvajanjem SCRUM-a kot metodologije razvoja. Usklajevanje poslovnih zamisli s potrebami trga, pospeševanje opredelitve priložnosti in izdelkov, kakovostno prepoznavanje in zbiranje implementacijskih zahtev ter vsekakor vrhunska kakovost dostavljenih izdelkov ter storitev so edini način obstoja v tem poslu. Projekti uvajanja aplikacij IBM Rational Requirements Composer (RRC), okolja za upravljanje poslovnih zahtev, in IBM Rational Quality Manager (RQM),
33. FYI by CROZ / oktober 2014 | 33 Slobodan Jovanovski Iskratel d.o.o. (direktor Upravljanja izdelkov) Izbrali smo IBM, ker ponuja vrhunsko platformo, ki pokriva celoten razvojni cikel. Začeli smo korak po korak, pri tem pa smo zajeli predvsem segment zbiranja in analize zahtev. Pričakujemo, da bo rešitev integrirana z obstoječimi sistemu v Iskratelu in da se bo med uporabo postopoma spremenila. CROZ je preverjen partner za implementacijo omenjenih rešitev, vendar tudi za dostavo najboljših praks pri uporabi RRC-a in RQM-a. To pomeni, da od projekta poleg namestitve in konfiguracije programske opreme pričakujemo tudi izboljšanje naših internih procesov, povezanih z analizo zahtev in nadzorom kakovosti končnega izdelka. Načrtujemo nadaljevanje sodelovanja tudi na področju uvajanja načina razmišljanja lean, ne samo pri razvoju, ampak tudi v poslovnem segmentu. Veste, kako pravijo: z agilizacijo razvoja dosežete, da razvojne skupine zelo dobro opravljajo svoje delo - treba je samo še zagotoviti, da delajo ”pravo stvar”, kar je naš cilj v naslednjem obdobju. RRC in RQM v Iskratelu | projektne zgodbe smo imeli situacijo, kjer so poslovni analitiki pozorno obdelovali funkcionalne in nefunkcionalne zahteve, pri čemer so kombinirali že obstoječa gradiva z novonastalimi, tako izdelano knjigo aktivnosti pa so posredovali naprej v razvoj. sestavljen iz več izdelkov, ali je obratno? Kako pa je z različicami? Kako na koncu vemo, da je posamezna poslovna funkcionalnost implementirana prav v tem izdelku, v sklopu tega projekta? IBM Rational Requirements Composer (RRC), kot del širše platforme Jazz, uporabnikom, predvsem poslovnim analitikom, zagotavlja strukturirano kolaboracijsko okolje za opredeljevanje in upravljanje zahtev. Z drugimi besedami prek zelo sodobnega in intuitivnega vmesnika, samo s spletnim brskalnikom lahko več analitikov hkrati dela na opredeljevanju poslovnih zahtev, kar je pri delu z dokumenti brez povezave razočarljivo zapleteno. Ker je s stališča RRC-a vsaka zahteva v bistvu tudi poseben in neodvisen artefakt, ki gre skozi določeno zaporedje korakov od nastanka do dostave, smo dobili okolje za kombiniranje teh zahtev v širše dokumente – podrobne specifikacije – z možnostjo revidiranja, odobritev in spremljanja različic. To so hkrati tudi osnovne projektne naloge: prepoznavanje optimalne konfiguracije procesov zbiranja in analize poslovnih zahtev, izboljšanje komunikacije med analitiki in razvojnimi skupinami in varčevanje časa na spremljajočih aktivnostih, kot je ustvarjanje dokumentacije, pri tam pa spoštovanje kulture ter specifičnosti podjetja. Ni treba posebej poudarjati, da je Iskratelova skupina ves čas trajanja projekta bila zelo konstruktivna – zavedali so se, da tako kritični procesi ne smejo priti od zunaj, pač pa da morajo nastati znotraj in biti izdelani po meri. Po drugi strani se aplikacija Rational Quality Manager uporablja na samem koncu procesa, v fazi testiranja. Seveda bi izoliranje testiranja bilo usodno za kakovost končnega izdelka, zato smo pri projektu predvideli neposredno povezovanje poslovnih zahtev, izvirne kode in testnih primerov, oziroma skript. RQM na srečo omogoča dokaj preprosto integracijo z obstoječo rešitvijo (Remedy), tako da bo na koncu te faze projekta mogoče spremljati eno funkcionalnost od nastanka, oziroma opredelitve zahteve, prek razvoja, vse do testa, ki potrjuje pravilnost implementacije. Kako naprej? V Iskratelu se zavedajo, da zgolj uvedba orodja v razvojni proces ne zagotavlja uspeha. Nujna je sprememba drže in pristopa, to pa je natanko to, kar sem kot vodja projekta opazil: željo po boljšem in učinkovitejšem procesom uresničevanja poslovnih zamisli s pomočjo najboljših orodij, ki so trenutno na voljo na trgu. Dobro je, da spodbuda za izboljšave prihaja od znotraj, iz samega osrčja družbe, ker brez trdnih temeljev v razvojnem segmentu tudi najboljša zamisel ne bo uspešna. V naslednji fazi projekta nadaljujemo s širjenjem dobrih vibracij, uvajanjem agilnih metodologij razvoja. ”If it compiles, it is good; if it boots up, it is perfect.” Sporočilo Linusa Torvaldsa razvojni skupini Linuxa 1998. Tak tradicionalni pristop za seboj potegne nekaj težav, ki so v neposrednem navzkrižju z željo po hitri dostavi izdelka, prilagojenega konkretnemu uporabniku. Spremljanje implementacije določene poslovne funkcionalnosti je prav tako zelo zapleteno in omejeno na administrativno delo, kar nikomur seveda ni ljuba dejavnost. Pri takšni količini ročnega dela samo na vzdrževanju dokumentacije, se seveda ”razvodeni” zavzetost, vemo pa, kako to vpliva na končni izdelek. (Namig: ne preveč dobro A) Na začetku smo morali razjasniti odnose med artefakti pri poslovni analizi: kaj je izdelek, kaj pa projekt? Je projekt
34. 34 | FYI by CROZ / oktober 2014 Integracija platforme IBM Connections in grafnih zbirk podatkov Platforme za družabna omrežja postajajo vedno pomembnejše v poslovnem okolju in uporablja jih vedno več organizacij, medtem ko priljubljenost grafnih zbirk podatkov narašča in pri teh zbirkah podatkov se pojavljajo vedno nove oblike uporabe. Kaj dobimo, če poskusimo združiti to dvoje? tehnologije in trendi | Integracija platforme IBM Connections in grafnih zbirk podatkov Z integracijo platforme IBM Connections in grafne zbirke podatkov je nastavljena vstopna točka v platformo, ki omogoča strnjen in jedrnat pregled celotne organizacije ter preprosto in hitro identifikacijo delov s povečano aktivnostjo. Grafi v javnih družabnih omrežjih V velikih javnih družabnih omrežjih (Facebook, Twitter, LinkedIn itd.) obstajajo številni bolj ali manj uspešni poskusi prikaza podatkov v obliki grafa. Za Facebook in Twitter obstajajo številne zunanje aplikacije, ki lahko prikažejo graf prijateljev/ followerjev in njihovo medsebojno povezanost. Najdlje je morda šel LinkedIn s projektom LinkedIn Maps (http://inmaps.linkedinlabs.com/), ki ga razvijajo v lastnem laboratoriju. Ob samem prikazu grafa se povezave uporabnikov samodejno razvrščajo v skupine, na voljo pa je tudi možnost poljubnega imenovanja nastalih skupin. Pišu: Dino Blažeka in Matija Folnović Skupnost znotraj platforme IBM Connections IBM Connections je ena izmed vodilnih platform za družabna omrežja v orga- nizacijah, s katero je mogoče povečati kohezijo znotraj organizacije, kar je najbolj izraženo v večjih organizacijah, kjer je odtujenost med zaposlenimi velika in pogojena z razpršenostjo organizacije ter številom zaposlenih. Z njeno uporabo se poveča tudi pretok informacij znotraj organizacije, kar izboljša informiranost zaposlenih o trenutnem stanju znotraj organizacije in spoznavanje sodelavcev ter njihovih pristojnosti, kar poveča učinkovi- tost poslovanja. Platforma IBM Connections je sestavljena iz nekaj medsebojno povezanih aplikacij:  Communities – oblikuje skupnost zaposlenih, ki jih združujejo isti interesi;  P rofiles – profil vsakega posameznega zaposlenega ali organizacijske enote;  Blogs – omogoča posredovanje projektnih izkušenj, zamisli ipd. v skupnosti;  Ideation Blog – prostor za izmenjevanje zamisli, omogoča glasovanje in komentiranje zamisli;  Files – omogoča posredovanje datotek znotraj organizacije;  Forums – platforma za razprave;  Wikis – podpira izmenjevanje znanja znotraj organizacije;  Activities – spremlja in razporeja aktivnosti znotraj organizacije. Skupnosti (angl. communities) so osnovna entiteta znotraj platforme IBM Connections. Vsaka skupnost ima svoje člane, oziroma združuje ljudi s skupnimi interesi. Vse druge aplikacije se naslanjajo neposredno na skupnost, zato skupnost ima na primer lahko svoj Blog, Wiki ali Forum, na katerih člani med seboj izmenjujejo informacije. Intenzivna in dolgotrajna uporaba platforme IBM Connections v družbi CROZ je razkrila dele platforme, ki bi jih bilo treba izboljšati in tako olajšati njeno uporabo. Opazili smo pomanjkanje enotne vstopne točke v platformo, ki bi ob bežnem pogledu pokazala vpogled v trenutno stanje in opozorila na skupnosti, v katerih so aktivnosti povečane. S tem bi uporaba in navigacija znotraj platforme postali bolj preprosti. Preprostost uporabe platforme spodbuja njeno uporabo in povečuje relevantnost ter popolnost razpoložljivih informacij. Za doseganje takšne vstopne točke smo se odločili zagnati projekt integracije platforme IBM Connections in grafne zbirke podatkov, s kateri bi podatke prikazali v obliki jedrnatega grafa z možnostjo izvajanja dodatnih analiz podatkov.
35. FYI by CROZ / oktober 2014 | 35 Integracija platforme IBM Connections in grafnih zbirk podatkov | tehnologije in trendi Arhitektura integracije platforme IBM Connections in grafnih zbirk podatkov Prikaz grafa kot vstopne točke v platformo IBM Connections in aktivnosti od zadnjega obiska – skupnosti, zamisli in komentarji z aktivnostjo od zadnjega obiska so označeni z rdečim robom. Grafne zbirke podatkov Kot smo pisali v prejšnji številki, grafne zbirke podatkov v zadnjem času postajajo vedno bolj priljubljene iz različnih razlogov, na primer zaradi podpore veliki količini podatkov, lažjega razvoja in hitrosti poizvedb. Glavna razlika glede na klasične relacijske zbirke podatkov je njihov podatkovni model - graf. Značilno uporabo grafnih zbirk podatkov lahko vidimo v družabnih omrežjih: nekatere med največjimi imajo svoje implementacije grafnih zbirk podatkov, specifičnih za svoje potrebe. Na primer Twitter uporablja svojo grafno zbirko podatkov FlockDB za shranjevanje povezav med uporabniki (kdo sledi komu). Obstajajo tudi druge oblike uporabe, kot so sistemi za delo z geolokacijskimi podatki, sistemi priporočil (recommendation systems) itd. Cilj projekta Za potrebe tega projekta smo se odločili na grafu prikazati aktivnosti iz Ideation Bloga, ki omogoča izmenjevanje zamisli med člani skupnosti na platformi IBM Connections. Rešitev družbe CROZ za upravljanje idej LIKE MY IDEA (www. likemyidea.com) je zgrajena predvsem okoli Ideation Bloga, zato je to bila odlična priložnost, da vidimo, kako se ti dve rešitvi vedeta pri vzporednem delovanju. Za prikaz aktivnosti iz Ideation Bloga smo se odločili tudi zato, ker uporabniki platforme IBM Connections hitreje posredujejo povratne informacije avtorju zamisli, če imajo boljši pregled nad novimi aktivnostmi in zamislimi. Na takšno hitro povratno informacijo se avtor lahko odzove s spremembami in izboljšavami, kar poveča skupno kakovost zamisli, ki jih odda prek platforme IBM Connections. Implementacija Odločili smo, da bomo podatke, ki jih zberemo prek platforme IBM Connections, shranili v grafno zbirko podatkov, ker tako dobimo osnovo za učinkovito izvajanje poizvedb, katerih rezultate potrebujemo za prikaz grafa, kar je hkrati tudi najbolj naravna oblika shranjevanja tovrstnih podatkov. Da bi to dosegli, smo uporabili obstoječi sistem globalnih dogodkov, ki ga zagotavlja platforma IBM Connections, kot so dogodki ”ustvarjena je skupnost”, ”ustvarjena je ideja”, ”oddan je glas za idejo” itd. Sistemu smo dodali možnost posredovanja omenjenih dogodkov zunanjim sistemom prek najugodnejših protokolov za vsak posamezen sistem. S to razširitvijo smo omogočili izdelavo zunanjih sistemov, ki uporabljajo neposredni prenos podatkov iz platforme IBM Connections. To položaj smo izkoristili tako, da smo izdelali sistem, ki sprejema dogodke iz platforme IBM Connections, iz njih vzame potrebne podatke in jih posreduje naprej sistemu, ki jih shrani v grafno zbirko podatkov, v strukturo, ki je primerna za prikaz v obliki grafa, ne glede na to, katero grafno zbirko podatkov uporabimo. Vizualizacija podatkov Vmesnik prikazuje graf, ki je sestavljen iz več vozlišč:  skupnost,  zamisel,  komentar,  uporabnik,  glas. Povezanost vozlišč na zelo intuitiven način prikazuje strukturo skupnosti (community), njihovih zamisli, komentarjev in glasov o zamislih. Pred implementacijo te rešitve smo za dostop do istih podatkov potrebovali veliko krmarjenja skozi platformo. Pri tej vizualizaciji zadostuje pogledati graf in večina pomembnih podatkov o zamislih je na voljo brez enega samega premika miške. Skupnosti, v katerih je bila opravljena aktivnost od zadnjega obiska platforme, so označene z rdečim robom. Če razširimo vozlišče te skupnosti, so označene nove zamisli, glasovi in komentarji ter njihovi avtorji. Načrti za prihodnost Implementacija te rešitve je pokazala, da je kombinacija grafne zbirke podatkov in družabnega omrežja zelo naravna, celo zaželena. V prihodnosti načrtujemo razširitev funkcionalnosti rešitve, s katero bomo zajeli vse aplikacije platforme IBM Connections in implementirali predhodno določene poizvedbe v zbirki podatkov, ki bi bile osnova za podrobne analize organizacije z družabnega vidika.
36. CROZ na novem trgu: uspešen projekt v Albaniji Evropska banka za obnovo in razvoj (EBRD) je financirala izgradnjo informacijskega sistema za podporo delovanja Albanske agencije za zavarovanje vlog (ADIA). Na mednarodnem razpisu je zmagala družba CROZ skupaj z dvema albanskima družbama. • Albanci odkimajo z glavo kot znak potrditve (pravzaprav nagnejo glavo na eno in nato na drugo ramo brez obračanja vratu A) • Med petdesetletno vladavino komunizma je bilo zgrajenih več kot 700.000 bunkerjev – po eden na vsake štiri prebivalce, ali neverjetnih 24 bunkerjev na kvadratni kilometer. Nekatere danes uporabljajo v turistične ali gostinske namene. • V albanščini beseda shqiptar pomeni Albanec, Shqipëria je ime za Albanijo, obe besedi pa po nekaterih virih imata korenine v besedi shqipe, kar pomeni orel, in je nacionalni simbol (ki je nekje vmes zaradi drugih razlogov dobil dve glavi). Po drugih virih pa obe besedi izvirata iz besede shqip, ki pomeni ”medsebojno razumevanje”. • Albanščina je eden izmed najstarejših jezikov na svetu in ne pripada nobeni skupini jezikov znotraj indoevropske družine – je samostojen in edinstven jezik. Po vsem svetu ga govori približno 8 milijonov ljudi. Albanija za radovedne • Skenderbeg ni samo priljubljen konjak, je tudi nacionalni heroj in zelo zanimiva zgodovinska osebnost. Za Albance je pomemben, ker je Albanijo uspešno obranil pred trinajstimi osmanskimi invazijami. Po njegovi smrti so Turki osvojili Albanijo in v njej vladali štiri stoletja. Spomenik tem albanskem heroju lahko najdete marsikje po svetu: v Rimu, na Dunaju, v Ženevi, Parizu, Bruslju, Prištini in Skopju. • Albanci najbolj ponosni na Mati Terezo. 19. oktober, dan njene beatifikacije, je v Albaniji nacionalni praznik. Osnovna dejavnost Albanske agencije za zavarovanje vlog (ADIA) je zavarovanje vlog vseh strank bank, hranilnic in drugih ustanov v primeru, da te propadejo. Naj- večji znesek za zavarovane vloge v Albaniji znaša 2.500.000 lekov ali približno 18.000 EUR, medtem ko je na Hrvaškem 100.000 EUR. V zadnjih letih je tudi hrvaška Državna agencija za zavarovanje hranilnih vlog in sanacijo bank (DAB) v nekaj primerih izplačala vloge strankam propadlih bank. Delo je bilo opravljeno v izjemno kratkem roku, brez pretiranega razburjenja varčevalcev ali javnosti, kar v bistvu prispeva k ohranjanju stabilnosti celotnega finančnega sistema države in zaupanja varčevalcev v institucije, ki jih na ta način ščitijo. Pomen obstoja dobrega informacijskega sistema je v takšnih primerih očiten. Med našim obiskom v Albaniji smo kolegom iz ADIA-e zagotovili obisk pri hrvaški agenciji in tako omogočili izmenjevanje izkušenj. S poslovnega stališča sistem, ki smo ga razvili, omogoča ADIA-i zbiranje podatkov o vlogah strank pri bankah in drugih finančnih ustanovah po elektronski poti skozi varne kanale. Tako zbrani podatki se uporabljajo za več nalog, ki jih ADIA izvaja in za katere je pooblaščena: • zavarovanje vlog (te podatke uporablja za izračun premije zavarovanja za posamezno finančno ustanovo), • nadzor dela finančnih ustanov (takšni podatki se uporabljajo tudi za raziskovanje in ugotavljanje morebitnih nezakonitih dejanj ali nezakonite pridobitve denarja), • izplačilo zagotovljenih sredstev v primeru propada finančne ustanove, ki je v njeni pristojnosti. Informacijski sistem ADIA-e je sestavljen iz nekaj modulov, ki omogočajo izvedbo navedenih opravil in podporo poslovnim procesom: od zbiranja podatkov, obračuna premije zavarovanja, priprave in analize podatkov za izvedbo nadzora, do ustvarjanja datotek s podatki za izplačilo. Projekt je trajal eno leto. V tem obdobju je skozi nekaj faznih dostav bila izdelana natančna specifikacija zahtev in poslovna analiza, izdelan je bil sistem z vsemi varnostnimi pravili, izvedeno pa je bilo tudi testiranje na vseh bankah v Albaniji. Zagon sistema v produkcijsko vsakodnevno delo je predviden jeseni. Partnerji pri projektu Družba CROZ je na projektu imela vlogo vodje projekta v imenu konzorcija in glave odgovorne osebe za realizacijo projekta v imenu EBRD. Pri projektu smo nastopili tudi kot svetovalci za metodologijo, kjer so naša znanja in izkušnje pri vodenju tako velikih ter pomembnih projektov bila še kako pomembna. Bili smo zadolženi za zagotovitev kakovosti pri izvedbi celotnega projekta: od revizije kakovosti funkcionalnih specifikacij in pregleda kode, do sodelovanja pri pripravi testiranja pri bankah. Med projektom smo imeli priložnost pokazati svoje izkušnje pri razvoju finančnih sistemov in pomagati pri uporabi varnostnih ukrepov na sistemu. Poleg CROZ-a je pri delu projekta, ki se je nanašal na poslovno svetovanje, sodelovala tudi hrvaška družba Dialog, največji del razvojnih aktivnosti pa sta Eden izmed bunkerjev Piše: Izabela Kolarić 36 | FYI by CROZ / oktober 2014 projektne zgodbe | Uspešen projekt v Albaniji
37. Albanska agencija za zavarovanje vlog je prosila Evropsko banko za obnovo in razvoj za tehnično pomoč pri oblikovanju, razvoju in implementaciji sistema, ki bi zagotovil zbiranje podatkov ter poročanje. Da bi agencija lahko zavarovala vloge v primeru propada bank, smo potrebovali sistem, ki je skladen z najboljšimi mednarodnimi standardi. Julija 2013 je projekt dodeljen konzorciju treh uglednih družb, ki so ves čas sodelovale z agencijo ADIA, in so avgusta 2014 dostavile končan ter zanesljiv sistem. Konzorcijski partnerji na tem projektu, Facilization, Communication Progress in CROZ, so bili zelo profesionalni in so odlično opravili zastavljeno delo, mi pa smo zelo zadovoljni z rezultati. Vse pogodbene zahteve so bile izpolnjene pravočasno in skladno z najvišjimi kakovostnimi standardi. Ta projekt je bil za nas prava sinergija znanja, strokovnosti, komunikacije in skupnega dela. Banke so nedavno uspešno izvedle pilotsko testiranje in poročila kažejo, da je sistem skladen z zahtevami IT-sistema agencije ADIA. Sistem je pripravljen za produkcijo, sedaj čakamo samo še poslovno odločitev. Erita Skendaj Albanska agencija za zavarovanje vlog (vodja projektov) Zgradbe v Tirani, prebarvane med kampanjo Give Me the Colours opravili dve albanski družbi: Facilization shpk in Communication Progress shpk. Druženje in delo s kolegi sta za nas predstavljali zelo prijetno izkušnjo: njihova strokovnost in sistematičnost ter filozofija in pristop do dela sta na najvišji ravni, za veščine komunikacije i pogajanja pa smo jim podelili najvišje ocene. Facilization shpk (www.facilization. com) je družba, ki svoje storitve zagotavlja predvsem v bančnem in finančnem sektorju, večinoma na programski opremi Oracle, pa tudi na lastnih rešitvah. So vodilni partner družbe Oracle v Albaniji, zaposlujejo strokovnjake, ki se izobraževali po vsem svetu, in imajo bogate mednarodne izkušnje. Njihova naloga pri projektu je bila izved- ba celotne poslovne analize in sistematiza- cija zahtev, pa tudi testiranje sistema med iterativnim razvojem in v zaključni fazi te- stiranja pri bankah, ki sodelujejo v sistemu. Pri tem delu so bila njihova finančna znanja izjemno pomembna. Communication Progress shpk (www. commprog.com) je družba, ki se ukvarja z razvojem programske opreme in informacijsko infrastrukturo. Pri segmentu programske opreme so njihove rešitve zasnovane na tehnologijah in proizvodih družbe Microsoft, moramo pa omeniti tudi njihove kompetence pri OpenERP-u, pri katerem so edini partner v regiji. Njihova naloga pri projektu je bila tisto, pri čemer so najmočnejši: vzpostavitev strojne infrastrukture projekta in programske arhitekture ter zlasti razvoj same rešitve, ki je brez napake prestala vsa predvidena testiranja. Tirana gostitelj Albanija je danes dežela nasprotij: Tirana je videti kot sodobna zahodna prestolnica, v notranjost pa spremembe prihajajo počasi, vendar zanesljivo. Na nebu nad Tirano obrisi steklenih stolpnic in vrhovi sodobnih zgradb nasprotujejo starim monumentalnim zgradbam iz obdobja komunizma, blesk reklam in ulične razsvetljave pa kljubuje obrabljenim in nevzdrževanim pločnikom. Vrhunsko izobraženi sodobno oblečeni poslovneži s popolnim znanjem angleščine ali italijanščine so v nasprotju s tradicionalno opravo, ki jo je mogoče pogosto videti na ulicah. Bogati jedilni listi izvrstne gastronomske ponudbe so nas vse presenetili. Vse, kar vas obkroža, je ”nekje vmes”, a to je samo prvi in zunanji vtis, saj gre vse zagotovo v smeri ustvarjanja sodobnega mesta in sodobne države. To ni več dežela bunkerjev (glejte okvir), ampak dežela, v katero se otroci izseljencev vračajo z željo in voljo, da svoji domovini dajo najboljše, kar lahko ponudijo. Tirana je mesto, v katerem so v kampanji Give Me the Colours stare zgradbe obarvane v neverjetne barve, da bi prebarvali sivino komunističnih časov. Naši gostitelji nam povedo, da se je Tirana v zadnjih petnajstih letih nekajkrat povečala in da ena tretjina albanskega prebivalstva živi v Tirani. Promet je kaotičen, vendar samo navidezno, kajti nismo videli, da bi vozniki izgubljali živce. Pohupati z opozorilom ”Pazi! Grem mimo!” je povsem normalna stvar. Prvo, kar vas bo zjutraj prebudilo v hotelski sobi, je prav pogosto hupanje pod oknom. Dediščino zaprtosti in državne lastnine bo še dolgo čutiti na vseh ravneh družbe in življenja, vendar pridni in ambiciozni ljudje najdejo način za spremembe. Po resnično posebnih izkušnjah na tem projektu sem v to trdno prepričana. FYI by CROZ / oktober 2014 | 37 Uspešen projekt v Albaniji | projektne zgodbe
38. 38 | FYI by CROZ / oktober 2014 tehnologije in trendi | tehnološki radar Piše: Mihael Sedmak Čeprav je morda nenavadno, bomo zaključek tokratnega radarja pos- tavili na začetek besedila. Namreč, takoj na začetku želimo poudariti, da je tokratna izdaja polna novosti in številnih premikov po radarju, z občasnimi popravki položaja, ki so nekatere tehnologije ohranili na radarju. Najprej bom izpostavil dva trenda, ki sta vidna v tej izdaji radarja: avtomatizacija infrastrukture in večfunk- cionalnost. Prvi trend, avtomatizacija infrastrukture (Infrastructure automation, Metodologije in tehnike) je viden v nekaj primerih na radarju, predvsem skozi Docker in Ansible (Platforme in orodja). Docker je platforma za distribucijo aplikacij skupaj z njihovimi izvršilnimi okolji. Je zelo priljubljen in omogoča izjemno hitro ustvarjanje dokončnih okolij z aplikacijami, ki so pripravljene za izvajanje, vse pa poteka pod nadzorom nekega orodja za neprekinjeno integracijo (če to želite). Ansible na vse to dodaja avtomatizacijo skoraj vsega, kar lahko najdete znotraj informacijske infrastrukture. Glavni značilnosti obeh platform, gre pa za poslovni platformi, ki sta pripravljeni za uporabo pri največjih informacijskih sistemih, sta odprtost in brezplačnost. Družba CROZ bo vsekakor poskušala vključiti ti dve rešitvi v svoje projekte. Drugi trend, večfunkcionalnost (skupine, osebe), je tudi viden v dveh primerih na radarju: No specialization in pri inverznem pojavu, I only do X. Skratka, specializacija članov skupine, ki je pogosto predmet spora v organizacijah, je osnova Tehnološki radar Tokrat smo že drugič A pripravili pregled tehnologij, ki jih skupine v družbi CROZ uporabljajo, imajo rade, jih preučujejo in opazujejo z enim očesom, pa tudi tehnologij, za katere mislimo, da bi jih bilo treba prezreti ali jih zamenjati z ustreznejšimi (sodobnejšimi, lažjimi za vzdrževanje) rešitvami. za nastanek organizacijskih silosov. Če se osredotočimo na nekaj drugega, na zadovoljitev potreb končnega uporabnika in na to, kako uspešno mu želimo dostaviti vrednost, silosi ne prispevajo k končnemu cilju, zato moramo poskušati zmanjšati specializacijo in ustvariti večfunkcionalne skupine ter vzgojiti večfunkcionalne inženirje. Programski okvirji in jeziki Programski okvirji in jeziki, katerih točke na radarju so potovale navzven, proti robu radarja, so Play, Akka in Scala. Ti premiki ne pomenijo, da ti okvirji in jeziki niso kakovostni ali uporabni – ravno nasprotno. To samo pomeni, da jih v CROZ-u nismo veliko uporabljali, ali da ne vidimo široke uporabnosti v kontekstu projektov, ki jih izvajamo skupaj z uporabniki. Še vedno so v pasu ocenjevanja: če se odpre širše področje uporabe, bodo vsekakor v prvem planu tudi na radarju. Treba je omeniti tudi pojavljanje koncepta OSGi na samem robu radarja. OSGi je konceptualno veliko obljubljal, uporablja se pri implementaciji aplikacijskega odjemalca WebSphere, vendar njegova zapletenost preprečuje širšo in lažjo uporabo. Platforme in orodja Najzanimivejši postavki v tej kategoriji sta vsekakor skoka dveh tehnologij – Neo4J in Gradle – ki sta skočili v področje uporabe pri projektih. Neo4J, najbolj izpostavljen predstavnik grafnih zbirk podatkov, svojevrstno skladišče za podatke NoSQL, ni več zgolj trend, pač pa tehnologija, ki lahko pri številnih področjih uporabe zamenja relacijske zbirke podatkov. Tehnologija, ki jo bomo pozorno spremljali je Structr, ki je povezan z Neo4J, in na njem tudi temelji. Gre za novo generacijo sistema CMS, ki zagotavlja neverjetno razširljivost in hitrost prikazovanja vsebin, na radarju pa se je kot novost znašel zelo blizu središča. Gradle je (sorazmerno) novo orodje za graditev, ki ga v CROZ-u vedno pogosteje uporabljamo pri projektih. Zaradi prednosti pred do sedaj standardnim Mavenom, prožnosti in dejstva, da graditvene datoteke temeljijo na programskem jeziku Groovy, ne pa na XML-u, ga priporočamo že zdaj. Metodologije in prakse Najpomembnejši novosti v tej kategoriji sta že omenjeni in opisani načeli Infrastructure automation ter No specialization. Med drugimi pojavi je treba omeniti Instant feedback. Kanban, kot metoda, s katero CROZ- ovci nadlegujejo vse, ki jih srečajo, ima eno bistveno lastnost - omogoča neprekinjene, neposredne povratne informacije pri razvojnem (ali katerem koli vizualiziranem) procesu. Taka oblika povratnih informacij je izjemno pomembna v intenzivnih okoljih, kot so CROZ-ove skupine, ki sodelujejo pri razvoju aplikacij. Ob drugih elementih metode Kanban (WIP limits, zlasti vizualizacija), Instant feedback prispeva k povečanju kakovosti izdelka, ki zapušča CROZ-ovo delavnico.
39. POMEN BARV UPORABITI PILOTIRATI OCENITI ZAMENJATI Novo na radarju Se približuje središču Se oddaljuje od središča tehnološki radar | tehnologije in trendi FYI by CROZ / oktober 2014 | 39 Apache Camel Clojure Play Akka Scala Ember Dart FreeMarker JSF JPA ClearQuest CoffeeScript Spray JSP BPEL GWT Deployit OrientDB TorqueBox OpenStack OpenShift Ansible JavaScript MVC Hawt.io Application as a service (Meteor, deployd) WebLogic MySQL Ant CVS WS-* Sbt Ivy TDD Instant feedback Kanban Infrastructure automation Continuous integration BDD Asynchronous/ Responsive architecture Model driven development Structured logging Immutable arhitecture CQRS Fully stateless architectures I only do X (X e { Java, CSS, JavaScript, SQL, ...}) Manual testing No requirements No performance tracking Waterfall Lean/Agile values, principles and methods Groovy JavaScript gradle Twitter Bootstrap Java extjs HTML5 Vaadin Spring Framework Thymeleaf Ruby Xtend React Less Sass AngularJS Swift Wro4j Python Google GO Rails Nashorn Lift Quartz OSGi Flex Apache Axis EJB2 Hadoop Cassandra Grails Solr Git Lucene Alfresco Selenium Maven WebSphere Liberty Profile Structr Puppet Chef NodeJs MongoDB Mercurial Vagrant Redis uDeploy Event sourcing Heroism Documentation inproprietary/binary formats No testing at all Apache Camel Spock D3.js Spring Boot Handlebar templates Django IntelliJ IDEA ElasticSearch/ Kibana/Logstash Responsive design NoEstimates Continuous delivery Continuous deployment Security/penetration tests as deliverable No planning Neo4J No specialization Docker rabbitmq Reactive Systems Everybody commits to same source tree WebSphere App Server < 8.5 Mobile "later"
40. Prebudite inovativnost