Agilni projekti - reflektivne izboljšave

Ob branju prosto dostopnega poglavja knjige A Human-Powered Methodology for Small Teams, ki govori o lastnostih, ki naj bi jih imel projekt, da izpolni pogoje agilnosti, je drugi lastnosti ime - reflektivne izboljšave.

Od vseh sedmih, ki jih poglavje opisuje je ta po mojih izkušnjah najmanj problematična, saj še nisem sodeloval v projektu, kjer se ne bi sodelujoči občasno (tedensko ali dvo-tedensko) usedli skupaj in predebatirali probleme in morebitne rešitve.

Avtor to lastnost začne opisovati s presenečenjem, ki ga je doživel ob nekem projektu.

Skupina se je sestala po 4 mesecih dela in ugotovila, da so daleč za rokom izdelave, arhitekturna zasnova pa slaba. Ni treba posebej poudarjati, da je bila skupina demoralizirana. Vodstvo je odpustilo 23 od 24. razvijalcev in najela 23 novih. Reorganizirali so skupine in vodstvene ljudi, plačali nekajtedenska izobraževanja in začeli znova od začetka.

Po njihovi četrti iteraciji (o iteracijah pišem tu) je bil dizajn izdelan, že izdelana koda pa je prehitevala projektno časovnico. Avtor pravi, da je večina projektov pri katerih je bil zraven imela težke porodne krče. S sestajanjem se pridobi veliko novih informacij o projektu in okolju v katerem živi. Te informacije so podlaga za odločitve o morebitnih spremembah pri izboru orodij in tehnologij.

Nič posebnega. Metode za doseganje zadanih ciljev so ali pa niso primerne za določeno skupino. Omenja tipične pristope ektremnega programiranja: programiranja v parih, unit testing, test-driven development, pa malo manj znano - delo v samostojni pisarni napram delu v sobi z veliko ljudmi.

Sam večino časa delam na razvojno naravnanih projektih, zato je izmenjava idej in preizkušanje del vsakdanjika. Reflektivne izboljšave so najbrž samo lepo ime za običajne delovne sestanke.

Tapestry

Naj za hiter uvod nakažem kaj je stvar iz naslova. Tapestry je ogrodje (framework) za izdelavo spletnih aplikacij v jeziku Java. Prinaša spremembo v načinu razmišljanja in pozitivne učinke v razvojnem ciklu, ki seveda vključuje tudi oblikovalce. Delo je popolnoma objektno orientirano, kar pomeni, da ne razmišljamo kako sestaviti URL za izvedbo določene akcije na strežniški strani. Ravno tako ne skrbimo za nastavljanje parametrov, členjenje URL-jev in druge nizkonivojske operacije. Tapestry nadgrajuje Java Servlet API, kar omogoča delovanje spletne aplikacije v kateremkoli (npr. Tomcat) Java EE kontejnerju.

Na Tapestry poštno listo za uporabnike sem se vpisal avgusta leta 2004. Ponavadi se na listo za uporabnike prijavim takrat, ko me tema res zanima in jo v praksi tudi uporabljam. Lahko rečem, da sem programiranje spletnih aplikacij spoznal (leta 2000) iz diametralno nasprotne strani kot večina ostalih spletnih programerjev. Šok, ki sem ga doživel ob prehodu iz spletnega ogrodja WebObjects (WO) na Java Server Pages (JSP) ni bil majhen. Veselje ob odkritju Tapestry ogrodja je bilo veliko, saj sem že takoj na začetku spoznal WO korenine in idejne zasnove.

Spletne strani so sestavljene iz komponent, vsaka odgovorna za del funkcionalnosti. Komponente so po funkcionalnosti različne (vizualne, nevizualne) in jih seveda lahko pišemo na enostaven način tudi sami. Poleg priloženih je nastalo že veliko novih v prostokodni skupnosti. Za lažjo predstavo kaj je to komponenta: DirectLink, For, Form, Image, Script, in veliko drugih.

Mogoče je najpomembnejša lastnost način doseganja iluzije, da uporabnik z spletno aplikacijo ne komunicira prek stateless HTTP protokola. Tapestry ponuja več načinov kako hraniti stanje uporabnika od ene do druge HTTP zahteve.

