{"id":5,"date":"2018-12-05T14:34:27","date_gmt":"2018-12-05T14:34:27","guid":{"rendered":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/2018\/12\/05\/chapter-1\/"},"modified":"2021-01-25T12:06:26","modified_gmt":"2021-01-25T12:06:26","slug":"chapter-1","status":"publish","type":"chapter","link":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/chapter\/chapter-1\/","title":{"raw":"Tarkvara kvaliteet","rendered":"Tarkvara kvaliteet"},"content":{"raw":"Selles peat\u00fckis \u00f5pid:\r\n<ul>\r\n \t<li>tundma tarkvara kvaliteedi m\u00f5istet<\/li>\r\n \t<li>kirjeldama tarkvaraarenduse protsessi eeldusi ja etappe<\/li>\r\n \t<li>v\u00f5rdlema tarkvaraarenduse protsessi koskmudelit ja agiilset mudelit<\/li>\r\n \t<li>osalema tarkvara arendustiimi koost\u00f6\u00f6s projektijuhtimiskeskkonnas<\/li>\r\n<\/ul>\r\n<h2>Kvaliteedi m\u00f5iste<\/h2>\r\nKuigi k\u00f5igil on mingi ettekujutus, mille poolest erineb kvaliteetne toode mittekvaliteetsest, on l\u00e4hemal vaatlusel tegemist v\u00e4ga keerulise m\u00f5istega. \u00dchelt poolt seostub toote v\u00f5i teenuse kvaliteet selle v\u00e4\u00e4rtusega. Seega oleks lihtne j\u00e4reldada, et kallim auto, arvuti v\u00f5i maja on alati kvaliteetsem kui odav, aga see pole alati t\u00f5si.\r\n\r\nKeskajal ja enne seda tegid kvaliteetseid relvi, ehteid, laevu ja ehitisi oma ala meistrid. Iga ese oli unikaalne ja iga meistri eesm\u00e4rgiks oli s\u00e4ilitada oma maine, mist\u00f5ttu meistri poolt oma loomingule j\u00e4etud tunnusm\u00e4rk oli justkui kvaliteedi garantiiks. Uusajal t\u00f5i t\u00f6\u00f6stuslik p\u00f6\u00f6re kaasa masstootmise, kus \u00fchesarnased tooted valmisid sadade t\u00f6\u00f6tajate panuse tulemusena keerukal tootmisliinil. Masstoodetud kaupade puhul ei suuda keegi kontrollida iga \u00fcksiku toote kvaliteeti v\u00f5i uskuda, et \u00fchest tehasest tulevad alati paremad tooted kui teisest, mitte niiv\u00f5rd tuntud\/tunnustatud mainega tootjalt. Tehastes hakati kontrollima toodete kvaliteeti pigem pisteliselt, n\u00e4iteks testides p\u00f5hjalikumalt iga sajandat v\u00f5i tuhandendat toodet ja otsides neist t\u00fc\u00fcpilisi vigu (sellega tegelesid eraldi tehnilise kontrolli spetsialistid). Viimastel aastak\u00fcmnetel on v\u00f5itnud populaarsust hoopis ettev\u00f5tte enda sisemiste protsesside, mitte \u00fcksikute toodete kvaliteedi hindamine. N\u00e4iteks <a href=\"https:\/\/fractory.com\/et\/5-iso-standardit-toostuses\/\">ISO 9001<\/a> kvaliteeditunnistuse saab ettev\u00f5te, mis suudab t\u00f5estada, et ta pidevalt parendab oma teenuseid kliendikeskselt, firmas toimib eesm\u00e4rgikeskne ja inimesi kaasav juhtimine, t\u00f5endusp\u00f5hine otsustamine ja t\u00f6\u00f6tajate pidev koolitamine. Sellises ettev\u00f5ttes on suure t\u00f5en\u00e4osusega ka k\u00f5ik tooted ja teenused hea kvaliteediga. Nagu n\u00e4ha, on l\u00e4bi ajaloo kujunenud erinevaid l\u00e4henemisi toodete ja teenuste kvaliteedi hindamisele.\r\n\r\n\u00dcldiselt t\u00e4hendab mingi toote v\u00f5i teenuse (n\u00e4iteks nutirakenduse) kvaliteet vastavust eelnevalt kliendi ja arendaja vahelises lepingus kirjapandud n\u00f5uetele ehk skoobile. Tarkvara anal\u00fc\u00fcsi protsess keskendubki taoliste n\u00f5uete s\u00f5nastamisele ja kliendiga l\u00e4bir\u00e4\u00e4kimisele, millest edaspidi juhenduvad nii tarkvara arendajad kui ka testijad. Paraku soovivad kliendid kvaliteetset toodet, millel on v\u00f5imalikult palju funktsionaalsusi ja seda veel v\u00f5imalikult odavalt ja kiiresti. Anal\u00fc\u00fctiku kohuseks on m\u00f5ista ja kliendile selgitada, et neid k\u00f5iki korraga ei saa ja tuleb otsida sobivat tasakaalu <a href=\"https:\/\/en.wikipedia.org\/wiki\/Project_management_triangle\">projektijuhtimise kolmnurgas<\/a>.\r\n\r\n[h5p id=\"15\"]\r\n\r\nTavaliselt on lihtsamad ja universaalsemat sorti arendusn\u00f5uded seotud tarkvara \u00fchilduvusega (nt nutirakendus toimib nii IOS kui Android platvormil, uue ja vana nutiseadme peal), j\u00f5udluse ja t\u00f6\u00f6kindlusega (ei esine t\u00f5rkeid ka suure koormuse v\u00f5i rumalate kasutajate puhul) v\u00f5i turvalisusega (pahatahtlikud r\u00fcndajad ei p\u00e4\u00e4se kasutaja andmetele ligi). Samas on suurem osa arendusn\u00f5udeid siiski otseselt seotud tarkvara funktsionaalsustega ja nende v\u00e4ljaselgitamine ongi anal\u00fc\u00fctiku \u00fclesanne.\r\n\r\nT\u00e4nap\u00e4eval \u00fcha enam suuri tehnoloogiaettev\u00f5tteid (Eestis nt Telia ja Elisa) oma kvaliteedijuhtimise protsessi \u00fcldisele parendamisele ja on taotlenud <a href=\"https:\/\/fractory.com\/et\/5-iso-standardit-toostuses\/\">ISO 9001<\/a> tunnistuse. Sel juhul v\u00f5etakse teenuse kvaliteedi hindamisel arvesse arendusprotsessi kavandamist, juhtimist, j\u00e4lgimist ja dokumenteerimist \u00fcle k\u00f5igi arendusprojektide.\r\n<h2>Tarkvaraarenduse protsess<\/h2>\r\nMajade ehitamise protsess on Eestis suhteliselt rangelt reguleeritud ja koosneb paljudest sammudest, mida saab teostada ainult siis kui eelmine samm on l\u00f5petatud. N\u00e4iteks oma kodumaja ehitama asudes peab esmalt taotlema kohalikust linna- v\u00f5i vallavalitsusest projekteerimistingimused, seej\u00e4rel tellitakse arhitektilt nendele tingimustele vastav ehitusprojekt. Valminud ehitusprojekti p\u00f5hjal v\u00e4ljastab omavalitsus ehitusloa ja alles siis v\u00f5ib ehitama asuda. Ehitamisprotsessi ja valminud maja vastavust n\u00f5uetele ja projektile j\u00e4lgib pidevalt ehitusj\u00e4relvalve eest vastutav firma v\u00f5i spetsialist. Kui l\u00f5puks on valminud maja vastavust k\u00f5igile n\u00f5uetele kontrollinud nii omavalitsus kui p\u00e4\u00e4steamet, siis v\u00e4ljastatakse kasutusluba ja v\u00f5ib sisse kolida.\r\n\r\nSarnaselt majaehitusega toimis veel m\u00f5ne aastak\u00fcmne eest ka tarkvaraarendus. Esmalt kehtestati projekteerimistingimused, siis koostas insenerib\u00fcroo tarkvara-arendusplaani ja pani selles paika arendusprotsessi etapid ja hindamiskriteeriumid. Teise arendusetapi juurde enne ei asutud kui esimene oli kontrollitud ja n\u00f5uetele vastavaks kuulutatud. Sellisel viisil v\u00f5ttis tarkvaraarendus suhteliselt palju aega ning suuremahulisemaks ja keerukamaks muutuvate infos\u00fcsteemide l\u00e4htekoodist oli \u00fcha raskem vigu \u00fcles leida. Ka kasutajad polnud rahul sellisel moel arendatud tarkvaraga, sest neid arendusprotsessi ei kaasatud.\r\n\r\nSellist traditsioonilist l\u00e4henemist tarkvaraarendusele nimetatakse koskmudeliks (i.k. <em>waterfall model<\/em>), kuna see visuaalselt meenutab ka n\u00e4iteks Tallinnas Kosmose kino ees paiknevat purskkaevu v\u00f5i kuulsat Trevi purskkaevu Roomas, milles vesi valgub kolmandasse basseini alles siis kui esimene ja teine t\u00e4is saanud on. Traditsioonilises koskmudelil p\u00f5hinevas tarkvaraarendusprotsessis ei p\u00f6\u00f6rdutud tagasi n\u00f5uete muutmise juurde sageli ka siis kui programmeerimise v\u00f5i testimise etapis leiti n\u00f5uete osas probleeme.\r\n\r\n10-15 aastat tagasi hakkasid v\u00e4ikesed tarkvarafirmad kasutama uudseid l\u00e4henemisi tarkvara-arendusele, mis v\u00f5imaldavad juba esimeses arendusetapis kasutajatele loodava s\u00fcsteemi esialgset protot\u00fc\u00fcpi tutvustada ning seel\u00e4bi kasutajatelt tagasisidet ja arendusettepanekuid koguda. Selliseid tarkvara-arendusmeetodeid nimetatakse agiilseteks ehk v\u00e4ledateks (i.k. <em>agile development<\/em>). Enamus v\u00e4lemeetodeid koosneb \u00fcldjuhul intensiivsetest arendusts\u00fcklitest. Iga ts\u00fckkel ehk sprint kestab vaid 1-2 n\u00e4dalat, sel on oma kitsas eesm\u00e4rk (rakenduse j\u00e4rgmise versiooni v\u00e4ljalase) ja selles l\u00e4bitakse kiirendatult nii planeerimise, disaini, arendus kui testimise etapp. Eesm\u00e4rgiks on anda v\u00f5imalikult kiiresti kasutajatele katsetamiseks minimaalsete v\u00f5imalustega protot\u00fc\u00fcp (i.k. <em>Minimal Viable Product<\/em>, MVP).\r\n\r\n[h5p id=\"16\"]\r\n\r\nLisalugemist: uuri l\u00e4hemalt, kuidas toimib <a href=\"https:\/\/codeborne.com\/et\/2015\/09\/15\/agiilne-tarkvaraarendus.html\">agiilne arendus XP meetodil Eesti tarkvarafirmas Codeborn<\/a>.\r\n<h3>N\u00e4ide v\u00e4learenduse kohta: Scrum<\/h3>\r\nScrum on \u00fcks populaarsematest v\u00e4learendusmeetodeist Eesti tarkvaraarenduse maastikul. Scrumi meeskonna t\u00f6\u00f6d juhib Scrum Master, lisaks arendajatele, disainerile ja anal\u00fc\u00fctikule on tiimi kaasatud ka tooteomanik (kes v\u00f5ib olla tellija esindaja). Scrumi sprindi alguses pannakse paika sprindi eesm\u00e4rk ja kava, mille p\u00f5hjal s\u00f5nastatakse sprindi konkreetsed \u00fclesanded (sprindi skoop, mis on v\u00e4ike osa toote skoobist). Sprindi k\u00e4ivitudes tehakse igal hommikul kiir\u00fclevaade erinevate tiimiliikmete poolt eile tehtud asjadest ja t\u00e4nastest plaanidest. Sprint l\u00f5peb kui k\u00f5ik skoobis kavandatu on valmis ja kokkuv\u00f5te tehtud. Tavaliselt tehakse enne j\u00e4rgmise sprindi kavandamist veel ka tagasivaade m\u00f6\u00f6dunud sprindile (retrospektiiv), mille k\u00e4igus anal\u00fc\u00fcsitakse Scrumi meeskonna toimimist ja sprindi korralduse parendamise v\u00f5imalusi.\u00a0Scrumi meeskonna omavaheline suhtlus ja k\u00f5igi tegevuste dokumenteerimine on \u00fclioluline sprindi \u00f5nnestumiseks, selleks kasutatakse erinevaid veebip\u00f5hiseid projektijuhtimise platvorme (Trello, Asana, Jira, Confluence).\r\n\r\n&nbsp;\r\n\r\nhttps:\/\/www.youtube.com\/watch?v=i-QyW8D3ei0\r\n\r\n&nbsp;\r\n\r\nhttps:\/\/www.youtube.com\/watch?v=Z9QbYZh1YXY\r\n\r\n&nbsp;\r\n\r\nhttps:\/\/www.youtube.com\/watch?v=9TycLR0TqFA\r\n\r\n[h5p id=\"1\"]\r\n<h3>R\u00fchmat\u00f6\u00f6\u00fclesanne<\/h3>\r\n<ol>\r\n \t<li>Moodustage 3-4 liikmeline tiim<\/li>\r\n \t<li>Tiimi \u00fclesandeks on kavandada sprint teie kooli kodulehe kujunduse ja sisu uuendamiseks.<\/li>\r\n \t<li>Tehke Trello keskkonnas kasutajakontod ja jagage tiimiliikmete vahel \u00fclesanded esimese sprindiga seoses: kooli kodulehe visuaalne kujundus, kasutajaliidese struktuur men\u00fc\u00fcd, sisu (sh seadusega n\u00f5utud info ja piirangud seoses isikuandmete kaitsega), veebilehe kasutajate rollid ja \u00f5igused, heade eeskujude leidmine jne.<\/li>\r\n \t<li>M\u00e4ngige l\u00e4bi mini-sprint, mille raames iga tiimiliige saab v\u00e4hemalt \u00fche \u00fclesande ja selle ka \u00e4ra teeb. Seej\u00e4rel viige l\u00e4bi sprindi kokkuv\u00f5te, pannes kirja sprindi tulemusena tehtud asjad.<\/li>\r\n \t<li>Dokumenteerige sprindi kokkuv\u00f5te ja tagasivaade, esitage see teisele tiimile hindamiseks ja hinnake ise teise tiimi kokkuv\u00f5tet sprindist.<\/li>\r\n<\/ol>\r\n<h3>Kasutatud allikad:<\/h3>\r\nhttps:\/\/eopearhiiv.edu.ee\/e-kursused\/eucip\/juhtimine\/521_kuidas_on_omavahel_seotud_aeg_kulud_ja_kvaliteet.html)","rendered":"<p>Selles peat\u00fckis \u00f5pid:<\/p>\n<ul>\n<li>tundma tarkvara kvaliteedi m\u00f5istet<\/li>\n<li>kirjeldama tarkvaraarenduse protsessi eeldusi ja etappe<\/li>\n<li>v\u00f5rdlema tarkvaraarenduse protsessi koskmudelit ja agiilset mudelit<\/li>\n<li>osalema tarkvara arendustiimi koost\u00f6\u00f6s projektijuhtimiskeskkonnas<\/li>\n<\/ul>\n<h2>Kvaliteedi m\u00f5iste<\/h2>\n<p>Kuigi k\u00f5igil on mingi ettekujutus, mille poolest erineb kvaliteetne toode mittekvaliteetsest, on l\u00e4hemal vaatlusel tegemist v\u00e4ga keerulise m\u00f5istega. \u00dchelt poolt seostub toote v\u00f5i teenuse kvaliteet selle v\u00e4\u00e4rtusega. Seega oleks lihtne j\u00e4reldada, et kallim auto, arvuti v\u00f5i maja on alati kvaliteetsem kui odav, aga see pole alati t\u00f5si.<\/p>\n<p>Keskajal ja enne seda tegid kvaliteetseid relvi, ehteid, laevu ja ehitisi oma ala meistrid. Iga ese oli unikaalne ja iga meistri eesm\u00e4rgiks oli s\u00e4ilitada oma maine, mist\u00f5ttu meistri poolt oma loomingule j\u00e4etud tunnusm\u00e4rk oli justkui kvaliteedi garantiiks. Uusajal t\u00f5i t\u00f6\u00f6stuslik p\u00f6\u00f6re kaasa masstootmise, kus \u00fchesarnased tooted valmisid sadade t\u00f6\u00f6tajate panuse tulemusena keerukal tootmisliinil. Masstoodetud kaupade puhul ei suuda keegi kontrollida iga \u00fcksiku toote kvaliteeti v\u00f5i uskuda, et \u00fchest tehasest tulevad alati paremad tooted kui teisest, mitte niiv\u00f5rd tuntud\/tunnustatud mainega tootjalt. Tehastes hakati kontrollima toodete kvaliteeti pigem pisteliselt, n\u00e4iteks testides p\u00f5hjalikumalt iga sajandat v\u00f5i tuhandendat toodet ja otsides neist t\u00fc\u00fcpilisi vigu (sellega tegelesid eraldi tehnilise kontrolli spetsialistid). Viimastel aastak\u00fcmnetel on v\u00f5itnud populaarsust hoopis ettev\u00f5tte enda sisemiste protsesside, mitte \u00fcksikute toodete kvaliteedi hindamine. N\u00e4iteks <a href=\"https:\/\/fractory.com\/et\/5-iso-standardit-toostuses\/\">ISO 9001<\/a> kvaliteeditunnistuse saab ettev\u00f5te, mis suudab t\u00f5estada, et ta pidevalt parendab oma teenuseid kliendikeskselt, firmas toimib eesm\u00e4rgikeskne ja inimesi kaasav juhtimine, t\u00f5endusp\u00f5hine otsustamine ja t\u00f6\u00f6tajate pidev koolitamine. Sellises ettev\u00f5ttes on suure t\u00f5en\u00e4osusega ka k\u00f5ik tooted ja teenused hea kvaliteediga. Nagu n\u00e4ha, on l\u00e4bi ajaloo kujunenud erinevaid l\u00e4henemisi toodete ja teenuste kvaliteedi hindamisele.<\/p>\n<p>\u00dcldiselt t\u00e4hendab mingi toote v\u00f5i teenuse (n\u00e4iteks nutirakenduse) kvaliteet vastavust eelnevalt kliendi ja arendaja vahelises lepingus kirjapandud n\u00f5uetele ehk skoobile. Tarkvara anal\u00fc\u00fcsi protsess keskendubki taoliste n\u00f5uete s\u00f5nastamisele ja kliendiga l\u00e4bir\u00e4\u00e4kimisele, millest edaspidi juhenduvad nii tarkvara arendajad kui ka testijad. Paraku soovivad kliendid kvaliteetset toodet, millel on v\u00f5imalikult palju funktsionaalsusi ja seda veel v\u00f5imalikult odavalt ja kiiresti. Anal\u00fc\u00fctiku kohuseks on m\u00f5ista ja kliendile selgitada, et neid k\u00f5iki korraga ei saa ja tuleb otsida sobivat tasakaalu <a href=\"https:\/\/en.wikipedia.org\/wiki\/Project_management_triangle\">projektijuhtimise kolmnurgas<\/a>.<\/p>\n<div id=\"h5p-15\">\n<div class=\"h5p-iframe-wrapper\"><iframe id=\"h5p-iframe-15\" class=\"h5p-iframe\" data-content-id=\"15\" style=\"height:1px\" src=\"about:blank\" frameBorder=\"0\" scrolling=\"no\" title=\"Kvaliteedikolmnurk\"><\/iframe><\/div>\n<\/div>\n<p>Tavaliselt on lihtsamad ja universaalsemat sorti arendusn\u00f5uded seotud tarkvara \u00fchilduvusega (nt nutirakendus toimib nii IOS kui Android platvormil, uue ja vana nutiseadme peal), j\u00f5udluse ja t\u00f6\u00f6kindlusega (ei esine t\u00f5rkeid ka suure koormuse v\u00f5i rumalate kasutajate puhul) v\u00f5i turvalisusega (pahatahtlikud r\u00fcndajad ei p\u00e4\u00e4se kasutaja andmetele ligi). Samas on suurem osa arendusn\u00f5udeid siiski otseselt seotud tarkvara funktsionaalsustega ja nende v\u00e4ljaselgitamine ongi anal\u00fc\u00fctiku \u00fclesanne.<\/p>\n<p>T\u00e4nap\u00e4eval \u00fcha enam suuri tehnoloogiaettev\u00f5tteid (Eestis nt Telia ja Elisa) oma kvaliteedijuhtimise protsessi \u00fcldisele parendamisele ja on taotlenud <a href=\"https:\/\/fractory.com\/et\/5-iso-standardit-toostuses\/\">ISO 9001<\/a> tunnistuse. Sel juhul v\u00f5etakse teenuse kvaliteedi hindamisel arvesse arendusprotsessi kavandamist, juhtimist, j\u00e4lgimist ja dokumenteerimist \u00fcle k\u00f5igi arendusprojektide.<\/p>\n<h2>Tarkvaraarenduse protsess<\/h2>\n<p>Majade ehitamise protsess on Eestis suhteliselt rangelt reguleeritud ja koosneb paljudest sammudest, mida saab teostada ainult siis kui eelmine samm on l\u00f5petatud. N\u00e4iteks oma kodumaja ehitama asudes peab esmalt taotlema kohalikust linna- v\u00f5i vallavalitsusest projekteerimistingimused, seej\u00e4rel tellitakse arhitektilt nendele tingimustele vastav ehitusprojekt. Valminud ehitusprojekti p\u00f5hjal v\u00e4ljastab omavalitsus ehitusloa ja alles siis v\u00f5ib ehitama asuda. Ehitamisprotsessi ja valminud maja vastavust n\u00f5uetele ja projektile j\u00e4lgib pidevalt ehitusj\u00e4relvalve eest vastutav firma v\u00f5i spetsialist. Kui l\u00f5puks on valminud maja vastavust k\u00f5igile n\u00f5uetele kontrollinud nii omavalitsus kui p\u00e4\u00e4steamet, siis v\u00e4ljastatakse kasutusluba ja v\u00f5ib sisse kolida.<\/p>\n<p>Sarnaselt majaehitusega toimis veel m\u00f5ne aastak\u00fcmne eest ka tarkvaraarendus. Esmalt kehtestati projekteerimistingimused, siis koostas insenerib\u00fcroo tarkvara-arendusplaani ja pani selles paika arendusprotsessi etapid ja hindamiskriteeriumid. Teise arendusetapi juurde enne ei asutud kui esimene oli kontrollitud ja n\u00f5uetele vastavaks kuulutatud. Sellisel viisil v\u00f5ttis tarkvaraarendus suhteliselt palju aega ning suuremahulisemaks ja keerukamaks muutuvate infos\u00fcsteemide l\u00e4htekoodist oli \u00fcha raskem vigu \u00fcles leida. Ka kasutajad polnud rahul sellisel moel arendatud tarkvaraga, sest neid arendusprotsessi ei kaasatud.<\/p>\n<p>Sellist traditsioonilist l\u00e4henemist tarkvaraarendusele nimetatakse koskmudeliks (i.k. <em>waterfall model<\/em>), kuna see visuaalselt meenutab ka n\u00e4iteks Tallinnas Kosmose kino ees paiknevat purskkaevu v\u00f5i kuulsat Trevi purskkaevu Roomas, milles vesi valgub kolmandasse basseini alles siis kui esimene ja teine t\u00e4is saanud on. Traditsioonilises koskmudelil p\u00f5hinevas tarkvaraarendusprotsessis ei p\u00f6\u00f6rdutud tagasi n\u00f5uete muutmise juurde sageli ka siis kui programmeerimise v\u00f5i testimise etapis leiti n\u00f5uete osas probleeme.<\/p>\n<p>10-15 aastat tagasi hakkasid v\u00e4ikesed tarkvarafirmad kasutama uudseid l\u00e4henemisi tarkvara-arendusele, mis v\u00f5imaldavad juba esimeses arendusetapis kasutajatele loodava s\u00fcsteemi esialgset protot\u00fc\u00fcpi tutvustada ning seel\u00e4bi kasutajatelt tagasisidet ja arendusettepanekuid koguda. Selliseid tarkvara-arendusmeetodeid nimetatakse agiilseteks ehk v\u00e4ledateks (i.k. <em>agile development<\/em>). Enamus v\u00e4lemeetodeid koosneb \u00fcldjuhul intensiivsetest arendusts\u00fcklitest. Iga ts\u00fckkel ehk sprint kestab vaid 1-2 n\u00e4dalat, sel on oma kitsas eesm\u00e4rk (rakenduse j\u00e4rgmise versiooni v\u00e4ljalase) ja selles l\u00e4bitakse kiirendatult nii planeerimise, disaini, arendus kui testimise etapp. Eesm\u00e4rgiks on anda v\u00f5imalikult kiiresti kasutajatele katsetamiseks minimaalsete v\u00f5imalustega protot\u00fc\u00fcp (i.k. <em>Minimal Viable Product<\/em>, MVP).<\/p>\n<div id=\"h5p-16\">\n<div class=\"h5p-iframe-wrapper\"><iframe id=\"h5p-iframe-16\" class=\"h5p-iframe\" data-content-id=\"16\" style=\"height:1px\" src=\"about:blank\" frameBorder=\"0\" scrolling=\"no\" title=\"Agiilne\"><\/iframe><\/div>\n<\/div>\n<p>Lisalugemist: uuri l\u00e4hemalt, kuidas toimib <a href=\"https:\/\/codeborne.com\/et\/2015\/09\/15\/agiilne-tarkvaraarendus.html\">agiilne arendus XP meetodil Eesti tarkvarafirmas Codeborn<\/a>.<\/p>\n<h3>N\u00e4ide v\u00e4learenduse kohta: Scrum<\/h3>\n<p>Scrum on \u00fcks populaarsematest v\u00e4learendusmeetodeist Eesti tarkvaraarenduse maastikul. Scrumi meeskonna t\u00f6\u00f6d juhib Scrum Master, lisaks arendajatele, disainerile ja anal\u00fc\u00fctikule on tiimi kaasatud ka tooteomanik (kes v\u00f5ib olla tellija esindaja). Scrumi sprindi alguses pannakse paika sprindi eesm\u00e4rk ja kava, mille p\u00f5hjal s\u00f5nastatakse sprindi konkreetsed \u00fclesanded (sprindi skoop, mis on v\u00e4ike osa toote skoobist). Sprindi k\u00e4ivitudes tehakse igal hommikul kiir\u00fclevaade erinevate tiimiliikmete poolt eile tehtud asjadest ja t\u00e4nastest plaanidest. Sprint l\u00f5peb kui k\u00f5ik skoobis kavandatu on valmis ja kokkuv\u00f5te tehtud. Tavaliselt tehakse enne j\u00e4rgmise sprindi kavandamist veel ka tagasivaade m\u00f6\u00f6dunud sprindile (retrospektiiv), mille k\u00e4igus anal\u00fc\u00fcsitakse Scrumi meeskonna toimimist ja sprindi korralduse parendamise v\u00f5imalusi.\u00a0Scrumi meeskonna omavaheline suhtlus ja k\u00f5igi tegevuste dokumenteerimine on \u00fclioluline sprindi \u00f5nnestumiseks, selleks kasutatakse erinevaid veebip\u00f5hiseid projektijuhtimise platvorme (Trello, Asana, Jira, Confluence).<\/p>\n<p>&nbsp;<\/p>\n<p><iframe loading=\"lazy\" id=\"oembed-1\" title=\"Software Development Lifecycle in 9 minutes!\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/i-QyW8D3ei0?feature=oembed&#38;rel=0\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<p>&nbsp;<\/p>\n<p><iframe loading=\"lazy\" id=\"oembed-2\" title=\"What is Agile?\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/Z9QbYZh1YXY?feature=oembed&#38;rel=0\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<p>&nbsp;<\/p>\n<p><iframe loading=\"lazy\" id=\"oembed-3\" title=\"Introduction to Scrum - 7 Minutes\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/9TycLR0TqFA?feature=oembed&#38;rel=0\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<div id=\"h5p-1\">\n<div class=\"h5p-iframe-wrapper\"><iframe id=\"h5p-iframe-1\" class=\"h5p-iframe\" data-content-id=\"1\" style=\"height:1px\" src=\"about:blank\" frameBorder=\"0\" scrolling=\"no\" title=\"Projekti komponendid\"><\/iframe><\/div>\n<\/div>\n<h3>R\u00fchmat\u00f6\u00f6\u00fclesanne<\/h3>\n<ol>\n<li>Moodustage 3-4 liikmeline tiim<\/li>\n<li>Tiimi \u00fclesandeks on kavandada sprint teie kooli kodulehe kujunduse ja sisu uuendamiseks.<\/li>\n<li>Tehke Trello keskkonnas kasutajakontod ja jagage tiimiliikmete vahel \u00fclesanded esimese sprindiga seoses: kooli kodulehe visuaalne kujundus, kasutajaliidese struktuur men\u00fc\u00fcd, sisu (sh seadusega n\u00f5utud info ja piirangud seoses isikuandmete kaitsega), veebilehe kasutajate rollid ja \u00f5igused, heade eeskujude leidmine jne.<\/li>\n<li>M\u00e4ngige l\u00e4bi mini-sprint, mille raames iga tiimiliige saab v\u00e4hemalt \u00fche \u00fclesande ja selle ka \u00e4ra teeb. Seej\u00e4rel viige l\u00e4bi sprindi kokkuv\u00f5te, pannes kirja sprindi tulemusena tehtud asjad.<\/li>\n<li>Dokumenteerige sprindi kokkuv\u00f5te ja tagasivaade, esitage see teisele tiimile hindamiseks ja hinnake ise teise tiimi kokkuv\u00f5tet sprindist.<\/li>\n<\/ol>\n<h3>Kasutatud allikad:<\/h3>\n<p>https:\/\/eopearhiiv.edu.ee\/e-kursused\/eucip\/juhtimine\/521_kuidas_on_omavahel_seotud_aeg_kulud_ja_kvaliteet.html)<\/p>\n","protected":false},"author":26,"menu_order":1,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[47],"contributor":[],"license":[],"class_list":["post-5","chapter","type-chapter","status-publish","hentry","chapter-type-standard"],"part":3,"_links":{"self":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapters\/5","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/wp\/v2\/users\/26"}],"version-history":[{"count":48,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapters\/5\/revisions"}],"predecessor-version":[{"id":272,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapters\/5\/revisions\/272"}],"part":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapters\/5\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/wp\/v2\/media?parent=5"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/pressbooks\/v2\/chapter-type?post=5"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/wp\/v2\/contributor?post=5"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/web.htk.tlu.ee\/digitaru\/testimine\/wp-json\/wp\/v2\/license?post=5"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}