Agilni projekti - osebna varnost

Osebna varnost pomeni zmožnost izražanja svojih pogledov brez strahu pred kakršnimikoli povračilnimi ukrepi.

Projektno delo v skupini običajno živi v hierarhičnem okolju sodelavcev, vodij skupin, menedžerjev, naročnikov, strank in še koga. Varnost pomeni, da smo sposobni v oči povedati menedžerju, da je njegov rok za predviden dan izida daleč preoptimističen.

Pomeni to, da smo sposobni povedati sodelavcu, da nas moti njegova smrdljiva srajca. Pomeni to, da lahko sodelavcu brez strahu povemo, da njegov načrt ali izvedba nista za nikamor. Brez takih odprtih pogovorov škodujemo celotni ekipi.

Ali ste že imeli sodelavca ali sodelavko, ki pri jedi sendviča tako cmoka, da ga (jo) je slišati v sosednji volilni okraj? Pa ste mu (ji) kaj rekli? Ali se je sploh vredno za nekaj minut trpljenja dnevno izpostavljati in potem poslušati ego obrambne protinapade? Kakor kdo, kakor kje, kakor za kaj. Bolj moteči so hrup ali celo konstantno tresenje mize, ker ima sodelavec "v riti mravljince". Verjetno ima vsakdo od vas še bolj pikantne primere!

Osebna varnost je pot do izgradnje timskega zaupanja. Zaupanje pomeni, da nekomu damo moč nad nami in pri tem tvegamo, da nas rani. Nekateri smo po naravi bolj odprti kot drugi, ravno tako kot nekateri gledamo na svet bolj optimistično kot drugi. Nezaupanje v delovni skupni povzroča celo vrsto negativnih posledic - prikrivanje ali celo laganje, slabše opravljeno delo zaradi pomanjkanja informacij, izdajanje poslovnih informacij in še kaj. Za povečanje zaupanja se moramo odpreti, to pomeni priznavati svoje šibkosti, a pri tem vedeti, da nam drugi zaradi tega ne bodo škodovali. Priznanje, da česa ne znamo, da smo kaj naredili narobe, ali da česa ne bomo zmogli je pogoj. Takoj za tem pa mora biti na voljo pomoč ostalih v skupini - neavtoritativna in dobrovoljna!

Živali se ob nesporazumih pogrizejo. Koliko krvavi končujemo izmenjavo mnenj, je tudi stopnja zrelosti posameznikov v skupini. Mogoče sam boj ni tako sporen, kot pa njegov zaključek. Bolj pomemben se mi zdi zaključek - ali lahko končamo vedro, prijateljsko, inteligentno!

Ali ste imeli kdaj sodelavca, ki ni poslušal, ali če rečem, ni poslušal v dobri volji? Tak človek je "natural party braker".

Druga plat komunikacije pa je prevelika vljudnost - kar z vsem se strinjamo, samo da ne bi "škodili" sogovorniku. Zombi ekipa.

Jakarta Commons

Računalništvo in njena poddomena - programiranje - je, sedaj že lahko rečemo, zrela veda. Z leti se izoblikujejo določeni vzorci. Načrtovalski vzorci so rešitev nekega ponavljajočega problema pri razvoju programske opreme. Takega vzorca ne moremo direktno prenesti v kodo, lahko rečemo celo, da so agnostični na programski jezik. Dve knjigi, ki jih imam na spisku na temo objektno orientiranih vzorcev sta: Design Patterns Explained: A New Perspective on Object-Oriented Design in Head First Design Patterns.

Če problem še nadalje drobimo, pridemo do faze realizacije, ko moramo za določen podproblem napisati kodo. Ker si hočemo prihraniti čas, je najbolje, da si pogledamo, če je kdo pred nami že rešil naš problem in nam tudi dovoli uporabiti znanje, ki je običajno v obliki programskih knjižnic ali ogrodij. Najbolj znano "zatočišče" za programerje v jeziku Java je jakarta commons.

Cilj odprokodnega projekta jakarta commons je pod eno streho združiti Java komponente, ki so na voljo pod Apache 2.0 licenco. Namen je združitev znanja in preprečevanje redundantnega dela. Komponente so narejene tako, da so minimalno odvisne od drugih zaradi lažjega nameščanja. Sledi se tudi stabilnosti programskih vmesnikov (API), tako da so nadgradnje manj boleče.

