Agilni metod razvoja softvera

Promene koje je agilna metodologija donela u Microsoft nisu vidljive samo u proizvodima koje koristimo, već i u samoj kompaniji iz Redmonda.

Mnogo toga se može zameriti kompaniji koja je postala sinonim za operativni sistem – američkom softverskom mastodontu po imenu Microsoft. Neki će reći da su monopolisti, drugi da kasne sa verzijama svojih najbitnijih proizvoda, treći da su ispali smešni u prvoj eri interneta. Ipak, ova kompanija je zaslužna što je softver dospeo na mesto na kome se danas nalazi. Svet pre ove kompanije nije vrednovao kôd ili aplikacije, cenila se samo mašina, ono što ste mogli da dodirnete. Ipak, zahvaljujući spletu okolnosti, dobrim potezima i pravovremenim „pozajmljivanjima” rešenja, Bil Gejts i drugari osvojili su svet. U decenijama koje su sledile, personalni računar je cvetao. Sa njim u trku, bučno i nespretno koračajući, rastao je i Microsoft, naizgled beskrajno iterirajući kroz verzije operativnih sistema, paketa kancelarijskog softvera i drugih pokušaja dominacije, koji nikada nisu postigli uspeh starije braće. U tom vrtlogu, Microsoft je, uprkos ulozi koju je imao, do dana današnjeg ostao sinonim za ne tako dobru softversku kompaniju. Argumenti za taj stav su već pomenuti – gotovo sve verzije operativnih sistema ovog proizvođača su kasnile, ponekada previše. Kada na to dodate da je ona verzija koja je najviše kasnila, Windows Vista, bila ujedno i najnestabilniji OS u gami do sada (mada ni Windows ME nije puno zaostajao), osećate se kao da vam je u restoranu, posle dugog čekanja, poslužena prekuvana, gnojiva masa, i to na prljavom tanjiru. Jedan od razloga zbog kojih se ovo dešavalo se krije u metodologiji koja je korišćena za razvoj. No, već četiri godine, u Microsoftu se „igraju” i sa drugim, savremenijim pristupima. Rezultati su počeli da pristižu. I nisu loši. Nimalo loši.

Vodopadi su krivi, ili ipak ne

