Agilni procesi razvoja softvera i agilno 12 principa agilnog razvoja:
upravljanje 1. Zadovoljan klijent je naš vrhunski prioritet, koji ostvarujemo
Mirjana Marić
Istorijski pogled na agilne procese razvoja
• Razvoj informaciono komunikacionih tehnologija i interneta
uticao je na pojavu globalnog poslovanja i 24 časovne
ekonomije.
• Prilagođavanje novim tržišnim prilikama i ekonomskim
uslovima nije zaobišlo ni kompanije za razvoj softverskih
proizvoda, jer je softver postao deo gotovo svih poslovnih
operacija.
• Rapidne promene u poslovnom okruženju onemogućile su
inicijalno definisanje stabilnih i fiksnih softverskih zahteva.
• Promenljivost zahteva tokom celog životnog ciklusa IT
projekta, pa i nakon njegove isporuke, postao je imperativ u
razvoju poslovnog softvera krajem dvadesetog veka.
• U ovakvim okolnostima tradicionalni procesi razvoja, koji su
do tada uspešno odgovarali na poslovne zahteve, nisu mogli
adekvatno da odgovore novim poslovnim izazovima.
• Dobro definisani procesi, sa velikim brojem uloga, aktivnosti i
masovnom dokumentacijom, pogodovali su razvoju velikih
skalabilnih softverskih rešenja koja se lako održavaju, ali su
predstavljali balast u razvoju malih internet poslovnih rešenja.
• Primer takvog procesa razvoja je RUP. Uspostavljanje samog
razvojnog procesa po RUP-u predstavljao je zahtevniji i
vremenski duži posao od samog rešenja koje se trebalo razviti.
• Tradicionalni procesi razvoja softvera iziskuje velika ulaganja
resursa, što preduzeća suočena sa brzim razvojem tehnologije i
čestim promenama u poslovnom okruženju nisu u mogućnosti
da obezbede.
• Kreiranje i prihvatanje promena postao je imperativ za
ostvarivanje njihove konkurentnosti na tržištu. To je istorijski
moment pojave “lakih” procesa razvoja softvera, koji se
svrstavaju u grupu agilnih metodologija.
• Februara 2001 sačinjen je Agilni Manifest - dokument koji
proklamuje 4 vrednosti i 12 principa agilnog razvoja.
4 vrednosti agilnog razvoja
1. Pojedinci i interakcije iznad procesa i alata.
2. Primenljiv softver iznad detaljne dokumentacije.
3. Saradnja sa klijentima iznad ugovora.
4. Reakcija na promenu iznad pridržavanja plana.
blagovremenom i kontinuiranom isporukom vrhunskog
softvera.
2. Spremno prihvatamo promene zahteva, čak i u kasnoj fazi
razvoja. Agilni procesi оmogućavaju uspešno prilagođavanje
izmenjenim zahtevima, što za rezultat ima prednost naših
klijenata u odnosu na konkurenciju.
3. Redovno isporučujemo primenljiv softver, u periodu od
nekoliko nedelja do nekoliko meseci, dajući prednost kraćim
intervalima.
4. Poslovni ljudi i razvojni tim svakodnevno sarađuju u tokom
trajanja projekta.
5. Projekte ostvarujemo uz pomoć motivisanih pojedinaca.
Obezbeđujemo im ambijent i podršku koja im je potrebna i
prepuštamo im posao s poverenjem.
6. Za najproduktivniji i najefikasniji metod prenosa informacija,
do i unutar razvojnog tima, smatramo kontakt licem u lice.
7. Primenljiv softver je osnovno merilo napretka.
8. Sponzori, razvojni tim i korisnici moraju biti u stanju da
kontinuirano rade ujednačenim tempom, nezavisno od
vremena trajanja projekta.
9. Stalna posvećenost vrhunskom tehničkom kvalitetu i
dobrom dizajnu pospešuju agilnost.
10. Jednostavnost je prioritet, kao veština eliminisanja
nepotrebnog, suvišnog rada.
11. Najbolje arhitekture, zahtevi i dizajn rezultat su rada
samoorganizovanih timova.
12. Tim u redovnim vremenskim intervalima razmatra načine
kako da postane efikasniji, usaglašava se, a potom i
prilagođava svoje ponašanje.
• Agilni procesi zasnivaju se na iterativno-inkrementalnom
razvojnom modelu.
• Razvoj softverskog rešenja realizuje se kroz veliki broj
malih iteracija (sprintova), čije trajanje je od 2-4 nedelje.
• Svaka iteracija (sprint) predstavlja zaokruženi ciklus
razvoja softvera, uključujući: planiranje, analizu zahteva,
dizajn, kodiranje, testiranje i prihvatanje testiranja.•
Rezultat svake iteracije je nova funkcionalnost (inkrement)
tj. deo softverskog proizvoda koji se razvija za korisnika.
• Korisnici su uključeni u ceo razvojni proces, što
obezbeđuje:
1. dobijanje brzog odgovora za razvijeni set funkcionalnosti
nakon svake iteracije (sprinta),
2. brzo uvođenje neophodnih promena, kroz set novih
zahteva i zadataka, koji postaju input za narednu iteraciju -
sprint.
 Scrum
• Scrum je iterativno - inkrementalni procesni okvir, koji se
koristi za upravljanje razvojem i održavanjem softverskih
proizvoda.
• Sadrži set menadžerskih preporuka, ali ne definiše aktivnosti
samog razvojnog procesa.
• Često se koristi u kombinaciji sa drugim procesima razvoja
softvera.
• Scrum okvir izgrađuju 3 ključna elementa:
 uloge u timu,
 događaji,
 artifakti
Scrum vrednosti : COMMITMENT COURAGE
FOCUS OPENNESS RESPECT
-------------------------------------------
Uloge
1. Product owner (vlasnik proizvoda) ima sledeće zadatke:
 da prikuplja inpute od krajnjih korisnika i sponzora