Prej omenjene komponente so jar datoteke, ki jih samo damo na razpolago Java virtualnemu stroju, ki pa imajo priložene tudi izvorne datoteke, dokumentacijo in običajno Ant build skript. To pomeni, da lahko sami po potrebi kakšno funkcionalnost tudi dodamo, če jo potrebujemo. Kar je še bolje, v projekt lahko tudi prispevamo naše znanje in tako drugim olajšamo razvoj.

Po funkcionalnosti se med seboj zelo razlikujejo saj pokrivajo zelo široko problemsko področje. 32 komponent je produkcijske kvalitete in še nadaljnih 10 je v tako imenovanem peskovniku. Naj jih nekaj omenim samo na kratko - mogoče jih bom podrobneje predstavil vsako posebej v prihodnjih zapisih v tem blogu.

Collections Nadgradi funkcionalnost java.util.Collection.
Configuration Splošen dostop do konfiguracijskih virov.
DBCP DataBase Connection Pool
HttpClient Nadgradi java.net z veliko nove funkcionalnosti.
Lang Veliko uporabnih metod, nekakšna splošna razširitev jezika.

Gotovo se splača pregledati metode posameznega API-ja, saj nam uporaba že izdelanih rešitev skrajša število vrstic naše kode, vsi pa vemo, da to pomeni manjšo možnost napake in lažje vzdrževanje produkta. Še kako pomebno je, da bo nekomu za
nami, ki bo moral vzrževati kodo, znan uporabljen API, ki ga je mogoče že uporabljal na prejšnji firmi. V težavah se vedno lahko zatečemo na liste za razvojnike ali uporabnike, kjer nam uporabniki ali avtorji posamezne komponente odgovorijo na naše vprašanje. V veliki skupnosti zagotovo lažje rešimo problem.

Subversion

Subversion je odprtokodni sistem za upravljanje z revizijami dokumentov - največkrat izvorne kode. Je neke vrste naravni naslednik že precej osivelega CVS (Concurrent Versioning System) sistema, ki še vedno obvladuje večji del trga, a z vsakim mesecem izgublja boj proti bolj napredenemu bratu.

Razvoj programske opreme zahteva navadno skupino ljudi, ki bolj ali manj paralelno razvija nek produkt. Kako torej poteka razvojni cikel? Idealno je, da imamo zelo dobro definirano datotečno strukturo za posamezen tip projekta. O tem bom več govoril v enem izmed neslednjih člankov.

Začetno ogrodje za projekt uvozimo v repozitorij, do katerega imajo dostop vsi udeleženi. Vsak posameznik si na svoj delovni računalnik prenese projekt iz repozitorija in prične z dodajanjem novih datotek ali spreminjanjem že obstoječih. Kmalu se pojavi potreba po več razvojnih vejah. Eden izmed razlogov je razvoj nove verzije produkta. Ker ne želimo z novo verzijo pokvariti tekočega konja naše firme, ki ga nameravamo vzdrževati zaradi strank še kar nekaj časa, moramo pričeti z razvojem novejše verzije na tak način, da kljub skupni bazi ne pokvarimo stabilne kode. Drug razlog je razvojne narave. Nekdo v ekipi želi testirati nov algoritem in to lahko počne na svoji razvojni veji, ki se kasneje ali uporabi ali pa zavrže.

Konfliktne situacije, ki nastanejo zaradi sprememb v isti datoteki rešujemo najlaže s podporo kakšnega namenskega grafičnega primerjalnega orodja, ki je navadno kar del razvojnega okolja v katerem razvijamo. Z utečenostjo ekipe in dobrim projektnim vodenjem so te "težave" obvladljive.

V čem so prednosti sistema Subversion pred CVS?

• Atomarni vnosi v repozitorij - prekinjen vnos (commit) ne povzroči nekonsistentnega stanja.

• Preimenovane, kopirane ali odstranjene datoteke ohranijo informacijo o verziji.

• Nativna podpora za binarne datoteke in prostorsko učinkovit algoritem shranjevanja za binarno primerjavo.

• Imeniki imajo verzije. Celotna poddrevesa se lahko premikajo po repozitoriju in pri tem še vedno ohranijo informacijo o verziji.

