…meie igapäevast IT’d anna meile igapäev…

2008-06-10

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

Filed under: Infotehnoloogia — Sander @ 12:03:00

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.

KiritiguSellise 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.

HareOmaette 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.

9 kommentaari »

  1. Kommentaariks (suht seosetu jutt, ma tean):

    http://mdworm.wordpress.com/2008/06/10/juhtimine-ja-kaos/

    kommentaar kirjutas mdworm — 2008-06-10 @ 13:32:41 | Vasta

  2. Jah, mul õnnestus juhtimine osavalt ära unustada siin jutus. Juhtimise ja agiilsete metoodikate kohta on ka riiulitäite kaupa kirjandust, kuid sellest ma eriti palju ei tea.

    kommentaar kirjutas dukelupus — 2008-06-10 @ 14:46:51 | Vasta

  3. Raamatute leidmisega on see “mure”, et see on eraldi tegevus, millele kulub aega. Niisama hunnikut suvalist kirjandust kokku kuhjata pole aga mõtet. Kui vaadata näiteks C# alal ilmunud raamatuid, siis üle 90% neist on referaadid, mis on keele spetsifikatsiooni põhjal koostatud. Parem loe läbi keele spets ja ära raiska aega tuhandete lehekülgede kirjanduse peale, mis seda kopeerivad. Paljud firmad ostavad igasuguseid käsiraamatu stiilis asju, selle asemel et sama inf Google’ist kätte saada, kui tarvis läheb. Mõni ime, et inimesed ei kipu lugema, kui raamatud kordavad üle seda, mille otsimootori kaudu kiiresti kätte saab.

    Heade raamatute leidmine on ainult pool lugemise temaatikast. Teine pool on inimesed, nende harjumused ja nõudmised. Mõned pole peale keskkooli kordagi raamatut kätte võtnud, teiste jaoks on inglise keel liiga keeruline, kolmandad pole nõus vabast ajast lugema, neljandad korra vaatasid jah ja viiendatel hakkas kõrvast verd tilkuma. Siia otsa võib mõelda veel oma sadakond põhjust miks mitte raamatuid lugeda. :)

    Lugemine on kasulik tegevus, kui on head raamatud, sest need õpetavad mõtlema uutes suundades ning annavad muuhulgas palju häid ideid. Samuti õpib probleemidele lähenema teisiti kui tavaliselt. Mina loen raamatuid pea igapäevaselt. Viikenditel muidugi vähem. Oleneb kas ja kus viibin. Aga siiski püüan lugeda nii palju kui võimalik.

    Muideks – head raamatud panevad mõtlema ja pakuvad seega tegevust. Ja raiskavad ära hulga kasulikku aega, mille saaks muidu kulutada blogisse kirjutamiseks. Aamen!

    kommentaar kirjutas Gunnar — 2008-06-10 @ 17:08:27 | Vasta

  4. Suures osas nõustun Sinu poolt kirjapanduga. Samas – agiilne ja waterfall arendus on tõepoolest nagu sea ja käo võrdlemine. Üks hästi paidlik ja teine tardunud arendus…

    Minul isiklikult on XP-ga väga hea kogemus. Projekt oli mahukas 1,5a. kestev, arendustiim keskmie (kasutajaliidese testimised mehitas tellijapool) jne. Arhitekt oli Sinu kirjeldust silmas pidades ju siis “väga hea”:) Miks kiidan – eelkõige seetõttu, et oli tihe side arendaja ja lõppkasutaja vahel. Tarkvara juurutamine oli hõlbus, kuigi… kasutajate jaoks muutus süsteem kardinaalselt.

    Fakt on, et ideaalset metoodikat tarkvaraarenduseks pole. Seetõttu peab arendaja suutma olema hea vaistuga ja suutma kohaneda vastavalt projektile ja tellijale.
    Tuimalt waterfall`i või RUP-i evides Eesti turul jätkusuutlik raske olla. Lõputult ei saa ju väidet – “pole skoop” – kultiveerida;-)

    kommentaar kirjutas Metsapiiga — 2008-06-10 @ 18:33:19 | Vasta

  5. 90% kehvade raamatute kohta – hiljaaegu kohustati lugema raamatut, mida nimetati tarkvara integratsiooni piibliks. Lugesingi ligi poole läbi – ja siis hakkasin põtkima: see raamat ei ole mitte integratsiooni põhimõtetest, vaid integratsiooni juures kasutatava UML’i detailne kirjeldus. Leidsin, et ei näe selle raamatu lõpuni lugemisel erilist mõtet.

    Soovitajateks olid seejuures projekti juhtimisega tegelevad inimesed, kes olid kuulnud “kui oluline see raamat on”, raamatul endal ka “Signature series” ja paljude inimeste soovitused kaanel kirjas.

    Ise olen lugenud/püüdnud lugeda teiste programmeerijate poolt soovitatavaid raamatuid. Näiteks “Code Complete 2” sai loetud just Gunnari soovitusel. Kahjuks on viimase kuu jooksul olnud nii kiire, et pole saanud erialaseid raamatuid kättegi võtta – tahaks loota, et saan varsti lõpuks “Peopleware” lugemisega peale hakata (siiani olen jõudnud sissejuhatuse ära lugeda…)

    kommentaar kirjutas dukelupus — 2008-06-10 @ 19:57:29 | Vasta

  6. Mis selle integratsioonipiibli pealkiri on?

    kommentaar kirjutas Gunnar — 2008-06-10 @ 22:09:29 | Vasta

  7. “Enterprise Integration Patterns” – http://www.enterpriseintegrationpatterns.com/ Pigem reference, aga mitte piibel.

    kommentaar kirjutas dukelupus — 2008-06-10 @ 22:54:09 | Vasta

  8. Integratsiooni teostega on tihti nii, et nende sisule saab kõige paremini pihta siis, kui endal mõned vaevalisemad projektid antud vallas selja taga. Mainitud teost ma ei ole ise lugenud, kuid plaanin sellega kindlasti tutvuda. Äkki leiab sealtki midagi olulist, mida järgmistes projektides rakendada.

    Kui mänekad käivad mingi kirjandusega peale, mida nad arvavad, et võiks hea olla, siis tasub kindlasti uurida, et kas antud kodanik on ka ise selle teose läbi lugenud. Kui on, siis võiks uurida, et mida ta sealt konkreetselt kasulikku teada sai ja juurde õppis. Kui vastuseks on kogelemine ja niisama sooja hingeauru välja ajamine, tasub kindlasti omal käel uurida ja teosega tutvust teha – nii saab kõige parema pildi.

    Mõni raamat, mis ühele inimese palju juurde annab, ei pruugi teisele midagi õpetada. Ja palju mängib siin rolli ka see, et millises kontekstis raamatu kallale asuti. Juhtus see vabatahtlikult ja omast huvist või tuli kuskilt kõrgemalt kellegi kaikuv sõnum ja nii sai raamat juba ettemääratult mahakandmisele kuuluvana avatud. Min soovitan igasugustesse teostesse suhtuda võimalikult neutraalselt kuni teos ise pole põhjendanud, kas ta on lugemist väärt või ei.

    kommentaar kirjutas Gunnar — 2008-06-11 @ 14:27:56 | Vasta

  9. […] vead ja inetused. Teine osa Filed under: Infotehnoloogia — dukelupus @ 09:46:00 Kui eelmisel korral kirjutasin väledatest metoodikatest üldiselt, siis seekord üritan kirjutada agile development’i kõige rohkem tuntud ja promotud metoodikast: […]

    Pingback-viide kirjutas Ekstreemprogrammeerimine: head, vead ja inetused. Teine osa « …meie igapäevast IT’d anna meile igapäev… — 2008-06-20 @ 09:46:16 | Vasta


RSS feed for comments on this post. TrackBack URI

Lisa kommentaar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Muuda )

Twitter picture

You are commenting using your Twitter account. Log Out / Muuda )

Facebook photo

You are commenting using your Facebook account. Log Out / Muuda )

Google+ photo

You are commenting using your Google+ account. Log Out / Muuda )

Connecting to %s

Create a free website or blog at WordPress.com.