Hodajući kostur pomaže da projekti, lični i poslovni, krenu kako treba.

Projekte možemo početi na niz načina. Ono što odlučimo da nam bude u žiži interesovanja i rada na samom početku mnogo utiče na to kako će se (i da li uopšte) projekat dalje razvijati. 

Dosadašnje iskustvo mi govori da sa projektima treba biti naročito pažljiv u početku, bili oni lični ili kompanijski. Inspiracija i entuzijazam s jedne i podrška organizacije sa druge strane nisu neiscripni resursi. Umeju brzo da presuše i zato treba igrati pametno.

Postoji niz načina kako projekat u ranoj fazi može da završi u ćorsokaku. Evo dva kod kojih nam pristup kojim se bavimo u ovom članku pomaže:

  1. Stavljanje velikog fokusa na arhitekturu, skalabilnost i ostale detalje tehničkog rešenja prerano,

  2. Uzimanje da se realizuje velika količina funkcionalnost pre nego što se korisnicima da softver na korišćenje.

Kada ih obrnemo, takođe dobijemo stvari koje mogu da ugroze projekat u nastanku:

  1. Nedovoljan fokus na arhitekturu, performanse i tehničke aspekte rešenja, koji nas posle dovodi u niz tehničkih problema i usporenja,

  2. Realizacija stvari koje su previše male ili u nebitnim delovima aplikacije tako da korisnicima ne mogu biti od koristi. Rizik je da korisnici neće razumeti širu sliku rešanja koje pravimo i izgubiti interesovanje.

Pristup koji nam pomaže da jasnije definišemo cilj u ranoj fazi, kao i da mu se lakše vratimo ako odlutamo, je Hodajući kostur (Walking sceleton):

“Hodajući kostur je minijaturna implementacija sistema koja u potpunosti radi jednu malu funkciju. Ne koristi konačnu arhitekturu rešenja, ali povezuje delove arhitekture. Arhutektura i funkcionalnost potom mogu da evoluiraju paralelno.”

— Alistair Cockburn, Crystal Clear

Prevedeno na “programerski”, treba da napravimo “samo da radi” jednu malu funkcionalnost. Šalu na stranu, i programeri i dizajneri sa kojima sam do sada imao prilike da radim intuitivno znaju šta “samo da radi” znači i to je dovoljno da se dođe do Hodajućeg kostura.

Ni jedna komponenta ovakvog rešenja nije završena, samo je povezana sa ostatkom da izvrši jednu odabranu funkciju. Daljim razvojem ćemo dodavati funkcionalnost i unapređivati tehničke aspekte rešenja, ali od momenta povezivanja pa na dalje, cilj je da komponente ostanu povezane i evoluiraju kako se softver razvija.

Primer

 

Uzmimo da naša organizacija ima problem gde ne znamo ko na čemu radi, koji su nam grupni izazovi, a koje pobede i slično. Za početak nam deluje da bi korak ka rešenju bio kompanijski blog na kome svi članovi organizacije mogu da se informišu i objavljuju vesti. Pošto želimo da imamo što otvorenije vesti i diskusije, prioritet nam je da se postaramo da objavljenim člancima ne može da se pristupi van organizacije.

S tim na umu, dogovor je da se fokusiramo i da u najviše par nedelja dođemo do sledećeg Hodajućeg kostura:

  1. Pristup blogu je moguć samo sa naše mreže i uz obavezno logovanje korisnika koji je član naše organizacije,

  2. Svi članovi organizacije mogu da čitaju sve objavljene članke,

  3. Objavljeni članci se listaju hornološki, tako da su najnovije stvari na vrhu i za svaki članak vidimo ko ga je objavio i kada.

Jednostavna forma za objavljivanje vesti

Jednostavna forma za objavljivanje vesti

Čak i da se zadržimo na najosnovjim elementima, tipa listanje sadržaja bez dodatne stilizacija, a unos pomoću dva polja za unos naslova i teskta, ovaj zadatak će nas suočiti sa nizom arhitekturalnih odluka:

  1. Odabir primarne platforme - web, mobilna aplikacija itd,

  2. Identifikacija članova organizacije i filtiranje saobraćaja,

  3. U slučaju web aplikacije, da li je u pitanju single ili multi-page aplikacija (SPA ili MPA)? Posle toga ide odabri osnove za razvoj, pakovanje i testiranje,

  4. Biranje mesta gde se podaci trajno čuvaju. U obzir mogu doći baza podataka, fajlove na disku, nekom Cloud API.

  5. Mesto gde će aplikacija da radi i način isporuke izmena.

Puno odluka za rešenje koje se verovatno svodi na listanje članka i dve proste forme, jednu za logovanje korisnika i drugu za dodavanje sadržaja. Nekada će donošenje tih biti jednostavno (Ruby on Rails web aplikacija koju ćemo da stavimo na Digital Ocean VPS), dok u nekim slučajevima stvari mogu biti komplikovanije. Na primer, do sada nikada niste kačili Python web aplikaciju na kompanijski Active Directory, pa to treba da sedne na svoje mesto.

Bilo lake ili teške, upravo ove odluke i rad na njihovoj realizaciji će na kraju rezultovati sa Hodajućim kosturom. U pitanju su povezane arhitekturalne komponente koje omogućavaju da se odradi jedna operacija (postavi obaveštenje).

 

