Page 1

ZNAČILNOSTI RAZVOJA INFORMACIJSKIH REŠITEV V TESNIH ČASOVNIH OKVIRIH Majda Šoro, Blaž Knafeljc IPMIT Ljubljana (Institut za Projektni Management in Informacijsko Tehnologijo), Kotnikova 30, 1000 Ljubljana majda.soro@ipmit.si, blaz.knafeljc@ipmit.si Povzetek Leta 2004 je potekala nadgradnja in integracija modula MJR s sistemom ISARR. Zaradi potrebe naročnika po hitri rešitvi informacijske podpore za izvedbo javnih razpisov je razvoj potekal v tesnih časovnih okvirih. Tveganje, da zastavljeni roki ne bi bili prekoračeni, je zahtevalo opustitev metodologij klasičnega razvojnega cikla informacijskih rešitev. Namen tega prispevka je prikazati metodološko rešitev – uporabo prilagojene agilne metodologije Scrum, katere določeni principi in načela so prispevali k zadovoljivi in pravočasni informacijski rešitvi. Abstract CHARACTERISTICS OF SHORT TIME APPLICATION DEVELOPMENT An upgrade and integration of the MJR module with system ISARR was implemented in 2004. A client's urgent need to solve an information support to carry out a public competition, demanded a quick development of the MJR module. In order not to exceed dead lines, methodologies of classic developmental cycle of information solutions had to be abandoned. The purpose of this article is to represent a methodological solution - the use of adapted agile Scrum methodology, the principles of which contributed to a satisfactory and timely solution.

1. UVOD Zaradi tendence po hitrih in hkrati kakovostnih rezultatih pri razvijanju informacijskih sistemov so klasični metodološki prijemi, ki procese razvoja informacijskih sistemov narekujejo do potankosti, vedno težje obvladljivi. Tako se kot alternativa težkim, natančno specificiranim, podrobnim ter »step by step« opredeljenim metodologijam vse bolj pojavlja želja po uporabi lažjih, prilagodljivejših in predvsem enostavnejših metodologij. Temelji tovrstnih, t.i. agilnih metodologij, so bili postavljeni decembra 2001, ko se je sestala skupina, združena v zvezo AgileAlliance. Člani skupine so podali štiri načela, ki veljajo za agilne metodologije: ƒ Posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja. ƒ Delujoča programska oprema je pomembnejša kot popolna dokumentacija. ƒ Vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi pogodb. ƒ Upoštevanje sprememb je pomembnejše od sledenja planu. Agilne metodologije tako spodbujajo hitro vidne rezultate, odzivnost na spremembe, osredotočenost na prioritetne naloge, izvajanje rednih kontrol ter zavedanje znanja v organizaciji. Treba je poudariti, da pojem agilnost ne pomeni hitrosti razvoja na račun kakovosti ali minimalnega opisa procesa. Je le zmožnost organizacije, da se ustrezno prilagaja spremembam v okolju ter zahtevam tega okolja. Cilj uporabe agilnih metodologij je skrajšanje časa, znižanje stroškov in povečanje fleksibilnosti razvoja in implementacije ob pogoju, da implementirana informacijska rešitev uspešno in kakovostno deluje.

349


