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.
Zakljuˇ cek
V diplomskem delu smo predstavili situacijski pristop k oblikovanju agilne metode razvoja programske opreme. Preko pregleda literature smo najprej sodelujoˇce na projektu razdelili na tri skupine in jim zastavili vpraˇsanja glede na njihovo vlogo. Rezultati ankete so sluˇzili kot odskoˇcna deska v poglobljeno diskusijo, izmenjavo mnenj in doloˇcitev agilne metode razvoja programske opreme, ki bi specifiˇcnemu podjetju kar najbolj ustrezala.
Tekom ustvarjanja smo se sreˇcali s ˇstevilnimi izzivi. Prvi je bil prav gotovo sam izbor potencialnih elementov, ki bi ustrezali podjetju. ˇSe veˇcji izziv pa je bil samo oblikovanje konˇcnega pristopa. Na delavnici smo se sreˇcali z veliko razliˇcnimi mnenji deleˇznikov v podjetju, ki so izhajale iz njihovih izkuˇsenj in osebnih preferenc, zato je tudi oblikovanje agilne metode kompleksna naloga na veˇc razliˇcnih nivojih. Velik del zahtevnosti je prav gotovo posluˇsanje in razumevanje ter sprejemanje mnenj vseh sodelujoˇcih v podjetju. Potrebno je doseˇci kompromis med vsemi skupinami in dati visoko podporo novemu naˇcinu razvoja programske opreme. Le tako lahko metoda dejansko zaˇzivi in se uporablja ter ne bo ostala samo na papirju.
Konˇcna misel zaposlenih na fokusni delavnici je bila, da oblikovana me-toda predstavlja temelj, na katerem se lahko gradi. Upoˇstevati bi bilo po-trebno tudi pomembne opombe, da ne glede na razporeditev elementov po fazah razvoja, se le-te velikokrat prepletajo. Tak primer je, da je potrebno
45
definirati sistemske zahteve ˇze v fazi zajema zahtev. Agilen model mora sle-diti svoji definiciji, kar pomeni, da se mora hitro odzivati in prilagajati na okoliˇsˇcine ter spremembe.
V nadaljevanju bi se bilo zanimivo posvetiti naˇcinu vpeljave teh elemen-tov v vsakodnevnem procesu razvoja. Kasneje pa tudi spremljanje same uporabe metode in dokumentiranje le-te. Smiselno bi bilo ˇcez nekaj ˇcasa ponovno izvesti enako anketo in oceniti posamezne elemente ter dodati nove.
Smiselno pa bi bilo tudi spodbujati zaposlene k prisostvovanju pri izboljˇsavah posameznega elementa. Vodstvo je tudi predlagalo, da se na obdobje pol leta izvede pogovor, retrospektivo na preteklo obdobje in naredi plan za nasle-dnje obdobje. S tem se o tej temi ohranja diskusijo ˇzivo in v razvoju. Kakor se podjetje stalno razvija in raste, se mora poslediˇcno razvijati tudi metoda razvoja programske opreme.
[1] Adetokunbo Adenowo in Basirat Adenowo. “Software Engineering Me-thodologies: A Review of the Waterfall Model and Object-Oriented Approach”. V: International Journal of Scientific & Engineering Re-search 4.7 (2013), str. 427–434.
[2] Suyash Agrawal. “Using Rapid Application Development for Software Development Projects”. Doktorska disertacija. Purdue University Gra-duate School, 2019.
[3] Naveed Ali in Richard Lai. “A method of software requirements spe-cification and validation for global software development”. V: Require-ments Engineering 22.2 (2017), str. 191–214.
[4] Scott Ambler in sod. The Agile Unified Process (AUP). 2005. url: http://www.ambysoft.com/unifiedprocess/agileUP.html (prido-bljeno 22. 1. 2022).
[5] David J Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
[6] Faiza Anwer in sod. “Comparative Analysis of Two Popular Agile Pro-cess Models: Extreme Programming and Scrum”. V:International Jo-urnal of Computer Science and Telecommunications 8.2 (2017), str. 1–
7.
[7] Roger Atkinson. “Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria”.
47
V: International journal of project management 17.6 (1999), str. 337–
342.
[8] Kent Beck. “Embracing Change with Extreme Programming”. V: Com-puter 32.10 (1999), str. 70–77.
[9] Kent Beck.Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, 1999.
[10] Mario Bernhart, Andreas Mauczka in Thomas Grechenig. “Adopting code reviews for agile software development”. V:2010 Agile Conference.
IEEE. 2010, str. 44–47.
[11] Barry Boehm. “A spiral model of software development and enhan-cement”. V: ACM SIGSOFT Software engineering notes 11.4 (1986), str. 14–24.
[12] Barry W Boehm. “A spiral model of software development and enhan-cement”. V:Computer 21.5 (1988), str. 61–72.
[13] A Brief History of Project Management. 2021. url: https : / / www . projectsmart . co . uk / history of project management / brief -history-of-project-management.php(pridobljeno 29. 11. 2021).
[14] Olesia Brill in Eric Knauss. “Structured and Unobtrusive Observa-tion of Anonymous Users and their Context for Requirements Elici-tation”. V: 2011 IEEE 19th International Requirements Engineering Conference. IEEE. 2011, str. 175–184.
[15] Dante Carrizo in Iv´an Quintanilla. “Prototyping Use as a Software Re-quirements Elicitation Technique: A Case Study”. V:World Conference on Information Systems and Technologies. Springer. 2018, str. 341–350.
[16] YC Chiu.An Introduction to the History of Project Management: From the earliest times to AD 1900. Eburon Uitgeverij BV, 2010.
[17] Chad Coulin, Didar Zowghi in Abd-El-Kader Sahraoui. “A Situational Method Engineering Approach to Requirements Elicitation Workshops in the Software Development Process”. V: Software Process: Improve-ment and Practice 11.5 (2006), str. 451–464.
[18] Alessio Ferrari, Paola Spoletini in Stefania Gnesi. “Ambiguity and Tacit Knowledge in Requirements Elicitation Interviews”. V: Requirements Engineering 21.3 (2016), str. 333–355.
[19] Martin Fowler, Jim Highsmith in sod. “The Agile Manifesto”. V: Soft-ware development 9.8 (2001), str. 28–35.
[20] Tomaˇz Hovelja, Olegas Vasilecas in Damjan Vavpotiˇc. “Exploring the influences of the use of elements comprising information system deve-lopment methodologies on strategic business goals”. V: Technological and economic development of economy 21.6 (2015), str. 885–898.
[21] Sanghoon Jeon in sod. “Quality attribute driven agile development”. V:
2011 Ninth international conference on software engineering research, management and applications. IEEE. 2011, str. 203–210.
[22] Henrik Jonsson, Stig Larsson in Sasikumar Punnekkat. “Agile practices in regulated railway software development”. V:2012 IEEE 23rd Inter-national Symposium on Software Reliability Engineering Workshops.
IEEE. 2012, str. 355–360.
[23] Itir Karac in Burak Turhan. “What Do We (Really)Know about Test-Driven Development?” V:IEEE Software 35.4 (2018), str. 81–85.
[24] Nevenka Kirovska in Saso Koceski. “Usage of Kanban methodology at software development teams”. V: Journal of Applied Economics and Business 3.3 (2015), str. 25–34.
[25] Andre W Kushniruk in Elizabeth M Borycki. “Integrating Low-Cost Rapid Usability Testing into Agile System Development of Healthcare IT: A Methodological Perspective.” V: MIE. 2015, str. 200–204.
[26] Young-Hoon Kwak. “Brief history of project management”. V: The story of managing projects 9 (2005).
[27] Klaus Leopold in Siegfried Kaltenecker. Kanban change leadership:
Creating a culture of continuous improvement. John Wiley & Sons, 2015.
[28] Lowell Lindstrom in Ron Jeffries. “Extreme programming and agile software development methodologies”. V: Information systems mana-gement 21.3 (2004), str. 41–52.
[29] Garm Lucassen in sod. “The use and effectiveness of user stories in practice”. V: International working conference on requirements engi-neering: Foundation for software quality. Springer. 2016, str. 205–222.
[30] Jan-Bert Maas, Paul C van Fenema in Joseph Soeters. “ERP as an or-ganizational innovation: key users and cross-boundary knowledge ma-nagement”. V: Journal of Knowledge Management (2016).
[31] Rezvan Mahdavi-Hezave in Raman Ramsin. “FDMD: Feature-driven methodology development”. V:2015 International Conference on Eva-luation of Novel Approaches to Software Engineering (ENASE). IEEE.
2015, str. 229–237.
[32] David Marshburn. “Scrum retrospectives: Measuring and improving effectiveness”. V:Proceedings of the southern Association for Informa-tion systems conference. 2018.
[33] James Martin. Rapid application development. Macmillan Publishing Co., Inc., 1991.
[34] Philipp Melzer in Mareike Schoop. “Individual End-User Training For Information Systems Using Learning Styles.” V: UKAIS. 2014, str. 27.
[35] Steve Neely in Steve Stolt. “Continuous Delivery? Easy! Just Change Everything (well, maybe it is not that easy)”. V:2013 Agile Conference.
IEEE. 2013, str. 121–128.
[36] Steve R Palmer in Mac Felsing. A practical guide to feature-driven development. Pearson Education, 2001.
[37] Software prototyping. url: https : / / en . wikipedia . org / wiki / Software_prototyping(pridobljeno 5. 5. 2021).
[38] SDLC – RAD Model.url:https://www.tutorialspoint.com/sdlc/
sdlc_rad_model.htm (pridobljeno 13. 1. 2021).
[39] Francisco Jose Rego Lopes in Fabio Petrillo. “SimKan: Training Kan-ban Practices Through Stochastic Simulation”. V:Brazilian Workshop on Agile Methods. Springer. 2016, str. 110–121.
[40] Cynthia K. Riemenschneider, Bill C. Hardgrave in Fred D. Davis.
“Explaining Software Developer Acceptance of Methodologies: A Com-parison of Five Theoretical Models”. V:IEEE transactions on Software Engineering 28.12 (2002), str. 1135–1145.
[41] Bernhard Rumpe in Astrid Schr¨oder. “Quantitative Survey on Extreme Programming Projects”. V: arXiv preprint arXiv:1409.6599 (2014).
[42] Ken Schwaber. “SCRUM Development Process”. V: Business object design and implementation. Springer, 1997, str. 117–134.
[43] Tom Seymour in Sara Hussein. “The History Of Project Management”.
V: International Journal of Management & Information Systems (IJ-MIS) 18.4 (2014), str. 233–240.
[44] Ryushi Shiohama in sod. “Estimate of the Appropriate Iteration Length in Agile Development by Conducting Simulation”. V:2012 Agile Con-ference. IEEE. 2012, str. 41–50.
[45] Viktoria Stray, Nils Brede Moe in Dag IK Sjoberg. “Daily Stand-Up Meetings: Start Breaking the Rules”. V: IEEE Software 37.3 (2018), str. 70–77.
[46] Viktoria Gulliksen Stray, Yngve Lindsjørn in Dag IK Sjøberg. “Obsta-cles to Efficient Daily Meetings in Agile Development Projects: A Case Study”. V: 2013 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. IEEE. 2013, str. 95–102.
[47] Beni Suranto. “Exploratory Software Testing in Agile Project”. V:2015 International Conference on Computer, Communications, and Control Technology (I4CT). IEEE. 2015, str. 280–283.
[48] Jeff Sutherland in Ken Schwaber. “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework”. V: (2007).
[49] Ohno Taiichi. Toyota Production System: Beyond Large-Scale Produc-tion. Productivity press, 1988.
[50] Hirotaka Takeuchi in Ikujiro Nonaka. “The new new product develop-ment game”. V: Harvard business review 64.1 (1986), str. 137–146.
[51] John F Tripp, Cindy Riemenschneider in Jason B Thatcher. “Job Sa-tisfaction in Agile Development Teams: Agile Development as Work Redesign”. V:Journal of the Association for Information Systems 17.4 (2016), str. 1.
[52] Damjan Vavpotiˇc in Olegas Vasilecas. “Selecting a Methodology for Business Information Systems Development: Decision Model and Tool Support”. V: Computer Science and Information Systems 9.1 (2012), str. 135–164.
[53] What is a kanban board? url: https://www.atlassian.com/agile/
kanban/boards (pridobljeno 16. 9. 2021).
[54] Prototyping Model in Software Engineering: Methodology, Process, Appro-ach. 2022. url: https://www.guru99.com/software-engineering-prototyping-model.html(pridobljeno 5. 1. 2022).
[55] Takafumi Yoshida. “A Perspective on Computer-Based Training, CBT”.
V:2013 IEEE 37th Annual Computer Software and Applications Con-ference. IEEE. 2013, str. 778–783.
[56] Yuefeng Zhang in Shailesh Patel. “Agile Model-Driven Development in Practice”. V: IEEE software 28.2 (2010), str. 84–91.
Rezultati ankete
1 Vodene delavnice 5,82 5,92 6,75
2 Opazovanje uporabnikov 5,06 4,75 4,63
3 Intervjuji 5,24 4,5 4,88
4 Dokument opredelitve zahtev pro-gramske opreme
6,03 6,59 6,88
5 Uporabniˇske zgodbe 5,3 4,92 4,88
6 Prototip 5,09 4,83 5,75
7 Agilno atributno voden razvoj 5,82 5,92 6,25 8 Planiranje po funkcionalnosti 5,67 6,42 7 9 UML model – Poenoteni jezik
modeli-ranja
5,18 5,08 4,5
10 Eno-tedenska iteracija 4,94 4,5 6,88
11 Tri-tedenska iteracija 5,15 5 2,5
1Ocena razvoja
2Ocena tehniˇcnega dela
3Ocena vodstva
55
12 Neprekinjena dostava 4,39 5,5 2,38
13 Dnevni Scrum sestanek 4,88 5,42 5,63
14 Sestanek veˇckrat na teden, ne pa nujno vsak dan
5,42 5,17 3,13
15 Dnevni sestanek na nogah 4,97 5,67 6,5
16 Sprint planning sestanek 5,48 5,75 5,5
17 Sestanek Igra naˇcrtovanja 5,09 4,75 4,25 18 Sestanek za doloˇcanje prioritet 5,73 5,8 5,8
19 Programiranje v paru 5,58 5,67 2,25
20 Pregled kode 5,4 4,92 4,75
21 Skupno lastniˇstvo nad kodo 5,24 6,17 2,25
22 Sprint Retrospektiva 4,79 5 4,88
23 Ocena dostave 4,91 4,5 3,88
24 Raziskovalno testiranje 5,67 5,25 6,25
25 Testiranje uporabnosti 5,45 5 6,25
26 Enotsko testiranje 5,09 3,67 3,5
27 Testno voden razvoj 4,76 3,67 4,13
28 Raˇcunalniˇsko izobraˇzevanje 5 5,42 5,5 29 Izobraˇzevanje kljuˇcnih uporabnikov 5,33 5,75 7 30 Individualno izobraˇzevanje konˇcnih
uporabnikov
4,15 3,67 5,13
Tabela A.1: Rezultati ankete – ocena elementa
Slika A.1: Graf primerjave ocene elementov razvoja in vodstva
Slika A.2: Graf primerjave ocene elementov razvoja in tehniˇcnega dela
Slika A.3: Graf primerjave ocene elementov vodstva in tehniˇcnega dela
A.2 Uˇ cinkovita izvedba
Zap.
ˇst.
Element Ocena
raz.
Ocena teh.
Ocena vod.
1 Vodene delavnice 5,36 4,67 6
2 Opazovanje uporabnikov 4,36 3,33 3
3 Intervjuji 4,64 4 3,5
4 Dokument opredelitve zahtev pro-gramske opreme
5,55 5,67 6
5 Uporabniˇske zgodbe 4,45 4,67 3,5
6 Prototip 4,27 3,67 5
7 Agilno atributno voden razvoj 5,64 5,67 6 8 Planiranje po funkcionalnosti 5,73 6,67 7
9 UML model – Poenoteni jezik modeli-ranja
4,82 5,33 3,5
10 Eno-tedenska iteracija 5,09 4,67 7
11 Tri-tedenska iteracija 4,82 5 3
12 Neprekinjena dostava 4,55 4,67 2,5
13 Dnevni Scrum sestanek 4,82 4,67 6
14 Sestanek veˇckrat na teden, ne pa nujno vsak dan
5,36 5,67 3,5
15 Dnevni sestanek na nogah 5,18 5 6,5
16 Sprint planning sestanek 5,45 5,67 5,5
17 Sestanek Igra naˇcrtovanja 5,27 4,33 4
18 Sestanek za doloˇcanje prioritet 6,27 6,33 1,5
19 Programiranje v paru 5,18 5,67 1,5
20 Pregled kode 5,73 5,67 4,5
21 Skupno lastniˇstvo nad kodo 5,27 6,33 1,5
22 Sprint Retrospektiva 4,73 5,33 5
23 Ocena dostave 5,36 5,67 4
24 Raziskovalno testiranje 5,64 5,33 6
25 Testiranje uporabnosti 6,36 4,67 5,5
26 Enotsko testiranje 5,18 4 5
27 Testno voden razvoj 4 3,67 4
28 Raˇcunalniˇsko izobraˇzevanje 4,91 6 5 29 Izobraˇzevanje kljuˇcnih uporabnikov 5,73 6,67 7 30 Individualno izobraˇzevanje konˇcnih
uporabnikov
4 4 5
Tabela A.2: Rezultati ankete – uˇcinkovita izvedba
Slika A.4: Graf primerjave ocen uˇcinkovite izvedbe razvoja in vodstva
Slika A.5: Graf primerjave ocen uˇcinkovite izvedbe razvoja in tehniˇcnega dela
Slika A.6: Graf primerjave ocen uˇcinkovite izvedbe vodstva in tehniˇcnega dela