2.2.1 Slapovni model
Slapovni model (angl. Waterfall model) temelji na zaporedju faz, ki jih je potrebno izvesti za uspeˇsno zgraditev programske opreme. Iz ene faze v drugo lahko prehajamo le, ˇce je predhodna faza uspeˇsno konˇcana. Vraˇcanje nazaj ni mogoˇce. Od tu tudi ime slapovni model, ker ponazarja izlivanje slapa v reko [1].
Faze se v tem modelu ne prekrivajo. Takˇsen model je moˇcno omejen.
Zaradi vse veˇcje potrebe po spremembah med samim procesom razvoja so model nadgradili in vanjo vkljuˇcili povratno informacijo v obliki testiranja.
Tak model je primeren za manjˇse projekte s statiˇcno strukturo, pri katerih lahko zagotovimo, da skozi faze razvoja ne bo priˇslo do kakrˇsnihkoli spre-memb.
Zaporedne faze v slapovnem modelu so naslednje [1]:
Analiza in zbiranje zahtev(angl. Requirement Analysis). V tej fazi so zajete vse moˇzne zahteve sistema razvoja dokumentirane v doku-mentu specifikacij zahtev.
Oblikovanje sistema (angl. Design). Najprej se preuˇcijo zahteve iz prve faze. Na podlagi tega se pripravi oblikovanje sistema, kar pa
Slika 2.2: Faze slapovnega modela
pomaga pri specifikaciji strojnih in sistemskih zahtev ter definiranju celotne arhitekture sistema.
Razvoj (angl. Implementation). Z vhodom iz prejˇsnje toˇcke najprej razvije manjˇse programe, ki jih imenujemo enote. Te so potem integri-rane v naslednjo fazo. Vsaka enota je razvita in preizkuˇsena za svojo funkcionalnost. Ta proces imenujemo “testiranje enote”.
Testiranje(angl. Testing). Vse enote razvite v fazi implementacije so v tej fazi integrirane v sistem. Po integraciji se celoten sistem testira za morebitne napake.
Vzdrˇzevanje sistema (angl. Maintenance). Pri stranki se pojavijo nekatere teˇzave, ki jih je potrebno popraviti. Za odpravo teˇzav se namestijo popravki. Za izboljˇsanje programske opreme so izdane nove verzije. Opravi se faza vzdrˇzevanja, ki zagotovi te spremembe
Prednosti slapovnega modela sta predvsem preprosta in enostavna upo-raba. V tem modelu so vse faze in rezultati dobro dokumentirani. Slabost je, da med razvojem ni interakcije s strankami. Zaradi zaporednega razvoja paralelni rezultati niso moˇzni. V primeru sprememb produkta po razvoju so
stroˇski viˇsji, kakor tudi porabljen ˇcas, ker moramo posodobiti od dokumenta do kode.
2.2.2 Prototipni model
V prototipnem modelu (angl. Prototyping Model) je bistvo izdelave pro-totipov programske opreme, ki so nepopolne verzije [37]. Prototip obiˇcajno vsebuje osnovne funkcionalnosti in je lahko popolnoma drugaˇcen od konˇcnega produkta. Uporabniki so vseskozi aktivni v procesu razvoja in tako razvijalci dobijo ˇze v zaˇcetni fazi projekta povratne informacije. Prototip pomaga pri opredelitvi zahtev za konˇcen produkt.
Pri prototipnem modelu loˇcimo veˇc vrst. Evolucijski oz. razvojni prototip (angl. Evolutionary prototype) se dopolnjuje s funkcionalnostmi do konˇcnega produkta. V drugem primeru se prototip zavrˇze (angl. Throwaway proto-type). Uporabljen je bil samo za natanˇcno opredelitev uporabniˇskih zahtev.
Proces modela vkljuˇcuje naslednje korake [37]:
1. Doloˇcitev osnovnih zahtev.
2. Razvoj zaˇcetnega prototipa.
3. Pregled s strani stranke in posredovanje povratne informacije o more-bitnih dopolnitvah ali spremembah.
4. Pregled povratnih informacij stranke in izboljˇsava prototipa.
Prednost prototipnega modela je med drugim tudi, da je mogoˇce odkriti napake ˇze v zgodnji fazi razvoja. Laˇzje je prepoznati manjkajoˇce funkcio-nalnosti, kar pomaga pri zmanjˇsevanju tveganja za neuspeh. Po drugi strani pa je izdelava prototipov poˇcasen in dolgotrajen proces. Izdelava prototipov lahko spodbudi pretirane zahteve po spremembah pri uporabnikih [54].
2.2.3 Model hitrega razvoja programske opreme
Model hitrega razvoja programske opreme (angl. Rapid Application Deve-lopment — RAD) je oblika agilnega razvoja programske opreme, ki jo je
izumil James Martin leta 1991 [33]. ˇZelel se je odzvati na omejitve pri sla-povnem modelu. Za razliko od slapovnega modela RAD ponuja iterativnost, ki podpira izdelavo prototipov, ter z njim omogˇca povratne informacije upo-rabnikov [2].
Pristop Jamesa Martina deli proces RAD modela na ˇstiri razliˇcne faze [33]:
1. Naˇcrtovanje zahtev(angl. Requirements planning) — zdruˇzuje ana-lizo in naˇcrtovanje zahtev. Faza se zakljuˇci, ko se ekipa dogovori o kljuˇcnih vpraˇsanjih in pridobi odobritev vodstva za nadaljevanje.
2. Funkcionalna zasnova (angl. User design) — v tej fazi uporabniki sodelujejo s sistemskimi analitiki in razvijajo prototip, ki pokriva vse sistemske procese in zadosti potrebam uporabnikov.
3. Izvedba(angl. Construction) — se osredotoˇca na razvoj konˇcne reˇsitve v sodelovanju z uporabniki. ˇSe vedno se lahko predlagajo spremembe ali izboljˇsave.
4. Uvajanje (angl. Cutover) — vsebuje migracijo podatkov, testiranje, prehod na nov sistem in izobraˇzevanje uporabnikov.
V tem modelu so funkcije, komponente razvite hkrati kakor, da bi bila vsaka zase majhen projekt. Hiter razvoj se v glavnem osredotoˇca na zbi-ranje zahtev skozi pomoˇcjo fokusnih skupin in delavnic, zgodnje testiranje prototipov z uporabo iterativnega koncepta in s ponovno uporabo kompo-nent in prototipa ter s tem hitro dostavo. V tem modelu ni predhodnega naˇcrtovanja, zato so spremembe laˇzje izvedljive znotraj razvojnega procesa.
RAD sledi inkrementalnemu in iterativnemu modelu in ima majhne ekipe, ki jih sestavljajo razvijalci, predstavniki strank in drugi s podroˇcja IT, ki postopno delajo na prototipu [38].
Prednosti so spreminjanje zahtev, ponovna uporaba komponent, ki ˇze ob-stajajo, ter skrajˇsan ˇcas razvoja. Stranka lahko tudi meri napredek razvoja.
Slabosti pa sta, da ta model zahteva usposobljene oblikovalce ter da je zelo odvisen od tehniˇcne ekipe, ki mora najti poslovne zahteve [2].
2.2.4 Spiralni model
Spiralni model (angl. Spiral Model) je meˇsanica ˇcistega strukturiranega in fleksibilnega prototipnega modela, ki zagotavlja tudi podporo pri obvladova-nju tveganj [12]. V svojem diagramskem prikazu je ponazorjen kot spirala s ˇstevilnimi zankami.
Natanˇcno ˇstevilo zank spirale ni znano in je odvisno od projekta. Vsako zanko spirale imenujemo faza postopka razvoja programske opreme. Na-tanˇcno ˇstevilo faz, potrebnih za razvoj izdelka, lahko vodja projekta spre-minja glede na projektna tveganja. Ker vodja projektov dinamiˇcno doloˇca ˇstevilo faz, ima vodja projekta pomembno vlogo pri razvoju izdelka z uporabo spiralnega modela. Polmer spirale na kateri koli toˇcki predstavlja dosedanje stroˇske projekta, kotna dimenzija pa predstavlja dosedanji napredek v tre-nutni fazi.
Vsaka faza spiralnega modela je razdeljena na ˇstiri kvadrante, kot je pri-kazano na sliki 2.3. Funkcije teh ˇstirih kvadrantov so naslednje [12]:
Doloˇcitev ciljev in doloˇcitev alternativnih reˇsitev. Zahteve so zbrane, cilji pa opredeljeni, izdelani in analizirani na zaˇcetku vsake faze.
Nato so v tem kvadrantu predlagane moˇzne reˇsitve za fazo.
Ugotovite in obvladovanje tveganja. V drugem kvadrantu se oce-nijo vse moˇzne reˇsitve, izbere se najboljˇsa moˇzna reˇsitev. Nato se ugo-tovijo tveganja, povezana s to reˇsitvijo, in ta se reˇsijo z najboljˇso moˇzno strategijo. Na koncu tega kvadranta je zgrajen prototip za najboljˇso moˇzno reˇsitev.
Razvoj naslednje verzije produkta. Med tretjim kvadrantom se prepoznane funkcionalnosti razvijejo in preverijo s testiranjem. Na koncu tretjega kvadranta je na voljo naslednja razliˇcica programske opreme.
Pregled in naˇcrtovanje naslednje faze. V ˇcetrtem kvadrantu stranka oceni do zdaj razvito razliˇcico programske opreme. Na koncu se zaˇcne
Slika 2.3: Spiralni model naˇcrtovanje naslednje faze.
Prav gotovo je prednost spiralnega modela obvladovanje tveganja. Pri-poroˇca se pri velikih in kompleksnih projektih. Tudi kasnejˇse zahteve se lahko natanˇcno vkljuˇcijo s tem modelom. Stranka lahko vidi razvoj produkta v zgo-dnji fazi razvoja programske opreme in se lahko seznani z njim in njegovo uporabo pred dokonˇcanjem celotnega izdelka. Po drugi strani pa je spiralni model veliko zapletenejˇsi kot drugi modeli SDLC. Spiralni model ni primeren za majhne projekte, saj je drag. Uspeˇsen zakljuˇcek projekta je v veliki meri odvisen od analize tveganja. Brez zelo izkuˇsenega strokovnega znanja razvoj projekta ne bo uspeˇsen po tem modelu. Tudi ocenjevanje ˇcasa je zelo teˇzko,
ker ˇstevilo faz na zaˇcetku projekta ni znano.
2.2.5 Ekstremno programiranje
Ekstremno programiranje (angl. Extreme Programming – XP) je model ra-zvoja programske opreme, ki ga je v prvi vrsti razvil Kent Beck [9]. Ek-stremno programiranje postavi tradicionalne metode na stran. Raje kot planiranje, analiziranje in oblikovanje za daljno prihodnost, XP izkoriˇsˇca zmanjˇsevanje stroˇskov na naˇcin, da se vse te aktivnosti izvajajo po malem skozi celoten proces razvoja programske opreme [8].
Razvojni cikel v ekstremnem programiranju se zaˇcne tako, da stranka iz-bere funkcionalnosti, ki se v XP imenujejo zgodbe (angl. stories) za naslednjo iteracijo. Stranka je obveˇsˇcena o stroˇskih zgodb in hitrostjo ekipe. Razvijalci vsako zgodbo razdelijo na manjˇse naloge, za katere individualno prevzamejo odgovornost. Nato razvijalec spremeni nalogo v niz testov, ki bodo pokazali, da je naloga konˇcana. Razvijalec v sodelovanju s partnerjem razvija in izvaja testne primere, pri tem pa skrbi, da se ohranja ˇcim preprostejˇsi model [8].
Spodaj so naˇstete nekatere glavne prakse ekstremnega programiranja [8]:
- Igra naˇcrtovanja (angl. Planning game). Stranka doloˇci obseg in ˇcas dostave na podlagi ocen razvijalcev. Razvita je samo tista funkcional-nost, ki jo zahtevajo zgodbe v tej iteraciji.
- Majhne izdaje (angl. Small releases). Nove izdaje so pogoste – od dnevnih do meseˇcnih.
- Preprost model (angl. Simple design). V vsakem trenutku lahko model izvede vse teste, ne vsebuje podvojene kode in ima ˇcim manj razredov in metod, kolikor je to mogoˇce.
- Testi (angl. Tests). Razvijalci vseskozi piˇsejo enotske teste (angl.
unit tests). Stranka napiˇse funkcijske teste (angl. functional tests) za zgodbe v iteraciji.
- Prestrukturiranje programske kode(angl. refactoring). Oblika se razvija s transformacijami obstojeˇcega sistema.
- Programiranje v paru(angl. Pair programming). Vso produkcijsko kodo piˇseta dva ˇcloveka za istim zaslonom/tipkovnico/miˇsko.
- Nenehna integracija (angl. Continuous integration). Integracija nove kode v trenuten sistem ne traja veˇc kot nekaj ur.
- Skupno lastniˇstvo (angl. Collective ownership). Vsak razvijalec lahko izboljˇsa kodo kjerkoli, ˇce se pojavi prilika za to.
- Samo pravila (angl. Just rules). Ekipa se zavezuje, da bo sledila pravilom, ampak to so ˇse vedno pravila. Ekipa jih lahko kadarkoli spremeni, dokler se vsi strinjajo, kako bodo ocenili uˇcinke spremembe.
Ekstremno programiranje je zelo uporabno pri majhnih projektih z majh-nimi razvojmajh-nimi ekipami. Primeren pa je tudi za projekte, ki vkljuˇcujejo novo tehnologijo ali raziskovalne projekte [28].
2.2.6 Funkcijsko voden razvoj
Funkcijsko voden razvoj (angl. Feature Driven Development – FDD) je agilna metodologija, ki, kot ˇze ime predlaga, v center postavi razvoj funkcional-nosti, kljub temu da funkcionalnosti v FDD kontekstu niso nujno funkcio-nalnosti produkta v sploˇsno razumljivem pomenu. Le-te so bolj podobne uporabniˇskim zgodbam v Scrumu. Z drugimi besedami, “dokonˇcaj postopek prijave” se lahko ˇsteje za funkcionalnost v metodologiji FDD [31].
FDD je bil zasnovan tako, da sledi petstopenjskemu razvojnemu procesu, ki je bil v veliki meri zasnovan na diskretnih “funkcionalnostnih” projektih.
Zivljenjski cikel projekta je videti tako [31]:ˇ - Razvoj sploˇsnega modela.
- Sestavitev seznama funkcij.
- Naˇcrt funkcionalnosti.
- Oblikovanje funkcionalnosti.
- Gradnja funkcionalnosti.
Prednosti FDD je preprost petstopenjski proces, ki omogoˇca hitrejˇsi ra-zvoj. Veˇcjim skupinam omogoˇca premikanje naprej produkta z neprekinje-nim uspehom. Uporablja vnaprej doloˇcene razvojne standarde, zato lahko razvojne ekipe hitro napredujejo [31].
2.2.7 Model AUP
Model AUP (angl. Agile Unified Process) je poenostavljena razliˇcica modela RUP (angl. Rational Unified Process — RUP), ki ga je ustvaril Scott W.
Ambler. Opisuje preprost in razumljiv pristop k razvoju programske opreme za poslovne aplikacije z uporabo agilnih tehnik in konceptov, vendar ˇse vedno ostaja zvest modelu RUP [4].
AUP temelji na naslednjih naˇcelih [4]:
- Veˇcina ljudi ne bo brala podrobne dokumentacije, vendar pa bodo obˇcasno potrebovali usmerjanje in usposabljanje.
- Projekt naj bo preprosto opisan na nekaj straneh.
- Model AUP se zgleduje po vrednotah in naˇcelih manifesta agilnosti.
- Projekt se mora osredotoˇcati na dejavnosti, ki dejansko ˇstejejo, in ne nepotrebne funkcionalnosti.
- Razvijalci morajo biti svobodni pri uporabi orodij, ki so najprimernejˇsi za zadano nalogo.
- AUP je enostavno prilagoditi s pomoˇcjo obiˇcajnih orodij za urejanje HTML.
AUP je zajet v ˇstiri faze [4]:
1. Zaˇcetek(angl. Inception). Cilj je identificirati zaˇcetni obseg projekta, potencialno arhitekturo za sistem ter pridobiti zaˇcetno financiranje pro-jekta in sprejetje s strani stranke.
2. Izdelava (angl. Elaboration). Cilj je dokazati arhitekturo sistema.
3. Konstrukcija(angl. Construction). Cilj je redno in iterativno graditi delujoˇco programsko opremo, ki bo ustrezala prioritetnim potrebam stranke.
4. Prehod (angl. Transition). Cilj je preveriti in uvesti produkt v pro-dukcijsko okolje.
Discipline se izvajajo na iterativen naˇcin, pri ˇcemer opredeljujejo dejav-nosti, ki jih izvaja razvojna ekipa za izgradnjo, validacijo in dostavo delujoˇce programske opreme, ki ustreza potrebam stranke. Te discipline pa so nasle-dnje [4]:
Model(angl. Model). Cilj te discipline je razumeti poslovanje stranke, problematiˇcna podroˇcja, ki ga projekt obravnava, in identificirati izve-dljivo reˇsitev za reˇsevanje problematike.
Test(angl. Test). Cilj te discipline je izvesti objektivno vrednotenje za zagotavljanje kakovosti. To vkljuˇcuje iskanje napak, preverjanje delo-vanja sistema kot je zasnovano in preverjanje, ali so zahteve izpolnjene.
Namestitev (angl. Deployment). Cilj te discipline je naˇcrtovati do-stavo sistema in izvesti naˇcrt, da bo sistem na voljo konˇcnim uporab-nikom.
Upravljanje konfiguracij (angl. Configuration Management). Cilj te discipline je upravljanje dostopa do artefaktov (angl. artifacts) pro-jekta. To ne vkljuˇcuje samo sledenje razliˇcicam artefaktov skozi ˇcas, temveˇc tudi nadzor in upravljanje sprememb le-teh.
Vodenje projektov(angl. Project Management). Cilj te discipline je usmerjanje aktivnosti, ki se odvijajo na projektu. To vkljuˇcuje upra-vljanje tveganj, usmerjanje ljudi (dodeljevanje nalog, spremljanje na-predka itd.) ter usklajevanje z ljudmi in sistemi izven obsega projekta, da se zagotovi, da bo produkt dostavljen pravoˇcasno in v okviru fi-nanˇcnega naˇcrta.
Okolje(angl. Environment). Cilj te discipline je, da se projekt izvaja v okolju, ki je dovolj primerno za zagotovitev uspeha na projektu, npr. da so vzpostavljeni ustrezni postopki, da so na voljo standardi in smernice ter da ima ekipa ustrezno strojno in programsko opremo za dokonˇcanje projekta.
2.2.8 Scrum metoda
Scrum je agilna metoda za vodenje in nadzor razvoja programske opreme, ki uporablja iterativne in inkrementalne pristope [42]. Kljuˇcno naˇcelo Scruma je dvojno spoznanje, da bo stranka v ˇcasu razvoja spremenila svoje ˇzelje in/ali potrebe (pogosto to imenujemo nestanovitnost zahtev) in da bo priˇslo do nepredvidljivih izzivov, za katere napovedni ali naˇcrtovani pristop ni pri-meren. Scrum kot tak uporablja empiriˇcni pristop, ki temelji na dokazih, saj sprejema, da teˇzave ni mogoˇce popolnoma razumeti ali definirati vnaprej, in namesto tega se osredotoˇca na to, kako maksimirati sposobnost ekipe za hitro izvedbo, odzivanje na nastajajoˇce potrebe, prilagajanje razvijanju teh-nologije in spremembe trˇznih razmer [48].
Scrum definira tri glavne vloge za zagotavljanje optimalne komunikacije med ˇclani ekipe, medtem ko imajo ˇstevilne organizacije pri doloˇcanju in do-stavi izdelka ˇse druge vloge. Scrum doloˇca le te tri [48]:
Lastnik izdelka (angl. Product owner) je odgovoren za seznam zahtev, pre-tvorbo le-teh v prednostni seznam in odloˇcanje, katere zahteve bodo na vrhu seznama za naslednjo iteracijo (angl. Sprint). S prioritiziranjem zahtev skrbi za maksimizirano dodano vrednost (angl. Return on
In-vestment — ROI) projekta. V nekaterih primerih sta lastnik izdelka in stranka ista oseba. To po navadi velja za interne aplikacije. V drugih primerih predstavlja stranko na milijone ljudi z razliˇcnimi potrebami.
V tem primeru pa je vloga lastnika izdelka podobna vlogi produktnega vodje ali vodji trˇzenja izdelkov. Kakorkoli, vloga lastnika izdelka se razlikuje od produktnega vodje v tem, da lastnik izdelka aktivno in pogosto komunicira z razvojno ekipo, pregleduje rezultate na koncu vsake iteracije in ne delegira razvojnih odloˇcitev projektnemu vodji.
Pomembno je omeniti, da je v Scrumu ena sama oseba, ki ima vlogo lastnika izdelka in je odgovorna, koliko bo delo vredno.
Razvojna ekipa (angl. Development team) skrbi za razvoj in dostavo funk-cionalnosti razvitih na osnovi uporabniˇskih zgodb na koncu vsakega sprinta. Ekipa po navadi ˇsteje sedem ljudi, plus minus dva ˇcloveka, medtem ko so ˇclani ekipe lahko razvijalci. Izraz se nanaˇsa na vsakogar, ki igra vlogo pri razvoju in podpori sistema ali izdelka in lahko vkljuˇcuje med drugim raziskovalce, arhitekte, oblikovalce, strokovnjake za po-datke, statistike, analitike, inˇzenirje, programerje in testerje. Ekipi se mora omogoˇciti, da se samoorganizira, torej sama razdeljuje delo med ˇclane. V Scrumu je ekipa najproduktivnejˇsa in najuˇcinkovitejˇsa, ˇce dela med iteracijo stoprocentno na enem izdelku in se izogiba delu na veˇc izdelkih ali veˇc projektih hkrati. Stabilne ekipe, ki ne menjujejo ˇclanov, so povezane z veˇcjo produktivnostjo.
Skrbnik metodologije (angl. Scrum master) je odgovoren za odstranje-vanje ovir pri ekipi in skrbi, da ekipa uresniˇci cilje in dostavi rezultate.
Scrum master ni tradicionalno vodja ekipe ali vodja projekta, ampak deluje kakor vmesnik med ekipo in morebitnimi moteˇcimi vplivi. Za-gotavlja, da ekipa sledi dogovorjenim procesom znotraj ogrodja Scrum, in spodbuja ekipo k izboljˇsanju.
Usposablja ekipo v skladu z naˇceli Scrum za zagotovitev kakovosti pro-dukta. Spodbujanje samoorganizacije znotraj ekipe, pomaga pri
od-Slika 2.4: Razvojni proces Scrum
stranjevanju ovir za napredek. Organizira skupinske dogodke za za-gotovitev rednega napredka. Eden od naˇcinov, kako se vloga Scrum masterja razlikuje od vodje projektov je, da ima slednji lahko odgo-vornost za upravljanje ljudi in dodeljuje naloge, Scrum master pa ne.
Scrum metoda formalno ne prizna vloge vodje projekta, ker ta ni po-trebna. Tradicionalne odgovornosti vodje projekta so razporejene med tri Scrum vloge.
Prvi korak v Scrumu je, da lastnik izdelka artikulira vizijo izdelka. Rezul-tat se razvije v prednosten seznam zahtev (angl. Product Backlog). Seznam se razvija skozi ˇzivljenjsko dobo izdelka in predstavlja zemljevid izdelka. Ob-staja samo en tak seznam. To pomeni, da more lastnik izdelka doloˇcati pri-oritete, zastopati interese deleˇznikov in upoˇstevati vpliv razvojne ekipe [48].
Razvoj poteka cikliˇcno v iteracijah (angl. Sprint) [48]. Posamezna ite-racija ne traja veˇc kot mesec dni in se izvajajo ena za drugo brez premora.
Sprinti so ˇcasovno omejeni. To pomeni, da se zaˇcnejo in konˇcajo na doloˇcen datum, ne glede na to, ali je bilo delo konˇcano. Nikoli se ne podaljˇsajo. Med
ciklom ni dovoljena nobena sprememba, ki bi ogrozila cilj cikla (angl. Sprint Goal).
Na zaˇcetku vsake iteracije si ekipa izbere elemente iz prednostnega se-znama zahtev. To poteka na sestanku za naˇcrtovanje iteracije (angl. Sprint Planning Meeting). Ekipa se zavezuje, da bo elemente dokonˇcala do konca iteracije. Posamezne elemente se razbije v seznam nalog (angl. Sprint Backlog).
Ko se Sprint zaˇcne, se ekipa udeleˇzuje dnevnih sestankov (angl. Daily Scrum). To je kratek sestanek, ki traja 15 minut ali manj, in poteka vsak delovni dan ob dogovorjenem ˇcasu. Udeleˇzijo se ga vsi ˇclani razvojne ekipe.
Na sestanku vsak ˇclan poroˇca o treh stvareh [48]:
1. Kaj so uspeli narediti od zadnjega sestanka?
2. Kaj nameravajo narediti do naslednjega sestanka?
3. So pri svoje delu naleteli na morebitne prepreke?
Iteracija se zakljuˇci s sestankom za pregled rezultatov (angl. Sprint Re-view meeting), na katerem je prisotna celotna Scrum ekipa, poleg tega pa je lahko prisotna tudi stranka, deleˇzniki, strokovnjaki in vsi drugi zainteresi-rani. To je tudi ˇcas, za poglobljen pogovor med razvojno ekipo in lastnikom izdelka, da se pregleda situacijo na strani lastnika izdelka in na strani ra-zvojne ekipe. Sestanek vkljuˇcuje tudi demonstracijo, kaj je ekipa naredila med iteracijo.
Pregledu sledi retrospektiva (angl. Sprint Retrospective meeting), ki jo organizira skrbnik metodologije. Na tem sestanku celotna ekipa razpravlja o pravkar konˇcani iteraciji in ugotavlja, kaj bi lahko spremenili na naslednji iteraciji, da bi bila ta boljˇse izvedena in produktivnejˇsa.
2.2.9 Metoda Kanban
Kanban je bil prvotno del Toyotinega proizvodnega sistema v petdesetih letih prejˇsnjega stoletja, ki se ravna po konceptu Ravno ob pravem ˇcasu