Pomenuto kašnjenje u izlasku najbitnijih softverskih paketa u gami kompanije Microsoft nije bilo uzrokovano samo jednim razlogom. Tu ne treba posebno mistifikovati nijedan pojedinačni aspekt razvoja softvera jer ova delatnost, sama po sebi, nije nimalo jednostavna niti jednodimenzionalna. Iskustvo u razvoju softvera vas vremenom uči da, ma koliko neki pokušavali da ga ukalupe, ne postoji jedan pravi način. Ukoliko ste kad gledali TED predavanje Malkoma Gledvela (a ako niste, onda ne časite ni časa i potražite ga na http://goo.gl/FvShsF), onda znate da zapravo nikada ne postoji samo jedno savršeno rešenje već više savršenih rešenja. Ipak, kao i u drugim sferama čovekovog delovanja, pokušavali smo da standardizujemo ovu delatnost, ako ni zbog čega drugog, onda svakako da bismo joj udenuli sposobnost lakog upoređivanja sa ostalima. Razne formalizacije ovog procesa su u decenijama iza nas bile predlagane, ali je jedna od njih doživela broj implementacija kojem nije prišao ni skup svih ostalih zajedno. U pitanju je takozvani Waterfall.

Formalno predstavljen 1970. godine, ovaj model projektovanja softvera je zasnovan na sekvencijalnom procesu, u kom se napredak projekta „sliva” iz faze u fazu (kao niz terase vodopada, po čemu je i dobio ime). Iako je moguće u takvom procesu imati i više faza, nekakav osnovni koncept podrazumeva niz sastavljen iz Analize, Dizajna, Implementacije, Testiranja, Produkcije i Održavanja. Ovaj koncept nije autohton za razvoj softvera. Njegovo poreklo dolazi iz industrije, posebno procesa proizvodnje složenih objekata, poput automobila. U takvom jednom procesu, zaista je bitno da dizajn čitavog konačnog rešenja imate pre no što krenete u proizvodnju. Jednostavno, dizajn rešenja mora biti očuvan do kraja procesa proizvodnje i najbolji način da to uradite je da pre nego što krenete u proizvodnju, dizajn do najsitnijih detalja izvedete i, što je jednako važno, dobro dokumentujete. Godine upotrebe su donele i statističke pokazatelje efekata upotrebe ovakvog procesa. U analizi i dizajnu sa obično troši 20-40%, u implementaciji 30-40%, a preostalo vreme se troši na testiranje i produkciju. Osnovni razlog zbog čega je ovaj model do dana današnjeg ostao na snazi u mnogim modelima projektovanja je taj da je veoma intuitivan, bar za proces proizvodnje. Naime, ukoliko ne radite po ovom modelu, morali biste da u toku proizvodnje (automobila, na primer) menjate dizajn, što bi povećalo vreme izrade i dovelo u pitanje čitav projekat. No, softver nije automobil i za njega ne važe tako stroga pravila. Uprkos tome, u toku poslednjih 40-ak godina, „vodopadi” su našli svoje mesto u samom srcu softverske industrije.

Upotreba modela Waterfall nikada nije bila propraćena velikim brojem argumenata u njegovu korist. Čak i u najranijim upotrebama ovog modela bilo je jasno da postoji puno problema. Na primer, neretko se dešavalo da se u toku implementacije shvati da postoji nepotrebna redundansa kôda i da je potrebno da se kôd dodatno optimizuje. Često se shvati da proces nije dobro centralizovan ili decentralizovan i da postoji mnogo bolji način organizacije kôda. Što je projekat veći, veća je i verovatnoća da će vodopadi pasti na zadatku optimizovanog dizajna. Ipak, ne bi bilo pravedno da ne podvučemo još nekoliko bitnih stavki. U čitavoj priči oko efikasnosti i efektivnosti Waterfall modela itekako je bitan kvalitet i iskustvo ljudi koji učestvuju u izradi svake od faza projekta. Iskusniji i kvalitetniji dizajneri softverske arhitekture će jako voleti ovaj princip jer mogu u jednom potezu (fazi) da urade čitav model – od koncepta do konkretne arhitekture, na papiru. Davanje ovako odgovorne uloge početnicima i manje kvalitetnim dizajnerima će često usloviti veliki broj izmena u fazi implementacije. No, svi ovi problemi se, posebno vremenom, smanje na relativno prihvatljivu granicu. Poseban problem se, pak, dešavao u fazi testiranja.

Ali, ja to nisam hteo

Došli smo do faze testiranja, posebno do dela u kom budući korisnici sistema validiraju urađeno u odnosu na ono što su želeli. I tu se dešava veliki obrt u našoj priči. Klijent je nezadovoljan. Funkcionalnost niti izgleda niti radi kako je on to „zamislio”. Ovo je naravno česta situacija, koja se do sada u praksi rešavala na razne načine. Pokušaj sistemskog pristupa borbi protiv nezgodnih iznenađenja leži u dokumentaciji. Pokušajmo da pojednostavimo objašnjenje. Na kraju svake faze, klijent potpisuje dokument u kom sve piše, relativno precizno, i šta se radi, i kako se radi, ponekada i zašto se baš tako radi. Kada se pređe u narednu fazu, ukoliko klijent kojim slučajem kaže kako to nije ono što je želeo, jedan pogled u dokumentaciju i često se pokaže da možda klijent nije tako želeo, ali je potpisao da jeste. Tada se ulazi u fazu pregovora oko promene zahteva i klijent plaća dodatno da dovede sistem u okvire svojih želja.

Dokumentacija i njeno pisanje imaju još niz bitnih koristi po čitav projekat. Jedan od najvažnijih je onaj da u velikim, zahtevnim projektima koji se dugo izrađuju, dinamika izrade projekta ne zavisi od odlazaka pojedinaca. Kako je sve dobro dokumentovano u prolasku kroz faze, pojedinci se mogu relativno bezbolno zameniti novim, kojima, uslovno rečeno, ne bi trebalo da bude potrebno previše vremena da „uskoče u sedlo”. Iako je veoma jednostavno ovo sve staviti u kontekst razvoja komercijalnog softvera za potrebe nekog poslovnog klijenta, kada se radi o razvoju softvera za mase (kakav je gotovo svaki proizvod kompanije Microsoft) stvari dobijaju još po koju dimenziju.

Uzmimo primer, prema mišljenju najvećeg broja programera i kodera širom planete, najboljeg korisničkog okruženja za razvoj softvera, paketa Visual Studio. Bitno je istaći, u kontekstu naše priče, da je razvojni ciklus ovog softverskog paketa (čak i do verzije 2010, koja će predstavljati pivotalnu tačku u našoj priči) bio kraći od onog koji je bio vezan za operativne sisteme. Umesto trogodišnjeg čekanja na novu verziju, u svetu VS-a se čekalo „samo” dve. Prvi pogled na proces razvoja ovog paketa bi vas možda zaveo da pomislite kako je njegova suština iterativna, a ne sekvencijalna, ali biste malo dubljim kompanjem i te kako razumeli da se radi o starom dobrom vodopadu.

Prvu fazu nove verzije VS-a čine projektovanje i dizajn. Trajanje ove faze je podešeno na četiri do šest nedelja i zadatak učesnika je da do kraja faze definišu doseg i funkcionalnosti koje će se naći u verziji. Sledeća faza uključuje sve elemente razvoja, traje do osam nedelja i na svom kraju predstavlja zaokruženu celinu. Treću fazu čini oko 16 nedelja testiranja i stabilizacije čitavog projekta. Na kraju ove faze, počinje faza beta testiranja. Dok beta-testeri rade svoj posao, ponovo se ulazi u proces razvoja (u sličnom trajanju kao i prethodna „iteracija”) a zatim i novih 16 nedelja stabilizacije. Naposletku, finalni proizvod izlazi u javnost. Da li uočavate problem?

Iteriraj, iteriraj

Uzmimo na primer, pomenuti proces stabilizacije u drugoj iteraciji. Njegovo trajanje od četiri meseca deluje relativno adekvatno poslu kom je namenjeno. Ipak, osnovni problem proističe upravo iz njegovog trajanja. Ukoliko ste beta tester koji prijavljuje bag, od izuzetnog je značaja trenutak u kom ćete pronađeni bag (dobro dokumentovan, što često zakasni slanje) poslati projektnom timu. Ukoliko ste to učinili u trećoj trećini ove faze, velika je verovatnoća da taj bag prosto neće biti na vreme servisiran i da će u produkcionoj verziji softvera on i dalje biti aktuelan. Vaš dobro dokumentovani bag će čekati novu fazu stabilizacije i nekakav Service Pack, kako bi nova verzija Visual Studio paketa bila očišćena. Kako niste jedini beta-tester, ovo se sigurno desilo i drugima, pa tako nemali broj bagova postoji u produkcionoj verziji.

Verovatno sada imate mnoge ideje kako bi ovaj proces mogao da se popravi. Sigurno su neke od tih ideja za konkretan primer razvoja VS-a i dobre. Ipak, postavlja se pitanje možemo li da napravimo jednu sistemsku apstrakciju rešenja ovog i drugih problema vodopada koja bi nam učinila nekoliko plezira od jednom. Srećom, ne moramo mnogo da razmišljamo. Alternativa već postoji.

Kraj devedesetih godina prošloga veka i početak novog milenijuma sa sobom su doneli vlast verovatno najbitnijeg čovekovog otkrića u vremenu u kom živimo – interneta. Microsoft je i u toj igri igrao ulogu, samo, ovoga puta, više nego podređenu. Po sopstvenom priznanju, Gejts nije predvideo da će internet biti značajan koliko se to pokazalo. No, u uslovima njegovog globalnog rasta i uspeha, internet je sa sobom doneo i talas promena koji vodopadu nude alternativu. Način na koji se softver koristi na internetu je bitno drugačiji od onog koji je razvijan metodom vodopada. Instalacija je nestala, testiranje je bitno drugačije, model licenciranja je suštinski izmenjen. Pristup unapređenjima, ispod i iznad haube, zreo za izmenu, konačno je dobio svoju priliku da zasija. Greške koje su izvedene u produkciji su mogle relativno bezbolno i brzo da se isprave jednostavnim osvežavanjem kôda na serveru, dok korisnik na klijentu toga nije ni svestan.

Sve je ovo moguće zahvaljujući procesu koji danas poznajemo kao agilni metod. Njegova osnova leži u iterativnom postupku izrade, sa relativno kratkim iteracijama kojima se zbog veličine lakše upravlja i čiji su budući korisnici sastavni deo tima. Svaka od ovih iteracija bi, ma koliko mala, morala da zaokružuje jednu funkcionalnost. Uključeni korisnici su tu da u ranoj fazi konkretne funkcionalnosti utiču na rad projektno-razvojnog tima i time približavaju konačno rešenje željenom.

Prve korake u novom plesu, Microsoft je izveo na nesvakidašnji način. Naime, projektni tim iza Visual Studio paketa je neko vreme radio na dodatku koji će podržati agilne metode izrade softvera. Prvi rezultati nisu bili zadovoljavajući. Tada je rastuća zajednica agilnih programera dala svoj doprinos i svi ti komentari su uticali ne samo da se izradi bolji dodatak za VS, već i da se čitav razvoj Visual Studio paketa učini agilnim. Danas, Team Foundation Server predstavlja srce razvoja na Microsoftovim tehnologijama. U njemu je moguće voditi projekte po agilnoj metodologiji, veoma, veoma kvalitetno.

Kako bi čitava stvar bila do kraja završena, potreban je bio još samo jedan element. On je usledio vrlo brzo. Kupovinom Skypea, sredinom 2011. godine, Microsoft je, pored dobitka najpopularnijeg softvera za prenos zvuka i slike između korisnika, dobio i tim koji je neko vreme već bio verziran u agilnom pristupu. Rezultati kolaboracije Skypeovih kodera i dela tima odgovornog za Visual Studio su vrlo brzo pokazali da agilna metodologija itekako ima svoje mesto u softverskom gigantu. Jedan od plodova ove saradnje je i Lync, Microsoftov alat za komunikaciju i kolaboraciju u Enterprise svetu. Autor ovog teksta ga na poslu koristi svakodnevno i može da potvrdi njegov izuzetan kvalitet i česte updateove koji stižu preko interneta.

• • •

Jedan od poslednjih uporišta vodopadnog razvoja je ostao Microsoft Office. Za to, Microsoft i nije toliko kriv. Krivi smo mi. Znate li onaj momenat kada se korisnički interfejs promeni u odnosu na poslednju verziju pa počnemo da pljujemo po Gejtsu, Bolmeru, Sadeli? Slično se ponašamo i kada je Windows u pitanju. Navika je čudo. Ipak, zar da dozvolimo da navika predstavlja toliku branu za promenu na bolje? Promene koje je agilna metodologija donela u Microsoft nisu vidljive samo u proizvodima koje koristimo. Svoj su uticaj one izvršile i na organizacionu kulturu dela Microsofta. Namesto dotadašnjeg standarda, solo kancelarija za svakog programera u kojoj ste kao početnik počinjali u svojevrsnoj „samici”, a napretkom dobijali sve veće prozore, sada timovi agilnih programera dele kancelarije. I sve imaju prozore. Zar ijedna druga varijanta treba da postoji?

Momir ĐEKIĆ