Kada biraš Agile ne budi previše agilan

Nakon objavljivanja Agile manifesta dogodila se posledična eksplozija raznih Agile metodologija. Kroz filter primene u realnom životu, vremenom se njihov broj smanjivao, sve dok apsolutni primat praktično nije preuzela samo jedna — Scrum. Na internetu ćete naći bezbroj tekstova o tome zašto je Scrum odlična metodologija, ali mali broj njih koji govore o tome da ne mora uvek da bude podrazumevani, optimalni izbor. Ovo je jedan od takvih tekstova, koji za cilj ima da vas inspiriše da dobro razmislite pre odabira metodologije rada za svoj tim.

Naime, implementacija nekog sistema rada bez razumevanja specifičnosti biznisa i potreba kompanije prouzrokuje manju efikasnost, a u nekim slučajevima čak i neuspeh projekata i proizvoda. Postoje projekti i proizvodi kod kojih je brzina iteracija ključ, i tu se Scrum kroz praksu jako dobro pokazao. Međutim, postoje i proizvodi kod kojih je potrebno konstantno održavanje uz inkrementalno usavršavanje, kada Scrum verovatno nije najbolji izbor.

Zašto menjati ono što funkcioniše?

KupujemProdajem, kao najveća platforma za trgovinu na našim prostorima, ima i proporcionalno složen i veliki code base, koji se konstantno održava i unapređuje. Pre odluke da se uvede standardizovana Agile metodologija, KupujemProdajem je dobro funkcionisao i bez nje. To je uspevalo zahvaljujući malom broju developera, koji su u tančine poznavali sistem i sve njegove prednosti i nedostatke. Ova odabrana grupa se ponašala po sopstvenim pravilima, koja su bila u skladu sa Agile principima, ali se nije koristila nijedna standardizovana, opšteprihvaćena metodologija.

Međutim, KupujemProdajem stalno raste. Iz meseca u mesec, raste broj aktivnih oglasa (trenutno više od dva miliona), broj registrovanih korisnika (trenutno oko 1,5 milion), broj poseta, otvorenih strana itd. Takođe, sada je, osim na browserima, KupujemProdajem prisutan i u obliku aplikacije za Android, a uskoro i za iOS. Ovakav rast kompanije i sistema neminovno zahteva i povećanje IT kapaciteta, tj. angažovanje novih IT stručnjaka.

Onboarding novih ljudi u tim koji se dobro međusobno razume i radi po sopstvenim, kroz praksu definisanim pravilima, bio je dug i komplikovan proces. Osim toga, pojavila se potreba i za kreiranjem manjih, specijalizovanih IT timova koji bi radili na privremenim projektima, poput naše interaktivne mape oglasa, KP Adresara, novog Admin modula i sl. Tako je na vreme uočena potreba za standardizacijom, kakva često mora da prati rast svakog tima ili kompanije.

Neophodno je bilo obezbediti dalji razvoj i jednostavnije uključivanje novih članova tima, sistematsko zaduženje ljudi, kao i ono zbog čega se svaka Agilna metodologija primarno i uvodi — povećanje odgovornosti pojedinca prema sistemu. Pritom, mali tim je bio pod velikim opterećenjem i u periodu godišnjih odmora i u slučaju odsustva, pa se od novog sistema rada očekivalo da obezbedi i adekvatnu redundatnost i rezilientnost.

Nakon pažljive analize, od svih standardizovanih Angilnih metodologija, u uže razmatranje uključili smo Scrum i Kanban, dve najrasprostranjenije. Scrum je daleko najkorišćenija, ali je i Kanban dosta zastupljen, više nego sve preostale zajedno.

Zašto ne Scrum?

Scrum je idealan za demostraciju efikasnosti i mogućnosti development tima. U jednom sprintu developeri kreiraju funkcionalnu celinu, čiji se rezultati po okončanju prezentuju menadžmentu. Rezultati sprinta vidljivi su nakon samo jedne do tri nedelje. Uvek je jasno na čemu se radi i šta je postignuto. To su samo neke od vrlina Scrum metodologije zbog koje je toliko popularan.

Međutim, kada imamo sistem gde je osnovni akcenat na održavanju i usavršavanju, a tek onda na dodavanju novih funkcionalnosti, Scrum metodologija pokazuje svoje nedostatke. Nakon izučavanja različitih praksi, našli smo primere kako se sistemi poput našeg održavaju i razvijaju pomoću Scruma. Upoređujući ih sa našom situacijom, uočili smo sledeće nedostatke:

1. Pripreme za sprint nisu optimalne ako je potrebno da se u rezervi ostavi veći broj radnih sati programera za iznenadne situacije, kojih možda bude, a možda i ne.
2. Scrum prezentacija na kraju sprinta može da deluje demotivišuće na tim ako u tom periodu nije napravljena nijedna nova funkcionalnost. Ako se tokom sprinta radilo „samo” na održavanju sistema, može preovladati utisak da se „ništa nije uradilo”.
3. Kada se sprint bliži svom kraju, i ako je sve prošlo kako treba, developeri se postepeno oslobađaju taskova, ali ne preuzimaju nove ukoliko ne mogu da ih završe u okviru sprinta ili ukoliko nisu planirani za taj sprint, što može da dovede do neoptimalnog iskorišćenja resursa.

Iako smo svesni da se neadekvatnost Scruma za naš tim mogla ispeglati poznatim modifikacijama, naše iskustvo je pokazalo je da je Kanban jednostavniji za implementaciju i prigodniji za nama potreban proces održavanje-usavršavanje. Što je najvažnije, sa Kanbanom smo povećali  posvećenost svakog člana tima platfrormi, i svi smo usvojili filozofiju postepenog usavršavanja, kako metodologije tako i samog proizvoda na kojem radimo.

