SVEUČILIŠTE U SPLITU FAKULTET ELEKTROTEHNIKE, STROJARSTVA I BRODOGRADNJE Poslijediplomski doktorski studij Elektrotehnike i informacijske tehnologije Kvalifikacijski doktorski ispit

Utjecaj Kanban agilne metodologije na razvoj programskog proizvoda

Split, studeni 2012. Ante Topić

i

Utjecaj Kanban agilne metodologije na razvoj programskog proizvoda

Sadržaj

1 UVOD .......................................................................................................................................................1

2 RAZVOJ METODOLOGIJA U PROGRAMSKOM INŽENJERSTVU ...................................................................3

2.1 VODOPADNA METODOLOGIJA ........................................................................................................................ 3

3 RAZVOJ AGILNIH METODOLOGIJA............................................................................................................5

3.1 EKSTREMNO PROGRAMIRANJE (XP) ................................................................................................................ 8

3.2 SCRUM ................................................................................................................................................... 12

3.3 RAZVOJ TEMELJEN NA SVOJSTVIMA (FDD) ..................................................................................................... 16

3.4 KRISTALNA OBITELJ METODOLOGIJA .............................................................................................................. 19

3.4.1 Crystal Clear..................................................................................................................................... 20

3.4.2 Crystal Orange ................................................................................................................................. 21

3.5 METODA DINAMIČKOG RAZVOJA SUSTAVA (DSDM) ........................................................................................ 22

3.5.1 Opis DSDM faza ............................................................................................................................... 23

3.5.2 Uloge u projektu .............................................................................................................................. 25

3.6 ADAPTIVNI RAZVOJ PROGRAMSKOG PROIZVODA (ASD) .................................................................................... 26

3.6.1 Faza istraživanja i razmišljanja........................................................................................................ 26

3.6.2 Faza suradnje................................................................................................................................... 27

3.6.3 Faza učenja ...................................................................................................................................... 27

3.6.4 Principi adaptivnog razvoja programskog proizvoda ...................................................................... 28

4 KANBAN AGILNA METODOLOGIJA .........................................................................................................29

4.1 LEAN KONCEPT ......................................................................................................................................... 29

4.2 KANBAN.................................................................................................................................................. 30

4.2.1 Principi ............................................................................................................................................. 31 4.2.1.1 Kanban ploča...........................................................................................................................................31 4.2.1.2 Ograničenja na Kanban ploči...................................................................................................................33

4.2.2 Uloge u projektu .............................................................................................................................. 34

4.2.3 Nova vrsta sastanaka ...................................................................................................................... 34

4.2.4 Kaizen .............................................................................................................................................. 34 4.2.4.1 Metrika ...................................................................................................................................................34

4.2.5 Vremenski okviri u iteraciji............................................................................................................... 36

5 ZAKLJUČAK.............................................................................................................................................37

6 REFERENCE.............................................................................................................................................39

ii

Popis slika

Slika 1-1: Troškovi promjene zahtjeva u agilnim sustavima.................................................................................... 1

Slika 2-1: Faze razvoja vodopadne metodologije .................................................................................................... 3

Slika 3-1: Perspektivne i prilagodljive metodologije................................................................................................ 6

Slika 3-2: Najčešće korištene agilne metodologije .................................................................................................. 7

Slika 3-3: Jedan dan programera na poslu .............................................................................................................. 9

Slika 3-4: Životni ciklus XP projekta....................................................................................................................... 10

Slika 3-5: Dijagram preostalog posla u Sprintu ..................................................................................................... 13

Slika 3-6: Scrum proces.......................................................................................................................................... 14

Slika 3-7: Osnovni procesi FDD .............................................................................................................................. 16

Slika 3-8: Kristalna obitelj metodologija [56] ........................................................................................................ 20

Slika 3-9: DSDM okvir ............................................................................................................................................ 22

Slika 3-10: Životni ciklus DSDM-a .......................................................................................................................... 23

Slika 3-11: DSDM organizacija tima ...................................................................................................................... 25

Slika 3-12: Faze životnog ciklusa ASD-a ................................................................................................................ 26

Slika 4-1: Primjer Kanban ploče............................................................................................................................. 32

Slika 4-2: Vođenje više projekata na jednoj Kanban ploči..................................................................................... 33

Slika 4-3: Metrika u Kanbanu ................................................................................................................................ 35

1

1 Uvod

Računarstvo je mlada znanost koja je osnovana 1960-ih stvaranjem prvih odsjeka i

studija [1]. Budući da su praktična računala postala dostupna, mnoge primjene računarstva su postale zasebna istaknuta područja proučavanja. Neprestanim razvojem sklopovlja računala kao i programskih proizvoda nalazimo se u informacijskom dobu gdje je programski proizvod važan čimbenik u svakom području.

Programski proizvod (eng. software product) je računalni program i povezana

dokumentacija kao što je specifikacija zahtjeva, specifikacija dizajna itd. Programski proizvod može biti generički (razvijen s namjenom da bude na tržištu dostupan različitim vrstama kupaca, npr. Microsoft Office Word) ili po narudžbi (razvijen za određenog kupca sukladno njegovoj specifikaciji). [2]

Pri svakom razvoju programskog proizvoda koristi se neka od poznatih metodologija

razvoja koja se prilagođava timu s obzirom na narudžbu i želje kupca, veličinu projekta, definirane rokove isporuke, resurse s kojima firma raspolaže u smislu broja razvojnih programera, njihovih znanja i vještina, tehnologija koje se koriste itd. Cilj svake metodologije je zadovoljstvo kupca uz minimalne troškove i isporuka programskog proizvoda na vrijeme uz minimalan broj programskih pogreški (eng. bug) kako bi firma postala konkurentna na tržištu.

Troškovi razvoja programskog proizvoda su uobičajeno veći od sklopovlja računala,

međutim troškovi održavanja programskog proizvoda koji ima dugi vijek trajanja su veći od izrade samog programskog proizvoda. Troškovi razvoja programskog proizvoda su približno 60% dok na testiranje proizvoda otpada 40% međutim troškovi ovise o vrsti sustava koji se razvija te o njegovim performansama i pouzdanosti. [2]

Slika 1-1: Troškovi promjene zahtjeva u agilnim sustavima

2

Sa svakom metodologijom razvoja programskog proizvoda postoji opasnost od osnovnih problema prilikom njegove izrade kao što su probijanje rokova, odustajanje od projekta (nakon probijanja rokova), nabacana arhitektura, puno grešaka (nekorisnost sustava), sustav ne rješava probleme poslovne logike, promjene poslovne logike, kriva svojstva programa („zabavno“, ali nekorisno), smjena programera. Stoga je cilj minimizirati sve navedene probleme ili ih pokušati preduhitriti definiranim načelima metodologije.

Kroz povijest su se razvijale razne metodologije koje su naglašavale različite pristupe

razvoju programskog proizvoda te su se s vremenom usavršavale. Opstale su samo one koje su se u praksi pokazale korisne i funkcionalne tako da mogu odgovoriti na rastuće zahtjeve korisnika i probleme u samoj izradi programskog proizvoda. Razlikujemo tradicionalne metodologije koje su procesno orijentirane te agilne koje daju naglasak na vrijednosti i principe, a ne na sami proces.

U današnje vrijeme organizacije koje se bave razvojem programskog proizvoda su

svjesne da mogu postati konkurentne na tržištu samo ukoliko budu fleksibilne na promjene korisničkih zahtjeva tijekom razvoja i brze u ispunjavanju tih zahtjeva, odnosno da se pridržavaju dogovorenih rokova i budžeta, a s druge strane da programski proizvod bude visokokvalitetan što im omogućavaju agilne metodologije razvoja programskog proizvoda.

Ovaj rad se bavi pregledom metodologija u programskom inženjerstvu za razvoj

programskog proizvoda te njihovim prednostima i nedostacima. Poseban značaj je dan Kanban agilnoj metodologiji razvoja programskog proizvoda koju autor koristi u izradi SEUD sustava (Sustav za Elektroničko Upravljanje Dokumentima) u projektu informatizacije Splitsko-dalmatinske županije.

U drugom poglavlju ovog rada opisano je programsko inženjerstvo kao računalna

disciplina te razvoj vodopadne metodologije. Treće poglavlje prikazuje razvoj agilnih metodologija izrade programskog proizvoda u programskom inženjerstvu kroz povijest. Navedene su i opisane njihove prednosti i nedostaci te sami proces po kojem funkcioniraju. Četvrto poglavlje donosi detljan opis Kanban metodologije razvoja programskog proizvoda te njene temeljne značajke. Zadnje poglavlje sadrži zaključak ovog rada te ideje kako se Kanban metodologija može usavršiti čime bi se doprinjelo produktivnijem razvoju programskog proizvoda.

3

2 Razvoj metodologija u programskom inženjerstvu

Programsko inženjerstvo je disciplina koja se bavi svim aspektima proizvodnje programskog proizvoda od specifikacije sustava do implementacije sustava i održavanja. [2]

Programsko inženjerstvo je računalna disciplina koja se bavi razvojem složenih

aplikacija. Ono se ne bavi samo tehničkim aspektima izgradnje sustava programskog proizvoda nego i menadžerskim problemima poput organizacije programerskog tima, planiranjem termina, financijama itd. [3]

2.1 Vodopadna metodologija

Vodopadnu metodologiju (eng. Waterfall model) [4] razvoja programskog proizvoda je popularizirao Winston W. Royce u članku „Managing Development of Large Scale

Software“ 1970. godine [5]. Programski proizvod se razvija kroz faze koje se izvršavaju linearno kako je prikazano na slici 2-1:

1. Definicija i analiza zahtjeva (engl. Requirements Analysis and Definition) 2. Dizajn sustava i programskog proizvoda (eng. System and Software Design) 3. Implementacija (kodiranje) i jedinično testiranje (eng. Implementation and Unit

Testing) 4. Integracija i testiranje sustava (eng. Integration and System Testing) 5. Rad i održavanje (eng. Operation and Maintenance)

Slika 2-1: Faze razvoja vodopadne metodologije

Naziv „vodopadni“ je iz razloga što se pojedina faza procesa naslanja na prethodnu. Na kraju svake faze provodi se kontrola radi utvrđivanja je li projekt spreman za sljedeću fazu [2]. Ukoliko nije, zadržava se na trenutnoj fazi ili se vraća u neku od prethodnih faza. Kako je Winston W. Royce u svom originalnom članku naveo ponovljivu upotrebu metodologije iterativnim načinom tako danas u praksi vodopadni model često ne slijedi linearni stil nego se koristi u iterativnom načinu.

4

Iako najstariji, ovaj model se i danas koristi iako je potisnut od strane agilnih metodologija [6]. Razlozi tome su težak i skup povratak u prethodnu fazu te dugo trajanje projekta. Koristan je kod detaljno i stabilno definiranih proizvoda te pri radu s dobro poznatom tehnologijom, dok se nedostaci otkrivaju kod slabo definiranih i promjenjivih projekata kao i kod potrebe za brzim razvojem. [7]

Prednosti vodopadne metodologije razvoja programskog proizvoda su preglednost i

dobra organiziranost dok se problemi pojavljuju kod povratka u prethodnu fazu koji je skup i kod nefleksibilne podjele projekta u više dijelova što promjenu korisničkih zahtjeva čini otežanom. [2]