projekta,
 da prikupljene inpute transformiše u korisničke zahteve u
formatu korisničke priče,
 vrši vrednovanje korisničkih priča sa aspekta prioriteta u
razvoju;Značaj i redosled razvoja pojedinih korisničkih priča
utvrđuje sa aspekta postizanja maksimalne poslovne
vrednosti za korisnika/sponzora projekta. Korisničke priče
koje donose najviše poslovne vrednosti korisniku imaće
najveći prioritet.
 vrši procenu napora (efforta) za realizaciju svake korisničke
priče ponaosob,
 definiše viziju i obim projekta.
Vizija projekta
-Jasno predstavljanje zahteva na Product Backlog -u
-Definisanje redosleda zahteva na Backlog-u i gruba procena
napora (efforta) za njihovu realizaciju
-Zastupa korisnika/kupca i obezbeđuje da je razvojni tim
razumeo viziju i obim projekta/proizvoda (scope)
2. Development team (razvojni tim) je: krosfunkcionalan i
samoorganizujuć.
Čini ga od 5 do 10 članova, sledećih profila eksperata:
analitičari, programeri, dizajneri, testeri.
Razvojni tim ima autonomiju u donošenju odluka, kao i
slobodu da Product owner-u (vlasniku proizvoda) dostavlja
ideje za unapređenje proizvoda.
• Scrum Master (vođa) odgovoran je za:
 uspešan razvoj krajnjeg proizvoda.
 uspešnu implementaciju Scrum-a na projektu,
pružajući kontinuiranu pomod i podršku članovima
razvojnog tima.
• Scrum vođa nije menadžer, već lider koji je ujedno i član
razvojnog tima. Treba da poseduje širok spektar znanja o
samom procesu razvoja (od analize do upravljanja projektom) i
da ima iskustva na razvojnim projektima. Za razliku od
menadžera ne delegira zadatke članovima razvojnog tima niti
se postavlja prema njima sa aspekta formalnog autoriteta i
moći zasnovane na položaju. On je jednak među jednakima.
---------------------------------
Događaji
1. Sprint
• Predstavlja iteraciju koja može da traje 2-4 nedelje, a rezultat
svake iteracije je inkrement (funkcionalnost, izvršni deo
proizvoda koji se razvija). Sprint sadrži sve faze razvoja
softverskog proizvoda.
• Nakon pokretanja sprinta, nije moguće vršiti izmene: niti
postavljenih ciljeva sprinta, niti korisničkih zahteva koji se
implementiraju tokom sprinta, niti promenu učesnika sprinta.
• Potrebne izmene moguće je implementirati pokretanjem
narednog sprinta.
• Izvršavanje sprinta može biti prekinuto samo u ekstremnim
slučajevima. Priviligija pripada samo Product owner-u (vlasniku
proizvoda).
2. Backlog Grooming Meeting
• Je događaj koji se prvi put organizuje na početku projekta i
na kojem product owner prikazuje korisničke priče koje je
definisao. Cilj je da razvojni tim razume svaku korisničku priču i
da zajednički procene potreban napor (effort) za njihovu
realizaciju. Jedna od mogućih tehnika za procenu napora jeste
Planning pocker.
• Ovaj događaj se vodi i pred svako planiranje sprinta, tokom
celog perioda trajanja projekta. Cilj je da su kontinuirano
ažurira produckt backlog tj. Unose/menjaju/dodaju nove
korisničke priče na njemu.
3. Sprint planning meeting (planiranje sprinta)
• Na događaju planiranja sprinta članovi tima diskutuju sa
vlasnikom proizvoda koje korisničke priče sa Product backloga
će biti realizovane tokom sprinta.
• Događaj planiranje sprinta je vremenski ograničen i može
trajati najduže 8 sati.
• Uključuje vlasnika proizvoda i razvojni tim.
• Rezultat planiranja sprinta je lista zadataka sprinta (Sprint
backlog), kroz čije izvršavanje se realizuju postavljeni ciljevi
sprinta: inkrement/funkcionalnost.
• Sprint backlog jeste lista zadataka koje članovi razvojnog
tima definišu i preuzimaju na sebe. Za svaki identifikovani
zadatak članovi tima vrše procenu koliko je vremena potrebno
za njegovu realizaciju.
4. Dnevni sastanci
• Ne smeju biti duži od 15 minuta, te se često održavaju u
stojećem položaju prisutnih.
• Obezbeđuju transparentnost u radu, jer je svaki član
razvojnog tima u obavezi da podnese izveštaj o: problemima
koje je identifikovao, o urađenom poslu prethodnog dana i o
rezultatima koje planira da ostvariti do sutrašnjeg dnevnog
sastanka.
• Scrum master ima zadatak da beleži iznesene probleme
članova razvojnog tima, kao i da im nakon sastanka pomogne u
njihovom rešavanju.
5. Sprint review meeting (ocena sprinta)
• Događaj se odvija na kraju sprinta radi demonstriranje
rezultata ostvarenih u sprintu (inkrementa/funkcionalnosti
softverskog rešenja).
• Cilj ovog događaja je: provera izgrađenog rešenja, dobijanje
povratnih informacija i generisanje polaznih inputa za
planiranje narednog sprinta.
• Na sastanku učestvuju: članovi razvojnog tima, scrum vođa,
vlasnik proizvoda, korisnici, menadžer i ključni stejkholderi. Po
prvi put gledaju izrađene funkcionalnosti/inkrement koji je
rezultat datog sprinta.
• Sastanak podrazumeva aktivnu diskusiju svih prisutnih.
6. Sprint retrospective meeting (retrospektiva sprinta)
1. Product Backlog (lista zadataka proizvoda)
• PB je lista korisničkih zahteva koja se zapisuje u formatu
korisničke priče.
• Listu generiše vlasnik proizvoda/product owner u prvoj
projektnoj fazi, na osnovu razgovara sa korisnicima.
• Vlasnik proizvoda i razvojni tim ažuriraju ovu Listu tokom
celog perioda trajanja projekta, usled promena u korisničkim
zahtevima i to na sastanku koji se zove Grooming meeting.
• Sve korisničke priče sa liste imaju utvrđene prioritete.
Prioriteti se utvrđuju sa aspekta njihove poslovne vrednosti.
Takođe imaju i procenjen napor – effort potreban za
realizaciju.
2. Sprint Backlog (lista zadataka sprinta )
• Razvojni tim odabira stavke (korisničke priče) sa Product
backlog-a koje će implementirati u sprintu i stavlja ih na Sprint
backlog.
• Sprint backlog sadrži definisane radne zadatke za svakog
člana razvojnog tima, na kojima će raditi tokom trajanja
sprinta.
• Razvojni tim procenjuje koliko je potrebno rada (sati po
radnom danu) da bi se neki radni zadatak mogao završiti u
sprintu. Reč je o Reming work-u. Reming work svakog zadatka,
svaki član razvojnog tima mora ažurirati nakon svakog radnog
dana. Na taj način se svakodnevno prati koliko vremena je
preostalo da se završi svaki od preuzetih zadataka u timu.
• Svaki radni zadatak na sprint backlogu može imati jedan od
sledećih statusa: To-do, In progress, Done.

