Scrum on religioon

Minu esimene kokkupuude Scrumiga oli aastal 2006 JAOO konverentsil Århusis, kus Jeff Sutherland rääkis Scrumi skaleerimisest või tuunimisest või millestki sellisest. Ei olnud ma varem Scrumist kuulnud ja suurem osa sellest jutust läks minust just seetõttu mööda. Igatahes ei jäänud veenvat muljet lektori Kümme-korda-kuulsam stiilis gospeljutlusest. Üldiselt meenutas veidi ka seda ketikirjade stiili, et saadad aga kirja edasi ja praktiliselt kohe tabab sind sajandi lotovõit. Nojah.

Aga edasi sai juba teemat natuke oma käe peal uuritud, mitmel-setmel koolitusel ka käidud ja inimesed saavadki ju vananedes üldteada faktina targemaks :P

Scrum on elustiil

Käinuna mitmesugustel koolitustel olen märganud, et neil kuuleb suht sageli mõne eluks vajaliku iva. Mõnikord rohkem, teinekord vähem, vahest harva on ka täiesti sisutühju koolitusi ette tulnud. Alati on jäänud tunne, et sai ju midagi, aga aega kulus roppu moodi ja kas see kasulik osa ikka oli seda aega ja raha väärt? Võib-olla oli. Aga Scrum on siiani esimene ja ainus, mis pani mu silma põlema ja see põleb siiani. See on õpetus, kus kõik on lihtsalt algusest lõpuni nii õige, et sa ei pea sellest arusaamiseks üldse kaua juurdlema, see on sulle juba intuitiivselt selge.

Niisiis kuuleb suva koolitustel kümneid nippe, juhiseid ja reegleid, kuidas mingisuguseid asju hästi ajada. Mitmete koolituste peale kokku sadu erinevaid. Kasulikke, ent meeldejätmiseks ja tulemusrikkaks kasutamiseks kokku võetuna liiga palju, liiga keerulisi või omavahel sidumatuid. Ja üsna sageli on kiusatus hüüatada vahele, et see on ju Scum. Et selgemalt, arusaadavamalt ja paljusid neid reegleid kokkuvõtvalt on ju Scumis selline lihtne asi olemas. Ja vahet ei olegi, kas räägiti tarkvaraarendusest, või stressi maandamisest või hoopis multikultuursest töökeskkonnast.

Scrum on psühholoogia

Selle paralleeli avastasingi just hiljuti, kui meil toimus ajajuhtimise seminaride sari, kus räägiti muuhulgas ka stressist, energia ammutamisest, õnnelik olemisest ja üldse väga igasugustest asjadest :-) Scrumi sagedased reliisid rahuldavad inimese vajadust saavutuste järele. Kõik tiimiliikmed saavad ühe kuni nelja nädala tagant (mis on ühe sprindi pikkus Scrumis) korraliku süsti eneseusku. Saavad kinnitust sellele, et nad teevad õiget asja ja teevad seda edukalt.

„Inforadiaator“ on samuti suurepärane leiutis päris mitme külje pealt. Esiteks kasvatab see tiimi ühtekuuluvustunnet läbi ühise alati silme ees oleva eesmärgi. Kõik on kõigile nähtav, feilimine samamoodi nagu edu. Nähes igati kogenud ja tublide kaaslaste feilimist väheneb või kaob ka teiste hirm ebaõnnestumise ees. Usaldus, avatus, probleemi hingelt ära saamine ja jagamine oma meeskonnaga… see kõlab juba täitsa kristliku jutluse moodi :-)
Teine inforadiaatori vahva omadus on pidev asjade ärategemise rõõm. Ja see on täpselt samuti avalik, kõigi ees saadav igapäevane tunnustus ja rahulolu. Kas meenub, kui hea tunne on teha oma todo-listi linnuke lõpetatud taski taha? Just, see see ongi.

Scrum on lihtne