V okviru agilnih metodologij, ki združujejo več vrst tako imenovanih lahkih metodologij (npr. XP-Extreme Programming, FDD-Feature-Driven Development, Crystal itd.) se je kot najbolj primerna za uporabo pri konkretnem projektu pokazala prilagojena metodologija Scrum. V nadaljevanju prispevka bodo podana teoretična izhodišča uporabljene metodološke rešitve, kasneje pa bo na podlagi praktičnega primera predstavljen potek in rezultati uporabe principov Scrum, ki so bili privzeti v okviru projekta nadgradnje in integracije Modula za izvedbo javnih razpisov (v nadaljevanju modul MJR). 2. AGILNA METODOLOGIJA SCRUM Na prvem mestu je treba poudariti, da se metoda Scrum uporablja za vodstveni, in ne razvojni proces. Scrum je opredeljen kot hiperproduktivna metoda, ki naj bi za razliko od težkih metodologij dramatično povečala produktivnost v timu. Je empirična tehnika vodenja, za katero je realnost pomembnejša od načrtov, potrebno je nenehno sodelovanje, zaupanje v ljudi in napredek. Metoda združuje vse predhodno naštete skupne lastnosti agilnih metodologij, njena posebnost pa je organizacija ter izvajanje vodenja in hkrati obvladovanje projektnega tima. Uporaba Scrum metode temelji na realizaciji realno mogočega, dnevnega preverjanja napredka in pogostih korektur. Bistvo so majhni projektni timi (do deset ljudi), serija 'sprintov' (eden do štirje tedni), vidne in uporabne nadgradnje ter časovno omejevanje. Vloge v projektnem timu Scrum so razdeljene po naslednjem principu: ƒ ScrumMaster (vodja projekta). ƒ Tim strokovnjakov. ƒ Lastnik izdelka. Med 'sprintom' se izvajajo redni, pogosti in kratki Scrum sestanki. Kratke (od 15 do 30 minut) sestanke vodi ScrumMaster, prisotni so vsi člani projektnega tima, ScrumMaster ima za vsakega pripravljena tri vprašanja: ƒ Kaj si naredil/a od zadnjega Scrum sestanka? ƒ Kaj te ovira pri delu? ƒ Kaj boš delal/a do naslednjega Scrum sestanka? Ob koncu 'sprinta' se skliče statusni sestanek z vsemi vpletenimi, predstavijo se nadgradnje, pridobljene izkušnje in spremembe ter dodelijo nove naloge in prioritete za naslednji 'sprint'. 3. NADGRAJEN IN INTEGRIRAN MODUL MJR 3.1. Predstavitev modula MJR Leta 2004 je potekala nadgradnja in integracija aplikacije URANUS s sistemom ISARR. Zaradi integracije aplikacije URANUS s sistemom ISARR ter pomembne vsebinske skladnosti obeh rešitev se je kasneje aplikacija URANUS preimenovala v modul MJR, ki predstavlja sestavni del sistema ISARR. Modul MJR je bil razvit kot celovita podpora postopkom podeljevanja javnih sredstev, prilagojenim za izvajanje Programa pobude Skupnosti INTERREG v okviru Agencije za regionalni razvoj in podpora postopkom podeljevanja pomoči, ki se izvajajo na Agenciji Republike Slovenije za kmetijske trge in razvoj podeželja. V okviru projekta nadgradnje so bile odpravljene določene omejitve, hkrati pa so bile dodane nove funkcionalnosti in vsebine, ki jih obstoječa aplikacija URANUS ni podpirala. Pomembna komponenta, ki je vplivala na koncept nadgradnje, je bila zahteva po odprtosti in prilagodljivosti rešitve, ki bi ob 350


minimalnih spremembah aplikacije omogočala njeno uporabo tudi v drugih organih javnega sektorja. 3.2. Potek nadgradnje in integracije modula MJR Potek nadgradnje in integracije modula MJR se je pričel izvajati na podlagi predstavitve aplikacije URANUS naročniku. Organizirane so bile delavnice, preko katerih se je pridobila vsebinska podlaga in se zajele vse zahteve po informatizaciji postopkov izvedbe javnih razpisov. Zahteve so bile zapisane v dokument Specifikacija zahtev in se kasneje ponovno uskladile. Ob kasnejši analizi izdelane specifikacije so se kot odločujoči dejavniki, ki jih je potrebno upoštevati pri nadgradnji, pokazali: 1. Časovni rok Potreba naročnika po hitri izdelavi informacijske podpore za izvedbo javnih razpisov je zahtevala nadgradnjo in integracijo celotnega modula v dobrih treh mesecih, ki naj bi potekala vzporedno z dejanskim potekom izvajanja razpisov na Agenciji za kmetijske trge in razvoj podeželja. 2. Vsebinske zahteve Zahteva naročnika je v specifikaciji opredeljevala več vsebinsko različnih sklopov. Posledično je to pomenilo, da bo nadgradnja zelo obsežna in bo zahtevala več kot 90 odstotkov prilagoditev in popravkov. 3. Tehnološke zahteve Zaradi potrebe po novi razvojni tehnologiji in obsežnih vsebinskih sprememb oziroma prilagoditev je nadgradnja modula zahtevala opustitev razvoja na obstoječi tehnologiji ASP in se preusmeriti v razvojno tehnologijo ASP.NET. Vsebinsko je bila nadgradnja modula razdeljena na 4 faze (slika 1) 1. faza ƒ enosmerna povezava s sistemom ISARR, ƒ priprava razpisa, ƒ sprejem vlog, 2. faza ƒ odpiranje vlog, 3. faza ƒ pregled dopolnjenih vlog, ƒ preverjanje skladnosti vlog s pogoji razpisa, ƒ ocenjevanje vlog, 4. faza ƒ dvosmerna povezava s sistemom ISARR, ƒ sprejem in obravnava pritožb ter ƒ podpis pogodb.

351


Slika 1: Terminska opredelitev faz