• Događaj na kojem učestvuje samo razvojni tim. • Sprint backlog ažurira jedino tim i to tokom celog perioda
trajanja sprinta.
• Cilj ovog sastanka je:
• Lista može biti ažurirana dodavanjem novih zadataka ili
• da se identifikuju ispravnosti/defekti u radu tokom proteklog
brisanjem zastarelih, kao i promenama statusa zadataka i
sprinta,
procenama preostalog rada.
• da se utvrdi šta je u razvojnom procesu tokom proteklog
• Status zadataka sprinta se prikazuju na sprint tabli u jednu od
sprinta bilo dobro,
tri predviđene kolone, shodno njihovom trenutnom statusu:
• da se utvrdi šta u razvojnom procesu tokom proteklog
 uraditi (To do)
sprinta nije bilo dobro,
 u toku (In progress)
• da sa zajednički odluči sa kojim dobrim praksama tim treba  završen (Done)
da nastavi,
3. Inkrement
• da sa zajednički odluči koje loše prakse treba da obustavi tim,
• Predstavlja deo funkcionalnog softverskog rešenje, koje je
• da sa zajednički odluči da li da se uvede neka nova razvio tim nakon završetka sprinta.
praksu/pravilo u timu.
• Slika (sa slajda)predstavlja razvoj Monalize kroz iterativno-
• Svrha ovog sastanka jeste da se kontiniurano povećava inkrementalni pristup.Slika je završena nakon 6 sprintova.
efikasnost rada u timu. Jedna od tehnika za vođenje ovog
Rezultat svakog sprinta je inkrement deo slike, kao jedne celine.
sastanka je STOP-START -CONTINUE
-----------------------------------------------

