Skram (engl.

scrum) predstavlja agilni pristup za upravljanje razvojem softvera opte prihvaen u

svetu. On se javlja polovinom 90-tih godina prolog veka. est utisak da je to akronim je
pogrean. Skram je pojam preuzet iz ragbija i oznaava momenat kada se protivniki timovi
skupljaju na gomilu i bore za posed lopte. To nije vezano, osim simboliki, za softverski projekat.
Ova metoda je vie vezana za agilno upravljanje softverskim projektom, nego za agilno
projektovanje softvera. Ona propisuje naine upravljanja zahtevima, formiranja iteracija
(planiranje sprinta), kontrole implementacije i isporuke klijentu. esto se upotrebljava kao nain
voenja XP, ili drugih projekta koji ne moraju obavezno da se projektuju nekom agilnom
metodom.
Osnovu predstavljaju tri kljuna pitanja koja se postavljaju na svakodnevnim, jutarnjim stojeim
petnaestominutnim sastancima, a to su:
1. ta je uraeno jue?
2. ta e se raditi danas?
3. Kakve nas danas prepreke oekuju?
Ova pitanja se odnose na:
1. Kontrolu izvrenog
2. Planiranje budueg dizajna
3. Identifikaciju rizika i nalaenje reenja
Ciklus iteracije u skram procesu traje fiksno 30 dana. Za to vreme se svakodnevno prati
napredak i identifikuju sporna i rizina mesta napredovanja.

Skram je pun iskustvenih trikova i mehanizama koji odravaju koncentraciju na sutinu problema
i ne dozvoljavaju degradaciju organizacije, kao to je plaanje 100 din za kanjenje na dnevni
skram sastanak, ili stajanje na sastanku. Jezgro skram metodologije ine odreeni elementi i
prakse, a to su:

Sagledavanje delova proizvoda

Uloge i odgovornosti

Zalihe proizvoda i planiranje isporuka

Sprint zalihe i planiranje sprinta

Sprint

Dnevni stojei sastanci

Karte dogorevanja (engl. burndown charts) i izvetavanje o projektu

Pregled sprinta i retrospektiva

pedesetdevetominutni skram

Skram tim broji 5-10 lanova od kojih su obavezni jedan vlasnik proizvoda (engl. product owner)
koji je predstavnik klijenta, skram master koji je voa tima i ostali lanovi tima koji mogu biti
specijalisti za pojedine oblasti razvoja.

Kao projektni okvir koristi se za realizaciju razliitih razvojnih procesa. Najee se kombinuje sa
razvojem pomou ekstremnog programiranja, ili drugih agilnih metoda.

Scrum je radni okvir (eng. Framework) za razvoj proizvoda (najee softverskih) i to je

najpoznatiji predstavnik agilnog pristupa upravljanju ivotnim ciklusom proizvoda

Standardno ili Agilno voenje projekata?

Ako elite da projekt ima imalo ansi za uspjeh potrebno je imati dobro razraenu
metodologiju. Metodologije se ugrubo mogu podijeliti na dvije
skupine: standardne i agilne. Standardne metodologije se jo nazivaju
i waterfall (slap), jer se odvijaju po fazama, gdje jedna slijedi drugu i nema iteracija.
Mnogi kritiari smatraju da je ova metodologija, naroito kada se radi o projektima
razvoja softvera, vrlo loa, a poneki su skloni rei i nemogua. Objanjenje nalaze u
tome da se u toj metodologiji mora precizno isplanirati i najmanji detalj i funkcionalnost
prije nego to se krene u razvoj te da su kasnije promjene nemogue ili ako se rade, vrlo

skupe, a timovi koji rade na takvim projektima demotivirani. Agilne metodologije (kao
to je to npr. Scrum ili Kanban) s druge strane govore o tome da su promjene tijekom
razvoja poeljne i konstantne.

Scrum agilno voenje projekata

Prvo u objasniti agilno voenje projekata na primjeru Scruma. Uloge koje postoje su:
Product Owner, Scrum Master i Development Team. Product Owner zastupa kupca i
zna to kupac eli i to je uvijek samo jedna osoba. Scrum Master je osoba koja se esto
mijea s voditeljem projekta. Scrum Master nije voditelj projekta ve osoba koja slui da
timu pomae kod primjene Scruma te da mie sve prepreke koje netko moe postaviti
pred tim. On zapravo vodi tim sluei mu, a ne efujujui mu.Development Team je
skupina pojedinaca (5 do 9) koji rade na projektu tako da planiraju aktivnosti koje treba
obaviti da bi napravili odreene funkcionalnosti, procjenjuju ih, organiziraju ih u
tzv. sprinteve i izvravaju zadatke. Dogaaji (Eventi) koji se odvijaju u Scrumu su: Sprint
Planning, Sprint, Daily Sprint Meeting, Sprint Review i Sprint Retrospective
Meeting. Sprint Planning je sastanak (koji traje maksimalno jedan dan, a vrlo esto i
krae) na kojem se uzimaju zadaci iz tzv.
Product Backloga (mjesto na kojem su po prioritetima od najveeg do najmanjeg
poredane funkcionalnosti, a koji definira Product Owner) i procjenjuje to se treba
napraviti za te zadatke i koliko njih moe biti napravljeno u samom Sprintu. Sprint je
vremenski ogranien period (od 2 do 4 tjedna) u kojem se ti preuzeti zadaci iz Sprint
Backloga rade, hajmo rei kodiraju, testiraju, integriraju i dokumentiraju. Ti zadaci se
nalaze u Sprin Backlogu. Vano je napomenuti da se Sprint ne produljuje ni pod kojim
uvjetima. Ako nije sve planirano napravljeno, a primjerice nedostaje jo samo pola dana
da bi se sve zavrilo, sprint se, bez obzira na to, zavrava.
Cilj agilne metodologije je da na kraju svakog sprinta imamo potencijalno razvijene
funkcionalnosti koje mogu ii u produkciju (ne nuno uvijek). Daily Sprint Meeting je
dnevni sastanak, koji se odrava svaki radni dan u isto vrijeme, a koji traje maksimalno
15 minuta i u kojem lanovi tima i samo oni daju odgovore na tri pitanja: to smo radili
juer?, to emo raditi danas? i Imamo li kakvih problema?. Ako je potrebno neto
dodatno razjasniti, to se ne radi na tom sastanku nego na nekom posebnom, najbolje
odmah poslije Daily Sprint Meetinga. Kada je Sprint zavren radi se sastanak koji se
zove Sprint Review, u kojem se Product Owneru i svim zainteresiranim prezentira to
je napravljeno u Sprintu. Sprint Retrospecitve je sastanak na kojem tim i Scrum Master
odgovaraju na pitanja: to je bilo dobro u zadnjem Sprintu, to nije bilo dobro u

zadnjem sprintu? i to uiniti da bi radili bolje?. Nakon toga ciklus zapoinje ponovo
novim Sprint Planningom.
Kada govorimo o standardnom voenju projekata prvo voditelj projekta, ako je imalo
pametan i profesionalan zajedno s timom, prikuplja i analizira zahtjeve koje treba
izvriti. Nakon toga se ti zahtjevi dokumentiraju u tzv. Specifikaciju funkcionalnosti i,
nakon ovjere naruitelja, kree se s radom. Ovdje neu opisivati sve procese, procedure
i podruja znanja (kao to je to npr. Scope Management ili Risk Management) koji su
prisutni kod ove metodologije.

Ne mogu se svi projekti voditi agilno

Gdje su problemi? Ja sam apsolutno za to da se svi softverski projekti vode agilno! Ali,
postoje i neke prepreke. Prva i osnovna prepreka je da se svi projekti jednostavno ne
mogu tako voditi. Evo primjera. Dravna institucija ABC propie tender u kojem jasno
opie to eli i do kada to eli. Naravno uz fiksnu cijenu. Ovdje je agilnu metodologiju
nemogue promijeniti jer uz ta ogranienja promjene jednostavno nisu mogue.
Graevinski projekti su isto takav primjer. Zamislite da imate nacrt kue od 5 katova,
napravite prva 3 i onda Product Owner kae: Ajmo momci sad mi treba dva kata za
garau ispod zemlje!. Jednostavno nemogua misija. Idui problem je svijest. Naime,
da bi se radilo po agilnim metodologijama, kupac (naruitelj) mora poznavati jednu od tih
metodologija, aktivno sudjelovati u projektu i biti voljan istu i primijeniti. Kako sam opisao
u agilnim metodologijama ne postoji voditelj projekta.
Timovi su samoorganizirani i samoodgovorni. Drugim rijeima sva odgovornost je na
timu, a ne na jednom pojedincu. To bi bilo predivno kada ne bi znali iz prakse da svi ljudi
nisu samoodgovorni, a da takve jednostavno ne moete zamijeniti drugim, odgovornim,
jer ih jednostavno nemate. Kada je projekt po agilnim principima voenja zavren?
Onda, kada kupac kae: U redu, sve iz Product Backloga je napravljeno i radi. ili Ovo
to je do sada napravljeno u potpunosti zadovoljava moje potrebe pa mi ostalo ne
treba.. Hmmmm, da. No najee e vam kupac rei: Meni treba ovo. i pitati Vas: Do
kada to moete napraviti i po kojoj cijeni?. Istina je to pobornici agilnih metodologija (a
ja sam jedan od njih) tvrde da je kupac svjestan svojih potreba tek kada se sa projektom
zapone i kada vidi to e dobiti, odnosno ve nakon prvog Sprinta.
Tada e on zapravo imati prilike prvi puta vidjeti kako e proizvod (okvirno) izgledati i isti
modificirati, na nain da promijeni prioritete ve postojeih funkcionalnosti u backlogu ili
da neke iz njega izbaci, a doda nove. No takav kupac mora znati da ne moe dobiti
toan datum kraja projekta. A cijena? Pa cijena je po principu to ti odradim, to e i

platiti, dakle i konaan budet se ne moe precizno odrediti. Vjerovali ili ne, to je ispravan
nain rada i sve vie tvrtki naruitelja su to prepoznale!

Metodologija ovisi o projektu i naruitelju, ali

kada moete birajte agilno!
Tradicionalni (waterfall) nain je lo smo ako kupcu (naruitelju) date da vidi svoj
proizvod na kraju projekta. Ako mu dajete da vidi to je napravljeno tijekom projekta
(princip, malo po malo), tada i u tom sluaju kupac moe pravovremeno reagirati. Nije
istina to neki tvrde, da su promjene bolne i skupe. Jesu ako isporuite sve odjednom na
kraju. Nisu, ako kupcu redovno isporuujete tijekom projekta.
Kako kupac moe zatraiti promjenu? Jednostavno pa postoji procedura upravljanja
promjenom i dokument zahtjev za promjenom, u kojem kupac napie to eli
promijeniti ili dodati. Prema tom dokumentu se radi procjena vremena i novaca i nakon
dobivene suglasnosti na promjeni se i radi. Nita novo! Mogu li se standardna i agilna
metodologija kombinirati? Naravno da mogu. Primjerice, s kupcem se potpie jasan
specifikacija, a tim radi agilno! To je uobiajena svjetska praksa.
Kao zakljuak, kada me ljudi pitaju koja je metodologija bolja, moj odgovor je: Ovisi za
to i s kim radi.. Generalno, ako postoji i najmanja mogunost za agilno radite agilno
bez razmiljanja!

Principi na kojima se zasniva Agilni Manifest

Rukovodimo se sledeim principima:

1.

Zadovoljan klijent je na vrhunski prioritet,

koji ostvarujemo blagovremenom i
kontinuiranom
isporukom vrhunskog softvera.

2.

Spremno prihvatamo promene zahteva, ak i u kasnoj

fazi razvoja. Agilni procesi omoguavaju

uspeno prilagoavanje izmenjenim zahtevima

to za rezultat ima prednost naih klijenata
u odnosu na konkurenciju.

3.

Redovno isporuujemo primenljiv softver,

u periodu od nekoliko nedelja do nekoliko meseci,
dajui prednost kraim intervalima.

4.

Poslovni ljudi i developeri svakodnevno da sarauju

u toku celokupnog trajanja projekta.

5.

Projekte ostvarujemo uz pomo motivisanih

pojedinaca. Obezbeujemo im ambijent i podrku koja
im je potrebna
i preputamo im posao s poverenjem.

6.

Za najproduktivniji i najefikasniji metod

prenosa informacije do i unutar razvojnog tima
smatramo kontakt licem u lice.

7.

Primenljiv softver je osnovno merilo napretka.

8.

Agilni procesi promoviu odrivi razvoj.

Pokrovitelji, developeri i korisnici moraju biti u stanju
da kontinuirano rade usklaenim tempom,
nezavisno od perioda trajanja projekta.

9. Stalna posveenost vrhunskom tehnikom kvalitetu

i dobar dizajn pospeuju agilnost.
10. Jednostavnost vetina dovoenja do najvieg stepena
koliine rada koji nije potrebno uraditi je od sutinske
vanosti.

11. Najbolje arhitekture, zahtevi i dizajn,

rezultat su rada samoorganizovanih timova.
12. Timovi u redovnim intervalima razmatraju
naine kako da postanu efikasniji,
zatim se usklauju
i na osnovu tih zakljuaka
prilagoavaju dalje postupke.

Scrum agilni proces razvoja softvera

December 18, 2013 | Filed under: Agile and tagged
with: Agile, ALM, lanak, Mrea, Scrum
Priprema, pozor, Scrum!

Scrum je metodologija razvoja softvera temeljena na agilnim principima, te ga

karakterizira iterativni i inkrementalni pristup razvoju softvera. On je izuzetno

pragmatina disciplina koja vrijednost za krajnjeg korisnika stavlja ispred

ugovornog pregovaranja, prilagodbu ispred planiranja, te pojedinca ispred
procesa i alata. Dok se tradicionalne metodologije bezuspjeno bore protiv
promjena tijekom trajanja projekta i pokuavaju unaprijed anticipirati sve
zahtjeve korisnika, Scrum prihvaa realnost i prilagouje se promjenama koje
su u softverskom razvojnom procesu
neizbjene.

Prilagodba, nadzor, transparentnost. To su tri

glavna principa kojima moemo opisati Scrum.
Scrum kao empirijski proces za upravljanje i
razvoj softvera bazira se na konstantnom nadzoru i uestaloj prilagodbi, a
glavni preduvjet toga je otvorenost razvojnog tima unutar sebe, ali i
transparentnost prema korisniku ili naruitelju. Scrum je jedna od nekoliko
agilnih metoda razvoja, kao to su i XP (Extreme Programming), DSDM
(Dynamic System Development Method) ili Crystal. Temelj svih agilnih
principa razvoja softvera sadran je u agilnom manifestu kojeg su 2001.
sastavili najvei autoriteti softverske industrije kao to Robert C. Martin,
Martin Fowler i Ken Schwaber koji je ujedno i jedan od autora Scruma. Agilni
manifest ne razrauje metodologiju nego samo definira principe razvoja
softvera. Ti principi ujedno su i temelj Scruma.
Od kuda ime Scrum? Da li je rije o jo jednom u nizu nezanimljivih akronima?
Ne, Scrum zaista nije akronim. Poznavatelji ragbija sigurno znaju znaenje
rijei Scrum u toj igri, a on oznaava trenutak nakon prekida kada se
protivniki timovi sakupljaju na hrpu i bore za posjed lopte. Svakim prekidom
tim se pomie prema cilju i zauzima nove pozicije. Ekipa koja je nadmona
svakim prekidom (scrumom) sve je blia protivnikoj liniji i ostvarenju cilja. Na
putu prema cilju, tim ne pokuava predvidjeti sve situacije u igri, nego se
stalno prilagoava trenutnoj situaciji na terenu, a glavni im je cilj progurati
loptu to blie protivnikoj liniji i na kraju naravno postii zgoditak. Scrum
proces razvoja softvera upravo je to, iterativni proces u kojem cijeli tim gradi
igru pomiui se sve blie glavnom cilju, postizanju zgoditka, zavretku
jednog uspjenog projekta. Upravo Scrum kao metafora timskog

inkrementalnog kretanja ka cilju inspirirala je osnivae ove metodologije (Ken

Schwaber i Jeff Sutherland) da poetkom prolog desetljea definiraju sasvim
novu metodologiju razvoja softvera.

Ureeni kaos

