Scrum – agilni proces razvoja softvera

Priprema, pozor, Scrum!

mainScrum je metodologija razvoja softvera temeljena na agilnim principima, te ga karakterizira iterativni i inkrementalni pristup razvoju softvera. On je izuzetno pragmatična disciplina koja vrijednost za krajnjeg korisnika stavlja ispred ugovornog pregovaranja, prilagodbu ispred planiranja, te pojedinca ispred procesa i alata. Dok se tradicionalne metodologije bezuspješno bore protiv promjena tijekom trajanja projekta i pokušavaju unaprijed anticipirati sve zahtjeve korisnika, Scrum prihvaća realnost i prilagođuje se promjenama koje su u softverskom razvojnom procesu neizbježne.

 

Prilagodba, nadzor, transparentnost. To su tri glavna principa kojima možemo opisati Scrum. Scrum kao empirijski proces za upravljanje i razvoj softvera bazira se na konstantnom nadzoru i učestaloj prilagodbi, a glavni preduvjet toga je otvorenost razvojnog tima unutar sebe, ali i transparentnost prema korisniku ili naručitelju. Scrum je jedna od nekoliko agilnih metoda razvoja, kao što su i XP (Extreme Programming), DSDM (Dynamic System Development Method) ili Crystal. Temelj svih agilnih principa razvoja softvera sadržan je u agilnom manifestu kojeg su 2001. sastavili najveći autoriteti softverske industrije kao što Robert C. Martin, Martin Fowler i Ken Schwaber koji je ujedno i jedan od autora Scruma. Agilni manifest ne razrađuje metodologiju nego samo definira principe razvoja softvera. Ti principi ujedno su i temelj Scruma.

Od kuda ime Scrum? Da li je riječ o još jednom u nizu nezanimljivih akronima? Ne, Scrum zaista nije akronim. Poznavatelji ragbija sigurno znaju značenje riječi Scrum u toj igri, a on označava trenutak nakon prekida kada se protivnički timovi sakupljaju na hrpu i bore za posjed lopte. Svakim prekidom tim se pomiče prema cilju i zauzima nove pozicije. Ekipa koja je nadmoćna svakim prekidom (scrumom) sve je bliža protivničkoj liniji i ostvarenju cilja. Na putu prema cilju, tim ne pokušava predvidjeti sve situacije u igri, nego se stalno prilagođava trenutnoj situaciji na terenu, a glavni im je cilj progurati loptu što bliže protivničkoj liniji i na kraju naravno postići zgoditak. Scrum proces razvoja softvera upravo je to, iterativni proces u kojem cijeli tim gradi igru pomičući se sve bliže glavnom cilju, postizanju zgoditka, završetku jednog uspješnog projekta. Upravo Scrum kao metafora timskog inkrementalnog kretanja ka cilju inspirirala je osnivače ove metodologije (Ken Schwaber i Jeff Sutherland) da početkom prošlog desetljeća definiraju sasvim novu metodologiju razvoja softvera.

 

Uređeni kaos

scrum_lifecycleScrum često zovemo metodologijom, ali ako želimo biti posve precizni, Scrum to nije. Scrum je okvir (framework) metodologije razvojnog procesa i za razliku od nekih drugih agilnih metodologija kao što su XP ili Crystal, Scrum ne definira detalje procesa već daje okvir unutar kojega tim stvara proces prilagođen sebi, odnosno proces čija je karakteristika konstanto usavršavanje i prilagodaba timu koji ga provodi.

