The public sector in Bosnia has been perceived negatively for several reasons (huge administration, slow system, bureaucratic culture, etc.) Therefore, the public administration reform and modernization of public companies is crucial for improving the quality of life of the citizens. Public administration reform and modernization projects usually ends up as IT projects. That's way it is so important to increase a success rate of these projects. In this regard, there will be two lectures at the meetup with the intention to list causes of the problem and offer some solutions. The first topic "Challenges of implementing agile software development in public companies" will give us an overview of the obstacles that stand in the way of applying agile paradigm for in-house software development in a public company and to offer recommendations to overcome them. Next topic "Public procurement of agile product development" will give us an insight into specification method of agile approach in the procurement process, with the distinct overview of describing procurement subject with the results that contracted provider need to achieve and the selection criteria in terms of technical and professional ability of the economic operators.

1. Izazovi uvođenja agilnog razvoja softvera u
javna preduzeća
AGILNOST U JAVNOM SEKTORU
Bosnia Agile Meetup
Jasmin Heljić
Omer Gegić
Sarajevo, 08.04.2016

2. Direkcija
Poslovnica
Djelatnost
Poslovnica
Poslovnica
Djelatnost
Poslovnica
Poslovnica
 Javno preduzeće - preduzeće u
državnom vlasništvu i/ili pod državnom
kontrolom koje obavlja djelatnost od
opšteg interesa.
 Najčešća područja djelovanja javnih
preduzeća su: energetika,
komunikacije, komunalne djelatnosti,
upravljanje javnim dobrima i dr.
2 Javno preduzeće

3. Razvoj softvera (1/2)
 Razvoj softvera - proces nastanka softverskog proizvoda.
 Softverski inžinjering - profesija koja se bavi dizajniranjem, implementacijom i
modifikacijom softvera s ciljem isporučivanja kvalitetnog softverskog
proizvoda.
 Postoje tri glavne paradigme razvoja softvera: tradicionalna, iterativna i
agilna. Svaka je pogodna za neke situacije, ali ni jedna nije pogodna za
sve situacije.
3

4.  Spektar načina realizacije softverskih proizvoda se proteže od razvoja do
nabavke gotovih paketa.
 Razvoj namjenskog softvera:
 vlastiti (in-house)
 vanjski (outsourced)
 U literature se rijetko pravi jasna razlika između vlastitog i vanjskog razvoja.
Razvoj se konceptualno posmatra kao istovjetna aktivnost bez obzira u
kojem kontekstu se dešava.
 Kompanije obično pribjegavaju vlastitom razvoju u slučaju trivijalnih
zahtjeva s jedne, te kompleksnih ili neobičnih zahtjeva s druge strane.
4 Razvoj softvera (2/2)

5.  Individue i interakcije iznad procesa i alata
 Funkcionalan softver iznad obimne dokumentacije
 Saradnja sa klijentom iznad ugovaranja
 Reagovanje na promjene umjesto slijeđenja plana
Agilni manifest5

6. 6 Karakteristike javnih preduzeća (1/5)
 Izražena birokratska kultura
 Hijerarhijska struktura
 Katastrofalna politika kadroviranja
 Toksične radne sredine

7. Dijagram iz studije slučaja o komunikaciji u javnom preduzeću
Karakteristike javnih preduzeća (2/5)7

8. Izvod iz bilježnice člana projektnog tima o pritiscima tokom trajanja projekta
Karakteristike javnih preduzeća (3/5)8

9. 9
Nisam dobio nalog da to uradim!
Karakteristike javnih preduzeća (4/5)

10. 10 Karakteristike javnih preduzeća (5/5)

11.  Struktura javnog preduzeća
 Sistematizacija radnih mjesta
 Organizaciona kultura
 Nefleksibilno rukovođenje
 Nadzorni organi
 Upravljanje ljudskim resursima
 Potreba za izvjesnošću
 Nedostatak poslovnih saradnika
 Inertnost
 Neznanje
11
Prepreke za uvođenje agilnog pristupa (1/2)

12.  Poslovna agilnost – agilna transformacija
 IT agilnost – agilna adopcija
12
Prepreke za uvođenje agilnog pristupa (2/2)

13. 13 Agilna adopcija (1/2)

14. 14 Agilna adopcija (2/2)
 Razumijevanje poslovne potrebe za agilnom adopcijom
 Plan edukacije o agilnosti
 Razvoj strategije adopcije
 Izvršenje

15. 15 Promjena (1/4)

16. 16 Promjena (2/4)

17. 17 Promjena (3/4)

18. 18 Promjena (4/4)

19. 19
Zaključci
 Uvođenje agilnog pristupa je kontekstualna aktivnost.
 Svako preduzeće je unikatno i ne postoji jedinstven recept.
 Promjena ne funkcioniše ako se ne radi na dva fronta – promjena realnosti i
promjena percepcije.
 Za promjenu su potrebni jaki sponzori – uprave preduzeća;
bez podrške top menadžmenta promjena je malo vjerovatna iako moguća.
 Dijagnoza barijera je preduslov kreiranja strategije uvođenja agilnog
pristupa.
 Prvi korak - učenje, upoznavanje s materijom, edukacija.

20. 20
Literatura
 Matthew Hotle. (2010, March). "Waterfalls, Products and Projects: A Primer
to Software Development Methods". Gartner. [On-line] Available:
www.gartner.com [23.10.2014]
 Agile Transformation: Four Steps to Organizational Change. On-line course.