Scrum esto zovemo metodologijom, ali ako elimo biti posve precizni, Scrum
to nije. Scrum je okvir (framework) metodologije razvojnog procesa i za razliku
od nekih drugih agilnih metodologija kao to su XP ili Crystal, Scrum ne
definira detalje procesa ve daje okvir unutar kojega tim stvara proces
prilagoen sebi, odnosno proces ija je karakteristika konstanto usavravanje
i prilagodaba timu koji ga provodi.
Kao i sve druge agilne metodologije, Scrum je
inkrementalni i iterativni pristup razvoju
softvera. Inkrementalni razvoj predstavlja
razvoj softvera korak po korak, dok iterativni
nain predstavlja strategiju vremenskog planiranja u kojem se softver kroz
svaki definirani period vremena dodatno usavruje. Osnovna vremenska
cjelina Scruma jest sprint. Sprint je zaokruena jedinica razvojnog procesa
koja najee traje 30 kalendarskih dana. Unutar svakog sprinta, Scrum
prolazi kroz sve faze razvojnog procesa. Planiranje, programiranje, testiranje i
isporuka ponavljaju se kroz svaki slijedei sprint. Na kraju svakog sprinta
razvojni tim isporuuje zaokrueni dio proizvoda, odnosno potencijalno
isporuiv inkrement proizvoda. Razbijanjem razvojnog procesa na sprintove,
Scrum smanjuje rizik od isporuke loeg softvera, softvera koji nee zadovoljiti
trite, a ujedno se time i lake prilagouje novim i promijenjenim zahtjevima
korisnika koji su neizbjeni. No, Scrum se ne zaustavlja na tome, pa i svaki
pojedini sprint dodatno razbija na jo manje dijelove koji traju tono 24 sata, a
poinju i zavravaju dnevnim scrumom. Dnevni scrum jedna je on malobrojnih
obaveza cijelog razvojnog tima, a nuan je da bi se postigla unutarnja
transparentnost u timu. To je stand-upsastanak na kojem svi lanovi razvojnog
tima u neformalnom okupljanju od 15-ak minuta odgovaraju na tono 3
pitanja:

1. to je uraeno juer?
2. to e se raditi danas?
3. Kakve nam prepreke stoje na putu?
Za provoenje dnevnog scruma kao i cijelog razvojnog procesa odgovoran je
Srcum master. Scrum master donekle odgovara ulozi voditelja projekta, iako
Scrum strogo gledajui ne poznaje ulogu voditelja projekta. Scrum nain
razvoja softvera u svojoj je biti samoorganizirajui proces te kao takav ne
zahtjeva ulogu voditelja, barem ne u onom smislu kako se tradicionalno takva
uloga opisuje. Scrum master ima ulogu prvenstveno kontrolirati proces, ali ne
i ljude u timu. Umjesto da rasporeuje posao i govori svim lanovima tima to
da rade, Scrum master nadzire proces i brine se o tome da se on potuje.

Samoupravljanje na dijelu

Jedna od osnovnih krilatica Scruma kae Ako hoe da preuzmem

odgovornost, daj mi i ovlasti. Vlast i odgovornost morali bi uvijek ii ruku pod
ruku. to se dogaa kada vlast nema odgovornost, nije potrebno posebno
opisivati, ali isto tako ako od nekoga traimo odgovornost za odreeni posao,
zadatak ili projekt, moramo mu dati sve potrebne ovlasti. To je upravo ono to
kae Scrum, te razvojnom timu daje potpunu slobodu samoorganizacije. Tim
se obvezuje samo na ono na to sam procjeni da se moe obvezati, a na putu
prema cilju, tim sam odluuje to e i kako raditi kako bi ostvario cilj, odnosno
isporuio ono na to se je obvezao. Dati razvojnom timu toliku slobodu,
menaderima naviklima na klasini nain rukovoenja, esto djeluje kao
rizina odluka i ovo je zbog toga u praksi jedna od najuestalijih prepreka
uvoenja i provoenja Scruma. Meutim, isto tako praksa pokazuje da se to
isplati jer takav tim donosi rezultate i opravdava dano povjerenje.
to to zapravo znai? Kako izgleda jedan sprint u Scrum razvojnom procesu?
Sprint zapoinje sastankom planiranja (Sprint planning meeting). Tijekom
sastanka definira se sprint backlog, popis svojstava koje treba ugraditi u
nadolazei sprint. Sprint backlog nastaje na osnovi product backloga, popisa

svih svojstava koje treba ugraditi u proizvod sortiran prema prioritetu kako ih
vidi sam korisnik. Na vrhu product backolga nalaze se najvanija svojstva, a
na dnu ona sa najmanjim prioritetom. Tijekom sastanka, tim procjenjuje koliko
svojstava iz product backlogamoe staviti u sprint backlog. Na osnovi sprint
backloga sastavljaju se ciljevi sprinta, a sastanak zavrava pristankom cijelog
tima da preuzme odgovornost i obvee se ispuniti te ciljeve u iduih 30 dana.
Tijekom trajanja sprinta izbjegava se svaka mogunost vanjskog utjecaja na
ciljeve sprinta, a svi eventualni zahtjevi za promjenama dodaju se u product
backlog i predmet su rasprave za slijedei sprint. Scrum zahtjevima korisnika
kae Da, ali ne u ovom sprintu!. Tijekom sprinta lanovi razvojnog tima
imaju samo dvije obaveze, ispuniti ciljeve sprinta i redovito dolaziti na dnevne
scrum sastanke. Na kraju uspjeno zavrenog sprinta pakira se isporuevina,
odnosno inkrement sprinta te se prezentira nositelju proizvoda (product
owner), korisnicima i drugim zainteresiranim stranama. Nakon to se napravi
retrospektiva sprinta i unesu podaci u product backlog, sprint je slubeno
zavrio, a time i slijedei poeo. Sprint traje uvijek jednako vrijeme te nije
odreen niti resursima niti planiranim zadacima nego jedino dogovorenim
vremenskim razdobljem. Vrijeme je jedina nepromjenjiva konstanta u
planiranju sprinta.

Odnos sa korisnicima

Ostvarivanje otvorenog i iskrenog odnosa sa korisnikom ili naruiteljem

softverskog rjeenja jedan je od najvanijih aspekata Scruma. Naalost, ovo je
i jedan od najeih kamena spoticanja provoenja Scruma u praksi.
Tradicionalni ugovorni odnos sa naruiteljem u kojemu orijentacija na
naruitelja odnosno korisnika traje samo za vrijeme do potpisivanja ugovora i
na kraju neposredno prije isporuke, u softverskoj industriji jednostavno ne

funkcionira. elimo li uspjean projekt, trebamo se svim silama truditi imati

korisnika tijekom cijelog razvoja to blie sebi. Naruitelj odnosno korisnik
treba biti svjestan svoje vanosti u procesu razvoja. On je taj koji odluuje to
stoji gore, a to dolje u listi svojstava (product backlog). On je taj koji na kraju
svakog sprinta preuzima potencijalno isporuiv proizvod te na njega daje
svoje primjedbe i elje za daljnjim promjenama. On je taj koji zahtjeve treba
izrei i iza njih stajati. Bez korisnika u Scrum procesu, zapravo nema ni
Scruma. Uestalom suradnjom sa korisnicima, postii emo da krajnji proizvod
bude upravo ono to korisnici oekuju. Uskladiti oekivanja korisnika i
razvojnog tima je proces i ne moe se postii jedim ugovorom ili jednim kickofsastankom. Razvoj softvera vie nalikuje istraivakom poslu nego
proizvodnoj traci i zbog toga nuna je stalna retrospektiva i od strane tima i
od strane korisnika da bi zavrni proizvod bio ono to elimo.

Scrum u bitovima

Scrum je proces, odnosno preciznije okvir

procesa razvoja softvera i za njegovo provoenje nije preduvjet niti jedan
programski jezik niti razvojna okolina. Za osnovne artefakte Scruma kao to
su product backlog, sprint backlog, ciljevi i rezultati sprinta mogu se koristiti
rukom ispisani papirii ili u boljem sluaju Excel tablice, te se i bez pomoi bilo
kojeg alata za upravljanje razvojnim procesom moe provoditi Scrum.
Meutim, koritenje dobrih alata za upravljanje razvojnim procesom koji u sebi
sadre sve to je potrebno za provoenje Scruma sigurno e uvelike pomoi u
ivotu Scrum projekta. Alati za upravljanje razvojnim procesom ili kako ih u
zadnje vrijeme zovemo ALM (Application Lifecycle Management) alati svakako
su dobrodoli u svaki ozbiljniji razvojni tim. No, koliko su ti alati prilagoeni
Scrum procesu? Na prvi pogled loa vijest je da niti jedan od takvih alata nije
posebno pripremljen za Scrum. Meutim, dobra vijest je da se neki od ALM

alata lako mogu prilagoditi Scrumu. Microsoft ALM sustav baziran na Microsoft
Team Foundation Serveru (TFS) lako se prilagoava raznim razvojnim
procesima. Proces je u Microsoft TFS-u definiran metodolokim predlokom, te
dolazi sa ve nekoliko predefiniranih predloaka za neke od razvojnih procesa.
Najblii Scrumu je MSF Agile predloak koji se u nekim segmentima poklapa
sa Scrumom. Dodatno postoje vanjski predloci koji se mogu dodati u sustav,
a meu takvima je i nekoliko onih koji su upravo Scrum metodoloki predloci.
Najpoznatiji je Scrum for team systempredloak firme EMC Consulting, a od
nedavno je i Microsoft izdao vlastiti Microsoftov Visual Studio Scrum,
predloak za TFS izraen od strane Microsoft razvojnog tima. Oba predloka
omoguit e vam provoenje Scruma kroz Microsoft ALM i oba dva predloka
su potpuno besplatna. EMC predloak sadri sve navedene artefakte i principe
Scruma, ali je relativno kompleksan za koritenje. Microsoftov je jednostavniji,
ali i siromaniji. Ako ste novi u Scrumu svakako e vam u prilagodbi na proces
pomoi alat koji e vas voditi, a s vremenom kada sazrijete poeljet ete u
njega ugraditi neto svoje, pravila ili ideje prilagoene vaem razvojnom timu.
Metodoloki predloci u TFS-u to vam omoguuju, tovie predvieni su za
nadogradnje i mijenjanje. U ostalom, jedan od principa Scruma i jest trajno
usavravanje procesa, te kao to vas Scrum potie da budete kreativni i
spremni na promjene i njima se prilagodite, tako je i sam Scrum proces
predvien da se mijenja i prilagouje vama i vaem timu. Osnove Scruma su
jednostavne te je najbolji nain da ga usvojite taj da ga ponete primjenjivati,
a zatim ga usavravate iterativno i inkrementalno. Scrum trenutno koriste
gotovo sve najvee svjetske softverske kompanije, meu njima i divovi
industrije kao to su Microsoft, IBM i SAP. Ako va razvojni tim jo ne ivi
Scrum, moda se moete barem u tome ugledati na njih i krenuti u va prvi
sprint.

Agilni manifest

Pojedinci i interakcija vaniji su od procesa i alata

Softver koji radi vaniji je od detaljne dokumentacije

Kolaboracija s korisnikom vanija je od ugovornog pregovaranja

Odgovor na promjenu vaniji je od praenja plana

Scrum Pojmovnik
Sprint osnovna vremenska radna cjelina Scruma u kojoj nastaje novi
inkrement proizvoda. Najee trajanje sprinta je 30 kalendarskih dana.
Product backlog popis svojstava koji se oekuju od konanog proizvoda.
Svojstva u popisu rasporeena su po prioritetu od najvanijih prema manje
vanim.
Product backlog element jedinini element iz Product backloga. Svaki
element predstavlja jedno svojstvo proizvoda opisano na nain da njegova
implementacija vremenski stane u okvir jednog sprinta. Tijekom izvoenja
sprinta backlogelementi se dalje razbijaju na zadatke i dodjeljuju lanovima
razvojnog tima.
Sprint backlog popis svojstava preuzet iz product backlogakoji su predmet
implementacije jednog sprinta.
Sprint burndown dijagram grafiki prikaz procjene preostalog posla kroz
vrijeme jednog sprinta. Prikazuje gdje se nalazi razvojni tim u odnosu na
zadatke planirane za tekui sprint.
Product owner nositelj proizvoda. Osoba koja donosi konane odluke
korisnika ili naruitelja softverskog rjeenja. Nositelj proizvoda direktno
sudjeluje u definiranju prioriteta elemenata u product backlogu.
Sprint master osoba odgovorna za provoenje scruma u timu. Uloga
najslinija voditelju projekta u klasinim metodologijama. Scrum master
koordinira komunikaciju izmeu nositelja proizvoda i razvojnog tima.
Dnevni Scrum dnevni sastanak razvojnog tima u trajanju od 15 minuta na
kojem lanovi razvojnog tima izmjenjuju kratke informacija o tome to rade i
to planiraju raditi u iduem danu. Takoer ako imaju kakve prepreke u radu,
iznose ih na sastanku. Scrum master zaduen je da se pobrine oko toga da se
te prepreke uklone.

Sprint sastanak planiranja Sastanak koji se provodi prije poetka

slijedeeg sprinta. Glavna tema sastanka je pregovaranje izmeu razvojnog
tima i nositelja proizvoda o tome koja svojstva odnosno koji elementi product
backloga trebaju ui u slijedei sprint, odnosno sprint backlog.
Retrospektiva sprinta Sastanak koji se provodi na kraju svakog sprinta.
Na tom sastanku scrum master zajedno sa lanovi tima raspravlja o upravo
zavrenom sprintu. Razvojni tim analizira to je bilo dobro, a to treba
popraviti u procesu razvoja za slijedei sprint. Nositelj proizvoda ne sudjeluje
na tom sastanku.

ALM upravljanje radnim stavkama

Od poetnog planiranja pa sve do odravanja nakon isporuke,

softverski projekt prepun je zadataka koje treba obaviti, odnosno,
kako se to u ALM terminologiji naziva, radnih stavki (work items).
Radna stavka iri je pojam od pojma zadatak i predstavlja bilo koji
jedinini ili skupni dio posla
koji se obavlja na projektu.
U softverskom razvojnom procesu
razlikujemo upravljanje zadacima,
korisnikim i tehnikim zahtjevima
aplikacija, upravljanje bugovima,
testovima i testnim sluajevima
koje treba testirati. Sve to spada u pojam upravljanje radnim stavkama.
Ovisno o metodologiji razvojnog procesa, razlikuju se i definicije radnih stavki
na projektu.
Zahtjevi korisnika prvi su artefakt s kojim se susree jedan razvojni projekt.
Tradicionalni razvoj softvera predvia da se svi zahtjevi korisnika prikupe na
poetku projekta. Nove agilne metodologije prikupljaju zahtjeve korisnika
tijekom cijelog procesa razvoja. Bez obzira u kojem se vremenu prikupljaju
zahtjevi, upravljanje zahtjevima (requirements management) izuzetno je

vano za uspjeh cijelog projekta. Kvalitetna definicija i obrada zahtjeva

preduvjet su kvalitete i same krajnje aplikacije ili sustava. Svaka greka
nastala u razvoju, radi krivo definiranih zahtjeva stvara viestruko vei troak,
nego da je dobrom razradom otklonjena na samom poetku.
Definiranje i upravljanje novim zahtjevima na postojeim aplikacijama ili
sustavima u produkciji esto nazivamo upravljanje promjenama (change
request management). Ako su ti zahtjevi za promjenama uvjetovani
otkrivenim problemima na sustavu, onda se ta disciplina naziva i upravljanje
grekama (issue managmanet) ili upravljanje bugovima (bugtracking
management). Sve ove poddiscipline dio su sustava za upravljanje radnim
stavkama (work items management system). Na tritu postoje i odvojeni
alati za neke od ovih disciplina. Najei su alati za praenje bugova. Meutim
bugovi samo su jedna vrsta radne stavke koju je potrebno pratiti na projektu.
Rad u brojkama
to definira jednu radnu stavku? Kao prvo to je vrsta radne stavke. Ve je
spomenuto da radna stavka moe biti bilo koji dio posla na projektu: zahtjev,
zadatak, testni sluaj, bug i drugo. Svaki tip radne stavke ima tono
definirane atribute kao to su naziv, opis, lan tima kojem je trenutno
pridruen, vremenska i logika kategorizacija radne stavke te ponekad
procjenu vremena i novaca potrebnih za njihovu implementaciju. Vrste
atributa se mogu mijenjati ovisno o pravilima na projektu i metodologiji rada.
Osim definicijom polja, radna stavka odreena je i workflowom, odnosno
definicijom moguih stanja i tranzicija izmeu njih. Na primjer, bugpoinje
stanjem otvoren, nakon ega je pridruen odgovarajuem lanu tima i
spreman za rjeavanje. Kada se rijei, prelazi u stanje rijeen, a nakon to se
testira i potvrdi rjeenje, prelazi u stanje zatvoren. Ovisno o metodologiji
rada, stanja moe biti i puno vie. U stroim okruenjima, onima koja
zahtijevaju bolju kontrolu, zahtjev za promjenama prolazit e kroz razna stanja
odobravanja prije nego to doe na implementaciju. Nakon implementacije
takva radna stavka nastavlja svoj hod kroz razne validacije prije nego to se
pusti u produkciju i zatvori. Konzistentnim koritenjem radnih stavki
omoguuje se transparentnost na projektu, a to je jedan od glavnim ciljeva
ALM-a.