• Čas za izdelavo vej in označevanje (tagging) je konstanten.

• Optimiziran dostop do repozitorija zmanjšuje mrežni promet.

S CVS sistemom sem prvič srečal leta 2001 in ga uporabljam za posamezne projekte še danes. Pred časom pa sem začel spoznavati zgoraj naštete prednosti na lastni koži. Kar se zgoraj bere kot suhoparna alineja, se v praksi izkaže kot neprecenljiva lastnost. Če izpostavim samo eno - pri CVS sistemu je še toliko bolj pomembna dobra začetna zasnova direktorijske strukture projekta, saj je prestavljanje imenikov ali vej prava muka, ki zahteva ročne posege v drobovje repozitorija.

S prakso, znanjem in dobrimi delovnimi navadami je uporaba sistema za kontrolo verzij pravi blagoslov. Priporočam uporabo tudi za solo projekte.

Agilni projekti - osmotska komunikacija

Razporeditev prostorov in delovnih mest lahko pomembno vpliva na potek projektov, ki se izvajajo v hiši. V večji meri zaposleni nimajo vpliva na razporeditev po svoji izbiri, zato je toliko bolj pomembno koliko se komunikacije med programerji, o tej "podvrsti" govorimo tu, zavedajo odgovorni. Neprimerni prostori že sami po sebi slabo vplivajo na storilnost, nedostopnost informacij pa zadevo še poslabša.

Izraz osmotska komunikacija izhaja iz biologije, a ga lahko prenesemo v bolj abstraktne koncepte. Pomeni tok informacij v ozadju, ki ga nezavedno filtrirajo člani skupine na ožjem delovnem območju. To običajno pomeni skupino ljudi v istem prostoru. Ob zastavljenem vprašanju se lahko posamezniki vključijo v diskusijo ali pa tudi ne, po lastni presoji. Največkrat osmotska komunikacija niti ne pomeni diskusije, ampak samo kratek stavek, ki bodisi odgovori na vprašanje ali pa popravi kaj že izrečenega, morda izrazi pomislek ali nestrinjanje. Z zdravo mero pameti tako dosežemo hitre in spontane odgovore na vprašanja, ki ne motijo delovnega procesa posameznika. Za posamezne faze projekta je lahko take vrste komunikacija povsem dovolj in lahko celo prepreči kakšen dolgočasen sestanek. Za majhne projekte je tovrstno komuniciranje lahko celo večinsko, običajni sestanki pa bolj redki. Že sama fizična oddaljenost običajno preprečuje zastavljanje vprašanj izkušenejšim na določenem področju. Sam zelo pogosto uporabljam poštne liste za razvojnike odprtokodnih projektov za iskanje odgovorov ali tehnik, to pa zahteva čas, predvsem takrat, če odgovora še ni na voljo na listi. V takem primeru moramo računati na dobro voljo nekoga z ustreznim znanjem, da nam odgovori na običajno zelo specifično vprašanje. Veliko pogostih vprašanj je na takih listah že odgovorjenih ali zbranih v FAQ datotekah za lažji dostop. Če sedimo v manjši skupini, po možnosti še z možnostjo hitrega pogleda na sosednji monitor z ustrezno informacijo, dobimo odgovore v rangu sekund, mogoče minut, kar je bistveno pri hitrem razvoju.

Najverjetneje se bo uveljavila tudi video konferenčna zveza med udeleženci, a bo to zahtevalo prilagajanje mediju in bo težko nademestilo osebni kontakt, papir in svinčnik. Obstajajo urejevalniki programske kode (in seveda besedil), ki dopuščajo hkratno urejanje istega modula, če na primer potrebujemo nasvet kako sprogramirati določen odsek kode. Tako ni potrebno združevanje prek sistemov za upravljanje z izvorno kodo (CVS, Subversion, SorceSafe, ...), če nam to ustreza. Vse je seveda odvisno od urejenosti delovnih procesov in nenazadnje tudi od navdušenosti posameznikov za napredne in ne vedno tudi koristne pripomočke.