5

3 Razvoj agilnih metodologija

Agilne metodologije u razvoju programskog proizvoda javljaju se kao odgovor na opsežne (tradicionalne) metodologije koje su nastale od 1970-ih do 1990-ih. One su pokušale nametnuti nekakav oblik discipline vezane za način na koji se programski proizvod osmišljava, dokumentira, razvija i testira. Kasnih 1990-ih, grupa projektanata (Ken Beck, Alstair Cockburn i dr. osnivaju Agile Alliance1) koja se protivila toj disciplini je začetnik agilnog pristupa u razvoju programskog proizvoda. Pobornici agilnih metoda razvoja programskog proizvoda 2001. godine donose Agile Software Development Manifesto pokušavajući naglasiti ulogu koju fleksibilnost može odigrati u spretnijem i bržem razvoju programskog proizvoda. Prema Manifestu je uspostavljen novi sustav vrijednosti [8]:

• Osobe i interakcije umjesto procesa i alata

• Programski proizvod koji radi umjesto opširne dokumentacije

• Zajednički rad i suradnja s kupcem umjesto pregovaranja preko ugovora

• Reagiranje na promjene umjesto striktnog pridržavanja plana

U Manifestu su zabilježeni i principi po kojima se trebaju razvijati i primjenjivati agilne metode. Principi jasno ukazuju na značajne promjene u pristupu i provođenju razvoja programskog proizvoda u odnosu na principe koji dolaze iz tradicionalnih metoda razvoja programskog proizvoda. Prema Agilnom Manifestu principi agilnih metodologija su: [8]

• najviši prioritet je zadovoljiti kupca kroz rane i kontinuirane isporuke programskog proizvoda koji ima vrijednost kupcu

• promjena zahtjeva je uobičajena pa i u kasnim fazama projekta. Agilni procesi podržavaju promjene tako da kupac to može iskoristiti kao prednost nad konkurentima

• programski proizvod koji radi isporučuje se svakih nekoliko tjedana ili mjeseci (preporuča se kraći period)

• naručitelji koji će koristiti proizvod i razvijatelji moraju svakodnevno zajedno raditi kroz čitav projekt

• projekti se grade oko motiviranih osoba kojima se osigurava okolina, podržava ih se i vjeruje da će napraviti posao kako treba

• najučinkovitiji način razmjene informacija u razvojnom timu je komunikacija licem u lice

• programski proizvod koji radi je osnovna mjera praćenja napredovanja

• agilni procesi promoviraju održivi razvoj (kao maraton)

• stalna pažnja usmjerena na tehničku izvrsnost i dobar dizajn povećavaju agilnost

• jednostavnost – “umjetnost” povećanja posla koji ne treba napraviti je ključna (tehnički gledano)

• najbolje arhitekture, zahtjevi i dizajn pojave se iz samoorganizirajućih timova

1 http://www.agilealliance.org – neprofitna organizacija koja promovira znanje i rasprave o svim agilnim metodologijama

6

• tim periodički ispituje dobre i loše postupke te ih prokušava popraviti u sljedećem periodu

Ne postoji definicija agilnog programiranja nego ona proizlazi iz principa iskazanih u

Manifestu. Principi predstavljaju konceptualni okvir kojeg se treba pridržavati pri razvoju programskog proizvoda. Metodologije razvoja programskog proizvoda temeljenog na agilnim principima koje su originalno uključene u Agile Alliance su:

• eXtreme Programming – XP (Beck, 1999.) [9],

• Scrum (Schwaber, 1995. Schwaber i Beedle, 2002.) [10].

• Feature Driven Development – FDD (Palmer i Felsing, 2002) [11, 12]

• Crystal family of methodologies (Cockburn, 2002.) [13]

• Dynamic Systems Development Method – DSDM (Stapleteon, 1997.) [14]

• Adaptive Software Development – ASD (Highsmith, 2000.) [15]

Slika 3-1: Perspektivne i prilagodljive metodologije

Dijagram na slici 3-1 koji je izradio Henrik Kniberg prikazuje metodologije u rasponu od najperspektivnijih do najprilagodljivijih prema broju pravila koja su napisana u zagradama. Primjerice RUP je prilično perspektivna metodologija jer ima preko 30 uloga (rola), preko 20 aktivnosti i preko 70 predmeta za uporabu dok Kanban ima gotovo sva pravila otvorena osim vizualizacije procesa i ograničenja posla u radu.

Agilne metodologije su podskup iterativnih i evolucijskih metoda [16, 17] i bazirane su na iterativnom povećanju, a iteracije (ponavljanja) su kratke kako bi mogle pružiti pravodobnu povratnu informaciju projektnom timu. [18]

U svim iterativnim proizvodima, svaka iteracija je samostalna, tj. kao zaseban mini projekt s aktivnostima koje obuhvaćaju specifikaciju zahtjeva, dizajn, implementaciju i testiranje [16]. Rezultat svake iteracije je distribucija malog dijela programskog proizvoda, koji može biti čak i samo interni, a na temelju njega kupac specificira svoje daljnje zahtjeve [19]. S obzirom da postoji kvantitativna evidencija između čestih rokova, može se smanjiti varijacija procesa izrade programskog proizvoda čime se povećaje predvidljivost i efikasnost. [20]

Unaprijed određena duljina iteracije razvojnom timu služi kao vremenski okvir. Prema duljini trajanja iteracije se određuje opseg zadataka koji se trebaju odraditi. Glavna razlika

7

između agilnih i iterativnih metodologija je duljina pojedine iteracije. Dok je duljina iteracije za iterativne metodologije tri do šest mjeseci, agilnim pristupom se interval smanjio na jedan do četiri tjedna, a maksimalno do 30 dana. Istraživanja su pokazala da se kod kraćih iteracija smanjuje kompleksnost i rizik, bolja je povratna informacija te je povećana produktivnost i stopa uspješnosti [16]

U petoj godišnjoj anketi „State of agile development“ koja je provedena u razdoblju između 11.08. i 31.10.2010. godine pod pokroviteljstvom „VersionOne“ ispitanici su odgovarali preko email lista, web stranica i drugih foruma. Istraživanje sadrži podatke od 4770 sudionika iz 91 zemlje, a podaci su analizirani i pripremljeni u sumarnom izvješću „Analysis.Net Resarch“. Prema ovom istraživanju, a kako je na grafu prikazano, danas je najviše u upotrebi Scrum agilna metodologija razvoja programskog proizvoda. [21]

Slika 3-2: Najčešće korištene agilne metodologije

U nastavku ovog poglavlja je dan pregled agilnih metodologija koje su originalno uključene u Agile Alliance iz 2001. godine.

8

3.1 Ekstremno programiranje (XP)

Ekstremno programiranje (eng. eXtreme Programming – XP) [22, 29] je jedna od nekoliko popularnih agilnih metodologija te se pokazao kao vrlo uspješan u mnogim firmama raznih veličina i industrijama širom svijeta, a prvi projekt je pokrenut 06.03.1996. godine. XP je metodologija odnosno pristup u razvoju programskog proizvoda kojoj je začetnik Kent Beck, 1990. godine, a pogodna je za razvoj u situacijama kada su zadaci nejasni i često se mijenjaju (tijekom procesa moguće je mijenjati zahtjeve, dizajn, poslovnu logiku, tehnologiju, ljude u timu itd.).

Ekstremno programiranje [27, 28] je uspješno jer naglašava zadovoljstvo kupca. Umjesto dostave svega što bi moguće kupac htio na određeni datum u budućnosti, ovaj proces isporučuje programski proizvod kada to kupcu treba. Razvojni programeri odgovaraju na promjenu korisničkih zahtjeva čak i u kasnijem dijelu razvojnog ciklusa programskog proizvoda. Ova metodologija naglašava rad u timu gdje su menadžeri, kupci i razvojni programeri ravnopravni partneri, a okruženje je jednostavno, ali učinkovito te omogućuje timovima da postanu što učinkovitiji.

Začetnici Ekstremnog programiranja [9] su se usmjerili na razvoj metodologije pogodne za „objektno orijentirane projekte koristeći tucet ili nekoliko programera smještenih na jednoj lokaciji“. [23]. Metodologija se temelji na pet osnovnih vrijednosti:

1. Komunikacija: XP potiče i prakticira usmenu komunikaciju s kupcima i razvojnim programerima. Vrijednost komunikacije se temelji na primjedbi da većina poteškoća u projektu nastane iz razloga što netko u timu nije razgovarao da bi razjasnio pitanje, surađivao ili potražio pomoć. [9]

2. Jednostavnost: dizajniranje jednostavnijeg proizvoda koji zadovoljava potrebe kupca. Važan aspekt ove vrijednosti je da se dizajniraju i programiraju samo trenutni zahtjevi kupca umjesto predviđanja i planiranja nenavedenih zahtjeva.

3. Povratni odgovor: razvojni tim dobiva povratni odgovor od kupca na kraju svake iteracije. Ovaj povratni odgovor je vodilja za sljedeću iteraciju. Osim toga, postoji vrlo kratak povratni odgovor o dizajnu i implementaciji ugrađenim u metodologiju putem programiranja u paru i razvoja vođenog testovima (eng. test-driven development) [24]

4. Hrabrost: navedene tri vrijednosti dozvoljavaju timu da bude hrabar u njegovim akcijama i donošenju odluka.

5. Poštovanje: članovi tima trebaju brinuti jedan o drugome i o projektu.

9

Slika 3-3: Jedan dan programera na poslu

Ova metodologija ne koristi standardnu dokumentaciju nego se oslanja na usmenu komunikaciju. Međutim, ovakav način „dokumentacije“ može funkcionirati u malim grupama te nije preporučljiva kao procedura u velikim ili visokorizičnim sustavima. U dokumentaciju spadaju: kartice korisničkih priča (eng. user story cards), tj. indeks kartice koje sadrže kratak zahtjev; lista zadataka koja treba biti završena u iteraciji; test prihvaćanja korisnika (eng. user

acceptance test), tj demonstracija završenog posla kupcu na kraju iteracije prema njegovim definiranim testovima; vidljivi zidni grafovi, odnosno grafovi koji prikazuju napredak, a nalaze se u prostoriji gdje radi tim. Uloge (eng. roles) koje se pojavljuju u XP-u su:

1. Menadžer: formira tim te upravlja njime i njegovim problemima 2. Trener: uči članove tima o XP metodologiji te prati slijede li se procesi XP-a. Trener

je uobičajeno programer, a ne menadžer. 3. Tragač (eng. tracker): prikuplja korisničke priče i napredak u slučajevima testova

prihvaćanja s ciljem izrade vidljivog zidnog grafa. Tragač je programer. 4. Programer: piše testove, dizajnira i kodira, ali također identificira i procjenjuje

zadatke i korisničke priče. Ova osoba također može biti tester. 5. Tester: pomaže kupcu pisati i razvijati testove. 6. Kupac: piše korisničke priče i testove prihvaćanja te odabire korisničke priče koje će

se raditi u određenoj iteraciji.

Prema vrlo jednostavnim pravilima projekt se sastoji od puno malih dijelova: planiranje, upravljanje, dizajniranje, kodiranje i testiranje. Životni ciklus razvoja programskog proizvoda XP-om ima šest faza:

1. Istraživanje (pisanje priča, upoznavanje tehnologije)

10

2. Planiranje (utvrđivanje potrebnog vremena, prioriteti, stvaranje) 3. Iteracije (pisanje, procjena i prioritiziranje novih zadataka, testiranje na kraju svake

iteracije) 4. Produkcija (testiranje prije isporuke, evidentiranje novih zahtjeva) 5. Održavanje (dodavanje novih funkcionalnosti, ispravke grešaka) 6. Kraj (zahtjevi ispunjeni, završetak projekta)

Slika 3-4: Životni ciklus XP projekta

Početna verzija XP metodologije razvoja programskog proizvoda [9] objavljena 2000. godine sastojala se od 12 tehničkih vještina orijentiranih na programera. 2005. godine, XP je promijenjen na način da sadrži 13 osnovnih praktičnih tehnika i 11 posljedičnih praktičnih tehnika [9]. Osnovne vještine su namijenjene da budu korisne neovisno jedna o drugoj te su opisane:

1. Sjedenje zajedno: cijeli tim razvija u jednom prostoru. 2. Cijeli tim, koristi sve funkcionalnosti ekipe u svrhu uspjeha proizvoda. 3. Informativni radni prostor: vidljivi zidni grafovi po cijelom radnom prostoru tako

da članovi ekipe i drugi zainteresirani promatrači mogu vidjeti u kojem smjeru ide projekt.

4. Radna energija – 40-satni radni tjedan: XP timovi ne rade prekovremeno za dulji vremenski period. Cilj ove prakse je održati visoku kvalitetu koda jer umoran programer proizvodi više grešaka.

5. Programiranje u paru: [25] odnosi se na praksu gdje dva programera rade zajedno na jednom računalu surađujući u dizajniranju, kodiranju i testiranju.

6. Priče: tim piše kratke izjave kupca, odnosno vidljive funkcionalnosti u proizvodu. Razvojni programeri procjenjuju korisničku priču, a korisnik ih prioritizira.

7. Tjedni ciklus: početkom svakog tjedna održava se sastanak da bi se ustvrdio napredak na projektu i da bi kupac odabrao korisničke priče koje će se pretvoriti u zadatke kojima je cilj završetak do kraja tjedna. Na kraju tjedna se vrši test prihvatljivosti od strane kupca.

8. Tromjesečni ciklus: cijeli tim odabere teme korisničkih priča za tromjesečje. Navedene teme pomažu timu da se upozna sa širom slikom cjelokupnog projekta.

9. Labavost: (eng. slack) u svakoj iteraciji se planiraju zadaci nižeg prioriteta koji se mogu odbaciti ukoliko ih tim ne stigne odraditi na vrijeme.

11

10. Desetominutna izgradnja projekta (eng. build): strukturirati projekt i njegove povezane testove tako da cijeli sustav može biti izgrađen i svi testovi mogu biti izvršeni u roku od 10 minuta.

11. Programiranje gdje se prvo izvode testovi: (eng. test-first programming) sve korisničke priče imaju barem jedan test prihvaćanja po mogućnosti automatiziran. Kada je test (ili testovi) prihvatljivosti izvršen bez grešaka za sve korisničke priče tada je korisnička priča završena.

12. Kontinuirana integracija: programeri spremaju (eng. upload) kompletirani kod na repozitorij i testove koji su vezani za njega nekoliko puta dnevno. Kod se može spremiti jedino u slučaju da su svi jedinični testovi (eng. unit tests) izvršeni bez grešaka.

13. Inkrementalni dizajn: umjesto da se razvija preuranjen detaljni dizajn prije implementacije, u dizajn se ulaže svaki dan prema iskustvima iz prošlosti.

Posljedične tehničke vještine su opisane:

1. Stvarna uključenost kupca: kupac je uvijek dostupan da bi razjasnio pitanja u vezi zahtjeva te ih prioritizira.

2. Inkrementalni razvoj (eng. incremental deployment): postupno implementiranje funkcionalnosti u živo okruženje kako bi se izbjegao rizik velikih implementacija

3. Kontinuitet ekipe: zadržati učinkovite ekipe zajedno 4. Skupljanje tima: kako raste kapacitet tima (prema iskustvu), treba zadržati njihovo

radno opterećenje, ali postepeno smanjivati tim 5. Analiza korijena uzroka: istražiti uzrok otkrivene greške pisajući testove

prihvatljivosti i jedinične testove. Nakon toga, istražiti zašto je greška napravljena, a nije pronađena u procesu razvoja.

6. Dijeljenje koda: jednom kada se kod snimi na repozitorij zajedno s povezanim testovima, tada je dostupan svim članovima tima.

7. Kodiranje i testiranje: u projektu održavati samo kod i testove. 8. Dnevna implementacija: implementiranje novog koda u produkciju svaku večer 9. Pregovarački opseg ugovora: popraviti vrijeme, troškove i zahtjevanu kavalitetu

projekta, ali pregovarati o opsegu projekta. 10. Plaćanje po uporabi: (eng. pay-per-use) naplatiti korisniku svaki put kada se sustav

koristi za dobivanje njihove povratne ingormacije. 11. Stojeći sastanci: (eng. Stand-up meeting) iako nije službena XP praksa, uobičajeno

svi XP timovi imaju kratke stojeće sastanke. Na tim sastancima osobe stoje u krug, a namjerno na nogama kako bi sastanak trajao kratko. Svaki član ekipe tada izvještava ostale:

• Što je učio prethodni dan

• Što planira odraditi danas

• Ima li ikakvih prepreka ili poteškoća

Metodologija ekstremnog programiranja nije dobra kada postoji otpor ovakvom načinu programiranja, u velikim timovima i nefleksibilnim okolinama, tamo gdje je potrebna opsežna dokumentacija i gdje se povratne informacije dugo čekaju te u okolini gdje je prekovremeni rad uobičajen ili ljudi u timu ne žele (ili ne mogu) komunicirati.

12

3.2 Scrum

Termin Scrum [26, 10] potječe iz ragbija, a znači „vraćanje lopte koja je izašla iz igre nazad u igru“ (uz pomoć timskog rada). Radi se o brzom, prilagodljivom samoorganiziranom procesu razvoja programskog proizvoda. Ovaj pristup koji povećava brzinu i fleksibilnost u razvoju programskog proizvoda, opisali su 1986. godine Hirotaka Takeuchi i Ikujiro Nonaka. Današnji Scrum zacrtali su početkom ’90-tih Ken Schwaber i Jeff Sutherland. Proces razvoja programskog proizvoda provodi se kroz tri faze:

• Prije igre (planiranje, dizajn/arhitektura visoka razina apstrakcije)

• Igra (razvoj, sprintovi – iterativni ciklusi, poboljšanja, nove verzije)

• Poslije igre (nema novih zahtjeva, sustav spreman za produkciju).

Razvoj projekta u Scrumu napreduje iterativno gdje svaka iteracija (sprint) traje dva do četiri tjedna, ali to trajanje mora biti fiksno i unaprijed definirano, tijekom kojih se izrađuje verzija proizvoda spremna za isporuku dok cjelokupni projekt (jedna igra) traje tri do osam sprinteva.

Postoje tri glavna dokumenta koje generira Scrum ekipa: zaliha proizvoda (eng. product backlog), zaliha trenutne iteracije (eng. sprint backlog) i dijagram preostalog posla u Sprintu (eng. Sprint burndown graph). Svaki od njih je dostupan i vidljiv Scrum timu.

• Zaliha proizvoda (eng. product backlog): evoluirajući, prioritizirani red poslovnih i tehničkih funkcionalnosti koje treba implementirati u sustav te grešaka i nedostataka koje treba popraviti tijekom razvoja programskog proizvoda. [10] Za svaki zahtjev u zalihi proizvoda postoji jedinstveni identifikator za zahtjev, kategorija (svojstvo, poboljšanje, nedostatak (greška)), status, prioritet, procjena koliko je vremena potrebno za implementaciju. Zaliha je organizirana i čuva se u obliku tablica, ali je isto tako promjenjiva na više načina. Jedan je od njih uočavanje novih funkcionalnosti koje bi proizvod trebao imati, a koje možda nisu bile očite ili dovoljno jasne u trenutku kada je projekt započeo. Drugi je u slučaju da se neka od funkcionalnosti iz trenutačne zalihe sprinta neće moći implementirati za vrijeme trenutačnog sprinta (npr. ako neki vanjski preduvjeti još nisu zadovoljeni za tu funkcionalnost ili jednostavno nema dovoljno vremena). U takvim se situacijama zadatak mora vratiti u zalihu proizvoda jer produžavanje sprinta izvan inicijalno zadanih vremenskih granica nije dopušteno.

• Zaliha sprinta (zaliha trenutne iteracije): lista svih poslovnih i tehnologijskih svojstava, poboljšanja i nedostataka koji su raspoređeni u trenutnu iteraciju (sprint). Zalihom sprinta se također upravlja u formatu tablica. Zahtjevi su pretvoreni u zadatke te za svaki od njih postoji kratak opis, kako je nastao, tko je vlasnik zadatka, status i vrijeme koje je potrebno da se zadatak završi. Zaliha sprinta se svakodnevno ažurira vremenom koje je preostalo do završetka zadatka. Procjena se može povećati kada član tima shvati da je posao na pojedinom zadatku podcijenjen.

• Dijagram preostalog posla u Sprintu (eng. Sprint burndown graph): prikazuje koliko je sati preostalo da bi se završili sprint zadaci te je uglavnom prikazan Scrum timu. Primjer grafikona je prikazan na slici 3-5:

13

Slika 3-5: Dijagram preostalog posla u Sprintu

Uobičajeno je Scrum tim smješten zajedno, međutim, postoje Scrum timovi koji su geografski razmješteni te gdje članovi tima sudjeluju na dnevnim sastancima preko konferencijske veze. Scrum timovi su samousmjereni i samoorganizirani. Tim se obvezuje da će izvršiti zadane ciljeve u jednoj iteraciji te mu je dana autonomija i odgovornost da odluči kako će do toga doći. Uloge koje su definirane Scrumom su:

• Vlasnik proizvoda: (eng. product owner) odgovoran za izradu i prioritiziranje zalihe proizvoda, odabire što će biti uključeno u sljedeću iteraciju (sprint) i pregledava sustav po završetku sprinta.

• Scrum majstor: (eng. scrum master) zna i pojačava cilj iteracije, održava dnevne sastanke (Scrum sastanci) i demonstraciju iteracije (Sprint pregled), prati napredak, uklanja zapreke i osigurava resurse. Scrum majstor je također razvojni programer i sudjeluje u razvoju proizvoda, odnosno nije samo menadžer.

• Razvojni programer: član Scrum tima koji se zalaže za postizanje cilja sprinta i ima sve ovlasti da učini što god je potrebno da bi to postigao. Scrum tim se najčešće sastoji od 7 članova, a minimum je 5 dok je maksimum 9.

14

Slika 3-6: Scrum proces