Povei sve sa svime

Radne stavke glavni su nain kolaboraciju u
razvojnom timu oslonjenom na ALM. Sve to se
tie razvoja poinje i zavrava radnom stavkom.
Svaka promjena oznaava se radnom stavkom ili
nekim njenim atributom. Ako se radi promjena u
kodu, onda se ta promjena vee uz odreenu
radnu stavku. Skup promijenjenih datoteka koji se
sprema u sredinji sustav za verzioniranje koda
naziva se changeset. Osim to sadri sve
promjene na izvornom kodu,changeset sadri i poveznicu na jednu ili vie
radnih stavki. Time je zabiljeeno da spremljene promjene ine rjeenja ili su
pak na bilo koji nain povezane sa definiranim zadatkom, zahtjevom ili
bugom. Svako testiranje aplikacije proizlazi iz definicije testnog sluaja, to je
takoer radna stavka, a naie li se na greku, stvara se radna stavka bug, koji
se pridruuje testu kroz koji je utvren. Automatizirani dnevni build proces,
koji se pokree jednom dnevno na projektu, prikuplja informacije o svim
radnim stavkama rijeenim prethodnog dana, te na kraju svog procesa kreira
izvjetaj u kojemu su popisani bugovi, zadaci i druge radne stavke odraene u
tom periodu. Radne stavke nalaze se posvuda u ALM sustavu i konzistentno
koritenje radnih stavki preduvjet je transparentnosti razvojnog projekta. Ne
samo da time svi lanovi tima tono znaju to su im zadaci, nego dobivaju i
iru sliku stanja projekta i za sve to rade znaju kako to utjee na cjelokupni
projekt.

Radne stavke kako ih definira MSF Agile 5.0 metodologija

iz Microsoft ALM-a:
User Story Opis funkcionalnosti kako ju definira korisnik. Svaki user
story opisuje eljenu funkcionalnost ili svojstvo iz perspektive korisnika. Pojam
je preuzet iz Scrum procesa razvoja. Donekle odgovara opisu use caseaili
scenarija u drugim metodologijama.

Task Zadatak. Osnovna jedinica rada. Nakon definicije user storya, potrebno
je definirati zadatke po kojima e se on implementirati, te takve zadatke
dodijeliti lanovima tima. U svakom trenutku jedan zadatak moe pripadati
samo jednom lanu tima.
Bug Greka koju treba ispraviti. Bugovi definiraju greku i opisuju korake
kako ju ponoviti. Moe se povezati na odreeni user story uz koji je logiki
vezan, a takoer i uz test case, koji opisuje korake testiranja kojim je utvrena
greka. Svaki bug pridruen je jednom lanu tima, ima svoj prioritet, stanje i
druge atribute. Stanja buga su: otvoren, rijeen i zatvoren. Bug otvara onaj
tko ga je pronaao, tester ili sam programer. Programer ga rjeava i stavlja u
stanje rijeen, a zatim inicijator buga potvruje da je rjeenje dobro i stavlja
ga u stanje zatvoren ili ga pak reaktivira i stavlja natrag u stanje otvoren.
Issue Opis problema koji treba rijeiti da bi se mogao nastaviti rad na
funkcionalnosti user storya. Issue se pridruuje odreenom lanu tima. Meu
atributima moe se definirati i datum due date do kada problem mora biti
razrijeen. Svaki lan tima ima uvid u svoju issue listu, u kojoj je popis
problema za koje je on odgovoran da ih rijei.
Test Case Opis testnog sluaja. Testeri ili druge osobe zaduene za
testiranje prvo definiraju testne sluajeve, a potom ih prolaze prema koracima
koji su dio definicije testnih sluajevima. Test case je osnovna jedinica rada
testera tijekom testiranja. Test Case radne stavke pridruuju se
odreenom user storyui time definiraju to je sve potrebno testirati uz
odreenu funkcionalnost.
Shared Steps Radna stavka koja se koristi kod manualnog testiranja za
opis koraka testa koji se ponavljaju kod vee koliine testnih sluajeva.
Definirani Shared Steps moe se pridruiti raznim test casovima i predstavlja
segment testiranja koje je zajedniko svim pridruenim testnim sluajevima.

Upravljanje ivotom aplikacije

Od definiranja zahtjeva pa do isporuke, dugi je put razvoja softvera,

a na kraju tog puta najee smo opet na novom poetku. Nakon
isporuke slijede novi zahtjevi te opet putujemo kroz iste stadije
planiranja, implementacije i testiranja da bi doli do nove isporuke. I
onda opet ispoetka. To su ciklusi ivota jedne aplikacije, jednog
softverskog uratka. Kako aplikacija ne bi ivjela bez kontrole,
potrebno je njome upravljati. To cjeloivotno upravljanje razvojem
aplikacija naziva se ALM
(Application Lifecycle Management).
Cjeloivotno upravljanje aplikacijom
(ALM) obuhvaa aktivnosti i alate koji
pokrivaju cjelokupni ivotni tijek razvoja
softvera od prvih ideja do zavrne
isporuke, pa i dalje kroz faze odravanja
sve do odlaska softvera u zasluenu mirovinu. ALM objedinjuje sve stadije
ivota aplikacije te proima sve discipline prisutne u softverskom razvoju, od
upravljanja zahtjevima (requirements management), preko arhitekture,
implementacije, testiranja do projektog menadmenta te upravljanja
verzijama i meuverzijama (release i build management). Ciljevi ALM-a su:
kroz sve faze razvoja poveati produktivnost i istovremeno unaprijediti
transparentnost i kvalitetan uvid u stanje razvojnog procesa. Vizija ALM-a je
brak izmeu biznisa i razvojnih timova. U organizacijama koje primjenjuju
ALM, biznis i razvoj vrsto su povezani, razvojni timovi nisu izolirani otoci
svojih organizacija. Biznis zna i vrednuje to ljudi u razvoju rade, a razvojni
timovi svjesni su svoje uloge u poslovanju tvrtke. Situacija u veini tvrtki vrlo
je rijetko takva. Na alost, vrlo esto, upravo suprotna. Biznis ne doivljava
razvojni tim. Nema uvid u stanje razvojnih projekata. Zapravo, nema uope
mogunosti saznati osnovne informacije o projektu, dobiti odgovor na
najjednostavnija pitanja. Kakvo je stanje projekta? Kada e softver biti
spreman za isporuku? Kakva je kvaliteta aplikacije koja se razvija? Kada bi
takva pitanja postavili lanovima razvojnog tima, oni ne bi znali odgovor, ili bi
pak svaki odgovor bio drugaiji. Ako nemamo sustav koji e nam omoguiti
transparentnost u razvojnom procesu, sustav koji e sam davati odgovore na
ovakva pitanja, vjerojatno nikada neemo ni znati u kakvom je stanju na
projekt, ili emo odgovore dobiti tek kada za to bude prekasno. Statistika

govori da veina razvojnih projekata propada i nikada se ne dovri do kraja, a

oni koji dou do svog cilja, esto probijuzacrtane budete i planirano vrijeme.
Morali to biti tako? Postoje i svijetli primjeri u razvoju softvera, postoje projekti
koji su vrijedni divljenja, ali oni nisu sluajno postali takvi. Davno je prolo
vrijeme kada je za razvoj uspjenog softvera bila dovoljna jedna garaa i par
entuzijasta. Zahtjevi na softver dananjice kao i zakoni trita iziskuju
drugaiji pristup. elimo li kvalitetan softver, ALM nije jedna od mogunosti,
ALM je nuan i to ALM u svim fazama razvojnog procesa. Na tritu se nalazi
puno alata koji pokrivaju neke faze razvoja, ali samo ih je nekoliko za koje
moemo rei da su ALM sustav, sustav koji objedinjuje alate za sve faze
razvojnog procesa. Meu najpoznatije i najvie zastupljene na tritu spadaju
sustavi velikih IT divova kao to su: Microsoft Visual Studio ALM, IBM Rational
Team Concert te skup HP ALM
alata.
U poetku bijae kd
Verzioniranje razvojnog kda
odnosno upotreba nekog od
sustava za upravljanje i
spremanje izvornog koda
(version control system) jedna
je od najee koritenih
disciplina ALM-a. Taj segment ALM-a ope je prihvaen i veina razvojnih
timova koristi neki od alata za verzioniranje. Iako se alati meusobno
razlikuju, principi rada su im prilino slini. Kompletan razvojni kod sprema se
u sredinju bazu podataka i svaki korisnik, odnosno programer, prije nego
mijenja bilo koju datoteku, preuzima je iz baze (check-out), radi na njoj te je
po zavretku posla vraa u bazu (check-in, commit). Svaka promjena se biljei
u povijest promjena i ostaje zauvijek zabiljeena. Uz to, veina alata nudi i
razne druge opcije za dodatno naprednije upravljanje kodom. Do pojave
naprednijih ALM alata, za potrebu verzioniranja najee su se koristili
jednostavni alati kao to je sada ve zastarjeli Microsoft SourceSafe, Java
bazirani SubVersion ili CVS. Nedostatak tih alata je to nisu integrirani u
cjelokupni ALM sustav, nego su izolirani alati koji slue iskljuivo verzioniranju
koda. ALM sustavi nove generacije verzioniranje povezuju i sa sustavom za

upravljanje radnim stavkama, testiranjem, automatizacijom buildova i svim

drugim podsustavima ALM-a. Izvorni kod osnova je svakog softverskog
projekta i nuna je njegova veza sa cjelokupnim razvojnim procesom. Tako se
stvara kolaboracija izmeu programera i ostatka tima. Programer i dalje
programira i govori jezikom koji samo raunalo razumije, a testeri, dizajneri,
voditelji timova znaju tono to on radi jer svaka njegova promjena u kodu
vezana je uz tono definiranu radnu stavku (work item) i nita ne smije biti
dodano u kod, a da nije rezultat neke definirane radne stavke, na primjer
zadatka ili opisa buga.
Sve se pie, sve se pamti

Jedna od glavnih ideja ALM-a je

transparentnost. Sve to se radi na
projektu treba imati svoj trag. Svako
rjeenje je rezultat definiranog
zadatka, a svaki zadatak proizaao je iz dokumentiranog zahtjeva. Takoer,
svaka greka otkrivena u testiranju mora biti zabiljeena, a kada se rijei,
rjeenje se mora povezati sa definicijom buga. Idealno i svaki bug otkriven je
tijekom izvravanja tono unaprijed definiranih testnih sluajeva. Svaki testni
sluaj testira tono odreeni scenarij koji je opet rezultat nekog od poetnih
zahtjeva. Zahtjevi, zadaci, bugovi, testni sluajevi, sve su to vrste radnih
stavki (work items). Ovisno o metodologiji rada koju koristimo, radnih stavki
moe biti vie ili manje. ALM alati moraju omoguiti prilagodbu definicija
radnih stavki metodologiji i procesu koji se koristi na projektu.
Uz upravljanje zahtjevima i upravljanje radnim stavkama, usko je vezano i
upravljanje promjenama (Change Request Management). Ovisno o stupnju
formalnosti nae organizacije, upravljanje promjenama bit e jednostavniji ili
sloeniji postupak. to je organizacija vea i sustav koji se mijenja bitniji, to
je proces upravljana promjenama sloeniji. Zamislite postupak promjene
softverskog koda ili ispravljanje greke u sustavu za upravljanje vojnim
satelitom ili moda blii nam primjer: promjena u softverskom sustavu
bankarskog poslovanja. Svaka promjena u takvom sustavu strogo je definirani
proces. Da bi linija koda ula u takav softver, nije dovoljno da postoji jedan

zahtjev, radna stavka koja ga opisuje, ve takav zahtjev mora proi kroz
strogo definirani tijek dogaaja (workflow). Od poetne definicije pa da
verifikacije zahtjeva, od raznih nivoa unutar firme pa do faze implementacije,
te testiranja na raznim sustavima i podsustavima. ALM alati, kroz upravljanje
radnim stavkama, moraju omoguiti takav
razvojni proces.
Graditeljstvo softvera
Release i build managament, u slobodnom
prijevodu upravljanje verzijama i
meuverzijama, neizostavni su dijelovi ALMa. Prije pojave ALM sustava, postojali su alati
namijenjeni bilo jednoj, bilo drugoj disciplini.
Meutim njihovim povezivanjem, ALM sustavi
dali su tim disciplinama dodatnu vrijednost. Svaka izdana verzija softvera, bilo
da je rije o verziji za trite ili samo jednog korisnika, bilo da je izdani service
pack ili mala zakrpa, mora biti posebno oznaena i spremljena na dohvatljivo
mjesto. Izvorni kod takve verzije mora biti lako dohvatljiv iz sustava za
upravljanje kodom. Radni kod i kod izdanih verzija mora se moi odvojiti. To
odvajanje verzija nazivamo grananje (branching). Grananjem se dobiva
mogunost istovremenog rada na promjenama izdane verzije i radne verzije
aplikacije.
Daily Build ili dnevna izgradnja

meuverzija

odavno je poznata praksa. I prije

postojanja

modernih ALM sustava, postojali

su razni alati

za upravljanje buildovima.
Dnevni build zapravo bi bolje

bilo zvati

noni build jer se najee

izvrava u

gluho doba noi. U vrijeme kad

su uredi

prazni i kad razvojni tim ne radi na projektu, razvojni proces i dalje je aktivan.
No je idealno vrijeme u kojem nai serveri mogu obavljati razne zahtjevne
poslove i tako koristiti vrijeme mira i tiine na razvojnim radnim stanicama.
Preporuka ALM-a je da se svaku no izvri build u kojem e seintegrirati sve
promjene prethodnog dana, te e se nakon toga nova meuverzija pripremiti

kao setup i/ili automatski isporuiti u sustav za testiranje. Izvrit e se sve

automatske analize i testovi nad aplikacijom, a ujutro razvojni tim u
svommailboxu dobit e izvjetaj o rezultatima builda. ALM omoguuje upravo
to, pa i vie od toga. Dobra je praksa da sebuildovi izvravaju i ee od
jednom dnevno. Stoga nam veina alata omoguuje definiranje builda koji se
pokree svakim checkinom. Time se uspostavlja continuous integration,
kontinuirana integracija koda u build proces. Svakom promjenom izvrava se
build i nakon par minuta ili na veim projektima moda malo dulje vrijeme,
dobivamo izvjetaj o tome kako
je proao build.
Aplikacija u laboratoriju
Rijetki su timovi koji u svojim
redovima imaju testere, osobe
zaduene iskljuivo za
testiranje. S druge strane
programeri ne vole testirati. Ili
su preuvjereni u kvalitetu svog uratka pa im je testiranje ispod asti ili su
pak prezagueni poslom pa za taj nebitni dio nemaju vremena. Tko onda
testira softver? Korisnik? Da, to je naalost esti odgovor. Pronalazi li korisnik
bugove? Ovo je retoriko pitanje, svi smo mi korisnici pa jako dobro znamo
kakav je softver koji koristimo, bilo privatno, bilo poslovno. Koliko kota
ispravak otkrivene greke? Statistika kae da je ispravak greke kod korisnika
i do nekoliko puta skuplje od ispravka greke koju smo otkrili na samom
poetku razvoja. Kako uoiti propuste u implementaciji na vrijeme? Prvi korak
je da se promijeni raspoloenje prema testiranju. No, kada odluimo poeti
testirati, pitanje je to testirati? Ako bi nakon svake promjene uvijek iznova
testirati cijelu aplikaciju, brzo bi odustali od toga. Potrebna nam je naravno
pomo alata za automatsko testiranje. Potreban nam je alat uz iju pomo
moemo definirati testove, izvriti testove, prikupiti rezultate testova te ih
pratiti i analizirati kroz vrijeme. Alati koji dolaze sa modernim ALM sustavima
nude upravo to. Po mnogim svojstvima najkvalitetniji meu njima su HP
Quality Center iz HP sustva za ALM, Microsoft Test Manager integriran sa Team
Foundation Serverom te IBM Rational Quality Manager iz IBM porodice ALM
alata.

