Scrum je još jedna od metodologija agilnog razvoja softvera, koja se kao i ostale metodologije iz iste grupe odlikuje adaptibilnošću i lakim unošenjem projektnih promena u letu. Posebno je pogodna za dugotrajne i kontinuirane razvoje, gde je česti slučaj da se nakon godinu dana razvoja inicijalni zahtevi izmene usled promena na tržištu ili pojava novih tehnologija.

Princip Scrum-a se ogleda u sledećem – umesto dugotrajne izgradnje velikog sistema u kom će učestvovati veliki broj ljudi, organizacija posla će se razbiti na manje i kraće segmente sistema i manje timove. Svaki segment će biti kao mini-projekat za sebe, na njemu će raditi određen broj ljudi iz razvojnog tima i po završetku njihovog rada isporučiće završenu jedinicu koja će se uklopiti u celokupan sistem.

Plan aktivnosti u Scrum-u se definiše putem sprintova. Sprint je jedan određeni period vremena (najčešće se meri brojem nedelja, i u zavisnosti od potreba projekta iznosi između 1 i 4 nedelje) tokom kojeg će razvojni tim odraditi jedan zahtev projekta i isporučiti ga naručiocu. Nakon svakog završetka ciklusa voditelj projekta planria aktivnosti za naredni sprint i na osnovu njih dodeljuje zadatke razvojnim timovima.

Tipična Scrum organizacija podrazumeva i određene uloge dodeljene pojedincima koji rade na projektu. Te uloge su sledeće:

– vlasnik projekta je, kao i uvek, predstavnik naručilaca projekta. Njegov zadatak je da konstantno prenosi viziju željenog rezultata razvojnom timu, kao i da nadgleda i odobrava rezultate prikazane nakon svakog sprinta. U većim projektima/organizacijama njegove aktivnosti se dodatno proširuju, no krajnja suština je da je on spona između razvojnog tima i naručilaca projekta – on postavlja zahteve i njemu se isporučuju rezultati.

– razvojni tim podrazumeva manje ili više grupa ljudi koji su u mogućnosti da funkcionišu kao samoorganizujuća celina. Obično u timu bude jedan predvodnik (team leader) i nekoliko članova drugih profila, od developera do dizajnera, inženjera, QA analitičara itd. Tokom svakog sprinta svaki tim je obavezan da uvidi na koji način će zadovoljiti zahteve projekta za taj sprint, organizuje aktivnosti i na kraju isporuči željeni rezultat.

– Scrum master je osoba koja se ponaša kao posrednik između vlasnika projekta i razvojnog tima. On sagleda širu sliku i stanje celokupnog projekta, radi na otklanjanju potencijalnih problema koji bi onemogućili razvojni tim da isporuči zacrtani rezultat, time garantujući efikasnost i produktivnost razvojnog tima. On takođe i servira rezultate vlasniku projekta i savetuje ga o daljim planovima i aktivnostima koje mogu poboljšati rezultate razvoja ili konačnog proizvoda.

Gde se ogleda adaptibilnost Scrum-a?

Prvo i najosnovnije – novi plan se formira nakon svakog sprinta, što znači da je u tom trenutku moguće menjati stare planove, stavljati prioritet na određene segmente i forsirati ih zbog njihove važnosti. Ovo je takozvana Ahilova peta starih metodologija razvoja softvera (poput Waterfall modela) čijim se pridržavanjem nakon višegodišnjeg razvoja dobija kao rezultat zastareo proizvod, ili dolazi do prekoračenja roka i budžeta usled letećih promena unetih u zahteve u toku izrade sistema.

Pored toga, slično Kanbanu, Scrum omogućava fina podešavanja unutar same organizacije projekta. Na primer, dužina sprinta je nešto što se bira na početku ali i što se vremenom može menjati ako se proceni da će druga vrednost doneti bolje rezultate. Isto važi i za količinu posla dodeljenog za jedan sprint (u Scrum-u nazvano velocity). Takođe, Scrum razvojni tim je uvek multifunkcionalan, što znači da sadrži ljude različitog profila. Ko će pripadati kojem timu određuje menadžment na početku projekta, ali je i to nešto što se može menjati tokom projekta sa ciljem podizanja efikasnosti i produktivnosti.

Dodatno, Scrum kao obaveznu uvodi i jednu zanimljivu tehniku – dnevne standup sastanke tima. Ti sastanci se obično održavaju u isto vreme i na istom mestu, vrlo su kratki (do 15min) i nazivaju se standup zato što je zamisao da svi učesnici stoje (baš kako bi se stavio akcenat na što brži i efikasniji tok sastanka). Na tim nalaženjima obično svaki od članova tima ukratko obavesti ostale na čemu će raditi tog dana, kakav mu je plan i da li ima nekih problema u postizanju zacrtanog cilja. Ovo je vrlo pogodan način za praćenje toka razvoja i vrlo često se praktikuje, ne vezano za to da li se koristi Scrum metodologija ili neka druga.

Odakle potiče naziv Scrum?

Vervali ili ne, naziv Scrum potiče iz ragbija. Ko je nekada gledao taj sport biće mu jasnije, no u ragbiju postoji jedna faza igre u kojoj se svi igrači oba tima okupe na gomilu i zajedničkim snagama pokušavaju da osvoje bolju poziciju na terenu i loptu, i ta faza se upravo naziva scrum. Tvorcima Scrum metodologije se svideo ovaj pristup u kom postoji jedan tim ljudi različitih profila i sposobnosti koji zajedničkim snagama rade na ostvarivanju zacrtanog cilja, pa su stoga odlučili i da upotrebe naziv iz popularnog sporta.