Prva faza nadgradnje in integracije modula MJR je zaradi nezahtevnosti in neobsežnosti potekala po projektnem planu, v drugi fazi pa se je zaradi njene vsebinske preobsežnosti in izjemno kratkih rokov ter posledično vedno težjega obvladovanja in nadziranja celotne nadgradnje pojavila nujna potreba po uvedbi sprememb. Ugotovitev, da metodologija klasičnega razvojnega cikla ne zadostuje, je pripeljala do uporabe principov metode Scrum. Poudariti je treba, da se metoda Scrum načeloma uporablja za obvladovanje kriznih projektov na robu kaosa, in ne v urejenem (faznem) okolju, kot ga je predvideval plan projekta. Kljub temu se je že v drugi razvojni fazi pojavila potreba po vpeljavi določenih principov metodološke rešitve Scrum. 3. PRAKTIČNA IZHODIŠČA Projektni tim, ki je sodeloval pri nadgradnji in integraciji modula MJR je prevzel naslednje vloge: 1. Vodja projekta (ScrumMaster) v vlogi usklajevalca. Usklajevanja so potekala: ƒ Z naročnikom (sprejemanje strateških usmeritev in novih oziroma spremenjenih zahtev). ƒ Z uporabniki (pomoč uporabnikom, sprejemanje novih oziroma spremenjenih zahtev, sprejemanje vsebinskih in tehničnih napak). ƒ Z razvijalcem (nudenje vsebinske podpore, podajanje sprejetih zahtev, vodenje). Vodja projekta je izvajal tudi testiranja modula, nadzor nad izvajanjem aktivnosti in posledično nadzor nad potekom celotnega projekta. 2. Tim strokovnjakov v vlogi sistemskih analitikov in programerjev. Glavne naloge tima strokovnjakov so bile: ƒ Izvajanje sistemske analize (zasnova poslovne logike modula in njegove arhitekture). ƒ Sprejemanje vsebinskih zahtev in usmeritev s strani vodje projekta. ƒ Nadgradnja modula (kodiranje). 3. Lastnik izdelka v vlogi naročnika. Glavni nalogi lastnika izdelka sta bili: ƒ Podajanje novih oziroma spremenjenih zahtev in strateško usmerjanje projekta. 352


ƒ

Sponzoriranje projekta.

Vodenje je skozi celoten proces razvijanja modula potekalo preko sestankov. Namen sestankov so bili odgovori na odprta vprašanja, ki so se dotikala vsebine, analize trenutnih stanj projekta, pregled dosedanjega dela, ocene nadaljnjega napora, usmeritev projekta in strateških odločitev naročnika. Pobudnik za sestanke je bil v večini primerov vodja projekta, v kolikor je prišlo do vsebinskega pomanjkanja znanja je bila pobuda sestanka zahtevana s strani tima strokovnjakov. Sestankov so se udeleževali predstavniki celotnega projektnega tima. Glede na dejstvo, da je bilo izvedenih več vrst sestankov, so se predstavniki udeleževali tistih sestankov, ki so se nanašali na vsebine njihovega dela. 1. Vzpostavitveni sestanek Na pobudo vodje projekta je bil najprej izveden začetni, vzpostavitveni sestanek. Na sestanku je bila pregledana celotna specifikacija zahtev, ki se je kasneje tudi malenkostno spremenila in dopolnila. Vodja projekta je predstavil vsebino specifikacije, medtem ko je tim strokovnjakov postavljal pomembna vprašanja, ki so vplivala na kasnejšo logiko in zasnovo modula. 2. Fazni sestanki Projekt je bil ločen na preostale tri vsebinske sklope – sprinte, hkrati pa je vsak sklop predstavljal svojo fazo. Pred vsako fazo je vodja projekta predal podrobno vsebino in vse zahteve, ki so bile vezane na posamično fazo. Tako so se izvedli trije fazni sestanki, ki so bili vezani izključno na vsebino posamezne faze – izvajali so se vedno tik pred prehodom v naslednjo fazo. 3. Uskladitveni sestanki V času razvijanja posamezne faze so se redno in v odvisnosti od potreb (2 do 4 krat na teden) izvajali krajši uskladitveni sestanki, kjer se je odgovarjalo predvsem na odprta vsebinska vprašanja, opravljale so se določene usmeritve in prerazporeditve virov na projektu ter reševala morebitna druga smotrna vprašanja, ki so se dotikala projekta. 4. Sprotna komunikacija Vzporedno z vsemi tremi vrstami sestankov je vseskozi potekala komunikacija projektnega tima preko elektronske pošte, programa za »instant messaging« in izvedbe priložnostnih pogovorov in usmeritev na »hodniku«. 4. REŠITVE Na podlagi izvedenih praktičnih izhodišč opredeljujemo principe agilne metodologije Scrum, ki so pripomogli k uspešni konkretni rešitvi pravočasnega in kakovostnega razvoja informacijske rešitve. Priporočila oziroma praksa, ki se je izkazala za pozitivno in posledice vpeljave teh principov: 1. Izvajanje sprotnih kontrol ƒ Pogoste krajše analize trenutnega stanja projekta posledično pripeljejo do pravočasnih usmeritev projekta. ƒ Kontrole se izvajajo na Scrum sestankih. ƒ Redne kontrole omogočajo učenje, ko je še čas za korektivne ukrepe in izboljšave procesa. ƒ Izboljšave procesa so pravočasne in zahtevajo minimalni trud.