Sam kostur nije kompletan. Arhitektura takođe, ali liči na ono ka čemu idemo i očekujemo da od postojeće možemo da evoluiramo željenu. Kostur jedva da šeta: forma za objavljivanje ne omogućava stilizaciju sadržaja, dodavanje slika i tabela itd, kolege ne mogu da komentarišu objave, nema nikakve mogućnosti za pretragu i kategorizaciju sadržaja, nema obaveštanja kada se postavi nova vest itd. 

Sve ove stvari i puno više od toga lagano možemo da dodajemo ukoliko se odlučimo da zadržimo rešenje i nastavimo da investiramo u njega. Proces daljeg razvoja može teći u iteracijama, a kroz njega ćemo dodavati novu funkcionalnost, usavršavati arhitekturu, unaprediti izgled i pristupačnost aplikacije, dodati mogućnost pristupa sa drugih tipova uređaja i tako dalje.

Hodajući kostur nije…

 

MVP

Hodajući kostur nije MVP. Pođimo od MVP definicije koju Eric Ries nudi u Lean Startup knjizi:

MVP je ona verzija novog proizvoda koja timu dozvoljava da ostvari najveću količinu validairanog učenja o mušterijama uz najmanji napor.

Cilj MVP-ja je učenje uz minimalan napor. Sama definicija ne podrazumeva fokus na komponente arhitekture, tehnička rešenja, niti se ograničava na to da se realizuje samo jedna funkcionalnost od kraja do kraja. U nekim interpretacijama, MVP čak ne mora ni da radi ono što proizvod koji želimo da napravimo radi. Dovoljno je da nam omogući da učimo o mušterijama ono što nam je potrebno da bismo realizovali kao proizvod.

Sa svim tim na umu, zaključujem da MVP nekada može da ima oblik Hodajućeg kostura, ali da to po definiciji ne mora da bude.

Spajk

Hodajući korstur nije spajk. Ovu razliku naglaša Alistair Cockburn opisujući Walking Sceleton strategiju u Crystal Clear knjizi.

Spajk je minimalna implementacija koja demonstira mogućnost uspešnog tehničkog rešavanja problema. Cilj je da nam kaže da li smo se krenuli u pogrešnom smeru, a taj cilj ostvaruje uz ulaganje minimalnog napora, što uglavnom podrazumeva pisanjem koda koji nije namenjen produkciji.

Za razliku od spajka, gde se proizvedeni kod uglavnom odbacuje pošto se nauči da li smo na pravom putu kao ostvarivom tehničkom rešenju ili ne, kod koji nastaje tokom razvoja Hodajućeg kostura je kod koji nameravamo da zadžimo na kome želimo dalje da razvijamo arhitekturu i rešenje.

Korak dalje.

Knjiga u kojoj je Hodajući kostur opisan je izašla pre više od 15 godina. U međuvremenu su neki alati i tehnike postali dosta bolji i dostupniji, tako da možemo da odemo i korak dalje po pitanju toga šta je hodajući kostur i šta sa njime možemo da postgnemo.

Prvi očigledan korak je da uz Hodajući kostur imamo automatizovane korake integracije, testiranja i isporuke, kao i sisteme kojim možemo da pratimo ponašanje sistema u produkciji. Na ovaj način svaki paket izmena koji prolazi testove biva automatski isporučen u produkciju. Moderne Cloud platforme i CI/CD rešenja omogućavaju da u produkciju odemo već prvog dana i da dalje iteriramo odatle. 

Ranije sam ovakav pristup zvao “Prodikcijom od prvog dana”, ali sam u međuvremenu naučio da je u nekim krugovima obrazac poznat kao Plešući kostur (Dancing sceleton).

Plešući i Hodajući kostur su slični u tome da nam pomažu da otkrijemo i rešimo neprijatna iznenađenja koja bi nas sačekala kasnije. U slučaju Plešućeg kostura, rešavamo putu do produkcije, a kod Hodajući integraciju komponenti arhitekture. Međusobno nisu isključivi, tako da je velika verovatnoća da će početak rada na današnjim projektima najbolje opslužiti neka mešavina ova dva modela.

Gojko Adžić dalje savetuje da stavimo kostur “na štake” kako bismo isporučili ranije. Pod tim misli da se ne trudimo da kostur prohoda, već da se fokusiramo na korisnički interfejs (UI), a da u pozadini uvežemo neke od mnogih servisa umesto da pravimo naš backend i bavimo se arhitekturalnim problemima koji stoje iza njega. 

Na primer, umesto da pravimo naš sistem za praćenje događaja u aplikaciji, možemo koristiti Google Analytics. Za prijavljivanje korisnika  na servis i aktiviranje pretplate možemo koristiti neki od form-builder alata koje povežemo sa Google Spredaheet dokumentom i našim Stripe nalogom, dok ne napravimo našu bazu i Stripe integraciju. Kada ubaimo red u taj Google dokument, možemo kroz Zapier dodati korisnima u CRM i na mailing listu.

Opcija ima puno i možemo stvarno puno da postignemo bez pisanja koda. Kostur na štakama možemo koristiti da testiramo naše pretpostavke, privučemo prve korisnike, demonstriramo rešenje klijentima itd. Vremenom možemo da odbacujemo štake kada se za to ukaže potreba i kada nam to vreme dozvoli.

Reference

 

Alistair Cockburn “Crystal Clear: A Human-Powered Methodology for Small Teams”

Eric Ries “The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses“

Spike Solution @ c2 wiki

Dan North “Decisions, Decisions” @ 57:02

Gojko Adžić “Forget the walking skeleton – put it on crutches“

Fotografija: Mathew Schwartz.

…