A šta mislite o Kanbanu?

Da ne bismo previše prekrajali i menjali Scrum, rešili smo da istražimo alternativne agilne metodologije. Kanban je bio prvi sledeći na spisku. Za razliku od Scruma, Kanban je manje striktno definisan, a zasniva se na ideji da se stvari inkrementalno usavršavaju. Implementacija ove metodologije se obično vrti oko Kanban table, na kojoj su skicirani taskovi na kojima se radi, oni koji su na čekanju i njihovi prioriteti, te oni koji su završeni.

Zamislite Kanban kao sistem optimalnog upravljanja velikom gomilom taskova svih vrsta. Tu mogu biti bugovi, nove funkcionalnosti, mala poboljšanja, sitnice poput uklanjanja zareza, ali čak i ceo novi projekat. Prioriteti taskova se dinamički postavljaju kako se ukaže koja potreba, a onda se oni postepeno, task po task, prebacuju (prevlače) iz jedne grupe taskova u drugu, pri čemu svaka grupa taskova praktično predstavlja jedan korak u razvoju. Na kraju se sve obavi, kako male izmene, tako i veliki projekti.

Kanban je efikasan način za razvoj postojećih proizvoda kroz konstantno usavršavanje. Ova metodologija se ne odnosi samo na proizvod, već i na procedure u poslovanju, pa se i one postepeno usavršavaju, što obezbeđuje da razvojni tim bude sve efikasniji i sposobniji.

Zahvaljujući ovakvom pristupu, svaki developer u svakom trenutku ima uvid u tok projekta, taskove na čekanju, ali i u sopstvenu ulogu i obaveze u datom trenutku. Uz to, menadžment ima pregledan i jasan krovni pogled na razvoj.

Osnovni razlog zašto nam se Kanban kao metodologija dopao je insistiranje na kontinualnom usavršavanju, što je ujedno i osnovi princip razvoja u KupujemProdajem. Drugi, praktičniji razlozi su sledeći:

1. Lako dodavanje manjih taskova, koji bi inače bili zanemareni jer nisu dovoljno veliki da bi se stavili u završnu prezentaciju za sprint.
2. Neometano rešavanje hitnih, ad hoc taskova, koji su posledica održavanja sistema.
3. Bez povećanog opterećenja na početku i „praznog hoda” na kraju, sa Kanbanom konstantno imamo optimalno opterećenje članova tima.
4. Olakšano paralelno vođenje dva ili više projekata od strane istog tima.
5. Efikasnije održavanje postojećeg sistema paralelno sa radom na projektima i novim funkcionalnostima.
6. Jednostavan workflow za bugove na produkciji, koji se ne razlikuje od ostalih taskova. Nema razlike da li je nešto došlo kao task sa produkcije, sa test servera ili u procesu razvoja.
7. Taskovi za testiranje se tretiraju isto kao i taskovi za razvoj.

Od svih pomenutih prednosti, lakoća implementacije je za nas imala presudnu ulogu.

Da li je Kanban savršen?

Prelazak na Kanban tekao je spontano i glatko. Promene je pratilo i konstatno usavršavanje radnih procesa, ka optimalnom načinu rada. Zahvaljujući Kanbanu, u samo nekoliko meseci osetili smo značajna poboljšanja, poput:

1. Brz i jednostavan onboarding novog kolege. Uhodavanje je sada trajalo manje od sedam dana, za razliku od uobičajenih nekoliko nedelja.
2. Veće zadovoljstvo developera, čiji se rad i trud veoma lako primeti na Kanban tabli.
3. Implementacija projekta dešava se u planiranom vremenskom obimu.
4. Veće mogućnosti planiranja, kao i preciznije planiranje za menadžment.
5. Optimalno korišćenje resursa, bez praznog hoda (planing za sprint, čekanje sprint prezentacije, čekanje da počne sledeći sprint).

Međutim, svaka metodologija ima i svoje nedostatke, pa smo se i mi uplašili određenih problema. Naime, Kanban podrazumeva da se taskovi preuzimaju i onda kada nisu vezani za projekte koji su u toku. To potencijalno može da izazove nedovoljnu posvećenost projektu od strane nekih članova tima, ili čak nezadovoljstvo onih koji jesu na svaki način posvećeni projektu.

Da bismo predupredili ove probleme, u radni proces smo uveli nedeljni sastanak kompletnog tima,  na kojem smo radili prikaz projekata, planiranja i estimacije predstojećih taskova, kao i kick-off novih taskova i projekata i reviziju završenih. Taj sastanak ujedno je zamenio ono čemu u Scrumu služe planiranje pred srpint, sprint prezentacije, sprint estimacije, itd. Standup sastanak na dnevnom nivou smo zadržali u istom obilku koji predviđa Scrum. Na ovaj način, povećali smo posvećenost svakog člana tima, jer smo nadomestili nedostajuću kariku — svi su razumeli zašto se nešto radi i kako to utiče na kompletan KupujemProdajem ekosistem.

Iako smo svesni da se neadekvatnost Scruma za naš tim mogla „ispeglati” poznatim modifikacijama, naše iskustvo je pokazalo je da je Kanban jednostavniji za implementaciju i prigodniji za nama potreban proces „održavanje-usavršavanje”. Što je najvažnije, sa Kanbanom smo povećali posvećenost svakog člana tima platfrormi, i svi smo usvojili filozofiju postepenog usavršavanja, kako metodologije tako i samog proizvoda na kojem radimo.