353


2. Pomen Vloge ScrumMasterja ƒ ScrumMaster usklajuje in vodi vse vpletene strani, organizira projektni tim. ƒ Zmanjšuje vidni obseg nalog. ƒ Čuti se pripadnost timu, ki v skrajnih razmerah lahko pripelje do tesnega sodelovanja. ƒ Zelo dobra odzivnost projektnega tima. 3. Razdelitev vlog in nalog v timu ƒ Vloge in naloge so razdeljene glede na strokovno usposobljenost in izkušnje posameznih članov. ƒ Vsak posameznik se zaveda svoje vloge in nalog ter v skladu s tem prevzema odgovornost za izvedbo. ƒ Zaupanje v delo sodelujočih v timu, ki so strokovnjaki na svojih področjih. ƒ Organizacija sestankov, na katerih vsak točno ve, kaj poročati in se predhodno pripravi, posledično optimizira sestanek v časovnem in podatkovnem smislu. 4. Sodelovanje strokovnjakov ƒ Na projektu so člani strokovnjaki in izkušeni na svojem področju, kar vpliva na hitrejši razvoj informacijske rešitve. ƒ Čas, potreben za uvajanje neizkušenih članov oziroma dodatnih virov za delo, se prihrani. 5. Vpletenost naročnika ƒ Komentarji naročnika se upoštevajo, ne ignorirajo. ƒ Organizacija sestankov, na katerih se obravnavajo zahteve in potrebe naročnika. ƒ Od naročnika se ne zahteva popolna analiza sistema že na začetku, kajti le-ti težko podajo abstraktno definicijo. ƒ Naročnik redno spremlja nastajanje izdelka (skozi nadgradnje), popravlja zahteve in komentira. ƒ Odnos med naročnikom in timom se razvija, dviga se zaupanje, znanje raste. 5. ZAKLJUČEK Metodologija Scrum je v primerjavi z ostalimi agilnimi metodami dokaj redko uporabljena tehnika. Prvenstveno se projektni timi odločajo za XP-Extreme Programming, FDD-Feature Driven Development, ASD-Adaptive Software Develpoment in DSDM-Dynamic System Development Method. Namen prispevka je bil predstaviti in predvsem izpostaviti prednosti, ki jih še relativno neznana metodologija vsebuje. Določeni principi metodologije Scrum so se v primeru nadgradnje in implementacije modula MJR s sistemom ISARR pokazali kot izvrstna rešitev. Ni nujno, da bodo načela metodologije primerna za vse razvojne informacijske rešitve, niti ni realno pričakovati, da bo uporaba vseh principov vedno smislena. Namen uporabe metodologije ni njen zapis in strogo sledenje načelom, ki jih zagovarja. Je zgolj vedenje, »know how«, ki ga je možno vpeti in preoblikovati v razvojni cikel na način, ki je njemu lasten in temu primerno učinkovit. 6. VIRI IN REFERENCE [1] BAJEC, Marko, KRISPER, Marjan: Agilne metodologije razvoja informacijskih sistemov, Uporabna informatika, 2003, 11(2), str. 68-76 [2] COMLAND d.o.o., Interna gradiva iz Baze znanja

354


[3] IPMIT, Interna gradiva iz Baze znanja [4] KRALJ, Miha, Scrum – upravlanje projektov na robu kaosa, NT konferenca 2004 [5] PEER, Peter: Dokumentiranje informacijske tehnologije, http://www.lrv.fri.uni-lj.si/~peterp/DIT/DIT2.pdf [6] RISING, Linda, JANOFF, Norman: The Scrum Software Development Process for Small Teams, http://members.cox.net/risingl1/articles/IEEEScrum.pdf

355

Znacilnosti razvoja  

Leta 2004 je potekala nadgradnja in integracija modula MJR s sistemom ISARR. Zaradi potrebe naročnika po hitri rešitvi informacijske podpore...

Read more
Read more
Similar to
Popular now
Just for you