Scrum proces se sastoji od nekoliko faza. Prva je planiranje sljedeće iteracije (eng. Sprint planning). Radi se o sastanku koji se održava s razvojnim timom, menadžerima i vlasnikom proizvoda koji predstavlja kupca. Vlasnik proizvoda izrađuje i prioritizira zalihu proizvoda, a na sastanku planiranja izabire svojstva koja će uključiti u sljedeći 30-dnevni sprint vodeći se najvećom poslovnom vrijednosti i rizikom. Cilj sprinta je uspostavljen i drži Scrum tim fokusiran na široku sliku projekta, a ne samo na odabranu značajku. Razvojni tim shvaća zadatke i zahtjevane resurse da bi isporučili svojstva programskog proizvoda. Na sastanku se zajedno određuje razuman broj svojstava koja će biti uključena u sljedeći sprint. U trenutku kada je skup svojstava određen ne može se raditi ponovna prioritizacija svojstava u sljedećih 30 dana do kraja sprinta u kojem će se svojstva dizajnirati, implementirati i testirati.

Sprint se planira tako da ima dovoljno vremena za implementaciju zadataka koji se

stave u zalihu sprinta te je ovdje jako bitna procjena razvojnog tima. Zadaci koji se nađu u zalihi sprinta trebali bi biti detaljnije razrađeni od onih iz zalihe proizvoda, a procijenjena količina posla po zadatku ne bi trebala prelaziti šesnaest sati rada. Zaliha sprinta je nepromjenjiva te u nju nije dopušteno dodavati nove aktivnosti iz zalihe proizvoda jednom kada je sprint počeo čime je timu povjerena odgovornost za procjenu toga što se može načiniti i u kojem vremenu, a pred sprintom se neće naći neočekivane prepreke. Tako su ljudi motiviraniji za rad, a bitne funkcionalnosti odabrane u fazi planiranja imaju veću vjerojatnost da zbilja budu implementirane na vrijeme.

Svakodnevno se tijekom sprinta programski kod integrira te se nad njim vrše

integracijski testovi. Također se svakodnveno održava 15-minutni sastanak (eng. scrum

meeting) koji su slični XP stojećim sastancima. Sastanak počinje uvijek u isto vrijeme na istom mjestu u stojećem položaju, a s obzirom da dugo stajanje na nogama nije ugodno, ovime se osigurava da se članovi tima u razgovoru drže bitnih tema. Sastanak se održava u

15

sobi s pločom tako da se zadaci i nedostaci (blokatori) mogu na nju zapisati kako bi svima bilo vidljivo. Svi mogu prisustvovati Scrum sastanku, ali samo članovi tima i Scrum majstor mogu govoriti. Svaki član tima odgovara na sljedeća pitanja:

• Što je napravio od posljedenjeg Scrum sastanka?

• Što će napraviti od sada do idućeg Scrum sastanka?

• Ima li ikakvih poteškoća? Scrum sastanak je osnovna komponenta metodologije te se na njemu daju obećanja

koja podižu odgovornost i održavaju da projekt ide u pravom smjeru. Međutim, ovi sastanci mogu biti nemogući ukoliko na njima prisustvuje previše ljudi, a preporučeno je da svaki tim ima maksimalno sedam ljudi. Kada postoje veći timovi, oni se dijele u manje skupine gdje svaka od njih ima svoj Scrum sastanak, a nakon toga predstavnik svake skupine sudjeluje na „Scrumu Scrumova“ sastanku gdje odgovara na već navedena pitanja te na ovaj način se šire informacije među podtimovima.

Na kraju Sprinta se radi pregled Sprinta (eng. Sprint review) s ciljem da se utvrdi

napredak, demonstriraju svojstva kupcu, menadžeru, korisniku i vlasniku projekta te da se izvrši pregled projekta iz tehničke perspektive. Na ovom sastanku, kojeg vodi Scrum majstor, a vlasnik proizvoda i drugi zainteresirani mogu prisustvovati, demonstrira se posljednja verzija proizvoda. Dakle, prezentacija u smislu slajdova nije dozvoljena. Ciklus se ponavlja sa sastankom planiranja sprinta (eng. Sprint Planning meeting) na kojem se opet odabiru svojstva koja će se implementirati u sljedećem sprintu.

Scrum je jednostavan, lako razumljiv i čvrst razvojni proces te je usredotočen na bitne

funkcionalnosti koje je razvojni tim sam procijenio da može implementirati. Komunikacijom na svakodnevnim stojećim sastancima rješavaju se tekući problemi i daju obećanja što će se napraviti do idućeg sastanka čime se stvara povjerenje među timom. Rezultat su zadovoljni članovi tima što za posljedicu ima kvalitetniji i brži razvoj, a samim time su zadovoljni naručitelji programskog proizvoda.

16

3.3 Razvoj temeljen na svojstvima (FDD)

Razvoj programskog proizvoda temeljen na svojstvima (eng. Feature Driven

Development – FDD) [11, 12], autora Peter Coad i Jeff de Luca (1997.), karakteriziraju metodologiju posjedovanja „taman dovoljno procesa da bi osigurao skalabilnost i ponovljivost te istovremeno poticao kreativnost i inovativnost“. [26] Metodologiju dalje razvijaju Stephen Palmer i Mac Felsing (2002.). FDD naglašava važnost posjedovanja kvalitetnih ljudi u timu te stručnjaka u određenoj domeni. Fokusira se na dizajn i razvoj sustava, naglašavajući kvalitetu kroz cijeli razvojni proces, uključujući česte isporuke programske podrške i precizno nadgledanje projekta. Dokumenti koji se koriste u procesu su:

• Lista svojstava (eng. features): sastoji se od svojstava koja su mala i korisna u očima klijenta. Svako svojstvo se može implementirati u dva tjedna ili manje. Međutim, ukoliko to nije izvedivo tada se svojstvo razlaže na manje dijelove.

• Dizajn paketi: sastoje se od dijagrama sekvenci (eng. sequence dijagram) i dijagrama klasa (eng. class dijagram) te informacija o metodi dizajniranja

• Praćenje po svojstvima (eng. Track by Feature): graf koji nabraja svojstva koja će se izgraditi i datum kada pojedini miljokaz (eng. milestone) treba biti završen.

• Dijagram odrađenih svojstava tijekom vremena (eng. „Burn up“ grafikon): graf kojemu se na x osi nalazi vrijeme dok se na y osi nalazi broj svojstava koja su završena. Kako svojstva bivaju završena tako ovaj graf poprima pozitivan nagib tijekom vremena.

FDD [32] proces ima pet inkrementalnih, iterativnih procesa kako je prikazano na slici

3-7. Smjernice su dane za vrijeme koji će se potrošiti u svakom od ovih koraka, ograničavajući iznos vremena potrošenog na ukupno planiranje arhitekture i naglašavajući količinu vremena potrošenog na dizajniranje i izradu svojstava.

Procesi od 1 do 3 su gotovi na početku projekta te se ažuriraju tijekom razvojnog ciklusa. Procesi 4 i 5 su završeni inkrementalno unutar ciklusa od dva tjedna. Svaki od ovih procesa ima specifične ulazne i izlazne kriterije.

Slika 3-7: Osnovni procesi FDD

17

Proces 1: Razvoj cjelokupnog modela (vrijeme: 10% na početku, 4% u tijeku). Tijekom ovog procesa definira se obuhvat projekta i ciljanog sustava pri čemu se pozornost ne posvećuje detaljima nego je bitno shvatiti i razumjeti područje u kojem će se razvijani sustav primjenjivati. Za razumijevanje opsega sustava i njegovog konteksta članovi razvojnog tima i grupe stručnjaka u određenom području rade zajedno. Projektni tim se dijeli u manje grupe (preporučljivo 3 osobe po grupi) kako bi modelirali rješenje za svako područje domene problema. Na kraju se rješenja uspoređuju te se konsenzusom odabire najbolje. Potom se nastavlja s drugim područjem dok sva ne budu obrađena i sva rješenja objedinjena u sveobuhvatni model. Proces 2: Izrada liste svojstava (vrijeme: 4% na početku, 1% u tijeku) Na temelju spoznaja dobivenih u prvom procesu, potrebno je identificirati sve „poslovne aktivnosti“ zahtjevane od strane kupca koje trebaju biti implementirane u programskom proizvodu. Sustav se raščlanjuje na manje dijelove koji sadrže određene funkcionalnosti sustava te se svaka pojedina mora moći realizirati u vremenskom intervalu od 2 sata do 2 tjedna. Ako za realizaciju treba više vremena, onda tu funkcionalnost treba raščlaniti na više manjih. Proces 3: Plan po svojstvima (vrijeme: 2% na početku, 2% u tijeku) Tim za planiranje sastoji se od voditelja projekta, voditelja razvoja i glavnog programera koji zajedno planiraju redosljed svojstava koja će se razvijati. Planiranje je temeljeno na ovisnostima, riziku, kompleksnosti, uravnoteženom opterećenju članova tima, zahtjevima kupca za miljokazima i kontrolnim točkama (eng. checkpoint). Poslovnim aktivnostima se dodjeljuju mjesečni/godišnji datumi završetka. Svojstva su grupirana prema tehničkim razlozima umjesto po poslovnim razlozima. Proces 4: dizajniranje po svojstvu (vrijeme: 34% na početku u dvotjednoj iteraciji) U ovom procesu se definiraju one funkcionalnosti koje trebaju u vremenskom intervalu od 2 tjedna biti razvijene. Pri tome se izrađuje detaljni dijagram sekvenci za svaku funkcionalnost. Razvojni programeri se detaljnije upoznaju s onim što razvijaju nakon čega se definira dizajn, a stručnjaci u određenoj domeni zajedno s timom vrše pročišćavanje zahtjevanih svojstava. Proces 5: Razvoj prema svojstvu (vrijeme: 43% na početku u dvotjednoj iteraciji) Na temelju definiranog dizajna započinje se programiranje potrebnih funkcionalnosti. Pri tome nakon osnovnog razvoja slijedi inspekcija koda i pojedinačno testiranje (eng. unit test) te na kraju uključivanje u stabilno izdanje sustava (eng. build).

Uloge koje sudjeluju u procesu razvoja programskog proizvoda metodologijom temeljenom na svojstvima su:

• Projekt menadžer (voditelj projekta): administrativni vođa projekta odgovoran za izvještavanje o napretku, upravljanju budžetom i upravljanje resursima uključujući ljude, opremu i prostor.

• Glavni arhitekt: odgovoran za cjelokupni dizajn sustava uključujući tekuće radionice s timom

18

• Razvojni menadžer (voditelj razvoja): odgovoran za vođenje svakodnevnih razvojnih aktivnosti uključujući rješavanje konflikata oko resursa.

• Glavni programer: iskusni razvojni programer koji djeluje kao vođa tima, mentor i programer za grupu od tri do šest programera.

• Vlasnik klase: odgovoran za dizajniranje, kodiranje, testiranje i dokumentiranje novih svojstava u klase.

• Stručnjak u određenoj domeni: korisnici, klijenti, sponzori, poslovni analitičari itd. koji imaju duboko znanje o proizvodu koji se razvija.

• Tim koji razvija određeno svojstvo: (eng. Feature team) privremena grupa razvojnih programera koja radi na određenom svojstvu. Kada je svojstvo implementirano, za dva tjedna ili kraće, tim se raspušta te formira novi za novo svojstvo.