Svi za jednog, ALM za sve

Alati za upravljanje zahtjevima,
zadacima, verzijama, alati za
testiranje, alati za izvravanje
buildova, sve to u raznim fazama
pomae razvojnom timu. No kada
se poveu ti alati u jedan cjeloviti
sustav onda je njihova vrijednost
vea nego zbroj vrijednosti svakog
pojedinano. Kvaliteta svakog pojedinanog alata je bitna, ali ne i presudna.
Dananji vrhunski alati za razvoj sami po sebi nisu dovoljni da bi razvojni
projekti bili uspjeni. ALM rjeenja podrazumijevaju alate koji razmjenjuju
podatke, implementiraju workflowekoji prelaze granice pojedinih rola i na taj
nain uspostavljaju komunikaciju meu njima. Kvalitetna integracija alata
katkada igra veu ulogu od njihovih osobina i specifinosti. Tek kroz
integraciju alati omoguavaju koordinaciju svih ALM aktivnosti i time
osiguravaju da rezultat naeg projekta rjeava poslovni problem zbog kojeg je
projekt i zapoet.
Ako alati nisu meusobno povezani i ne brinu se za razmjenu informacija, ljudi
su prisiljeni kontinuirano manualno sinkronizirati tj. kopirati podatke iz jedne
aplikacije u drugu, npr. prijave greaka iz aplikacije za podrku korisnicima se
moraju kopirati u aplikaciju ili dokument za evidenciju bugova koju koristi
razvojni tim. Ako se informacija o statusu pojedinih zadataka ne distribuira
automatski, projektni menader mora sazivati sastanke ili traiti izvjetaje od
lanova tima. Sva ta eksplicitna komunikacija zahtjeva vrijeme i trud i tako
smanjuje produktivnost. Integriranim ALM sustavima i njihovom pravilnom
primjenom svi podaci o projektu prikupljaju se sami i daju transparentnu sliku
stanja projekta, a razvojni tim ne optereuju jo jednih administrativnim
poslom, ve naprotiv olakava im poslovnu svakodnevicu i poveava njihovu
produktivnost.

ALM Alati za verzioniranje izvornog kda

October 23, 2012 | Filed under: ALM, Uncategorized and tagged
with: ALM, SCCM, Verzioniranje

Jednom izreeno, zauvijek zapisano

Verzioniranje kda najee je koritena disciplina ALM-a. Mnogi
razvojni timovi kojima je pojam ALM potpuno nepoznat, koriste neki
od alata za verzioniranje koda. Verzioniranje,odnosno spremanje
koda u sredinji repozitorij u kojemu se biljei svaka promjena kroz
povijest, jedna je od rijetkih opeprihvaenih dobrih praksi u razvoju
softvera svih vrsta i namjena.
Kd je sredinji dio svake aplikacije. Izgubite li popis vaih zahtjeva ili
rezultate testiranja, jo uvijek imat ete projekt koji razvijate. Moda neete
najbolje moi upravljati daljnjim razvojem svoje aplikacije, ali barem neete
izgubiti ono to je do tada napravljeno. Gubitkom izvornog koda, izgubili ste
temelje vaeg projekta. Nema koda, nema aplikacije! Stoga je opravdano rei
da je verzioniranje koda temeljna disciplina ALM-a i najee prvi korak u
stvaranju dobro organiziranog razvojnog projekta. Nije dovoljan, ali je sigurno
nuan uvjet za usvajanje
ALM-a u razvojnom timu.
Preuzmi zadnju verziju (get),
oznai datoteke koje
namjerava promijeniti
(check-out), nakon izvrenih
promjena vrati ih u sustav
(check-in) i to je to. Tri su to
osnovne akcije svakog
sustava za verzioniranje. Kod
nekih alata meutim akcije check-out i check-in objedinjene su u jednu. U
alatu SubVersion takva se akcija naziva commit. Terminologija se razlikuje od
alata do alata, ali su principi poprilino slini. Tko je stekao praksu sa jednim
alatom, vrlo lako e se naviknuti i na drugi.
to se ispod haube takvih alata dogaa? Moderni sustavi za verzioniranje
temelje se na bazi podataka to cijeli sustav ini robusnijim, sigurnijim i
skalabilinijim. Primjer takvog sustava je Microsoft Team Foundation Server, iji
se podsustav za verzioniranje temelji na SQL Serveru. S druge strane,
zastarjeli Microsoftov alat SourceSafe temeljen je na klasinom sustavu

datoteka, te kao takav ne poznaje pojmove transakcionalnosti, atomarnosti i

openito svih dobrih principa baza podataka. SourceSafe alat je kojeg je
davno pregazilo vrijeme, meutim radi svoje jednostavnosti, mnogi ga i dalje
koriste. Na tritu postoji jo cijeli niz malih i jednostavnih alata za
verzioniranje koji su dobri za male one-man-band timove, meutim vei
timovi svakako bi takve alate trebali zamijeniti pravim ALM sustavima.
Funkcija takvih sustava nije samo spremanje koda nego i njegovo povezivanje
sa drugim podsustavima ALM-a. Takvi alati mogu svaku metodu izvornog koda
povezati sa zadatkom radi kojeg je nastala, svaku liniju sa testom koji ju
testira, svaki projekt sa buildom koji se po elji automatski izvrava
na buildmaini. Za svaki dio koda, od takvih sustava moe se dobiti
informacija kada je nastao, te tko ga je i s kojim razlogom stvorio ili
promijenio, i na kraju, koliko je trajala, odnosno kotala, njegova
implementacija. Nisu li to pitanja na koja bi svaki ozbiljniji razvojni tim trebao
znati odgovore?
Neka grane govore
Grananje (branching)
te povezivanje grana
(merging) sljedee su
bitne funkcije sustava
za verzioniranje koja ne spadaju u kategoriju osnovnih. Grananje je postupak
razdvajanja jednog stabla koda u dva odvojena stabla sa istim korijenom.
Postupak slian kopiranju datoteka, ali pri emu dvije kopije ostaju povezane
preko svoje iste izvorne toke. Zamislimo sljedei scenarij. Razvijate aplikaciju
ija prva verzija odlazi korisniku, a istovremenu nastavljate razvoj na novoj
verziji koja e u jednom trenutku u budunosti biti isporuena. Tijekom razvoja
te verzije, zatraena je hitna promjena ili ispravka u aplikaciji koja je u
produkciji, odnosno kod korisnika. Scenarij nije ni malo neobian, dapae vrlo
je est u softverskoj industriji. Kako e razvojni tim ispraviti greku na
isporuenoj verziji? Vjerojatno izvorni kod isporuene verzije negdje postoji i
mogue ga je nai te na njemu ugraditi eljenu prepravku. Prepravku koju
smo napravili na isporuenoj verziji, potrebno je napraviti i na verziji u
razvoju. Koritenjem branchinga opisani postupak znaajno se
pojednostavnjuje. Svaka isporuena verzija jedna je grana koda, te se

promjene na odreenoj verziji svode na promjene pripadajuih grana. Ako je

potrebno promjenu nakon toga prenijeti iz jedne grane u drugo, to se radi
postupkom spajanja (merging). Merging verzija omoguava da gotovo jednim
klikom mia prenesete sve eljene promjene iz jedne grane u drugu, a da se
pri tom sustav brine o konzistentnosti koda i rjeava sve eventualne konflikte
koji prilikom tog spajanja mogu nastati. Paralelni rad na razliitim verzijama
aplikacije nije jedini razlog koritenja branchinga. Na veim projektima vrlo je
est pojam feature branch. To je odvojena grana koda na kojoj se paralelno i
neovisno od ostatka projekta razvija jedno, najee relativno veliko, svojstvo
aplikacije. Takvo svojstvo odvaja se u posebnu granu kako radi svoje
kompleksnosti ne bi naruilo integritet ostatka koda. Ponekad se za razvoj
takvog svojstva formira i posebna radna skupina koja odvojeno od ostatka
tima radi na tom svojstvu. Takve odvojene grupe nazivamo feture crew.
Grananje se naravno ne mora zaustaviti samo na jednoj razni i po potrebi
moe se hijerarhijski nadovezivati. Koliko grana e imati pojedini projekt ovisi
o stvarnim potrebama. Svaka grana donosi dodatnu kompleksnost u radu i
treba ih kreirati samo onda kada je to opravdano. Prevelikom koliina grana,
vrijeme potrebno za odravanje promjena meu njima moe biti vei gubitak
od eventualnog benefita koji smo
grananjem dobili.
Za one koji ele znati vie
Razliiti sustavi za verzioniranje nude
razliite napredne mogunosti
upravljanja i izvjetavanja o kodu.
elite li doi do informacije tko je i kada
napravio jednu liniju koda u nekoj
datoteci, moete to na vie naina.
Podaci o svim promjena na kodu
spremljeni su i vidljivi iz povijesti
promjena svake datoteke i ako krenete
traiti uvijek ete nai krivca za traeni
kod. Neki alati meutim nude jednostavniji nain za pronalaenje
krivca. Annotate naredba na TFS ili ClearCase sustavu ili kako je u CVS-u i

SubVersionu zovu blame, prikazat e nam kod sa popisom odgovornih za

svaku liniju u kodu. Ako je taj kod k tome jo i povezan sa listom zadataka kao
to je to u TFS-u onda ete za svaku liniju koda lako pronai i razlog njenog
postojanja.
Sustavi za verzioniranje koda najee ne nude mogunost brisanja promjena
iz povijesti, barem ne kroz standardno korisniko suelje. Undo u smislu
nikad se nije niti dogodilo nije predviena akcija. elimo li zanemariti
zadnju checkiniranupromjenu, mogue je napraviti kompenzacijsku promjenu
ili runo ili uz pomo alata i vratiti stanje koda na prijanje. Meutim u
povijesnom pregledu zauvijek e ostati vidljiva takva akcija.
Veina razvojnih alata dananjice omoguava spajanje na sustav za
verzioniranje po izboru. Visual Studio preferira spajanje sa Microsoft TFS-om,
ali doputa i ostale alate. IBM Rational alati najbolje se povezuju sa IBM-ovim
ALM alatima, ali se mogu spajati i na druge sustave za verzioniranje. Veliki
razvojni timovi, esto koriste vie od jednog razvojnog alata, a ponekad i vie
od jedne razvojne platforme. Nije rijetkost da se na primjer serverski slojevi
poslovnih aplikacija razvijaju u Javi na Unix sustavima, a klijenti u .NET-u na
Micorosoft okolini. Zahvaljujui otvorenosti pojedinih sustava za verzioniranje,
mogue je takve timove integrirati u zajedniki ALM sustav. U integraciji
heterogenih okruenja, iznenaujua je otvorenost Microsoft ALM-a. Moda iz
nekih drugih alata nismo navikli da Microsoft otvoreno gleda prema Unixu,
Linuxu ili pak Macu. Zahvaljujui alatu Team Explorer Everywhere, koji je dio
Microsoftovog ALM sustava namijenjen heterogenim okruenjima, klijenti iz
najrazliitijih okolina mogu se jednostavno povezati na TFS sustav. Neovisno
rade li u javi, programiraju li u Eclipsu, te bez obzira na to o kojem je
operativnom sustavu rije, dostupan im je isti ALM sredinji sustav. Kada je u
pitanju verzioniranje, nuna je mogunost povezivanja razliitih okruenja u
isti sredinji sustav. U protivnom, dio koda uvijek e ostati zakinut za
verzioniranje, a jedna od pretpostavki ALM-a je da se verzionira kompletan
kod sa svim svojim dijelovima.
Objanjenje osnovnih pojmova sustava za verzioniranje
Get /update proces dohvaanja aktualne ili neke od prethodnih verzija
izvornog koda iz sustava za verzioniranje

Checkin /commit spremanje lokalnih promjena u sustav za verzioniranje

Checkout oznaavanje datoteka iz sustava za verzioniranje koje se
namjeravaju mijenjati. Promjene su mogue samo na datotekama na kojima je
napravljen checkout. Kod nekih sustava ne postoji akcija checkout nego se
sve datoteke mogu mijenjati odmah nakon dohvata.
Branching proces razdvajanja jedne grane u sustavu za varzioniranje u
dvije jednake kopije, pri emu jedna grana predstavlja branch od druge
grane. Grane se mogu meusobno usporeivati te se promjene iz jedne grane
mogu prebaciti u drugu.
Merging proces prenoenja promjena nainjenih na jednoj grani (branch) u
drugu.
Label oznaka stanja izvornog koda u odreenom vremenskom trenutku.
Revision jedinstvena oznaka (ID) stanja datoteke u sustavu za
verzioniranje. Svakom promjenom datoteke, mijenja se i njegov revision
Changeset pojam poznat kod novijih (naprednijih) sustava za verzioniranje.
Skup svih lokalnih promjena koje su predmet jednog checkina. Changeset
tijekom checkinau obliku transakcije odlazi na server kao atomarna cjelina.
Jednostavniji i zastarjeli alati nemaju taj koncept to je ozbiljno ogranienje
npr. SourceSafea ili CVS-a
Lock- naziva se i ekskluzivni checkout. Datoteke nad kojima je jedan korisnik
nainio lock ne mogu mijenjati drugi korisnici, odnosno nije
mogu checkoutod drugih korisnika.
Shelve spremanje lokalnih promjena na server na privremenu lokaciju izvan
glavnog projektnog repozitorija. Omoguuje korisnicima spremanje verzije
koja nema utjecaja na trenutno stanje datoteka u sustavu za verzioniranje.
Akcija je omoguena samo kod nekih sustava (Team Foundation Server,
Bazaar)
Rollback mogunost brisanja jedne promjene iz povijesti promjena. Veina
sustava ne podrava takvu akciju. Oni koji podravaju najee rade na nain

da sustav generira promjenu koja ponitava ranije napravljeno, zapravo

nastaje novi changeset koji ponitava utjecaj onog changesetakoji se eli
stornirati.
Blame/Annotate prikaz datoteka tako da se za svaku liniju koda vidi tko ju
je promijenio ili stvorio. Omoguuje brzo otkrivanje kada i zato je nastala
svaka pojedinana linija u izvornom kodu. TFS to naziva Annotate, a CVS ili
SVN Blame.

SubVersion
SubVersion jedan je od najpoznatijih i najrairenijih alata za verzioniranje
koda. Nije ALM alat, meutim razni ALM alati omoguavaju integraciju s njime.
Najvie koriten u open-source zajednici. Koriste ga razni poznati projekti, a
meu ostalima i Google Code za distribuciju koda. Postoje razni klijentski alati
na raznim platformama koji se povezuju sa SubVersionom. Za Windows
platformu poznat je klijent Tortoise SVN.
Proizvoa: open-source, izvorno proizveden
od kompanije CollabNet
Tip: alat za verzioniranje koda
Url: http://subversion.apache.org/
Platforma: Unix, Linux, Solaris, Windows, Mac
+: Besplatan, jednostavan, dostupan kroz razne platforme, omoguena veina
naprednih funkcija, integrira se u razne druge sustave
-: Ne nudi potpunu integraciju u ALM sustave

CVS

CVS izraen je jo davne 1986. Veteran je meu sustavima za verzioniranje.

Vrlo popularan u open-source svijetu. Zastupljen praktiki svugdje i dostupan
kroz sve platforme, meutim u nekim segmentima zastarjeli sustav koji ne
podrava razne naprednije mogunosti sustava za verzioniranja. Veliki
nedostatak je to nije mogue isto obrisati ili preimenovati datoteke i mape.
Takve operacije potrebno je napraviti direktno na serveru, a nije ih mogue
napraviti transakcionalno kroz
proces commita.
Proizvoa: open-source, proizveo CVS tim
programera
Tip: alat za verzioniranje koda
Url: http://savannah.nongnu.org/projects/cvs
Platforma: Unix, Linux, Solaris, Windows, Mac
+: Besplatan, jednostavan, dostupan kroz razne platforme,
-: Zastarjeli alat, nedostatak naprednih funkcija, netransakcijsko upravljanje
brisanjem i preimenovanjem datoteka

Bazaar
Bazaar je jo jedan jednostavan i besplatan alat. Kroz jednostavno korisniko
suelje omoguuje razne prilagodljive procese (workflowe) tijekom
verzioniranja. Nije toliko rairen kao SubVersion ili CVS. Postoje razni add-in
ovi koji nadopunjuju Bazaar.
Proizvoa: open-source, sponzoriran od
Canonical
Tip: alat za verzioniranje koda
Url: http://bazaar.canonical.com

