Životni ciklus i metodologije razvoja

Šta učimo ovog semestra

Petnaest sedmica, svaka s tri časa teorije i tri časa prakse. Danas: poglavlje 2 (Sedmica 2, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001 (24,50 €).

Literatura

1. B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
2. J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
3. L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
4. D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
5. V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.

Priča za početak

Zašto ovo poglavlje

U poglavlju 1 vidjeli smo da sistemi propadaju kad se prava pitanja postave prekasno. Ovo poglavlje odgovara na pitanje kojim redom se ta pitanja postavljaju i kako tim organizuje posao od ideje do sistema koji radi. Prvo upoznajemo faze kroz koje prolazi svaki sistem i najstariji način da se one poredaju, vodopad. Zatim agilni pristup i Scrum, koji danas koristi većina timova. Na kraju Kanban, DevOps i alate koje programeri koriste kroz cijeli ciklus. Na praktičnoj nastavi pravimo tablu zadataka za DeliveryApp na GitHubu i planiramo prvi sprint.

Riječi ovog poglavlja (1/3)

• Životni ciklus sistema – sve faze kroz koje sistem prolazi, od ideje do gašenja.
• Metodologija razvoja – dogovoren način kojim tim redom i u kojim koracima radi posao.
• Vodopad – metodologija u kojoj faze idu jedna za drugom, bez vraćanja.
• V-model – vodopad u kojem svaka faza projektovanja ima svoj par u fazi provjere.
• Iteracija – jedan kratki krug rada na kraju kojeg imamo nešto što se može pokazati.
• Inkrement – komad sistema koji radi i dodaje se prethodnim komadima.

Riječi ovog poglavlja (2/3)

• Agilni razvoj – pristup u kojem se sistem pravi u kratkim iteracijama, uz stalan razgovor s korisnikom.
• Scrum – najpoznatija agilna metodologija: sprintovi, tri uloge i pet događaja.
• Sprint – iteracija u Scrumu, obično od jedne do četiri sedmice.
• Backlog – lista svega što treba napraviti, poredana po važnosti.
• Kanban – metoda u kojoj se posao vidi na tabli s kolonama i ograničava koliko se radi odjednom.
• WIP ograničenje (work in progress) – najveći broj zadataka koji smiju biti „u radu” istovremeno.

Riječi ovog poglavlja (3/3)

• DevOps – način rada u kojem razvoj i održavanje sistema rade kao jedan tim i automatizuju isporuku.
• Kompajler, povezivač, debager – programi koji pretvaraju izvorni kod u izvršni program i pomažu da se pronađe greška.

Ciljevi poglavlja

Nakon poglavlja možete:

nabrojati faze životnog ciklusa sistema i za svaku reći šta nastaje; opisati vodopad i V-model i navesti kada su dobar izbor; objasniti razliku između iterativnog i inkrementalnog razvoja; navesti četiri vrijednosti agilnog manifesta; opisati tri uloge, tri artefakta i pet događaja Scruma; izračunati koliko sprintova treba za backlog ako je poznata brzina tima; objasniti Kanban tablu i WIP ograničenje i izračunati prosječno vrijeme zadatka po Littleovom zakonu; reći šta je DevOps; nabrojati sistemske programske alate od editora do debagera; za dati projekat obrazložiti izbor metodologije; napraviti GitHub Projects tablu i plan prvog sprinta za DeliveryApp.

Plan poglavlja – Sedmica 2: tri časa teorije i tri časa praktične nastave

2.1 Faze životnog ciklusa

Svaki informacioni sistem, od male aplikacije do bankarskog sistema, prolazi kroz iste faze. Zovemo ih životni ciklus razvoja sistema (engleski systems development life cycle, SDLC). Faze se mogu raditi jednom, redom, ili mnogo puta u malim krugovima, ali posao u njima je uvijek isti.

2.1 Faze životnog ciklusa

2.1 Faze životnog ciklusa

Faze lako pamtimo uz gradnju kuće. Planiranje je odluka da gradimo i koliko imamo novca. Analiza je razgovor s porodicom o sobama. Projektovanje je arhitektov nacrt. Implementacija je zidanje. Testiranje je tehnički prijem kuće: da li curi krov, da li radi struja. Isporuka je useljenje. Održavanje je krečenje i popravka bojlera narednih trideset godina.

Posljednja faza najčešće traje najduže i najviše košta. Sistem koji je napravljen za godinu dana može se koristiti i deset godina, a za to vrijeme mijenjaju se zakoni, cijene, uređaji i želje korisnika. Zato se dobar projektant pita i „kako će se ovo mijenjati za pet godina?”, a ne samo „kako ovo napraviti do roka?”.

Ukratko – 2.1 Faze životnog ciklusa

• Svaki sistem prolazi kroz planiranje, analizu, projektovanje, implementaciju, testiranje, isporuku i održavanje.
• U svakoj fazi nastaje nešto konkretno: vizija, zahtjevi, modeli, kod, testovi, sistem u radu, nove verzije.
• Održavanje najčešće traje najduže, pa se sistem projektuje i za promjene koje će doći.

2.2 Vodopad

Najstariji i najjednostavniji način da se faze poredaju je vodopad (engleski waterfall). Faze idu jedna za drugom, kao voda niz stepenice: kad se završi analiza, počinje projektovanje, i u analizu se više ne vraća. Na kraju svake faze nastaje dokument koji se odobri i „zamrzne”, i on je ulaz u sljedeću fazu.

Vodopad ima prave prednosti:

• jasno je šta se radi kada i ko je odgovoran;
• lako se planira budžet i rok;
• dokumentacija je potpuna, što je važno kad sistem pregledaju nadležni organi (npr. softver za medicinske uređaje, avione, željeznicu).

Ali ima i ozbiljnu manu: korisnik vidi sistem tek na kraju. Ako je u analizi nešto pogrešno shvaćeno, to se otkrije tek kad je sve programirano, a to je, sjetimo se slike 1.3, najskuplji trenutak za ispravku. Pored toga, svijet se ne zaustavlja dok tim radi: za dvije godine razvoja mogu se promijeniti i zakon i tržište.

2.2 Vodopad

U priči o FBI-ju (poglavlje 1) problem je bio upravo u tome što su se zahtjevi mijenjali, a projekat je bio organizovan kao da se neće mijenjati. Vodopad radi dobro samo kad su zahtjevi jasni, stabilni i dobro poznati od početka.

Ukratko – 2.2 Vodopad

• U vodopadu faze idu jedna za drugom, a na kraju svake nastaje odobren dokument.
• Prednosti su jasan plan, budžet i potpuna dokumentacija.
• Mana je da korisnik vidi sistem tek na kraju, kad je ispravka najskuplja.
• Vodopad je dobar izbor samo kad su zahtjevi jasni i stabilni od početka.

2.3 V-model: svaka faza ima svoju provjeru

V-model je vodopad nacrtan u obliku slova V, da bi se istaklo nešto što vodopad zanemaruje: svaka faza projektovanja ima svoj par u fazi provjere. Lijeva strana slova V spušta se od opšteg ka detaljnom (zahtjevi, arhitektura, detaljan dizajn, kod). Desna strana se penje od detaljnog ka opštem i provjerava svaku lijevu fazu:

2.3 V-model: svaka faza ima svoju provjeru

Ključna ideja V-modela je da se test planira u istom trenutku kad se piše ono što test provjerava. Kad zapišemo pravilo PP-4 („od 30,00 € dostava je besplatna”), odmah zapišemo i kako ćemo ga provjeriti: narudžba od tačno 30,00 € mora imati dostavu 0,00 €, a narudžba od 29,99 € mora je platiti. Tako se nejasna pravila otkriju odmah, a ne kad tester dođe na red.

V-model se i danas koristi u industrijama gdje greška može ugroziti život: automobili, avioni, medicinski uređaji. O nivoima testiranja detaljno govori predmet Testiranje softvera, a u ovoj knjizi poglavlje 14.

Ukratko – 2.3 V-model: svaka faza ima svoju provjeru

• V-model je vodopad u kojem svaka faza projektovanja ima svoj par u fazi provjere.
• Zahtjevi se provjeravaju prihvatnim, arhitektura sistemskim, dizajn integracionim, a kod jediničnim testom.
• Test se planira u istom trenutku kad se piše zahtjev, pa se nejasnoće otkriju rano.
• V-model se koristi tamo gdje greška može ugroziti život.

Provjeri se

1. Koja faza životnog ciklusa obično traje najduže? Održavanje.
2. Kada je vodopad dobar izbor? Kad su zahtjevi jasni, stabilni i poznati od početka, a potrebna je potpuna dokumentacija.
3. Koji test u V-modelu provjerava zahtjeve korisnika? Prihvatno testiranje.

Odgovori: tipka R ili klik na zamućeno polje.

2.4 Iterativni i inkrementalni razvoj

Umjesto da cijeli sistem prođe kroz sve faze jednom, može se raditi u krugovima. U svakom krugu tim malo analizira, malo projektuje, programira, testira i pokaže rezultat korisniku. Taj krug se zove iteracija. Na kraju iteracije postoji inkrement: komad sistema koji stvarno radi i koji se dodaje prethodnim komadima.

Dvije riječi znače različito, pa ih razdvojimo:

• iterativno znači „ponavljamo i doterujemo”: prvu verziju ekrana napravimo grubo, pokažemo, pa je popravljamo;
• inkrementalno znači „dodajemo komad po komad”: prvo samo naručivanje, pa plaćanje karticom, pa praćenje dostavljača.

Dobri timovi rade i jedno i drugo istovremeno.

2.4 Iterativni i inkrementalni razvoj

Najpoznatija slika za ovu razliku je put do automobila. Ako kupac hoće prevozno sredstvo, pogrešan inkrementalni put je napraviti prvo točak, pa šasiju, pa karoseriju: kupac do kraja nema čime da se vozi. Dobar put je napraviti prvo skejtbord, pa romobil, pa bicikl, pa motor, pa automobil. Svaka verzija je mala, ali već vozi, i kupac može reći „zapravo mi treba nešto s krovom” prije nego što je potrošen sav novac.

Za DeliveryApp bi „skejtbord” bio: jedan restoran, jelovnik od tri jela, narudžba bez plaćanja karticom (plaća se dostavljaču), i e-mail restoranu. To je malo, ali neko već može naručiti ručak i reći šta mu smeta.

Ukratko – 2.4 Iterativni i inkrementalni razvoj

• Iteracija je kratak krug analize, projektovanja, programiranja i testiranja s rezultatom koji se pokaže korisniku.
• Iterativno znači doterivati, a inkrementalno dodavati komad po komad.
• Svaki inkrement treba da „vozi”, kao skejtbord prije automobila.
• Najmanji DeliveryApp je jedan restoran, tri jela i narudžba bez kartice.

2.5 Agilni manifest

Manifest iz Snowbirda (2001) kaže da tim više cijeni stvari s lijeve strane, iako i one s desne imaju vrijednost:

2.5 Agilni manifest

Važno je pročitati i sitna slova: manifest ne kaže da dokumentacija, plan i ugovor nisu potrebni. Kaže da su ljudi, softver koji radi, saradnja i promjena važniji. Tim koji ne piše nikakvu dokumentaciju i kaže „mi smo agilni” nije pročitao manifest do kraja.

Iz dvanaest principa manifesta izdvajamo četiri koja ćemo stalno koristiti:

2.5 Agilni manifest

1. Najveći prioritet je zadovoljan korisnik, kroz ranu i stalnu isporuku softvera koji ima vrijednost.
2. Softver koji radi isporučuje se često, svakih nekoliko sedmica.
3. Ljudi iz posla (npr. vlasnici restorana) i programeri rade zajedno, svakodnevno.
4. U redovnim razmacima tim razmisli kako da radi bolje i to promijeni.

Ukratko – 2.5 Agilni manifest

• Agilni manifest napisan je 2001. u Snowbirdu i ima četiri vrijednosti i dvanaest principa.
• Ljudi, softver koji radi, saradnja i promjena važniji su od procesa, dokumentacije, ugovora i plana, ali ih ne ukidaju.
• Softver se isporučuje često, a tim redovno razmišlja kako da radi bolje.

2.6 Scrum

Scrum je najrašireniji agilni okvir. Ime je pozajmljeno iz ragbija, gdje „scrum” znači zbijenu grupu igrača koji zajedno guraju loptu naprijed. Scrum je namjerno jednostavan i ima tri grupe pojmova: uloge, artefakte (stvari koje tim pravi i čuva) i događaje.

2.6 Scrum

Tri uloge

Scrum master nije šef. On je više kao trener: ne igra umjesto tima, nego pazi da tim može igrati.

2.6 Scrum

Tri artefakta

1. Backlog proizvoda (product backlog) – lista svega što bi DeliveryApp mogao imati, poredana po važnosti. Na vrhu su sitne, jasne stavke, na dnu krupne i nejasne.
2. Backlog sprinta (sprint backlog) – stavke koje je tim izabrao za ovaj sprint, s planom kako ih napraviti.
3. Inkrement – ono što na kraju sprinta radi i ispunjava Definiciju gotovog.

Definicija gotovog (Definition of Done) je lista uslova koje svaka stavka mora ispuniti da bi se smjela nazvati gotovom. Za DeliveryApp bi mogla glasiti: kod je u Gitu, prošao je recenziju kolege, svi testovi prolaze, kriteriji prihvatanja su provjereni, dokumentacija je dopunjena. Bez ovakve liste svako „gotovo” znači nešto drugo.

2.6 Scrum

Pet događaja

2.6 Scrum

2.6 Scrum

Brzina tima i plan izdanja

Timovi često procjenjuju veličinu stavki u bodovima (story points): to nisu sati, nego relativna težina („ova stavka je otprilike duplo veća od one”). Zbir bodova završenih u jednom sprintu zove se brzina tima (velocity).

Primjer: tim DeliveryApp je u prva tri sprinta završio 18, 22 i 20 bodova. Prosječna brzina je

Čemu služi. Ako je u backlogu još 120 bodova, potrebno je otprilike 120 / 20 = 6 sprintova, a to je kod sprintova od dvije sedmice oko 12 sedmica. Ovo je procjena, ne obećanje: backlog se mijenja, a brzina varira. Ali je mnogo bolja od „biće gotovo kad bude gotovo”.

2.6 Scrum

Ukratko – 2.6 Scrum

• Scrum ima tri uloge: vlasnika proizvoda, scrum mastera i razvojni tim.
• Artefakti su backlog proizvoda, backlog sprinta i inkrement koji ispunjava Definiciju gotovog.
• Pet događaja su sprint, planiranje, dnevni sastanak, pregled i retrospektiva.
• Brzina tima je zbir završenih bodova po sprintu; kod brzine 20 i backloga od 120 bodova treba oko šest sprintova.

Provjeri se

1. Koja je razlika između iterativnog i inkrementalnog razvoja? Iterativno znači doterivati isti dio, a inkrementalno dodavati nove dijelove.
2. Da li agilni manifest ukida dokumentaciju? Ne; kaže da je softver koji radi važniji, ali dokumentacija i dalje ima vrijednost.
3. Šta je Definicija gotovog? Lista uslova koje svaka stavka mora ispuniti da bi se smjela nazvati gotovom.

Odgovori: tipka R ili klik na zamućeno polje.

2.7 Kanban

Kanban (japanski: „kartica”, „tabla”) potiče iz fabrike automobila Toyota u Japanu, iz sredine dvadesetog vijeka. Tamo je kartica putovala s dijelovima i govorila kada treba proizvesti nove, tako da se ne gomilaju zalihe. U softveru Kanban znači tablu s kolonama na kojoj svaki zadatak ima svoju karticu, a kartice putuju s lijeva na desno.

Tipična tabla DeliveryApp ima pet kolona: Backlog, Spremno, U radu, Pregled, Gotovo. Svako odmah vidi gdje je koji posao i gdje se posao gomila.

Najvažnija ideja Kanbana nije tabla, nego ograničenje posla u toku (WIP ograničenje, od engleskog work in progress). Ako kolona „U radu” smije imati najviše tri kartice, niko ne smije početi četvrti zadatak dok se jedan ne završi. To zvuči kao kočnica, a zapravo ubrzava: ljudi završavaju započeto umjesto da istovremeno žongliraju s deset poluzavršenih stvari.

Slika iz života: kasa u prodavnici. Ako jedna blagajnica istovremeno počne naplaćivati pet kupaca (kod jednog skenira mlijeko, kod drugog hljeb…), niko ne izlazi iz prodavnice. Ako naplati jednog po jednog, svaki kupac čeka kraće.

2.7 Kanban

Littleov zakon

Postoji jednostavna veza između broja zadataka u radu, brzine kojom se završavaju i vremena koje jedan zadatak provede na tabli. Zove se Littleov zakon, po matematičaru Johnu Littleu:

Čemu služi. W je prosječno vrijeme koje jedan zadatak provede u sistemu (od „Spremno” do „Gotovo”). L je prosječan broj zadataka koji su istovremeno u radu. λ (čita se „lambda”) je propusnost, prosječan broj zadataka koje tim završi u jedinici vremena. Primjer: ako je na tabli DeliveryApp stalno oko 6 kartica u radu, a tim dnevno završi 3 kartice, jedna kartica u prosjeku putuje W = 6 / 3 = 2 dana. Ako tim smanji WIP na 3, a završava i dalje 3 dnevno, prosječno vrijeme pada na 1 dan. Ista ekipa, isti posao, a kupac dobija ispravku duplo brže.

2.7 Kanban

Kanban nema sprintove ni propisane uloge. Zato je dobar za timove kojima posao stiže neravnomjerno: podrška korisnicima, održavanje, ispravke grešaka. Mnogi timovi kombinuju Scrum i Kanban: rade u sprintovima, a sprint prate na Kanban tabli.

Ukratko – 2.7 Kanban

• Kanban potiče iz Toyote; posao se vidi kao kartice koje putuju kroz kolone table.
• WIP ograničenje kaže koliko zadataka smije biti u radu odjednom i tako ubrzava završavanje.
• Littleov zakon W = L / λ: sa 6 zadataka u radu i 3 završena dnevno, zadatak traje 2 dana.
• Kanban nema sprintove i dobar je za podršku i održavanje.

2.8 DevOps: razvoj i rad kao jedan tim

U starijim firmama postojala su dva odvojena tima. Razvoj (development) je pisao novi kod i želio ga što prije pustiti. Održavanje rada (operations) brinulo je o serverima i željelo da se ništa ne mijenja, jer svaka promjena može nešto pokvariti. Između njih je stajao „zid” preko kojeg se kod bacao jednom u nekoliko mjeseci, uz mnogo stresa.

DevOps (od development i operations) je način rada u kojem ta dva tima rade zajedno i automatizuju sve što se ponavlja:

• svaka izmjena koda automatski se prevede i testira (kontinuirana integracija, continuous integration, CI);
• ako testovi prođu, izmjena se automatski pripremi ili pusti u rad (kontinuirana isporuka, continuous delivery/deployment, CD);
• sistem u radu se stalno nadzire, a tim brzo vidi kad nešto ne valja.

Umjesto jedne velike, strašne isporuke svaka tri mjeseca, DevOps timovi isporučuju male izmjene često, nekad i više puta dnevno. Mala izmjena se lakše provjeri, a ako nešto pođe naopako, lakše se vrati. DevOps detaljno radimo u poglavlju 14, gdje ćemo vidjeti i šta se desi kad automatska isporuka nije dovoljno pažljivo projektovana.

Ukratko – 2.8 DevOps: razvoj i rad kao jedan tim

• DevOps spaja razvoj i održavanje rada u jedan tim.
• Kontinuirana integracija automatski prevodi i testira svaku izmjenu, a kontinuirana isporuka je pušta u rad.
• Česte male izmjene sigurnije su od rijetkih velikih.

2.9 Alati kroz životni ciklus

Kroz faze životnog ciklusa tim koristi mnogo alata. Neki pomažu da se razmišlja i dogovara, a neki pretvaraju naš tekst u program koji računar izvršava. Ove druge zovemo sistemski programski alati i vrijedi znati šta svaki radi, jer projektant odlučuje i o njima (posebno kod sistema u realnom vremenu, poglavlje 13).

2.9 Alati kroz životni ciklus

2.9 Alati kroz životni ciklus

U DeliveryApp pišemo u Pythonu, koji se izvršava interpreterom, pa kompajler i povezivač ne vidimo direktno. Ali aplikacija za mobitel, baza i operativni sistem servera prevedeni su upravo ovim alatima. U sistemima koji upravljaju uređajima (poglavlje 13), program se često piše u C-u, prevodi kompajlerom za mali procesor, isproba u simulatoru i tek onda učita u uređaj.

Ukratko – 2.9 Alati kroz životni ciklus

• IDE je mjesto rada, a asembler, kompajler i interpreter prevode ili izvršavaju kod.
• Povezivač spaja dijelove u jedan program, a punjač ga učitava u memoriju.
• Debager zaustavlja program i pokazuje varijable, a simulator glumi uređaj koji nemamo.
• Git i CI server prate i automatski provjeravaju svaku izmjenu.

2.10 Kako izabrati metodologiju

Ne postoji jedna metodologija koja je najbolja za sve. Izbor zavisi od toga koliko su zahtjevi poznati i stabilni, koliko je greška opasna i kako posao stiže.

2.10 Kako izabrati metodologiju

Za DeliveryApp biramo Scrum sa sprintovima od dvije sedmice i Kanban tablu na GitHubu. Razlog: vlasnici restorana i kupci tek treba da vide prvu verziju da bi rekli šta im zaista treba. Kad sistem bude u radu i pređe u održavanje, tim može preći na čisti Kanban.

Ukratko – 2.10 Kako izabrati metodologiju

• Nijedna metodologija nije najbolja za sve projekte.
• Vodopad i V-model odgovaraju stabilnim zahtjevima i strogim propisima, Scrum novim proizvodima, a Kanban neravnomjernom poslu.
• Za DeliveryApp biramo Scrum sa sprintovima od dvije sedmice i Kanban tablu.

Provjeri se

1. Šta je WIP ograničenje? Najveći broj zadataka koji smiju istovremeno biti u radu.
2. Šta radi povezivač? Spaja prevedene dijelove programa i biblioteke u jedan izvršni program.
3. Zašto DeliveryApp radi po Scrumu? Jer je proizvod nov i korisnici tek kroz česte inkremente vide šta im zaista treba.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – tabla i prvi sprint DeliveryApp

Cilj je da tim (ili svaki student sam, u ulozi cijelog tima) napravi tablu zadataka za DeliveryApp na GitHubu, popuni backlog i isplanira Sprint 1. Radi se u repozitoriju deliveryapp-projekat iz poglavlja 1.

Korak 1 – Stavke backloga kao GitHub Issues

1. U repozitoriju otvorite karticu Issues i kliknite New issue.
2. Napravite bar 12 stavki iz vizije. Naslov je kratak i počinje glagolom, a opis kaže zašto stavka postoji. Primjeri:

- „Prikazati jelovnik jednog restorana” - „Dodati jelo u korpu i vidjeti zbir” - „Izračunati dostavu po pravilima PP-2 do PP-4” - „Primijeniti kod STUDENT10 (PP-5)” - „Restoran prihvata ili odbija narudžbu” - „Kupac otkazuje narudžbu (PP-6)” - „Plaćanje karticom” - „Praćenje dostavljača na mapi” - „Mjesečni izvještaj za restoran”

1. Svakoj stavci dodajte oznaku (label) veličine: S (mala), M (srednja), L (velika). Na sljedećem času oznake ćemo zamijeniti bodovima.

Korak 2 – Tabla u GitHub Projects

1. Kartica Projects → New project → Board. Nazovite je „DeliveryApp”.
2. Napravite kolone: Backlog, Spremno, U radu, Pregled, Gotovo.
3. U postavkama kolone U radu upišite ograničenje (limit) 3. GitHub će upozoriti kad ga pređete.
4. Dodajte sve stavke na tablu, u kolonu Backlog, i poredajte ih po važnosti prevlačenjem: na vrh ide ono bez čega DeliveryApp ne može (jelovnik, korpa, dostava), na dno „lijepo je imati” (mapa, izvještaj).

Korak 3 – Plan Sprinta 1

1. Napišite cilj sprinta u jednoj rečenici, npr. „Kupac može naručiti iz jednog restorana i vidjeti tačnu cijenu s dostavom.”
2. Iz vrha backloga izaberite stavke koje služe tom cilju i prebacite ih u Spremno. Za sprint od dvije sedmice izaberite tri do pet stavki.
3. U README.md dodajte odjeljak Definicija gotovog s najmanje četiri uslova (kod u Gitu, prošao recenziju, testovi prolaze, kriteriji prihvatanja provjereni).
4. Napravite fajl sprint-1.md po šablonu:

# Sprint 1

- Trajanje: 2 sedmice
- Cilj: (jedna rečenica)

## Stavke
| Issue | Naslov | Veličina |
| --- | --- | --- |
| #1 | Prikazati jelovnik jednog restorana | S |

## Rizici
(Šta bi nas moglo zakočiti?)

Korak 4 – Simulacija dnevnog sastanka i retrospektive

U grupama od četiri studenta odigrajte dnevni sastanak od tačno 15 minuta: svako kaže šta je „juče” uradio, šta će „danas” i šta ga koči. Jedan član je scrum master i pazi na vrijeme. Zatim odigrajte kratku retrospektivu: svako na papirić napiše jednu stvar koja je išla dobro i jednu koju bi promijenio. Zaključak retrospektive (jedna promjena za sljedeći put) upišite na kraj sprint-1.md.

Korak 5 – AI kao pomoćnik u backlogu (opcionalno)

Dajte AI asistentu viziju DeliveryApp i zatražite prijedlog dodatnih stavki backloga. Za svaku predloženu stavku odlučite: ide u backlog, ide u „nije u prvoj verziji”, ili se odbacuje, i zapišite zašto. Provjerite da AI nije izmislio pravilo koje vlasnici nisu tražili (npr. „dostava besplatna nedjeljom”).

Rezultat koji se predaje: link na GitHub Projects tablu s najmanje 12 stavki i WIP ograničenjem 3, te fajl sprint-1.md s ciljem, stavkama, rizicima i zaključkom retrospektive.

Vježba za studenta 1 – faze.

Vježba za studenta 1 – faze. – rješenje

Vježba za studenta 2 – V-model.

Vježba za studenta 2 – V-model. – rješenje

Vježba za studenta 3 – brzina tima.

Vježba za studenta 3 – brzina tima. – rješenje

Vježba za studenta 4 – Littleov zakon.

Vježba za studenta 4 – Littleov zakon. – rješenje

Vježba za studenta 5 – izbor metodologije.

Vježba za studenta 5 – izbor metodologije. – rješenje

Sažetak u pet rečenica

1. Svaki sistem prolazi kroz planiranje, analizu, projektovanje, implementaciju, testiranje, isporuku i održavanje, a održavanje obično traje najduže.
2. Vodopad radi faze jednom i redom, a V-model svakoj fazi projektovanja daje par u fazi provjere; oba su dobra kad su zahtjevi stabilni i propisi strogi.
3. Agilni razvoj, opisan u manifestu iz Snowbirda 2001, pravi sistem u kratkim iteracijama s inkrementima koji rade i stalnim razgovorom s korisnikom.
4. Scrum ima tri uloge, tri artefakta i pet događaja, a brzina tima pomaže da se procijeni koliko je sprintova potrebno za backlog.
5. Kanban s WIP ograničenjem i DevOps s automatizovanom isporukom ubrzavaju završavanje posla, a sistemski programski alati od editora do debagera prate kod kroz cijeli ciklus.

Pitanja za ponavljanje

1. Nabrojte sedam faza životnog ciklusa i za svaku jedan rezultat iz DeliveryApp.
2. Koje su prednosti i mane vodopada?
3. Šta je V-model i šta je njegova ključna ideja?
4. Koja je razlika između iterativnog i inkrementalnog razvoja? Objasnite primjerom skejtborda i automobila.
5. Navedite četiri vrijednosti agilnog manifesta. Da li manifest ukida dokumentaciju?
6. Navedite tri uloge u Scrumu i šta radi svaka.
7. Navedite pet događaja Scruma i pitanje na koje svaki odgovara.
8. Šta je Definicija gotovog i zašto je potrebna?
9. Šta je brzina tima i kako se koristi za plan?
10. Šta je WIP ograničenje i zašto ubrzava rad? Napišite Littleov zakon i objasnite simbole.
11. Šta je DevOps i šta su CI i CD?
12. Šta rade kompajler, interpreter, povezivač, punjač i debager?