ARTIFAKTI
4. Sprint burndown chart
• Predstavlja dijagram toka realizacije sprinta.
• Ima za cilj praćenje napretka samoorganizujućeg Scrum tima,
shodno definisanim ciljevima sprinta.
• Izrađuje se u terminima količine preostalog posla i potrebnih
časova rada tima.
• Članovi razvojnog tima u obavezi su da svakodnevno
ažuriraju preostale sate potrebne za obavljanje posla
neophodnog za kompletiranje tekućeg zadatka.
• Ukupni časovi preostalog rada u sprintu, zbir su časova rada
svakog učesnika ponaosob.
• Suma ukupno preostalog rada svih učesnika predstavlja se na
dijagramu, kako bi svi stejkholderi mogli svakodnevno da imaju
uvid u realnu sliku toka realizacije sprinta u odnosu na
planiranu.
• Ukoliko rezultati na dijagramu nisu optimistični, tim mora
izvršiti prilagođavanja, u smislu smanjenja obima posla ili
pronalaženja efikasnijih načina rada
5. Release Burndown chart
• Artifakt prati tok realizacije release-a tj. isporuke verzije
softverskog rešenja.
• Pokazuje progres u realizaciji planiranog datuma njegove
proizvodnje i isporuke u produkciju.
-------------------------------------------------------------
SCRUM PROCES RAZVOJA
Tri razvojne faze:
1. Predigra (formiranje tima, grubo planiranje i definisanje
korisničkih zahteva, dizajn ključnih elemenata arhitekture).
2. Igra - razvojna faza (razvoj u okviru sprintova, poboljšanja
rešenja kroz nove sprintov, verzije softverskog rešenja).
3. Postigra (nema novih zahteva, testiranje, integracija,
konačna distribucija rešenja).
II
Tradicionalna vs Scrum metodologija
prema primarnim karakteristikama projekta
Waterfall vs Agile
Waterfall model razvoja softvera podrazumeva sekvencijalno
izvršavanje faza razvoja koje su prikazane na slici. Dok se prva
faza ne završi druga ne može da otpočne.
Agilan proces razvoja softvera podrazumeva da se sve razvojne
faze (navedene na slici) realizuju u okviru svake iteracije
(sprinta) koji traje od 2-4 nedelje.
Rezultat svake iteracije je funkcionalan i primenljiv deo
softverskog proizvoda koji se razvija i koji se isporučuje
korisniku. Na ovaj način se kumulativno razvija softverski
proizvod tj. svakom novom iteracijom se upotpunjuje.
Waterfall proces razvoja softvera podrazumeva da se tek na
kraju projekta softverski proizvod u celini isporuči
korisniku na upotrebu.
Agilan proces: isporuka delova softveskog proizvoda se vrši
nakon svake iteracije.
Waterfall proces: isporuka softverskog proizvoda u celini se
vrši na kraju projekta .
----------------------------------------------
Komparativna analiza agilnog i tradicionalnog načina
upravljanja projektima
• Opisana na narednim slajdovima, poređenjem 6 ključnih
dimenzija.
1. Definisanje proizvoda
Kako, kada i ko definiše softverski proizvod?
Kako su “uhvaćene” potrebe i očekivanja korisnika?
Kako se zahtevi prenose tehničkom timu?
Kako će tehnički tim komunicirati sa korisnicima?
Model vodopada (tradicionalni projekti)
• Korisnički zahtevi su izraženi tehničkim jezikom.
• Korisnički zahtevi su obimno dokumentovani tokom prve
faze projekta.
• Korisnici su u razvojnom procesu prisutni samo na početku
projekta.
• Na kraju faze definisanja zahteva, mogućnosti i karakteristike
budućeg sistema su u potpunosti precizirane.
• Tehnički tim sa korisnicima komunicira posredno, putem
dokumentacije koja mu se dostavlja.
Scrum
• Definisanje proizvoda se vrši putem identifikovanih
korisničkih zahteva, koji se zapisuju prirodnim jezikom u obliku
korisničkih priča:<neko> želi da radi <nešto> jer <razlog>
• Narativan stil specifikacije korisničkih zahteva je bliži i
razumljiviji korisnicima i klijentu.
• Korisničke priče se dekomponuju, a potom i detaljno opisuju
pred samu implementaciju tj. iteraciju (sprint) u kojoj će biti
realizovane (implementirane).
• Za identifikovanje korisničkih zahteva zadužen je vlasnik
proizvoda/product owner, koji iste predstavlja razvojnom timu
na samom početku projekta.
• Inicijalni set korisničkih zahteva i funkcionalnosti
proizvoda je dinamičan i menja se tokom životnog ciklusa
projekta.
• Razvojni tim tokom celog perioda trajanja projekta učestvuje
na sastancima sa vlasnikom proizvoda (Grooming backlog
meeting), na kojima se vrši ažuriranje liste korisničkih zahteva :
dodavanje novih, izmene/eliminisanje postojećih zahteva.
• Korisnici su deo Scrum tima tokom celog perioda trajanja
projekta.
• Svoj feedback o razvijenim funkcionalnostima korisnici daju
nakon svake vremenski ograničene iteracije, na događaju koji
se zove Spint Review -ocena sprinta.
2. Adaptibilnost
Kako svaka od datih metodologija radi sa promenljivim
zahtevima?
Da li metodologija preferira stabilnost ili promenljivost?
Model vodopada (tradicionalni projekti)
• Detaljno definisani korisnički zahtevi se „zaključavaju“ ranije
u životnom ciklusu projekta.
• Stabilni i sveobuhvatni zahtevi na početku projekta
omogućuju narednu razvojnu fazu: Big Design Up Front
(BDUF).
• BDUF podrazumeva razvoj celokupne softverske arhitekture
proizvoda i izradu detaljnog dizajna rešenja, koje će koristiti
programeri u fazi implementacije prilikom kodiranja.
• Promene zahteva, uvedene u kasnijim fazama projekta,
mogu imati veliki uticaj na planirano vreme i troškove.
• Svaka promena zahteva u kasnijim fazama projekta, zahteva
izradu i odobravanje dokumenta koji se naziva Nalog za
promenom. Navedeni dokument se koriste za praćenje i
raspored troškova i funkcionalnosti proizvoda.
• Ovakav pristup upravljanja projektom omogućuje definisanje
predvidivih troškova i vremenski plan/raspored razvoja
proizvoda.
• Promene u zahtevima nisu dobrodošle, jer predstavljaju rizik
da će sedefinisani troškovi i vremenski plan/raspored razvoja
proizvoda ozbiljno ugroziti.
Scrum
• Pretpostavlja se da će se inicijalno identifikovane
funkcionalnosti proizvoda (na samom početku projekta)
menjati tokom projekta.
• Promene su dobrodošle i one postaju sastavni deo liste
zahteva proizvoda (product backlog-a), koja je definisana na
početku projekta.
• Pošto se promene očekuju, onda imaju i mnogo manje efekta
na čitav projekat. U vremenski raspored se dodaju novi
sprintovi ili izdanja/release-ovi radi implementacije novih
funkcionalnosti proizvoda.
3. Vremenski plan/raspored
Koja je osnova za planiranje funkcionalnosti ili ljudi?
Kada ćete znati da li projekat „klizi“?
Model vodopada (tradicionalni projekti)
• Planiranje je prediktivno – realizuje se na početku
projekta.
• Predviđa se trajanje svake razvojne faze i zadataka u
okviru nje.
• Svaka razvojna faza se zasniva na radu i odlukama
donetim u prethodnoj fazi.
• Svaka razvojna faza zasniva se na uspešnom završetku
prethodne faze.
• Kašnjenja u realizaciji zadataka tokom neke faze, utiču na
vremenski raspored celog projekta.
• Ova metoda ne reaguje dobro na „proklizavanja“, jer su
zavisnosti između zadataka i faza često veoma kompleksne.
• Ukoliko procene na početku projekta nisu tačne,
vremenski planirani zadaci i projektne faze probiće ne samo
vremenski raspored, već i troškove projekta.
Scrum
• Planiranje je empirijsko i traje tokom celog projekta.
• Posao se planira i vremenski raspoređuje na osnovu
brzine/velocity Scrum tima.
• Procena/estimation postaje sve tačnija sa svakim
uzastopnim sprintom, jer se zasniva na stvarno završenom
poslu u okviru sprinta.
• Planiranje i vremensko raspoređivanje u Scrumu je veoma
pouzdano zbog fiksnih, vremenski ograničenih sprintova.
• Scope/obim projekta je manje pouzdan, jer
funkcionalnosti mogu da variraju tj. da ulaze i izlaze iz
predviđenih sprintova i release-a/izdanja, kako bi se tim
prilagodio fiksnom vremenskom rasporedu.
4. Ljudi
Kako su organizovani timovi?
Kada se ljudi uključuju i isključuju sa projekta?
Model vodopada (tradicionalni projekti)
• Specijalizovani timovi rade na različitim razvojnim fazama
projekta.
• Poslovni analitičari definišu sve zahteve na početku
projekta, često pre nego što se tehnički tim i uključi u
projekat.
• Kada počne faza implemetacije, poslovni analitičari imaju
smanjenu ulogu na projektu.
• Testiranje počinje nakon završetka faze implementacije, te
se tek tada formira tim za testiranje.
• Upravljanje projektom je specijalizovana uloga, često
realizovana od strane kancelarije za upravljanje projektima.
Scrum
• Jedan tim uključen je u ceo životni ciklus projekta.
• U okviru tima, postoje samo tri uloge. Rad je veoma
kolaborativan unutar i između uloga.
• Tim je samoorganizovan, a članovi tima imaju potpunu
vidljivost product backlog-a (liste zahteva proizvoda) i
obavezuju se na implementiranje preuzetog obima posla.
• Tim je uključen u planiranje, procenu, razvoj i testiranje.
• Tim je fokusiran na klijenta tokom celog projekta.
5. Dokumentacija
• Kakav oblik dokumentacije je potrebno generisati na
projektu?
• Koji alati pomažu dokumentovanje?
Model vodopada (tradicionalni projekti)
• Dokumentacija predsatvalja vladavinu prava.
• Dokumenti opisuju šta je potrebno i kako će sistem
funkcionisati.
• Na početku projekta neophodno je definisati
sveobuhvatan i detaljan dokument svih poslovnih zahteva
kao i dokument sistemskih zahteva.
• Dokumenti omogućavaju da članovi tima, nesmetano i bez
posledica po projekat, dolaze i odlaze jer su u njima
dokumentovane sve odluke na projektu.
• Dokumentacija je primarno sredstvo komunikacije između
razvojnih faza modela vodopada.
• Microsoft Project i Gantt grafikoni su alati koji se obično
koriste za dokumentovanje vremenskog rasporeda projekta.
Scrum
• Diskusija i neformalna komunikacija favorizuju se u
odnosu na formalnu dokumentaciju.
• Product backlog je agilni “dokumenat” – dinamična lista
korisničkih zahteva.
• Na početku projekta vlasnik proizvoda i članovi tima
detaljno razgovaraju o zahtevima sa produckt backloga,
definišući prioritete tj. redosled njihove implementacije.
• Sprint backlog je agilni “dokumenat” sa listom zadataka
koje će tim implementirati tokom sprinta.
• Visual Studio TFS je veoma efikasan alat za komunikaciju,
definisanje korisničkih priča, funkcionalnosti i zadataka.
---------------------------------
6. Trajanje projekta
Koje je tipično trajanje projekta?
Model vodopada (tradicionalni projekti)
• Pogodan je za razvojne projekte koji traju godinama i gde
su svi korisnički zahtevi poznati na početku projekta i
nemaju tendenciju menjanja.
• Na ovakvim projektima obično se oko 6 meseci provodi na
definisanju poslovnih zahteva, 3 - 4 meseca za definisanje
funkcionalnih zahteva, a potom 3 do 4 meseca za
definisanje tehničkog dizajna.
• Na ovom tipu projekata faza implementacije (kodiranje
rešenja) otpočinje tek nakon godinu dana od početka
projekta.
• Potom sledi faza testiranja i izrade detaljne
dokumentacije.
• Korisnik/klijent tek nakon 2-3 godine po prvi put vidi
softverski proizvod koji je poručio. Tek tada može da da
feedback o proizvodu.
Scrum
• Pogoduje projektima promenljive dužine i obima.
• Prikladan za projekte kod kojih se promene u zahtevima
korisnika normalna i česta pojava.
• Prikladan za projekte koji zahtevaju ranu isporuku
vrednosti klijentu, putem velikog broja kratkih iteracija.
• Verzija softverskog proizvoda/release obično traje od 6 -
12 meseci.
• Iteracija (sprint) traje od 2 do 4 nedelje.
• Prikladan za projekte na kojima de korisnici biti deo tima
tokom celog perioda trajanja projekta.
-----------
Metrike za merenje uspešnosti projekta
• Tradicionalne metrike:
 vreme,
 obim (scope) projekta
 budžet.