Platforma: Unix, Linux, Solaris, Windows, Mac

+: Besplatan, jednostavan, ugodno korisniko suelje,
mnotvo communitydodataka, prilagodljiv
-: Nije dio ALM sustava, nema sve naprednije funkcije

SourceSafe
SourceSafe stari je Microsoftov alat. Osim to je jednostavan i nezahtjevan za
instalaciju, nema drugih razloga zbog ega bi ga koristili u odnosu na noviji
Microsoftov alat TFS, pogotovo nakon to je Microsoft izdao TFS Basics koji i
po cijeni odgovara SourceSafeu. Veina timova SourceSafe koristi iz inercije,
ekajui priliku da ga zamijene boljim
alatom, najee TFS-om.
Proizvoa: Microsoft
Tip: alat za verzioniranje koda
Url: http://msdn.microsoft.com/enus/vstudio/aa718670.aspx
Platforma: Windows
+: jednostavan, softverski i hardverski nezahtjevan
- : nepouzdan, netransakcijski check-in, zastarjeli alat bez mnotva funkcija

Rational ClearCase
Rational ClearCase alat je iz IBM Rational obitelji. Nije ALM alat, ali je
omogueno povezivanje IBM-ovog ALM sustava TeamConcert na nain da se
uspostavi sinkronizacija ili pak da se jednokratno importiraju podaci u novi
sustav. ClearCase je u odnosu na SubVersion i veinu drugih alata relativno

sloeniji sustav i nije prikladan za veinu manjih timova. Velika mana mu je i

cijena. Veina slinih alata su ili besplatni ili
barem jeftiniji.
Proizvoa: IBM
Tip: alat za verzioniranje koda, Software
Configuration Management alat
Url: http://www-01.ibm.com/software/awdtools/clearcase/
Platforma: Linux, Solaris,Windows
+: napredne funkcije, mogunost povezivanja na ALM sustav
-: Cijena, sloenost

Team Foundation Server

Team Foundation Server sadri kao jedan od podsustava alate za verzioniranje
integrirane u cjelokupni ALM sustav. Robustan sustav, baziran na SQL
Serveru. Omoguuje sve napredne funkcije. Klijent se integrira u Visual
Studio, a dostupan je i Eclipse Add-in preko kojeg je pristup TFS-u mogu iz
raznih ne Windows platformi.
Proizvoa: Microsoft
Tip: ALM sustav
Url: http://msdn.microsoft.com/enus/vstudio/ff637362
Platforma: Windows Server 2003/2008 za posluitelja, a za klijente Windows,
Mac, Unix, Linux, Solaris
+: dio ALM sustava, robustan, pouzdan, dostupan u raznim platformama

-: Veliki i sloen sustav, ako vam treba samo sustav za verzioniranje. TFS je
predvien za puno vie od toga.

Razvoj aplikacija Application Lifecycle Management

Davno su prola vremena kad je za razvoj softvera bila dovoljna jedna garaa i
nekoliko programera entuzijasta. Iako su takvim pristupom, moemo rei, stvoreni
temelji dananje softverske industrije, sasvim je jasno da zahtjevi na softver
dananjice kao i zakoni trita iziskuju drugaiji
pristup.
Industrija softvera se nalazi na prekretnici. Ve
godinama imamo alate koji programerima daju
dobru podrku brze kompajlere,
pametne editore i integrirana razvojna okruenja
(IDE). Uzwizarde i intellisense, pisanje koda nije
nikad bilo lake. Pa ipak, projekti na kojima svi mi
radimo, esto kasne s isporukom, probijaju budet ili na kraju bude isporueno manje
nego to je na poetku planirano. Oigledno, dobra podrka za fazu implementacije
softvera nije dovoljna da bi razvojni projekt uspio. Najei razlozi za neuspjeh su
manjak uvida u status projekta, loa komunikacija, nepredvidljivost termina isporuke
i kvalitete konanog proizvoda i (ne)usklaenost poslovnih zahtjeva sa kapacitetima
razvojnog tima.
U osnovi ovih problema je kvaliteta suradnje svih ukljuenih u razvojni proces, pa se
kao rjeenje namee proirenje alata i procesa za podrku razvoju i developerima na
cjelokupni razvojni tim i sve ostale faze razvoja. Potrebna je podrka za sve ostale
uloge u razvojnom procesu poslovne analitiare, arhitekte, testere, projektne
menadere i sve ostale zainteresirane strane. Cilj podrke je omoguiti da svi ovi
sudionici razvojnog procesa efikasno surauju, usklauju zadatke i razmjenjuju
informacije o statusu i prioritetima, a sve s ciljem da rjeavanjem poslovnih problema
ostvare novu vrijednost krajnjim korisnicima. Da bi imala anse za uspjeh i da bi
mogla ostvariti preokret u statistikama uspjenosti naih razvojnih projekata, ta
podrka mora pratiti cjelokupni ivotni tijek razvoja softvera, pa otud dolazi i ime
teme ovog lanka, cjeloivotno upravljanje aplikacijama, application lifecycle
management (ALM).

to sve ukljuuje cijeloivotno upravljanje

aplikacijama?

Automatizacija i integracija alata

ALM obuhvaa aktivnosti i alate koji pokrivaju sve

faze razvojnog ciklusa od upravljanja zahtjevima (requirements management),
modeliranja i arhitekture, implementacije, testiranja, projektnog menadmenta i
upravljanje verzijama i meuverzijama (release ibuild management). ALM
omoguuje praenje veza meu artefaktima, automatizaciju i transparentnost tj.
kvalitetan uvid u stanje razvojnog procesa.
U teoriji bi se ALM aktivnosti mogle obavljati i runo, bez podrke alata (primjerice,
zapisujemo zadatke na ploi, a lanovi tima upisuju svoja imena i status uz svaki
zadatak), ali u stvarnim svakodnevnim projektima bez da koristimo alate vrlo brzo
bismo bili izgubljeni u ogromnoj koliini informacija koje treba pratiti. Pritom je
kvaliteta alata bitna, ali ne i presudna. Ve smo utvrdili da dananji vrhunski alati za
razvoj sami po sebi nisu dovoljni da bi razvojni projekti bili uspjeni. ALM rjeenja
podrazumijevaju alate koji razmjenjuju podatke, implementiraju workflowe koji
prelaze granice pojedinih uloga i na taj nain uspostavljaju komunikaciju i
omoguavaju suradnju. Puno je vanija kvalitetna integracija alata, nego osobine
svakog pojedinog od njih. Tek kroz integraciju alati omoguavaju koordinaciju svih
ALM aktivnosti i time osiguravaju da rezultat naeg projekta rjeava poslovni
problem zbog kojeg je projekt i zapoet.
Veze meu alatima koje koriste lanovi razliitih uloga u timu se prenose i na veze
meu artefaktima koje ti lanovi tima tokom svoga rada kreiraju i meusobno
razmjenjuju. Upravo je praenje veza meu artefaktima poput zahtjeva, modela i
arhitekture, izvornog koda, testova ili radnih stavki (work item) osnova cjelokupne
integrirane strategije koja nam omoguava da u svakom trenutku znamo to ljudi
rade i dokle su stigli (to vidimo iz popisa aktivnih i rijeenih radnih stavki), kako se to
to rade odnosi na osnovni poslovni problem (veze izmeu zahtjeva i zadataka) ili ak
zato je nastala svaka pojedina linija izvornog koda (odgovor na to pitanje daju veze
izmeu izvornog koda i radnih stavki). Bez alata ili sa slabo integriranim alatima
nema transparentnosti razvojnog procesa, a kolaboracija i razmjena informacija u
timu su nedostatni. Transparentnost, predvidljivost trendova (uspjeha ili neuspjeha) i

mogunost pokretanja korektivnih akcija u realnom vremenu su kljuni preduvjeti za

uspjeh razvojnih projekata.
Svatko ima ulogu, malu ili veliku
Timska kolaboracija

Ako alati nisu meusobno povezani i ne brinu se za razmjenu informacija, ljudi su

prisiljeni kontinuirano manualno sinkronizirati tj. kopirati podatke iz jedne aplikacije
u drugu. Na primjer, prijave greaka iz aplikacije za podrku korisnicima se moraju
kopirati u aplikaciju ili dokument za evidenciju bugova koju koristi razvojni tim. Ako
se informacija o statusu pojedinih zadataka ne distribuira automatski, projektni
menader mora sazivati sastanke ili traiti izvjetaje od lanova tima. Sva ta
eksplicitna komunikacija zahtjeva vrijeme i trud i tako smanjuje produktivnost.
Kako jo integracija alata moe automatizirati timsku komunikaciju? Veza izmeu
promjena na izvornom kodu (changeset) i radnih stavki daje informaciju testerima
to moraju testirati. Svako jutro kada tester dobije najnoviju meuverziju (build), u
izvjetaju koji dolazi uz nju stoje popisane promjene u kodu i radne stavke rijeene u
toj meuverziji. Na taj nain programeri izvjetavaju testere koji dijelovi aplikacije su
gotovi i spremni za testiranje.
Kod checkiniranja, odnosno snimanja promjena u kodu u sustav za verzioniranje, te
promjene povezujemo s radnim stavkama zbog kojih su napravljene i oznaavamo za
svaku pojedinu radnu stavku da li je do kraja implementirana. Na taj je nain, im
programer implementira neki zadatak i checkinira kod, projektnom menaderu
automatski dostupna informacija da je zadatak gotov bez da mu programer mora slati
mail ili ga na neki drugi nain o tome obavjetavati. Omoguena je automatizirana
razmjena informacija bez dodatnog tereta koji je standardno vezan uz komuniciranje
i time istovremeno poveana i uinkovitost i transparentnost. Informacija o statusu
svake radne stavke trenutno je dostupna svim lanovima tima.
Veze od zahtjeva, preko use-caseova do taskova i dalje do bugova i testova
omoguuju razliite analize na osnovu kojih projektni menader moe agilno
upravljati projektom i brzo donositi ispravne odluke. Stavite se u ulogu projektnog
menadera koji u zavrnoj fazi rada na projektu, suoen s rokovima koji se
neumoljivo pribliavaju, ima dvije opcije smanjiti opseg projekta ili pomaknuti
rokove. Iako je micanje rokova u pravilu puno bolnije, projektni menaderi se esto
odluuju za tu opciju, jer nemaju dobar nain da izdvoje neki odreeni dio aplikacije
koji bi prebacili u sljedeu verziju. Uz veze meu artefaktima, moe se precizno rei

koliko je nestabilan pojedini dio aplikacije, tj. koliko je bugova vezano uz zahtjeve
koje taj dio ostvaruje. Od svih dijelova koji nisu kljuni za funkcioniranje aplikacije,
na projektni menader jednostavno moe izbaciti najmanje stabilne, one na kojima
ima jo najvie posla, odnosno bugova.
Vrste ALM rjeenja

Postoje dvije vrste ALM rjeenja rjeenja nastala povezivanjem prvotno

samostalnih alata namijenjenih pojedinim ulogama u timu i rjeenja nastala oko
centralnog kolaboracijskog servera, odnosno jedinstvenog repozitorija za sve podatke
vezane uz razvojni proces.
Niz je razlika izmeu ova dva tipa rjeenja. U prvom tipu, koji je i povijesno prvi
nastao, alati specijalizirani za pojedine role su razvijeni odvojeno i tek naknadno su
meusobno povezani. Takva rjeenja imaju niz nedostataka. Zbog preklapanja meu
pojedinim alatima, esto nije jasno u kojem od njih bi trebalo napraviti odreenu
zadau, a zbog sitnih razlika u nainu implementacije nije svejedno za koji alat emo
se odluiti. Svaki alat ima svoj repozitorij i nunost njihovog meusobnog
povezivanja uvodi znaajnu sloenost. Sve dolazi na granicu pucanja kad, to je
uobiajeno, u jedno rjeenje budu integrirani alati koje su razvili razliiti proizvoai,
naknadno povezani poslovnim akvizicijama. Pa tako, iako primjerice imamo i alat za
upravljanje zahtjevima i alat za testiranje, dogaa se da veze meu njima nisu
mogue i na projektni menader iz prethodnog primjera ne bi mogao agilno
upravljati opsegom projekta i ostvariti oekivanu korist od upotrebe ALM-a.
Druga vrsta rjeenja se sastoji od kolaboracijskog posluitelja i niza dodataka za
razliite klijentske aplikacije koji integriraju te aplikacije s centralnim posluiteljem.
Svaki od alata pohranjuje u centralni repozitorij (data warehouse) sve artefakte i
metrike razvojnog procesa vezane uz svoje podruje. Budui da svi alati pristupaju
zajednikom repozitoriju, u njemu su dostupni najrazliitiji podaci koji stoga mogu
biti meusobno povezivani i analizirani bez ogranienja. Upravo takvu vrstu
integracije omoguuje Team System, odnosno Team Foundation Server kao njegov
centralni posluitelj.

Pogled na cjelokupnu platformu Team Systema 2010 Team Foundation

Server sredinji je posluitelj sustava koji kroz svoje podsustave komunicira s
razliitim vrstama klijenata
ALM i Team System

Microsoft Visual Studio Team System je integrirano rjeenje za ALM, a sastoji se od

sredinjeg posluitelja, Team Foundation Servera (TFS) i niza klijentskih alata,
odnosno niza ugradnji za postojee alate. Upravo tim ugradnjama u postojee alate,
omogueno je da svi lanovi tima i dalje rade u okruenju na koje su navikli. Tako
e .NET razvojni inenjeri i dalje raditi u Visual Studiju, projektni menaderi u
Projectu ili Excelu, a svi e zajedno kroz standardni kolaboracijski alat Outlook biti
informirani o stanju projekta. Na raspolaganju im jo stoje Sharepoint projektni
portal i Team System Web Access za pristup projektnim podacima preko web suelja.
No Team System ne bismo smjeli svesti samo na skup alata. Naime, rije je o novoj
platformi koja se lako povezuje s drugim sustavima, pa i drugim ne-Microsoftovim
platformama. Upravo zahvaljujui svojoj ekstenzibilnoj arhitekturi, Team System
mogu efikasno koristiti i razvojni inenjeri koji rade u Javi preko Eclipsa ili pak
koriste Oracle preko Toada, ili moda razvijaju koristei neki drugi razvojni alat koji
se moe povezati sa sredinjim dijelom Team Systema, Team Foundation Serverom.
Na taj nain imamo integraciju ne samo alata, nego i timova koji ne moraju raditi u
istim alatima niti koristiti istu platformu. to konkretno znai ta integracija i kakve
koristi od nje imaju svi lanovi tima bit e jasnije kroz pregled dijelova Team
Systema, odnosno podsustava Team Foundation Servera.
Praenje radnih stavki

Upravljanje radnim stavkama (Work Item Management) je jedan od kljunih

podsustava Team Systema. Radnom stavkom moemo nazvati bilo koji dio posla na
jednom projektu ili jo openitije bilo to o emu elimo voditi evidenciju odnosno
pratiti ga. To mogu biti zadaci, bugovi, zahtjevi ili rizici kojima elimo upravljati.
Svaki tip radne stavke definiran je poljima i njihovim atributima, stanjima i

tranzicijama te izgledom korisnikog suelja odnosno forme preko koje e se unositi.

Radne stavke ne samo da predstavljaju cjelokupnu evidenciju obavljenog i preostalog
posla na projektu, nego definiraju i workflow naeg razvojnog procesa ovisno o
metodologiji koju koristimo. Bez dodatnih promjena, Team System nakon instalacije
dolazi sa predlocima za dvije metodologije MSF agilni (MSF for Agile Software
Development 4.2) i MSF formalniji (MSF for CMMI Process Improvement). Ovisno o
odabranoj metodologiji, u projektu emo imati razliite tipove radnih stavki i
razliiti workflow odnosno procedure u radu s pojedinim stavkama.
Jedan od osnovnih principa Team Systema je prilagodljivost okruenju u kojem se
koristi. Team System se prilagoava specifinostima naeg razvojnog procesa, a ne mi
njemu, pa je u tu svrhu omogueno vrlo jednostavno definiranje vlastitih tipova
radnih stavki ili mijenjanje postojeih. Na taj nain moemo promijeniti ili definirati
sasvim novi razvojni proces, odnosno metodoloki predloak koji odgovara naoj
organizaciji. Na webu je mogue nai gotove metodoloke predloke za poznate
razvojne metodologije, kao to je primjerice SCRUM, a svaki od tih metodolokih
predloaka mogue je dalje prilagoavati razvojnom procesu dodajui nove ili
mijenjajui postojee tipove radnih stavki i njihove workflowe.
Kontrola i verzioniranje koda

