Agiilne arendus ei ole võluvits IT-hangetel

Olen nõus, et agiilne arendus on traditsioonilisest iteratiivsest mudelist mõnes kontekstis parem ja kohati efektiivsem, kuid iga metoodika jaoks on olemas kindel aeg ja koht, kus seda kasutada.

Enamasti pole IT-lahenduste hankijad teadlikud, et agiilne arendus vajab üpris vilunud arendusmeeskonda ja kindlakäelist juhtimist nii kliendi kui ka pakkuja poolel ning see asetab tellija tihtipeale kehvemasse seisu. Riigiasutused ei suuda tavaliselt agiilse arenduse põhimõtete järgi toimetada, kuna nende enda organisatsiooni ülesehitus seda ei toeta – nt võtab otsustamine liiga palju aega või kehtiv seadusandlus ei lase soovitud tulemust saavutada.  Tulemuse saavutamiseks on vaja muuta seadust.

Enne suure hurraaga agiilse arenduse juurde tõttamist ja selle hanketingimustesse lisamist tasub endalt küsida, kas asutuses on piisavalt kogemusi ja teadmisi, et sellega kaasas käia. Hankijad ei kipu olema vilunud arendusspetsialistid ning ei pruugi teada, millist valmisolekut ja panust agiilsed arendusprojektid nendelt tegelikult nõuavad.

Oleme kõrvaltvaatajana näinud, kuidas suured projektid hakkavad rebenema just siis, kui toimub liigne agiilse arenduse pealesurumine keskkondades, mis oma loomult agiilsust ei toeta. Selline tegutsemisviis meenutab tihtipeale metsiku hobuse selga ronimist, mille tulemuseks pole õigesse kohta veetud raske koorem ega kerge ja kiire galopp, vaid hoopis tõsisemat tüüpi vigastused.

Kriitilisi protsessijuhtimise ja seadmete automaatjuhtimissüsteeme ei saa kahjuks rakendada nii, et teeme midagi valmis, paneme muutujad sisse, lülitame käima ja vaatame, kas protsess jääb seisma või süsteem plahvatab. Agiilset arendust on jätkuvalt kõige efektiivsem kasutada projektides, mis ei ole oma olemuselt missioonikriitilised.

Agiilse arenduse läbisurumine riigiasutustes ja isegi ettevõtetes, kes pole oma loomult agiilsed, viib enamasti pikemate tähtaegade ja erinevate sisepingeteni. Suurte arendusprojektide puhul on hankijatel mõttekam projekt väiksemateks tükkideks jagada ning seejärel pikalt peeglisse vaadata ja otsustada, kas nende asutuse puhul on mõttekas arendada tänapäevase iteratiivse mudeli alusel või kasutada selleks mõnda agiilse arenduse metoodikat, olgu selleks siis Scrum, Lean, Kanban või XP.

Iteratiivne arendus sisaldab nt kasutajakogemuse disaini faasis agiilse arenduse komponente ning on enamikele hankijatele parim võimalik lahendus. Erinevad ideed katsetatakse varakult läbi ning arendusse jõuab lõplik ja läbimõeldud süsteem.

Tarkvaraarenduse planeerimisel ja hangete koostamisel võiksid hankijad kaaluda põhjalikult erinevate arendusmetoodikate plusse ja miinuseid. Kui peate valima kahe metoodika vahel, millest üks on moodsam ning teine sobivam ja jõukohasem, siis kahtluste tekkimise korral tasub valida just viimane.

Kokkuvõttes on oluline siiski kvaliteetne e-teenus, mitte valitud arendusmetoodika.

Marko Nemberg osaleb 20. märtsil toimuval seminaril "IT-hanked uue riigihangete seaduse järgi" ja räägib oma tähelepanekutest tarkvaraettevõtete arutlusringis, kus on teemaks kogemused uue riigihangete seadusega ja hankepraktika kitsaskohad. 

Autor: Marko Nemberg