Iako FDD [28] ima osnovni nedostatak u tome što iziskuje dosta truda i ulaganja u

osnovne procese istraživanja, razvoja, testiranja i evaluacije, njegova glavna prednost je što omogućava česte i vremenski predvidljive isporuke funkcionalnih komponenata sustava.

19

3.4 Kristalna obitelj metodologija

Alistair Cockburn 1991. godine razvija metodologiju za efikasni razvoj programskog proizvoda jer vjeruje da ne postoji „jedna veličina koja svima odgovara“ (eng. one-size-fits-

all) u razvojnom procesu odnosno za sve projekte. Također, smatra da su metodologije koje su orijentirane na ljude (eng. people-centric methodologies) bolje od metodologija koje su orijentirane na proces (eng. process-centric methodologies). U tom kontekstu, Cockburn razvija skup metodologija (engl. family of methodologies) koji je od 1998. godine poznat pod jedinstvenim imenom „Crystal” gdje je svaka pojedina metodologija specifična s različitim pravilima te namijenjena za određenu svrhu. Sve Crystal metodologije naglašavaju važnost ljudi u razvoju programskog proizvoda. „Crystal se usredotočuje na ljude, interakciju, zajedništvo, vještine, talent i komunikaciju kao najvažniji utjecaj na performanse. Proces ostaje važan, ali sekundaran.“ [27] Definirano je sedam ključnih principa Crystal metodologije:

• Učestala isporuka: vrši se svakih nekoliko mjeseci, a korisnici su upoznati s međuverzijama te daju povratne informacije

• Kontinuirane povratne informacije: projektni tim raspravlja o projektnim aktivnostima i o mogućim problemima, a validacija projekta se odvija s korisnicima

• Stalna komunikacija: mali timovi su smješteni u jednoj prostoriji dok su veći timovi lokacijski povezani

• Sigurnost: članovi tima komuniciraju i rade bez represije jer svi projekti nisu kritično isti

• Fokus: članove tima je potrebno upoznati s prioritetnim ciljevima te im dati mogućnost da ih ostvare

• Raspoloživost korisnika: članovima tima treba omogućiti suradnju s korisnicima tijekom cijelog projekta

• Automatski testovi i integracija: definirani su različiti oblici verifikacije funkcionalnosti projekta

U obitelji Crystal metodologija inkrementalni ciklus ne smije biti duži od 4 mjeseca, a

radionice se moraju održati nakon svake isporuke proizvoda tako da metodologija bude samoprilagodljiva te da se nakon pogleda unatrag uči iz vlastitih grešaka. U ovoj metodologiji projekt će biti uspješan ukoliko ljudi sjede zajedno te često komuniciraju, ako je eliminirana birokracija te smanjena papirologija, a korisnik je direktno uključen u projekt te su napisani dobri testovi.

Kristalne metodologije [13] su razvijene za rješavanje varijabilnih okolina i specifičnih karakteristika projekta. Različitim metodama su dodijeljene boje rapoređene prema opadajućoj prozirnosti pa je stoga najagilnija metodologija Kristalno čista (eng. Crystal

Clear), zatim Kristalno žuta (eng. Crystal Yellow), Kristalno narančasta (eng. Crystal Orange) i Kristalno crvena (eng. Crystal Red). Graf na slici služi kako bi pomogao u izboru Crystal metode. Na x-osi se nalazi veličina tima. Što je tim veći, teže je upravljati procesom međusobnom komunikacijom te je stoga veća potreba za dokumentacijom, praksom i alatima.

20

Y-os označava potencijal sustava za uzrokovanje štete. Najmanja šteta uzrokuje nedostatak udobnosti, zatim gubitak diskrecijskog novca, nakon toga gubitak esencijalnog novca te naposljetku „gubitak života“, odnosno gubitak projekta. Temeljem veličine tima i kritičnosti, odabire se odgovarajuća Crystal metoda. Svaka metodologija ima skup preporučenih praksi, skup uloga, tehnika i zapisa. Najpoznatije metodologije su cystal clear, crystal orange i crystal orange web.

Slika 3-8: Kristalna obitelj metodologija [56]

3.4.1 Crystal Clear

Crystal Clear [13] je orijentiran (usmjeren) na D6 projekt, a može se primjeniti na C6 i E6 projekte te vjerojatno i na D10 projekt. Crystal Clear je optimizacija Crystal-a koja se može primjeniti na timove koji se sastoje od 3 do 8 osoba koji se nalaze u istoj prostoriji ili spojenim uredima. Neposredna komunikacija ojačava tim na način da članovi čuju jedni druge dok razgovaraju o prioritetima projekta, statusu, zahtjevima i dizajnu na dnevnoj osnovi. Elementi Crystal Clear metodologije su:

• Dokumenti: plan puštanja u rad, raspored recenzija, neformalni slučajevi korištenja (eng. use cases), skice dizajna, testovi i korisnički priručnik

• Uloge: sponzor projekta (kupac), senior programer projektant, programer projektant, korisnik (barem dio vremena)

• Proces: inkrementalna dostava projekta, puštanje u rad u manje od dva do tri mjeseca, automatizirani testovi, korisnik je direktno uključen, dvije korisničke recenzije prije puštanja u rad te praćenje napretka na projektu.

21

3.4.2 Crystal Orange

Crystal Orange je orijentiran (usmjeren) na D40 projekt. Crystal Orange je za 20-40 programera koji rade zajedno u jednoj zgradi na projektu na kojem oštećenja mogu uzrokovati gubitak diskrecijskog novca, tj. srednji rizik. Trajanje projekta je od jedne do dvije godine Elementi Crystal Clear metodologije su:

• Dokumenti: dokumentacija zahtjeva, plan puštanja projekta u rad (eng. release plan), raspored, izvještaji o statusu, dokumentacija dizajna korisničkog sučelja, specifikacija među timom, testovi, migracijski kod i korisnički priručnik

• Uloge: sponzor projekta, ekspert u poslu, ekspert u korištenju, tehnički pomagač, poslovni analitičar, voditelj projekta, arhitekt, mentor za dizajn, voditelj programer projektant sustava, programer projektant sustava, dizajner korisničko sučelja, tester

• Proces: inkrementalna dostava projekta, puštanje u rad u manje od tri do četiri mjeseca, automatizirani testovi, korisnik je izravno uključen, dvije korisničke recenzije prije puštanja u rad.

22

3.5 Metoda dinamičkog razvoja sustava (DSDM)

Mnoge metodologije koje su danas poznate kao agilne nastale su prije Agilnog manifesta, a jedna od takvih je metoda dinamičkog razvoja sustava (eng. Dynamic System

Development Method – DSDM) [30]. DSDM metodologija je prvi put objavljena 1995. godine te je tada bila jedina RAD (eng. Rapid Application Development) metoda u svijetu, a izrađena je prema praktičnim vještinama tijekom godina od članova neprofitne organizacije DSDM konzorcija. Od tada je DSDM razvijen u okvir za razvoj aplikacija orijentiranih na poslovanje (eng. Framework for Business Centred Development) te je postao jedan od predvodnika Agile Alliance, a daljnjim razvitkom je 2006. godine izdana inačica 4.2 DSDM-a.

DSDM [14] je agilna metodologija kojoj je cilj pravovremeno isporučiti poslovno rješenje, a sastavljena je od niza vodećih načela, životnog ciklusa projekta sa fleksibilno definiranim skupom proizvoda, jasno definiranim ulogama u projektu i njihovim odgovornostima te nizom najboljih praktičnih tehnika koje omogućuju isporuku programskog proizvoda.

Slika 3-9: DSDM okvir

Principi Snaga DSDM-a je u njegovim principima koji omogućavaju da se projekti isporuče na najučinkovitiji mogući način:

1. Aktivno sudjelovanje korisnika 2. Tim mora donositi odluke 3. Česta isporuka proizvoda 4. Tim mora isporučiti proizvod koji služi korisniku 5. Iterativni i inkrementalni razvoj 6. Sve promjene za vrijeme razvoja se mogu poništiti 7. Osnovni zahtjevi su definirani na početku 8. Testiranje i integracija se provodi tijekom čitavog projekta 9. Suradnja i kooperacija između svih sudionika je ključna

23

U DSDM-u kompletni životni ciklus započinje s Pred-projektnom fazom, a završava s

Post-projektnom fazom.

Slika 3-10: Životni ciklus DSDM-a

3.5.1 Opis DSDM faza

Životni ciklus DSDM Aterna dozvoljava projektu da ide od kontroliranog početka do točke gdje je razumijevanje projekta dovoljno dobro za početak iterativne i inkrementalne izrade programskog proizvoda. Dijagram životnog ciklusa je poznat kao „tri pizze i sir“ dijagram gdje „sir“ predstavlja dvije faze sekvencijalnog početka u kojima projekt počiva na čvrstim temeljima gledano sa svih točaka gledišta dok „pizze“ predstavljaju pristup u kojem je glavni fokus na pravovremenoj isporuci programskog proizvoda.

24

DSDM se fokusira na IT projekte s kratkim rokovima i ograničenim budžetima, definira 3 osnovne sekvencijalne faze:

1. Pred-projektna faza 2. Projekta faza

1. Studija izvedivosti 2. Poslovna studija 3. Iteriranje funkcionalnog modela 4. Iteriranje dizajna i razvoja 5. Implementacija

3. Post-projektna faza

U pred-projektnoj fazi projekt se identificira te se osigurava budžet i angažiranost za njegovu realizaciju. Aktivnosti ove faze ovise o lokalnoj praksi za pokretanje projekata.

Projektna faza sastoji se od pet podfaza. Prve dvije, studija izvedivosti i poslovna

studija, komplementarne su, a odnose se na analizu ostvarivosti s obzirom na moguće rizike, te na karakteristike ciljanog tržišta. Ciljevi studije izvodivosti su utvrditi može li predloženi razvoj zadovoljiti poslovne zahtjeve organizacije te da procijeni prikladnost primjene programskog proizvoda DSDM razvoju. Također, ciljevi ove studije su da skicira moguća tehnička rješenja poslovnog problema kao i da procijeni vremenske i financijske troškove. Studija izvodivosti treba biti detaljna toliko da procijeni je li izvodivo rješenje postoji ili odabrati najprikladnije. Detalji zahtjeva, rizici, planiranje, trošak itd. se razvija u idućim fazama. Ciljevi poslovne studije su opseg poslovnih procesa koji će biti podržani te skica budućeg razvoja u smislu prototipiranja isporuke. Osim toga, identificiranje reprezentativnih korisničkih klasa za prototipiranje aktivnosti; prioritiziranje zahtjeva predloženog sustava; preispitivanje rizika projekta; osiguravanje čvrste osnove za tehnički razvoj i skup nefunkcionalnih zahtjeva, osobito zahtjeva održavanja sustava. Treća, iteriranje funkcionalnog modela, sastoji se od identificiranja funkcionalnosti, izrade i revizije funkcionalnog prototipa, zajedno s određivanjem vremenskog rasporeda kad i kako treba razviti pojedine funkcionalnosti. Četvrta, iteriranje dizajna i razvoja, odnosi se na identificiranje, izradu i provjeru dizajnerskog prototipa što uključuje i vremenske planove, strategiju implementacije kao i korisničku dokumentaciju i plan testiranja. Zadnja podfaza odnosi se na implementaciju, a uključuje korisničko prihvaćanje dizajna, treniranje krajnih korisnika, implementaciju kod krajnjih korisnika te reviziju utjecaja razvijenog sustava na poslovanje tj. utvrđivanje koliko izrađeni sustav zadovoljava postavljene ciljeve.