Version Control, odnosno verzioniranje i spremanje koda je podsustav Team Systema

s kojim se razvojni timovi najee prvo susreu i prvog ga poinju koristiti.
Najvjerojatnije je razlog tome to to su veina korisnika Team Systema nekadanji
korisnici Source Safea pa ovaj dio Team Systema najlake usporeuju s poznatim
alatom. Meutim usporeivati Team System i Source Safe zapravo je pogreno, pa
ak i ako se ograniimo samo na sustav za verzioniranje, razlike i prednosti Team
Systema su toliko velike da je svaka usporedba neprimjerena.
Sustav za verzioniranje u Team Systemu i Source Safe imaju vrlo slino korisniko
suelje, ali tu sve daljnje slinosti prestaju. Naime, Team System nudi nove i mone
mogunosti kao to su Branching, Merging, Shelving i Annotate (pogledajte tablicu
pojmova uz tekst), ali najvanije svojstvo je mogunost integracije koda s artefaktima
iz drugih podsustava, tako da je na vrlo jednostavan nain ostvareno povezivanje
promjena na kodu s radnim stavkama. Upravo zbog takve integracije moemo,
primjerice, za svaku promjenu u kodu rei zbog kojeg je zadatka napravljena ili za
svaki rijeeni bug moemo doi do informacije tko, kada i kojim dijelom koda ga je
rijeio.

Krajnji korisnik podsustava za verzioniranje najee je razvojni inenjer. On snima

promjene na kodu kroz postupak koji se naziva checkin. Kod svakog checkina zajedno
s promjenama na kodu spremaju se i metapodaci koji poblie opisuju te promjene. U
metapodatke spadaju komentari i linkovi na radne stavke, dakle zadatke ili usecaseove, zbog kojih smo napravili promjene. Za svaku radnu stavku odabiremo da li
je ona samo povezana s promjenama (promjene su napravljene zbog te radne stavke,
ali ne implementiraju je u potpunosti) ili je potpuno implementirana.
Dodatno u metapodatke spadaju jo i primjedbe reviewera
i checkin politika. Checkinpolitika je niz pravila koja se provjeravaju tijekom
svakog checkina. Neka od standardnih pravila zahtijevaju da se svaka promjena koda
mora povezati s barem jednom radnom stavkom ili da se tijekom checkina mora
upisati komentar. Sveukupni sadraj jednogcheckina ini changeset, atomarni skup
promjena na kodu i metapodataka koji ih opisuju.
Ako pogledamo s tehnike strane, najvanije je da se svi podaci ukljuujui i
promjene na kodu spremaju u SQL Server bazu, a ne u datoteke na disku, kao to je
sluaj u Source Safeu. Stoga sve prednosti SQL Server baze podataka kao to su
robusnost, transakcionalnost i stabilnost, vrijede i za Team Systemov podsustav za
verzioniranje.

Changeset, atomarni skup promjena na kodu i metapodataka koji ih

opisuju prilikom svakog checkina, skup promjena povezuje se s radnim stavkama
Upravljanje meuverzijama

Kada imamo dobro organizirano verzioniranje koda, slijedei bitni korak ALM-a je
organizacija meuverzija (buildova). Team Build je ime podsustava koji ima za cilj
omoguiti da od prvog dana svaki projekt ima automatizirani build proces. Team
Build izvodi buildove na odvojenim posluiteljima, pri emu se buildovi mogu
pokretati jednom dnevno, nou, u tono odreeno vrijeme ili nakon svake promjene u
kodu, odnosno svakogcheck-ina. Ovo zadnje se naziva continuous integration i
preporuena je build strategija na sloenijim razvojnim projektima, pogotovo onima

na kojima radi vei broj programera. Pokretanje builda nakon svake promjene u kodu
omoguava da, ako se desi greka prilikom izgradnje builda, znamo da je uzrok
greke upravo ta zadnja promjena, pa je tako ispravljanje greaka bitno lake i bre.
Team Build je usko povezan s ostalim dijelovima Team Systema. Upravo zbog
integracije sa sustavom za praenje radnih stavki i sustavom za verzioniranje, nakon
svakog buildamoemo dobiti izvjetaj o svim promjenama na kodu u odnosu na
prethodni build, o tome koji su zadaci tim buildom rijeeni i kakvi su rezultati
automatiziranih testova. Iz takvog izvjetaja vrlo lako moemo koristei poveznice
doi do detaljnih informacija o kodu, radnim stavkama i o testovima izvrenim
tijekom izgradnje zadnjeg builda.
Projektni izvjetaji

Upravo zahvaljujui integraciji svih podsustava Team Systema i informacijama koje ti

podsustavi neprestano spremaju u sredinju SQL Server bazu podataka, a iz nje i u
OLAP kocku SQL Server Analysis Servicesa, omogueno je vrlo bogato izvjetavanje o
stanju projekta. Jednim klikom mia omoguen je uvid u najrazliitije analize, neke
zanimljive za biznis dio tima, a neke korisne i samom razvojnom timu.
U prateem okviru moete vidjeti dva zanimljiva izvjetaja Remaining
work i Quality indicators. Prvi opisuje stanje obavljenog i preostalog posla na
projektu, a drugi daje uvid u indikatore kvalitete na samom razvojnom kodu. Ove kao
i druge izvjetaje lanovi tima mogu vidjeti kroz timski SharePoint portal, koji je
sastavni dio Team Systema, a zahvaljujui integraciji Team Systema u Office, mogue
im je pristupiti i direktno kroz Outlook.
Gdje je tu razvojni tim?

Na kraju si moda postavljate pitanje treba li vam i vaem razvojnom timu ALM,
odnosno Team System. Moemo li danas uope razvijati softver bez da upravljamo
razvojnim ciklusom aplikacije? Treba li nam upravljanje zahtjevima, integracija
radnih stavki sa sustavom za verzioniranje koda, trebaju li nam
automatizirani buildovi i automatski izvjetaji o stanju projekta? Nije li to malo
previe za va mali tim od nekoliko ljudi? Moete li i dalje bez toga razvijati
aplikacije? Vjerojatno moete, isto kao to moete komunicirati unutar organizacije i
bez koritenja e-maila, samo je pitanje koliko ete u tome biti efikasni i kvalitetni.
Moda to zvui nezamislivo, ali nekad zaista nije postojao e-mail ili se barem nije
koristio u veini organizacija. Treba li vaem timu ALM? Odgovorite sami.

TeamCompanion for Outlook

Outlook klijent za Team System

TeamCompanion for Outlook djelo je domae softverske firme Ekobit, specijalizirane
za ALM rjeenja i usluge na Team System platformi. TeamCompanion je Team
System klijentska aplikacija ugraena u Outlook. Koristei TeamCompanion moete
pristupiti svim projektnim podacima direktno iz Outlooka, a zahvaljujui
zakazanim work item upitima, podaci o projektu sami e se osvjeavati u Outlooku
bez potrebe da se vi time bavite. Ovaj alat dodatno omoguuje integraciju
standardnih Outlook akcija s Team Systemom, pa je lako iz Outlook e-mailovastvoriti
radnu stavku ili pak na osnovi neke radne stavke poslati e-mail ili sazvati sastanak.
TeamCompanion na intuitivan nain povezuje prednosti Outlooka kao
kolaboracijskog alata i Team Systema kao alata za
ALM.

TeamCompanion for Microsoft Outlook

to nije napravio razvojni tim u Redmondu,
napravili su razvojni inenjeri u zagrebakoj
softverskoj firmi Ekobit.

Primjeri izvjetaja

Kakvo je stanje projekta?

Da bismo saznali kakvo je stanje na projektu, ponekad je dovoljno samo baciti pogled
na projektne izvjetaje. Na slici su dva primjera projektnih izvjetaja: Remaining
work iQuality indicators. Prvi opisuje stanje obavljenog i preostalog posla na
projektu, a drugi daje uvid u indikatore kvalitete izvornog koda.
Remaining work pokazuje ukupan broj otvorenih, rijeenih (implementiranih, ali
jo ne testiranih) i zatvorenih (implementiranih i testiranih) radnih stavki tokom
jedne iteracije. Ovaj izvjetaj omoguava praenje tempa kojim se rjeavaju zadaci.
Na osnovi grafa ekstrapolacijom je donekle mogue predvidjeti trenutak kada emo

sa svim zadacima biti gotovi. Projektni menader time ostvaruje pravovremeni uvid u
stanje projekta bez potrebe da svoj tim dodatno optereuje izvjetavanjem.
Izvjetaj Quality indicators osim projektnom menaderu, zanimljiv je i razvojnim
inenjerima jer se odnosi na kod, odnosno na kvalitetu njihovog rada. On pokazuje
nekoliko razliitih indikatora koji svi zajedno daju sliku o kvaliteti koda. Na
prikazanom grafu, kako se pribliavamo kraju iteracije, code churn (broj promjena
koda) se smanjuje, a istovremeno se pokrivenost koda testovima (code coverage)
poveava. Ovo su sve dobri trendovi i kvaliteta koda u ovom projektu s vremenom
raste.

Izvjetaj "Remaining work" stanje obavljenog i preostalog posla na projektu.

Izvjetaj "Quality Indicators" kakva je kvaliteta programskog koda?

Objanjenje Team System pojmova

Work Item

Radna stavka je bilo koji dio posla na projektu ili jo

openitije bilo to o emu elimo voditi evidenciju. Neki od
standardnih tipova radnih stavki su Task, Scenario, Bug,
Risk.

Work Item

Podsustav Team Systema za upravljanje i praenje radnih

Tracking

stavki.

Version Control

Podsustav Team Systema za spremanje i verzioniranje

izvornog koda.

Checkin

Postupak spremanja promjena na kodu u versioncontrolu.

Changeset

Atomarni skup promjena na kodu zajedno s metapodacima

o promjenama koje odlaze na posluitelj tijekom
jednog checkina.

Shelving

Slian postupak kao i checkin, osim to promjene koje

odlaze na posluitelj nisu vidljive kao dio koda koji se
preuzimanjem dobiva sa servera. Slui za sigurno
pohranjivanje koda na posluitelj u situacijama kada nije
mogue napraviti checkin. Idealno za spremanje koda radi
prekida u radu ili prijenosa koda drugom programeru kako
bi on napravio review ili nastavio raditi na kodu.

Branching

Odvajanje dijela ili kompletnog izvornog koda u zasebnu

granu kako bi daljnje promjene na toj grani bile odvojene
od glavnog izvornog koda.

Merging

Spajanje promjena iz dvije grane, odnosno prenoenje

promjena napravljenih u jednoj grani u drugu granu.

Annotate

Pogled na izvorni kod tako da se uz svaku liniju koda vidi

tko ju je i kada napravio.

Team Build

Podsustav Team Systema odgovoran za

automatiziranibuild proces

Continous
integration

Build strategija kod koje se build pokree na nakon

svakog checkina. Daje kontinuiranu sigurnost u
konzistentnost koda.

Code Churn

Mjera koliine promjena na kodu.

Unit testing

Testiranje dijelova koda, najee pojedinih metoda,

drugim metodama koje provjeravaju oekivano ponaanje
napisanog koda.

Code coverage

Mjera pokrivenosti koda unit testovima.

Napomena: lanak je preuzet iz posebnog izdanja WinDays Mrea 2009, objavljenog

u travnju 2009, izdava BUG d.o.o

ULOGE U SCRUM-U
Scrum nas elegantno zavarava. On je jedan od okvira koji je najlake razumjeti a najtee dobro
implementirati. Kaem dobro implementirati jer naslijeena jednostavnost Scrum-a moe nas
zavesti da pomislimo da ga je lako implementirati, kada su u stvarnosti potrebne godine da se
dobro prakticira. ini se da Scrum ide protiv svega to smo nauili u mnogim, mnogim godinama
tradicionalnog (waterfall) razvoja. Razumljivo je da je potrebno vrijeme da se odviknemo od naih
loih

navika

prilagodimo

se

novoj

realnosti.

U ovom tekstu dajem kratak uvod u uloge u Scrum timu.

Scrum Master
Trkai automobil ima instrumente i senzore kojima se nadgleda motor koji takoer ima ulje. Bez
ulja, motor bi prestao raditi, unitavajui pri tome sebe. Ulje je svuda, omoguujui da dijelovi

motora rade kao podmazani, hladei ih i osiguravajui dobru performansu pod optereenjem.
Scrum Master je takav. On ima ugraene senzore i instrumente koji mu omoguavaju da uoi
kada tim ne daje rezultate prema svojim sposobnostima i ima vjetine (mazivo) potrebno da
pomogne u popravljanju greaka. Biti Scrum Master je teak posao. Dobar Scrum Master je neko
ko razumije neverbalnu komunikaciju, osjea se sigurno u konfliktnim situacijama, efektivan je
komunikator, moe izgraditi povjerenje i zasluiti potovanje, i razumije dinamiku tima. Dobar
Scrum Master evoluira razvojni proces. On gradi povjerenje ne samo unutar tima, ve i sa
klijentima.

Product Owner
Osnovni cilj Product Owner-a je da se vizija koju su traili stejkholderi/klijenti implementira od
strane tima. Product owner ovo postie radei sa stejkholderima, kako bi razumio potrebne
funkcionalnosti sistema u razvoju. Potom e Product Owner pisati korisnike prie (user stories)
ili e ih pisati radei zajedno sa klijentima. Korisnike prie idu u Product Backlog.
Product

Owner

upravlja

predstavlja

interese

stejkholdera

klijenata.

Vratimo se na model automobila. Ako je Scrum Master kao ulje i senzori maine, Product Owner
je poput vozaa. Product Owner usmjerava automobil u pravom smjeru i pravi stalne korekcije
smjera potrebne da ostane na pravom putu i isporui rezultate. On predstavlja interese klijenata i
stejkholdera. Njegov posao je da uspostavi, odrava i komunicira viziju proizvoda timu i drugim
stejkholderima, upravlja povratom investicije (ROI) i finansijama projekta i donosi odluke kada da
pusti oficijelni release (uz pomo informacija koje dobija od klijenta i stejkholdera). Product Owner
je osoba na kojoj je konana odgovornost za uspjeh ili propast projekta. On odluuje ta se
razvija, kada se razvija, i da li ono to je razvijeno zadovoljava oekivanja.

Razvojni tim
Razvojni tim je motor trkaeg automobila. Sve vozake vjetine i svo ulje na svijetu nisu od koristi
automobilu bez motora. Razvojni tim izvrava viziju Product Owner-a uz pomo Scrum Master-a.
Tim je sastavljen od ljudi potrebnih da urade posao developeri, testeri, arhitekti, dizajneri svi
koji su potrebni. Razvojni tim je idealno sastavljen od ljudi koji su u punom radnom angamanu
posveeni jednom projektu. Razvojni tim je odgovoran za upravljanje svojim radom, svojim
obavezama

izvrenju

tih

obaveza.

Veina Scrum materijala e rei da je idealna veliina tima 7, plus ili minus 2 ljudi. Ja preferiram
parne brojeve jer to bolje podrava integraciju sa XP inenjerskom praksom. Tim je upravo to, tim
uloge i titule bi trebalo ukloniti jer to pomae razvoj drugarstva u timu. Cilj je ukloniti nain
razmiljanja Ja sam developer i ja samo piem kod i pomjeriti panju tako da Ja sam lan tima
odgovoran da isporui ovaj rezultat i ja to ne mogu uraditi sam zaivi u timu. U Scrum timu,
testeri mogu pisati kod a developeri mogu pisati testove kros-funkcionalnost je dobra stvar.

MOJ PRVI SUSRET SA XP-OM

tampa

El. pota