Scrum on kõige lihtsam tarkvaraarendusprotsess, mida ma siiani kohanud olen. Ta on maksimaalselt õhuke, defineerides vaid käputäie tõeliselt olulisi reegleid. Kuigi samas, äsja lõpetanud 4 tunnise Scrumiloengu pidamise jäi mul selline tunne, et hulgi igasugu nüansse on ikka rääkimata… ja neist ilmselt jääkski rääkima (vihje religioonile, elustiilile, psühholoogiale ja millest iganes ma siin veel targutanud ei ole :P)

Scrumi ülivahva omadus on veel see, et tegelikult sa ei peagi tegema Scrumi, et teha Scrumi. Bah… Ma proovin uuesti. Scrumi võlu on selles, et sa võid rakendada sellest just täpselt nii palju, kui sul parajasti vaja on. Või võimalik on. Või kui palju sa julged. Või oskad. Võta näiteks esiteks kasutusele ainult igapäevased stand-up miitingud, ja juba sa näed kuidas su elu läheb järjest ilusamaks. (Need miitingud olid just see, millest mina alustasin). Või alusta lühikeste sprintidega. Või inforadiaatoriga. Vahet pole. See on üks oluline erinevus teistest metodoloogiatest. Sa ei saa näiteks teha edukalt edasi oma waterfalli, kui sul ei ole staatusmiitinguid. Või gantti charti. Olen kuulnud sellist väidet ka agiilse eXtreme Programmingu kohta, et kui sa ei tee seda perfektselt, siis sa feilid kogu oma protsessiga. Uups sorry, aga keegi meist ei ole täiuslik.

Scrum on efektiivne

Efektiivne olemiseks on tegelikult väga lihtne reegel – tee ainult neid asju, mida on vaja. Vastandina protsessile, kus sa teed neid asju, mida nõuete spetsifikatsioon ette kirjutab. Esmapilgul vastuoluline väide. Siiski, on üldteada rusikareegel, et 20% implementeeritud funktsioonidest annavad 80% toote ärilisest väärtusest (business value). Marketingiinimesed on juba harjunud, et neilt küsitakse projekti alguses nõuded ja selle põhjal öeldakse neile siduv arenduse maksumus. Seega kirjutavad nad oma spekki sisse kõikvõimalikud võib-olla-vajalikud featuurid. Igaks juhuks. Ja enamasti on see lihtsalt hunnik pahna ja soovmõtlemist. Kui nad ainult teaksid, et näiteks see auto-complete läheb neile maksma 150 000 raha, siis loobuvad nad sellest nõudest ülikiiresti. Märksõna, mis siin säästab meeletu hulga raha, on prioritiseerimine. Valides sprintidesse ainult kõige olulisemaid asju ja ümberprioritiseerides iga sprindi alguses saab see oluline osa tootest valmis võib-olla veerandiga kogu projektile planeeritud mahust. Vabalt võib peale seda ilmneda, et ülejäänud featuure ei olegi mõtet implementeerida ja projekti saab juba lõpetada.

Teine tore asjaolu Scrumiga seoses on see, et sa oled fokusseeritud konkreetse sprindi eesmärgile. Alistair Cockburni mõtet kasutades – ei ole vaja raisata aega ehitades igaks juhuks neid sildu, mida sul võib-olla hiljem vaja ei lähegi. Neid, mida sa oled implementinud tulevase laiendavuse, taaskasutatavuse või mille iganes jaoks. Nõuded ja olukorrad muutuvad elus pea igapäevaselt. Enamasti avastad sa lõppeks, et su ülicooli XFactory’t ei läinudki mitte kuskil vaja. Mõnikord muidugi läks ka.

Scrum töötab

Scrum ei ole silver-bullet. Või siis on. Sest Scrumi ei ole võimalik mittetöötamises paljastada :-). Sellepärast, et ta on nii adaptiilne. Scrum ei olegi oma olemuses täpselt defineeritud metodoloogia. Öeldakse, et Scrum on framework, mille peale sa võid arendada just sellise protsessi, nagu täpselt sinule vaja on. Unikaalse. Parima antud reaalse olukorra jaoks. Scrum kohandub sinu vajadustega. Ja mis siis sellest, kui keegi räägib, et sa ju ei tee ikka seda Õiget Scrumi. Scrum adapteerub. Ise. Teeb, mida on vaja sinul.