Kao i sve druge agilne metodologije, Scrum je inkrementalni i iterativni pristup razvoju softvera. Inkrementalni razvoj predstavlja razvoj softvera korak po korak, dok iterativni način predstavlja strategiju vremenskog planiranja u kojem se softver kroz svaki definirani period vremena dodatno usavršuje. Osnovna vremenska cjelina Scruma jest sprint. Sprint je zaokružena jedinica razvojnog procesa koja najčešće traje 30 kalendarskih dana. Unutar svakog sprinta, Scrum prolazi kroz sve faze razvojnog procesa. Planiranje, programiranje, testiranje i isporuka ponavljaju se kroz svaki slijedeći sprint. Na kraju svakog sprinta razvojni tim isporučuje zaokruženi dio proizvoda, odnosno potencijalno isporučiv inkrement proizvoda. Razbijanjem razvojnog procesa na sprintove, Scrum smanjuje rizik od isporuke lošeg softvera, softvera koji neće zadovoljiti tržište, a ujedno se time i lakše prilagođuje novim i promijenjenim zahtjevima korisnika koji su neizbježni. No, Scrum se ne zaustavlja na tome, pa i svaki pojedini sprint dodatno razbija na još manje dijelove koji traju točno 24 sata, a počinju i završavaju dnevnim scrumom. Dnevni scrum jedna je on malobrojnih obaveza cijelog razvojnog tima, a nužan je da bi se postigla unutarnja transparentnost u timu. To je stand-upsastanak na kojem svi članovi razvojnog tima u neformalnom okupljanju od 15-ak minuta odgovaraju na točno 3 pitanja:

1. Što je urađeno jučer?

2. Što će se raditi danas?

3. Kakve nam prepreke stoje na putu?

Za provođenje dnevnog scruma kao i cijelog razvojnog procesa odgovoran je Srcum master. Scrum master donekle odgovara ulozi voditelja projekta, iako Scrum strogo gledajući ne poznaje ulogu voditelja projekta. Scrum način razvoja softvera u svojoj je biti samoorganizirajući proces te kao takav ne zahtjeva ulogu voditelja, barem ne u onom smislu kako se tradicionalno takva uloga opisuje. Scrum master ima ulogu prvenstveno kontrolirati proces, ali ne i ljude u timu. Umjesto da raspoređuje posao i govori svim članovima tima što da rade, Scrum master nadzire proces i brine se o tome da se on poštuje.

 

Samoupravljanje na dijelu

Jedna od osnovnih krilatica Scruma kaže „Ako hoćeš da preuzmem odgovornost, daj mi i ovlasti“. Vlast i odgovornost morali bi uvijek ići ruku pod ruku. Što se događa kada vlast nema odgovornost, nije potrebno posebno opisivati, ali isto tako ako od nekoga tražimo odgovornost za određeni posao, zadatak ili projekt, moramo mu dati sve potrebne ovlasti. To je upravo ono što kaže Scrum, te razvojnom timu daje potpunu slobodu samoorganizacije. Tim se obvezuje samo na ono na što sam procjeni da se može obvezati, a na putu prema cilju, tim sam odlučuje što će i kako raditi kako bi ostvario cilj, odnosno isporučio ono na što se je obvezao. Dati razvojnom timu toliku slobodu, menadžerima naviklima na klasični način rukovođenja, često djeluje kao rizična odluka i ovo je zbog toga u praksi jedna od najučestalijih prepreka uvođenja i provođenja Scruma. Međutim, isto tako praksa pokazuje da se to isplati jer takav tim donosi rezultate i opravdava dano povjerenje.

Što to zapravo znači? Kako izgleda jedan sprint u Scrum razvojnom procesu? Sprint započinje sastankom planiranja (Sprint planning meeting). Tijekom sastanka definira se sprint backlog, popis svojstava koje treba ugraditi u nadolazeći sprint. Sprint backlog nastaje na osnovi product backloga, popisa svih svojstava koje treba ugraditi u proizvod sortiran prema prioritetu kako ih vidi sam korisnik. Na vrhu product backolga nalaze se najvažnija svojstva, a na dnu ona sa najmanjim prioritetom. Tijekom sastanka, tim procjenjuje koliko svojstava iz product backloga može staviti u sprint backlog. Na osnovi sprint backloga sastavljaju se ciljevi sprinta, a sastanak završava pristankom cijelog tima da preuzme odgovornost i obveže se ispuniti te ciljeve u idućih 30 dana. Tijekom trajanja sprinta izbjegava se svaka mogućnost vanjskog utjecaja na ciljeve sprinta, a svi eventualni zahtjevi za promjenama dodaju se u product backlog i predmet su rasprave za slijedeći sprint. Scrum zahtjevima korisnika kaže „Da, ali ne u ovom sprintu!“. Tijekom sprinta članovi razvojnog tima imaju samo dvije obaveze, ispuniti ciljeve sprinta i redovito dolaziti na dnevne scrum sastanke. Na kraju uspješno završenog sprinta pakira se isporučevina, odnosno inkrement sprinta te se prezentira nositelju proizvoda (product owner), korisnicima i drugim zainteresiranim stranama. Nakon što se napravi retrospektiva sprinta i unesu podaci u product backlog, sprint je službeno završio, a time i slijedeći počeo. Sprint traje uvijek jednako vrijeme te nije određen niti resursima niti planiranim zadacima nego jedino dogovorenim vremenskim razdobljem. Vrijeme je jedina nepromjenjiva konstanta u planiranju sprinta.

