Fakulteta za raˇ cunalniˇ stvo in informatiko Fakulteta za matematiko in fiziko
Ana Rovan
Situacijski pristop k oblikovanju agilne metode razvoja programske
opreme
DIPLOMSKO DELO
INTERDISCIPLINARNI UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN MATEMATIKA
Mentor : izr. prof. dr. Tomaˇ z Hovelja
Ljubljana, 2022
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
opreme
Vrsta naloge: Diplomska naloga na univerzitetnem interdisciplinarnemu programu prve stopnje Raˇcunalniˇstvo in matematika
Mentor: izr. prof. dr. Tomaˇz Hovelja
Opis:
Kandidatka naj pregleda relevantno literaturo o agilnem razvoju programske opreme s poudarkom na upoˇstevanju situacijskih dejavnikov. Na tej osnovi naj razvije lasten situacijski pristop k agilnemu razvoju programske opreme in razviti model empiriˇcno preveri v izbranem podjetju.
Title: Situational approach to designing an agile software development me- thod
Description:
The candidate should review the relevant literature on agile software deve- lopment with an emphasis on situational factors. On this basis, situational approach to agile software development should be developed and the develo- ped model empirically tested in the selected company.
podporo ter moji dragi prijateljici Mateji. Brez njih ne bi uspela dokonˇcati diplomskega dela.
Lektorica: Tea Adamlje
Povzetek
Abstract 1
1 Uvod 1
2 Pregled literature 3
2.1 Zgodovina . . . 3
2.2 Kljuˇcni modeli razvoja programske opreme . . . 10
3 Opredelitev situacijskega pristopa k agilnemu razvoju pro- gramske opreme elementov 27 3.1 Potencialni elementi . . . 28
3.2 Doloˇcitev anketnih vpraˇsanj . . . 30
3.3 Anketa . . . 32
3.4 Fokusna delavnica . . . 33
4 Studija primeraˇ 35 4.1 Predstavitev podjetja . . . 35
4.2 Predstavitev rezultatov . . . 36
4.3 Doloˇcitev agilne metode razvoja programske opreme . . . 38
4.4 Oblikovana agilna metoda razvoja programske opreme . . . 42 4.5 Predstavitev predloga vodstvu in povratna informacija vodstva 43
5 Zakljuˇcek 45
A Rezultati ankete 55 A.1 Ocena elementa . . . 55 A.2 Uˇcinkovita izvedba . . . 58
kratica angleˇsko slovensko PERT Program (Project) Manage-
ment and Review Technique
Tehnika upravljanja in pre- gledovanja programa (pro- jekta)
CPM Critical Path Method Metoda kritiˇcne poti IPMA International Project Mana-
gement Association
Mednarodno zdruˇzenje za projektni management PMI Project Management Insti-
tute
Zdruˇzenje za projektni ma- nagement
PMBOK The Project Management Body of Knowledge
Vodnik po znanju projek- tnega vodenja
PROMPT II
Projects Resource Organiza- tion Management Planning Technique II
Tehnika naˇcrtovanja upra- vljanja z organizacijo pro- jektov II
PRINCE PRojects In Controlled En- vironments
Projekti v nadzorovanem okolju
TOC Theory of Constraints Teorija omejitev CCPM Critical Chain Project Ma-
nagement
Metoda kritiˇcne verige UML Unified Modeling Language
model
Poenoteni jezik modeliranja ERP Enterprise resource planning Naˇcrtovanje virov
SDLC Software Development Life Cycle
Zivljenjski cikel razvoja pro-ˇ gramske opreme
NASA National Aeronautics and Space Administration
Nacionalna zrakoplovna in vesoljska uprava
HTML Hyper Text Markup Langu- age
Jezik za oznaˇcevanje nadbe- sedila
IT Information Technology Informacijska tehnologija
Naslov: Situacijski pristop k oblikovanju agilne metode razvoja programske opreme
Avtor: Ana Rovan
Namen diplomskega dela je pripraviti situacijski pristop k agilnemu razvoju programske opreme za specifiˇcen tip podjetja. V prvem delu je predsta- vljena zgodovina vodenja projektov in razvoj procesnih metod ter opis po- gosto uporabljenih agilnih modelov razvoja programske opreme. Drugi del se posveti opredelitvi situacijskega pristopa – od naˇcina ocenjevanja posame- znih potencialnih elementov pristopa, zastavitev vpraˇsanj glede na literaturo in sami sestavi ankete. Sledi poglavje, ki opiˇse uporabo pristopa na spe- cifiˇcnem podjetju. Zaˇcne se z predstavitvijo podjetja in analizo rezultatov empiriˇcne raziskave. Osrednji del raziskave predstavlja izvedba fokusnih de- lavnic, sam izbor elementov metode razvoja programske opreme in razlago razlogov za njihovo izbiro. Nadaljuje se s seznamom izbranih elementov me- tode in povratno informacijo vodstva. Diplomsko delo se zakljuˇci s sklepnimi ugotovitvami in moˇznim prihodnjim delom na tem podroˇcju.
Kljuˇcne besede: agilne metode, razvoj programske opreme, ocenjevanje elementov razvoja programske opreme, situacijski pristop razvoja metodolo- gij.
Title: Situational approach to designing an agile software development method
Author: Ana Rovan
The purpose of the thesis is to prepare a situational approach to agile software development for a specific type of company. The first part describes the history of project management and the development of process methods, as well as a description of commonly used agile software development models.
The second part focuses on the definition of the situational approach - from the evaluation of individual potential elements of the approach and forming questions based on the literature to the composition of the survey. The following is a section that describes how to apply the approach to a specific company. It begins with a presentation of the company and analysis of the results of empirical research. The central part of the research is the implementation of focus workshops, the selection of elements of the software development method and the explanation of the reasons for their choice. It continues with a list of selected method elements and management feedback.
The diploma thesis concludes with final thoughts and possible further work in this field.
Keywords: agile methods, software development, evaluation of software development elements, situational method engineering.
Uvod
Za vsako podjetje, ki razvija programsko opremo, je pomembna kvaliteta produktov, ki jih dostavlja, doseˇzeni roki in zadovoljstvo stranke. Tesno z dobrim izdelkom je povezano tudi dobro vodenje in izbira metode razvoja programske opreme. V obdobju uporabe mnogih agilnih metod se poraja veliko vpraˇsanj: Katero metodo izbrati?, Kakˇsni so izzivi pri uvedbi?, Kakˇsna bo sprejetost pri razvojnem in tehniˇcnem delu podjetja?, Kako se bo odzvalo vodstvo?.
Cilj diplomskega dela je oblikovati in preveriti pristop k agilnemu razvoju programske opreme za manjˇsa in srednje velika podjetja. Da bi ta cilj dosegli, je diplomsko delo strukturirano na sledeˇci naˇcin.
Prvo poglavje obravnava zgodovino, povezano z vodenjem projektov, in razvoj procesnih metod ter pregleda pogosto uporabljene modele. Prvi del sluˇzi kot osnova za izbor potencialnih elementov razliˇcnih znanih metod ra- zvoja programske opreme. V drugem poglavju opredelimo sam pristop, naˇcin ocenjevanja posameznega elementa in pripravo ankete za zaposlene. V tre- tjem poglavju sledi izvedba empiriˇcne ˇstudije primera, v sklopu katere anali- ziramo rezultate ankete in izvedemo fokusno delavnico, na kateri predstavimo rezultate ankete kljuˇcnim deleˇznikom. Ta predstavitev sluˇzi kot izhodiˇsˇce za diskusijo s kljuˇcnimi deleˇzniki in potrditev izbora elementov agilne metode razvoja programske opreme. Prvi del delavnice predstavlja predstavitve re-
1
zultatov ankete. Drugi del pa predstavlja razvoj debate in konsenz med vsemi anketiranimi skupinami o konˇcnem izboru elementov ter poslediˇcno konˇcno oblikovana metoda, ki bo ustrezala konkretnemu podjetju. V zakljuˇcku so opisane sklepne ugotovitve in nadaljnje delo.
Oblikovana agilna metoda z opisanim pristopom naj predstavlja izboljˇsavo delovnih procesov, doseganje zaˇcrtanih rokov, zmanjˇsevanje stroˇskov razvoja in zadovoljstvo zaposlenih ter stranke.
Pregled literature
Poglavje je razdeljeno na dva dela. V prvem delu je opisana zgodovina vo- denja projektov in zgodovina razvoja procesnih metod razvoja programske opreme. Drugi del pa opiˇse kljuˇcne modele razvoja programske opreme.
Cilj tega poglavja je spoznati samo vodenje projektov, razvoj tradicional- nih ter agilnih metod razvoja programske opreme. Pregled kljuˇcnih modelov pa sluˇzi kot temelj za opredelitev situacijskega pristopa.
2.1 Zgodovina
2.1.1 Antika
Kaj sploh je projekt? Glede na inˇstitut PMI (angl. Project Management Institute) je projekt “zaˇcasna skupinska dejavnost, namenjena izdelavi edin- stvenega izdelka, storitve ali rezultata” in projektno vodenje “uporaba zna- nja, veˇsˇcin, orodij in tehnik pri projektnih aktivnostih za zadostitev pro- jektnih zahtev”. Po tej definiciji so ljudje zaˇceli delati na projektih ˇze v antiˇcni zgodovini. Skozi zgodovino so iznajdljivi arhitekti in inˇzenirji izvedli impresivne projekte, kot so Velika piramida v Gizi, Kitajski zid, Kolosej, Babilonski viseˇci vrtovi in Stonehenge. Ti arhitekti in inˇzenirji so poleg svo- jih primarnih nalog prevzeli tudi nalogo vodje projektov. Potrebno je bilo skrbno premisliti o vseh procesih projekta od zaˇcetne faze in faze naˇcrtovanja
3
pa do izvedbe in zakljuˇcka projekta. Za vsakega od teh projektov je moral nekdo veˇc let voditi na stotine do tisoˇce delavcev. Poleg tega pa je moral za- gotoviti, da je projekt na pravi poti in seveda izpolniti priˇcakovanja kljuˇcnih deleˇznikov [43].
2.1.2 Zaˇ cetki sodobnega projektnega vodenja
Mnenja o tem, kdaj se je zaˇcela sodobna doba vodenja projektov, se razli- kujejo. Y. C. Chiu v svoji knjigi An introduction to the History of Project Management: From the Earliest Times to A.D.1900 razglasi Henrija Fayola in Henryja Gantta za oˇceta sodobnega vodenja projektov [16]. ˇCeprav se nekateri ne strinjajo s to trditvijo, se pa mnogi strinjajo, da imata oba, Fayol in Gantt, pomemben prispevek na tem podroˇcju [43].
Henri Fayol (1841—1925) je bil francoski inˇzenir v velikem jeklarskem in ˇzelezarskem podjetju. Med delom je postajal vse bolj zainteresiran za izzive managementa. Z opazovanjem je Fayol opredelil pet osnovnih aktivnosti ma- nagementa, za katere je menil, da so univerzalne: naˇcrtovanje, organiziranje, ukazovanje, usklajevanje in nadziranje. Fayol je tudi oblikoval ˇstirinajst naˇcel vodenja, ki sluˇzijo kot navodilo za uˇcinkovito izvajanje zgoraj naˇstetih ak- tivnosti. Mnogi so ga kritizirali, da teorija ne odraˇza resniˇcne kompleksnosti vodenja, s katero se sreˇcujejo vodje pri vsakodnevnem delu. Kljub temu je Fayolovo delo pomembno prispevalo pri razvoju managementa.
Henry Gantt (1861—1919) je bil ameriˇski inˇzenir in kasneje svetovalec za vodenje. Najbolj znan je po razvoju gantograma. Gantogram je pomemben pripomoˇcek v sodobni zgodovini projektnega vodenja, saj prepozna prednosti razdelitve velikih projektov v manjˇse, bolj obvladljive naloge. Upoˇsteva tudi, da so nekatere naloge lahko odvisne ena od druge. Gantogrami se uporabljajo ˇse danes in veljajo za kljuˇcno orodje pri vodenju projektov. Oblikovani so bili med letoma 1910 in 1915, kasneje pa so bili uporabljeni pri velikih projektih v prvi svetovni vojni in gradnji Hooverjevega jezu, kar je prispevalo k njihovem sprejetju in ˇsiroki uporabi. Primer prepostega gantograma je prikazan na sliki 2.1.
Slika 2.1: Primer gantograma
Po mnenju Snyderja in Klinea (1987) se je moderna doba vodenja pro- jektov zaˇcela ˇsele leta 1958 z razvojem CPM/PERT [26]. CPM/PERT je bil vzporedno razvit na dveh zelo razliˇcnih podroˇcjih: vojni mornarici in kemiˇcni industriji. Leta 1958 je ameriˇska mornarica vodila projekt Polaris. Za po- trebe tega projekta je ameriˇska mornarica razvila eno izmed danes najbolj razˇsirjenih projektnih metod PERT (angl. Program (Project) Management and Review Technique). To je tehnika upravljanja in pregledovanja programa (projekta). Metoda kritiˇcne poti (angl. Critical Path Method — CPM) je bil razvita soˇcasno z metodo PERT. Do razvoja CPM metode je priˇslo pri gradnji velikega kemiˇcnega obrata. CPM metoda je nastala za naslovitev potrebe po natanˇcni ocenitvi stroˇskov in ˇcasa trajanja projekta.
2.1.3 Sodobno vodenje projektov
Zametki sodobnega projektnega vodenja segajo v obdobje med 1900 in 1950.
V tem obdobju so boljˇsi prometni in telekomunikacijski sistemi omogoˇcali veˇcjo mobilnost in hitrejˇso komunikacijo. V porastu je bila tudi uporaba gantograma. Poleg ˇze prej omenjenega Hooverjevega jezu je bil gantogram uporabljen tudi v projektu Meddrˇzavni avtocestni sistem (angl. Interstate Highway System) in projektu Manhattan. Leta 1956 je Herbert D. Benning-
ton dal prvi uradni opis slapovnega model (angl. Waterfall model).
V obdobju med 1958 in 1979 je priˇslo do znatnega tehnoloˇskega napredka.
Podjetje Xerox je predstavilo prvi kopirni stroj. Zaˇcela se je tudi uporaba orodij za vodenje projekta, kot sta PERT in CPM. Obvezna je bila tudi uporaba pristopa Strukturirana ˇclenitev projekta (angl. Work Breakdown Structure – WBS) za obseˇzne projekte, kakor je bil Polaris. Ustanovljeno je bilo zdruˇzenje za management, sedaj znano kot IPMA — Mednarodno zdruˇzenje za projektni management. Od ustanovitve leta 1965 se je IPMA moˇcno poveˇcala in je sedaj glavni promotor projektnega vodenja v Evropi, Aziji in arabskih drˇzavah. ˇStiri leta pozneje je bil ustanovljen inˇstitut PMI.
Poleg tega je bilo to obdobje bogato s pomembnim razvojem raˇcunalniˇske tehnologije. V sedemdesetih letih prejˇsnjega stoletja so raˇcunalniki napre- dovali od osrednjih raˇcunalnikov do mini raˇcunalnikov, zaradi ˇcesar so bili raˇcunalniki cenovno dostopnejˇsi. Cenovna dostopnost mini raˇcunalnikov je kasneje olajˇsala nastanek veˇc programske opreme in orodij za projektno vo- denje podjetja. Tukaj velja omeniti tudi projekt Apollo, ki je prvi uradni sis- tem projektnega vodenja agencije NASA in je nastal kot odgovor na potrebo po standardu v upravljanju zapletenega, dragega in ambicioznega naˇcrta za pristanek ˇcloveka na Luni.
V osemdesetih in zaˇcetku devetdesetih so osebni raˇcunalniki vplivali na ˇstevilne vidike dela in poslovanja, vkljuˇcno z vodenjem projektov. Uˇcinkovitost osebnih raˇcunalnikov je omogoˇcila razvoj sposobne programske opreme po- trebne za projektno vodenje. V osemdesetih so programi za projektno vode- nje veˇcinoma temeljili na modelu PROMPT II, ki je bil kasneje izpopolnjen v model PRINCE. Drugi pomemben razvoj v tem obdobju je razvoj teorije omejitev (angl. Theory of Constraints — TOC), ki jo je uvedel Eliyahu M. Goldratt v svoji odmevni knjigi “Cilj: Proces nenehnih izboljˇsav”. To obdobje je tudi zaˇcetek uporabe prototipov.
Barry Boehm je leta 1986 postopek razvoja programske opreme opisal v obliki spiralnega modela [11]. Spiralni procesi uporabljajo iterativne razvojne koncepte za zmanjˇsanje tveganj. Istega leta sta izraz Scrum v povezavi z
razvojem programske opreme uvedla Takeuchi in Nonaka [50].
Leta 1987 je PMI izdal knjigo Vodnik po znanju projektnega vodenja (PMBOK). Knjiga je zbirka procesov in podroˇcij znanja, ki so sploˇsno spre- jeta kot najboljˇsa praksa na podroˇcju vodenja projektov. Projekt Predor pod Rokavskim prelivom (1989—1991), Space Shuttle Challenger (1983–1986), XV. zimske olimpijske igre v Calgaryju (1988) predstavljajo uporabo visoke tehnologije, orodij in praks projektnega vodenja tistega ˇcasa. Predor pod Rokavskim prelivom je bil mednarodni projekt, ki je vkljuˇceval dve drˇzavi – Veliko Britanijo in Francijo, veˇc finanˇcnih institucij, inˇzenirska gradbena podjetja in druge organizacije. Za izvedbo projekta je bilo treba prilagoditi cilj projekta, stroˇske, urnik in druge faktorje. Jezik, merske enote in druge komunikacijske razlike je bilo potrebno uskladiti. Katastrofa projekta Space Shuttle Challenger je povzroˇcila usmerjeno pozornost na obvladovanje tve- ganj, skupinsko dinamiko in kakovostno vodenje. Zimske olimpijske igre leta 1988 pa so primer uspeˇsnega vodenja dogodkov.
V drugi polovici devetdesetih je tehnologija ˇse naprej gonilna sila spre- memb in moˇcno vpliva na to, kaj poˇcnejo vodje projektov. Leta 1996 je bil PRINCE nadgrajen na PRINCE2, kmalu zatem pa je bila leta 1997 uvedena alternativna metoda, imenovana CCPM (angl. Critical Chain Project Mana- gement). CCPM je metoda naˇcrtovanja in vodenja projektov, ki jo je razvil Eliyahu M. Goldratt. Izhaja iz TOC in za razliko od CPM in PERT pou- darjala vire, potrebne za dokonˇcanje projekta, in ne posebne naloge. Leta 1998 Ameriˇski drˇzavni inˇstitut za standarde (angl. The American National Standards Institute – ANSI) prizna PMBOK kot standard, prav tako to stori Inˇstitut inˇzenirjev elektrotehnike in elektronike (angl. Institute of Electrical and Electronics Engineers – IEEE) kasneje tega leta.
Pristopi v tem poglavju so bili razviti za izjemno velike in kompleksne projekte. Vsebovali so veliko administracije in so bili izjemno togi. Prav zaradi tega niso primerni za mala in srednja podjetja.
2.1.4 Doba agilnih metodologij
Leta 2001 je bil napisan manifest agilnosti programske opreme. Manifest agilnosti temelji na nizu temeljnih vrednot [19]:
- Posamezniki in interakcije pred procesi in orodji.
- Delujoˇca programska oprema pred vseobseˇzno dokumentacijo.
- Sodelovanje s stranko pred pogodbenimi pogajanji.
- Odziv na spremembe pred togim sledenjem naˇcrtom.
Dvanajst principov agilne programske opreme:
1. Naˇsa najviˇsja prioriteta je zadovoljiti stranko z zgodnjim in nepretrga- nim izdajanjem vredne programske opreme.
2. Sprejemamo spremembe zahtev, celo v poznih fazah razvoja. Agilni procesi vpreˇzejo tovrstne spremembe v prid konkurenˇcnosti naˇse stranke.
3. Delujoˇco programsko opremo izdajamo pogosto, znotraj obdobja nekaj tednov, do nekaj mesecev, s preferenco po krajˇsem ˇcasovnem okvirju.
4. Poslovneˇzi in razvijalci morajo skozi celoten projekt dnevno sodelovati.
5. Projekte gradimo okrog motiviranih posameznikov. Omogoˇcimo jim delovno okolje, nudimo podporo in jim zaupamo, da bodo svoje delo opravili.
6. Najboljˇsa in najuˇcinkovitejˇsa metoda posredovanja informacij razvojni ekipi in znotraj ekipe same, je pogovor iz oˇci v oˇci.
7. Delujoˇca programska oprema je primarno merilo napredka.
8. Agilni procesi promovirajo trajnostni razvoj. Sponzorji, razvijalci in uporabniki morajo biti zmoˇzni konstantnega tempa za nedoloˇcen ˇcas.
9. Nenehna teˇznja k tehniˇcni odliˇcnosti in k dobremu naˇcrtovanju izboljˇsa agilnost.
10. Preprostost – umetnost zmanjˇsevanja koliˇcine nepotrebnega dela – je bistvena.
11. Najboljˇse arhitekture, zahteve in naˇcrti izhajajo iz tistih ekip, ki so samoorganizirane.
12. V rednih ˇcasovnih razdobjih ekipa iˇsˇce naˇcine, kako postati uˇcinkovitejˇsa ob rednem prilagajanju svojega delovanja.
Nekateri avtorji manifesta so ustanovili Agile Alliance, neprofitno organiza- cijo, ki spodbuja razvoj programske opreme v skladu z dvanajstimi temelj- nimi naˇceli manifesta.
Med letoma 2008 in 2021 je bilo narejenih veˇc izdaj vodnika PMBOK, zadnja je bila sedma izdaja, in sicer leta 2021. Najnovejˇsa izdaja obrav- nava trenutne in prihodnje potrebe izvajalcev projektov ter jim pomaga, da so proaktivnejˇsi, inovativnejˇsi in agilnejˇsi pri omogoˇcanju ˇzelenih rezultatov projekta. Kritiˇcna sprememba v tej izdaji odraˇza celoten nabor razvojnih pristopov, ki zagotavlja celoten razdelek, namenjen prilagajanju razvojnega pristopa in procesov.
Leta 2010 David J. Anderson v svoji knjigi Kanban opiˇse Kanban metodo v povezavi razvoja programske opreme na primeru projekta [5].
Septembra 2012 je Mednarodna organizacija za standardizacijo (angl. In- ternational Organization for Standardization – ISO) objavila “ISO 21500:2012 , Smernice za vodenje projektov”. Standard je zasnovan za vsako organizacijo in je rezultat petletnega dela strokovnjakov iz veˇc kot 50 drˇzav. Sem spa- dajo javne, zasebne ali skupnostne skupine ter katerikoli projekt, ne glede na zahtevnost, velikost in trajanje.
Leta 2015 je bila izdana knjiga za PRINCE2 Agile, ki je prilagojena oblika PRINCE2 metodologije in je primerna za agilne projekte, ki uporabljajo Kanban, Scrum ali podoben agilni sistem.
Lahko priˇcakujemo, da se bodo agilne metodologije vseskozi razvijale, sprejemale lastne temeljne vrednote in naˇcela za vseprisoten pristop. Pro- jekti postajajo veˇcji, zapletenejˇsi in vse zahtevnejˇsi za vodenje. Ekipe so bolj raznolike in razˇsirjene po vsem svetu. Zaradi pritiska po zniˇzevanju stroˇskov se delo seli v drˇzave z niˇzjim standardom, kar samo po sebi predsta- vlja svojevrstne teˇzave. Svet se spreminja in vodenje projektov se bo moralo spremeniti z njim.
[26, 43, 13]
2.2 Kljuˇ cni modeli razvoja programske opreme
2.2.1 Slapovni model
Slapovni model (angl. Waterfall model) temelji na zaporedju faz, ki jih je potrebno izvesti za uspeˇsno zgraditev programske opreme. Iz ene faze v drugo lahko prehajamo le, ˇce je predhodna faza uspeˇsno konˇcana. Vraˇcanje nazaj ni mogoˇce. Od tu tudi ime slapovni model, ker ponazarja izlivanje slapa v reko [1].
Faze se v tem modelu ne prekrivajo. Takˇsen model je moˇcno omejen.
Zaradi vse veˇcje potrebe po spremembah med samim procesom razvoja so model nadgradili in vanjo vkljuˇcili povratno informacijo v obliki testiranja.
Tak model je primeren za manjˇse projekte s statiˇcno strukturo, pri katerih lahko zagotovimo, da skozi faze razvoja ne bo priˇslo do kakrˇsnihkoli spre- memb.
Zaporedne faze v slapovnem modelu so naslednje [1]:
Analiza in zbiranje zahtev(angl. Requirement Analysis). V tej fazi so zajete vse moˇzne zahteve sistema razvoja dokumentirane v doku- mentu specifikacij zahtev.
Oblikovanje sistema (angl. Design). Najprej se preuˇcijo zahteve iz prve faze. Na podlagi tega se pripravi oblikovanje sistema, kar pa
Slika 2.2: Faze slapovnega modela
pomaga pri specifikaciji strojnih in sistemskih zahtev ter definiranju celotne arhitekture sistema.
Razvoj (angl. Implementation). Z vhodom iz prejˇsnje toˇcke najprej razvije manjˇse programe, ki jih imenujemo enote. Te so potem integri- rane v naslednjo fazo. Vsaka enota je razvita in preizkuˇsena za svojo funkcionalnost. Ta proces imenujemo “testiranje enote”.
Testiranje(angl. Testing). Vse enote razvite v fazi implementacije so v tej fazi integrirane v sistem. Po integraciji se celoten sistem testira za morebitne napake.
Vzdrˇzevanje sistema (angl. Maintenance). Pri stranki se pojavijo nekatere teˇzave, ki jih je potrebno popraviti. Za odpravo teˇzav se namestijo popravki. Za izboljˇsanje programske opreme so izdane nove verzije. Opravi se faza vzdrˇzevanja, ki zagotovi te spremembe
Prednosti slapovnega modela sta predvsem preprosta in enostavna upo- raba. V tem modelu so vse faze in rezultati dobro dokumentirani. Slabost je, da med razvojem ni interakcije s strankami. Zaradi zaporednega razvoja paralelni rezultati niso moˇzni. V primeru sprememb produkta po razvoju so
stroˇski viˇsji, kakor tudi porabljen ˇcas, ker moramo posodobiti od dokumenta do kode.
2.2.2 Prototipni model
V prototipnem modelu (angl. Prototyping Model) je bistvo izdelave pro- totipov programske opreme, ki so nepopolne verzije [37]. Prototip obiˇcajno vsebuje osnovne funkcionalnosti in je lahko popolnoma drugaˇcen od konˇcnega produkta. Uporabniki so vseskozi aktivni v procesu razvoja in tako razvijalci dobijo ˇze v zaˇcetni fazi projekta povratne informacije. Prototip pomaga pri opredelitvi zahtev za konˇcen produkt.
Pri prototipnem modelu loˇcimo veˇc vrst. Evolucijski oz. razvojni prototip (angl. Evolutionary prototype) se dopolnjuje s funkcionalnostmi do konˇcnega produkta. V drugem primeru se prototip zavrˇze (angl. Throwaway proto- type). Uporabljen je bil samo za natanˇcno opredelitev uporabniˇskih zahtev.
Proces modela vkljuˇcuje naslednje korake [37]:
1. Doloˇcitev osnovnih zahtev.
2. Razvoj zaˇcetnega prototipa.
3. Pregled s strani stranke in posredovanje povratne informacije o more- bitnih dopolnitvah ali spremembah.
4. Pregled povratnih informacij stranke in izboljˇsava prototipa.
Prednost prototipnega modela je med drugim tudi, da je mogoˇce odkriti napake ˇze v zgodnji fazi razvoja. Laˇzje je prepoznati manjkajoˇce funkcio- nalnosti, kar pomaga pri zmanjˇsevanju tveganja za neuspeh. Po drugi strani pa je izdelava prototipov poˇcasen in dolgotrajen proces. Izdelava prototipov lahko spodbudi pretirane zahteve po spremembah pri uporabnikih [54].
2.2.3 Model hitrega razvoja programske opreme
Model hitrega razvoja programske opreme (angl. Rapid Application Deve- lopment — RAD) je oblika agilnega razvoja programske opreme, ki jo je
izumil James Martin leta 1991 [33]. ˇZelel se je odzvati na omejitve pri sla- povnem modelu. Za razliko od slapovnega modela RAD ponuja iterativnost, ki podpira izdelavo prototipov, ter z njim omogˇca povratne informacije upo- rabnikov [2].
Pristop Jamesa Martina deli proces RAD modela na ˇstiri razliˇcne faze [33]:
1. Naˇcrtovanje zahtev(angl. Requirements planning) — zdruˇzuje ana- lizo in naˇcrtovanje zahtev. Faza se zakljuˇci, ko se ekipa dogovori o kljuˇcnih vpraˇsanjih in pridobi odobritev vodstva za nadaljevanje.
2. Funkcionalna zasnova (angl. User design) — v tej fazi uporabniki sodelujejo s sistemskimi analitiki in razvijajo prototip, ki pokriva vse sistemske procese in zadosti potrebam uporabnikov.
3. Izvedba(angl. Construction) — se osredotoˇca na razvoj konˇcne reˇsitve v sodelovanju z uporabniki. ˇSe vedno se lahko predlagajo spremembe ali izboljˇsave.
4. Uvajanje (angl. Cutover) — vsebuje migracijo podatkov, testiranje, prehod na nov sistem in izobraˇzevanje uporabnikov.
V tem modelu so funkcije, komponente razvite hkrati kakor, da bi bila vsaka zase majhen projekt. Hiter razvoj se v glavnem osredotoˇca na zbi- ranje zahtev skozi pomoˇcjo fokusnih skupin in delavnic, zgodnje testiranje prototipov z uporabo iterativnega koncepta in s ponovno uporabo kompo- nent in prototipa ter s tem hitro dostavo. V tem modelu ni predhodnega naˇcrtovanja, zato so spremembe laˇzje izvedljive znotraj razvojnega procesa.
RAD sledi inkrementalnemu in iterativnemu modelu in ima majhne ekipe, ki jih sestavljajo razvijalci, predstavniki strank in drugi s podroˇcja IT, ki postopno delajo na prototipu [38].
Prednosti so spreminjanje zahtev, ponovna uporaba komponent, ki ˇze ob- stajajo, ter skrajˇsan ˇcas razvoja. Stranka lahko tudi meri napredek razvoja.
Slabosti pa sta, da ta model zahteva usposobljene oblikovalce ter da je zelo odvisen od tehniˇcne ekipe, ki mora najti poslovne zahteve [2].
2.2.4 Spiralni model
Spiralni model (angl. Spiral Model) je meˇsanica ˇcistega strukturiranega in fleksibilnega prototipnega modela, ki zagotavlja tudi podporo pri obvladova- nju tveganj [12]. V svojem diagramskem prikazu je ponazorjen kot spirala s ˇstevilnimi zankami.
Natanˇcno ˇstevilo zank spirale ni znano in je odvisno od projekta. Vsako zanko spirale imenujemo faza postopka razvoja programske opreme. Na- tanˇcno ˇstevilo faz, potrebnih za razvoj izdelka, lahko vodja projekta spre- minja glede na projektna tveganja. Ker vodja projektov dinamiˇcno doloˇca ˇstevilo faz, ima vodja projekta pomembno vlogo pri razvoju izdelka z uporabo spiralnega modela. Polmer spirale na kateri koli toˇcki predstavlja dosedanje stroˇske projekta, kotna dimenzija pa predstavlja dosedanji napredek v tre- nutni fazi.
Vsaka faza spiralnega modela je razdeljena na ˇstiri kvadrante, kot je pri- kazano na sliki 2.3. Funkcije teh ˇstirih kvadrantov so naslednje [12]:
Doloˇcitev ciljev in doloˇcitev alternativnih reˇsitev. Zahteve so zbrane, cilji pa opredeljeni, izdelani in analizirani na zaˇcetku vsake faze.
Nato so v tem kvadrantu predlagane moˇzne reˇsitve za fazo.
Ugotovite in obvladovanje tveganja. V drugem kvadrantu se oce- nijo vse moˇzne reˇsitve, izbere se najboljˇsa moˇzna reˇsitev. Nato se ugo- tovijo tveganja, povezana s to reˇsitvijo, in ta se reˇsijo z najboljˇso moˇzno strategijo. Na koncu tega kvadranta je zgrajen prototip za najboljˇso moˇzno reˇsitev.
Razvoj naslednje verzije produkta. Med tretjim kvadrantom se prepoznane funkcionalnosti razvijejo in preverijo s testiranjem. Na koncu tretjega kvadranta je na voljo naslednja razliˇcica programske opreme.
Pregled in naˇcrtovanje naslednje faze. V ˇcetrtem kvadrantu stranka oceni do zdaj razvito razliˇcico programske opreme. Na koncu se zaˇcne
Slika 2.3: Spiralni model naˇcrtovanje naslednje faze.
Prav gotovo je prednost spiralnega modela obvladovanje tveganja. Pri- poroˇca se pri velikih in kompleksnih projektih. Tudi kasnejˇse zahteve se lahko natanˇcno vkljuˇcijo s tem modelom. Stranka lahko vidi razvoj produkta v zgo- dnji fazi razvoja programske opreme in se lahko seznani z njim in njegovo uporabo pred dokonˇcanjem celotnega izdelka. Po drugi strani pa je spiralni model veliko zapletenejˇsi kot drugi modeli SDLC. Spiralni model ni primeren za majhne projekte, saj je drag. Uspeˇsen zakljuˇcek projekta je v veliki meri odvisen od analize tveganja. Brez zelo izkuˇsenega strokovnega znanja razvoj projekta ne bo uspeˇsen po tem modelu. Tudi ocenjevanje ˇcasa je zelo teˇzko,
ker ˇstevilo faz na zaˇcetku projekta ni znano.
2.2.5 Ekstremno programiranje
Ekstremno programiranje (angl. Extreme Programming – XP) je model ra- zvoja programske opreme, ki ga je v prvi vrsti razvil Kent Beck [9]. Ek- stremno programiranje postavi tradicionalne metode na stran. Raje kot planiranje, analiziranje in oblikovanje za daljno prihodnost, XP izkoriˇsˇca zmanjˇsevanje stroˇskov na naˇcin, da se vse te aktivnosti izvajajo po malem skozi celoten proces razvoja programske opreme [8].
Razvojni cikel v ekstremnem programiranju se zaˇcne tako, da stranka iz- bere funkcionalnosti, ki se v XP imenujejo zgodbe (angl. stories) za naslednjo iteracijo. Stranka je obveˇsˇcena o stroˇskih zgodb in hitrostjo ekipe. Razvijalci vsako zgodbo razdelijo na manjˇse naloge, za katere individualno prevzamejo odgovornost. Nato razvijalec spremeni nalogo v niz testov, ki bodo pokazali, da je naloga konˇcana. Razvijalec v sodelovanju s partnerjem razvija in izvaja testne primere, pri tem pa skrbi, da se ohranja ˇcim preprostejˇsi model [8].
Spodaj so naˇstete nekatere glavne prakse ekstremnega programiranja [8]:
- Igra naˇcrtovanja (angl. Planning game). Stranka doloˇci obseg in ˇcas dostave na podlagi ocen razvijalcev. Razvita je samo tista funkcional- nost, ki jo zahtevajo zgodbe v tej iteraciji.
- Majhne izdaje (angl. Small releases). Nove izdaje so pogoste – od dnevnih do meseˇcnih.
- Preprost model (angl. Simple design). V vsakem trenutku lahko model izvede vse teste, ne vsebuje podvojene kode in ima ˇcim manj razredov in metod, kolikor je to mogoˇce.
- Testi (angl. Tests). Razvijalci vseskozi piˇsejo enotske teste (angl.
unit tests). Stranka napiˇse funkcijske teste (angl. functional tests) za zgodbe v iteraciji.
- Prestrukturiranje programske kode(angl. refactoring). Oblika se razvija s transformacijami obstojeˇcega sistema.
- Programiranje v paru(angl. Pair programming). Vso produkcijsko kodo piˇseta dva ˇcloveka za istim zaslonom/tipkovnico/miˇsko.
- Nenehna integracija (angl. Continuous integration). Integracija nove kode v trenuten sistem ne traja veˇc kot nekaj ur.
- Skupno lastniˇstvo (angl. Collective ownership). Vsak razvijalec lahko izboljˇsa kodo kjerkoli, ˇce se pojavi prilika za to.
- Samo pravila (angl. Just rules). Ekipa se zavezuje, da bo sledila pravilom, ampak to so ˇse vedno pravila. Ekipa jih lahko kadarkoli spremeni, dokler se vsi strinjajo, kako bodo ocenili uˇcinke spremembe.
Ekstremno programiranje je zelo uporabno pri majhnih projektih z majh- nimi razvojnimi ekipami. Primeren pa je tudi za projekte, ki vkljuˇcujejo novo tehnologijo ali raziskovalne projekte [28].
2.2.6 Funkcijsko voden razvoj
Funkcijsko voden razvoj (angl. Feature Driven Development – FDD) je agilna metodologija, ki, kot ˇze ime predlaga, v center postavi razvoj funkcional- nosti, kljub temu da funkcionalnosti v FDD kontekstu niso nujno funkcio- nalnosti produkta v sploˇsno razumljivem pomenu. Le-te so bolj podobne uporabniˇskim zgodbam v Scrumu. Z drugimi besedami, “dokonˇcaj postopek prijave” se lahko ˇsteje za funkcionalnost v metodologiji FDD [31].
FDD je bil zasnovan tako, da sledi petstopenjskemu razvojnemu procesu, ki je bil v veliki meri zasnovan na diskretnih “funkcionalnostnih” projektih.
Zivljenjski cikel projekta je videti tako [31]:ˇ - Razvoj sploˇsnega modela.
- Sestavitev seznama funkcij.
- Naˇcrt funkcionalnosti.
- Oblikovanje funkcionalnosti.
- Gradnja funkcionalnosti.
Prednosti FDD je preprost petstopenjski proces, ki omogoˇca hitrejˇsi ra- zvoj. Veˇcjim skupinam omogoˇca premikanje naprej produkta z neprekinje- nim uspehom. Uporablja vnaprej doloˇcene razvojne standarde, zato lahko razvojne ekipe hitro napredujejo [31].
2.2.7 Model AUP
Model AUP (angl. Agile Unified Process) je poenostavljena razliˇcica modela RUP (angl. Rational Unified Process — RUP), ki ga je ustvaril Scott W.
Ambler. Opisuje preprost in razumljiv pristop k razvoju programske opreme za poslovne aplikacije z uporabo agilnih tehnik in konceptov, vendar ˇse vedno ostaja zvest modelu RUP [4].
AUP temelji na naslednjih naˇcelih [4]:
- Veˇcina ljudi ne bo brala podrobne dokumentacije, vendar pa bodo obˇcasno potrebovali usmerjanje in usposabljanje.
- Projekt naj bo preprosto opisan na nekaj straneh.
- Model AUP se zgleduje po vrednotah in naˇcelih manifesta agilnosti.
- Projekt se mora osredotoˇcati na dejavnosti, ki dejansko ˇstejejo, in ne nepotrebne funkcionalnosti.
- Razvijalci morajo biti svobodni pri uporabi orodij, ki so najprimernejˇsi za zadano nalogo.
- AUP je enostavno prilagoditi s pomoˇcjo obiˇcajnih orodij za urejanje HTML.
AUP je zajet v ˇstiri faze [4]:
1. Zaˇcetek(angl. Inception). Cilj je identificirati zaˇcetni obseg projekta, potencialno arhitekturo za sistem ter pridobiti zaˇcetno financiranje pro- jekta in sprejetje s strani stranke.
2. Izdelava (angl. Elaboration). Cilj je dokazati arhitekturo sistema.
3. Konstrukcija(angl. Construction). Cilj je redno in iterativno graditi delujoˇco programsko opremo, ki bo ustrezala prioritetnim potrebam stranke.
4. Prehod (angl. Transition). Cilj je preveriti in uvesti produkt v pro- dukcijsko okolje.
Discipline se izvajajo na iterativen naˇcin, pri ˇcemer opredeljujejo dejav- nosti, ki jih izvaja razvojna ekipa za izgradnjo, validacijo in dostavo delujoˇce programske opreme, ki ustreza potrebam stranke. Te discipline pa so nasle- dnje [4]:
Model(angl. Model). Cilj te discipline je razumeti poslovanje stranke, problematiˇcna podroˇcja, ki ga projekt obravnava, in identificirati izve- dljivo reˇsitev za reˇsevanje problematike.
Test(angl. Test). Cilj te discipline je izvesti objektivno vrednotenje za zagotavljanje kakovosti. To vkljuˇcuje iskanje napak, preverjanje delo- vanja sistema kot je zasnovano in preverjanje, ali so zahteve izpolnjene.
Namestitev (angl. Deployment). Cilj te discipline je naˇcrtovati do- stavo sistema in izvesti naˇcrt, da bo sistem na voljo konˇcnim uporab- nikom.
Upravljanje konfiguracij (angl. Configuration Management). Cilj te discipline je upravljanje dostopa do artefaktov (angl. artifacts) pro- jekta. To ne vkljuˇcuje samo sledenje razliˇcicam artefaktov skozi ˇcas, temveˇc tudi nadzor in upravljanje sprememb le-teh.
Vodenje projektov(angl. Project Management). Cilj te discipline je usmerjanje aktivnosti, ki se odvijajo na projektu. To vkljuˇcuje upra- vljanje tveganj, usmerjanje ljudi (dodeljevanje nalog, spremljanje na- predka itd.) ter usklajevanje z ljudmi in sistemi izven obsega projekta, da se zagotovi, da bo produkt dostavljen pravoˇcasno in v okviru fi- nanˇcnega naˇcrta.
Okolje(angl. Environment). Cilj te discipline je, da se projekt izvaja v okolju, ki je dovolj primerno za zagotovitev uspeha na projektu, npr. da so vzpostavljeni ustrezni postopki, da so na voljo standardi in smernice ter da ima ekipa ustrezno strojno in programsko opremo za dokonˇcanje projekta.
2.2.8 Scrum metoda
Scrum je agilna metoda za vodenje in nadzor razvoja programske opreme, ki uporablja iterativne in inkrementalne pristope [42]. Kljuˇcno naˇcelo Scruma je dvojno spoznanje, da bo stranka v ˇcasu razvoja spremenila svoje ˇzelje in/ali potrebe (pogosto to imenujemo nestanovitnost zahtev) in da bo priˇslo do nepredvidljivih izzivov, za katere napovedni ali naˇcrtovani pristop ni pri- meren. Scrum kot tak uporablja empiriˇcni pristop, ki temelji na dokazih, saj sprejema, da teˇzave ni mogoˇce popolnoma razumeti ali definirati vnaprej, in namesto tega se osredotoˇca na to, kako maksimirati sposobnost ekipe za hitro izvedbo, odzivanje na nastajajoˇce potrebe, prilagajanje razvijanju teh- nologije in spremembe trˇznih razmer [48].
Scrum definira tri glavne vloge za zagotavljanje optimalne komunikacije med ˇclani ekipe, medtem ko imajo ˇstevilne organizacije pri doloˇcanju in do- stavi izdelka ˇse druge vloge. Scrum doloˇca le te tri [48]:
Lastnik izdelka (angl. Product owner) je odgovoren za seznam zahtev, pre- tvorbo le-teh v prednostni seznam in odloˇcanje, katere zahteve bodo na vrhu seznama za naslednjo iteracijo (angl. Sprint). S prioritiziranjem zahtev skrbi za maksimizirano dodano vrednost (angl. Return on In-
vestment — ROI) projekta. V nekaterih primerih sta lastnik izdelka in stranka ista oseba. To po navadi velja za interne aplikacije. V drugih primerih predstavlja stranko na milijone ljudi z razliˇcnimi potrebami.
V tem primeru pa je vloga lastnika izdelka podobna vlogi produktnega vodje ali vodji trˇzenja izdelkov. Kakorkoli, vloga lastnika izdelka se razlikuje od produktnega vodje v tem, da lastnik izdelka aktivno in pogosto komunicira z razvojno ekipo, pregleduje rezultate na koncu vsake iteracije in ne delegira razvojnih odloˇcitev projektnemu vodji.
Pomembno je omeniti, da je v Scrumu ena sama oseba, ki ima vlogo lastnika izdelka in je odgovorna, koliko bo delo vredno.
Razvojna ekipa (angl. Development team) skrbi za razvoj in dostavo funk- cionalnosti razvitih na osnovi uporabniˇskih zgodb na koncu vsakega sprinta. Ekipa po navadi ˇsteje sedem ljudi, plus minus dva ˇcloveka, medtem ko so ˇclani ekipe lahko razvijalci. Izraz se nanaˇsa na vsakogar, ki igra vlogo pri razvoju in podpori sistema ali izdelka in lahko vkljuˇcuje med drugim raziskovalce, arhitekte, oblikovalce, strokovnjake za po- datke, statistike, analitike, inˇzenirje, programerje in testerje. Ekipi se mora omogoˇciti, da se samoorganizira, torej sama razdeljuje delo med ˇclane. V Scrumu je ekipa najproduktivnejˇsa in najuˇcinkovitejˇsa, ˇce dela med iteracijo stoprocentno na enem izdelku in se izogiba delu na veˇc izdelkih ali veˇc projektih hkrati. Stabilne ekipe, ki ne menjujejo ˇclanov, so povezane z veˇcjo produktivnostjo.
Skrbnik metodologije (angl. Scrum master) je odgovoren za odstranje- vanje ovir pri ekipi in skrbi, da ekipa uresniˇci cilje in dostavi rezultate.
Scrum master ni tradicionalno vodja ekipe ali vodja projekta, ampak deluje kakor vmesnik med ekipo in morebitnimi moteˇcimi vplivi. Za- gotavlja, da ekipa sledi dogovorjenim procesom znotraj ogrodja Scrum, in spodbuja ekipo k izboljˇsanju.
Usposablja ekipo v skladu z naˇceli Scrum za zagotovitev kakovosti pro- dukta. Spodbujanje samoorganizacije znotraj ekipe, pomaga pri od-
Slika 2.4: Razvojni proces Scrum
stranjevanju ovir za napredek. Organizira skupinske dogodke za za- gotovitev rednega napredka. Eden od naˇcinov, kako se vloga Scrum masterja razlikuje od vodje projektov je, da ima slednji lahko odgo- vornost za upravljanje ljudi in dodeljuje naloge, Scrum master pa ne.
Scrum metoda formalno ne prizna vloge vodje projekta, ker ta ni po- trebna. Tradicionalne odgovornosti vodje projekta so razporejene med tri Scrum vloge.
Prvi korak v Scrumu je, da lastnik izdelka artikulira vizijo izdelka. Rezul- tat se razvije v prednosten seznam zahtev (angl. Product Backlog). Seznam se razvija skozi ˇzivljenjsko dobo izdelka in predstavlja zemljevid izdelka. Ob- staja samo en tak seznam. To pomeni, da more lastnik izdelka doloˇcati pri- oritete, zastopati interese deleˇznikov in upoˇstevati vpliv razvojne ekipe [48].
Razvoj poteka cikliˇcno v iteracijah (angl. Sprint) [48]. Posamezna ite- racija ne traja veˇc kot mesec dni in se izvajajo ena za drugo brez premora.
Sprinti so ˇcasovno omejeni. To pomeni, da se zaˇcnejo in konˇcajo na doloˇcen datum, ne glede na to, ali je bilo delo konˇcano. Nikoli se ne podaljˇsajo. Med
ciklom ni dovoljena nobena sprememba, ki bi ogrozila cilj cikla (angl. Sprint Goal).
Na zaˇcetku vsake iteracije si ekipa izbere elemente iz prednostnega se- znama zahtev. To poteka na sestanku za naˇcrtovanje iteracije (angl. Sprint Planning Meeting). Ekipa se zavezuje, da bo elemente dokonˇcala do konca iteracije. Posamezne elemente se razbije v seznam nalog (angl. Sprint Backlog).
Ko se Sprint zaˇcne, se ekipa udeleˇzuje dnevnih sestankov (angl. Daily Scrum). To je kratek sestanek, ki traja 15 minut ali manj, in poteka vsak delovni dan ob dogovorjenem ˇcasu. Udeleˇzijo se ga vsi ˇclani razvojne ekipe.
Na sestanku vsak ˇclan poroˇca o treh stvareh [48]:
1. Kaj so uspeli narediti od zadnjega sestanka?
2. Kaj nameravajo narediti do naslednjega sestanka?
3. So pri svoje delu naleteli na morebitne prepreke?
Iteracija se zakljuˇci s sestankom za pregled rezultatov (angl. Sprint Re- view meeting), na katerem je prisotna celotna Scrum ekipa, poleg tega pa je lahko prisotna tudi stranka, deleˇzniki, strokovnjaki in vsi drugi zainteresi- rani. To je tudi ˇcas, za poglobljen pogovor med razvojno ekipo in lastnikom izdelka, da se pregleda situacijo na strani lastnika izdelka in na strani ra- zvojne ekipe. Sestanek vkljuˇcuje tudi demonstracijo, kaj je ekipa naredila med iteracijo.
Pregledu sledi retrospektiva (angl. Sprint Retrospective meeting), ki jo organizira skrbnik metodologije. Na tem sestanku celotna ekipa razpravlja o pravkar konˇcani iteraciji in ugotavlja, kaj bi lahko spremenili na naslednji iteraciji, da bi bila ta boljˇse izvedena in produktivnejˇsa.
2.2.9 Metoda Kanban
Kanban je bil prvotno del Toyotinega proizvodnega sistema v petdesetih letih prejˇsnjega stoletja, ki se ravna po konceptu Ravno ob pravem ˇcasu
(angl. Just In Time – JIT). Koncept JIT sledi principom, da se naredi samo, kar je potrebno, ko je potrebno in kolikor je potrebno. S pomoˇcjo Kanbana so poveˇcali produktivnost in zmogljivost ter zmanjˇsali povpreˇcen ˇcas izdelave [49].
Zaˇcetki vkljuˇcevanja Kanban metode v razvoj programske opreme so po- vezane z Davidom J. Andersenom [5], ko ga je Microsoft povabil, da pomaga manjˇsi razvojni ekipi pri boljˇsi vizualizaciji delovnega toka in omejevanju koliˇcine dela v teku. Proces uspeˇsnega izvajanja pa se zaˇcne s sprejetjem temeljnih naˇcel:
- Zaˇcnite s tem, kar imate zdaj — to je vaˇs trenutni proces.
- Strinjati se z evolucijskim pristopom k spremembam in izboljˇsavam.
- Spoˇstujte trenutne vloge in odgovornosti ekipe/organizacije.
Rezultat tega je pet naˇcel za izvajanje Kanbana [5]:
1. Vizualizacija dela in potek dela, ki sledi.
2. Zmanjˇsevanje koliˇcine dela v teku z uporabo virtualnega Kanban sis- tema.
3. Obvladovanje toka.
4. Naj bo politika upravljanja izrecna.
5. Uporaba modelov in znanstvenih metod ter izboljˇsanje sodelovanja.
David Anderson je prviˇc uporabil izraz “virtualna Kanban tabla” [24].
Kanban tabla je orodje agilne metodologije, ki pomaga vizualizirati delo, omejiti delo v teku in poveˇcati uˇcinkovitost. Tako agilnim kot tudi DevOps ekipam lahko pomaga vzpostaviti red pri vsakodnevnem delu. Kanban table s pomoˇcjo kartic, stolpcev in stalnih izboljˇsav pomagajo ekipi, da se posvetijo potrebni koliˇcini dela in ga opravijo. Primer table je prikazan na sliki 2.5.
Slika 2.5: Kanban tabla
David Anderson je ugotovil, da je mogoˇce Kanban tablo razdeliti na pet komponent: vizualni signali, stolpci, omejitve dela v teku, toˇcka zavzetosti in toˇcka dostave [53].
Vizualni signali (angl. Visual Signals). Ena od prvih stvari, ki jih boste opazili na Kanban tabli, so vizualne kartice. Kanban ekipa vse svoje projekte in delovne elemente zapiˇsejo na kartice, obiˇcajno enega na kartico. Za agilne ekipe bi lahko vsaka kartica predstavljala eno upo- rabniˇsko zgodbo. Ko so ti vizualni signali enkrat na tabli, pomagajo vsem ˇclanom, da hitro razumejo na ˇcem ekipa dela.
Stolpci (angl. Columns). ˇSe en znak Kanban table so stolpci. Vsak stolpec predstavlja doloˇceno aktivnost, ki skupaj sestavlja potek dela. Kartice
se premikajo skozi potek dela do zakljuˇcka. Potek dela je lahko zelo preprost kot “Opraviti”, “V teku”, “Dokonˇcano”, ali pa veliko zaplete- nejˇse.
Omejitve dela v teku (angl. Work In Progress (WIP) Limits). Pome- nijo najveˇcje ˇstevilo kartic, ki so lahko v doloˇcenem trenutku v enem stolpcu. Stolpec, ki ima omejitev tri, ne sme imeti veˇc kot treh kar- tic. Ko je stolpec “zapolnjen”, mora ekipa na teh karticah delati in jih premakniti naprej, preden se nove kartice lahko premaknejo v to fazo poteka dela. Te omejitve so kljuˇcne za razkritje ozkih grl.
Toˇcka zavzetosti (angl. Commitment point). Kanban ekipe imajo pogosto seznam zahtev (angl. Backlog) v svoji tabli. Tu stranka in ekipa po- stavljajo ideje za projekt, ki jih lahko ekipa pobere, ko so pripravljene.
Toˇcka zavzetosti je trenutek, ko ekipa prevzame idejo in zaˇcne delo na projektu.
Toˇcka dostave (angl. Delivery point). Toˇcka dostave je konec delovnega toka za ekipo. Za veˇcino ekip je to takrat, ko je izdelek ali storitev v rokah stranke. Cilj ekipe je, da kar najhitreje vzame kartico od toˇcke zavzetosti do toˇcke dostave. Preteˇceni ˇcas med njima je tako imenovani ˇcas izdelave (angl. Lead Time). Ekipa se nenehno izboljˇsuje, ˇce se njihov ˇcas vodenja skrajˇsuje.
Prednosti Kanban metode je prav gotovo prilagodljivost procesa in zmanjˇsevanje ˇcasovnega cikla. Osredotoˇca se na neprekinjeno dostavo in ni omejena na ite- racije. Sama metoda je enostavna za razumevanje in pri le-tej ni potrebno definirati vlog na projektu, kakor je to na primer pri metodi Scrum. Stremi k poveˇcanju produktivnosti in uˇcinkovitosti [24].
Opredelitev situacijskega
pristopa k agilnemu razvoju programske opreme elementov
V tem poglavju je opisan postopek opredelitve pristopa. Zaˇcne se z oceno primernosti potencialnih elementov. V nadaljevanju sledi opis ocenjevanja potencialnih elementov in priprava ankete. Zakljuˇci se z izvedbo fokusne delavnice. Proces pristopa je prikazan na sliki 3.1.
Slika 3.1: Proces pristopa 27
3.1 Potencialni elementi
Potencialni elementi so bili izbrani na podlagi pregleda literature pogosto uporabljenih agilnih metod razvoja programske opreme. Potrebno je bilo tudi upoˇstevati velikost in organizacijo podjetja. Seznam potencialnih ele- mentov pa mora seveda upoˇstevati tudi tiste kljuˇcne elemente, ki jih konkre- tno podjetje, ki uporabi pristop, ˇze uporablja.
Tabela 3.1 prikazuje konˇcen seznam elementov, ki so bili vkljuˇceni v anketo, po fazah razvoja programske opreme. V tretjem stolpcu je naveden vir, ki le-tega predlaga.
Faza Elementi posamezne faze Vir
1. Zajem zahtev Vodene delavnice (angl. Workshops) [17]
Opazovanje uporabnikov (angl. Observation of anonymous users)
[14]
Intervjuji (angl. Interviews) [18]
Dokument opredelitve zahtev programske opreme (angl. Software requirements specifi- cation document)
[3]
Uporabniˇske zgodbe (angl. User stories) [29]
Prototip (angl. Prototype) [15]
2. Arhitektura in oblikovanje
Agilno atributno voden razvoj (angl. Attri- bute driven Agile Development)
[21]
Planiranje po funkcionalnosti (angl. Plan by feature)
[36]
Model UML – Poenoteni jezik modeliranja (angl. Unified Modeling Language model – UML)
[56]
3. Razvoj Enotedenska iteracija [44]
Tritedenska iteracija [44]
Neprekinjena dostava (angl. Continuous deli- very)
[35]
Dnevni Scrum sestanek (angl. Daily Scrum) [6]
Dnevni sestanek “na nogah” (angl. Standup meeting)
[46]
Sestanek veˇckrat na teden, ne pa nujno vsak dan
[45]
Sprint planning sestanek (angl. Sprint plan- ning)
[42]
Sestanek “Igra naˇcrtovanja” (angl. Planning Game)
[6]
Sestanek za doloˇcanje prioritet (angl. Queue replenishment meeting)
[27]
Programiranje v paru (angl. Pair program- ming)
[41]
Pregled kode (angl. Code review) [10]
Skupno lastniˇstvo nad kodo (angl. Collective Code Ownership)
[22]
Sprint Retrospektiva (angl. Retrospective) [32]
Ocena dostave (angl. Service Delivery Re- views)
[39]
4. Testiranje Raziskovalno testiranje (angl. Exploratory te- sting)
[47]
Testiranje uporabnosti (angl. Usability te- sting)
[25]
Enotsko testiranje (angl. Unit testing) [51]
Testno voden razvoj (angl. Test Driven Deve- lopment)
[23]
5. Implementacija Raˇcunalniˇsko izobraˇzevanje (angl. Computer Based Training – CBT)
[55]
Izobraˇzevanje kljuˇcnih uporabnikov (angl.
Key users training)
[30]
Indvidualno izobraˇzevanje konˇcnih uporabni- kov (angl. Individual End-User Training)
[34]
Tabela 3.1: Seznam potencialnih elementov
3.2 Doloˇ citev anketnih vpraˇ sanj
Po pregledu literature je bilo ugotovljeno, da oceno uspeˇsnosti elementa opre- deljuje veˇc kriterijev, ki pa se lahko razlikujejo glede na vlogo udeleˇzenca na projektu. Udeleˇzenci na projektu so razdeljeni v tri glavne skupine, ki so aktivno vkljuˇcene ob razvoju vsakega projekta: razvojna ekipa, tehniˇcni del in vodstvo.
Na podlagi literature so bila oblikovana vpraˇsanja za posamezno skupino.
V spodnjih tabelah so razvidna sama vpraˇsanja oziroma trditve, strokovna literatura, ki predlaga to vpraˇsanje, ter razlog zastavitve vpraˇsanja.
Vpraˇsanja za razvojno ekipo so prikazana v tabeli 3.2.
Vpraˇsanje Razlogi Vir Uporaba elementa v tej fazi moˇcno
skrajˇsa razvojni ˇcas.
Dejanska uporaba elementa.
Efektivnost.
[7]
Uporaba elementa v tej fazi pomembno poveˇca kvaliteto konˇcnega produkta.
Ponos.
Dobri odnosi s stranko.
Zadovoljstvo z lastnim delom.
[20]
Uporaba elementa v tej fazi bo moˇcno poveˇcala moje zadovoljstvo na delovnem mestu.
Zadovoljstvo.
Veˇcja motivacija.
Manjˇse tveganje, da bo razvi- jalec zapustil podjetje.
[40]
Tabela 3.2: Vpraˇsanja za razvojno ekipo
Vpraˇsanja za tehniˇcni delso prikazana v tabeli 3.3.
Vpraˇsanje Razlogi Vir
Uporaba elementa v tej fazi moˇcno skrajˇsa razvojni ˇcas.
Doseˇzeni roki. [7]
Uporaba elementa v tej fazi pomembno poveˇca kvaliteto konˇcnega produkta.
Pogostost izpadov zaradi ne- pravilnega delovanja.
[20]
Ce bi imeli moˇˇ znost uporabljati ta element v tej fazi, kako pogosto bi ga uporabljali?
Koliko je element primeren za podjetje.
[20]
Ali je element skladen z naˇsim naˇcinom dela v tej fazi?
Stroˇski prilagajanja.
Moˇznost odpora pri podreje- nih.
[52]
Tabela 3.3: Vpraˇsanja za tehniˇcni del
Vpraˇsanja za vodstvoso prikazana v tabeli 3.4.
Vpraˇsanje Razlogi Vir Uporaba elementa v tej fazi moˇcno
skrajˇsa razvojni ˇcas.
Zanesljiv posloven partner. [7]
Uporaba elementa v tej fazi pomembno poveˇca kvaliteto konˇcnega produkta.
Pripomore k ugledu firme in zmanjˇsanje resursov pri vzdrˇzevanju.
[20]
Element v tej fazi pomaga zmanjˇsati razvojne stroˇske pro- dukta.
Finanˇcni vidik. [7]
Element v tej fazi pomaga podje- tju pri doseganju ciljev tako, da se osredotoˇci na enega ali nekaj se- gmentov.
Uresniˇcevanje smeri podjetja. [20]
Tabela 3.4: Vpraˇsanja za vodstvo
Za konˇcno potrditev ali ovrˇzbo je bilo pri vsakem elementu dodana trdi- tev: “Uporaba elementa je nujna za uspeˇsno in uˇcinkovito izvedbo te faze.”.
3.3 Anketa
Za laˇzjo preglednost pri tako dolgi anketi je bila le-ta razdeljena po fazah razvoja programske opreme. Na vsakem delu – fazi so bili najprej naˇsteti potencialni elementi in kratek opis vsakega elementa.
Za ocenjevanje je bila izbrana Likertova lestvica s sedmimi stopnjami, od
“Sploh se ne strinjam” do “Povsem se strinjam”. To pomeni, da je bilo naj- manjˇsa ocena ena in najviˇsja ocena sedem. Lestvica je bila za vsa vpraˇsanja in elemente enaka. Zaradi razliˇcnih vpraˇsanj za posamezno skupino, so bile narejene tri razliˇcne ankete z enakimi potencialnimi elementi. Del ankete je viden na sliki 3.2.
Slika 3.2: Del ankete
3.4 Fokusna delavnica
Fokusna delavnica sluˇzi predstavitvi rezultatov ankete in doloˇcitvi metode razvoja programske opreme. Na delavnici naj bodo prisotni predstavniki vseh treh skupin. Spodbuja naj se izmenjava mnenj in izkuˇsenj. Sliˇsane morajo biti vse tri skupine. Cilj delavnice je oblikovana metoda razvoja programske opreme, doseˇzena v konsenzu.
Studija primera ˇ
4.1 Predstavitev podjetja
Podjetje Akademika d. o. o. je bilo ustanovljeno 22. 10. 2008. ˇStartali so ga ˇstirje dobri sodelavci z jasno vizijo. Od zaˇcetne ˇstevilke 4 podjetje raste in trenutno ˇsteje 19 zaposlenih. Ukvarja se z vzpostavitvijo dokumentnih sistemov ter se specializira za upravljanje dokumentov in procesov v SAP sistemu. Naloga Akademike je poenostaviti podjetjem in poslediˇcno njihovim zaposlenim vsakdanje naloge in jih v ˇcim veˇcji meri avtomatizirati. Podjetje ponuja bogato paleto svojih izdelkov in storitev – s SAP AdOn produkti, DMS produkti in ostalimi produkti. Strategija podjetja temelji na naˇcelih trajnostnega razvoja in se kaˇze v skrbi za stranke, zaposlene, sponzorski in donatorski podpori razliˇcnim projektom (dobrodelni, gasilski, akademski).
Podjetje utrjuje poloˇzaj enega vodilnih ponudnikov obvladovanja pro- cesov znotraj SAP in glavni DMS ponudnik za podjetja z ERP sistemom SAP v Sloveniji. Vizija podjetja je, da to postane na celotnem obmoˇcju JV Evrope. To dosega z razvojem samostojnih reˇsitev in hkrati s krepitvijo dolgoroˇcnih poslovnih povezav in partnerskih odnosov na podroˇcju trˇzenja razvojnih projektov. Uspeˇsno pa ˇze danes deluje tudi na obmoˇcju Zahodne Evrope, predvsem v Nemˇciji.
Podjetje se deli na veˇc razliˇcnih razvojnih delov. Najveˇcji del oddelka 35
razvija in skrbi za SAP reˇsitve, ostali del pokriva razvoj v povezavi z do- kumentnimi sistemi. Prav tako podjetje dela na implementaciji standardnih produktov. Poleg razvoja so nepogreˇsljiv del zaposleni, ki delajo v podpori in prodaji.
Ne glede na rast podjetja skozi leta je Akademika ˇse vedno relativno majhno podjetje. To pomeni, da ni obiˇcajno, da bi zaposlen v razvojni ekipi delal izkljuˇcno samo na enem projektu. Vsakdanje je, da naenkrat dela nekdo tudi na veˇc projektih, vzdrˇzuje obstojeˇce produkte in komunicira s stranko.
4.2 Predstavitev rezultatov
Po izpolnitvi ankete so bili najprej zbrani rezultati. Najveˇcje ˇstevilo anket je bilo oddanih s strani razvojne ekipe, sledita jim tehniˇcni del in vodstvo.
Najprej je bilo izraˇcunano povpreˇcje posameznega vpraˇsanja po skupinah.
Potem pa je sledila obdelava rezultatov glede na oceno elementa in uˇcinkovita izvedba, ki predstavlja zadnje vpraˇsanje.
Vodstvo je predstavljalo najmanj ˇstevilˇcno skupino. Razpon ocen je bil pri tej skupini najveˇcji. Zanimivo je bilo, da so na zastavljena vpraˇsanja podobno odgovarjali. Poslediˇcno so imeli elementi podobne skupne ocene glede na posameznika v skupini vodstva. Razvojna ekipa, ki je ˇstevilˇcno tudi najveˇcja, je zelo razliˇcno ocenjevala enak element in so je konˇcna povpreˇcna ocena posameznega elementa zelo malo razlikovala.
Posebej so bili narejeni grafi primerjav za oceno elementa in za uˇcinkovito izvedbo. Grafi ponazarjajo primerjavo med vsemi tremi skupinami – med vodstvom in tehniˇcnim delom, tehniˇcnim delom in razvojem ter razvojem in tehniˇcnim delom. Glede na mediano ocen posamezne skupine je bil graf razdeljen na ˇstiri kvadrante, kakor prikazuje slika 4.1. Razdelitev glede na mediano, je bila izbrana zaradi majhne razlike med minimumom in maksi- mumom ocen razvoja in tehniˇcnega dela. Rezultati ankete in pripadajoˇci grafi za oceno elementa se nahajajo v prilogi A.1, za uˇcinkovito izvedbo pa v prilogi A.2. V vsakem grafu je poleg toˇcke ˇstevilka, ki predstavlja zaporeden
Slika 4.1: Primer grafa
element glede na tabelo rezultatov.
V prvem kvadrantu so zajeti potencialni elementi, ki so bili najslabˇse ocenjeni s strani obeh skupin, katerih ocene so prikazane na grafu. V drugem in tretjem kvadrantu so elementi, ki jih je ena skupina visoko ocenila in druga nizko. Elementi v ˇcetrtem kvadrantu so tisti, ki so bili najviˇsje ocenjeni s strani obeh skupin. To pomeni, da so jim naklonjeni obe skupini in so zanimivi za predlogo metode.
Po priˇcakovanjih skupine niso bile sloˇzne glede izbire elementov za posa- mezno fazo. V ta namen je bil organizirana fokusna delavnica.
4.3 Doloˇ citev agilne metode razvoja program- ske opreme
Za oblikovanje metode je bila organizirana fokusna delavnica, katere namen je bil oblikovati metodo iz predlaganih elementov, ki bi ˇcim bolj ustrezala specifiˇcnemu podjetju, v povezavi z naˇcinom dela podjetja in projekti, pred- vsem pa v konsenzu z vsemi skupinami. Na delavnici je bilo prisotno celotno vodstvo, tehniˇcni del in del razvojne ekipe. Delavnica je bila bolj debatnega znaˇcaja z dvema ciljema – predstavitev rezultatov in oblikovanje metode.
Poleg predstavitve rezultatov je bila tukaj konstantna spodbuda k priso- stvovanju in izraˇzanju svojega mnenja. S tem smo dosegli vkljuˇcenost vseh interesnih skupin.
Rezultati so predstavljeni po fazah razvoja. Za vsako fazo posebej so bili preko pogovora in skupnega konsenza izbrani elementi z najveˇcjo podporo.
4.3.1 Zajem zahtev
Vse tri skupine so bile v anketi soglasne, da se brez vodenih delavnic in do- kumenta opredelitve zahtev programske opreme ne more izvesti faze zajema zahtev. Potrditev je bila dana tudi na delavnici. Ta dva elementa izhajate sicer ˇze iz prakse.
Pri vodenih delavnicah je bilo izpostavljeno, kako je pomembno, kdo je prisoten na teh delavnicah. Iz predstavljenih izkuˇsenj je sledilo, da je naj- boljˇsa praksa, da je na strani podjetja poleg vodje projekta obvezno prisoten tudi vodja razvojne ekipe in/ali arhitekt. Na strani stranke se po navadi stvari malo zapletenejˇse. Poleg vodje projekta na strani stranke morajo biti prisotni tudi kljuˇcni uporabniki. Slednji morajo poznati delovne procese in jih objektivno predstaviti. Nemalokrat se zgodi, da vsak uporabnik svoje zahteve podaja individualistiˇcno in ne vidi ˇsirˇse slike. Izbor kljuˇcnih uporab- nikov se lahko iz tega razloga tudi veˇckrat spremeni tekom procesa razvoja programske opreme.
Pri oblikovanju zahtev pa pomaga tudi prototip, ki je tudi eden izmed iz-
branih elementov za fazo zajema zahtev, vendar z doloˇcenimi prilagoditvami.
Stranki je v veˇcino primerih dobrodoˇslo, da ˇcimprej vidi, kako pribliˇzno bo izgledal konˇcni produkt. Specifiˇcnemu podjetju ni sprejemljivo, da bi pora- bili preveˇc ˇcasa za prototip, ki na koncu ne bi bil uporaben. Predlagan pa je bil t. i. ˇziˇcni model (angl. wireframe) z doloˇceno mero interaktivnosti. To pomeni, da niso samo slike, ampak npr. klik na gumb, kar pomeni premik na drugo okno aplikacije.
Popis vseh zahtev mora biti obvezno v Dokumentu opredelitve zahtev programske opreme. S potrditvijo tega dokumenta se naroˇcnik strinja, da je bil proces v celoti opredeljen in da dokument vsebuje vse zahteve s strani naroˇcnika. Pogosto tekom projekta pride do sprememb, dopolnitev ali nespo- razumov in ravno ta dokument je potem podlaga za ugotavljanje in pisanje morebitnih dopolnitev ali ugotavljanje napak.
S strani razvoja so bili dobro ocenjeni tudi intervjuji in uporabniˇske zgodbe. Vseeno pa so vse skupine priˇsle do skupnega zakljuˇcka, da bi in- tervjuji vzeli preveˇc ˇcasa in resursov. Pri uporabniˇskih zgodbah bi bilo potrebno trenutno vloˇziti preveˇc truda za vpeljavo. Mogoˇce bi pa o tem elementu razmiˇsljali v prihodnosti.
4.3.2 Arhitektura in oblikovanje
Arhitekturen del te faze je kompleksen in veˇcplasten. Zelo je tudi preple- ten s fazo zajema zahtev. Pri produktih po navadi stranka v doloˇceni meri definira arhitekturo sistema s svojimi zahtevami po operacijskem sistemu in podatkovni bazi.
Vse tri skupine so bile zelo naklonjene elementu Planiranje po funkcional- nost, ki je bil takoj dodan na seznam elementov metode razvoja programske opreme. Drugaˇcna zgodba pa je bila pri elementu Agilno atributno voden razvoj. Zelo visoko je bil ocenjen s strani vseh treh vlog. Preko pogovora in razlage je bilo ugotovljeno, da gre tukaj za celotno metodo. Absolutno je bil koncept zanimiv vsem, vendar trenutno predstavlja preveˇc dela za vpeljavo, zato je bil zaenkrat postavljen na stranski tir in ni bil izbran v metodo.
Na drugi strani pa je bil izpostavljen element Poenoteni jezik modeliranja.
Tehniˇcni del mu je dal visoko oceno. Bilo pa je predlagano, da bi bil delno vkljuˇcen, kar pomeni, da bi bil model UML vkljuˇcen v smislu diagramov, brez generacije kode.
4.3.3 Razvoj
Razvoj je najobˇsirnejˇsa faza in ima poslediˇcno najveˇc predlaganih elementov.
Tudi na fokusni delavnici smo se najdlje ustavili pri tej fazi. Ob gledanju zgolj na rezultate, je zanimivo to, da noben izmed elementov razvojnega cikla ni priˇsel v ˇcetrti kvadrant pri grafih primerjav med enim in drugim delom.
In prav s tem se je zaˇcela debata pri fazi razvoja.
Vodstvo je ocenilo enotedensko iteracijo kot najboljˇso, tehniˇcni del pa ji ni bil naklonjen. Na koncu so vsi ugotovili in potrdili, da je za specifiˇcno podjetje in trenuten naˇcin delovanja najprimernejˇsi element Neprekinjena dostava, zato enotedenska iteracija ni izbrana. Poudarjeno pa je bilo, da je potrebno delati na izboljˇsavi avtomatizacije dostave.
Sestanki so pomemben del vsakega razvoja programske opreme. V pri- meru tega podjetja je veˇckrat tako, da nekdo ne dela ekskluzivno samo na enem projektu. Iz tega dejstva je sledila izbira elementa Dnevni sestanek na nogah po posameznem oddelku, ki tudi vkljuˇcuje prvine dnevnega Scrum sestanka. Na sestanku tako vsak pove, kaj je delal prejˇsnji dan, ˇce so kje kakˇsne teˇzave in kaj je plan za danaˇsnji dan. Ni pa nujno, da je dnevni sestanek sestavljen samo iz tega dela, vendar naj bo karseda kratek. Poleg tega pa je bil dodan tudi sestanek za doloˇcanje prioritet, ki je bil zelo visoko ocenjen. Le-ta naj se izvaja enkrat na teden.
Metodi je bil dodan tudi element Skupno lastniˇstvo nad kodo, ki bo pri- pomoglo k kvalitetnejˇsi kodi. Vodstvo ni bilo najbolj naklonjeno elementu Pregled kode zaradi morebitne ˇcasovne potratnosti. Razvoj in tehniˇcni del je izbiro tega elementa oznaˇcil za nepogreˇsljivega. Tudi ˇce v doloˇceni meri podaljˇsa ˇcas razvoja, v ˇcasu vzdrˇzevanja zmanjˇsa ˇcas in pripomore k zado- voljstvu stranke zaradi manj napak. Vodstvo se je na koncu strinjalo, zato
je bil dodan tudi element Pregled kode. Omenjen je bil tudi element Pro- gramiranje v paru, ki je bil visoko ocenjen s strani razvoja in tehniˇcnega dela, vodstvo pa ga je ocenilo zelo slabo. Tudi na delavnici je bilo vodstvo enotno, da se ta element ne more uvrstiti v seznam elementov metode, ker pri manjˇsem podjetju to ne bi bilo profitabilno.
4.3.4 Testiranje
Raziskovalno testiranje je bilo od vseh elementov v fazi testiranja na prvem mestu. Za to testiranje ni potrebno vnaprej doloˇcenih scenarijev in priprave, hkrati pa je dober naˇcin odkrivanje napak in omejitev produkta.
Tako vodstvu kot razvoj je na drugo mesto postavil element Testiranje uporabnosti. Velikokrat se premalo ˇcasa posveˇca testiranju enostavnosti in logiˇcnosti uporabe samega produkta. Glede na to, da je eno izmed vodil specifiˇcnega podjetja poenostaviti strankam vsakdanje delo, je ta element dobil pomembno mesto v metodi.
Debata je na fokusni delavnici tekla tudi o elementu Enotsko testiranje.
Razvoj je temu elementu dal dobro oceno. Trenutno ni dovolj pomemben, da bi ga uvrstili v konˇcni seznam metode. Je pa bil podan predlog, da bi se v bliˇznji prihodnosti delalo na vpeljavi avtomatiziranega enotskega testiranja.
Udeleˇzenci so tudi izpostavili, da je potrebno dodati manjkajoˇce elemente.
Manjkati ne smeta testiranje obremenitve (angl. stress test) in integracijska testiranja (angl. integration testing).
4.3.5 Implementacija
Pri implementaciji so bili vsi naklonjeni izobraˇzevanju kljuˇcnih uporabnikov in je bil ta element brez dvoma takoj potrjen. To pomeni, da peˇsˇcico upo- rabnikov, ki so bili v veˇcini primerov prisotni tudi na vodenih delavnicah, izobrazimo. Ti uporabniki dobro poznajo produkt in vse procese do te mere, da lahko izobrazijo svoje sodelavce.
Izbrano je bilo tudi raˇcunalniˇsko izobraˇzevanje. Na tem elementu bi bilo
potrebno bolj delati in ga v prihodnosti razˇsiriti, predvsem v smislu uporab- niku prijazne dokumentacije in video vadnic.
4.4 Oblikovana agilna metoda razvoja pro- gramske opreme
Cilj delavnice je bil doseˇzen in s konsenzom so preˇsli potencialni elementi v izbrane elemente. Tabela 4.1 prikazuje izbrane elemente, ki so bili izbrani v prvotni definiciji, spet drugi so bili dodani z modifikacijami.
Faza Elementi posamezne faze
1. Zajem zahtev Vodene delavnice (angl. Workshops)
Dokument opredelitve zahtev programske opreme (angl. Software requirements specifica- tion document)
Prototip (angl. Prototype) 2. Arhitektura in
oblikovanje
Planiranje po funkcionalnosti (angl. Plan by fe- ature)
Model UML – Poenoteni jezik modeliranja (angl.
Unified Modeling Language model – UML) 3. Razvoj Neprekinjena dostava (angl. Continuous deli-
very)
Dnevni sestanek “na nogah” (angl. Standup me- eting)
Sestanek za doloˇcanje prioritet (angl. Queue re- plenishment meeting)
Pregled kode (angl. Code review)
Skupno lastniˇstvo nad kodo (angl. Collective Code Ownership)
4. Testiranje Raziskovalno testiranje (angl. Exploratory te- sting)
Testiranje uporabnosti (angl. Usability testing) Testiranje obremenitve (angl. Stress test) Integracijska testiranja (angl. Integration te- sting)
5. Implementacija Raˇcunalniˇsko izobraˇzevanje (angl. Computer Based Training – CBT)
Izobraˇzevanje kljuˇcnih uporabnikov (angl. Key users training)
Tabela 4.1: Konˇcen seznam elementov
4.5 Predstavitev predloga vodstvu in povra- tna informacija vodstva
Potrebno je omeniti, da je bilo celotno vodstvo prisotno na delavnici in po- slediˇcno je seznanjeno in ˇze potrdilo vse izbrane elemente za posamezno fazo.
Posebej jim je bilo podano tudi poroˇcilo delavnice. Po delavnici je bil izve- den sestanek z namenom pridobivanja povratne informacije. Delavnica je zanje predstavljala spodbudo, da se podjetje razvija tudi v tej smeri, da so potrebne spremembe ter da se oblikujejo vloge na projektu, ki so bile mogoˇce prej zabrisane. Priˇcakovano je bilo, da vodstvo pri vseh organizacijskih spre- membah gleda s finanˇcnega vidika. Koliko resursov, ˇcasa porabijo za uvajanje teh sprememb.
Sama delavnica je bila nad priˇcakovanji – bila je zelo dobro sprejeta s strani vodstva. Zanje to ni bila neka stvar, ki bi jim bila odveˇc, ˇse manj po- trata ˇcasa. Imajo pa zaradi dolgoletnih izkuˇsenj dela z razliˇcnimi metodami in poslediˇcno elementi zelo dobro izoblikovano mnenje in naklonjen oziroma odklonilen odnos do doloˇcenih elementov. Teˇzko je tudi uporabiti samo eno
metodo za vse projekte, ki se zelo razlikujejo po obseˇznosti in sami obliki ter namenu.
