Najuspješnije IT kompanije odgovaraju na korisničke zahtjeve u svega dan ili dva

Infobip je softversko-telekomunikacijska kompanija koja dnevno procesira 300 milijuna poruka, posluje u 44 ureda diljem svijeta, a u klijente ubraja vodeće internetske kompanije, banke i telekom operatere. Ove će godine, uz Infobipove programere, na konferenciji u subotu 14. svibnja govoriti i Michael Feathers te Dave Farley, etablirani autori i predavači u području razvoja softvera, kontinuirane isporuke te analize i revitalizacije koda.

Skaliranje složenih distribuiranih sustava

A Infobipovi Mario Žagar i Marko Stipanov i ove će godine na Dev Daysima govoriti o bogatim znanjima i iskustvima stečenim na tom putu, dok su prošle pred tristotinjak programera govorili o rastu i skaliranju vrlo složenih, distribuiranih sustava, na primjeru Infobipa. O kakvim je sustavima riječ? Mario Žagar pojašnjava:

Radi se o sustavima gdje više aplikacija smještenih na različitim računalima međusobno komunicira kako bi ostvarile zajednički cilj. Za razliku od sustava gdje je jedna aplikacija zadužena za sve poslovne procese i nalazi se na jednom računalu, distribuirani sustavi su obično sastavljeni od više manjih aplikacija koje žive svaka na svom računalu i bave se svaka svojom specifičnom problematikom, koja rješava točno određeni dio poslovnih potreba.

Osim što nam olakšavaju razmišljanje i dozvoljavaju da se koncentriramo na specifične probleme, distribuirani sustavi pružaju i veću otpornost na pogreške u samom sustavu. Kod monolitnih arhitektura gdje imamo samo jednu aplikaciju koja je odgovorna za sve nije tako — ako ona iz bilo kojeg razloga prestane raditi, staje cijeli sustav.

Možemo povući paralelu s ljudskim tijelom, nastavlja, u kojem mnogo manjih dijelova čini funkcionalnu cjelinu. Ako neki dio i prestane funkcionirati, tijelo se adaptira i preživljava. Ne znači nužno da čitav sustav prestaje raditi.

U današnje vrijeme kada korisnici očekuju da aplikacije rade 24 sata na dan, i sedam dana u tjednu, i budu dostupne čitavo vrijeme, ovo je vrlo važna karakteristika.

Distribuirani sustavi donose i nove izazove koji nisu postojali u monolitnim arhitekturama. Treba osigurati da aplikacije mogu razgovarati jedna s drugom, odlučiti kako se postaviti kada komunikacija ne radi kako treba, pratiti stanje i zdravlje tih aplikacija. A kad nešto ne radi, izazov je i točno locirati problem. Kao i kod žongliranja, teže je baratati s više loptica nego s jednom.

Kontinuirana isporuka – jedan od temeljnih izazova u IT tvrtkama

Ove se godine Dev Daysi nastavljaju baviti tom tematikom – moći će se, među ostalim, čuti koliko je i kako Docker olakšao procese razvoja i implementacije aplikacija u Infobipu. Kontinuirana isporuka (continuous delivery) jedan od temeljnih izazova i pitanja u mnogim većim IT tvrtkama, a Mario se prisjeća kako se nekada razvoj aplikacija radio u iteracijama koje su trajale od nekoliko mjeseci do nekoliko godina; na kraju tog ciklusa aplikacija bi se distribuirala putem CD-a ili DVD-a krajnjem korisniku, a novi korisnički zahtjevi čekali bi kraj narednog ciklusa. Danas takav pristup više ne prolazi na tržištu – najuspješnije IT kompanije isporučuju nove feature u jako kratkom vremenu, kadre su odgovoriti zahtjevima klijenata u roku od jednog ili dva dana, ili čak kraćem, i tako rade non-stop. No, da bi tvrtke mogle tako raditi, moraju imati ostvarene mnoge preduvjete i postaviti dobre temelje, uključujući organizacijske, kaže. Kako je izgledao razvoj tih alata i procesa u Infobipu?

Na početku Infobipa nismo imali ništa osim testova koje smo ručno izvršavali svaki na svom računalu. Činjenica da smo u startu odmah razvijali kulturu pisanja testova po meni je ključna za to gdje smo danas. S vremenom smo shvatili da ručno izvršavanje testova je posao koji puno bolje može raditi računalo nego mi pa smo uveli centralno mjesto gdje će se ti testovi izvršavati nakon svake promjene koda.

Koristimo open source Jenkins aplikaciju koja se brine o tome da izvrši sve testove za svaku našu aplikaciju kada se na njoj nešto promijeni i obavijesti tim koji razvija tu aplikaciju o rezultatu testova.

