Agiilne treening

See idee pärineb ühelt kolleegilt, kes seostas muusika ja tarkvaraarenduse – protsess on agiilne ja iteraktiivne ning pärast arendust minnakse live’i (mõnikord minnakse kohe live’i – eriti kõvadel meestel tuleb asi ka siis hästi välja, aga see kuulub rubriiki “ärge seda kodus järgi tehke”). Ma nüüd väänan sellele ideele veel ühe vindi juurde ja räägin hoopis agiilsest treeningust.

Soojenduseks sõnaseletusi tarkvaravõhikutele:

•  agiilsus (agility) – eestikeelne vaste oleks väledus või kohanemisvõime. Tarkvara-arenduses töökorraldus, kus kliendilt saadakse pidevat tagasisidet tarkvara kvaliteedi ja prioriteetide kohta. Algsest plaanist kinnipidamine ei ole oluline, tähtis on anda kliendile kiiresti töötav tarkvara ning seda hiljem vajadusel täiendada ja muuta.
• iteratiivsus – maakeeles kordamine. Tarkvara-arenduse kontekstis tähendab, et erinevad protsessi osad (analüüs-arendus-testimine-live) käiakse läbi korduvalt, lühikeste perioodide kaupa ja iga kord võetakse ette ainult mingi väiksem osa tarkvarast. 

See oli siis meelevaldne lühikokkuvõtte, huvilised võivad vaadata agiilse tarkvaraarenduse manifesti või Wikipediat.

Agiilsust saab aga suurepäraselt rakendada ka spordis ja kui päris aus olla, siis seda ka tehakse, aga ei nimetata just päris nii. Milline oleks siis agiilne sport? Kohandame Agile Manifesto ideid ja saame:

Sporti tehes ning teisi spordi tegemise juures aidates oleme leidnud selleks tööks paremaid viise.
Oleme hakanud hindama:

• reaalset tulemust rohkem, kui kõikehõlmavat treeningplaani
• inimesi ja nendevahelist suhtlust rohkem, kui protsesse ja -vahendeid
• koostööd treeneri, ametnike ja sportlase vahel rohkem, kui reegleid ja käske
• reageerimist muutunud oludele rohkem, kui algse plaani järgimist

Ka parempoolsetel teguritel on väärtus, kuid me hindame vasakpoolseid tegureid kõrgemalt.

Mida see kõik ikkagi tähendab? 

Kõigepealt peab olema mingi visioon tulemusest, milleni me tahame jõuda, mida me tahame saavutada, miks me sporti teeme (vastavalt – millist probleemi meie tarkvara lahendab).
Seejärel on mingisugune plaan, kuidas selleni jõuda – arvestades olukorda, millest alustamine. Ei pea olema eriti detailne (see on üldanalüüs).
Siis võetakse üldplaanist mingid osad, mis on kõige tähtsamad, millega tegelemine aitaks meid kõige rohkem edasi ja viiakse need ellu (vastavalt – ühe komponendi/funktsionaalsuse detailanalüüs ja realisatsioon).
Järgneb testimine spordis, mis ongi testmine ja live oleks siis võistlus. Treeningvõistlus on pre-live:)
Testimine annab sisendi hindamisele: kas me jõudsime eesmärgile lähemale? Kas meie eesmärk on üldse õige? Kas üldplaan kehtib? Mis on järgmine üldplaani osa?
Ning kõik algab otsast peale. Sealjuures on olulised inimestevahelised suhted – avatud ja sõbralik suhtumine, kuna eesmärk on ühine (tulemus/töötav ja kasulik tarkvara). Autoriteedi asemel kehtivad kokkulepped. Plaanid on olemas, aga neid võib muuta.

See võib kõlada üsna kaootiliselt ja paradoksaalselt ongi kaose vältimiseks ka agiilsel arendusel üsna kindlad raamid ja protsessid:) Näiteks on mingid fikseeritud ajavahemikud, mille jooksul plaane/kokkuleppeid ei muudeta ja kindlad ajad, millal kõik need üle vaadatakse. Samuti on raudkindel reegel teiste inimeste ja nende arvamuse austamine. Aga üldiselt panebki iga meeskond (mitte võistkonna tähenduses, vaid siis ametnikud-treenerid-sportlased/kliendid-analüütikud-arendajad-testijad kompott) paika omad reeglid ja seejärel austab neid – seni, kuni need uuesti üle vaadatakse.

Ja ideaalis liigume me samm-sammult muudki parema tuleviku poole! Alati kui ma kirjutama hakkan, jõuan ma tagasi ühe põhimõtte juurde – tee mis tahad, peaasi et hea saab:)