Available: www.frontrowagile.com
 Mike Cottmeyer. (2011, January). "12 Key Barriers to Agile Transformation" .
Available: www.leadingagile.com
 Radovi i predavanja prof. Luc de Brabandere o promjeni

21. Javna nabavka agilnog razvoja
proizvoda
Kemal Bajramović
21

22. Životni ciklus razvoja inf.sistema
Odabir
projekta
• Identifikacija potencijalnih
projekata
• Razmatranje opravdanosti i
održivosti projekata
• Prioretizacija projekata
• Razvoj inicijalne vizije
Iniciranje
projekta
• Osiguranje finansiranja i podrške
• Uspostavljenje projektnog tima
ugovornog organa
• Definisanje inicijalnih zahtjeva sistema
• Definisanje inicijalne arhitekture sistema
Razvojne
interacije
• Kolaborativno modeliranje i razvoj
• Dizajn baziran na prototipovima
• Testiranje kriterija prihvatljivosti
• Isporuke inkremenata
funkcionalnosti
• Evolucija dokumentacije
Isporuke
• Testiranje kriterija
prihvatljivosti
• Puštanje isporuke u
produkciju
• Finalizacija dokumentacije
• Pilot produkcija
Produkcija
• Korištenje sistema
• Podrška sistemu i održavanje
• Identifikacija grešaka i
mogućnosti za poboljšanja
Analiza i
specifikacija
zahtjeva
sistema
• Utvrđivanje inicijalnih
zahtjeva sistema
• Dovoljno detaljno
opisivanje poslovnih
očekivanja
Javna nabavka Javna nabavka Javna nabavka
R A Z V O J

23. Vaša uloga u agilnom razvoju23

24. Vrste problema

25. Vi: “Sada kada vidim ove razvijene
funkcionalnosti, shvatam da mi je potreban
funkcionalnost koja nije u dokumentu sistemskih
zahtjeva.”
Softwareska kompanija: “Ako vam je potrebna ta
funkcionalnost, zašto je niste specificirali u
tenderskoj dokumentaciji?”
Vi: “Pa, nismo se tada sjetili ovoga.”
Softwareska kompanija: “Pa, da ste više razmišljali
i bolje planirali o tome šta vam treba, tada bi
otkrili ovu funkcionalnost, a ne sada. Morate
platiti!”

26. Big-bang isporuka (Waterfall)
1 2 3 4
vrijednost
11

27. Rane i česte isporuke (Agile)
51 432
vrijednost
12

28. Javna nabavka agilnog razvoja (1)
 Prethodno informativno obavještenje
 Preferirati otvorene postupke
 Opisati i predmet nabavke i agilni proces realizacije
 Uspostaviti sistem za kontinuiranu komunikaciju ugovornog organa i ugovorenog
ponuđača
 Uspostava sistema za praćenje realizacije projekta
 Uspostaviti mehanizam vizualizacije: mockup, prototipovi...
 Propisati korištenje open-source okvira za razvoj grafičkog interfejsa
 Propisati pravila razvojnih sprintova
 Uspostaviti uslove za nesmetano održavanje virtuelnih sastanaka u audio-video
formatu, ukoliko ponuđač nema sjedište u mjestu ugovornog organa
 Izbjegnuti vendor lock-in

29. Javna nabavka agilnog razvoja (2)
 Propisati privremeni raspored realizacije aktivnosti
 Osigurati mehanizam za kontinuirano testiranje sistema od sprinta 2
 Osigurati dovoljno resursa za efikasno i brzo uklanjanje uočenih grešaka u pilot
implementaciji
 Osigurati ograničeni besplatni change request po puštanju sistema u produkciju
 Propisati mehanizam klasifikacije i određivanja prioriteta
 Propisati uslove za kvalifikaciju u svrhu dokazivanja lične sposobnosti, te u pogledu
ekonomske i finansijske sposobnosti ponuđača primjerene predmetu nabavke
 Posebnu pažnju posvetiti minimalnim uslovima u pogledu tehničke i profesionalne
sposobnosti ponuđača:
 Referentna lista
 Uposleno / angažirano tehničko osoblje
 Reference: Tehničko osoblje kompanije, a ne kompanija realizuje projekat!

30. Komunikacija i kolaboracija je ključ uspjeha
Pronalazimo bolje načine za razvoj software-a
tako što razvijamo software i pomažemo drugima u tome.
Kroz ovaj rad spoznali smo vrijednost:
Pojedinaca i njihovih međuodnosa u odnosu na procese i alate
Ispravnosti software-a u odnosu na obimnu dokumentaciju
Saradnje s klijentom u odnosu na ugovoranje
Reagovanja na promjenu u odnosu na pridržavanje plana
To znači, iako su stavke na desnoj strani bitne,
veći značaj pridajemo stavkama na lijevoj strani.
30

31. Komunikacija i kolaboracija je ključ uspjeha
Spremno prihvaćamo promjene zahtjeva, čak i u kasnoj fazi razvoja.
Poslovni ljudi i razvojni inženjeri moraju svakodnevno zajedno raditi, tokom cjelokupnog
trajanja projekta.
Projekte ostvarujemo oslanjajući se na motivirane pojedince. Pružamo im okruženje i
podršku koja im je potrebna i prepuštamo im posao s povjerenjem.
Razgovor uživo je najučinkovitiji način prijenosa informacija razvojnom timu i unutar tima.
Agilni procesi potiču i podržavaju održivi razvoj. Pokrovitelji, razvojni inženjeri i korisnici trebali
bi moći neograničeno dugo zadržati jednak tempo rada.
31