scrum_papiri

Odnos sa korisnicima

Ostvarivanje otvorenog i iskrenog odnosa sa korisnikom ili naručiteljem softverskog rješenja jedan je od najvažnijih aspekata Scruma. Nažalost, ovo je i jedan od najčešćih kamena spoticanja provođenja Scruma u praksi. Tradicionalni ugovorni odnos sa naručiteljem u kojemu orijentacija na naručitelja odnosno korisnika traje samo za vrijeme do potpisivanja ugovora i na kraju neposredno prije isporuke, u softverskoj industriji jednostavno ne funkcionira. Želimo li uspješan projekt, trebamo se svim silama truditi imati korisnika tijekom cijelog razvoja što bliže sebi. Naručitelj odnosno korisnik treba biti svjestan svoje važnosti u procesu razvoja. On je taj koji odlučuje što stoji gore, a što dolje u listi svojstava (product backlog). On je taj koji na kraju svakog sprinta preuzima potencijalno isporučiv proizvod te na njega daje svoje primjedbe i želje za daljnjim promjenama. On je taj koji zahtjeve treba izreći i iza njih stajati. Bez korisnika u Scrum procesu, zapravo nema ni Scruma. Učestalom suradnjom sa korisnicima, postići ćemo da krajnji proizvod bude upravo ono što korisnici očekuju. Uskladiti očekivanja korisnika i razvojnog tima je proces i ne može se postići jedim ugovorom ili jednim kick-offsastankom. Razvoj softvera više nalikuje istraživačkom poslu nego proizvodnoj traci i zbog toga nužna je stalna retrospektiva i od strane tima i od strane korisnika da bi završni proizvod bio ono što želimo.

 

Scrum u bitovima

scrumproces Scrum je proces, odnosno preciznije okvir procesa razvoja softvera i za njegovo provođenje nije preduvjet niti jedan programski jezik niti razvojna okolina. Za osnovne artefakte Scruma kao što su product backlog, sprint backlog, ciljevi i rezultati sprinta mogu se koristiti rukom ispisani papirići ili u boljem slučaju Excel tablice, te se i bez pomoći bilo kojeg alata za upravljanje razvojnim procesom može provoditi Scrum. Međutim, korištenje dobrih alata za upravljanje razvojnim procesom koji u sebi sadrže sve što je potrebno za provođenje Scruma sigurno će uvelike pomoći u životu Scrum projekta. Alati za upravljanje razvojnim procesom ili kako ih u zadnje vrijeme zovemo ALM (Application Lifecycle Management) alati svakako su dobrodošli u svaki ozbiljniji razvojni tim. No, koliko su ti alati prilagođeni Scrum procesu? Na prvi pogled loša vijest je da niti jedan od takvih alata nije posebno pripremljen za Scrum. Međutim, dobra vijest je da se neki od ALM alata lako mogu prilagoditi Scrumu. Microsoft ALM sustav baziran na Microsoft Team Foundation Serveru (TFS) lako se prilagođava raznim razvojnim procesima. Proces je u Microsoft TFS-u definiran metodološkim predloškom, te dolazi sa već nekoliko predefiniranih predložaka za neke od razvojnih procesa. Najbliži Scrumu je MSF Agile predložak koji se u nekim segmentima poklapa sa Scrumom. Dodatno postoje vanjski predlošci koji se mogu dodati u sustav, a među takvima je i nekoliko onih koji su upravo Scrum metodološki predlošci. Najpoznatiji je Scrum for team system predložak firme EMC Consulting, a od nedavno je i Microsoft izdao vlastiti Microsoftov Visual Studio Scrum, predložak za TFS izrađen od strane Microsoft razvojnog tima. Oba predloška omogućit će vam provođenje Scruma kroz Microsoft ALM i oba dva predloška su potpuno besplatna. EMC predložak sadrži sve navedene artefakte i principe Scruma, ali je relativno kompleksan za korištenje. Microsoftov je jednostavniji, ali i siromašniji. Ako ste novi u Scrumu svakako će vam u prilagodbi na proces pomoći alat koji će vas voditi, a s vremenom kada sazrijete poželjet ćete u njega ugraditi nešto svoje, pravila ili ideje prilagođene vašem razvojnom timu. Metodološki predlošci u TFS-u to vam omogućuju, štoviše predviđeni su za nadogradnje i mijenjanje. U ostalom, jedan od principa Scruma i jest trajno usavršavanje procesa, te kao što vas Scrum potiče da budete kreativni i spremni na promjene i njima se prilagodite, tako je i sam Scrum proces predviđen da se mijenja i prilagođuje vama i vašem timu. Osnove Scruma su jednostavne te je najbolji način da ga usvojite taj da ga počnete primjenjivati, a zatim ga usavršavate iterativno i inkrementalno. Scrum trenutno koriste gotovo sve najveće svjetske softverske kompanije, među njima i divovi industrije kao što su Microsoft, IBM i SAP. Ako vaš razvojni tim još ne živi Scrum, možda se možete barem u tome ugledati na njih i krenuti u vaš prvi sprint.

 