• Agilne metrike:
 transparentnost (npr. backlog, burndown chart,
velocity chart...),
  provera (sprint planning, sprint review, sprint Dakle, svaki projekat počinje fazom definisanja projekta
retrospective...) odnosno iniciranjem projekta:
 prilagođavanje (backlog re-prioritization, planiranje  uvid i vizija,
sprinta, promena zahteva i idenfikovanje rizika)  alociranje resursa projekta (angažovanje tima i
tehnologije)
 grubo planiranje.
Transparentnost
• Procesi bi trebali biti svima vidljivi i definisani zajedničkim
standardom. I Uvid i vizija

• Transparentnost i standardizacija stvaraju zajedničko • Svaki projekat razvoja softverskog proizvoda mora početi
uvidom u poslovno stanje (kako nešto trenutno radi i kako se
razumevanje tokova posla, projekta (ili proizvoda) strategije
može poboljšati razvojem novog softv. proizvoda), te
i metrika za uspeh. definisanjem vizije projekta i softv. proizvoda koji će se
• Scrum timovi koriste sledeće artefakte u cilju razvijati.
transparentnosti: • Vizija sadrži jednostavan opis ŠTA će se graditi, ZA KOGA i
ZAŠTO.
 izjava o viziji projekta/proizvoda,
• Vizija proizvoda treba da bude jasna i dovoljno sveobuhvatna
 product backlog
