Agiilne tarkvaraarendus ei ole…

… see mis sa arvad!!!

Olles järjekordsel konverentsil järjekordsete professoritega vaielnud, tekkis tahtmine tarkvaramaailma agiilset paradigmat veidikene selgitada. Konverentsiks oli XP2010, aga professorid jätaks enda teada. Võimalik, et kõik ei olnud akadeemilised professorid, kuid elu professorid ning kõiketeadjad konsultandid küll. Ühesõnaga me loobime termineid, ise teadmata, mis see tähendab ja selle koha pealt tuleb midagi ette võtta.

Mis siis toimub?

Agiilne tarkvaraarendus ei ole protsess, raamistik, mudel, ega midagi, mis võiks eeltoodud nimekirja lisanduda. Agiilse tarkvaraarenduse jaoks ei pea tegema paarisprogrammeerimist ega ka test-driven progemist – EI PEA. Viimati mainitud on lihtsalt praktikad, mida võid kasutada kus iganes ja millal iganes. Kasuta paarisprogemise põhimõtteid kasvõi vanaemaga sukka kududes, ega see midagi siis kohe agiilsemaks tee… Käesoleval hetkel on oluline just miks sa seda tööd paaris teed!

Mis see agiilne tarkvaraarendus siis ikkagi on?!? Okei, okei, ei hoia enam saladust – nagu see varem hirmsalt peidetud oleks.
Agiilne tarkvaraarendus on lähenemisviis! Meile teadatuntud keeles siis approach mitte process, framework, tehnika, metodoloogia, meetod, vms. Lähenemisviis siis lihtsalt seab softi arendades ette mõned põhimõtted, millest lähtuda, muud ei midagi! Kohe päris kindlasti ei tähenda agiilne lähenemine ühtegi kohustuslikku praktikat, mis sageli millegipärast inimeste meeles on. Hea küll, võibolla pole see fakti tunnistamine piisavalt selgitav ning läheme siis täpsemalt lähenemisviisi lahkama.

Agiilne softi arendus sai alguse agiilsest manifestist, kus nimetati ära mõned põhimõtted, millest peaks lähtuma. Tegelikkuses on need põhimõtted ääretult lihtsat, kuid millegipärast sageli unustusse vajunud.

Manifest siis selline…

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on?the right, we value the items on the left more.

Ei ole vast mõtet hakata lahkama erinevaid ridu – aega lihtsalt pole nii palju ja mingit eepost kirjutama ei hakka. Seega peatume ainult viimase lause juures.

Just seesama lause unustatakse sageli ära, kuid see on vahest üks olulisemaid manifestis. Kui eelpool seatakse põhimõtted ritta, siis ei unusta me seda ära, et olemas on ka nö Common Sense ja nüüd tuleb leida tasakaal erinevate poolte vahel. Ei ole ainult nii, et inimesed over-rule’vad protsessi. Kui ikka vaja teeme protsessi ja jutul lõpp. Seega tegelikkuses on juriidiliselt ka see korrektne, kui me nimetame waterfall meetodil arendavat softi agiilseks lähenemiseks antud situatsioonis. Situatsioon peab olema muidugi mingi tuumapommi regulaatori juhtmuhvi progemine, kus me peame otsuseid tegema teistel alustel. Seniks aga kui inimesed teevad otsuseid agiilset manifesti silmas pidades on kõik jokk.

Nii et lugegem veelkord manifest läbi ning mõelge, mis teeb teie projektid, arenduse või elu agiilsemaks… on see nüüd siis lähenemisviis või mingi tehnika, mida te XP raamatust lugesite…

6 thoughts on “Agiilne tarkvaraarendus ei ole…”

  1. Ohoo milline tubli provokatiivne artikkel :)

    Kirjelda palun natuke seda agiilset watefalli, mul endal jääb kujutlusvõimet väheks. Jokk ei ole agiilne, jokk on nii anti-agiilne kui üldse olla saab.

  2. nagu mainitud on agiilne arendus lähenemisviis (mõtteviis) ning waterfall protsessi mudel. Seega ei takista üks kuidagi teist. Kui tulete kokku uut softi arendama agiilne mõtteviis peas ning otsustate, et jah waterfall on way to go, siis palun. Me räägime siin äärmustest, mis reaalses elus kunagi ilmselt ei rakendu, aga paberil võiks see nii olla. Ja miks see kunagi ei rakendu, sest segatakse ühte patta kokku mõtteviisid ja protsessid, tehnikad, jms, aru andmata, mida mõisted tähendavad.

  3. Pooled punktid välistavad waterfalli:

    Customer collaboration over contract negotiation
    Responding to change over following a plan

    Waterfallis sa liigud ühest etapist teise, võttes aluseks eelmise etapi kinnitatud tulemuse, kaks eelmist punkti põhimõtteliselt välistavad selle.

    Põhiline on siiski see, et selline arendusmudel nagu waterfall on mingi tohutu arusaamatus – see oli tähelepanek ebaõnnestuvate projektide kohta, aga noh, keegi pani sellele nime ja siis hakati selle järgi projekte tegema. Telefonimäng noh. Nüüdseks on see ka wikipedias ära parandatud – soovitan oma koolitarkuse nüüd kustutada ja üle lugeda.

    Samuti see jutt:

    http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

  4. > nagu mainitud on agiilne arendus lähenemisviis (mõtteviis)

    No ma ikka ei tea…

    Minu arust ‘mõtteviis’ ei ole seesama, mis ‘arendus’. Agiilselt mõtlemine ei taga veel agiilset tarkvaraarendust. Arenduse teevad agiilseks need agiilsed praktikad, mis jõuavad mõttemaailmast ka reaalselt kasutusele.

  5. “waterfalli” põhiline halb omadus olevat paindumatus. Saanud waterfalli ajastul faas läbi siis käitutanud tulemustega kui kivisse graveeritutega. Reaalses elus aga keegi ju nii teinud pole!?!

    Seega … waterfall on pseudomudel. Waterfall on tont, mida järjekordse uue metoodika jutlustajad alati seinale joonistavad. Selleks, et siis saaks väita, et nende “uus” metoodika on parem millestki, mida olemaski pole.

    Suurema projekti juures on ikka mõistlik selle tegemise kulukus umbkaudu ära hinnata, plaane teha ja ikka ka umbkaudu etappideks katsuda jagada. Loomulikult tuleb siis tegemise käigus ka neid plaane korrigeerida. Kukkuda otsast “2 nädalat korraga” agiilselt nikerdama ja rapsima, et siis iga spurdi lõpus vaatame, kus oleme, mõistlik ei tundu.

  6. Agiilne tarkvaraarendus

    Mingist asjast rääkides, on alati nutikas kohe selgeks teha, kas räägime nähtusest või protsessist. Agiilne tarkvaraarendus võib olla vaadeldud nii protsessi kui nähtusena.

    Antud loo autor on püüdnud öelda, et me ei saa rääkida agiilsest tarkvaraarendusest kui protsessist vaid üksnes kui nähtusest. Tegelikult saab mõlemat. Arengut võime vaadelda nii nähtuse kui protsessina. Lapse arenemine kui protsess. Laste arengud eri ühiskondades või subkultuurides kui nähtus.

    Ehk teisisõnu agiilne tarkvaraarendus kui tarkvaraarenduse protsess tugineb agiilsel manifestil.

    http://tarkvara.tv/artiklid/tarkvaraarendus/

Leave a Reply

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