Parčanje je tehnika koja nam omogućava da isporučimo softver ranije, čak i kada je scope projekta zakucan.
“Kada će biti gotovo?” i “Kada će biti pred korisnicima?” na prvu deluju kao strogo povezana pitanja, na koje je jedini prihvatljiv odgovor: “Ide pred kupca kada je gotovo.” Jedna od lepota razvoja softvera je u tome što uopšte nije teško odvojiti ove dve stvari. Uprkos tome i dalje se veliki deo softverskih projekata upravo tako pravi, da se odradi dosta funkcionalnosti i dođe do visokog stepena “gotovosti” pre nego što se isporuči kranjim korisnicima.
Ukoliko biste me pitali zašto je to tako, ne bih znao da dam konkretan odgovor, već bih pošao od niza pretpostavki:
Možda su navike od ranije, iz vremena kada je distribucija softvera bila otežana i podrazumevala kupovinu fizičkih medijuma u prodavnicama?
Možda ne postoji razumevanje za kontinualni razvoj od strane (netehničkog) menadžementa kompanije ili klijenta?
Može biti i da je u pitanju jak instinkt i želja za kompletnošću unutar tima koji je odgovoran da odabere model razvoja i isporuke?
Ili je pak priroda projekta protumačena kao takva da ne može da se radi u koracima?
Verovatno u svakom takvom projektu ima pomalo od svega, plus ponešto peto i šesto što utiče na to da smatramo da softver može pred korisnike tek kada je gotov.
Big Batch
batch, eng - količina, hrpa, gomila
Ukoliko bismo se poslužili terminima iz Lean proizvodnje, gore-opisani pristup gde radimo količinski puno posla pre nego što isporučimo stabilan proizvod krajnjim korisnicima možemo zvati Big-Batch pristupom (velika količina ili velika gomila posla). Ovo je tipičan i dosta rasprostranjen pristup razvoju, gde se posao uglavnom gleda kao jedan ili više povezanih projekata.
Kao takav ima izvesne mehanizme da dođe do korisnika ranije, ali je i pored toga glavni pristup to da tim ne tvrdi da je softver stabilan i pogodan za opštu upotrebu pre nego što završi isplanirani posao.
U najtipičnijem slučaju se uzme neki opseg posla (scope) koji želimo da ralizujemo:
Tako definisan opseg posla se kroz planiranje i anallizu razbije na faze i sitnije zadatke i korake. Tim na osnovu tako definisanog plana kreće u realizaciju rešenja
U nekom trenutku rešenje dolaze u fazu gde je moguće napraviti nekakav vid izvršnog programa koji može da se proba i testira. Ova verzija se najčešće naziva alfa verzijom i njena osnovna svrha je testiranje. Alfa verzije retko izlaze van okvira kompanije i često dolaze sa prilično jasnim upozrenjem: “Ovo je alpha verzija! Neke stvari ne rade i verovatno ima dosta bugova u softveru. Koristite ga da dobijete ideju u kom smeru idemo, ali nemojte ga koristi ni za šta ozbiljno!”:
Nastavak 👉
Kako vreme odmiče, tim nastavlja da radi dalje i dolazi do faze kada su sve ili većina planiranih mogućnosti napravljene, ali softver i dalje nije u poptunosti testiran.
Tim tada objavljuje beta verziju rešenja i često je to prvi put da se softver isporučuje van kompanije koja ga je razvila, krajnjim korisnicima. Bete mogu biti otvorene i zatvore, u zavisnosti od toga da li je softver dostupan javno ili samo odabranoj grupi korisnika
Tim nastavlja da unapređuje softver, pegla greške, unapređuje performanse i kompatibilnost itd, svakom novom betom se približavajući bliže stabilnoj verziji.
U nekim slučajevima se direktno iz bete ulazi u objavljivanje stabilne verzije, ali ima i slučajeva kada se određene bete proglašavaju kandidatima za objavljivanje (release candidate ili RC), koji u suštini predstavljaju beta verzije koje imaju potencijal da postanu stabilne ako se ne otkriju nikakvi ozbiljniji problemi.
Na posletku dolazimo do konačne, stabilne verzije softvera koja se čini dostupnom svim zainteresovanim krajnjim korisnicima, uz sve preporuke da je to rešenje stabilno i pogodno za opštu upotrebu.
Big Batch osobine 👉
Ovakav pristup ima par osobenosti koje bih želeo da istaknem jer će nam dobro doći posle:
Kompanija ne tvrdi da je softver stabilan i pogodan za upotrebu pre stabilne verzije. Sve verzije pre toga dolaze sa upozorenjem da je u pitanju softver koji može sadržati greške, loše performanse ili nepotpunu funkcionalnost,
Tim sve vreme radi na tom da isporuči ceo planirani opseg posla, gde su različiti delovi tog rešenja do različite mere izvedeni i stabilni. Opseg posla može da se menja u skladu sa povratnim informacijama koje dobijamo tokom beta testiranja, ali obično odstupanja od početnog plana nisu radikalna.
Parčanje
Big-batch razvoj je gore opisan u dosta detalja pre svega da bih ima referencu na koju mogu da se osvrćem kada opisujem drugačiji pristup razvoju softvera. Kao u primeru gore, uprostićemo tako da imamo unapred dogovoren opseg posla:
Prva aktivnost u pristupu realizaciji nije pravljenje detaljnog plana, već grubo razlojavanje celog opsega posla u niz većih vertikalnih celina. Pod pojmom “verikalne celine” se podrazume da je u pitanju potpuno funkcionalno parče softvera. Npr, “backend za video pozive” nije veritikalna celina, pošto korisnik nema puno koristi od nje dok se ona ne integriše sa nekim interfejsom. “Mogućnost da korisnik vidi listu ljudi sa kojima može da usposati video poziv” je već nešto sa čime možemo da radimo, jer obuhvata aktivnost od koje korisnik može da ima vrednost.
Nakon ove vežbe, naš dogovoreni opseg posla izgleda ovako:
U ovom koraku nismo procenjivali složenost pojedinih koraka i tražili najbolji redosled, već smo ih samo popisali. Od takve liste imamo neke koristi, ali ona je samo početak.
Sledeći korak je da procenimo složenost pojedinih celina i menjamo im redosled tako da što pre dođemo u priliku da korisnicima isporučimo nešto što je dovoljno zaokružena celina da u njoj prepoznaju vrednost. U sortiranju nam može pomoći jednostavan graf ispod naših celina koji pokazuje koju procenjenu korisničku vrednost oslobađamo kada pojedine celine završimo:
Stvari na koje se u sortiranju obraća pažnja su međuzaivnosti određenih celina, vreme potrebno za realizaciju i procenjena vrednost koju celine donose. U situacijama gde nismo sigurni da li je planirani opseg stvarno ono što treba da pravimo i kako će korisnici reagovati, prioritet možemo dati stvarima koje ispituju najveće rizike i pretpostavke ugrađene u rešenje. Stavljanjem rizika i hipoteza napred možemo ranije naučiti o potrebama korisnika i koliko dobro ih naše rešenje zadovoljava.
Sve se to radi kako bi se mogle povući vertikalne crte kroz scope koje definišu kada i kome puštamo određene mogućnosti i sa kojim ciljem (podebljane linije sa 🚀).
U našem dosadašnjem radu najčešće smo povlačili sledeće crte:
Imamo najosnovije celine zaokružene tako da mi interno možemo da počnemo da koristimo to što pravimo,
Funkcionalnost je dovoljno zaokružena da je pustimo ograničenom broju korisnika koju su pokazali najveće interesovanje za nju, pa nam mogu dati komentare na šta sledeće da se fokusiramo,
Funkcionalnost je takva da možemo da je pustimo svim korisnicima iako znamo da ceo opseg posla još nije gotov, jer su preostale stvari od manje važnosti za svakodnevno korišćenje rešenja,
Zaokruživanje preostalih funkcionalnosti.
Primer kako sada izgleda naš opseg posla, isečen na celine i faze isporuke:
Ovi koraci su samo ilustracija, iz našeg iskustva. Okruženja u kojima radimo i potrebe i očekivanja korisnika umeju puno da se razliku, pa će se samim time i koraci razlikovati.
Takođe, gde su momenti u kojima možemo da uključimo korisnike se jako razlikuju od problema do problema. Do sada smo imali prilike da radimo na “levo nagnutim“ stvarima, gde se pred korisnike dolazi vrlo rano i onda isporučuju sve ostale planirane mogućnosti u inkrementima, ali i na “desno nagnutim“, gde mora dosta posla da se uradi pre nego što može da se pusti bilo kome van tima.
Tek kada je posao isečen na ovaj način, tim ulazi u detaljno planiranje prvih dogovrenih celina. Celine se onda prave jedna po jedna, tako da su završene, bez znanih defekata i problema sa performansama. Svaka zaokružena celina je potpuno stabilno i korisno parče softvera koje u bilo kom trenutku možemo da odlučimo da isporučimo krajniim korisnicima.
Osobine parčanja 👉
Ovaka pristup razvoju ima par bitnih osobina koje treba istaći:
Softver je uvek stabilan i ne dolazi sa upozorenjem da ima znane defekte i probleme sa performansama. Podrazumevano je da se te stvari ispravljaju pre nego što se celina smatra gotovom i softver isporuči,
Puno ranije se dolazi pred korisnike sa rešenjem. Na taj način softver počinje da kreira ekonomsku vrednost ranije, što utiče na profitabilnost projekta,
Poruka koja se komunicira korisnicima je da je ono što je dostupno samo deo planirane funkcionalnosti i da radimo na daljim unapređenjima.
Stvarno korišćenje i komentari mogu da informišu naš dalji razvoj i skrenu nam pažnju na neke bitne funkctionalnosti koje smo prevideli ili nam pokažu da neke stvari možemo da preskočimo jer nisu bitne korisnicima.
Studija slučaja: My Work
Primer na kome mogu da pokažem kako smo seckali posao je nedavno redizajnirana My Work stranica. Taj posao mi deluje priklano jer nam je opseg bio većim delom poznat unapred. My Work stranica je postoji već godinama i imali smo na stotine sugestija kako da je unapredimo.
Nije sav posao u proizvodima neizvesnost i istraživanje nepoznatog. Ima puno stvari gde znaš šta treba da uradiš, samo tražiš način da to uradiš što brže, kompletnije i kvalitetnije. My Work je bio baš takav posao - znali smo šta i kako želimo da posignemo, ali smo tražili način kako da što pre isporučimo tražena unapređenja.
Nakon pretresanja svih prikupljenih komentara, istraživanja konkurencije i intervjua došli smo do koncepta sa kojim smo bili zadovoljni. Taj koncept je predstavljao naš opseg posla. Bili smo svesni da će neke stvari morati dodatno da se razrade i dotegnu, a da neke neće biti realizovani, ali u suštini to je bilo to. Naša "kutija":
Primetite da se “kutija“ ni na koji način ne razlikuje do opsega posla koje sam u Big Batch primer i u primer koji objašnjava parčanje. To je manje-više ista stvar. Na nama je da odlučimo na koji način ćemo da pristupimo problemu.
Parčanje, procene, planiranje
Iako je koncept imao izvesnu "širinu", svima nam je vrlo brzo bilo jasno šta je najvažnije u njemu: mogućnost sortiranja zadataka po roku. Za tom mogućnošću smo imali najviše zahteva, a sve ostalo je bilo manje važno u odnosu na to.
Iako je bilo manje bitno, baš te "ostale stvari" su činile da novi My Work bude puno skladniji i kompletniji, pa nismo hteli da ih preskočimo. Često je baš sklad to što strada kada Agile krene da seče makazama "vrednosti za korisnika" po rešenjima, ali to je neka druga priča.
Kada smo imali koncept kojim smo zadovoljni, krenuli su u traženje optimalnog puta za realizaciju, svesni da to što vidimo nije sve i da ima skrivenih kompleksnosti i rizika. Prvo treba da nađemo veće celine koje nam sam koncept otkriva:
Dodavanje opcije da se zadaci grupišu po roku (najtraženije),
Dodavanje mogućnosti da se projekti, liste i datumske grupe sakriju (druga po broju zahteva),
Omogućiti korisnicima sa Client+ rolom da mogu da koriste My Work (treća po broju zahteva),
Čestitati korisniku kada završi sav posao,
Prebaciti da My Work koristi tabove, umesto da se sve učitava i prikazuje odjednom,
Dodati punu listu aktivnosti kao tab,
Izvući upravljanje ličnim podacima o dostupnosti iz "dubina" People sekcije na My Work.
Prve tri stvari su direktno došle kao korisnički zahtevi, dok ostale četiri predstavljaju neke strateški bitne promene i naši želju za skladnijim rešenjem.
Izvlačenje krupnih celina iz koncepta je samo početak. Koncepti ulivaju optimizam i pokazuju neko bolje stanje sofvera, ali ne pokazuju konkretan put i šta sve na tom putu krije od izazova. Sledeći korak je bio da se vide upravo zavisnosti i stvari koje se kriju među koracima. Pošto smo se mi kretali unutar postojećeg softvera sa postojećim podacima i podešavanjima lista je ispala ovako:
Postojeći prikaz zadataka treba da se prebaci na React i dobija podatke o izmenama kroz WebSocket,
API koji vraća zadatke treba da se optimizuje jer smo primetili probleme sa performansama kod postojećeg,
Forme za dodavanje zadataka treba da se napravi da može da se koristi na više mesta u aplikaciji,
Lista aktivnosti treba sa se prebaci na React na način da može da se koristi kroz celu aplikaciju,
Podaci o novim aktivnostima treba da dolaze kroz WebSocket,
Pravljenje frontend komponenti koje nam nedostaju.
I za kraj, par rizika i nepoznatih za koje treba naći vremena i odgovore. Veliki deo nepoznatih se rešava u fazi koncipiranja, tako da koncepti ili nude rešenja ili alternative, ali je nemoguće i nepraktično imati odgovore na sva pitanja unapred. Takođe, koncepti su prepuni naših pretpostavki koje treba preispitati sa korisnicima. Evo par stvari koje smo mi zapisali:
Da li treba da podržavamo drag and drop zadataka u listama?
Kako se menja rok zadatka kada se prevuče u Next Week grupu na primer? Od ponedeljka do petka ili samo da mu je rok ponedeljak?
Da li podatke o dostupnosti skroz da izvučemo iz People sekcije ili da ih imamo na dva mesta?
Da li i u kojoj meri nove My Work funkcionalnosti mogu da se koriste kao profili korisnika u People sekciji?
Spojeno:
Podugačka lista, ali s razlogom. Kada se planira nova funkcionalnost u postojećem softveru često se ignoriše postojeći tehnički dug i ignorišu stvari mimo najčešće korišćenih korisničkih ruta (happy path), što dovodi do preoptimističnih procena, frustracija ljudi koji prave softver, kasnijih pritisaka zbog “probijanja rokova“ i isporuke manje kvalitetnog rešenja.
Sada na red dolazi zanimljivi deo. Sa krupnim stavkama, rizicima i tehničkim zahtevima “na čistacu” možemo da preraspoređuje stvari tako da na odgovoran način otključamo i isporučimo što više korisnički prepoznate vrednosti što pre. Kažem “odgovoran način” zato što imamo i rizike u igri koji mogu napraviti puno posla i rasipanja energije kasnije ako se na bitne ne odgovori ranije.
Sledeći korak je procena korisnički prepoznate vrednosti i grube procene vremena potrebnog za izradu za svaku od stavki. Procenjivanju se može pristupiti formalno ili se osloniti na intuiciju tima, zavisno od uhodanosti i iskustva ljudi i bitnosti stvari koju radimo. Mi smo se u konkretnom slučaju oslonili na intuiciju da bismo ceo posao završili u smislenom vremenskom periodu, ali da smo procenjivali tabela bi ispala ovako:
U zavisnosti od problema kojim se bavimo i potreba možemo dodati dimenzije koje procenjujemo kako bismo dobili dodatne uvide. Neke od ideja: koliko pojedina stavka nosi rizika, gde su momenti učenja, očekivan prihod isporukom određene stavke itd. Pošto je My Work bio “zicer” unutar postojećeg softvera, naš fokus je bio na svega dve dimenzije: prepoznatu korisničku vrednost i vreme potrebno za izradu.
Idemo na sortiranje. Cilj je doći do redosleda koji je moguće izvesti (imajući na umu međuzavisnosti) tako da se isporuči što više vrednosti u što kraćem vremenskom periodu. Promenom mesta stavkama i diskusijom smo došli do sledećeg redosleda:
Grafikoni otkrivaju da vreme uloženo u izradu i isporučena vrednost nisu direktno povezani, tj. da prostim igranjem sa redosledom možemo isporučiti korisnicima više vrednosti ranije. Crveni deo funkcionalnosti u sebi nosi skoro 3/4 procenjene vrednosti, iako smo procenili da je to vremenski nešto manje od polovine posla. Iskustvo mi govori da nema srebrnih metaka kada je razvoj softvera u pitanju, ali ovo dobacuje prilično blizu!
Crveni deo funkcionalnosti smo procenili kao dovoljno vredan da možemo da pustimo My Work svim korisnicima bez obzira što nas čeka još dosta posla. Zahvaljujući tome što stvari uvek stavljamo pod feature flag koji nam omogućava da selektivno puštamo mogućnosti različitim grupama korisnika, mi smo počeli da testiramo funkcionalnost puno ranije na našem nalogu, a u nekom trenutku smo uveli i uzak krug strpljivih korisnika, da vidimo šta oni misle o urađenom. Jedno je pričati o konceptima, drugo probati softver.
Pošto smo završili posao iz crvenog bloka i nismo našli veće blokere, pustili smo to što je urađeno na sve naloge, bez puno buke. U ovoj fazi smo samo interno komunicirali korisnicima novu funkcionalnost, ali nismo promovisali dalje od toga. Možemo reći da je ovo bilo “tiho” lansiranje.
Sledeće na čemu smo mogli da radimo je My Work za klijente. Ova funkcionalnost je prepoznata od strane korisnika kao vredna, ali nije imala velike međuzavisnosti tako da je mogla samostalno da se razvije i isporuči za kratko vreme.
Posle toga imamo zeleni blok u kome ima puno više međuzavisnosti koje uslovljavaju da skoro ceo blok pred korisnike mora ide kao jedna celina. Upravo ovde su se krili veliki problemi po pitanju vremena potrebnog za realizaciju. Sa druge strane, ovaj blok posla nosi vrlo malo korisnički prepoznate vrednosti, jer se uglavnom vrteo oko performansi, vizuelnom zatezanju i rada na sekciji aplikacije sa kojom su korisnici već bili zadovoljni.
Sada kada sam ga tako opisao, deluje kao posao koji verovatno nije ni trebao da se dira. Međutim, nama je ovaj deo bio bitan jer nas pokreće ka novom dizajnu aplikacije, rešava dosta tehničkog duga i izvlači neke strateški bitne funkcije bliže korisnicima. Iz naše perspektive, tek po završetku ovog dela smo bili spremni My Work sekciju da nazovemo “novom” i promovišemo je.
Ono što ostaje iza zelenog bloka je… ostalo.
Realizacija
U preradu My Work sekcije smo ušli sredinom oktobra.
Dve i po nedelje kasnije smo imali prvi deo funkcionalnosti pred malom grupom korisnika - preprađene zadatke na React, sa mogućnošću obaranja grupa i osvežavanju podataka u realnom vremenu. Sredinom novembra je crveni blok bio zaokružen, testiran i pušten svim korisnicima.
Početkom decembra smo zaokružili i zeleni blok i lagano počeli da pričamo o sledećoj većoj celini na kojoj treba da radimo. Ceo posao je imao svoj paket izazova, kao i svaki drugi posao, ali ništa zbog čega bismo gubili san (ili korisnike).
Zahvaljujući parčanju i spremnosti svih uključenih da isporučujemo ranije, umesto da čekamo da stvari budu “gotove”, 3/4 prepoznate korisničke vrednosti je isporučeno za pola potrebnog vremena, a ostale stvari smo posle odmotavali kao unapređenja, kako je šta pristizalo.
Da li je moglo biti bolje? Uvek može bolje. Žao nam je što se ovde nismo više vodili metrikama korisničkog ponašanja, nismo uspeli da se rešimo svog tehničkog duga kada je listanje korisničkih zadataka u pitanju itd. Biće dana kada ćemo se i tim stvarima pozabaviti.
Zaključak
Na slici desno možete videti šta bismo dobili kada bismo se vratili “kutiji” od koje smo počeli… 👉
Ova ilustracija pokazuje da vreme puštanja pred korisnike i vreme kada posao smatramo gotovim i “gotovim gotovim” uopšte ne moraju biti isti. U našem primeru smo imali puštanje ograničenoj grupi korisnika, puštanje svim korisnicima, zaokruživanje funkcionalnosti propraćeno planiranim marketinškim aktivnostima i preostale stvari koje smo posle odmotavali lagano prebacujući fokus na nešto drugo.
Kod kratkih poslova, od po mesec, dva, ovakav pristup možda deluje kao previše posla, ali ni tu ga ne bih zanemario. Nije problem kada nešto procenjeno na mesec, dva dana posla toliko vremena i uzme - problem je kada se takav posao razvuče na pola godine! Parčanje i bavljenje rizicima i tehničkim zahtevima nam pomažu da ranije uvidimo da postoji šansa da se stvari tako odmotaju.
Sa druge strane, zamislite poslove za koje procenjujete da zahtevaju pola godine, godinu ili možda više. Ako ne koristimo tehnike poput parčanja ili nešto slično, da pred korisnike izađemo ranije, ulazimo u ogromne rizike i troškove. Što duže nismo sa rešenjem na tržištu, to se izlažemo većem riziku da imamo pogrešno rešenje ili da je naše rešenje tehnički i dizajnom već u određenoj meri zastarelo kada ga izbacimo. U mnogim okruženjima rizik od otkaza projekta raste što je projekat duži. Dugi projekti su takođe pogubni za moral. Ljudi dugo pamete koliko ih rastegnuti marševi ka nekom maglovitom trenutku u budućnosti troše. Ne treba zaboraviti ni ekonomski momenat i trošak kašnjenja. Raniji izlazak na tržište sa jednostavnim, ali korisnim rešenjem može nas dovesti do prihoda ranije i početi praviti trakciju, umesto da čekamo “veliko rešenje“ koje isto od nule kreće da pravi trakciju i generiše prihode, samo sa godinu, dve dana kašnjenja.
Što se pristupa za parčanje veće celine tiče, tu imamo niz alata na raspolaganju. My Work je relativno jednostavan tako da je lista zapisanih stvari radila posao. U nekim komplikovanijim slučajevima verovatno treba složeniji pristup. Npr, za stvar koju sada radimo smo pravili mapu korisničkih priča (User Story Map) kao polaznu tačku. Kod rešenja koja imaju veliku količinu neizvesnosti pre treba da se vratimo hipotezama i testiramo ih nego da se odmah bacimo na realizaciju i isporuku.