Razporeditev pisarniškega pohištva v prvi meri vpliva na osebni prostor posameznika, neposredno s tem pa na odnose med sodelavci. V odvisnosti od narave dela so se izoblikovale tipične konfiguracije miz, predelnih sten in samih pisarniških sob. Vsakemu posamezniku seveda ustreza nekaj česar drugemu ne. Nekoga moti, da mu drugi lahko gledajo v monitor vsak trenutek, drugega (beri mene) moti, če nekdo konstantno trese mizo, spet tretjega ne moti, da mora vsakič vstati, če hoče pogledati sogovorca in tako naprej. Fino je, da obstaja prostor kamor lahko na trenutke "zaidemo", da prekinemo rutino ali da se umaknemo iz skupine. Najbolje je, da obstaja na firmi neformalna soba za sestanke. To je nekakšna večnamenska soba kjer poleg običajnih sestankov lahko naključno s kakšnim kolegom (ki ne kadi :-)) mimogrede izmenjamo kakšno idejo. Kajenje sem omenil z razlogom. Kot bivši kadilec lahko z gotovostjo rečem, da se je v vseh čik pavzah povedalo poleg nujnih govoric tudi precej, če ne večino, s službo povezanih zadev. Ne gre pa pretiravati s temi pavzami - slej ko prej postaneš aktualna tema udeležencev ne-čik pavz.

Slaba lastnost osmotske komunikacije je ta, da generira veliko šuma in da običajno predstavlja breme za vodilnega razvojnika, ki največkrat odgovarja na vprašanja. Veliko komunikacije pomeni za nekoga motenje svojega dela in tako postane manj storilen ali pa sploh ne dosega svojega potenciala. Vodilni razvojnik(i) običajno najdejo svojo rezino miru po običajnih delovnih urah ali čez vikend. Boljše, čeprav nenaravno, je doseči dogovor o tihi uri ali dveh. Nazadnje se vse konča pri posamezniku in njegovem značaju, o čemer pa bom pisal v nadaljevanju člankov o agilnih projektih.

Cayenne

Vsi vemo, da je zadan problem rešljiv na veliko načinov. Ena izmed možnih poti pri izdelavi dinamične spletne aplikacije je tudi uporaba ORM (Object Relational Mapping) ogrodij. To je programska tehnika, ki podatkovno bazo predstavi kot objektno strukturo.

Zakaj bi si sploh želeli imeti podateke zapisane v bazi v aplikaciji predstavljene kot graf objektov? Odgovor je zelo podoben tistemu, zaradi katerega je veliko programerjev opustilo proceduralne programerske tehnike in jezike ter osvojilo koncepte objektnega programiranja. Ljudje lažje razmišljamo o objektih, njihovih lastnostih in povezavami med njimi, kot pa o tabelah in vrsticah podatkovne baze (po lastnih izkušnjah velikokrat nenormaliziranih).

Uporaba relacijske baze za shranjevanje objektno orientiranih podatkov vodi v semantični prepad - programerji moramo(jo) programsko rešitev snovati tako, da mešajo dva pristopa. S podatki operiramo na objekten način, shranjujemo pa jih relacijsko. Združevanje tehnik na tak način pomeni zadajanje omejitev enega na drugega in obratno. Prihaja do tako imenovane impedančne nezdružljivosti. SQL podatkovne baze so sestavljene iz niza tabel, ki vsebujejo elementarne podatke. Posamezen zapis v taki bazi se običajno razteza čez več tabel, ki jih moramo za aplikativne potrebe pred tem združiti. S tem hočem povedati, da moramo pri pisanju poizvedbe navesti tudi relacije med njimi.

Uporaba SQL stavkov bo vedno hitrejša rešitev, ob predpostavki da je to v celotnem kontekstu problema najbolj kritičen člen. ORM rešitve podatke na veliko shranjujejo v medpomnilniku, kar je resnično velikega pomena za visoko zmogljiv sistem.

To je bilo nekaj malega v splošnem, zdaj pa še o Cayenne. Ogrodje se zgleduje po EOF (Enterprise Objects Framework), ki velja za enega izmed najboljših. Tabele in vrstice so v pomnilniku predstavljeni kot graf objektov. Nad tem grafom objektov izvajamo čisto običajne operacije kot bi delali z javanskimi zrni. Cayenne spremlja kaj počnemo s posameznimi objekti in relacijami med njimi in ko je čas za zapis v bazo, ogrodje samo izgradi optimizirane SQL stavke. Podatkovne baze različnih proizvajalcev lahko združimo v enoten podatkovni vir do katerega dostopamo prek enega vmesnika. To pomeni, da imamo lahko več dislociranih podatkovnih baz, ki v navezavi z naprednim (Cross-VM Cache Sharing) mehanizmom omogoča skalabilne aplikacije.