jer će je svi u projektnom timu čitati i razgovarati o njoj.
 sprint backlog
• Vizija treba da opiše poslovni problem koji se rešava kao i
 elektronske table zahteva, table zadataka mogućnosti i benefite od njegovog rešavanja.
 burn down chart • Vizija mora uključivati opis ciljeva i ishoda proizvoda koji se
 velocity chart želi razviti, kao i potrebe i koristi od istog, sa stanovišta
korisnika.
Provera (Inspection) • Mora da odgovara interesima svih stejkholdera: kupaca,
• Čest i ponavljajući pregled ciljeva projekta, mape sponzora i projektnog tima.
razvojnog puta i postepeni napredak prema tim ciljevima. • Vlasnik proizvoda (product owner) je uloga u Scrum timu
koja je odgovorna za uvid u to kako će korisnik
• Provera pomaže ranom otkrivanju rizika i identifikovanju ceniti/vrednovati proizvod. Šta se korisnicima dopada/ne
oblasti za poboljšanje. dopada, šta vole i šta ne vole.
• Scrum timovi koriste sledeće događaja u cilju
kontinuiranih provera: • Izjava o viziji postavlja pravac projekta tako što određuje šta
 sprint planning, će se projektom postići.
 daily scrum or stand up, • Sastavni deo vizije je i definisanje obima/granica projekta
 sprint review and retrospectives. (definition of scope).

• Glavni elementi izjave o viziji uključuju:

Prilagođavanje
1. Ciljeve projekta
• Zahvaljujući transparentnost i proveri, timovi i svi
stejkholderi su u stanju da kontinuirano procenjuju, 2. Obim projekta/scope
3. Zahteve/requirements visokog nivoa
prilagođavaju i ponovo prioritizuju poslove (zahteve i
funkcionalnosti) prema aktuelnoj potrebi korisnika/klijenta. 4. Glavne izlazi i rezultate

• Scrum timovi koriste sledeće za prilagođavanje procesa 1. Ciljevi projekta:

razvoja:
 treba da budu usklađeni sa identifikovanim
 Risk identification problemima i mogućnostima njihovog rešavanja.
 Change requests  izražavaju očekivane rezultate projekta.
 Sprint planning  trebali bi biti SMART: specifični, merljivi, usmereni
 backlog re-prioritization na akciju, realni i vremenski specificirani.
III
2. Obim projekta:
Prva projektna faza,definisanje projekta: vizija i uvid,
 dati odgovor na pitanje šta jeste/nije uključeno u
alociranje resursa (angažovanje tima i nabavka tehnologije).
projekat?
3. Zahtevi visokog nivoa:
 identifikovati najznačajnije zahteve
 istaći esencijalne u odnosu na poželjne zahteve
4. Glavni izlazi i rezultati proizvoda:
 istaći ključne funkcionalnosti proizvoda
Šablon za izradu izjave vizije proizvoda
• Za (ciljni korisnik)
• Koji (izjava o potrebi ili priliku)
• Naziv proizvoda... je.. (kategorija proizvoda)
• Koji omogućava.... (ključne prednosti, obavezujudi razlog
za njegovu kupovinu)
• Za razliku od (sličnih konkurentskih proizvoda)
• Naš proizvod (izjava o primarnoj diferencijaciji)
Primer1:
Za korisnike računara svih starosnih grupa koji žele da se druže i
održavaju kontakt sa porodicom, prijateljima i saradnicima, veb
lokacija MultiFacea je veb lokacija za društvene mreže koja
omogućava korisnicima da imaju više identifikacija. Za razliku od
tradicionalnih društvenih mreža kao što su Faceook i MiSpace, naš
proizvod omogućava korisnicima da održavaju odvojene i različite
identifikacije za različite grupe porodica, prijatelja i saradnika.
Primer 2
Za sektore marketinga i prodaje, srednje veličine, kojima je
potrebna osnovna CRM funkcionalnost, CRM-Innovator je usluga
zasnovana na Vebu, koja omogućuje funkcije za praćenje prodaje,
generisanje potencijalnih kupaca i funkcionalnosti za podršku
predstavnicima prodaje koje poboljšavaju odnose sa klijentima u
kritičnim dodirnim tačkama. Za razliku od drugih konkurentskih
softverskih proizvoda, naš proizvod pruža veoma najvažnije usluge
u sferi CRM-a, po umerenim cenama.
Obim (scope) projekta
• Viziju proizvoda obično prati i definisanje obima (scope)
projekta.
• Scope jasno određuje put za viziju, od problema do rešenja.
• Scope definiše ključne funkcionalnosti softverskog proizvoda
koji se razvija, vremenske linije i ograničenja.
• Scope treba jasno da definiše ono što ulazi u okvire projekta i
ono što je izvan granica projekta.
• Često se vizija i scope kombinuju u jednom dokumentu
vision/scope.
• Ova inicijalna faza projekta može trajati samo nekoliko sati,
dok na kompleksnijim projektima može biti potrebno i
nekoliko nedelja.
TRADICIONALNI PROJEKTI
• Obim projekta se definiše nekim dokumentom specifikacije
(npr. specifikacijom zahteva, funkcionalnim specifikacijama ili
specifikacijom programa).
Bez obzira na naziv, svi ovi dokumenti opisuju isto:
– funkcionalne i nefunkcionalne zahteve softvera.
• Dokumentacija je široka i duboka, tj. izrađuje se u inicijalnoj
fazi projekta i detaljno pokriva sve zahteve, koje je
preporučljivo ne menjati tokom vremena.
• Tradicionalno upravljanje projektima, bilo kakve promene u
obimu projekta smatra pretnjom za uspeh projekta.
AGILNI PROJEKTI
Agilni projekti razlikuju se po sledećim elementima:
 Stav prema promenama
 Dokumenti koji definišu obim/scope agilnih projekata
 Vreme izrade agilnih zahteva
 Naglasak na zahtevima visokog nivoa
