Kako smo poboljšali efikasnost uspostavljanjem razvojnog procesa

03. 02. 2021.

development 1

U oblasti razvoja softvera, različiti timovi imaju različite pristupe tome kako se stvari rade. Kada je tim mali, uvođenje procesa može biti neodoljivo, a najveći izazov je odrediti kada je pravo vreme za definisanje jednog procesa.

Od ranih dana u kompaniji Things Solver, nismo baš razmišljali o definisanju procesa razvoja, jer su stvari išle prilično glatko i uključivanje je bilo veoma brzo. Zatim, tokom vremena, količina posla koji treba da se uradi je enormno porasla, što je rezultiralo kompromisom između kvaliteta rada i vremena isporuke. Pretpostavka da svi izvršavaju svoje obaveze i daju najkvalitetniji posao je lepa i predstavlja timski duh pun međusobnog poverenja i poštovanja – ali nesporazumi i nedostatak iskustva često dovode do neželjenih rezultata gde se nešto mora isplatiti.

Tako smo se susreli sa situacijom koja je zahtevala primopredaju nekog dela naše aplikacije, gde je kod koji je ostao bio zaista neorganizovan i pun anti-šablona koji su ga činili teško razumljivim. To je rezultiralo preradom modula koji je čiju primopredaju je trebalo izvršiti i našom spoznajom koliko je ključno uvesti neke standardizacije. Morali smo da se uverimo da svi razumeju šta treba da isporuče i da uvedemo najbolje prakse u celoj kompaniji. A kako se svi procesi rađaju iz slučajnih grešaka, tako je i naš. Naš razvojni proces smo definisali na nivou kompanije, tako da svi imamo manje „nepoznatih promenljivih“ dok radimo najbolje što možemo.

Prva faza procesa je planiranje mape puta koja odlučuje koji su naši dugoročni planovi za naš proizvod. Ovde procenjujemo vremensku liniju napretka našeg proizvoda u narednim mesecima. Nakon početnog podešavanja mape puta može se prilagođavati i proširivati u povremenim intervalima, ali promene u mapi puta ne bi trebalo da budu drastične od početnog podešavanja. Kada se postavi mapa puta, ona treba da utiče na planiranje i dizajn specifičnih zadataka.

Sledeća faza procesa razvoja je dizajn zadatka. Sesije dizajniranja zadataka uključuju starije i najiskusnije članove kompanije Things Solver, koji zajedno precizno definišu zahteve koje ova funkcija treba da podržava i na kojima će se raditi u narednom periodu. Na primer, ako zadatak uključuje određenu mikrouslugu, sesije dizajna zadataka definišu koje krajnje tačke servis podržava, koji su inputi krajnje tačke, koja logika se primenjuje unutar krajnje tačke i kako će izgledati izlazne vrednosti svake krajnje tačke.

Nakon ove faze, definisanim zadacima se daje prioritet na osnovu njihove složenosti i vremena potrebnog za isporuku. Kada imamo definisane zadatke, možemo pristupiti planiranju sprinta. Planiranje sprinta je događaj koji se održava svake dve nedelje gde se raspodeljuju radni zadaci za sledeći sprint koji će trajati naredne dve nedelje.

Poslednja faza razvojnog procesa je razvoj. To je period od dve nedelje između planiranja sprinta u kome ljudi rade na dodeljenim zadacima. Tokom razvoja svi timovi imaju svakodnevne sastanke na kojima ljudi razgovaraju o tome šta će raditi tog dana, kao i sastanke sa rezimeom koji se održavaju na kraju radnog dana gde svi govore o svom napretku, potencijalnim problemima, blokiranjima ili greškama na koje su naišli.

Kada neko obavi zadatak, on se šalje na proveru koda. Stručnjaci koji pregledaju kod mogu postavljati pitanja, tražiti izmene ili odobriti poslani kod. Kada se postignu tri odobrenja, zadatak se smatra završenim i može se započeti sledeći izazov. Ako se svi zadaci koji su raspoređeni u fazi planiranja izvrše, prva stvar na beklogu je sledeći zadatak.

Nadam se da ste uživali u mom kratkom pregledu našeg razvojnog procesa koji smo prilagodili potrebama naše kompanije i možda vidite nešto što mislite da možete primeniti u svom radnom okruženju.

Photo credits: https://unsplash.com/photos/KE0nC8-58MQ