Nastavit ćemo temu započetu prošlim člankom s malom dizertacijom o razlozima uspješnosti Agile projekata.
Agile projekti su po mojem mišljenju uspješniji zbog kvalitetnije komunikacije između svih sudionika i veće spremnosti svih sudionika na promjene. Što to znači? To su, zapravo, samo alati za borbu protiv već prije spomenutih i svima nama poznatih demona: promjena ciljeva u toku projekta i pogrešnih procjena o vremenu potrebnom za implementaciju.
Ključno je razumjeti da i uz najbolju volju kupac stvarno neće znati što želi dok mu se u rukama ne nađe prva verzija vašeg uratka. Tim koji implementira novi projekt mora biti spreman na promjene u ciljevima klijenta a takve promjene je lakše napraviti ako se iterativnim pristupom i kvalitetnom komunikacijom ranije identificira potreba za promjenom smjera. Ako radite mjesecima na projektu malo vam je teže mijenjati smjer u odnosu na situaciju kad nakon dva tjedna klijent testirajući vaš kod odluči da bi želio nešto drugo. Kako uopće pristupiti izradi projekta koji omogućuje klijentu da rano dobije vaš rad u ruke, i to u stanju da se već može testirati funkcionalnost? Jedan od pristupa je vertikalna implementacija svih podsustava, ali samo u onom opsegu koji je potreban da bi se implementirala određena funkcionalnost cijelog sustava. To je suprotno uobičajenoj praksi da se sustav implementira sloj po sloj.
Pokušat ću vertikalni pristup implementaciji opisati primjerom: zamislite da želite izgraditi web shop. Vaš klijent ima posebne ideje o interakciji s kupcima tako da već gotovi web shop proizvodi jednostavno nisu primjenjivi i cijelom problemu treba pristupiti iznova. Nakon identifikacije svih zahtjeva isplanirate arhitekturu sustava i krećete u izradu sloj po sloj. Najprije definirate data model i kreirate bazu podataka. Zatim middleware sloj s određenom količinom business logike. Zatim prezentacijski sloj s web sučeljem prema korisnicima i sa administracijskim sučeljem. Zatim dodajete preko svega sloj koji pazi na sigurnost (na sigurnost se uvijek misli na kraju!). Sve to nakon npr. četiri mjeseca posla fino povežete, isporučite klijentu, on to počne testirati i već pri proceduri registracije novog korisnika web shopa ima primjedbe na samu proceduru (npr. procedura je previše složena i traži se previše podataka). Kreće natezanje, s tipičnom rečenicom od strane izvođača: "U specifikaciji ste lijepo napisali da..." i tipičnim odgovorom klijenta: "Jesam ali nisam mislio da će to biti izvedeno na ovaj način".
Da ste išli u vertikalnu implementaciju sustava krenuli bi ovako: U ovom ciklusu vam je zadatak implementirati prijavu i registraciju korisnika. U bazi podataka definirate SAMO onaj dio ukupnog data modela koji je minimalno potreban za implementaciju ove funkcionalnosti. U middleware sloju implementirate opet SAMO one funkcije potrebne za registraciju i prijavu korisnika. U prezentacijskom dijelu... shvaćate što želim reći. Dva tjedna kasnije vi ponosni na svoj rad isporučite ovu fukcionalnost klijentu. Klijent, naravno, kao i u prvoj priči, isto ima primjedbe. Ovaj put vi ste, kao izvođač, spremniji na promjene jer ste uložili samo 2 tjedna vremena u ovaj podsustav a štedite i zbog toga što ne morate raditi izmjene na podsustavima koji još ne postoje a možda bi se pojavila potreba za njihovim promjenana kao posljedica promjena na prvom podsustavu. Krajnji rezultat: klijentu isporučujete ono što je bliže njegovim željama, odnosno, isporučujete veću vrijednost.
Ovakav pristup izgradnji stvara i jedan drugačiji mentalni model cijelog sustava pa arhitektura obično postaje više modularna i podsustavi nisu toliko međusobno isprepleteni. Kasnije, kad poželite raditi promjene (pa čak i radikalne) ne morate previše brinuti da će promjene u jednom dijelu sustava učiniti štetu na ostalim podsustavima.
| Igor Rumiha nezavisni je konzultant koji se u svojoj IT karijeri od 2000. godine do danas bavio izradom sustava za mrežni nadzor, provisioning sustavima u ISP i mobile telekom okolinama i automatizacije testova na embedded platformama. U pauzama između tih poslova bavio se administracijom Oracle i MSSQL baza, billing sustava pa čak i izradom billing sustava. |