Nakon što smo automatizirali bildanje i testiranje aplikacija, shvatili smo da najviše vremena gubimo na stavljanje tih aplikacija u produkciju jer koristimo ručni proces i svatko to radi na svoj način, što nije doprinosilo konzistentnosti ni sigurnosti. Zbog toga smo napravili malu aplikaciju koja nam je omogućavala da taj deployment proces radimo na jednostavniji i brži način. Tako je nastao Infobip Deployment Manager koji omogućava da praktički bilo koji novi developer koji dođe u Infobip prvi dan može deployati kod u produkciju.

Kasnije smo dodatno automatizirali proces pa možemo deployati novu verziju aplikacije praktički na jedan klik. U prosjeku puštamo promjene u produkciju svakih nekoliko minuta.

Umjesto panike – planiranje

Mario i Marko su lani govorili o agilnoj metodologiji i organizaciji, kao preduvjetu efikasnog developmenta, a spominjali su tranziciju s takozvanog panic-driven developmenta k planiranju, prioritiziranju i odlučivanju po Scrum metodologiji. Marko napominje kako nije neobično da development u IT kompanijama odlučuje o prioritetima na principu panike – radi se ono što je nekom trenutku najhitnije, odnosno ono oko čega je nekom trenu već nastala panika.

U našem slučaju, podjela posla često nije bila ravnomjerna, odnosno znalo se događati da manji broj ljudi radi na većem broju ključnih produkata. To je dovodilo do preopterećenja, otežavalo prioritiziranje i podjelu posla.

Zato smo počeli istraživati metodologije i organizacijske principe koji bi se najprirodnije uklopili u naše okruženje, potrebe i ciljeve. Jedan od glavnih zahtjeva je bio da se čitava tranzicija ni najmanje ne odrazi na tekući razvoj produkata, odnosno da klijenti ni u jednom trenutku ne osjete zastoje ili teškoće.

Kako se Scrum uvodi u veći R&D sustav?

Infobip je transformirao svoj development prije više od dvije i pol godine. Koliko je potrebno da se Scrum uvede u veći R&D sustav i počne davati konkretne rezultate? Koje su najčešće prepreke? Marko nastavlja:

Nama je trebalo oko 5 mjeseci da u potpunosti uvedemo Scrum u development odjel. To je uključivalo pilot, edukacije, treninge, reorganizaciju timova i projekata. Rezultati su vidljivi odmah – kako na produktima, tako i na zadovoljstvu developera i boljem protoku znanja.

Kroz retrospektive se cijeli sustav dalje usavršava i postaje još efikasniji. Scrum metodologija i agile principi nisu nepromjenjivi, niti vrijede zauvijek jednom kada ih uvedete. Morate razumjeti u kojoj fazi razvoja je produkt, o kakvom tipu produkta je riječ, kakvi su profili i potrebe članove timova.

Veličina organizacije sigurno otežava uvođenje nove metodologije, i treba posvetiti dosta vremena edukaciji i treninzima. Osim toga, većih prepreka zapravo nema, jer se Scrum metodologija uglavnom percipira pozitivno, i developeri je rado prihvaćaju.

Najveći i najteži korak: Formiranje timova

Marko se prisjeća i problema koji su cijeli proces pratili – nisu postojali timovi u pravom smislu pa bi se događalo da su ljudi radili ad hoc. Pojavila bi se potreba za nekim servisom i taj zadatak bi uglavnom preuzela najkompetentnija osoba. Ako je bila riječ o većem problemu ili zadatku, preuzelo bi ga dvoje ili troje ljudi, ali oni nisu bili tim, jer su istovremeno radili na mnogim drugim projektima. Na taj način je bilo teško pratiti opterećenje pojedinaca, ali i procijeniti rokove dovršetka.

Formiranje timova je zapravo najveći i najteži korak koji smo učinili uvođenjem scruma. Formiranje dev timova također je išlo u nekoliko iteracija, to je proces koji stalno traje i usavršava se, jer timovi stalno evoluiraju, na više razina.

Paralelno s tim počeli smo usvajati Scrum metodologiju – principe, rituale, uloge, produkte. Prvo je krenuo pilot s jednim timom u Puli, a nakon toga je metodologija uvedena na razini čitavog developmenta. Organizirane su radionice i edukacije za Scrum mastere i Team leadere, koji su se certificirali i osposobili za ove uloge.

Sigurno je da činjenica da imamo razvojne centre u više zemalja nije pomogla. U početku smo imali veći broj distribuiranih timova, ali pokušavamo postići da što veći broj dev timova ima članove na istoj lokaciji. Lakše je održavati sastanke, dijeliti znanje i postići optimalnu efikasnost. 

Je li se dobilo ono što se očekivalo? Sugovornici odgovaraju potvrdno – sada se mogu puno preciznije procijeniti rokovi, odrediti prioriteti i na optimalan način reagirati na potrebe i zahtjeve tržišta i klijenata. Također, znatno je olakšan prijenos znanja, što je u većoj dev organizaciji vrlo bitno, a olakšao se onboarding i zapošljavanje – lakše se prati treba li novih ljudi po timovima i projektima ili ih ima previše pa valja formirati novi tim.