Infotehnoloogia ettevõtjale 880 sõna
Agiilarendus, ingl k agile development või ka lihtsalt agile, on 1980-ndatel tekkinud mõtteviis, mis ütleb, et tarkvara tegemisel :
Aga vastuargument: kas pooliku tootega välja minek ikka on hea mõte?
Nii on garanteeritud, et tekib töötav süsteem.
Tänapäevaks on agiilmeetodid saanud tarkvaraarenduse peavooluks (mainstream), üldtunnustatud arendusmeetodiks. Praktika on kinnitanud, et agiilarenduses:
Miks agiilarendus on üldse teema?
Vastus peitub osalt tarkvara tegemise olemuslikus keerukuses ja osalt organisatsiooni- ja inimese psühholoogias.
Agiilse tarkvaraarenduse manifest on 2001. a tuntud agiilmõtlejate poolt kokku pandud 4-punktiline deklaratsioon, agiilliikumise ideoloogiline tüvitekst. Mõtet on orginaalsõnastused meelde jätta:
inimesed ja nendevaheline suhtlus on tähtsam kui protsessid ja arendusvahendid
töötav tarkvara on olulisem kui kõikehõlmav dokumentatsioon
Customer collaboration over contract negotiation
koostöö kliendiga on loob rohkem väärtust kui läbirääkimised lepingute üle
Responding to change over following a plan
reageerimine muutunud oludele on adekvaatsem kui algsest plaanist kinnihoidmine
Erder & Pureur (2016) What’s the Architect’s Role in an Agile, Cloud-Centric World?. IEEE Software.
Agiilne tööde struktuur. Nt: 1) eepik (Epic) - “high-level goal of the product for the multi-release time horizon”; 2) featuur (Feature) - eepiku osa, mis teostatav ühe reliisitsükliga; 3) kasutuslugu (User Story) - featuuri osa, funktsionaalsuse väike tükk kasutaja vaatepunktist; 4) ülesanne (Task) - tehniline ülesanne, mida on vaja kasutusloo teostamiseks.
Võtmesõna seejuures on reliis (Release). Kosemudeli järgi toimuvas arenduses reliisitakse tüüpiliselt kord aastas või veel harvemini. Avaarenduse guru Eric S. Raymond aga ütleb, et „Release early, release often“.
Vrdl: 1) strateegia; 2) tööplaan; 3) tegevuskava; 4) arenduse iteratsioon; 5) minihange; 6) etapp; 7) tööpakett; 8) omadus/nõue
Frechette, Galen (2013) The Product Design Sprint
“Tootedisaini sprint”, viiepäevaline kiire tootearenduse protseduur: 1) saada aru (Understand); 2) genereerida variante (Diverge); 3) vali (Converge); 4) prototüübi (Prototype); 5) Testi ja õpi (Test & Learn).
(“Agiilsusbaromeeter”)
Küsimused on mõeldud vastamiseks Tellijale. Küsitletakse mitut Pakkuja poolt referentsina esitatud Tellijat. Punktid summeeritakse ja arvutatakse keskmine.
1 Kas tellisite arendustööd klassikalise koskmudeli (ingl Waterfall) järgi või soovisite agiilset arendust?
Märkus. Koskmudeli tunnusteks on ühe või mitme järgmise elemendi esinemine: tööde teostamine enne arendust koostatud spetsifikatsiooni v põhjaliku lähteülesande alusel; lähteülesande fikseerimine lepingus (muudatuste mitte ette nägemine); tööde jagamine etappideks - analüüs, projekteerimine, programmeerimine, juurutamine jne; tulemite üleandmine etapi või lepingu lõpus; töötava, paigaldatud koodi valmimine lepingu lõpuks.
(kui koskmudel, siis 0 punkti ja intervjuu lõpp)
2 Kas Täitja lubas pakkumuses, et teostab tööd agiilselt?
Jah - 0 p, Ei - 0 p
Märkus. Sõna “agiilne” kasutamine iseenesest pole määrav.
3 Kas teie arvates tööd teostati agiilselt?
Jah - 3 p, Ei -0 p; Ei oska öelda - 0 p
4 Kas tööd teostati iteratsioonidega (arendustsüklitena)? Kui pikk oli üks iteratsioon?
Jah, interatsioon kuni 2 nädalat - 2 p; Ei või iteratsiooni pikkus üle 2 nädala - 0 p
5 Kas igal iteratsioonil teostati väike arv kasutuslugusid või kasutajale vajalikke omadusi?
Jah - 2 p, Ei - 0 pt
6 Palju kasutuslugusid oli korraga töös?
Kuni 8 kasutuslugu - 2 pt; kuni 12 kasutuslugu - 1 pt; üle 12 kasutusloo või kõik kasutuslood - 0 pt
7 Kas iga iteratsiooni lõpuks valmis töötav kood (mitte prototüüp), mida demonstreeriti Tellijale?
Jah - 2 p, Ei - 0 p
8 Kui tihe oli Täitja ja Tellija arendajate suhtlus?
Igapäevane, arendus toimus in-premise, Tellija ruumides - 4 pt; igapäevane skype-i vms suhtluskeskkonna abil koos iganädalaste koosolekutega - 3 pt; iganädalasel koosolekul ja vajadusel e-postiga - 0 pt
9 Kui pikk oli iganädalane projektikoosolek?
Kuni 1 h - 1 p, üle tunni - 0 p
10 Kas Täitja meeskonnas oli Scrum Certified Master vm analoogiliste agiilmeetodite sertifikaatidega liikmeid?
Jah - 0 p, Ei - 0 p
11 Palju kulus aega minimaalse funktsionaalsusega, piirangutega, kuid siiski lõppkasutaja seisukohast kasutatava lahenduse tekkimiseks?
Kuni 2 kuud projekti algusest - 2 pt, kuni 3 kuud projekti algusest - 1 p, kauem kui 3 kuud - 0 p
Hindamisskaala: 15 või rohkem punkti - agiilarenduse kogemus on tõendatud; 0-14 punkti - agiilarenduse kogemus ei ole tõendatud