Običajno najprej popišemo problem, ki ga želimo aplikativno rešiti. V tem procesu spoznamo naravo podatkov in relacije med njimi. Entitetni model lahko prenesemo v Cayenne Modeler, ki je vizualno modelirno orodje. Z njim lahko tudi preberemo že obstoječo podatkovno shemo in iz nje tvorimo javanske razrede, lahko pa iz modela naredimo shemo - imamo skratka dvosmerno povezano operacijo. S tem orodjem se posredno izdelajo vse konfiguracijske datoteke, ki jih potrebuje naša (spletna) aplikacija. Cayenne je agnostičen na prezentacijski nivo. Java razredi se avtomatsko zgenerirajo "v paru", vedno se naredi še podrazred, v katerega mi dodajamo poslovno logiko. Na ta način lahko Cayenne Modeler ob spremembi (npr. dodan ali spremenjen atribut tabele) prepiše "očeta", ne pa tudi naše dodatne logike. Ne potrebujemo razmišljati, če tega eksplicitno ne želimo, o primarnih ključih, ker to ni v OO (Object Oriented) semantiki. Ker so vsi podatki o preslikavah v posebnih konfiguracijskih datotekah, ki jih izdela prej omenjeni Modeler, je v samih razredih lahko samo čista poslovna logika, kar je lep način ločitve odgovornosti.

Iz svojih izkušenj lahko povem, da je arhitektura aplikacije in koda veliko lepša, če si lahko privoščimo toliko svobode pri načrtovanju.

Eclipse

Eclipse kot razvojno okolje sem začel uporabljati pred slabimi dvemi leti. V tem času sem spoznal, da za tem imenom stoji več kot samo okolje za razvoj aplikacij.

Eclipse je skupnost - odprtokodna skupnost, v kateri se "kuhajo" raznolika orodja za izdelavo aplikacij. Deluje kot povezovalno ogrodje. Deluje na Windows, Linux, Mac OS X, Solaris, AIX, HP-UX in QNX sistemih.

Nastajati je začel novembra 2001 s povezovanjem velikih podjetij kot so Borland, IBM, Red Hat, SuSE, Rational Software. Trenutno je v konzorciju že več kot 100 podjetij, ki razvija v Eclipse skupnosti devet večjih in preko petdeset manjših odprtokodnih projektov. Če naštejem omenjenih devet:

The Eclipse Top-Level Project
razvojno okolje za orodja in aplikacije

The Eclipse Tools Project
skrbi za medsebojno povezovanje in združljivost orodij

The Eclipse Web Tools Platform Project
platforma za razvoj spletnih aplikacij

Test & Performace Tools Platform
platforma na kateri razvijalci razvijajo testna in performančna orodja

The Business Inteligence and Reporting Tools Project
orodja za poročanja iz aplikacij

The Eclipse Data Tools Platform Project
orodja za podatkovno orientirane tehnologije

Device Software Development Platform
orodja za razvoj aplikacij namenjenih za različne naprave

The Eclipse SOA Tools Platform Project
okolje in orodja za SOA (Service Oriented Architecture) aplikacije

The Eclipse Technology Project
inkubator za nove tehnologije

V bližnji prihodnosti (junij 2006) se nam obeta izid kar desetih Eclipse projektov pod skupnim imenom Callisto.

Pri delu uporabljam intenzivno samo prvega, to je Eclipse IDE z raznimi dodatki (plug-ins). Za razvoj Java frontend aplikacij uporabljam MyEclipse in Spindle, za backend in samostojne aplikacije v Java jeziku pa so nepogrešljivi XMLSpy, RMI compiler, Subversion, UML, Log4E, LogWatcher in pa zadnje čase tudi JProfiler in Maven. Urejevalnik izvorne kode za Java jezik ima odlično podporo za refaktoring, ki prihrani čas in živce pri razvoju programske opreme.

Dodatki za Eclipse se najdejo na Eclipse plugins in na Eclipse plugin central.

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.