Päris kindlasti tekib sul Scrumi esimest korda rakendades probleeme. Võib-olla nii tõsiseid, et sa otsustad Scrumist loobuda ja jätkata oma vana läbiproovitud protsessiga. Oluline oleks aru saada, et nende probleemide põhjus ei ole Scrum. „Scrum is not creating problems, but exposing them“. Scrumi lihtsus ja läbipaistvus võimendab neid juba varem olemas olnud probleeme, mis seni peitsid ennast heavyweight protsessi, hajunud vastutuse ja mille iganes taha. Scrumiga avaneb sul võimalus (või lausa hädavajadus) lahendada see Karvane Probleem, mille eest oli siiamaani võimalik pea peita liiva alla. Ja kui sa oled selle Karvasega ühel pool, siis sa näed, et Scrum töötab tõesti.

Scrumiga on veel ka see tore asi, et teda saab märkamatult peita ka suure heavyweight protsessi sisse, kui too on sulle peale surutud, olgu siis kliendi, juhtkonna või kasvõi ISO sertifikaadi poolt. Nad ei peagi saama teada, et sa teed Scumi.

Proekspert teeb Scrumi

Loodetavasti oli see heietus huvitav neile, kel on juba varem olemas ettekujutus, mis elukas see Scrum on. Scrumi protsessikirjeldus ise sellesse artiklisse paraku ei mahtunud. Ehk järgmise postitusega võtame Scrumi üksipulgi juppideks lammutamise ka ette. Igatahes, meie Proeksperdis oleme leidnud, et Scrum vastab üpris hästi meil juba aastate jooksul iseenesest välja kujunenud protsessile. Nüüd me siis teame ka, mis nimega oma protsessi kutsuda ja kuhu poole seda edasi arendada. Ja koolitume hoolega. Minul endal on õnnestunud on kuulata selliseid tuntud agiliste, nagu Boris Gloger, Tobias Mayer, juba mainitud Jeff Sutherland ja Alistair Cockburn ning ka teisi, veidi vähemtuntuid. 2007-ndal aastal õnnestus Alistair tuua Eestisse loengut pidama ja ehk soodsate asjaolude korral ei jää ta meile viimaseks maaletoodud agiilseks guruks :P