Večna dilema je tudi sodelovanje programerjev in oblikovalcev. Tapestry se tega loti takole: HTML ne vsebuje nobene nove značke, kar pomeni, da lahko HTML predlogo gledamo med samim razvojem tako kot jo vidi oblikovalec - z vsemi dinamičnimi elementi - tudi seznami, ki se v živo npr. zgradijo iz podatkov iz podatkovne baze! To je mogoče zaradi zelo zelo premišljenega koncepta, ki je že od vsega začetka vključeval idejo tesnega sodelovanja programerjev in oblikovalcev. Najbolj enostaven primer je vsem znani HelloWorld. Samo za okus.

Validacija vnosnih polj je neobhodna naloga, ki jo Tapestry olajša na skorajda rutinsko opravilo. Poleg vgrajenih (min, max, email, minLength, maxLength, pattern, minDate, maxDate) lahko pišemo svoje validacijske algoritme (npr. preverba znakov iz generirane popačene slike), na strežniški in uporabnikovi strani - na enem mestu. Poglejte si tretje poglavje knjige Enjoying Web Development with Tapestry, ki jo tudi priporočam, če želite spoznati Tapestry, saj vas vodi zelo natančno od namestitve naprej. Prebral sem že kakšno knjigo, ampak tako dobro napisanih primerov še nisem srečal. Mislim, da je avtor Kent Tong izdal še eno knjigo na temo Web Services, ki bo tudi zagotovo na moji mizi.

Če bi moral na kratko povzeti ključne točke:

1. Pristop k programiranju spletnih aplikacij ne zahteva razmišljanja o URL naslovih in parametrih v njih, ampak o objektih, metodah in lastnostih.
2. Značilna je zelo visoka stopnja ponovne uporabe že narejenih komponent med projekti. Poudarjam, to ni copy/paste.
3. URL-je gradi framework. Posledično pomeni, da kompleksnost spletnih strani ne raste hitro z velikostjo aplikacije.
4. Enostavna lokalizacija in validacija.
5. Najenostavnejša integracija programerjev in dizajnerjev do sedaj tudi za velike projekte.
6. Zelo robustna aplikacija (manj kode, manj napak). Napake se sporočajo zelo natančno, zato jih lahko hitreje odpravljamo.
7. Persistenca med zahtevami uporabnika.

Zaradi arhitekture nam Tapestry ponuja odlično MVC okolje.

Topic Maps

Pred meseci sem se začel ukvarjati s problemom čigar rešitev vidim v znanju, ki se je začelo zbirati v začetku devedesetih let prejšnjega tisočletja, torej pred petnajstimi leti.

Začetni problem je bil izbrati ali izdelati ustrezno podatkovno strukturo, s katero bi lahko modeliral poljubne objekte in njihove lastnosti. Potreboval sem nekaj uporabnega, po možnosti programsko knjižnico z jasno definiranim API vmesnikom, ki bi jo nemudoma lahko uporabil kot temelj podatkovno gnane spletne aplikacije.

Nemalo časa sem porabil za iskanje in v tem času je mojo raziskovalno pot prekrižalo ogromno novih pojmov in zloglasnih tri-črkovnih kratic. Da se ne zapletem vanje že na začetku, bom poskusil na kratko obrazložiti pojem iz naslova tega bloga - topic maps.

Topic maps so ISO standard za predstavitev in izmenjavo znanja s poudarkom na lažji pridobitvi željene informacije. V njih so informacije predstavljene s temami (topics), asociaciami (associations) in pojavitvami (occurances). Za občutek kaj bi posamezni pojmi lahko predstavljali:

Topic Praktično karkoli. To je lahko oseba, začimba, številka, dogodek, datoteka, ...
Association Relacije med zgornjimi temami.
Occurance Relacije med temami in njihovimi pojavitvami v določenih kontekstih.

Topic map zgradimo z XML dialektom imenovanim XTM. Obstajajo orodja, tako odprtokodna kot komercialna, za izdelavo, različne vizualne predstavitve, analize in zlivanja že zgrajenih map. To slednje je zelo pomembno, ker pomeni združevanje znanja. Najlaže ilustriram na primeru.

