Kako balansirati brzinu i kvalitetu u razvoju softvera, pitali smo QA inženjera i CTO-a malog startupa

“Make it work. Make it right. Make it fast”  legendarni je citat i pristup razvoju softvera inženjera Kenta Becka, tvorca razvoja vođenog testiranjem, koji se često navodi kao zlatno pravilo kojeg se treba držati kod razvoja bilo kakvog softverskog projekta.

Ideja je da je na početku bitno isprogramirati nešto bilo kako, samo da bi se ustanovilo drži li ideja vodu ili da bi se prvim korisnicima isporučila neka funkcionalnost. Tek u drugoj fazi na red dolazi “ljepota” i kvaliteta koda te refaktoriranje kako bi bio uredan i mogao se održavati. A na kraju, kad su prva dva koraka odrađena, dolazi razmišljanje o optimizaciji performansi.

Zvuči odlično i logično, u teoriji. U praksi, startupi pritisnuti zahtjevima tržišta ili investitora, a agencije rokovima klijenata često nikad ne dođu ni do one druge faze, a kamoli do treće!

Kvaliteta ili brzina? Uvijek nešto mora patiti!

Kako razriješiti vječnu dilemu između potrebe za što bržim razvojem novih funkcionalnosti i potrebe da se preduhitre bugovi i pred korisnike stavlja kvalitetan proizvod pitala sam CTO-a u malom startupu i voditelja QA odjela u agenciji.

Mateo Stjepanović, CTO startupa Spiritus, kaže da je to teška dilema i poziva da mu se javi tko zna dobar odgovor na to pitanje:

Ako netko zna kvalitetan odogovor na ovo pitanje, molio bih da se javi Spiritusu!

Mogu reći da je tu dilemu jako teško razriješiti, uvijek nešto mora patiti. Jedino bitno je, posebno u startup svijetu, da je cijeli tim svjestan donesenih odluka i da svi razumiju zašto smo odabrali fokusirati se na jednu ili drugu stranu.

Međutim, prošlo je doba MVP-a, i startupi se danas bore s konkurencijom, korisnici su navikli na kvalitetne proizvode odličnog korisničkog iskustva i ne opraštaju greške. Zato Vanja Žunić, voditelj QA tima u agenciji Async Labs, zagovara da se QA u proces razvoja softvera uključi što prije i za to nudi uvjerljiv argument:

Što su bugovi ranije prepoznati, jeftinije ih je popraviti, ali ih je najjeftinije izbjeći.

Ideja QA-a je prevencija, u ovom kontekstu, bugova – što znači ranu detekciju istih. “Rana detekcija bugova” može se zamijeniti s “ranom prevencijom bugova”, i za to je potrebno što ranije imati osobu koja s takvim pristupom analizira proizvod.

“Nemamo školski posloženo testiranje, ali smo zato napisali puno više koda”

Vanja dodaje da je preduvjet za to osvještavanje klijenata o važnosti Quality Assureancea u razvoju softvera te jasno i kvalitetno posložene development procedure. Ali priznaje da to ne dolazi preko noći, pa su i Async Labsu počeli samo s testerima, a tek kasnije oformili specijalizirani odjel za QA (i, naravno, naglašava da Quality Assurance ne čine samo testeri!):

Kombinacijom ta dva postulata, posloženih procedura developmenta i edukacije klijenata, mi balansiramo između kvalitete i brzine razvoja. Mislim da je to win-win kompromisna situacija za sve stakeholdere u digitalnom razvoju.

Iz pozicije agencije koja za klijente može birati one s kojima dijeli stav prema kvaliteti ili one koje o prednostima takvog načina rada mogu educirati, to jest win-win. Iz pozicije startupa koji nema viška vremena, a ni ljudskih resursa, a mora se što prije dokazati na tržištu, često i ona početna faza, u kojoj se “samo testira” ostaje nedostižna.

Mateo priznaje da Spiritus trenutno nema niti to, odnosno da nemaju posložen “školski” proces testiranja kao dio razvoja:

Cijeli tim sudjeluje u testiranju svake nove funkcionalnosti i sve to dokumentiramo.

Eh sad, je li to bila dobra odluka ili ne, je diskutabilno. Zasigurno smo zbog toga razvili puno više aplikacije i napisali puno više koda. S druge strane, nemamo automatizirani proces testiranja niti stopostotnu pokrivenost koda unit testovima.

Filozofija kojom se inače vodimo u Spiritusu je da je korisno i idealno imati potpunu pokrivenost testovima i osobe u timu koje su zadužene za opsežno testiranje. Nažalost, to nije uvijek moguće i potrebno je pronaći ovakve kompromise.

Shift Left ako možeš, ako ne i špageti kod je dobar za početak

Često se kaže da je svaki danas uspješan tehnološki proizvod počeo kao monolit špageti koda kojeg razumije samo njih nekoliko koji su ga pisali – raspetljavanje, optimizacija i preslagivanje “po peesu” obično dođe u fazi kad se tvrtka već dokazala na tržištu, a timovi narasli toliko da im je sav taj tehnički dug postao uteg oko vrata.

Iako je Vanja zagovornik pristupa shift-left (uključivanja Quality Assurancea kao svojevrsnog advokata korisnika što ranije u proces razvoja, po mogućnosti odmah na početku, kod inicijalne ideje), zapravo se slaže s Mateom da je tržište danas takvo da je provedba toga ponekad nemoguća:

Pozitivno u tome je što startupi ovako ranije znaju jesu li na pravom putu pa naknadno idu dotjerivati proizvod. Bilo bi šteta uložiti x vremena u kreiranje nečeg kvalitetnog pa onda dobiti odbijenicu investitora nakon toliko uloženog truda. S druge strane, tu je i utrka s tržištem i njegovim rapidnim razvojem. Tvoja ideja danas jest nečija ideja sutra.

Čak i firme koje su uhodane, s više iskustva, isto počinju tako, i to je nešto što tržište promovira, odnosno na takav način diktira “igru”.

“Nema smisla ulagati u kvalitetu i skalabilnost prije prvih korisnika”

Mateo se nadovezuje primjerom Spiritusa, koji su otpočetka zamislili kao globalni proizvod, ali ga nisu odmah razvijali kao takvog jer nije bilo smisla ulagati u kvalitetu i skalabilnost prije prvih korisnika. Zato je i njihov proizvod kreiran kao monolitna aplikacija, izgrađena tako da može podržati par tisuća korisnika:

Nakon godinu dana razvoja i prikupljanja feedbacka dobili smo potvrdu da idemo na iduću razinu razvoja. Tada smo dogovorili strategiju promjene arhitekture i pisanja koda te je sada Spiritus puno ljepša i održivija aplikacija.

I svjesni smo da ćemo, kada se Spiritus proširi na strana tržišta, opet raditi reviziju i nadograditi naš kod da podržava stotine tisuća korisnika.

Nadamo se da će uskoro biti potrebe da ga revidiramo za još veći broj njih. Važno je da smo svjesni da sve ide korak po korak.

I on dodaje da takav ciklus razvoja nije svojstven samo za startupe te da ideja da se razvijaju “nesavršeni” proizvodi koji se redovito revidiraju uopće nije loša:

Naime, svi se mi razvijamo kroz to vrijeme i puno smo pametniji godinu dana nakon što smo napisali nešto. Iz češće revizije proizilazi lakša nadogradnja na neke nove ideje ili arhitekture.

Nitko ne voli vidjeti kod star 10 godina, iščupati poslovnu logiku i sve to prepisati na neki moderan način.