Proces i organizacija projekta

Šta učimo ovog semestra (1–5)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas: poglavlje 2 (označeno). Isti primjer kroz knjigu: DeliveryApp 2.0.

Šta učimo ovog semestra (6–10)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas je poglavlje 2. Isti primjer kroz knjigu: DeliveryApp 2.0.

Priča za početak

Priča za početak

Literatura

1. I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlja 2, 3, 22, 23).
2. R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner's Approach, 9th ed., McGraw-Hill, 2019.
3. F. P. Brooks: The Mythical Man-Month, Anniversary ed., Addison-Wesley, 1995.

Zašto ovo poglavlje

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.

Riječi ovog poglavlja (1/3)

• 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.

Riječi ovog poglavlja (2/3)

• 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.

Riječi ovog poglavlja (3/3)

• 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

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.

2.1 Klasični modeli razvoja

Ukratko – 2.1 Klasični modeli razvoja

• 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:

2.2 Agilni pristupi i uloge u timu

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.

2.2 Agilni pristupi i uloge u timu

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).

Ukratko – 2.2 Agilni pristupi i uloge u timu

• 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:

2.3 Kako izabrati pristup

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.

Ukratko – 2.3 Kako izabrati pristup

• 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.

2.4 Planiranje i budžet; agilno planiranje

Brzina tima i plan izdanja. Tim DeliveryApp je u četiri sprinta verzije 1.x završio 18, 22, 20 i 24 boda. Prosjek je

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.

2.4 Planiranje i budžet; agilno planiranje

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.

Ukratko – 2.4 Planiranje i budžet; agilno planiranje

• 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

1. Šta je u centru spiralnog modela? Procjena i smanjivanje rizika na početku svakog kruga.
2. Ko u Scrumu odlučuje o redoslijedu backloga? Vlasnik proizvoda.
3. Tim je završio 15, 25 i 20 bodova; backlog ima 100 bodova. Koliko sprintova? Brzina 20, pa 100 / 20 = 5 sprintova.

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

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:

1. Prepoznaj – tim zajedno nabraja šta bi moglo poći naopako: tehnika, ljudi, naručilac, zakon, dobavljači.
2. Procijeni – za svaki rizik vjerovatnoću (1–5) i uticaj (1–5). Proizvod V × U daje prioritet.
3. Odgovori – izbjegni (promijeni plan da rizik nestane), ublaži (smanji vjerovatnoću ili uticaj), prenesi (osiguranje, ugovor) ili prihvati (i prati).
4. Prati – registar rizika se pregleda na svakoj retrospektivi.

Registar rizika DeliveryApp 2.0:

2.5 Upravljanje rizicima

2.5 Upravljanje rizicima

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.

Ukratko – 2.5 Upravljanje rizicima

• 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

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.

2.6 Ljudi i timski rad

2.6 Ljudi i timski rad

Faze razvoja tima. Psiholog Bruce Tuckman opisao je 1965. četiri faze kroz koje prolazi svaka grupa:

1. Formiranje – ljudi su ljubazni i oprezni, uloge nisu jasne.
2. Sukobljavanje – pojavljuju se razmimoilaženja oko načina rada; prirodno je i korisno ako se razgovara.
3. Normiranje – tim se dogovori oko pravila (npr. Definicija gotovog, pravila pregleda koda).
4. 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.

2.6 Ljudi i timski rad

Ukratko – 2.6 Ljudi i timski rad

• 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:

2.7 Verzioniranje i upravljanje kvalitetom

1. Definicija gotovog – stavka je gotova tek kad je kod u Gitu, prošao pregled kolege, testovi prolaze automatski i kriteriji prihvatanja su provjereni.
2. Pregled koda – nijedna izmjena ne ide u glavnu granu bez da je pročita još jedan član tima.
3. 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 – 2.7 Verzioniranje i upravljanje kvalitetom

• 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:

2.8 Poboljšanje procesa i alati

2.8 Poboljšanje procesa i alati

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 – 2.8 Poboljšanje procesa i alati

• 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

1. Koliko kanala komunikacije ima tim od 8 ljudi? 8 × 7 / 2 = 28.
2. Rizik ima vjerovatnoću 3 i uticaj 5. Koji je prioritet? 15, visok; rješava se rano.
3. Šta je retrospektiva u terminima PDCA? Mali PDCA ciklus: tim bira jednu promjenu, isproba je i provjeri efekat.

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

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 odbija

Korak 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

1. Projects → New project → Board, kolone Backlog, Spremno, U radu, Pregled, Gotovo; WIP ograničenje za U radu: 3.
2. Napravite Milestone „v2.0.0” s datumom za 12 sedmica i dodijelite mu stavke.
3. 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žba za studenta 1 – izbor modela.

Vježba za studenta 1 – izbor modela. – rješenje

Vježba za studenta 2 – brzina i budžet.

Vježba za studenta 2 – brzina i budžet. – rješenje

Vježba za studenta 3 – Brooksov zakon.

Vježba za studenta 3 – Brooksov zakon. – rješenje

Vježba za studenta 4 – rizici.

Vježba za studenta 4 – rizici. – rješenje

Sažetak u pet rečenica

1. 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.
2. Pristup se bira prema stabilnosti zahtjeva, kritičnosti, dostupnosti naručioca, vrsti posla i veličini tima, a hibridi su u praksi česti.
3. 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 €.
4. 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.
5. Kvalitet se ugrađuje kroz upravljanje konfiguracijom, Definiciju gotovog i pregled koda, a proces se stalno poboljšava kroz PDCA i retrospektive.

Pitanja za ponavljanje

1. Šta kaže Brooksov zakon i kako je nastao?
2. Opišite vodopad, V-model i spiralni model. Kada je koji dobar izbor?
3. Navedite tri odgovornosti, tri artefakta i pet događaja Scruma.
4. Po čemu se Kanban razlikuje od Scruma? Šta je WIP ograničenje?
5. Koja pitanja postavljamo pri izboru pristupa razvoju?
6. Zašto agilni timovi procjenjuju bodovima, a ne satima? Šta je planning poker?
7. Kako se računa broj sprintova za backlog? Izračunajte za DeliveryApp 2.0.
8. Opišite četiri koraka upravljanja rizicima i četiri moguća odgovora na rizik.
9. Napišite formulu za broj kanala komunikacije i izračunajte je za 6 i 9 ljudi.
10. Navedite Tuckmanove faze razvoja tima. Šta je psihološka sigurnost?
11. Šta je upravljanje konfiguracijom i šta znače tri broja u verziji 1.4.2?
12. Šta je PDCA ciklus? Nabrojte nivoe zrelosti CMMI.