Väledad metoodikad: head, vead ja inetused. Esimene osa

Mind on korduvalt sõimatud lolliks, kuna ma ei pea agiilseid programmeerimismetoodikaid Jeesuse teiseks tulekuks ja ei kummarda neid kui suurimat läbimurret tarkvaraarenduse ajaloos.

Võimalik, et ma siis olengi loll. See on rohkem teiste hinnata – aga ma saan vähemalt kirja panna, miks ma ei leia et väledad metoodikad on alati parim, ülim, ainus ja õige. Kirjutangi siis natuke juttu sellest, miks ma ei pea agiilseid metoodikaid igal ajal ja kohal parimaks lahenduseks.

Esimeses osas räägin ma agiilsetest metoodikatest, teises ekstreemprogrammeerimisest (extreme programming). Virisemist saab lugeda eelkõige teises osas.

 

Mis on agile development?

Agile development (ek kasutatakse nii agiilne arendus kui väledad metoodikad, kuid parem oleks paindlikud või kohanduvad metoodikad – tänan, L.) on kontsept, mille järgi toimub tarkvaraarendus kiirete pisitsüklitena. Iga tsükkel iseenesest on traditsioonilise tarkvaraarenduse pisikordus, so analüüs, arhitektuur, koodimine, testimine, veaparandus, dokumenteerimine. Iga tsükli lõpus peaks klient saama uue töötava versiooni tarkvarast, millele on lisandunud funktsionaalsust või on sisse viidud kliendi soovidele vastavad muudatused. Iga iteratsiooni lõpus hinnatakse ümber eesmärgid.

Sellise mudeli eeliseks peetakse eelkõige paindlikkust. Kuna klient saab esmased versioonid juba päris tarkvara valmimise algusfaasis, siis saab ta oma soovide ja nõutud muudatuste kohta anda tagasisidet juba varakult, samuti saab klient parema ülevaate töö seisust ja lõpuks tema nõuetele paremini vastava tarkvara. See kõik peaks tõstma kliendi rahulolu (customer satisfaction).

Arendaja poolt on aga soodne see, et kuna feedback saabub jooksvalt ning juba arenduse algfaasist peale, siis on vajalike muudatuste tegemine lihtsam ja odavam. Kokkuvõttes peaks tarkvara valmimine olema kiirem ja odavam.

Agile development idee sai alguse üheksakümnendate keskel, suuresti vastusena aeglasele ja põhjalikule waterfall-mudelile (või formal methods, kui soovite). See oli aeg, kus hakkas ilmnema järjest suurem soov klientide jaoks kirjutatud spetsiaalvara järgi ning samal ajal hakkas oluliselt langema nii tarkvaraarenduse kui ka riistvara hind – esimene tänu uutele kiiretele ja lihtsamatele arendusvahenditele (Delphi, Visual Basic, paremad C++ arendusvahendid, hiljem ka Java jne), teine tänu PC muutumisele tarbekaubaks. Muutunud aeg vajas ka muutunud metoodikat.

Omaette verstapost oli Agile Manifesto, mille pani kokku grupp väledate metoodikate gurusid 2001. aastal. Selle manifesti põhimõtted on järgmised (copy-paste Wikipediast):

• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (Co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

Reaalses töös tähendavad agiilsed metoodikad suuremat automatiseeritud testimise kasutamist (eriti unit tests), vähem dokumenteerimist, pidevat ja aktiivset suhtlust arendusmeeskonna ja kliendi vahel.

Eestis on väledate metoodikate kasutamine… omapärane. Tundub, et enamik firmasid ei ole reaalselt omale teadvustanud, mis metoodikat nad kasutavad ega tegelikult selle peale mõelnud. Seetõttu on tulemus kummaline segu waterfall mudelist ja väledatest metoodikatest: alustatakse waterfall-mudeli järgi põhjaliku analüüsi ja arhitektuuriga, kuid koodimise lõppjärgus hakatakse järjest rohkem tegema pisiväljalaskeid ja kiireid muudatusi. Klienti kasutatakse tasuta testijana. Ilmselt on selline kahe mudeli mittetäielik segamine üsnagi ebaefektiivne.

Siiski on ka firmasid, kus rakendatakse täielikku agiilsete metoodikate komplekti. Mõned neist on välisfirmade Eesti filiaalid kus emafirma on metoodika ette kirjutanud, mõned aga innovatiivsed pisifirmad, kus programmeerimisteooria-geek on sõnaõiguse saanud. Suurtes firmades rakendatakse agiilseid metoodikaid kuuldavasti kohati, sageli projektipõhiselt.

 

Vead ja inetused

Kui keegi heidab väledad metoodikad täielikult kõrvale, siis pole tema kohta tõesti muud öelda kui “loll”. Agiilne arendusmetoodika on kasulik ja vajalik – aga mitte alati ja kõikjal.

Agiilse metoodika gurud Barry Boehm ja Richard Turner toovad välja järgmised kohad, kus agiilne arendus on parem:

• Low criticality
• Senior developers
• Requirements change very often
• Small number of developers
• Culture that thrives on chaos

Ning samuti, kus traditsiooniline, planeerimispõhine mudel on tugevam:

• High criticality
• Junior developers
• Requirements don’t change too often
• Large number of developers
• Culture that demands order

(tsiteeritud Wikipedia järgi, kuna mul omal veel nende raamatut ei ole).

Ehk teisisõnu – agiilne arendus on kohane madala kriitilisusega (pisi-)projektidele, kus nõuded muutuvad sagedasti ja arendajate arv on väike; lisaks veel on arendajad kogenud. Traditsiooniline mudel on aga parem stabiilsetele, kriitilistele projektidele, kus arendajaid on palju ja nende kogemused ei ole liiga suured.

Arvake nüüd ära, kui kogenud on Eestis enamik arendajaid? Üldse mitte kedagi maha tehes – me kõik oleme kunagi algajad olnud ja loodetavasti saavad meist kõigist ka senior developer’id. Paratamatu on aga see, et enamus arendajatest on suhteliselt väikese kogemusega (eriti hull on asi siis, kui enesearendusest ka ei huvituta). Ning üritada ühe-kaheaastase kogemusega, pahatihti veel ülikoolis käiva inimesega teha kriitilist projekti agiilse metoodika alusel… kas keegi leiab, et see on suurepärane ja ainuvõimalik idee?

Rääkimata veel sellest, et agiilne metoodika elab väga professionaalsete analüütikute ja arhitektide peal. Iga arhitektuuri ajal tehtud viga maksab ennast nagunii ülivalusalt kätte – ning väledate metoodikate puhul kipub sellise vea hind olema veelgi suurem.

Eestis on aga korralikest arhitektidest ja analüütikutest puudus veel palju suurem, kui arendajatest. Enamik arhitekte-analüütikuid on arendajad, kes on olnud sunnitud töö kõrval arhitektuuri ja analüüsi tegema. Mis tegelikult on hea ja õige, nii vähemalt arhitektid peavadki tekkima. Kurvem on aga see, et arendajana on neil pahatihti kogemusi vähevõitu – ja arhitektuuri detaile ainult raamatust ei õpi. Eeldusel, et nad iial on võtnud tarkvara arhitektuuri käsitleva raamatu kätte – enamik Eesti IT-ala inimesi suhtub oma eriala raamatutesse sügava põlgusega. See tegelikult on mingil määral arusaadav – Sturgeoni seadus kehtib ka siin: 90% kõigest on pask. Probleem on aga selles, kuidas neid häid 10% raamatuid leida…

Boehmi ja Turneri nimekirja viimane punkt on, et agiilne metoodika sobib (töö-)kultuurile, mis kaost ei karda. Siin ma vaidleksin neile vastu – agiilne metoodika eeldab just suuremat enesedistsipliini ja korda, muidu on tulemuseks cowboy coding. “Release early, release often” ei tähenda veel, et tegemist oleks agiilse metoodikaga, see võib samahästi tähendada kaost.

Eriti kehtib see muidugi ekstreemprogrammeerimise puhul, tulen teises postituses selle teema juurde tagasi.

Tuttava käest kuuldud näide – ta töötab ühes Eesti edumeelseimas IT-firmas, kus laialdaselt agiilseid metoodikaid kasutatakse. Kui aga projekti valmimine kippus venima, siis tuli projektijuht tema juurde, “Kuule, äkki saaks siiski nii, et kõiki reegleid nii rangelt ei jälgiks? Pole vaja nii tingimata neid stiilireegleid ja muutujate nimetamist koguaeg järgida, küll hiljem teeme korda.” Ja nii jõutaksegi kauboikoodini…

Üks vähemainitud väledate metoodikate miinuseid on seotud kliendi või klientide rahuloluga. Kui kasutaja avastab korra päevas, et tema sisestatud andmetega vorm saab submitil serveri käest näkku teatega “Lae alla rakenduse uus versioon!!!” või “Värskenda leht ja proovi uuesti”, siis arvake kui paljudele kasutajatele see meeldib? Lisaks veel kipub dokumentatsioon sageli out-of-sync olema, nupp mis enne oli vasakul on nüüd paremal ja rakendusel on teine ikoon desktopil. IT-firma jaoks on aga kasutaja rahulolu firma headuse kõige olulisem näitaja.

Teine kliendipoolne probleem võib sageli olla, et nende töötaja või töötajad on pidevalt seotud programmi arendamise ja parandamisega, selle asemel et IT-juht ja projektijuht loevad analüüsi ja arhitektuuri läbi, annavad go ja seejärel saavad korra nädalas vahearuandeid kuni töö valmib. Iga firma ei ole valmis võtmetöötajat siduma teadmatuks ajaks muu tööga.

Ning viimane (ja sageli kõige olulisem) probleem: sa ei saa müüa agiilset metoodikat. Kas kliendile annab agiilne arendus täiendavat kasu või on see hoopiski arendusfirma mugavuse jaoks? Kas tal on vajadust saada aruandeid juurde nimekirja üks päevas või on tal neid vaja alles majandusaasta lõpus, Maksuametile saatmiseks? Ehk – agiilne metoodika iseenesest ei ole lisaväärtus.

Teine kirjutise osa valmib loodetavasti nädala jooksul.