Post-projekta faza osigurava da sustav funkcionira efektivno i efikasno, a to se

ostvaruje kroz održavanje, poboljšanja i popravke.

25

3.5.2 Uloge u projektu

Definirano je 12 uloga te svaka od njih ima određene odgovornosti. Strukturirani su na takav način da svaki od njih može biti predstavljen u projektu. Projektna razina: Poslovni sponzor, poslovni vizionar, voditelj projekta, tehnički koordinator Timska razina: voditelj tima, poslovni ambasador, poslovni analitičar, razvojni programer, tester Ostali: poslovni savjetnik, voditelj radionice, DSDM Atern učitelj

Slika 3-11: DSDM organizacija tima

26

3.6 Adaptivni razvoj programskog proizvoda (ASD)

Adaptivni razvoj programskog proizvoda (eng. Adaptive Software Development –

ASD) [15, 31] se uglavnom fokusira na probleme u razvoju velikih i kompleksnih sustava. Metodologija snažno potiče inkrementalni i iterativni razvoj s konstantnim prototipiranjem. U osnovi, ASD je „balansiranje na rubu kaosa“, tj. njen cilj je omogućiti okvir s dovoljno vodilja da se spriječi padanje projekta u kaos, ali da se ne onemogući kreativnost. ASD projekt se provodi u tri ponavljajuće faze:

1. Istraživanje i razmišljanje 2. Suradnja 3. Učenje

Slika 3-12: Faze životnog ciklusa ASD-a

3.6.1 Faza istraživanja i razmišljanja

Postoji pet osnovnih koraka u fazi istraživanja i razmišljanja iako svaki korak može biti izmjenjen nekoliko puta tijekom podfaza pokretanje projekta i planiranja. Pri pokretanju projekta potrebno je postaviti ciljeve projekta, razumjeti ograničenja, uspostaviti organizaciju projekta, identificirati i skicirati zahtjeve čime se može procijeniti veličina i opseg projekta. Vrijeme potrebno za fazu pokretanja projekta u malim i srednjim projektima je dva do pet dana dok je za velike projekte potrebno dva do tri tjedna. Nadalje, vremenski okvir za cjelokupni projekt je definiran na temelju opsega, veličine zahtjevanih svojstava programskog proizvoda i raspoloživosti resursa.

Treći korak je odluka o broju iteracija i definiranje vremenskog roka za svaku od njih.

za aplikacije male i srednje veličine, iteracija obično varira od četiri do osam tjedana. Pojedini projekti najbolje napreduju u dvotjednim iteracijama dok je za druge potrebno više od osam tjedana iako je to rijetko. Veličina cjelokupnog projekta i stupanj nesigurnosti u projektu su dva čimbenika koja određuju dužinu pojedine iteracije.

27

Nakon utvrđivanja broja iteracija i njihovog rasporeda, članovi tima i kupac određuju ciljeve svake od iteracija. Svaka iteracija donosi vidljiv skup svojstava koje kupac pregledava. Razvojni programeri dodjeljuju zadatke za svaku pojedinu iteraciju po kriteriju da se na kraju iteracije kupcu prikaže vidljiv skup svojstava programskog proizvoda. U procesu dodjeljivanja zadataka, kupac odlučuje o prioritizaciji svojstava koja će se implementirati koristeći procjenu svojstava, rizik i informacija koje je dobio od tima. Iskustvo je pokazalo da je planiranje koje provodi razvojni tim umjesto voditelja projekta pruža bolje razumijevanje projekta.

3.6.2 Faza suradnje

Dok tehnički tim isporučuje programski proizvod, voditelj projekta olakšava suradnju i istovremene razvojne aktivnosti. Vitalne značajke u projektima koji uključuju distribuirane timove i različite partnere su komunikacija među ljudima i njihove međuovisnosti.

Za manje projekte u kojima su članovi tima fizički u neposrednoj blizini, suradnja se

sastoji od neformalnih razgovora i pisanja na ploči. Veći projekti zahtjevaju dodatne vještine kao što su alati za suradnju te interakcija voditelja projekta koji potiče povjerenje i poštovanje. Podijeljeno razvijanje programskog proizvoda obuhvaća razvojni tim, kupce, vanjske konzultante i prodavače, a tim mora surađivati po pitanju tehničkih problema, poslovnih zahtjeva i brzog donošenja odluka.

3.6.3 Faza učenja

Faza učenja je teška u okolinama gdje vlada pravilo da sve mora biti dobro napravljeno iz prvog pokušaja te gdje je razvojni progres linearan poput vodopadnog modela. Ukoliko su ljudi stalno primorani raditi bez greške, oni neće eksperimentirati ni učiti. Također, u vodopadnom modelu ne smije biti nikakvih grešaka u fazama jer nema povratka.

Učenje iz grešaka i eksperimentiranja zahtijeva da članovi tima dijele djelomično

završeni kod s ciljem pronalaska grešaka, učenja iz njih i reduciranja ukupne količine ponavljanja istog posla pronalaskom malih problema prije nego postanu veliki. Četiri su opće kategorije stvari koje se mogu naučiti na kraju razvoja svake iteracije:

1. Kvaliteta rezultata iz korisnikove perspektive: dobivanje povratne informacije od korisnika je prvi prioritet u ASD metodologiji jer korisnik najbolje ocjenjuje programski proizvod, a ne dokumentacija i dijagrami.

2. Kvaliteta rezultata iz tehničke perspektive: standardna praksa za tehničku procjenu kvalitete programskog proizvoda su periodični tehnički pregledi programskog koda, cjelokupne arhitekture i slično.

3. Funkcioniranje razvojnog tima: razvojni tim prati svoju kvalitetu. Na kraju iteracije, mini retrospektivom se može odrediti što nije funkcioniralo, što tim treba raditi bolje i što tim treba raditi manje s ciljem poticanja tima da nauče kako bolje raditi zajedno.

4. Status projekta: cilj pregleda statusa projekta je bolje planiranje sljedeće iteracije. Osnovna pitanja ovog pregleda su: „Gdje se nalazi projekt u odnosu na plan?“ i „Gdje bi trebao biti?“

28

Faze projekta su imenovane na način da naglase uloge u projektu. „Istraživanje i razmišljanje“ se koristi umjesto planiranja na koje se općenito gleda kao nešto gdje je nesigurnost slabost te odstupanja od planiranja ukazuju na nauspjeh. „Suradnja“ naglašava važnost timskog rada kao sredstva za razvijanje sustava koji su podložni velikim promjenama dok „Učenje“ naglašava potrebu za znanjem i reagiranjem na pogreške i promjene zahtjeva.

3.6.4 Principi adaptivnog razvoja programskog proizvoda

ASD počiva na sljedećim principima:

• Orijentiranost na zadatak: aktivnosti u svakom razvojnom ciklusu moraju biti opravdani prema cjelokupnom projektu. Ciklus se može korigirati kako razvoj napreduje.

• Temeljen na komponentama: razvojne aktivnosti ne bi trebale biti orijentirane na zadatke nego fokusirane na razvoj programskog proizvoda, tj. na izgradnju malih komada na vrijeme.

• Iterativnost: većina razvojnih procesa je turbulentna, a sami napor za razvoj programskog proizvoda bi stoga trebao biti fokusiran na ponovni rad umjesto na točan rad iz prvog pokušaja.

• Vremenski okviri: upravljanje projektom zasnovano na vremenskim okvirima forsira sudionike projekta na neizbježne odluke u ranoj fazi projekta što znači da svaka iteracija ima ograničeno vrijeme.

• Tolerancija na promjene: vrlo je važno moći se prilagoditi promjenama nego ih kontrolirati. Za izgradnju sustava tolerantnog na promjene, razvojni programeri moraju konstantno procjenjivati vjerojatnost promjene.

• Orijentiranost na rizik: razvoj visokorizičnih predmeta treba započeti što je ranije moguće.

Životni ciklus ASD-a [15] se fokusira na rezultate, a ne na zadatke i rezultati su

identificirani kao značajke aplikacije. Značajke su korisničke funkcionalnosti koje se razvijaju tijekom iteracije. Dokumentacija (npr. podatkovni model) je uvijek sekundarna naspram značajkama programskog proizvoda koji pružaju izravne rezultate kupcu (dokumentacija koja se odnosi na kupca kao što su „Upute za uporabu“ je isto značajka proizvoda). Značajke se mogu razvijati kroz nekoliko iteracija ovisno o povratnom odgovoru korisnika.

29

4 Kanban agilna metodologija

4.1 Lean koncept

Kanban agilna metodologija razvoja programskog proizvoda slijedi linijski razvoj proizvoda (eng. Lean software development) [33, 35]. Pojam „lean“ (eng. vitak) predstavlja motiv da se utroši manje vremena, manje ljudskog napora, manje investicija, manje napora i manje kapitala prilikom razvoja. Termin je prvi put primijen u knjizi „The machine that changed the world“ J. P. Womack-a i D. T. Jones-a, koja je bila rezultat istraživačkog rada IMVP-a (eng. International Motor Vehicle Program), a gdje su autori prvi put opisali razlike između Japanske i zapadne automobilske industrije i prvi put upotrijebili izraz „lean“ za Toyotin način proizvodnje.

„Lean“ [34, 36] je proizvodna filozofija koja kada je implementirana skraćuje vrijeme

od narudžbe kupca do isporuke gotovog proizvoda, eliminirajući sve izvore rasipanja (gubitaka) u proizvodnom procesu. Rasipanje (engl. waste, jap. muda) su elementi proizvodnog procesa, koji ne sadrže nikakvu vrijednost, tj. to su aktivnosti koje ne donose direktnu vrijednost proizvodu. Prema Taiichi Ohno2 postoji sedam tipova rasipanja:

1. Prekomjerna proizvodnja: a. stvaranje proizvoda koji se ne mogu plasirati na tržištu b. predetaljna obrada c. izvođenje operacija koje nisu neophodne d. stvaranje dokumentacije koju nitko ne zahtjeva ili koja uopće neće kasnije

koristiti e. loše predviđanje (procjena) prodaje, tj. zahtijevanje tržišta f. slanje uputa prema previše (ili premalo) ljudi g. proizvodnja „za svaki slučaj“

2. Transport a. neučinkovit transport informacija b. neuspješna komunikacija: gubitak podataka, nekompatibilnost, nepouzdanost

informacija 3. Vrijeme čekanja

a. vrijeme čekanja između operacija b. čekanje na rezultate testova, informacije, odluke, potpis, odobrenje

4. Prekomjerna obrada a. previše procesa obrade b. loš dizajn proizvoda koji zahtjeva previše koraka obrade (prekompleksan

proizvod) 5. Zalihe

a. visoke zalihe povezane su s prekomjernom proizvodnjom

2 začetnik Toyotinog sustava proizvodnje (eng. Toyota Production System – TPS)