Agilni manifest

  • Pojedinci i interakcija važniji su od procesa i alata
  • Softver koji radi važniji je od detaljne dokumentacije
  • Kolaboracija s korisnikom važnija je od ugovornog pregovaranja
  • Odgovor na promjenu važniji je od praćenja plana

 

kSchwaber

Scrum Pojmovnik

Sprint– osnovna vremenska radna cjelina Scruma u kojoj nastaje novi inkrement proizvoda. Najčešće trajanje sprinta je 30 kalendarskih dana.

Product backlog– popis svojstava koji se očekuju od konačnog proizvoda. Svojstva u popisu raspoređena su po prioritetu od najvažnijih prema manje važnim.

Product backlog element – jedinični element iz Product backloga. Svaki element predstavlja jedno svojstvo proizvoda opisano na način da njegova implementacija vremenski stane u okvir jednog sprinta. Tijekom izvođenja sprinta backlogelementi se dalje razbijaju na zadatke i dodjeljuju članovima razvojnog tima.

Sprint backlog – popis svojstava preuzet iz product backlogakoji su predmet implementacije jednog sprinta.

Sprint burndown dijagram– grafički prikaz procjene preostalog posla kroz vrijeme jednog sprinta. Prikazuje gdje se nalazi razvojni tim u odnosu na zadatke planirane za tekući sprint.

Product owner – nositelj proizvoda. Osoba koja donosi konačne odluke korisnika ili naručitelja softverskog rješenja. Nositelj proizvoda direktno sudjeluje u definiranju prioriteta elemenata u product backlogu.

Sprint master– osoba odgovorna za provođenje scruma u timu. Uloga najsličnija voditelju projekta u klasičnim metodologijama. Scrum master koordinira komunikaciju između nositelja proizvoda i razvojnog tima.

Dnevni Scrum– dnevni sastanak razvojnog tima u trajanju od 15 minuta na kojem članovi razvojnog tima izmjenjuju kratke informacija o tome što rade i što planiraju raditi u idućem danu. Također ako imaju kakve prepreke u radu, iznose ih na sastanku. Scrum master zadužen je da se pobrine oko toga da se te prepreke uklone.

Sprint sastanak planiranja – Sastanak koji se provodi prije početka slijedećeg sprinta. Glavna tema sastanka je pregovaranje između razvojnog tima i nositelja proizvoda o tome koja svojstva odnosno koji elementi product backloga trebaju ući u slijedeći sprint, odnosno sprint backlog.

Retrospektiva sprinta – Sastanak koji se provodi na kraju svakog sprinta. Na tom sastanku scrum master zajedno sa članovi tima raspravlja o upravo završenom sprintu. Razvojni tim analizira što je bilo dobro, a što treba popraviti u procesu razvoja za slijedeći sprint. Nositelj proizvoda ne sudjeluje na tom sastanku.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>