Obim/scope agilnog projekta definiše se takođe u inicijalnoj
fazi projekta, ali samo zahtevima visokog nivoa.
Postavljaju se narativno u obliku korisničke priče.
Detaljni (ili duboki) zahtevi su i dalje potrebni, ali se definišu
“just in time”, tokom planiranja sprinta.
• Vlasnik proizvoda/product owner u saradnji sa korisnicima, u
inicijalnoj fazi agilnog projekta definiše korisničke priče za ceo
projekat, ali se detaljan opis zahteva, izrađuje samo za one
korisničke priče koje Će se implementirati u prvoj
iteraciji/sprintu.
• Tokom prve vremenski ograničene iteracije/sprinta, detaljno
se razrađuju korisničke priče koje će biti implementirane u
drugoj iteraciji.
• Na ovaj način ako/kada korisnici promene obim/scope
projekta, potrebno je uložiti minimalan napor da se isti i
redefiniše.
• Scope proizvoda je u agilnom razvoju promenljiva kategorija,
za razliku od tradicionalnog .
II Resursi projekta
• Izgradnja softverskog proizvoda je veoma intenzivna
aktivnost i potrebno je puno resursa za izgradnju i isporuku
kvalitetnog softverskog proizvoda.
• Ključni resursi su: vreme i novac.
• Za razliku od vremena, novac se lako može pretvoriti u druge
resurse koji su neophodni na projektu. Dva primarna resursa
potrebna za razvoj softverskog proizvoda su: ljudi i
oprema/tehnologija.
• Neophodno je razumeti šta želi kupac i koliko je spreman njihovu POSLOVNU VREDNOST na osnovu koje je definisao
da potroši novca,a onda u skladu sa tim kupovati njihove PRIORITETE u realizaciji .
tehnologiju i formirati projektni tim. • Korisnička priča najvećeg prioriteta će biti realizovana tokom
SCRUM TIM prvog sprinta.

• Tip projekta i problem koji se rešava opredeliće strukturu • Za najprioritetnije korisničke priče na product backlog-u
definišu se i KRITERIJUMI PRIHVATANJA.
Scrum tima.
• Takođe se za najprioritetnije stavke na product backlog-u
• Formiranje tima podrazumeva uključivanje 2 vrste ljudi:–
vrše i GRUBE PROCENE NAPORA (effort) potrebnog za
“generaliste” i “specijaliste”.
realizaciju svake korisničke priče.
• Najveći deo tehničkog posla na projektu obavljaju
• Najčešća tehnika je Planning pocker.
“generalisti”: inženjeri koji su kvalifikovani za kodiranje i
• Ovo doprinosi da održavanje sastanka za planiranja sprint-a
testiranje.
ne traje previše dugo vremena.
• Međutim, projekti zahtevaju u učešće ljudi
• U većini slučajeva, procene napora za realizaciju korisničkih
specijalizovanih znanja i veština, “specijaliste”:
priča de se promeniti tokom planiranja sprinta u odnosu na
– Vlasnika proizvoda koji treba da definiše skup ove grube procene tokom backlog grooming sastanka.
karakteristika proizvoda koje
Product Backlog– lista zahteva proizvoda
tačno zadovoljava potrebe klijenta/korisnika.
– Softver arhitektu, koji bi definisao arhitekturu i šablone • Svaki softverski projekat ima zahteve. Zahtev opisuje
dizajna. nešto što zainteresovano lice/stejkholder očekuje od
– Stručnjaka za korisnički interfejs proizvoda.
– Stručnjaka za baze podataka • Npr. ako vaš projekat zahteva sigurnost, imaćete sledeće
– Stručnjaka za bezbednost i performanse proizvoda. zahteve:
• Ako na projektu treba visok procenat stručnjaka/specijalista,  zahtev da svaki korisnik mora da se registruje.
a ne generalista (programera i testera), preporučljivo je u tom  zahtev da se korisnik može prijaviti sa korisničkim
imenom i lozinkom.
slučaju povećati procenu/estimiranje vremena i troškova.
 zahtev da važeća lozinka mora biti šest od više znakova i
Pronalaženje i zamena stručnjaka može zahtevati više vremena
mora sadržavati najmanje
i biti skuplja aktivnost nego zamena generalista.
 jedno slovo i jedan broj.