30

6. Nepotrebni pokreti a. premala automatiziranost pojedinih procesa b. ručni rad kako bi se kompenzirali nedostaci automatizacije

7. Škart a. prekid toka zbog grešaka, nepotrebna vremena, troškovi za analizu i

otklanjanje b. nepotpune, netočne, nepravodobne informacije

Osnovno načelo „lean“ proizvodnje je da se proizvodi točno ono što kupac ili klijent

želi, tj. vrstu, kvalitetu i količinu proizvoda izravno diktira potražnja tržišta. „Lean“ se primjenjuje zbog konstantno promjenjivog tržišta, visokih zahtjeva kupaca i konkurencije te se njegovom primjenom postiže:

• Skraćuje se ukupno vijeme proizvodnje

• Povećava se radni učinak

• Reducira se papirologija

• Pojednostavnjuje se planiranje

• Veća angažiranost zaposlenih

• Povećanje kvalitete

• Brži odgovor na promjene u zahtjevima tržišta

Sve aktivnosti u lancu vrijednosti mogu se podijeliti na aktivnosti koje dodaju vrijednost, aktivnosti koje ne dodaju vrijednost, ali su neophodne i aktivnosti koje ne dodaju vrijednost i nisu neophodne. Unaprijeđenje proizvodnog procesa je fokusirati se na poboljšanje aktivnosti koje dodaju vrijednost te paralelno smanjiti vrijeme trajanja aktivnosti koje ne dodaju vrijednost.

4.2 Kanban

U Japanskom rječniku „kan“ znači „signal“ dok „ban“ znači „kartica“ ili „ploča“. Kanban kartica [37] je signal koji treba pokrenuti akciju i koja upućuje na kretanje ili izradu dijelova u „pull“ proizvodnom sustavu, izumljenom i razvijenom 1950-ih kao dio Toyota proizvodnog sustava (eng. Toyota Production System – TPS). Prema tome Kanban se odnosi na „signalne kartice“ kojima se signalizira potreba za određenim proizvodom. Taiichi Ohno je dobio ideju za Kanban kada je bio u posjeti američkom supermarketu gdje se polica dopunjava kada se količina na njoj smanji na određenu mjeru (pull mehanizam).

Kanban se u proizvodnoj industriji proširio po cijelom svijetu kao alat linijske proizvodnje (eng. Lean Manufacturing), a u agilnom razvoju programskog proizvoda je način vizualizacije projekta postavljanjem kartica sa zadacima na ploču kojima se postiže „upravo na vrijeme“ (eng. just in time – JIT) strategija razvoja programskog proizvoda.

Tok kartica implicira da postoji glatki neprekinut protok između niza koraka koji uključuje sve od kupca do podrške inženjera, a ne samo razvojnog tima. Kontinuirani glatki protok vrijednosti, novih značajki u razvoju je idealan krajnji rezultat. Kroz mjerenje

31

podataka je moguće procijeniti timsku učinkovitost, tj. koliko se vremena troši na dodavanje, odnosno ne dodavanje značajki u programski proizvod.

Linijsko Kanban razmišljanje se općenito daleko više fokusira da posao bude izveden na vrijeme umjesto da se fokusira na tko to tko ga je odradio. Ljudi rade zajedno, ali ne rade svi istom brzinom, nemaju ista znanja i vještine te se moraju sinkronizirati. U Kanbanu je rad organiziran po zadatku ili procesu te dozvoljava članovima tima da sami primjenjuju tijek rada na najučinkovitiji način.

Pravila Kanbana su takva da se ne razmatraju značajke programskog proizvoda koje netko ne treba odmah; ne piše se više specifikacije nego što se može isprogramirati; ne piše se više koda nego što se može testirati te se ne testira više nego što se može pustiti u rad.

Kanban sustav u programskom inženjerstvu izgleda tako da postoji posao koji čeka u redu te prolazi kroz faze dok ne bude završen. Kada je posao u fazi završen tada prelazi u drugu fazu kako je prikazano na slici 4-1. Kada netko treba posao povuče ga iz prethodne faze. Prednosti Kanbana u odnosu na tradicionalne „push“ sustave su:

1. Jednostavan i razumljiv proces 2. Pruža brze i precizne informacije 3. Niski troškovi prijenosa informacija 4. Brz odgovor na promjene 5. Ograničenje kapaciteta u procesu 6. Izbjegava hiperprodukciju 7. Minimizira rasipanje 8. Kontrola se može održavati 9. Delegira odgovornost linijskim radnicima

4.2.1 Principi

Osnovna načela Kanbana [38] u programskom inženjerstvu, a koja tim kontinuirano prati su:

• Vizualna kontrola (Kanban ploča)

• Ograničenje posla u procesu (eng. Limit Work in Process – WIP)

• Povlačenje (eng. pull) kartica (s ograničenjem WIP)

• Povećanje propusnosti

• Fiksna Kanban zaliha (eng. backlog)

• Kvaliteta ugrađena u proces

4.2.1.1 Kanban ploča

Korištenje obojanih kartica i njihovo objavljivanje za različite tipove poslova te objavljivanje na karticama može brzo omogućiti radnom timu da:

• Vide ono na čemu rade (kartice daju vrijednost određenom poslu)

• Poprave vizualni pokazatelj blokatora

• Procijene koliko je bila dobra analiza i proces osiguranja kvalitete

32

• Provedu jednostavno praćenje (koliko je stavki premašilo zadani rok, koliko ima blokatora itd.)

Ukoliko postoji hitan slučaj u vidu zahtjeva za podršku ili greške u programskom

proizvodu u produkciji tada se koristi prazno mjesto na Kanban ploči označeno kao „Hitno“. Zadaci koji se rješavaju ovim putem ne stavljaju se prvotno u zalihu te je cilj njih riješiti što prije. Prednosti Kanban ploče su vidljivost sljedećeg:

• Na čemu pojedina osoba radi

• Je li preopterećen poslom

• Gdje se nalazi „usko grlo“

• Gdje se stvaraju rupe u poslu

• Što je blokirano

Slika 4-1: Primjer Kanban ploče

Na slici 4-1 je prikazana Kanban ploča na kojoj je cilj riješeni zadatak F prebaciti u

fazu testiranja (stupac „Test“) u kojem se mogu nalaziti maksimalno dva zadataka. S obzirom da se nalaze točno dva, jedan od njih treba do kraja istestirati te prebaciti u stupac „Gotovo“. Iz ovoga je vidljivo da je stupac „Test“ usko grlo te da bi tok zadataka ostao konstantan netko od radnika treba pristupiti testiranju D ili E kartice.

33

Jedna Kanban ploča dozvoljava vođenje više projekata koji se mogu označavati različitim bojama kartica ili su odvojeni crtom. [41]

Slika 4-2: Vođenje više projekata na jednoj Kanban ploči

Svaki stupac Kanban ploče predstavlja jedno stanje procesa ili pak red čekanja u

kojem se spremaju zadaci koji čekaju na obradu. Broj stupaca na ploči je fleksibilan, a dodaju se po potrebi.

4.2.1.2 Ograničenja na Kanban ploči

Ograničenja na Kanban ploči po pojedinom stupcu nisu striktno definirana nego se do njih dolazi praksom kroz rad. Kada je određeni stupac po definiranom kriteriju popunjen tada radnik koji čeka da se stupac isprazni, tj. koji trenutno nema što raditi gleda postoji li negdje „usko grlo“ te ga pomaže riješiti. Ukoliko ne postoji „usko grlo“ to može biti znak da su ograničenja po stupcima premala jer smanjenje posla u procesu (eng. Work In Progress –

WIP) po stupcima se radi s ciljem bržeg protoka zadataka. Međutim, ako na ploči postoji veliki broj zadataka na kojima duže vrijeme nitko ne radi može se zaključiti da je ograničenje po stupcima preveliko. Slijedom navedenog vrijedi:

• Premaleno Kanban ograničenje po stupcu je znak da ljudi miruju, tj. nemaju posla što rezultira lošom produktivnošću

• Preveliko Kanban ograničenje po stupcu je znak da zadaci miruju što rezultira lošim vremenom vođenja (eng. lead time)

Kanban ploča za razliku od ploče agilnih metodologija ima ograničenja. Iz razloga što

je cilj novu funkcionalnost programskog proizvoda izdati što prije, ograničava se količina posla koja se može odraditi istovremeno. Postoje dva osnovna ograničenja:

1. Redovi čekanja: stupci na Kanban ploči gdje se gomilaju zadaci do definiranog maksimalnog broja. Primjerice u stupcu „Zadaci“ može se nalaziti pet kartica.

2. WIP graničenje [40]: određuje maksimalan broj radnih zadataka koji mogu biti u određenom stanju. Primjerice u stupcu „Razvoj“ mogu biti maksimalno tri kartice.

34

4.2.2 Uloge u projektu

Za razliku od svih drugih agilnih metodologija razvoja programskog proizvoda, Kanban metodologija nema uloge u projektu. To ne znači da ih ne smije imati nego samo da ne trebaju.

4.2.3 Nova vrsta sastanaka

Glavna razlika u Kanban dnevnim stojećim sastancima [39] je da moderator nabraja po karticama, a ne po ljudima. Pregled posla se vrši s desna na lijevo kako bi se naglasio „pull“ sustav. Ploča pokazuje ukupan status posla umjesto da fokus bude na iznimkama.

4.2.4 Kaizen

Kaizen [37] je japanski izraz za kontinuirano poboljšanje. To je stroga znanstvena metoda koja koristi statističku kvalitetu kontrole (eng. Statistic Quallity Control – SQC) i prilagodljivi okvir organizacijskih vrijednosti i uvjerenja koje drže radnike i voditelje projekta podjednako usmjerene na minimum grešaka. To je filozofija kojom se postiže da radnici nikad nisu zadovoljni s onim što je postignuto prošli tjedan ili prošlu godinu nego se teži savršenstvu.

Za razliku od zapadne kulture gdje velike ideje i poboljšanja dolaze od menadžera i

inženjera, u Japanu velika poboljšanja dolaze od konstantnih malih poboljšanja od strane radnika iz pogona. Glavni ciljevi Kaizena su:

• Podići razinu osviještenosti zaposlenika o korisnim aspektima promjena

• Otvoriti i proširiti vidike zaposlenika i menadžera

• Standardizacija postojećih procesa

• Obuka/edukacija zaposleniak za rad na različitim poslovima

• Poticanje timskog rada i zajedništva

Tim je odgovoran za poboljšanja trenutnog sustava i procedura uključujući sami Kanban koji se unaprijeđuje s vremenom prema Kaizen modelu. Cilj je prepoznati sve oblike rasipanja, a trenutno stanje treba analizirati te osmisliti plan poboljšanja. Moto Kaizena je da se ne traže krivci nego se rješavaju problemi. Kaizen ciklus ima četiri koraka:

1. Uspostavljanje plana promjene svega što se može poboljšati 2. Provođenje promjena u malim koracima 3. Proučavanje rezultata 4. Proučavanje procesa i učenje

4.2.4.1 Metrika