Moj prvi susret sa Agile metodologijama je XP projekat u softverskoj kui Leuven (Belgija), koja je
pravila migraciju velikog, 30 godina starog mainframe sistema na Java (jsf, kodo, Oracle, Sun)
platformu. Te 2005. godine bio sam svjedok brzoj transformaciji jednog velikog, staromodnoga i
tromog (RUP) tima u efikasnu XP mainu koja melje sve pred sobom.
NB: RUP (Rational Unified Proces, IBM) sa svojim iterativnim pristupom je u to vrijeme bio "the
way to go" u razvoju softvera u zapadnoj Evropi i generalno u svijetu.
ta je to XP ili eXtreme Programming? Mnogo literature se moe nai na internetu o tome, a
najjednostavnija definicija je da je XP grupa pravila kojih se programerski tim treba pridravati:
collective ownership, continuous integration, test driven development, pair programming, daily
standup, sustainable pace...
Na tim je bio striktan u praenju svih, tada definisanih, XP pravila, i vodio nas je ovjek koji je
ve tada imao dugogodinje iskustvo sa XPom. Ja sam, kao prvi XP coach na naem projektu,
imao svakodnevne "brainwashing sesije" s njegove strane i svi smo proitali Kent
Beckovu knjigu ve u prvih par sedmica itd.
Bilo nas je 20tak programera (ne raunam analiste, menadere) i na poetku smo funkcionisali
kao jedan veliki tim koji se kasnije, dolaskom novih ljudi, organizovao u 3 funkcionalna tima (30ak
programera).
Kakav je osjeaj raditi na XP projektu? Pokuat u da opiem stvari koje su me najvie dojmile u
tom periodu, stvari zbog kojih sam od tada, pa do dananjeg dana vrstog vjerovanja da je Agile
najbolja metodologija za uspjean razvoj softvera.
Collective ownership. Kod je svaiji. Svi treba da znaju sve o sistemu (kodu i konfiguraciji). Ne
postoje ljudi "bez kojih se ne moe". Raunari su svaiji. Kada ujutro doete na posao, vi ne
znate gdje ete sjesti jer nemate svoj raunar (svi raunari su identino konfigurisani i mogu
bukvalno svaki dan da se reformatiraju sa novim imidom), sjedate za prvu mainu koja je
slobodna i ekate stand up meeting (Scrum) da dobijete zadatak za taj dan ili dio tog dana. Cilj je
da su podijeljeni zadaci (tasks ili stories) u to veoj mjeri "vertikalni", a nikada horizontalni;
primjer: ako pravite dio nove stranice, onda zavravate i biznis koja ta stranica koristi, kao i
komunikaciju sa bazom podataka. Klasine podjele meu ljudima "on zna baze" i "ona je najbolja
u stranicama" prestaju da postoje.
Pair programming. XP je glasan. Ako niste dio tima i ako niste koncentrisani da sa svojim parom
zavrite neki zadatak, sve vam se ini kao jedan veliki kokoinjac, jer previe je buke. Za svakim

raunarom u jednoj velikoj prostoriji sjede 2 osobe i neprestano priaju i komentariu stvari koje
vide na ekranu. Pair programming je dakle pravilo u kome za svakim raunarom sjede dva
programera: driver, onaj koji kodira (vozi) i navigator,onaj koji promatra drivera, ukazuje na
greke, razmilja o stvarima koje nas ekaju, koje smo premetnuli s uma. Pravilo je bilo da se
svakih 15ak minuta uloge mijenjaju. Nekada smo tu frekvenciju mijenjali u funkciji TDDa (jedan
pie test, a drugi implementaciju). Pair programming je najefikasniji metod za transfer znanja.
Pair programming je takoer najefikasniji metod za pravljenje kvalitetnoga softvera. Code review
u timu u kome se parovi mijenjaju sa dovoljno dinamike je preteno nepotreban. Dakle, parovi
treba da se mijenjaju, ako ne u jednom danu, onda sigurno u iduem. Moj posao XP coacha je
izmeu ostalog bio da u standupu argumentujem potrebu da neko treba da promjeni paira,
ukoliko taj neko to nije sam izjasnio kao potrebu. Nekada smo "repairing" radili u podne, da
osvjeimo dinamiku rada. U svakom sluaju, "story lead" je onaj koji je odgovoran za delivery (i
burndown update) svog dijela posla, on ostaje sa odgovornou za svoj story, a parovi koji sjede
pored njega/nje se mijenjaju.
Test driven development (TDD) je definitivno najmoniji princip koji sam u tom vremenu
savladao i od tada pokuavam koristiti na svim projektima. Savladati TDD se sastoji u prihvatanju
sljedeeg pravila: ne postoji promjena koda ili konfiguracije ili bilo kojeg artifacta koji je dio
sistema u produkciji, ako prije toga niste napravili test koji pokazuje ta ta promjena tano donosi
sistemu. Taj isti test treba da padne (red) na samom poetku jer vae promjene jo nema. Zatim
napravite planiranu promjenu sistema (kod ili konfiguracija ili baza) i test tada treba da uspije
(green). Faza nakon toga je refactoring ili poboljanje koda koji ste upravo napravili sa redovnim
izvravanjem testova kao garancijom da daljnje promjene i poboljanja nee promijeniti pozitivan
rezultat testa. Red-green-refactor. Testovi su idealan nain dokumentacije. Metode u testu koje
sadre itave reenice u svom naslovu su uobiajena pojava jer nema boljeg naina da se sistem
opie nego u testu koji garantuje da sistem radi ono to treba da radi. Da bi se pobrinuli da niko
ne pie nijedan drugi vid dokumentacije, nismo dozvoljavali bilo koju vrstu komentara u kodu.
Imali smo automatske testove koji skeniraju kod i javljaju ako je neko pisao komentare u kodu.
Continuous build osigurava redovnu egzekuciju svih testova u svrhu kontrole koda koji su svi
programeri checkirali u source control. Prije bilo kojeg checkin-a, svaki programer je duan uzeti
"build token" (kod nas je to bio jedan mali teady bear) i staviti na vidljivo mjesto pored svog
raunara, zatim sinhronizovati svoj kod i pokrenuti build process, nakon ijeg pozitivnog izvrenja
moe da se napravi check in. Taj isti build process ili preteno znatno vea verzija napravljena na
produkcijskom operativnom sistemu ( = full build) je sastavni dio procesa continous builda koji
svaku no provjeri da li je neki test pao kao posljedica svih checkin-ova prethodnog dana. U tom
sluaju se na centralnom monitoru pojavi crvena boja kao znak svima u timu da prvo build treba
da se rijei prije nego se krene sa daljnim razvojem.
Iako ima jo mnogo toga to bih mogao napisati o XPu, zavrit u sa komentarom jo jednog
vanog pravila u XPu: sustainable pace. Stvarno je bitno ne raditi prekovremene sate ako
istinski pratite XP. Pregoriti e te.

U stvari, naa percepcija je bila da sva pravila XPa treba da se potuju ako elite postii balans i
dugotrajnost u izradi kvalitetnoga softvera. Nepotivanje samo jednog od njih moe imati fatalne
posljedice.

Kako ga zadrati Projekti pod kontrolom

Kako zadrati projekti pod kontrolom?CIO.com zatraio desetke projektnih menadera i
strunjaka za upravljanje projektima saznati.Ovdje su njihovi top 13 prijedloga za rjeavanje
izazova svi voditelji projekata susreu u jednom ili drugom trenutku-a za voenje projekata u
provjeru.

Flic
kr: C Knaus

1.Imenovanje pravi projekt menader za posao."Iznajmljivanje projektne menadere koji e

imati potovanje programere i koji razumiju ono to oni rade", kae Harry E. Keller, predsjednik,
izvrni direktor i osniva Smart znanosti obrazovanja Inc "Nita ne ubija IT projekti bre od loeg
upravljanja. To je teko, jer veina programeri nisu prikladni za upravljanje i veina menadera su
clueless u vezi s vrstama developer, ali vrijedi truda. "

2.Podrka voditelju projekta s pravom timu. "CIO mora adekvatno pripremiti momad s pravim
ljudima", kae Ben Lichtenwalner, vii menader Internet & eCommerce za Whirlpool Corporation
i osniva ModernServantLeader.com.Ne samo da ete izabrati pravi voditelj projekta, ali morate
"podrati svoj projekt menader s pravom reprezentativci (poslovni analitiar, QA manager, itd.)
tako da voditelj projekta moe [pravilno] voenje projekta i [ne ] obaviti sav posao. "
"Dodjela sredstava na temelju sposobnosti ne dostupnosti", kae Gerardo Menegaz, izvrni IT
arhitekt, IBM Global Technology Services."Preesto se sredstva dodjeljuju kako bi se jasno klupu
nego zbog vjetine utakmicu sa zahtjevima. Na kraju, ovo e posluiti samo potkopati uspjeh
projekta," kae on.

3.Razumjeti prednosti i slabosti svog projektnog tima. "Najvanija stvar u odravanju

projekte pod kontrolom je da 'znaju svoje konje,' to je moj tata bi rekao," kae dr. Tim Lynch,
predsjednik Uprave PsychsoftPC, tvorac visokih performansi gaming raunala i grafike radne
stanice."To je, morate znati koji su na svoj tim najbolje radi s minimalnim nadzorom i mogu biti
lijevo za pokretanje, koji treba biti potaknut i tko treba biti nadvladana i upravljati njima u skladu s
tim."
4.Opseg iz projekta tada ga svuku, dolje."Mi opseg iz cijelog projekta s juhom. Onda mi
izgleda da ga smanjiti za gotovo 50 posto", kae Patrick Clements, predsjednik Uprave
bigWebApps.com."Od toga 50 posto projekta uzmemo tri stvari moemo poeti i potpuna da bi
projekt bio uspjeh, u osnovi metoda MVP (minimalno odriv proizvod)."
5.Prioritete zadatke i dolazi do smjernica za prilikom sukoba prioritete. "Dobri voditelji
projekata znaju da multitasking je velika produktivnost ubojica, pa su [treba] stvoriti okruenje u
kojem pojedinci i timovi mogu se usredotoiti na nekoliko zadataka u isto vrijeme", kae Sanjeev
Gupta, predsjednik Uprave, realizaciju Technologies, koja omoguuje planiranje i izvrenje
softver.

"To podrazumijeva smanjenje broja radnih tokova u izvrenju (kako bi se smanjili prioritetnih
sukoba) i pokretanja novih radnih potoci samo ako su svi potrebni ulazi na mjestu", rekao je
Gupta.Osim toga, vano je da odrede prioritete zadatke i utvrditi smjernice i procedure za to

uiniti kada prioritetna sukobi ne nastaju."Ove mjere pomau u kombinaciji premijera poboljati
stopu izvrenja za ak 20 do 50 posto", rekao je on.
6.Aktivno praenje projekata, kao i svoj tim. "Voditelj projekta mora biti budno svjesni onoga
to se dogaa u svakom trenutku", izjavio je Albert Sarvis, PMP, koji vodi projekt menadment
tima na Harrisburg Sveuilita znanosti i tehnologije.
"Uinite to stvar dosljedan rutinu za praenje projektne podatke na razini resursa i ne dopustite
tradicionalni projekt alata biti va jedini vodi," kae on."Ne alat za upravljanje projektima moe
rasvijetliti projektne iznenaenja kao lan projektnog tima moe osigurati putem redovitih jedanna-jedan komunikacije."
7.Koristite softver za upravljanje projektima. "Nemojte koristiti e-mail kao alat za upravljanje
projektima", kae Kent Milholland, predsjednik NeoNexus, koji prua web dizajn, prilagoene web
aplikacije i internet marketing rjeenja."To je previe teko pratiti."
Umjesto toga, Milholland kae, "drati softver za upravljanje projektima na sustavu kao
Assembla, ili ak Basecamp, pa su pojedinosti o svakom zahtjevu dokumentirani bez puno
dodatnog napora. Web-based project management omoguuje svima od korisnika do programera
za klijente na donositelji odluka pratiti napredak s lakoom. "

Flic
kr: VFS digitalni dizajn

8.Drite tjedne sastanke. "Postavljanje kratku, obvezni tjedni sastanak gdje svaki lan tima traje
minutu ili dvije za rei tim to su napravili prolog tjedna, njihovi planovi za ovaj sljedei tjedan i
sve zapreke koje imaju da tim moe pomoi u", kae Grant M . Howe, potpredsjednik odjela za
istraivanje i razvoj, Sage Neprofitne Solutions, koja nudi softverske proizvode i usluge za vladine
agencije i neprofitne organizacije."To stvara hitnost za svakog pojedinca u timu oko napreduje
svaki tjedan."
9.Upravljanje promjenama. "Upravljanje promjenama na izvornom djelokrugu rada je najvanije
za voenje projekata pod kontrolom", kae Jaimin Doshi, glavni konzultant, AppleTech
konzultanti, IT savjetovanje i upravljanje projektima tvrtke.
"Vano je da se [koritenja] kontrole promjena oblika analizirati utjecaj promjena s obzirom na
vrijeme, trokove i bitnost", kae Doshi."Promjene smatraju kozmetike (manje) takoer trebaju
biti praeni od strane voditelja projekta, kao i provoenje testiranje te promjene ponekad mogu
dodati do znaajnih sati."
10.Uzmi vrstu liniju protiv opseg puzanja."Scope creep je glavni uzrok projekata izmiu
kontroli", kae Nick Coons, tehniki direktor, Hyperion Works, pruatelj web stranice, prilagoene
web aplikacije i softver i IT menadment.
Meutim, "troenje vremena unaprijed kako bi se postavili temelji i jasno definirati opseg e vam
pomoi zadrati projekt na pravom putu", kae on.tovie, "kada klijent neizbjeno ini out-ofopseg zahtjeve, nemojte se sramiti rei im da ete dodati njihov zahtjev da se" Faza 2 "projekta,
koji e imati svoj opseg i cijene."

11.Stvaranje kljune toke za svakog lana tima i slaviti ih, kada se sastao. "Stvaranje
prekretnice u fazi planiranja za vas i va tim e vam pomoi pratiti svoj napredak i dati vam
osjeaj postignua kada doete svaki korak", kae G. Karthik, direktor projekta, Hexaware
Technologies, poslovna inteligencija, poslovne analitike i enterprise rjeenja usluga.
Zatim, "kada doete do prekretnice, donijeti svi zajedno za neke zabave drutvene vrijeme (npr.,
drite sladoled socijalne u uredu) na [lanovima nagrada tima] i drati svi uzbueni aboutthe
projekta", kae Michael Hamelin, ef sigurnosti projektant Tufin Technologies, pruatelj rjeenja
firewall upravljanja.Za ekipe koje krue geografski ili rade gotovo, priznaju dogaaje s manjim
gestama, to moe biti kao jednostavan kao estitku e-mail.
12.Razmislite o koritenju agilni metodologiji."Ustanovili smo da upravljanje projektima
slijedei Agile metodologije radi jako dobro za nas", kae Andre Winter, vii menader
inenjering, CA Technologies."Ova metodologija omoguuje tim reagirati i prilagoditi svoje
projekte za potrebe trita, boravei vjerni interese, vrijednosti i sposobnosti nae tvrtke."
13.Pratite vrijeme. "Pratite vremena proveo po kljunim osobljem odgovornim za zavretak
glavnih dijelova projekta," savjetuje Ken Leland III, potpredsjednik inenjerstva, Monmouth
Telecom."To e vas upozoriti na netonosti u svojih prvotnih procjena rano u projekt i dati vam
vie vremena da se bave posljedicama", kae on.Za praenje vremena provedenog od strane
internih resursa, Leland sugerira cloud-based usluge kao to su toggl.com.

Scrum je procesni framework koji se koristi za upravljanje kompleksnim razvojem. Scrum nije
metodologija ili tehnika razvoja sooftware-a , nego je okvir unutar kojega se mogu koristiti razni
procesi i tehnike (npr. ekstremno programiranje). Kao to je ve spomenuto Scrum framework se
sastoji od Scrum timova, njihovih pridruenih uloga, dogaaja, artefakata i pravila.

Scrum timovi i uloge unutar tima

Scrum tim
Scrum tim sastoji se od vlasnika proizvoda (engl. Product Owner), razvojnog tima (engl. Development
team) i Scrum mastera. Scrum isporuuje proizvode iterativno i inkrementalno, maksimirajui mogue
povratne informacije.

Vlasnik proizvoda
Vlasnik proizvoda je odgovoran za maksimizaciju vrijednosti proizvoda i rada razvojnog tima. Naina
na koji se to postie vrlo je razliit izmeu raznih organizacija, timova i ljudi. Vlasnik proizvoda je jedini
odgovoran za upravljanje Product Backlogom. to ukljuuje jasno objaanjvanje razvojnom timu vizije,
ciljeve i stavke na Product Backlogu. Razvojni tim radi prema naputcima Vlasnika stoga i cijela
organizacija mora potivati njegove odluke.

Razvojni tim
Razvojni tim sastoji se od profesionalaca koji rade konkretan posao isporuujui inkrement proizvoda
na kraju svakog Sprinta. Samo lanovi razvojnog tima stvaraju inkrement proizvoda.

