Kuigi suurem osa tänapäevastest arendusprojektidest soovitakse läbi viia agiilses arenduskeskkonnas, lõigates kasu Scrumist ja teistest agiilsetest raamistikest, siis pole Uptime’i tehnoloogiajuhi Raimo Seero sõnul haruldane, et osadel juhtudel tingib arendust ümbritsev keskkond kompromisse tegema. Seetõttu pole haruldane, et algselt agiilsena alustatud projekt omandab ühel hetkel hübriidvormi, kus omavahel sobitatakse kokku klassikaline waterfall, Scrum ja harvemal juhul veel mõni kolmas raamistik.
“Agiilses arenduskeskkonnas töötamine tähendab, et kõik osapooled mõistavad, et on mingi hulk asju, mida me ei tea, kuid kuna me usaldame üksteist, siis hakkame otsast minema ja oleme kindlad, et suudame iteratsioonide ja tagasiside toel kõik väljakutsed lahendada – kiiremini, soodsamalt ja paremini, kui liiga detailselt ette planeerides,” rääkis Seero. “Reaalses maailmas on aga kuskil mingi leping, mingi skoop ja mingid rollid, kes soovivad kindlust ja teksti, kus on täpselt kirjas, millal, mis, kuidas ja täpselt mis tundide arvuga valmib.”
Seero märkis, et kuigi iga arendusprojekti osaks on skoop ja visioon, kuhu jõuda tahakse, siis eeldab päriselt agiilses keskkonnas töötamine võimalust plaane jooksvalt muuta ja lahendada väljakutseid nii, nagu need esile kerkivad. Kuigi ühelt poolt tähendab see, et plaanid võivad muutuda ja seetõttu tuleb mõne ülesande lahendamiseks tund-kaks kauem kulutada, siis teiselt poolt loob liialt kivisse raiutud plaani puudumine võimaluse lennult paremad lahendused kasutusele võtta, leida aega säästvaid otseteid ja vastata äkilistele vajaduste muutustele – eile pidi äpp tegema kolme asja, täna hoopis nelja.
Reaalsust tuleb endale tunnistada
“Reaalses maailmas tähendab see, et suur agiilselt alanud projektidest on ühel hetkel segu waterfallist, mille puhul planeeritakse kõik meeletu detailsusega ette, ja Scrumist või muust agiilsest metoodikast, kus lahendatakse probleeme iteratsioonide käigus jooksvalt, tükkidega tegeletakse ükshaaval ning järgmist arendusfaasi analüüsitakse ja planeeritakse eelmise tüki arendamise kõrval,” rääkis ta.
Samas rõhutab ta, et hübriideste arendusmetoodikatega töötamises pole iseeneses midagi valet, kui need aitavad jooksvalt täieliku agiilsuse poole liikuda. Seejuures on aga oluline, et nii tellija kui ka arendusmeeskond ise mõistaks, et kaldudes rohkem või vähem ühe või teise metoodika poole antakse alati midagi ära ning seetõttu on oluline võetud lähenemise eeliseid-probleeme reaalselt mõista.
“Arendusprojektides on mingid piirangud tavaliselt ning kui selgub, klasskaline Scrum õigeks lahenduseks pole, siis tasub korraks aeg maha võtta ja mõelda, kuidas edasi. Võibolla on õigeks lahenduseks Water-Scrum-Fall, äkki aga hoopis SAFe, LeSS või hoopis midagi kolmandat?” sõnas ta. “Kõik see tähendab, et enne päriselt arendamise kallale asumist on oluline mõista, mis on konkreetse projekti puhul kõige olulisem. Vastavalt sellele saab valida õige arendusmetoodika, samas endale ausalt tunnistades, mida tehakse ning kas asju nimetatakse lihtsalt ilusa nimega, või on päriselt tegu agiilsusega. See aitab ootused õigesse kohta seada.”