Ukoliko želite da saznate više o Scrum metodologiji, preporučujemo vam e-knjigu “Kanban and Scrum” u kojoj možete naći više detalja o jednoj i drugoj metodologiji. Knjiga je besplatna i možete je preuzeti ovde.

Kanban je jedna od danas vrlo popularnih i često korišćenih metodologija agilnog razvoja softvera, a glavni fokus Kanbana se zasnva na fleksibilnosti i kontinuiranim promenama tokom razvoja. Kroz Kanban principe, koji nisu komplikovani, razvojni tim je u mogućnosti da lakše upravlja svojim resursima, prati trenutno aktivne zadatake i time jasnije sagleda trenutno stanje projekta i bolje planira buduće aktivnosti.

Suština Kanban metodologije je tabla (board) podeljena u šest vertikalnih sekcija (broj sekcija nije striktan i može se menjati u zavisnosti od dogovora). Svaka od sekcija predstavlja stanje jednog razvojnog zadatka (task), a ideja je da svaki task, kako bude napredovao ka svom završetku, prelazi iz jedne sekcije u drugu, i to sekvencijalnim putem, bez preskakanja.

Tipična Kanban tabla sadrži sledeće sekcije:

• backlog – izvor taskova, kojim najčešće upravlja naručilac projekta. On generiše zadatke i smešta ih u ovu sekciju
• ready – taskovi koji su u potpunosti jasni razvojnom timu i spremni su za početak njihovog rešavanja
• coding – taskovi koji se trenutno rešavaju
• testing – taskovi čija se rešenja trenutno testiraju
• approval – taskovi koji su uspešno prošli proces testiranja i čekaju na odobrenje za puštanje u produkciju
• done – taskovi koji su uspešno pušteni u rad. Ovo je izlazna sekcija i krajnje stanje svakog zadatka

Kako radi Kanban? Prosto, generisani taskovi se stavljaju u prvu sekciju, sortiraju se po želji znajući da će task sa vrha uvek prvi biti preuzet u narednu sekciju. Svaki od zadataka prolazi kroz sva stanja svojim tempom, s obzirom da su neki taskovi mali i mogu se brzo završiti, dok su neki drugi širi, obimniji i za njih je potrebno više vremena.

Ideja Kanbana je da se ograniči broj taskova koji se mogu naći u svakoj od kolona Kanban table (takozvani Work In Progress parametri – WIP). Multitasking je ubica efikasnog rada, zato što iziskuje konstantne napore i vreme utrošeno na promenu konteksta rada (praktično za skakanje sa zadatka na zadatka), i zbog toga se Kanban fokusira na ograničavanje maksimalnog broja zadataka na kojima se radi.

To prosto znači da ako imamo limit na nekoj sekciji i ako je on trenutno ispunjen – da nijedan task iz prethodne sekcije (iako je možda spreman za prelazak) ne može preći u tekuću dok se u njoj ne oslobodi mesta. Ovo može zvučati problematično i kao neka pojava koja će gušiti i usporavati rad na projektu, međutim u realnosti je sasvim druga priča – time se sprečava preopterećenje članova razvojnog tima, a i forsira se kontinuiran rad kroz projekat. Drugim rečima – ako su neki zadaci zaglavili i blokiraju resurse, treba učiniti dodatan napor oko njih i rešiti problem, a ne ostaviti ga da se razvija svojim preterano sporim tokom i nastaviti rad na drugom mestu.

Magija Kanbana

Upotrebom Kanbana razvojni tim može doći do vrlo bitnih statistčkih podataka i saznanja koja mogu iskoristiti kako bi unapredili efikasnost. Praćenjem nekih osnovnih parametara poput vremena potrebnog za svaki zadatak da prođe kroz sve sekcije (cycle time), zatim vremensko praćenje broja zadataka u svakoj od sekcija, razvojni tim može videti koji deo razvoja je najproblematičniji i šta usporava rad. Te informacije se zatim mogu upotrebiti u baždarenje – povećavanje ili smanjivanje limita (WIP parametara) za svaku od sekcija, čime će se razvojni proces manje ili više izmeniti, a kao glavni cilj baždarenje traži se minimizacija prosečnog vremena potrebnog za završetak jednog zadtka. Kroz ovu optimizaciju razvojni tim će biti u stanju i lakše da predvidi vreme neophodno za završetak nekog novog zadatka.

Još jedna koncepcijska razlika kod Kanbana, u odnosu na druge metodologije razvoja softvera, je to što nema striktno definisanih uloga i jasno definisanih rokova, već se uloge raspodeljuju dinamično, i po trenutnom stanju na tabli, dok se rokovi mogu, ali i ne moraju zacrtavati, s obzirom da se dobrim planiranjem i preciznom analizom statističkih podataka mogu predvideti vremenski trenuci završetka svakog zadatka.

Kako isprobati Kanban

Postoje razni task-management alati koji podržavaju Kanban metodologiju, a ukoliko sami želite da isprobate i dalje istražite Kanban principe mi vam preporučujemo Kanbanery, koji je besplatan za projekat sa samo jednim korisnikom. Takođe, preporučujemo vam i e-knjigu “Kanban and Scrum” u kojoj možete pročitati više detalja o jednoj i drugoj metodologiji, njihove međusobne sličnosti i razlike. Knjiga je takođe besplatna i možete je preuzeti ovde.