Metrika je vrlo važan dio Kanbana. Razlikuju se vrijeme vođenja [39] (eng. lead time), vrijeme ciklusa (eng. cycle time) i vrijeme reakcije (eng. reaction time). Vrijeme vođenja počinje kada je kreiran zadatak, tj. izrađena kartica, a završava kada je zadatak odrađen i pušten u rad (eng. release). Ono ne može biti kraće od vremena ciklusa.

35

Vrijeme ciklusa počinje kada se počne raditi na određenom zadatku i završava kada je taj zadatak spreman za puštanje u rad. Vrijeme reakcije ili vrijeme odgovora počinje u trenutku kreiranja zadatka, a završava određivanjem njegovog prioriteta.

Vrijeme vođenja je vrijednost koju vidi kupac dok je vrijeme ciklusa mehanička mjera

sposobnosti procesa. U kontekstu održavanja koristi se SLA (eng. Service Level Agreement) na mjestima koja definiraju u kojem vremenu se mora završiti zadatak te se naziva vrijeme razlučivosti (eng. resolution time), a koje je u stvari isto što i vrijeme vođenja.

Slika 4-3: Metrika u Kanbanu

Poboljšanje vremena ciklusa se može postići:

• Smanjenjem broja stvari u procesu

• Poboljšanjem prosječne stope dovršenja posla

• Smanjenjem ponovnog rada istog posla

• Podešavanjem visoke vidljivosti blokatora

• Provođenjem analize da se identificiraju stavke koje su prevelike

U Kanbanu se također definira propusnost, a to je stopa isporuke odrađenog posla kupcu. Dvije glavne varijable reguliraju propusnost: WIP i vrijeme ciklusa. Propusnost omogućuje predviđanje budućih mogućnosti.

36

4.2.5 Vremenski okviri u iteraciji

Vremenski okviri unutar iteracije za Kanban metodologiju nisu propisani te se stoga planiranje, puštanje u rad i poboljšanja u procesu rade po potrebi. Moguće je ove aktivnosti odrađivati na vremenskoj osnovi (npr. puštanju u rad svaki ponedjeljak) ili na zahtjev (npr. puštanje u rad kada je završeno nešto korisno).

37

5 Zaključak

Za vrijeme trajanja razvoja programskog proizvoda događa se toliko promjena da razvojni tim teško može definirati sami proces. Skup predefiniranih koraka možda neće dovesti do poželjnog i predvidljivog ishoda jer je razvoj programskog proizvoda izrazito ljudska djelatnost u kojoj dolazi do problema promjene zahtjeva kupca, promjena tehnologije, promjena razvojnih programera itd. Drugim riječima, varijanca procesa je vrlo visoka.

Područje koje je zajedničko svim metodologijama je važnost ljudi i njihovih uloga u procesu te spoznaja da više od bilo kojeg procesa, alata koji se koristi ili definiranog pristupa, ljudi su najutjecajniji faktor svakog projekta.

Prednost agilnih metodologija je sposobnost da se nose s ispravkama ili nedostacima koji su se pojavili u programskom proizvodu. Reakcija kojom će doći do ispravke pogreške treba biti brza te popravak mora biti primjenjen unutar životnog ciklusa faze (iteracije) u kojem je primljena informacija o grešci. Međutim, uvođenje povratne informacije u proces razvoja programskog proizvoda će ovisiti o mogućnostima razvojnih inženjera u organizaciji.

Fokus Kanbana nije da postane agilna metodologija razvoja programskog proizvoda koja može i treba dovesti do uspjeha nego se Kanban usredotočuje na uspješnost izrade samog programskog proizvoda, a taj proces može dovesti do toga da je Kanban agilan. Kanban je maksimalno fleskibilan, ali istovremeno postoje jasno definirana pravila koja određuju proces.

Isporuka programskog proizvoda sa što manjim brojem grešaka i na vrijeme je cilj svake metodologije razvoja te se stoga definira propusnost koja omogućuje predviđanje budućih mogućnosti na temelju prikupljenog znanja i iskustva. Propusnost je stopa isporuke odrađenog posla kupcu koju u Kanbanu određuju dvije glavne varijable: vrijeme ciklusa i ograničenja posla u procesu.

Poboljšanjem vremena ciklusa ubzala bi se obrada zadataka te njihovo učestalije puštanje u rad što je moguće postići razbijanjem korisničkih priča na manje dijelove detaljnom analizom, smanjenjem ponovnog odrađivanja istog posla, automatizacijom pojedinih procesa, podešavanjem visoke vidljivosti blokatora te njihovo aktivno uklanjanje itd.

Uz vrijeme ciklusa, ograničenje posla u procesu je također varijabla koja određuje propusnost sustava. Pravilnim i pametnim definiranjem ograničenja po stupcima izbjegava se loša produktivnost koja nastaje uslijed premalih ograničenja što dovodi do mirovanja radne snage i loše vrijeme vođenja koje je rezultat prevelikih ograničenja po stupcima što znači da su pojedini zadaci u stanju mirovanja.

38

Dakle, unaprijeđenje proizvodnog procesa je fokusirati se na poboljšanje aktivnosti koje dodaju vrijednost te paralelno smanjiti vrijeme trajanja aktivnosti koje ne dodaju vrijednost projektu te koristiti kvalitetniju metriku u cilju boljeg predviđanja budućeg projekta.

39

6 Reference

[1] Denning, P. J.: „Computer Science: The Discipline“, Encyclopedia of Computer

Science, 2000.

[2] Sommerville, I.: „Software Engineering“, 7th edition, Addison Wesley, May 2004

[3] Pressman, R. S.: „Software Engineering: A practicioner's Approach“, 5th edition,

McGraw-Hill, New York, 2001.

[4] Chavert, J.: „Project Management Methodologies: Selecting, Implementing, and

Supporting Methodologies and Processes for Projects“, John Wiley & Sons, ISBN:

0471221783, Feb 2003.

[5] Royce, W. W.: „Managing Development of Large Scale Software: Concepts and

Techniques Proceeding“, Wescon, 1970.

[6] Firestone, J. M.: „Knowledge Management Process Methodology: An Overview,

Volume One, No. Two“, Knowledge Management Consortium International, Inc., Jan 2001

[7] „Project Lifecycle Models: How They Differ and When to Use Them“, Dostupno na:

http://www.business-esolutions.com/islm.htm, (pristupljeno 15.10.2012.)

[8] Beck, K. i dr.: „Manifesto for Agile Software Development“, Dostupno na: http://agilemanifesto.org/, (pristupljeno 15.10.2012) [9] Beck, K.: „Extreme Programming Explained: Embrace Change, Second ed“, Addison-

Wesley, 2005.

[10] Schwaber, K., Beedle, M.: „Agile Software Development with SCRUM“, Prentice-Hall,

2002.

[11] Coad, P., LeFebvre, E., DeLuca, J.: „Java Modeling in Color with UML“, Prentice Hall,

1999.

[12] Palmer, S. R., Felsing, J. M.: „A Practical Guide to Feature-Driven Development“,

Prentice Hall PTR, 2002.

[13] Cockburn, A.: „Agile Software Development“, Addison Wesley Longman, Oct 2001.

[14] Stapleton, J.: DSDM: The Method in Practice, Second ed“, Addison Wesley Longman,

2003.

[15] Highsmith, J.: „Adaptive Software Development: A Collaborative Approach to

Managing Complex Systems“, New York, NY: Dorset House, 2000.

[16] Larman, C.: „Agile and Iterative Development: A Manager's Guide“, Boston: Addison

Wesley, 2004.

40

[17] Larman, C., Basili, V.: „A History of Iterative and Incremental Development“, IEEE

Computer, vol. 36, no. 6, pp. 47-56, June 2003.

[18] Basili, V. R., Turner, A. J.: „Iterative Enhancement: A Practical Technique for Software

Development“, IEEE Transactions on Software Engineering, vol. 1, no. 4, pp. 390 - 396,

1975.

[19] Boehm, B.: „A Spiral Model for Software Development and Enhancement“, Computer,

vol. 21, no. 5, pp. 61-72, May 1988.

[20] Potok, T., Vouk, M.: „The Effects of the Business Model on the Object-Oriented

Software Development Productivity“, IBM Systems Journal, vol. 36, no. 1, pp. 140-161,

1997.

[21] State of Agile Development Survey, 5th annual, Oct 2010.: Dostupno na:

http://www.versionone.com/state_of_agile_development_survey/10/default.asp, (pristupljeno

25.09.2012.)

[22] „Extreme Programming: A gentle introduction“, Dostupno na:

http://www.extremeprogramming.org/, (pristupljeno 05.09.2012. g.)

[23] Jeffries, R., Anderson, A., Hendrickson, C.: „Extreme Programming Installed“, Addison

Wesley, 2001.

[24] Williams, L.: „The XP Programmer: The Few Minutes Programmer“, IEEE Software,

vol. 20, no. 3, pp. 16-20, May/June 2003.

[25] Williams, L., Kessler, R.: „Pair Programming Illuminated“, Addison Wesley, 2003.

[26] Highsmith, J.: „Agile Software Development Ecosystems“, Addison-Wesley, 2002.

[27] Cockburn, A.: „Writing Effective Use Cases: The Crystal Collection for Software

Professionals“, Addison-Wesley, 2000.

[28] Astles, D., Miller, G., Novak, M.: „A Practical Guide to Extreme Programming“,

Prentice Hall, 2002.

[29] Newkrik, J., Martin, R. C.: „Extreme Programming in Practice“, Addison–Wesley,

2001.

[30] DSDM Consortium, Dostupno na: http://www.dsdm.org, (pristupljeno 05.10.2012.)

[31] Agile Project Management: Adaptive Software Development, Dostupno na:

http://www.adaptivesd.com, (pristupljeno 05.10.2012.)

[32] Feature Driven Development, Dostupno na:

http://www.featuredrivendevelopment.com/, (pristupljeno 12.10.2012.)

[33] Poppendieck, M., Poppendieck, T.: „Lean Software Development“, Addison Wesley,

2003.

41

[34] Womack, J. P., Jones, D. T., Roos, D.: „The Machine That Changed the World: The

Story of Lean Production“, Simon & Schuster, 2007.

[35] Womack, J. P., Jones, D. T.: „Lean thinking: Banish waste and create wealth in your

corporation“, Simon & Schuster, 2003.

[36] Murman, E. i dr.: “Lean Enterprise Value: Insights from MIT’s Lean Aerospace

Initiative“, Palgrave, NewYork, 2002.

[37] Ikonen, M.: „Lean Thinking in Software Development: Impacts of Kanban on Projects“,

doktorska disertacija, Department of Computer Science, University of Helsinki, 2011.

[38] Hiranabe, K.: „Kanban applied to software development: From agile to lean.“, 2008.

Dostupno na: http://www.infoq.com/articles/hiranabe-lean-agile-kanban, (pristupljeno

12.10.2012.)

[39] Middleton, P., Joyce, D. P.: „Lean Software Management“, In Lean Software &

Systems Conference 2010, pages 15–23, Atlanta, Georgia, USA. Lean Software & Systems

Consortium, 2010.

[40] Anderson, D.: „Kanban: Successful Evolutionary Change for your Technology

Business“, Blue Hole Press., 2010.

[41] Kniberg, H.: „Kanban vs. Scrum: How to make the most of both“, Dostupno na:

http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf, 2009, (pristupljeno 15.10.2012.)