Nekdo ali neka organizacija pripravi topic map, ki popisuje npr. začimbe za hrano. Na drugem koncu sveta je nekdo storil isto in ker tam rastejo drugačne rastline, je logično, da njegova mapa vsebuje nekaj zeli, ki jih prvi popisovalec ni vključil. Nekdo tretji je najbrž že opisal merske enote. Sedaj lahko jaz opišem kaj je to krompir, fižol, moka, jajca, vi pa iz vsega dosedaj naštetega in zlitega skupaj sestavite opis za nekaj jedi!

S tako bogatimi opisi se odpirajo ogromne možnosti predstavitev podatkov in predvsem iskanja po še vedno eksponentno naraščajočih količinah informacij, predvsem pa je to dober temelj za semantični splet - gotove bodočnosti.

Omeniti moram še RDF (Resource Description Framework), ki je "ravno tako" primeren za enkodiranje, izmenjavo in uporabo strukturiranih (meta)podatkov v XML obliki. Ker se vanj še nisem poglabljal, ne morem narediti niti kratke primerjave - mogoče v eni izmed naslednjih objav.

Vsebine, ki sem se jih samo dotaknil, so zelo obsežne in odpirajo celo nove delovne discipline, kot je na primer informacijski arhitekt, ki naj bi predstavil vsebine na tak način, da bi jih obiskovalci spletne strani z lahkoto našli in po njih navigirali. Hkrati naročniku ne sme naložiti nemogoče naloge pri pripravi podatkov in ne nazadnje razvijalcem ne dati pretrdega oreha pri izdelavi aplikacije.

Agilni projekti - pogosta dostava

Zagotovo je najpomembnejša lastnost vsakega projekta, naj bo ta majhen ali velik, pogosta dostava v hiši pretestirane aplikacije končnim uporabnikom.

Naročnik s tem dobi jasen vpogled v napredek izdelka. Uporabniki lahko na ta način hitreje pridobijo izkušnje in občutek ali je izdelek to kar v resnici potrebujejo. Vse pripombe in novi zahtevki se zbirajo sproti, da je razvijalcem lažje snovanje. Razvojna ekipa se na tak način tudi izogne pogostim zastojem zaradi nezmožnosti sprejetja odločitve o določenem aplikacijskem problemu. Nenazadnje to omogoča zgodnje razhroščevanje in pogostejši pregled nad razvojnim ciklom. Skupini se prileže tudi doza moralne vzpodbude z dokončanjem cikla.

Dostave programske opreme se razlikujejo, saj to lahko pomeni namestitve na delovnih postajah vseh končnih uporabnikov ali pa druga skrajnost posodobitev spletne aplikacije. Slednje je seveda neprimerno lažje, zato lahko dostavljamo pogosteje - tudi v dvo tedenskih ciklih, če je potrebno.

Prepogoste menjave ali nadgradnje uporabnike v najboljšem primeru jezijo. Če je možno si v takih primerih pomagamo z uporabniki, ki želijo imeti najnovejšo različico in tako pri njemu/njej "vadimo" namestitev in od njega/nje pridobivamo povratne informacije.

Integracija in iteracija sta dva različna pojma, ki ju ne smemo mešati. Integracija je postopek, ki mora biti v največji meri avtomatiziran v navezi z avtomatskimi testi in se mora dogajati čim pogosteje - boljše ekipe imajo samo 30 minutni interval. Iteracija pa vsebuje dokončanje sklopa cele skupine, integracije, poročil nadrejenim, pogovora v obliki reflektivnih izboljšav in pa seveda doseganje občutka dokončanja dela naloge. Ta občutek je zelo pomemben in zagotovo pripomore k izboljšanju timskega duha.

Past v katero se radi ujamemo je podaljševanje roka za konec načrtovanih iteracij zaradi nedokončanih delov aplikacije. Četudi dobronamerno, odgovorna oseba za odobritev teh podaljškov ekipi na dolgi rok bolj škodi, saj se emocije ob zaključkih nikoli ne zgodijo.

V odvisnosti od "sovražnosti" okolja oziroma naročnika, se odloča o tem ali naj se fiksira zahtevke do njihove izvedbe. Če naročnik pogosto spreminja zahteve, je to vsekakor pomembno.

Povzeto po knjigi Crystal Clear: A Human-Powered Methodology for Small Teams.