11 thoughts on “Scrum on religioon”

  1. Hea kirjutis, tasub järgimist. Oleme Exactis samuti Scrumi juurutanud, kliendid ja team on väga rahul. Ei taha mõeldagi kui palju aega see säästis võrreldes nende Sharepointi ja MS Project Serveritega mida me protsesside juhtimiseks plaanisime. Seinatahvel on parim info liigutamiseks:)

  2. “… et see on ju Scum.”

    freudian slip :)

    Aga vahvalt energiast õhkav kirjatükk, meenutab küll religiooni müümist, miks ta ei meenuta.

  3. “… ei ole vaja raisata aega ehitades igaks juhuks neid sildu, mida sul võib-olla hiljem vaja ei lähegi. Neid, mida sa oled implementinud tulevase laiendavuse, taaskasutatavuse või mille iganes jaoks.”

    Testitavus. Khm. Loetavus. Mind hirmutab see jutt, esiteks ma ei taha tulla arendama spagetiprojekti, see on tõsiselt valus. Ma ei tahaks fiksida bugisi spagetiprojektis. Ja ma loodan, et ma ei pea kunagi seda projekti mõne aja pärast edasi arendama. Spagett on alati selge kuni sa seda arendad… Ma just siin kiitsin Mareku kirjutatud projekti loetavust ja laiendatavust. Lausa rõõm oli sinna uuendusi teha.

    See tundub juba väga religiooniteema, et kõik mida me tegime eelmises religioonis on nüüd patune. Vajadus hea disaini järgi selgus aastakümnete pikkuste feilimiste tõttu, nüüd oleme pisut hea elu peal olnud ja hakkame jälle lammutama. Kõlab nagu heal elul rootsi noorte mäss globaliseerimise vastu.

    Ja ausalt öeldes, see kogu jutt nõuete kohta on küll asi mida ma kordagi pole kohanud. Ütleks, et lausa vastupidi on. Algul on nõudeid vähe, need pole läbi mõeldud. Esimeste reliiside puhul eeldatakse, et ülejäänud probleemid lahenevad tähtajaks iseenesest ning neid ei mainita. Enne tähtaega aga süvenetakse lõpuks nõuetesse ja tulemusse ning avastatakse, et projekti alguses ei mõeldud asju läbi. Sealt edasi tuleb Panic Oriented Development, millest võib pikalt kirjutada.

    Samuti äriline prioritiseerimine ei lange tihtilugu kokku rakenduse ehitamise prioriteetidega ja struktuuriga. Näiteks on hiljutine kogemus kui raske oli “madalaprioriteedise” tõlgitavuse lisamine praktiliselt valmis rakendusse. Nii võibki juhtuda, et õigel etapil tehtud autocomplete maksab 1000eek ja valel etapil 150keek.

    Samuti on ilmselt äriliselt madalal asjad: logimine/traceimine, konfigureerimine. Ok, need on nö common sense asjad millega ilmselt keegi scrummitama ei hakkaks, aga illustreerivad tähtsat pointi – rakendustel on struktuur ja sellest peaks kinni pidama. Mitte keegi ei palu ju maja ehitusel seda odavat ja “äriliselt” vähetähtsat vundamenti teha siis kui siseviimistlus käib. Ja seda peab vältima ka softiarenduses.

    Skeptiline olen. Miks? Sest ma ei näe, et Scrum oleks lahendanud ühegi ebaõnnestunud projekti, millega olen kokkupuutunud, probleeme.

    Mu point on, et osad asjad mulle Scrumi puhul meeldivad, ja need teevad asju paremaks/selgemaks, aga imho projektid feilivad samas olukorras samamoodi. Hullemaks ei lähe, paremaks läheb, aga mitte korda. Ei ole tõesti silver bullet. Ei maksa lootagi.

    Ma ei tahtnud väga kriitiline olla, pigem pragmaatiline. Aga vist kukkus välja nagu alati :)

  4. Ma üritan siis neile kahtlustele jõudumööda vastata.

    1) Testitavus, loetavus, spagettkood
    Need on probleemid, mis on olemas igal pool, Scrumiga või Scrumita. Spagetikirjutaja vastu waterfall ei aita, ma pigem arvaks vastupidi. Tööle on ikka vaja võtta häid inimesi. Aga pmst, kui sellised mured projektis ilmnevad, siis lahendused neile on ju olemas – Pair Programming, Test Driven Development ja koodireviewd.

    2) Disain
    Üldine arhitektuur peab olemas olema, selle vastu ei aita miski. Olgu ta siis kasvõi üksainus komponentdiagramm, kritseldus whiteboardile või suulised kokkulepped tiimis. Sellise lihtsa struktuuri annab kokku leppida ühe koosolekuga. Kui kokkulepe kipub hiljem reaalsele olukorrale jalgu jääma, siis saab tiim selle igal ajal üle vaadata ja teha oma parandused arhitektuuri.

    Aga detailse disaini kirjutamisele olen ma enamasti kõigi kahe jalaga vastu (väljaarvatud erijuhud, nagu näiteks Boeing 737). See disain võtab väga palju aega (ja seda tehakse projekti alguses kus hulk nõudeid võivad olla veel ebaselged). Selle up-to-date hoidmine osutub projekti edenedes üsna pea üle jõu käivaks ülesandeks. Ja lõppeks detailne disain ei taga, et seda ka reaalselt järgitakse või spagetti ei kirjutata.

    Sellessamas projektis, mida sa kiitsid (tänks :P), oligi ainult 1 diagramm ja iga komponendi kohta umbes kaks lauset selgitavat juttu. Ja kõik. Ning sedagi ei tehtud projekti alguses, vaid sellel hetkel, kui tekkis tunne, et seda on vaja.

    3) Ebaselged nõuded ja paanika
    Jep, nõuded on projekti alguses sageli segased ja puudulikud, palju nõudeid tuleb hiljem juurde jne. Sellistele nõuetele on keeruline teha upfront disaini, anda siduvat hinnapakkumist või schedulet. Siin aitab Scrum ;) sellega, et me ei tee disaini ega ürita lõpuni läbi näha kogu projekti funktsionaalsust.

    See, et probleemid tulevad välja esimeste reliisidega, on väga hea asi. Ainult et reliise tuleb teha mitte vähem, kui kord kuus. Võrdle olukorraga, kus sa avastad probleemid projekti lõpus… sellisel juhul feilib kogu projekt.

    4) Äriline prioritiseerimine
    Õige jutt, et logimine ega konfimine ei saa marketingidelt kõrgeid prioriteete. Scrum lahendab seda olukorda kasutades kahte eraldi backlogi. Esiteks on olemas Product Backlog, mida manageerib äripoole esindaja (Product Owner, ehk PO). PO määrab backlogi itemitele ärilised prioriteedid ja tiim hindab nende itemite suhtelist suurust üksteise vastu.

    Aga iga sprindi alguses loob tiim endale eraldi sprindi backlogi, vastavalt olemasolevatele ärilistele prioriteetidele ja lisaks ka lähtudes oma kogemustest, ettenägelikkusest ja itemite omavahelistest sõltuvustest. Kui tiim näeb, et selle login-akna implementimiseks on enne vaja ära teha trace, siis võtavad nad selle ka oma sprinti sisse hoolimata madalast ärilisest prioriteedist. Seda sprindi backlogi manageerib scrumi tiim ise.

    5) Ei, sa ei olnud liiga kriitiline :) Igas projektis on omad vastikud probleemid. Scrum üritab need probleemid tuua kapist välja võimalikult varajases staadiumis, sest siis saab neid lahendama hakata varem ja nende impact projektile tervikuna on väiksem.

  5. Mõtlesin siin natuke Panic Oriented Developmendi peale. Jaan, sa võiksid sellest tõesti natuke kirjutada. Aga minu mõtted said sellised:

    _Kõige_tähtsam_asi_üldse_ on see, et tiim saaks rahus progeda. Whatever probleemid kuskil ka ei eksisteeriks, projektijuhi (või siis ScrumMasteri) ülesanne on seista oma tiimi ees nagu firewall. Tema peab tagama, et tiimis ei teki paanikat. Kui projektijuht ise on paanikas, siis on muidugi kõik kadunud.

    Scrum töötab sellise paanika vastu lihtsal viisil. Üle mitmete sprintide on tiimi velocity (story points per sprint) üsna kindlalt paigas. On selge, et ka järgmise sprindi jooksul teeb tiim enam-vähem sama palju stooripointse, kui siiani. Suht lihtne peaks olema marketingidele öelda, et näe, reaalselt me teeme selle sprindiga ära sellised asjad. Ja ükskõik kui suur tulekahju ka ei oleks, see on asi mida me saame tehtud. Mina isiklikult ei tunne mingit süümepiina või piinlikkust vms seda kliendile välja öeldes. See on matemaatika. Ka minu peale lõugamine ei aita, liitmistehe töötab ikka edasi sama moodi.

  6. Einoh, vägev, keegi viitsib argumenteeritult vastata :)

    Ok, mõistan ma õigesti, et üks alustala on kogemustega ja tiim? See muidugi lahendab terve klassi probleeme mille kallal norisin. Samas liigselt väljareklaamitud “disain pole oluline” võib ühe aktiivse lolli käes ohtlik relv olla. Ütleme siis pigem nii, et “disain pole väärtus omaette”?

    “See, et probleemid tulevad välja esimeste reliisidega, on väga hea asi. ” – tegelt tahtsingi väita, et see ei tule. Tihedatel reliisidel on Beta maik juures ja miskipärast jäetakse paljud asjad vaikselt mainimata või lausa tähele panemata.

    Ma ütleks nii, et tihedate reliiside idee toimib väga hästi kui reliisid lähevad kohe lõppkasutajale kasutamiseks(sisemine või beta veebiliides, mingi tööriist). Aga praktiliselt ei toimi mitte kunagi, kui tegu on kliendi tootega, mis läheb lõppkasutajale alles siis kui asi on “valmis” ja sinu kiired reliisid lähevad lihtsalt testimisse.

    See tarkusetera kehtib iga iteratiivse protsessi puhul. Ja lahendust ma ei tea.

    Põhiraskuseks paljudes projektides Scrumi ja paljude teiste protsesside juurutamises on et “meie ei teeme nii”, “pole mõtet hinnata ette, sest see läheb metsa niikuinii”, “teen kliendile selgeks”, “klient mõistab”. Öelda muidugi võib, ise võid end kah hästi tunda. Kuid praktiliselt midagi saavutada on aga väga raske ja siin on põhjuseid palju. Kommunikatsiooniprobleemid, harjumused, kliendi oma protsess, hirmud.

    Protsessijuurutus on üks asi millest vähe räägitakse, loodetakse, et piisab sellest, et asi hea on. Kuid, vaadakem tõele näkku, kahjuks ei piisa.

    Paralleeli võib tõmmata ka arendusvahenditega – kui ikka klient tahab mingi pisiasja C-s kirjutada ja maksta selle eest 100x rohkem kui näiteks pythoni skripi eest, siis proovi tõestada. Ja tõestadki, aga see on kliendile solvav, kirjutab otse paar levelit ülespool, et mis värk on, arendajad plõksivad. Siis, “heade suhete” nimel tehakse asi C-s. Praktikas läheb asjaga kaua, asi on bugisem, ja kõigil on pärast halb tuju ja häid suhteid pole enam kuskil. Täpselt samamoodi on protsessiga.

    “_Kõige_tähtsam_asi_üldse_ on see, et tiim saaks rahus progeda. Whatever probleemid kuskil ka ei eksisteeriks, projektijuhi (või siis ScrumMasteri) ülesanne on seista oma tiimi ees nagu firewall.”

    See on tõesti üks olulistest juhi ülesannetest, isegi sõjaväes õpetati nii, vaatamata väidetavale hoolimatusele nö kahuriliha suhtes.

    Lõppude lõpuks on ju loogiline, et kõik sujub, kui iga inimene teeb vabalt OMA tööd SEGAMATA ja HEAS TUJUS.

    Samas mikromanageerijale on jällegi seda raske selgeks teha, kuna mikromanageerija poolt lõhutud tiimis tekib palju vigu ja tegematajätmisi. Ja talle tõesti tundub, et kui ta veel ei mikromanageeriks mis siis veel oleks.

    Oehh, nüüd tagasi vaadates, tundubki, et enamik probleeme on kommunikatsiooniprobleemid :) Inimesed lihtsalt ei mõista üksteist ega ei taha kunagi oma arvamust muuta.

  7. Mõnus äratundmine, et agiilse maailmavaatega inimesi (ja ettevõtteid) Maarjamaal ikka leidub. :) Siinkohal mõned “popupid”, mis lugemise käigus mõttes üles hüppasid (pikemaks ja süstemaatiliseks jutuks pole blogikommentaar just õigeim paik).

    Päris nii ei ole, et XP-st ei saa kohe mitte põrmugi rääkida, kui kõik tosinkond praktikat pole poleerituna rakendatud. Arvan, et saab küll. Jah, kui mingi seltskond ütleb, et „me kirjutame koodi kahekesi ühe arvuti taga istudes, järelikult teeme XP-d “, siis on asi selle konkreetse metoodika rakendamisest küll seitsme mäe ja mere taga. Kui aga meeskond rakendab (mitte küll perfektselt, aga piisavalt hästi) mingit komplekti XP praktikaist ja annab endale aru, et puuduvad praktikad tuleb samuti aja jooksul juurutada ning juba kasutatavaid lihvida, siis julgeksin küll öelda, et meeskond kasutab XP-d ning sellest saab ka asjaosalistele tulu tõusma. Jah, Scrum kui pigem (projekti)juhi vaatele orienteeritud metoodika jätab XP-ga, mis on selgelt arendajakesksele vaatele orienteeritud metoodika, võrreldes märksa „lõdvema“, järsku seetõttu ka lihtsama ja sõbralikuma mulje (XP on minu arvates üldse kõige rangem, mõnes mõttes seeläbi ka kõige distsiplineerivam agiilne metoodika). Aga eelnimetatust tulenevad ka mõlema head ja vead, tugevamad ja nõrgemad küljed.

    Kui maailmas ringi käia, kuulata-arutleda ning mõtiskleda teemal „kuhu edasi“, siis mulle tundub, et erinevad agiilsed metoodikad, mis senini mingist oma ammusaegsest algsest tüvest veidi eri suundadesse kasvanud on, jõuavad tasapisi sulandumise faasi. Eelkõige on mul selline tunne Scrumi ja XP osas. Need kaks (ma pakuks, et kaks priskeimat vaala selles vallas) täiendavad teineteist kenasti ning siit tõuseks tulu mõlemale poolele.

    Kellele nüüd silma jäi, et kasutan mõistet „metoodika“ ja mitte „metodoloogia“, siis see on teadlik. Minu arusaamist mööda on inglise keelse „methodology“ vaste maakeeli „metoodika“, mitte „metodoloogia“. Viimane on siin mail liiga ambitsioonikas, kiht kõrgemalt mõiste, tähendades metoodikate kui niisuguste uurimist või siis teadust teaduse enese uurimisest või veel midagi suurejoonelisemat.

    Kui seda blogi juhtuvad lugema huvilised, kes alles kaaluvad, kas ikka tasub „mingite kahtlaste kergekaalu metoodikate ja protsessidega“ ennast siduda või jätkata tasa ning targu kose ja rupi ja mis iganes „vanade ja tõsiste tegijate“ viisil, kinnitan julgustuseks – tasub. Agiilne arendus on juba ammu peavoolu nähtus ja tõsiselt suurte (ja muidugi ka väikeste aga tõsiste) firmade igapäev. On valik siis Scrum või XP või Lean või mingi muu – see on juba konkreetse meeskonna enese asi ja äratundmine. Ja see töötab. Kui õigesti tööle panna muidugi. ;)

    Muide, et Alistar Cockburn suuremalt Scrumi tutvustamisega üles on astunud, seda on huvitav teada. Niipalju kui olen teda kuulama (ja lugema) sattunud, on tema lemmiklaps ja tavaline loenguteema ikka Crystal…

  8. Koodi loetavuse, testitavuse ja teatavas plaanis ka lahenduse üldisema disaini kohta: lisaks kõigele muule, mida meeskondlik sünergiline mõistus pakub, on selline vaikselt toimiv võlusõna nagu “refactoring”. Ega see mingi paugupüss ei ole, refaktordamise hea mõju ilmneb siiski pikema aja jooksul. Aga kui seda järjepidevalt ning teadmisega kasutada, siis eneselegi märkamatult jõutakse isegi mingi legacy koodiga niikaugele, et ühel kenal päeval mõni uus tulija või kõrvaltvaataja ütleb tunnustavalt: “Hoo, nii puhas kood!”

    Et selle olulisus meelest ei läheks oleme kõikidele XP töökohtade monitoridele isegi väikese reminderi pannud: “Leave the campground cleaner than you found it!” ;)

Leave a Reply

Your email address will not be published. Required fields are marked *