Bez obzira na to jeste li već čuli za scrum metodologiju ili je ovo vaš prvi susret s njom, nadamo se približiti osnovne prednosti i možda pomoću scruma unaprijediti i vaš poslovni život.
Scrum se najviše spominje kao agilna metodologija izrade softverskih rješenja, međutim primjene su višestruke. Jednom kad naučite scrum – možete ga koristiti prilikom vođenja projekta, organizacije privatnog života pa čak i planiranja vjenćanja.
Po definiciji, scrum je metodologija uz čiju pomoć možete rješavati kompleksne probleme te produktivno i kreativno isporučivati proizvode najveće moguće vrijednosti.
Scrum je jednostavna metodologija koja olakšava ljudima, timovima i organizacijama da isporuče vrijednost kroz prilagođena rješenja kompleksnih problema. Ime mu je poteklo iz ragbi terminologije i generalno dijeli neke karakteristike s tim sportom. Ideja je da lopta/zadatak mijenja ruke od jednog do drugog igrača (svaki sa specifičnim zadatkom) i svaka ta izmjena za cilj mora imati kretanje unaprijed.
Osnovni koraci i dionici scrum tima su:
- Product owner naručuje kompleksni projekt čiji se detalji zapisuju u „product backlog“
- Scrum tim – odabire dijelove projekta te ih kroz jedan segment procesa (sprint) pretvara u inkrementalnu vrijednost
- Scrum tim i dionici pregledavaju rezultate te dogovaraju potrebne prilagodbe za sljedeći sprint
- Svi koraci se ponavljaju do isporuke finalnog proizvoda
Osnovne ideje ove metodologije su da predstavlja praktičnu organizacijsku pomoć baziranu na 3 osnovne ideje
- “rastavi pa vladaj” (rastavi kompleksno u jednostavno)
- Kompliciran posao rastavi u jednostavne dijelove
- Rastavi ukupno planirano vrijeme u kratke cikluse
- Smanji veliku organizaciju u manje timove
- pregledaj i prilagodi se
- Redovito pregledaj planove i provjeri pretpostavke
- Optimiziraj vrijednost koju donosi proizvod
- Neprestano unapređuj svoj proces
- budi transparentan – ljudi donose bolje odluke kad imaju sve informacije
Za što se scrum koristi?
Kao metodologija, inicijalno je implementiran od strane timova koji su se bavili razvojem softvera u devedesetim godinama prošlog stoljeća.
Zamišljen je kao pomoć u proizvodnji boljeg softvera u kraćem vremenu, a taj proces usrećuje i kupce. Pokazalo se da osim kupaca, implementacija scruma čini i timove sretnijima. Danas se pretpostavlja da se u čak 73% agilnih softverskih projekata koristi scrum kako bi se skratilo vrijeme potrebno da proizvod dođe na tržište. Kao što smo već spomenuli, scrum nije isključiv i ne upotrebljava se samo u svijetu razvoja softvera. Postao je uvelike korišten i u drugim industrijama kao što su: novinarstvo, školstvo i fizička proizvodnja jer bez obzira na to kojom djelatnošću se timovi bave, scrum im omogućuje da to rade:
Bolje – u scrum metodologiji, kupac je u centru dizajna i razvoja, što osigurava da proizvodi koji se isporučuje zadovoljava sve želje i potrebe naručitelja
Brže – scrum timovi neprestano provjeravaju i prilagođavaju svoje procese kako bi se kroz kontinuirani napredak proizveli više u manje vremena
Sretnije – scrum ohrabruje timove na donošenje brzih odluka i primjenu talenata, što vodi i većem zadovoljstvu zaposlenih
Zašto Scrum ili Kanban, a ne waterfall metode i kada odabrati agilno?
Waterfall metoda prikladna je za jednostavnije projekte koji se odvijaju linearno te ne dozvoljava povratke u prijašnju fazu razvoja – ili su ti povratci iznimno skupi i neisplativi. Pojednostavljeno, kod waterfall metode, klijent daje sav input na početku projekta te na kraju dobiva gotov proizvod. Ukoliko išta pođe po krivu (došlo je do nesporazuma, klijent se naknadno sjetio da treba još neku funkcionalnost itd..), popravci već isporučenog proizvoda mogu biti opsežni (skupi) ili u potpunosti nemogući.
Agilne metode „razbijaju“ projekt na manje, iterativne periode. U glavnom fokusu Kanbana je unaprijeđenje procesa, dok je scrum fokusiran na obavljanje što više posla u što kraćem vremenu.
Agilni projekti generalno gledajući mogu biti jeftiniji i proizvodi se mogu brzo isporučiti. Pružaju veću fleksibilnost, ali jednako tako i rezultati su teže predvidivi. Waterfall projekti znaju biti skuplji i njihov dovršetak može duže trajati.
Waterfall metode puno manje su koncentrirane na krajnjeg korisnika ili proizvod te su česte promjene potreba krajnjih korisnika previđaju. Krajnji korisnik nije član razvojnog tima, a često nije niti upućen u tijek projekta – stoga se zna dogoditi i da mu krajnji proizvod često bude neprihvatljiv.
Može li se scrum pojednostavniti i koristiti i u manjim timovima?
Prema Scrum vodiču, idealan Scrum tim sastoji se od najmanje 3 i ne više od 9 članova. Tečajevi agilnog razvoja spominju brojku od 5 do 7 članova tima, te izičito napominju da iako timovi od 20 ili više ljudi mogu biti visokoproduktivni, to se ne može nazvati scrum metodologijom. A što je s manjim timovima?
Iako ih stručnjaci vjerojatno ne bi nazvali scrum timovima – postoji način da i manji timovi svoje projekte odrađuju po scrumu.
Kako?
Jedna od bitnih preduvjeta kojih treba biti svjestan svaki član manjeg tima je da će možda u timu morati igrati dvostruku ulogu i preuzimati zadatke koje mu u klasičnom scrum timu možda ne bi bili dodijeljeni.
Tko su članovi scrum tima?
Scrum tim ima 3 specifične role: product ownera (vlasnik proizvoda), scrum mastera i development tim (razvojni tim).
Obzirom da su scrum timovi funkcionalni, razvojni softverski tim obično uključuje testere, UX dizajnere i developere.
Kako prilagoditi scrum malom timu?
Kroz naše bogato iskustvo izrade vlastitih aplikativnih rješenja kao što su MyIntranet ili aplikativnih rješenja po narudžbi klijenta, u DuplicoIT isprobali smo razne metodologije razvoja softvera. Ukoliko je bila riječ o manjim projektima ili manjim timovima, optimalnim se pokazalo rješenje izrade projektnog backloga nakon kojeg smo planirali svaki sprint. Radi brzine izrade i lakše komunikacije u malom timu, dnevni standup nije bio nužan, kao ni product ni sprint backlogovi.
Vodili smo računa o tome da svi članovi tima i svakom trenutku budu informirani o statusu projekta, a revizije i retrospektive sprinteva mogle su se odraditi u jednoj ceremoniji, posljednji dan sprinta. Ciklus bi ponovo započinjao planiranjem i daljnjim logičkim koracima.
Obzirom na obujam projekta i izrađeni backlog, product owner nije bio potreban u svakom koraku projekta, ali je u svakoj fazi projekta imao pristup aktualnim informacijama, a nakon uhodavanja tima, prisutnost scrum mastera se također svela na minimum. Inzistirali smo samo na tome da svi članovi tima budu prisutni na planiranju i reviziji. Ovaj pristup ubrzao je naše procese izrade aplikacija, pojednostavio komunikaciju između članova tima i dao odlične rezultate u vidu zadovoljstva gotovim proizvodom.
Bez obzira na to koju metodologiju razvoja softvera preferirate, ukoliko želite aplikativna rješenja napravljena upravo po mjeri vašeg poslovanja – na način koji vama odgovara, obratite nam se s povjerenjem.