Agiilse arendusmeetodi kiirkursus
Olen IT-maailmas veel täiesti idu seisundis, aga siiski proovin selle ülesande täitmisel toetuda isiklikule kogemusele. Juhtus nii, et sattusin aastaks tööle ühte pisikesse Hollandi-Horvaatia tarkvarafirmasse. Ilma igasuguse ettevalmistuseta visati mind keset projekti vette, minu ülesanne oli arendatavat süsteemi testida ja dokumenteerida, päästerõngaks minu enda kangekaelsus ja tööandja jäägitu toetus. Pikemat sissejuhatust ei tehtud, kord nädalas oli Teams'i koosolek ja edasi sumas igaüks omas ujumisrada pidi.
Nüüd tagantjärgi saan aru, et meeskond kasutas agiilse arenduse põhimõtteid. Esmaspäevasel koosolekul tutvustas igaüks, kuidas eelmisel nädalal läks ja mis on selle nädala prioriteedid. Uuel meeskonnaliikmel saavad nii päris hästi teiste nimed ja näod selgeks ja on ka ülevaade sellest, mis meeskonnal tervikuna parajasti käsil on. Samuti aitas see mõista, et vahel pannakse ajaarvestusega mööda, ja näitas ka, kuidas meeskond vastavalt kliendi soovidele tööd ja protsesse kohandas.
Selles projektis oli klient oli protsessi väga aktiivselt kaasatud. Meeskonnal regulaarsed mitme tasandi (juhtimise, arenduse) kohtumised, kliendile oli loodud eraldi testikeskkond ja kuna keskkonna töövõtted ja nõuded olid kaunis spetsiifilised, siis tegelikult koostas klient ka kvaliteetseid testiraporteid. Samas oli selgelt tunda, et kliendiga oli kokku lepitud funktsioonipõhises arenduses ja kui töö väga toppama jäi, anti ekstreemprogrammeerimise ja koodi läbivaatusega hoogu juurde.
Nagu ka juba foorumis tõdeti, on projektihalduse töövahenditest kasu vaid siis, kui need päriselt ka tööd hõlbustavad. Paistab, et see meeskond ei olnud igasugu board'ide usku. Lõpuks jäädi pidama MatterMosti ja Githubi kombinatsioonile, aga elasime üle ka selle, kuidas sobivaid vahendeid järjest katsetati.
Sain omal nahal tunda ka agiilse arenduse murekohti. Teada on oht, et dokumenteerimine jääb projekti lõpufaasi. Sel hetkel mina projektiga liitusingi, aga siis olin ma ka olukorras, kus mul ei olnud ülevaadet ei projekti seisust ega sellest, milline peaks olema lõpptulemus. Nii et ühelt poolt pidin ma tegema parajat detektiivitööd, et aru saada, mida süsteem tegema peab ja seejärel testimises tuvastama vigase käitumise, teisalt püüdsin eri tasandi spetsialistidelt kätte saada infot, mis aitaks kirjutada dokumentatsiooni. Õigupoolest läks see kõik lihtsamaks alles siis, kui mõistsin, et mitte kellegi polnud süsteemi toimimisest tervikpilti ja mina olin see, kes need tükid kokku pidi panema.
Kokkuvõttes arvan, et agiilne arendus töötab väikse meeskonna puhul ülihästi. Regulaarsed ja väikese intervalliga koosolekud hoiavad töötempo kõrgel ja mõtted asja juures. Miinus on see, et kui kliendil on muutlikud või ebamõistlikud nõudmised, siis selle võrra tõuseb stressitase kogu meeskonnas.
World Anvil ja annetuspõhine mudel
Tutvusringkonnast on mul tuua näide selle kohta, kuidas hobiprojektist kasvab edukas ettevõte. World Anvil on maailmade ehitamise platvorm, mis sobib nii kirjanikele kui rollimängude mängijaile. Platvormi loojad tabasid ära niši laua- ja rollimängukogukondades, pakkusid välja tehnoloogilise lahenduse ning oskasid hiljem juba toimivad kogukonnad oma projekti kaasata.
Pikalt toimis platvorm annetuspõhisel mudelil – Patreoni ja Twitch.tv kaudu kaasati nii palju finantse, et sai ehitada toimiva toote. Seejärel kaasati vabatahtlikud, kes aitasid toodet edasi arendada, nüüdseks toimib WorldAnvil peamiselt freemium-mudelil, kus põhifunktsioonidele on ligipääs vaba, kuid lisafunktsioonid on saadaval teatud tasu eest.
World Anvil on ilus näide sellest, kuidas mingit valdkonda süvitsi tundes saab kogukonna toel sellele IT-ga lisandväärtuse anda.
Kommentaarid
Postita kommentaar