• Neki članovi tima će biti zaposleni – ljudi koji ostaju u  zahtev da se korisnik može odjaviti.
kompaniji i nakon projketa. Drugi de biti izvođači/pod
• Svi ovi zahtevi pišu se u formi korisničke priče i postavljaju
ugovorom - ljudi sa specijalizovanim veštinama koje su vam
se na Product backlog -u (listi zahteva). Zato se još nazivaju i
potrebni na samo određenim projektima.
Product backlog item (PBI).
Preporučljivo je da Scrum tim redovno ažurira product
TEHNOLOGIJA
backlog, stoga mora periodično da održava sastanak
• Resurs novca koristi se i za potrebnu tehnologiju na projektu,
backlog grooming meetings tokom celog projekta. Savetuje
koja se može kupiti, zakupiti ili iznajmiti za daljinski pristup.
se da timovi posvete 5% svog vremena, po sprintu, upravo
Ovo važi i za hardver i za softver.
ovoj aktivnosti
• Odabir i način angažovanja tehnologije zavisi od problema
koji se rešava i od trenutaka njegovog rešavanja na projektu. PBI=Korisnička priča
• Scrum optimizuje resurse iterativnim razvojem rešenja. To
Dobra korisnička priča sledi INVEST model:
omogućava da se planovi podešavaju tokom razvojnog puta, u
Independent
skladu sa realnim potrebama tima, korisnika i tehnologije.
Negotiable
IV Valuable to user or business
Agilni korisnički zahtevi Estimable
Backlog grooming meeting Small
Testable
• Prvi događaj na koji se okupljaju vlasnik proizvoda (product
owner) i razvojni tim.
• Vlasnik proizvoda dolazi sa listom zahteva/korisničkih priča
(product backlog-om). Pretstavlja ih razvojnom timu i ističe
BACKLOG PRIORITY vs BUSINESS VALUE vs EFFORT:
• POSLOVNA VREDNOST je merilo važnosti zahteva/korisničke
priče sa stanovišta klijenta/korisnika. Poslovnu vrednost
svakog zahteva utvrđuje vlasnik proizvoda, u razgovoru sa
korisnicima/klijentom.
• PRIORITETI zahteva na product backlogu predstavljaju
redosled kojim će oni biti implementirani kroz sprintove.
• Neki zahtev može biti veoma važan za korisnika (dakle ima
visok business value), ali možda neće tehnički biti izvodljivo da
se implementira prvim sprintom, već tokom nekog kasnijeg
sprinta (dakle, imaće niži prioritet).
• Poslovna vrednost i prioritet u realizaciji zahteva može se
razlikovati.
• Razlog tome je što zim upravlja zavisnostima između zahteva
upravo definisanjem prioriteta.
• Ako stavka A zavisi od stavke B, tim bi trebao premestiti
stavku B na višu poziciju na product backlog.
• A ako stavka C zavisi od stavke B, onda bi trebalo premestiti
stavku C iznad stavke B na product backlog.
• Prioriteti stavki na backlog-u bi trebalo da u potpunosti
reflektuju njihov redosled implementacije, uzimajudi u obzir
dakle zavisnosti koje postoje između njih.
• Svaki zahtev/korisnička priča ima i treću osobinu:
NAPOR/EFFORT koji tim procenjuje da je potrebno uložiti za
njegovu implementaciju.
• Effort je gruba procena članova razvojnog tima koliko je
teško izgraditi neku funkcionalnost.
• Procena nije u vremenu ili novcu;.
• U pitanju je relativna procena potrebnog napora.
• Postoji više agilnih tehnika za procenu napora.
• Najčešća tehnika u praksi je Planning pocker.
Acceptance criteria
• Kriterijumi prihvatanja su uslovi koji moraju biti ispunjeni
kako bi se korisnička priča nakon implementacije u sprintu
smatrala završenom.
• Odličan je alat za komuniciranje vlasnika proizvoda sa
razvojnim timom po pitanju toga šta to znači da je korisnička
priča “završena”.
• Ako pitate 10 zrelih Agilnih timova: "Kako znate kada ste
završili implementaciju neke korisničke priče sa backlog-a?
Dobićete isti odgovor od svih:- definisanjem i korišćenjem
dobro napisanih kriterijuma prihvatanja!!!
• Moć kriterijuma prihvatanja leži u činjenici da vlasnik
proizvoda i tim grade zajedničko shvatanje šta to znači da je
nešto “urađeno”.
• Kriterijumi se definišu na prvom događaju – Grooming
backlog meeting.• Sarađujući zajednički na kriterijima
prihvatanja, tim minimizira rizik da nije razumeo zahtev.
• Povećava se verovatnoća da de isporučiti funkcionalnosti
proizvoda koje očekuje korisnik.
• Odlična su osnova za definisanje zadataka sprinta, kao i
testova.
Primeri korisničke priče i kriterijuma prihvatanja
KORISNIČKA PRIČA:
Kao učesnik konferencije, želim biti u mogućnosti da se
registrujem putem interneta, tako da mogu efikasnije da se
registrujem i smanjim papirologiju.
KRITERIJUMI PRIHVATANJA:
 Korisnik ne može završiti registraciju bez punjavanja
svih obaveznih polja na obrascu.
 Informacije sa obrasca se čuvaju u bazi podataka, u
tabeli za registraciju.
 Postoji zaštita od neželjene pošte (spam).
 Korisnici mogu platiti kreditnom karticom.
 Korisniku se nakon uspešne registracije šalje E-mail za
potvrdu iste.
Definition of ready vs definition of done
Definition of ready
• Definicija spremnosti (definition of ready) je koncept koji
podrazumeva da se definiše lista uslova koje treba da zadovolji
svaka korisnička pre njene implementacije.
• Sprint ne može da počne ako korisnička priča ne zadovoljava
ovaj set uslova.
Primer:
 Pravilno definisana korisnička priča
 Definisani kriterijumi prihvatanja korisničke priče
 Identifikovane zavisnosti između korisničkih priča
 Izvršena procena napora implentacije korisničke priče
 Članovima tima je jasno koja funkcionalnost treba da bude
rezultat sprinta
• Definition of ready može biti definisan za:
 Korisničke priče
 Sprint
 Release
Definition of done
• Definition of done je lista uslova koju korisničke priče treba
da zadovolje nakon sprinta (implementacije).
• Ova lista je odličan alat za komunikaciju svih učesnika na
projektu, jer su svi na početku sprinta upoznati sa ovim
uslovima.
• Čekiranjem ispunjenosti ovih uslova, tim može reći da je
uspešno završio implementaciju neke korisničke priče.
• Definisani uslovi pretstavljaju standard koji se definiše na
početku projekta i koji važi za sve sprintove i sve korisničke
priče.
• Definition of done može biti definisan za:
Korisničke priče Sprint Release