Scrum master
Scrum master je odgovoran da se Scrum razumije i koristi. Scrum Masteri to postiu na nain da
osiguravaju da se Scrum timovi pridravaju teorije, prakse i pravila Scruma.

Dogaaji u Scrumu
Scrum koristi propisane dogaaje radi uspostave pravilnosti i minimizacije potrebe za sastancima koji
nisu definirani Scrumom. Scrum koristi vremenski ograniene dogaaje na nain da svaki vremenski
dogaaj ima odreeno maksimalno trajanje. Na taj nain se osigurava da se dovoljno vremena koristi
za planiranje bez uzaludnog troenja vremena.

Sprint
Srce Scruma je Sprint, vremenski ogranieni period od jednog mjeseca ili manje tijekom kojega se
proizvede zavren, upotrebljiv i potencijalno isporuiv inkrement proizvoda. Sprintovi su jednakog
trajanja tijekom cijelog razvoja proizvoda. Novi Sprint zapoinje neposredno nakon to zavri
prethodni. Sprint se sastoji od sastanka za planiranje Sprinta, dnevnog Scruma, posla razvoja, revizije
Sprinta i retrospektive Sprinta. Svaki Sprint se moe smatrati projektom iji horizont ne prelazi mjesec
dana. Poput projekata Sprint se koristi da se obavi neki posao. Svaki Sprint ima definiciju to e se
obaviti, na koji nain i koji e odrediti izradu, posao i konani proizvod.

Dnevni Scrum
Dnevni Scrum je 15-minutni, vremenski ogranien dogaaj, koji slui da razvojni tim uskladi aktivnosti i
donese plan za sljedea 24 sata. To se ini kontrolom rada od prethodnog dnevnog Scrum sastanka i
procjenom posla koji bi mogao biti odraen prije slijedeeg sastanka. Dnevni Scrum se odrava uvijek
na istom mjestu svaki dan da bi se smanjila kompleksnost. Scrum master forsira pravilo da samo
razvojni tim sudjeluje na dnevnom Scrum sastanku i da sastanak traje 15 minuta.

Artefakti u Scrumu

Product Backlog
Product backlog je sortirana lista svega to e moda biti potrebno za proizvod i jedini izvor zahtjeva
za bilo kakvim promjenama koje se rade na proizvodu. Vlasnik proizvoda je odgovoran za Product
backlog, ukljuujui njegov sadraj, raspoloivost i sortiranje. Product backlog nikad nije konaan. U
poetku sadri samo one zahtjeve koji su inicijalno poznati i razumljiviji. Product backlog evoluira kako
evoluira proizvod i okolina na kojoj e se primjenjivati. Product backlog sadri listu svih mogunosti,
funkcionalnosti, zahtjeva, unaprijeenja i popravaka koja zajedno ine promjene koje e se primijeniti
nad proizvodom u budunosti. Obino je sortiran prema vrijednosti, riziku, prioritetu i nunosti. Stavke
na vrhu backloga su dio trenutnih razvojnih aktivnosti.

Sprint Backlog
Sprint backlog je skup stavki s Product Backloga koje su odabrane za Sprint plus plan realizacije
Inkrementa i realizacije Cilja Sprinta. Sprint Backlog je procjena razvojnog tima koje funkcionalnosti e
biti u sljedeem Inkrementu i posao koji je potreban za realizaciju tog Inkrementa.
Sprint backlog je plan sa dovoljno detalja da bi se na Dnevnom scrumu mogle razumjeti aktualne
promjene. Razvojni tim mijenja Sprint backlog tijekom Sprinta, te se na njega dodaju zadaci tijekom
Sprinta . Ti zadaci se dogaaju kada Razvojni tim, radei prema planu, naui neto vie o poslu koji je
potreban da se zadovolji cilj Sprinta. Kako se pojavi potreba za novim poslom, Razvojni tim ga dodaje
na Sprint backlog. Samo razvojni tim moe mijenjati Sprint backlog tijekom Sprinta. Sprint backlog je
vidljiva slika posla u realnom vremenu kojeg Razvojni tim namjerava obaviti tijekom Sprinta i koji
pripada iskljuivo Razvojnom timu.

to se tie bagova:
Scrum proces bagove tretira tako to ih dodaje kao stavke u Product Backlog,
Scrum kroz stalna poboljanja Definition Of Done tei tome da nema bagova u isporuenom
inkrementu ili da bagovi budu takvog uticaja na rad softverskog sistema da mogu da saekaju
zavretak aktuelnog Sprint-a da bi u sledeem Sprint Planning-u uli, zbog visokog prioriteta, u
sledei Sprint Backlog,
Development Tim sprovodi standarde u toku Sprinta , koji su definisani u Definition Of Done, da
bi stalno odravali i poboljavali kvalitet svog rada i kvalitet proizvoda. Standardi na koje moe da
se oslanja Definition Of Done mogu da budu interno ili eksterno definisani.

to se tie faze Razvoja:

Dekompozicija preuzetih stavki Product Backlog-a u stavke Sprint Backloga i dalje redefinisanje
i poboljanje definicije ve uraenih stavki Sprint Backloga se radi u toku faze Razvoja. U toku
faze razvoja Development Tim ne radi samo razvoj. Vreme potrebno da se radi na definisanju i
poboljanju definicije Sprint Backlog stavki u toku Razvoja a i na ostalim aktivnostima, kao to su
Testiranje ili recimo pisanje dokumentacije za odravanje i pisanje korisnikih uputstava, je vreme
koje Development Tim mora da ima na umu kad na Sprint Planning-u preuzima stavke Product
Backloga.
Ovo je u skladu sa Scrum-om koji je definisan Scrum Guide-om na scrum.org.

How does Scrum Work?

Building complex products for customers is an inherently difficult task. Scrum provides structure to
allow teams to deal with that difficulty. However, the fundamental process is incredibly simple, and
at its core is governed by 3 primary roles.
1.
2.

Product Owners determine what needs to be built in the next 30 days or less.
Development Teams build what is needed in 30 days (or less), and then
demonstrate what they have built. Based on this demonstration, the Product Owner
determines what to build next.

3.

Scrum Masters ensure this process happens as smoothly as possible, and

continually help improve the process, the team and the product being created.
While this is an incredibly simplified view of how Scrum works, it captures the essence of this
highly productive approach for team collaboration and product development.

Glossary of Scrum Terms

This glossary is meant to represent an overview of Scrum-related terms.
Some of the mentioned terms are not mandatory in Scrum, but have been added
because they are commonly used in Scrum.
To learn more about the Scrum framework, to identify which of these terms are
required elements of Scrum and to understand how the mentioned elements are
connected, we highly recommend that you reference the Scrum Guide.
To learn more about terms specific to software development teams using Scrum and
agile software development techniques, reference the Professional Scrum Developer
glossary.

B
Burn-down Chart: a chart showing the evolution of remaining effort against time.
Burn-down charts are an optional implementation within Scrum to make progress
transparent.
Burn-up Chart: a chart showing the evolution of an increase in a measure against
time. Burn-up charts are an optional implementation within Scrum to make progress
transparent.

D
Daily Scrum: daily time-boxed event of 15 minutes, or less, for the Development
Team to re-plan the next day of development work during a Sprint. Updates are
reflected in the Sprint Backlog.
Definition of Done: a shared understanding of expectations that software must live
up to in order to be releasable into production. Managed by the Development Team.
Development Team: the role within a Scrum Team accountable for managing,
organizing and doing all development work required to create a releasable Increment
of product every Sprint.
Emergence: the process of the coming into existence or prominence of new facts or
new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

E
Empiricism: process control type in which only the past is accepted as certain and in
which decisions are based on observation, experience and experimentation.
Empiricism has three pillars: transparency, inspection and adaptation.
Engineering standards: a shared set of development and technology standards
that a Development Team applies to create releasable Increments of software.

F
Forecast (of functionality): the selection of items from the Product Backlog a
Development Team deems feasible for implementation in a Sprint.

I
Increment: a piece of working software that adds to previously created Increments,
where the sum of all Increments -as a whole - form a product.

P
Product Backlog: an ordered list of the work to be done in order to create, maintain
and sustain a product. Managed by the Product Owner.

Product Backlog refinement: the activity in a Sprint through which the Product
Owner and the Development Team add granularity to the Product Backlog.
Product Owner: the role in Scrum accountable for maximizing the value of a
product, primarily by incrementally managing and expressing business and functional
expectations for a product to the Development Team(s).

R
Ready: a shared understanding by the Product Owner and the Development Team
regarding the preferred level of description of Product Backlog items introduced at
Sprint Planning.

S
Scrum: a framework to support teams in complex product development. Scrum
consists of Scrum Teams and their associated roles, events, artifacts, and rules, as
defined in the Scrum GuideTM.
Scrum Board: a physical board to visualize information for and by the Scrum Team,
often used to manage Sprint Backlog. Scrum boards are an optional implementation
within Scrum to make information visible.
Scrum Guide: the definition of Scrum, written and provided by Ken Schwaber and
Jeff Sutherland, co-creators of Scrum. This definition consists of Scrums roles,
events, artifacts, and the rules that bind them together.
Scrum Master: the role within a Scrum Team accountable for guiding, coaching,
teaching and assisting a Scrum Team and its environments in a proper understanding
and use of Scrum.
Scrum Team: a self-organizing team consisting of a Product Owner, Development
Team and Scrum Master.
Scrum Values: a set of fundamental values and qualities underpinning the Scrum
framework; commitment, focus, openness, respect and courage.
Self-organization: the management principle that teams autonomously organize
their work. Self-organization happens within boundaries and against given goals.
Teams choose how best to accomplish their work, rather than being directed by
others outside the team.

Sprint: time-boxed event of 30 days, or less, that serves as a container for the other
Scrum events and activities. Sprints are done consecutively, without intermediate
gaps.
Sprint Backlog: an overview of the development work to realize a Sprints goal,
typically a forecast of functionality and the work needed to deliver that functionality.
Managed by the Development Team.
Sprint Goal: a short expression of the purpose of a Sprint, often a business problem
that is addressed. Functionality might be adjusted during the Sprint in order to
achieve the Sprint Goal.
Sprint Planning: time-boxed event of 1 day, or less, to start a Sprint. It serves for
the Scrum Team to inspect the work from the Product Backlog thats most valuable to
be done next and design that work into Sprint backlog.
Sprint Retrospective: time-boxed event of 3 hours, or less, to end a Sprint. It
serves for the Scrum Team to inspect the past Sprint and plan for improvements to
be enacted during the next Sprint.
Sprint Review: time-boxed event of 4 hours, or less, to conclude the development
work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the
Increment of product resulting from the Sprint, assess the impact of the work
performed on overall progress and update the Product backlog in order to maximize
the value of the next period.
Stakeholder: a person external to the Scrum Team with a specific interest in and
knowledge of a product that is required for incremental discovery. Represented by the
Product Owner and actively engaged with the Scrum Team at Sprint Review.

V
Velocity: an optional, but often used, indication of the average amount of Product
Backlog turned into an Increment of product during a Sprint by a Scrum Team,
tracked by the Development Team for use within the Scrum Team.

Professional Scrum Developer

Glossary
This glossary represents an overview of terms specific to software development
teams using Scrum and agile software development techniques.

To learn more about the Scrum framework, we highly recommend that you reference
the Scrum Guide and the Scrum Glossary.

A
ALM (Application Lifecycle Management): holistic view on the management of
software applications and systems, accounting for all stages of the existence of a software
product.
ATDD (Acceptance Test-Driven Development): test-first software development
practice in which acceptance criteria for new functionality are created as automated tests. The
failing tests are constructed to pass as development proceeds and acceptance criteria are met.

B
BDD (Behavior-Driven Development): agile software development practice adding to
TDD the description of the desired functional behavior of the new functionality.
Branching: creating a logical or physical copy of code within a version control system so that
this copy might be changed in isolation.

C
Clean Code: software code that is expressed well, formatted correctly, and organized for later
coders to understand. Clarity is preferred over cleverness.
Code Coverage: a measurement indicating the amount of product code that is exercised by
tests.
Cohesion and Coupling: coupling refers to the interdependencies between modules, while
cohesion describes how related the functions within a single module are.
Collective Code Ownership: a software development principle popularized by Extreme
Programming holding that all contributors to a given codebase are jointly responsible for the code
in its entirety.
Continuous Delivery: a software delivery practice similar to Continuous Deployment except
a human action is required to promote changes into a subsequent environment along the pipeline.
Continuous Deployment: a software delivery practice in which the release process is fully
automated in order to have changes promoted to the production environment with no human
intervention.<

Continuous Integration (CI): agile software development practice popularized by Extreme

Programming in which newly checked-in code is built, integrated and tested frequently, generally
multiple times a day.
Cyclomatic Complexity: a measure of code complexity based on the number of
independent logical branches through a code base. Cyclomatic complexity is expressed as a
simple integer.
Cross-functional: characteristic of a team holding that all the skills required to successfully
produce a releasable Increment in a sprint are available within the team, where releasable refers
to making the software available in production.

D
Definition of Done: a shared understanding of the expectations that software must live up to
in order to be releasable into production, with a purpose of providing transparency over the
software created. Managed by the Development Team.
Developer: any member of a Development Team, regardless of technical, functional or other
specialty.
DevOps: an organizational concept serving to bridge the gap between development and
operations, in terms of skills, mind-set, practices and silo-mentality. The underlying idea is that
developers are aware of, and in daily work consider implications on operations, and vice versa.
Development Team: the self-organizing role within a Scrum Team accountable for managing,
organizing and doing all work required to create a releasable Increment of product every Sprint.
All work is called development.
DRY (dont repeat yourself): software development principle to avoid repetition of the
same information in one system, preventing the same code from being produced multiple times
on a code base.

E
Engineering Standards: a shared set of development and technology standards that a
Development Team applies to create releasable Increments of software, and against which a
Development Team can inspect and adapt.
Extreme Programming (XP): agile software development framework with an extreme focus
on programming and taking engineering practices to an extreme in order to create and release
high quality code. Highly complementary to the Scrum framework.

F
Feature Toggle: software development practice that allows dynamically turning (parts of)
functionality on and off without impacting the overall accessibility of the system by its users.

I
Increment: a fully functional piece of working software, living up to the definition of Done, that
adds to previously created Increments, where the sum of all Increments - as a whole - form a
product. An Increment typically is the result of a Sprint.

P
Pair Programming: agile software development practice popularized by Extreme
Programming in which 2 team members jointly create new functionality.

R
Refactoring: agile software development practice popularized by Extreme Programming in
which code is adjusted within the code base without impacting the external, functional behavior of
that code.

S
Scout Rule: the practice of always leaving the code base in a little better state than it was
found before modifications. A means to progress towards Clean Code.
Scrum: a framework to support teams in complex product development. Scrum consists of
Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum
Guide.
Scrum Board: a board to visualize information within the Scrum Team primarily, often used to
manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make
information visible and thereby increase transparency.
Scrum Guide: the definition of Scrum, written and provided by Ken Schwaber and Jeff
Sutherland, co-creators of Scrum. The Scrum Guide consists of Scrums roles, events, artifacts,
and the rules that bind them together.
Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and
Scrum Master.

Self-organization: the organizational principle that teams autonomously organize their work.
Teams choose how best to accomplish their work, rather than being directed by others outside the
team. Self-organization happens within boundaries and toward goals.
Specification by Example: agile software development practice based on TDD and ATDD
that calls for using realistic examples from past experience instead of untested or abstract
statements in the description of the desired functional behavior.

T
TDD (Test-Driven Development): test-first software development practice in which test
cases are defined and created first, and subsequently executable code is created to make the test
pass. The failing tests are constructed to pass as development proceeds and tests succeed.
Technical Debt: the typically unpredictable cost of having to resolve or work with unfinished,
unclean, undone or defect code once it has been released into production.

U
User Story: agile software development practice from Extreme Programming to express
requirements from an end user perspective, emphasising verbal communication. In Scrum, it is
often used to express functional items on the Product Backlog.
Unit Test: low-level technical test focusing on small parts of a software system that can be
executed fast and in isolation. The definition and boundaries of a unit generally depends on the
context and is to be agreed by the Development Team.

V
Velocity: an optional but often used indication of the average amount of Product Backlog
turned into an Increment of product during a Sprint. It is tracked by the Development Team for use
within the Scrum Team.

http://www.free-management-ebooks.com/skills-leadership.htm
http://it-ebooks.info/search/?q=project%20management%20body%20of
%20knowledge&type=title&page=100