Poglavlje 2: Proces i organizacija projekta
Priča za početak. Sredinom šezdesetih godina Fred Brooks vodio je u IBM-u razvoj operativnog sistema OS/360, jednog od najvećih softverskih projekata svog vremena. Projekat je kasnio, i Brooks je uradio ono što bi uradio skoro svaki rukovodilac: dodao je još programera. Projekat je kasnio još više. Novi ljudi su prvo morali učiti, stari su ih morali podučavati umjesto da programiraju, a svaki novi čovjek je značio još sastanaka i još nesporazuma. Deset godina kasnije, 1975, Brooks je iskustvo opisao u knjizi „Mitski čovjek-mjesec” (The Mythical Man-Month). Najpoznatija rečenica iz nje danas se zove Brooksov zakon: dodavanje ljudi zakašnjelom softverskom projektu čini ga još zakašnjelijim. Brooks je to objasnio i slikom koju niko ne zaboravlja: dijete se rađa za devet mjeseci, bez obzira na to koliko je žena dodijeljeno tom poslu. Knjiga se i danas prodaje, a Brooks je 1999. dobio Turingovu nagradu, najveće priznanje u računarstvu.
U poglavlju 1 vidjeli smo da proizvod nastaje kroz niz projekata i da DeliveryApp 2.0 pravi tim od šest ljudi za dvanaest sedmica. Ovo poglavlje odgovara na pitanje kako se taj posao organizuje. Prvi dio govori o modelima procesa (klasičnim i agilnim), ulogama u timu, izboru pristupa i planiranju: koliko će trajati i koštati. Drugi dio govori o onome što plan najčešće obori: rizicima i ljudima. Na kraju vidimo kako se čuva kvalitet i kako se sam proces s vremenom poboljšava.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlja 2, 3, 22, 23).
- R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner’s Approach, 9th ed., McGraw-Hill, 2019.
- F. P. Brooks: The Mythical Man-Month, Anniversary ed., Addison-Wesley, 1995.
Riječi ovog poglavlja.
- Model procesa – dogovoren redoslijed i način rada tima od ideje do isporuke.
- Vodopad – model u kojem faze idu jedna za drugom, bez vraćanja.
- Spiralni model – model u kojem se projekat razvija u krugovima, a svaki krug počinje analizom rizika.
- Scrum – agilni okvir sa sprintovima, tri odgovornosti (vlasnik proizvoda, scrum master, razvojni tim) i pet događaja.
- Kanban – metoda u kojoj se posao vidi na tabli i ograničava koliko se radi odjednom.
- Backlog – lista svega što treba napraviti, poredana po važnosti.
- Bod priče (story point) – relativna mjera veličine posla, a ne broj sati.
- Brzina tima (velocity) – broj bodova koje tim završi u jednom sprintu.
- Plan izdanja – plan koji kaže koje funkcije stižu u kojoj verziji i otprilike kada.
- Rizik – događaj koji se možda desi i ako se desi, šteti projektu.
- Registar rizika – tabela rizika s vjerovatnoćom, uticajem i odgovorom.
- Brooksov zakon – dodavanje ljudi zakašnjelom projektu čini ga još zakašnjelijim.
- Upravljanje konfiguracijom – praćenje svih verzija koda, dokumenata i podešavanja.
- Poboljšanje procesa (SPI, software process improvement) – sistematsko mijenjanje načina rada da bi tim radio bolje.
Ciljevi poglavlja. Nakon poglavlja možete: opisati vodopad, V-model, spiralni model, Scrum i Kanban i reći kada je koji dobar; nabrojati uloge u timu i šta svaka radi; obrazložiti izbor pristupa za dati projekat; procijeniti stavke backloga bodovima i izračunati broj sprintova iz brzine tima; napraviti budžet tima; napraviti registar rizika i rangirati rizike; izračunati broj kanala komunikacije i objasniti Brooksov zakon; opisati faze razvoja tima; objasniti upravljanje konfiguracijom i Definiciju gotovog; opisati PDCA ciklus i nivoe zrelosti CMMI.
Plan poglavlja – Predavanje 2: dva časa teorije i jedan čas dopunske prakse
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 2.1–2.4 Modeli, uloge, izbor pristupa, planiranje | Planning poker za tri stavke DeliveryApp |
| Teorija 2 | 2.5–2.8 Rizici, ljudi i tim, kvalitet, poboljšanje procesa | Brooksov zakon na tabli; registar rizika |
| Dopunska praksa | Plan izdanja 2.0 i registar rizika u GitHub Projects | Tabla, milestone, rizici |
Dio 1 – Modeli, uloge i plan
2.1 Klasični modeli razvoja
Svaki softver, bez obzira na model, prolazi kroz iste poslove: planiranje (vrijedi li?), analizu zahtjeva (šta treba?), dizajn (kako?), implementaciju (kod), provjeru (radi li?), isporuku i održavanje. Modeli se razlikuju samo po tome kojim redom i koliko puta se ti poslovi rade.
Vodopad radi svaki posao jednom, redom, kao voda niz stepenice. Na kraju svake faze nastaje odobren dokument koji je ulaz u sljedeću. Prednost: jasan plan, budžet i dokumentacija. Mana: korisnik vidi rezultat tek na kraju, kad je ispravka najskuplja.
V-model je vodopad u kojem svaka faza „lijeve strane” (zahtjevi, arhitektura, dizajn, kod) ima par na „desnoj strani” (prihvatni, sistemski, integracioni, jedinični test). Koristi se tamo gdje greška može ugroziti život: automobili, avioni, medicinski uređaji.
Spiralni model (Barry Boehm, 1986) razvija sistem u krugovima. Svaki krug ima četiri koraka: odredi ciljeve, procijeni i smanji rizike (npr. napravi prototip onoga što je najneizvjesnije), razvij i provjeri, isplaniraj sljedeći krug. Spirala je bila važan korak prema iterativnom razvoju jer je prva stavila rizik u centar procesa.
Za radoznale. Winston Royce, čiji se rad iz 1970. smatra prvim opisom vodopada, u istom radu upozorio je da je čisti redoslijed faza bez povratka „rizičan i poziva na neuspjeh”. Mnogi su kasnije preuzeli samo njegovu sliku, bez upozorenja.
Ukratko.
- Svi modeli rade iste poslove; razlikuju se po redoslijedu i broju ponavljanja.
- Vodopad radi faze jednom i redom; V-model svakoj fazi daje par u provjeri.
- Spiralni model razvija u krugovima i svaki krug počinje procjenom rizika.
2.2 Agilni pristupi i uloge u timu
U februaru 2001. sedamnaest programera napisalo je Manifest agilnog razvoja: četiri vrijednosti i dvanaest principa. Suština: softver se pravi u kratkim iteracijama, na kraju svake postoji nešto što radi i što korisnik može vidjeti, a plan se mijenja kad se sazna nešto novo.
Scrum je najrašireniji agilni okvir. Posao se radi u sprintovima (obično dvije sedmice). Scrum ima tri odgovornosti, tri artefakta i pet događaja:
| Odgovornosti | Artefakti | Događaji |
|---|---|---|
| Vlasnik proizvoda – šta i kojim redom | Backlog proizvoda – sve što treba | Sprint – okvir od 1–4 sedmice |
| Scrum master – pomaže timu da radi po Scrumu, uklanja prepreke | Backlog sprinta – šta radimo u ovom sprintu | Planiranje sprinta |
| Razvojni tim – pravi inkrement | Inkrement – komad proizvoda koji radi | Dnevni sastanak (15 minuta) |
| Pregled sprinta – pokažemo šta radi | ||
| Retrospektiva – kako da radimo bolje |
Kanban nema sprintove. Posao teče preko table s kolonama (npr. Spremno – U radu – Pregled – Gotovo), a u koloni „U radu” smije biti najviše nekoliko kartica (WIP ograničenje). Kanban je dobar za posao koji stiže neravnomjerno, kao što su podrška i ispravke grešaka.
Uloge izvan Scruma ne nestaju: u većim firmama postoje projektni menadžer (rok, budžet, ugovor), arhitekta (velike tehničke odluke), tester ili inženjer kvaliteta, dizajner korisničkog iskustva, DevOps inženjer (isporuka i rad sistema), poslovni analitičar (zahtjevi). U malom timu jedna osoba nosi više uloga.
U DeliveryApp 2.0: Lana je vlasnica proizvoda, Amar scrum master i programer, Sara, Dino i Emir programeri, a Ena je dizajnerka i testerka. Arhitektonske odluke donose zajedno, a Amar vodi računa da budu zapisane (poglavlje 7).
Česta zabluda. „Agilno znači bez plana i bez dokumentacije.” Agilni tim planira češće, ne manje: svake dvije sedmice. Dokumentacija postoji, ali samo ona koja nekome služi. Manifest kaže da je softver koji radi važniji od iscrpne dokumentacije, a ne da je dokumentacija zabranjena.
Ukratko.
- Agilni razvoj pravi softver u kratkim iteracijama, s inkrementom koji radi na kraju svake.
- Scrum ima tri odgovornosti, tri artefakta i pet događaja; Kanban ima tablu i WIP ograničenje.
- U DeliveryApp 2.0 Lana je vlasnica proizvoda, Amar scrum master, a sprint traje dvije sedmice.
2.3 Kako izabrati pristup
Nijedan model nije najbolji za sve. Izbor zavisi od nekoliko pitanja:
| Pitanje | Ako je odgovor „da” | Ako je odgovor „ne” |
|---|---|---|
| Da li su zahtjevi jasni i stabilni od početka? | vodopad ili V-model | agilno (Scrum) |
| Da li je softver kritičan za život ili ga pregleda regulator? | V-model, mnogo dokumentacije | agilno, lakša dokumentacija |
| Da li je naručilac stalno dostupan za razgovor? | agilno | više planiranja unaprijed |
| Da li posao stiže neravnomjerno (podrška, greške)? | Kanban | Scrum |
| Da li postoji velika tehnička neizvjesnost? | spirala ili prototip prvo | bilo koji |
| Da li je tim velik (više od 10 ljudi) ili raštrkan? | više timova, skalirani okvir, jasni interfejsi | jedan tim |
U praksi su česti hibridi: firma potpiše ugovor s rokom i budžetom (kao u vodopadu), a unutar njega tim radi u sprintovima. Za DeliveryApp 2.0 tim bira Scrum za nove funkcije (zahtjevi se još otkrivaju, Lana je dostupna svaki dan) i Kanban za podršku verziji 1.4.2 koja radi u Gradu A.
Na času. Za svaki projekat izaberite pristup i obrazložite jednom rečenicom: a) softver za pumpu za inzulin; b) aplikacija za studentski festival za tri mjeseca; c) održavanje bankarskog sistema koji radi 15 godina; d) nova društvena mreža čija ideja još nije sasvim jasna.
Ukratko.
- Pristup se bira prema stabilnosti zahtjeva, kritičnosti, dostupnosti naručioca, vrsti posla, neizvjesnosti i veličini tima.
- Hibridi su česti: ugovor po vodopadu, rad po Scrumu.
- DeliveryApp 2.0 koristi Scrum za nove funkcije i Kanban za podršku staroj verziji.
2.4 Planiranje i budžet; agilno planiranje
Svaki naručilac pita dva pitanja: koliko će trajati i koliko će koštati. Klasično planiranje odgovara tako što posao razbije na zadatke, za svaki procijeni sate i sabere. Problem je što su procjene u satima za posao koji niko još nije radio skoro uvijek preoptimistične.
Agilno planiranje koristi drugi trik: ne pitamo „koliko sati?”, nego „koliko je ovo veće od onoga?”. Ljudi loše procjenjuju apsolutno, a dobro relativno: teško je reći koliko je visoka zgrada, ali lako je reći da je duplo viša od susjedne.
Bodovi priče. Svaka stavka backloga dobija broj iz niza 1, 2, 3, 5, 8, 13, 20 (slično Fibonaccijevom nizu). Razmak između brojeva raste namjerno: velike stvari su neizvjesnije, pa nema smisla raspravljati da li je nešto 14 ili 15.
Planning poker. Svaki član tima ima karte s brojevima. Vlasnica proizvoda pročita stavku, svi istovremeno okrenu kartu. Ako se procjene mnogo razlikuju, oni s najmanjom i najvećom kartom objasne zašto, i glasa se ponovo. Vrijednost nije u broju, nego u razgovoru: Emir je dao 13 jer zna da servis mapa u Gradu B vraća adrese u drugom obliku, a ostali to nisu znali.
| Stavka backloga DeliveryApp 2.0 | Bodovi |
|---|---|
| Tarife dostave po gradu (podešavanje umjesto koda) | 8 |
| „Ponovi narudžbu” | 5 |
| „Praćenje dostavljača uživo” | 13 |
| Izbor grada pri prvom pokretanju | 3 |
| Izvještaj o prometu po gradu za udruženje | 5 |
Brzina tima i plan izdanja. Tim DeliveryApp je u četiri sprinta verzije 1.x završio 18, 22, 20 i 24 boda. Prosjek je
\[ v = \frac{18 + 22 + 20 + 24}{4} = \frac{84}{4} = 21 \text{ bod po sprintu.} \]
Backlog za verziju 2.0 ima 126 bodova. Potrebno je 126 / 21 = 6 sprintova, odnosno 12 sedmica. To je plan izdanja: verzija 2.0 za oko 12 sedmica, uz rezervu jer brzina varira.
Budžet. Najveći trošak razvoja su ljudi. Ako član tima košta firmu 2.000 € mjesečno (bruto plata i ostali troškovi), šest ljudi tri mjeseca košta 6 × 3 × 2.000 = 36.000 €. Uz dizajn, licence i marketing (4.000 €), ulaganje u DeliveryApp 2.0 je 40.000 €. Da li se to isplati, računamo u poglavlju 10.
Broj za pamćenje. 21 bod po sprintu: brzina tima DeliveryApp. Brzina je mjera tog tima i ne poredi se s drugim timovima, jer svaki tim bodove „osjeća” drugačije.
Ukratko.
- Agilno planiranje procjenjuje relativnu veličinu bodovima, a ne sate.
- Planning poker otkriva razlike u znanju tima; vrijednost je u razgovoru.
- Broj sprintova = bodovi u backlogu / prosječna brzina; za DeliveryApp 2.0: 126 / 21 = 6 sprintova.
- Najveći trošak su ljudi: 6 × 3 × 2.000 € = 36.000 €, ukupno ulaganje 40.000 €.
Provjeri se.
- Šta je u centru spiralnog modela? – Procjena i smanjivanje rizika na početku svakog kruga.
- Ko u Scrumu odlučuje o redoslijedu backloga? – Vlasnik proizvoda.
- Tim je završio 15, 25 i 20 bodova; backlog ima 100 bodova. Koliko sprintova? – Brzina 20, pa 100 / 20 = 5 sprintova.
Dio 2 – Rizici, ljudi i kvalitet
2.5 Upravljanje rizicima
Rizik je nešto što se još nije desilo, ali bi moglo, i ako se desi, šteti projektu. Problem je rizik koji se već desio. Upravljanje rizicima znači baviti se problemima dok su još rizici, kad je jeftino.
Postupak ima četiri koraka:
- Prepoznaj – tim zajedno nabraja šta bi moglo poći naopako: tehnika, ljudi, naručilac, zakon, dobavljači.
- Procijeni – za svaki rizik vjerovatnoću (1–5) i uticaj (1–5). Proizvod V × U daje prioritet.
- Odgovori – izbjegni (promijeni plan da rizik nestane), ublaži (smanji vjerovatnoću ili uticaj), prenesi (osiguranje, ugovor) ili prihvati (i prati).
- Prati – registar rizika se pregleda na svakoj retrospektivi.
Registar rizika DeliveryApp 2.0:
| Oznaka | Rizik | V | U | V × U | Odgovor |
|---|---|---|---|---|---|
| RZ-1 | Servis mapa u Gradu B nema tačne adrese | 4 | 4 | 16 | ublažiti: ručna korekcija adrese, test na 100 adresa |
| RZ-3 | Ručak u tri grada preoptereti server | 3 | 4 | 12 | ublažiti: test opterećenja, keš, skaliranje (poglavlje 6) |
| RZ-2 | Ključni programer napušta tim | 2 | 5 | 10 | ublažiti: pregled koda, dokumentacija, rad u paru |
| RZ-4 | Novi zakon o fiskalizaciji računa | 2 | 3 | 6 | pratiti |
| RZ-5 | Dobavljač plaćanja diže proviziju | 3 | 2 | 6 | prihvatiti; imati rezervnog dobavljača |
Rizik RZ-1 je na vrhu. Zato tim prvi sprint ne počinje lakim stvarima, nego tarifama i adresama za Grad B: ako se problem pokaže nerješivim, bolje je to saznati u drugoj nego u desetoj sedmici. To je ista ideja kao u spiralnom modelu.
Česta zabluda. „Registar rizika je papir za šefa.” Registar ima smisla samo ako mijenja plan. Ako rizik broj jedan ne utiče na to šta se radi u sljedećem sprintu, registar je ukras.
Ukratko.
- Rizik je mogući budući problem; upravljamo njime dok je još jeftino.
- Koraci: prepoznaj, procijeni (V × U), odgovori (izbjegni, ublaži, prenesi, prihvati), prati.
- Najveći rizik DeliveryApp 2.0 (adrese u Gradu B) rješava se u prvom sprintu.
2.6 Ljudi i timski rad
Softver prave ljudi, i najveći dio uspjeha ili propasti projekta zavisi od toga kako ti ljudi rade zajedno.
Zašto Brooksov zakon važi. Kad tim ima n ljudi, broj parova koji moraju međusobno razgovarati je
\[ k = \frac{n(n-1)}{2}. \]
Za tim DeliveryApp (6 ljudi) to je 15 kanala. Ako Lana doda još troje, kanala je 36, više nego duplo, a ljudi je samo 50 % više. Za 12 ljudi kanala je 66. Novi ljudi uz to prvo uče, a stari ih podučavaju. Zato dodavanje ljudi na kraju projekta usporava, a na početku, uz dobro podijeljen posao, može pomoći.
Iz stvarnog svijeta. U Amazonu se priča pravilo „tima od dvije pice”: tim treba biti dovoljno mali da ga nahrane dvije velike pice, dakle oko šest do osam ljudi. Kad posao naraste, ne povećava se tim, nego se pravi novi tim sa svojim jasnim dijelom proizvoda. To je Brooksov zakon pretvoren u organizaciju.
Faze razvoja tima. Psiholog Bruce Tuckman opisao je 1965. četiri faze kroz koje prolazi svaka grupa:
- Formiranje – ljudi su ljubazni i oprezni, uloge nisu jasne.
- Sukobljavanje – pojavljuju se razmimoilaženja oko načina rada; prirodno je i korisno ako se razgovara.
- Normiranje – tim se dogovori oko pravila (npr. Definicija gotovog, pravila pregleda koda).
- Djelovanje – tim radi glatko i sam rješava probleme.
Šta čini dobar tim. Istraživanje Googlea o timovima (projekat „Aristotel”, objavljen 2015) pokazalo je da je najvažnije psihološka sigurnost: da se svako usuđuje reći „ne razumijem”, „pogriješio sam” ili „mislim da ovo nije dobro” bez straha da će biti ismijan. U timu gdje se greške skrivaju, one stižu do korisnika.
Upravljanje ljudskim resursima u projektu uključuje i izbor ljudi (kombinacija vještina), raspodjelu posla, razvoj (učenje, mentorstvo) i zadržavanje (rizik RZ-2). Dobar rukovodilac ne mjeri ljude brojem linija koda, nego vrijednošću koju tim isporuči.
Na času. Koliko kanala komunikacije ima vaša grupa za seminarski rad od pet ljudi? Šta biste uradili da ih bude manje, a da svi i dalje znaju šta se dešava?
Ukratko.
- Broj kanala komunikacije je n(n − 1)/2: 6 ljudi → 15, 9 → 36, 12 → 66.
- Dodavanje ljudi kasno u projektu usporava jer rastu komunikacija i učenje.
- Tim prolazi kroz formiranje, sukobljavanje, normiranje i djelovanje.
- Psihološka sigurnost je najvažnija osobina dobrog tima.
2.7 Verzioniranje i upravljanje kvalitetom
Kad šest ljudi istovremeno mijenja isti proizvod, a u Gradu A radi verzija 1.4.2 dok se pravi 2.0, mora se tačno znati šta je u kojoj verziji. To je upravljanje konfiguracijom: praćenje svih verzija koda, dokumenata, podešavanja i biblioteka.
Tri alata to čine mogućim:
- Git pamti svaku izmjenu koda i ko ju je napravio (detaljno u poglavlju 5).
- Oznake verzija po pravilu glavna.sporedna.zakrpa (npr. 1.4.2): zakrpa za ispravku greške, sporedna za novu funkciju koja ne kvari staro, glavna za promjenu koja kvari staro. DeliveryApp 2.0.0 je nova glavna verzija jer se mijenja način obračuna dostave. O tome više u poglavlju 8.
- Bilješke o izdanju (release notes) – kratak spisak šta je novo u svakoj verziji, za korisnike i podršku.
Upravljanje kvalitetom znači da se kvalitet planira i ugrađuje, a ne samo provjerava na kraju. Tim DeliveryApp ima tri pravila:
- Definicija gotovog – stavka je gotova tek kad je kod u Gitu, prošao pregled kolege, testovi prolaze automatski i kriteriji prihvatanja su provjereni.
- Pregled koda – nijedna izmjena ne ide u glavnu granu bez da je pročita još jedan član tima.
- Mjerenje – broj grešaka koje su stigle do korisnika i vrijeme njihove ispravke prate se svakog mjeseca.
Na nivou firme kvalitet opisuju standardi: ISO 9001 (sistem upravljanja kvalitetom bilo koje organizacije) i ISO/IEC 25010 (model kvaliteta softverskog proizvoda, poglavlje 6).
Ukratko.
- Upravljanje konfiguracijom prati sve verzije koda, dokumenata i podešavanja.
- Verzija ima oblik glavna.sporedna.zakrpa; DeliveryApp prelazi s 1.4.2 na 2.0.0.
- Kvalitet se ugrađuje kroz Definiciju gotovog, pregled koda i mjerenje.
2.8 Poboljšanje procesa i alati
Dobar tim ne radi samo proizvod, nego stalno poboljšava i način na koji radi. To se zove poboljšanje procesa razvoja softvera (SPI).
PDCA ciklus (Plan – Do – Check – Act, planiraj – uradi – provjeri – djeluj) potiče iz industrije kvaliteta i jednostavan je: izaberi jednu promjenu, isprobaj je, izmjeri efekat, i ako pomaže, uvedi je za stalno. Scrum retrospektiva je PDCA u malom: svake dvije sedmice tim bira jednu stvar koju mijenja.
Primjer iz DeliveryApp: na retrospektivi Sprinta 2 tim primijeti da pregled koda čeka u prosjeku dva dana. Plan: pregled se radi isti dan, prije podne. Uradi: dvije sedmice. Provjeri: čekanje palo na pola dana. Djeluj: pravilo ulazi u Definiciju gotovog.
CMMI (Capability Maturity Model Integration) je model koji opisuje zrelost procesa organizacije u pet nivoa:
| Nivo | Naziv | Kako izgleda |
|---|---|---|
| 1 | Početni | uspjeh zavisi od heroja; svaki projekat drugačije |
| 2 | Upravljani | projekti se planiraju i prate |
| 3 | Definisani | firma ima zajednički, zapisan proces |
| 4 | Kvantitativno upravljani | proces se mjeri brojevima |
| 5 | Optimizirajući | proces se stalno poboljšava na osnovu mjerenja |
Alati za upravljanje projektom. Tabla i backlog vode se u alatima kao što su GitHub Projects, Jira, Azure DevOps ili Trello; dokumenti u wiki sistemu (npr. Confluence ili wiki na GitHubu); komunikacija u Slacku ili Teamsu. Alati se brzo mijenjaju, ali princip ostaje: posao mora biti vidljiv svima, jedna tabla, jedan backlog, jedno mjesto istine.
Ukratko.
- Poboljšanje procesa znači stalno i mjerljivo mijenjati način rada.
- PDCA: planiraj, uradi, provjeri, djeluj; retrospektiva je PDCA u malom.
- CMMI opisuje pet nivoa zrelosti procesa, od heroja do stalnog poboljšanja.
- Alati se mijenjaju, a princip ostaje: posao vidljiv svima, na jednom mjestu.
Provjeri se.
- Koliko kanala komunikacije ima tim od 8 ljudi? – 8 × 7 / 2 = 28.
- Rizik ima vjerovatnoću 3 i uticaj 5. Koji je prioritet? – 15, visok; rješava se rano.
- Šta je retrospektiva u terminima PDCA? – Mali PDCA ciklus: tim bira jednu promjenu, isproba je i provjeri efekat.
Dopunska praksa – plan izdanja i registar rizika
Cilj je u repozitoriju deliveryapp-2 iz poglavlja 1 napraviti tablu, plan izdanja i registar rizika. Trajanje: jedan čas.
Korak 1 – Backlog kao Issues
Napravite najmanje 8 stavki (GitHub Issues) za DeliveryApp 2.0. Naslov počinje glagolom, a u opisu stoji kriterij prihvatanja. Primjer:
Naslov: Izračunati dostavu po tarifi grada
Kriterij prihvatanja:
- N-1001 (21,50 €, 4,2 km) u Gradu B ima dostavu 3,80 €
- Adresa 8,1 km u Gradu B se odbijaKorak 2 – Planning poker
U grupi od 3–5 studenata procijenite stavke bodovima (1, 2, 3, 5, 8, 13, 20). Kartice možete napraviti od papira ili koristiti besplatnu web aplikaciju za planning poker. Bodove upišite kao oznaku (label) ili polje u GitHub Projects.
Korak 3 – Tabla i plan izdanja
- Projects → New project → Board, kolone Backlog, Spremno, U radu, Pregled, Gotovo; WIP ograničenje za U radu: 3.
- Napravite Milestone „v2.0.0” s datumom za 12 sedmica i dodijelite mu stavke.
- Saberite bodove. Uz brzinu 21, koliko sprintova treba? Upišite račun u
docs/plan-izdanja.md.
Korak 4 – Registar rizika
Napravite docs/rizici.md s tabelom iz odjeljka 2.5 i dodajte bar dva vlastita rizika. Poredajte ih po V × U. Za rizik s najvećim prioritetom napravite Issue „Smanjiti rizik RZ-…” i stavite ga u prvi sprint.
Rezultat: tabla s bar 8 procijenjenih stavki, milestone v2.0.0, docs/plan-izdanja.md i docs/rizici.md.
Vježbe
Vježba za studenta 1 – izbor modela.
Firma pravi softver za kontrolu semafora u gradu. Zahtjevi su propisani pravilnikom, a softver mora proći nezavisnu provjeru prije puštanja. Koji model predlažete i zašto?
Rješenje. V-model: zahtjevi su stabilni (propisani), a softver je kritičan i pregleda ga nezavisno tijelo, pa je potrebna potpuna dokumentacija i test za svaku fazu. Iz agilnog pristupa korisno je pozajmiti rane prototipe ekrana za operatere.
Vježba za studenta 2 – brzina i budžet.
Tim od 5 ljudi ima brzinu 16, 20, 18 i 22 boda. Backlog ima 150 bodova. Sprint traje 2 sedmice, a član tima košta 2.000 € mjesečno. Koliko sprintova, sedmica i novca treba (mjesec računajte kao 4 sedmice)?
Rješenje. Brzina je (16 + 20 + 18 + 22) / 4 = 19. 150 / 19 ≈ 7,9, dakle 8 sprintova = 16 sedmica = 4 mjeseca. Budžet: 5 × 4 × 2.000 = 40.000 €.
Vježba za studenta 3 – Brooksov zakon.
Lana predlaže da se u desetoj sedmici, kad kasne dvije sedmice, tim poveća sa 6 na 10 ljudi. Izračunajte promjenu broja kanala i obrazložite odgovor Lani.
Rješenje. Sa 6 ljudi je 15 kanala, sa 10 ljudi 10 × 9 / 2 = 45, tri puta više. Novi ljudi bi prve sedmice učili, a stari ih podučavali, pa bi tim u preostale dvije sedmice vjerovatno bio sporiji. Bolji odgovor: smanjiti obim verzije 2.0 (npr. „Praćenje uživo” prebaciti u 2.1) ili pomjeriti rok.
Vježba za studenta 4 – rizici.
Rangirajte rizike i predložite odgovor: A) cloud dobavljač ukida besplatni plan (V 2, U 3); B) dizajnerka je jedina osoba koja zna Figma fajlove (V 3, U 4); C) restorani u Gradu C ne žele koristiti tablet (V 4, U 5).
Rješenje. C (20), B (12), A (6). C: ublažiti – posjeta restoranima, prototip na papiru, obuka, možda i ekran na mobitelu. B: ublažiti – dijeljeni pristup i kratka dokumentacija dizajna. A: pratiti i imati procjenu troška plaćenog plana.
Sažetak u pet rečenica
- Svi modeli procesa rade iste poslove, a razlikuju se po redoslijedu i broju ponavljanja: vodopad i V-model jednom i redom, spirala u krugovima vođenim rizikom, Scrum u sprintovima, Kanban u stalnom toku.
- Pristup se bira prema stabilnosti zahtjeva, kritičnosti, dostupnosti naručioca, vrsti posla i veličini tima, a hibridi su u praksi česti.
- Agilno planiranje procjenjuje bodovima i planning pokerom, a broj sprintova je backlog podijeljen brzinom tima: za DeliveryApp 2.0 to je 126 / 21 = 6 sprintova i budžet od 40.000 €.
- Rizicima se upravlja dok su jeftini (prepoznaj, procijeni, odgovori, prati), a Brooksov zakon i formula n(n − 1)/2 objašnjavaju zašto dodavanje ljudi kasno u projektu usporava.
- Kvalitet se ugrađuje kroz upravljanje konfiguracijom, Definiciju gotovog i pregled koda, a proces se stalno poboljšava kroz PDCA i retrospektive.