Väledad tarkvaraarenduse mudelid: Difference between revisions
(→Scrum) |
No edit summary |
||
(35 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
== Sissejuhatus == | == Sissejuhatus == | ||
Välearendus on kiire tarkvaraarendus, kus kasutatakse agiilseid metoodikaid. Agiilsete metoodikate väljatöötamine sai alguse 1990. aastatel, kui tarkvaraarendajad mõistsid, et traditsioonilised tarkvaraarenduse meetodid paljude projektide jaoks ei sobi. | Välearendus on kiire tarkvaraarendus, kus kasutatakse agiilseid metoodikaid. Agiilsete metoodikate väljatöötamine sai alguse 1990. aastatel, kui tarkvaraarendajad mõistsid, et traditsioonilised tarkvaraarenduse meetodid paljude projektide jaoks ei sobi. | ||
Traditsioonilised tarkvaraarenduse meetodid (nt kosemudel ja spiraalmeetod) panevad rõhku hoolikale projektiplaneerimisele, rohkele dokumentatsioonile ja süsteemidisainile enne arendustöö algust. Kuigi neid meetodeid on aja jooksul märkimisväärselt edasi arendatud, pole muudatused saanud jagu traditsiooniliste mudelite peamistest nõrkustest, milleks on lõhkised eelarved, võimetus ajagraafikus püsida ja vigased tooted – ühesõnaga ebaõnnestunud projektid. Samuti pole | Traditsioonilised tarkvaraarenduse meetodid (nt kosemudel ja spiraalmeetod) panevad rõhku hoolikale projektiplaneerimisele, rohkele dokumentatsioonile ja süsteemidisainile enne arendustöö algust. Kuigi neid meetodeid on aja jooksul märkimisväärselt edasi arendatud, pole muudatused saanud jagu traditsiooniliste mudelite peamistest nõrkustest, milleks on lõhkised eelarved, võimetus ajagraafikus püsida ja vigased tooted – ühesõnaga ebaõnnestunud projektid. Samuti pole edasiarendused oluliselt tõstnud tootlikkust, usaldusväärsust ega mudelite lihtsust.<ref name="IssuesChallenges">"Issues and Challenges of Agile Software Development with Scrum", Juyun Cho, https://iacis.org/iis/2008/S2008_950.pdf</ref> | ||
Välearenduse puhul eeldatakse, et projektides tuleb muutusi ette niikuinii ning neid tuleb hallata, mitte vältida | Välearenduse puhul eeldatakse, et projektides tuleb muutusi ette niikuinii ning neid tuleb hallata, mitte vältida <ref>"Extreme Programming Explained", Kent Beck, 2000, Reading, MA: Addison Wesley</ref>. Välearendus seab fookusesse inimesed, kes tarkvaraarendust teostavad ja kuidas nad koos töötavad. Lahendused valmivad iseorganiseeruvate ja polüfunktsionaalsete meeskondade koostöö tulemusena <ref>"Agile 101", https://www.agilealliance.org/agile101/</ref>. Lähemalt võrreldakse traditsioonilist ja väledat tarkvaraarendust alljärgnevas tabelis <ref name="Kivimaa">"Agiilsete tarkvaraarendusmeetodite võrdlus", Kristen Kivimaa, 2014, http://www.cs.tlu.ee/teemaderegister/get_file.php?id=326</ref>. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 53: | Line 50: | ||
|} | |} | ||
Esmalt käsitleb käesolev artikkel välearendust üldisemalt ning seejärel tutvustab lähemalt kolme tuntumat agiilset metoodikat: Scrum’i, Kanban’i ja | Esmalt käsitleb käesolev artikkel välearendust üldisemalt ning seejärel tutvustab lähemalt kolme tuntumat agiilset metoodikat: Scrum’i, Kanban’i ja ekstreemprogrammeerimist, seades fookuse nende professionaalsetele ja sotsiaalsetele aspektidele. | ||
== Välearenduse põhimõtted ja -printsiibid == | == Välearenduse põhimõtted ja -printsiibid == | ||
2001. aastal sõnastas grupp tarkvaraarendajaid välearenduse põhimõtted ja -printsiibid, millele agiilsed metoodikad peaksid toetuma | 2001. aastal sõnastas grupp tarkvaraarendajaid välearenduse põhimõtted ja -printsiibid, millele agiilsed metoodikad peaksid toetuma. <ref name="IssuesChallenges"></ref> | ||
=== Agiilse tarkvaraarenduse põhimõtted === | === Agiilse tarkvaraarenduse põhimõtted === | ||
Tarkvara luues hinnatakse alljärgnevas tabelis vasakpoolses tulbas olevaid tegureid kõrgemalt, teadvustades samas ka parempoolse tulba tegurite väärtust | Tarkvara luues hinnatakse alljärgnevas tabelis vasakpoolses tulbas olevaid tegureid kõrgemalt, teadvustades samas ka parempoolse tulba tegurite väärtust <ref>"Agiilse tarkvaraarenduse manifest", 2001, https://agilemanifesto.org/iso/et/manifesto.html (06.05.2020)</ref>. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 77: | Line 74: | ||
=== Agiilse tarkvaraarenduse põhiprintsiibid === | === Agiilse tarkvaraarenduse põhiprintsiibid === | ||
Agiilse tarkvaraarenduse 12 põhiprintsiipi on järgmised | Agiilse tarkvaraarenduse 12 põhiprintsiipi on järgmised <ref>"Agiilse tarkvaraarenduse manifesti põhimõtted", 2001, https://agilemanifesto.org/iso/et/principles.html (06.05.2020)</ref>: | ||
* Kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti. | * Kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti. | ||
Line 100: | Line 97: | ||
=== Ajalugu === | === Ajalugu === | ||
Scrumi esitleti avalikkusele esmakordselt aastal 1995 Jeff | Scrumi esitleti avalikkusele esmakordselt aastal 1995 Jeff Sutherlandi ja Ken Schwaberi poolt. Samas on mudeli autorid öelnud, et tegemist pole mingi enneolematu lähenemisega – sarnaseid praktikaid on kasutatud ka varem. Nii Sutherlandi kui Schwaberi jaoks oli Scrumi lõplik mudel aastatepikkuse kogemuste ja õppimise tulemus. <ref name="ScrumDeskHistory">"The History of Scrum: How, when and WHY", https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/ (06.05.2020)</ref> | ||
Mudeli mõlemad autorid osalesid aastatel 1967-1975 Vietnami sõjas. Sellel perioodil oli riskide hindamine meestele igapäevaelu loomulikuks osaks ning mõjutas ilmselt nende mõttelaadi ka tulevikus. Pärast sõda asusid mõlemad tööle tarkvaraarenduses ning hoidsid teineteisega kontakti. | Mudeli mõlemad autorid osalesid aastatel 1967-1975 Vietnami sõjas. Sellel perioodil oli riskide hindamine meestele igapäevaelu loomulikuks osaks ning mõjutas ilmselt nende mõttelaadi ka tulevikus. Pärast sõda asusid mõlemad tööle tarkvaraarenduses ning hoidsid teineteisega kontakti. <ref name="ScrumDeskHistory"></ref> | ||
==== Ken Schwaber ==== | ==== Ken Schwaber ==== | ||
Ken Schwaber asutas pärast kümneaastast tarkvaraettevõttes töötamise kogemust 1985. aastal omaenda firma. Ta on öelnud, et ettevõttes töötamine tekitas temas palju stressi ning ta ei saanud aru, miks projektide õigeaegne ja edukas elluviimine ning inimeste meeskonnana tööle panemine oli niivõrd raske. Tollal lõppesid edukalt ligi 45% projektidest, mille kallal ta töötas. Inimestele ei meeldinud nende töö ja nad kippusid liikuma teistesse ettevõtetesse lootuses sealt midagi paremat eest leida. | Ken Schwaber asutas pärast kümneaastast tarkvaraettevõttes töötamise kogemust 1985. aastal omaenda firma. Ta on öelnud, et ettevõttes töötamine tekitas temas palju stressi ning ta ei saanud aru, miks projektide õigeaegne ja edukas elluviimine ning inimeste meeskonnana tööle panemine oli niivõrd raske. Tollal lõppesid edukalt ligi 45% projektidest, mille kallal ta töötas. Inimestele ei meeldinud nende töö ja nad kippusid liikuma teistesse ettevõtetesse lootuses sealt midagi paremat eest leida. <ref name="ScrumDeskHistory"></ref> | ||
Schwaber oli kosemudeli entusiast ning üritas seda oma projektides edutult rakendada. See pani teda mõistma, et tarkvaratööstus vajab muudatust. Ta on hiljem kirjutanud, et kosemudeli puhul eeldatakse, et tarkvaraarendus on protsessina lihtsasti hoomatav ning ootamatute tagajärgede ja probleemideta, kuid nii see tegelikkuses ei ole – tarkvaraarendus on paljudel põhjustel väga etteaimamatu. | Schwaber oli kosemudeli entusiast ning üritas seda oma projektides edutult rakendada. See pani teda mõistma, et tarkvaratööstus vajab muudatust. Ta on hiljem kirjutanud, et kosemudeli puhul eeldatakse, et tarkvaraarendus on protsessina lihtsasti hoomatav ning ootamatute tagajärgede ja probleemideta, kuid nii see tegelikkuses ei ole – tarkvaraarendus on paljudel põhjustel väga etteaimamatu. <ref name="ScrumDeskHistory"></ref> | ||
==== Jeff Sutherland ==== | ==== Jeff Sutherland ==== | ||
Jeff Sutherland sai 1986. aastal ettevõttes Saddlebrook Corporation vastutavaks sularahaautomaatidega tegeleva osakonna eest. Seal seisis ta silmitsi traditsioonilise projektihalduse probleemidega, kus ei suudetud tähtaegadest kinni pidada ning kasutajate rahulolu ja kvaliteet olid madalad. Sutherland tahtis nendele probleemidele lahenduse leida ja seda ta ka tegi. Ta muutis sularahaautomaatide osakonna ettevõttes kõige probleemsemast ja vähem kasumlikumast üksusest kuue kuuga kõige edukamaks. | Jeff Sutherland sai 1986. aastal ettevõttes Saddlebrook Corporation vastutavaks sularahaautomaatidega tegeleva osakonna eest. Seal seisis ta silmitsi traditsioonilise projektihalduse probleemidega, kus ei suudetud tähtaegadest kinni pidada ning kasutajate rahulolu ja kvaliteet olid madalad. Sutherland tahtis nendele probleemidele lahenduse leida ja seda ta ka tegi. Ta muutis sularahaautomaatide osakonna ettevõttes kõige probleemsemast ja vähem kasumlikumast üksusest kuue kuuga kõige edukamaks. <ref name="ScrumDeskHistory"></ref> | ||
Sutherland õpetas oma meeskonda protsessi paremini juhtima, võrreldes seda lennuki maandamisega. Piloodil tuleb pikkamisi allapoole laskuda, täites ülesande ülesande haaval ja maanduda lõpuks edukalt lennurajale. Selle protsessi juures pidas ta oluliseks kolme aspekti: meeskonnaliikmete töö tulemused peavad olema kõigi jaoks nähtavad, iga liige peab vastutama talle määratud ülesannete eest ning meeskond peab suutma oma tööd ise ümber korraldada. See kogemus näitas | Sutherland õpetas oma meeskonda protsessi paremini juhtima, võrreldes seda lennuki maandamisega. Piloodil tuleb pikkamisi allapoole laskuda, täites ülesande ülesande haaval ja maanduda lõpuks edukalt lennurajale. Selle protsessi juures pidas ta oluliseks kolme aspekti: meeskonnaliikmete töö tulemused peavad olema kõigi jaoks nähtavad, iga liige peab vastutama talle määratud ülesannete eest ning meeskond peab suutma oma tööd ise ümber korraldada. See kogemus näitas Sutherlandile, et on olemas vajadus uue arendusmetoodika järgi, mis sobiks paremini nii arendajatele kui ka klientidele ning aitaks projektidel õigeaegselt valmis saada. <ref name="ScrumDeskHistory"></ref> | ||
Nendele kogemustele tuginedes töötasid Schwaber ja Sutherland 4-5 aastat välja uut arendusmudelit, mis oleks paindlikum, annaks liikmetele protsessi üle rohkem kontrolli, aitaks kaasa loomingulisusele ning võimaldaks paremini hallata riske ja kulutusi. | Nendele kogemustele tuginedes töötasid Schwaber ja Sutherland 4-5 aastat välja uut arendusmudelit, mis oleks paindlikum, annaks liikmetele protsessi üle rohkem kontrolli, aitaks kaasa loomingulisusele ning võimaldaks paremini hallata riske ja kulutusi. <ref name="ScrumDeskHistory"></ref> | ||
==== The New New Product Development Game ==== | ==== The New New Product Development Game ==== | ||
Ülimalt oluliseks ideede allikaks uue tarkvaraarendusmetoodika kujundamisel oli 1986. aastal Hirotaka Takeuchi ja Ikujiro Nonaka poolt avaldatud artikkel ''„The New New Product Development Game“''. See käsitles mõnes Jaapani ja USA firmas kasutatavat uudset ja holistilist tootearenduse lähenemist, mis muutis protsessi kiiremaks ja paindlikumaks ning aitas ettevõttes muutuseid läbi suruda. Need praktikad pärinesid tollastelt edukatelt firmadelt nagu Xerox, Canon, Honda ja Hewlett-Packard. Tootearenduse meeskonna tegevust võrdlesid Takeuchi ja Nonaka ragbitiimiga, mis liikus ühtse üksusena lõppeesmärgi saavutamiseks edasi, tegutsedes koos tekkinud takistuste ületamisega. Samast artiklist pärineb ka Scrumi nimetus – ragbis nimetatakse scrumiks palli mängupanemise momenti, kus meeskondade ründajad palli oma tiimile võitmiseks rüselevad. | [[File:Scrum Rugby.JPG|250px|thumb|right|Scrum ragbis]] | ||
Ülimalt oluliseks ideede allikaks uue tarkvaraarendusmetoodika kujundamisel oli 1986. aastal Hirotaka Takeuchi ja Ikujiro Nonaka poolt avaldatud artikkel ''„The New New Product Development Game“''. See käsitles mõnes Jaapani ja USA firmas kasutatavat uudset ja holistilist tootearenduse lähenemist, mis muutis protsessi kiiremaks ja paindlikumaks ning aitas ettevõttes muutuseid läbi suruda. Need praktikad pärinesid tollastelt edukatelt firmadelt nagu [//en.wikipedia.org/wiki/Xerox Xerox], [//en.wikipedia.org/wiki/Canon_Inc. Canon], [//en.wikipedia.org/wiki/Honda Honda] ja [//en.wikipedia.org/wiki/Hewlett-Packard Hewlett-Packard]. Tootearenduse meeskonna tegevust võrdlesid Takeuchi ja Nonaka ragbitiimiga, mis liikus ühtse üksusena lõppeesmärgi saavutamiseks edasi, tegutsedes koos tekkinud takistuste ületamisega <ref name="TakeuchiNonaka">"New New Product Development Game", Hirotaka Takeuchi, Ikujiro Nonaka, 1986, Harvard Business Review, https://hbsp.harvard.edu/product/86116-PDF-ENG</ref>. Samast artiklist pärineb ka Scrumi nimetus – ragbis nimetatakse scrumiks palli mängupanemise momenti, kus meeskondade ründajad palli oma tiimile võitmiseks rüselevad <ref>"Scrum", https://www.lexico.com/definition/scrum (06.05.2020)</ref>. | |||
Takeuchi ja Nonaka tõid oma artiklis näite uue auto väljatöötamisest | Takeuchi ja Nonaka tõid oma artiklis näite uue auto väljatöötamisest Toyotas. Töötajad said korralduse valmistada auto, mille kütusekulu oleks varasematest kaks korda väiksem ja saada auto valmis kaks korda kiiremini kui senised mudelid. Traditsioonilisi meetodeid kasutades olnuks selle ülesande täitmine võimatu, kuid arendusmeeskond suurendas koostööd ja muutus iseorganiseeruvaks, et kogu protsessi kiirendada. <ref name="TakeuchiNonaka"></ref> | ||
Sutherland leidis, et samasugust lähenemist tuleb rakendada ka tarkvaraarenduses. Eriti oluliseks pidas ta meeskondade autonoomsust, üksteiselt õppimist ja ühist eesmärkide poole liikumist, toetudes meeskonnaliikmete kirglikkusele. 1994. aastal alustas | Sutherland leidis, et samasugust lähenemist tuleb rakendada ka tarkvaraarenduses. Eriti oluliseks pidas ta meeskondade autonoomsust, üksteiselt õppimist ja ühist eesmärkide poole liikumist, toetudes meeskonnaliikmete kirglikkusele. 1994. aastal alustas Sutherlandi osavõtul tööd esimene Scrum tarkvaraarendustiim. Järgmisel aastal avaldasid Sutherland ja Schwaber Scrumi tutvustava artikli. Mõlemad olid tegevad ka välearenduse põhimõtete (''„Manifesto for Agile Software Development“'') kirjapanekul 2001. aastal <ref name="ScrumDeskHistory"></ref> | ||
. Kuigi Sutherland ja Schwaber sõnastasid esimesena Scrumi raamistiku tarkvaraarenduse kontekstis, peavad paljud Takeuchi ja Nonaka mõju sedavõrd oluliseks, et nimetavad neid Scrumi loojateks ka tarkvaramaailmas <ref>"The Role of the Product Owner in Scrum-comparison between Theory and Practices", Hrafnhildur Sif Sverrisdottir, Helgi Thor Ingason, Haukur Ingi Jonasson, 2014, https://www.sciencedirect.com/science/article/pii/S1877042814021211</ref><ref>"Why Scrum works ", Lene Pries-Heje, Jan Pries-Heje, 2011, https://www.researchgate.net/publication/224256381_Why_Scrum_Works_A_Case_Study_from_an_Agile_Distributed_Project_in_Denmark_and_India</ref>. | |||
=== Sisu === | === Sisu === | ||
Line 130: | Line 130: | ||
==== Võtmeväärtused ==== | ==== Võtmeväärtused ==== | ||
Scrum rajaneb empiirikale, mis tähendab, et teadmised tulenevad kogemustest ja otsuste langetamine teadaolevatest faktidest. Mudel on iteratiivse ja järk-järgulise lähenemisega, tehes nii projektiga seotud prognoositavuse ja riskide haldamise lihtsamaks. | Scrum rajaneb empiirikale, mis tähendab, et teadmised tulenevad kogemustest ja otsuste langetamine teadaolevatest faktidest. Mudel on iteratiivse ja järk-järgulise lähenemisega, tehes nii projektiga seotud prognoositavuse ja riskide haldamise lihtsamaks. <ref name="ScrumGuide">"The Scrum Guide", Ken Schwaber, Jeff Sutherland, 2016, https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf</ref> | ||
Scrum tugineb kolmele põhiväärtusele: | Scrum tugineb kolmele põhiväärtusele <ref name="ScrumGuide"></ref>: | ||
* läbipaistvus – protsessi olulised aspektid peavad olema kõigile meeskonna liikmetele nähtavad | * läbipaistvus – protsessi olulised aspektid peavad olema kõigile meeskonna liikmetele nähtavad | ||
* kontroll – vigade vältimiseks tuleb aeg-ajalt kontrollida tehtud töö vastavust soovitud eesmärgile | * kontroll – vigade vältimiseks tuleb aeg-ajalt kontrollida tehtud töö vastavust soovitud eesmärgile | ||
Line 139: | Line 139: | ||
==== Scrum meeskond ==== | ==== Scrum meeskond ==== | ||
Scrum meeskond koosneb tooteomanikust, arendusmeeskonnast ja Scrumi juhist (''Scrum Master''). Scrum meeskonnad on iseorganiseeruvad ja polüfunktsionaalsed. See tähendab, et meeskond ise otsustab, kuidas neile seatud ülesannet täita ning nad ei vaja töö teostamiseks abi teistelt väljaspool tiimi – kogu vajalik kompetents on meeskonnas endas olemas. <ref name="ScrumGuide"></ref> | |||
'''Tooteomanik''' on isik, kes vastutab nende ees, kes on toote tellinud. Tema ülesandeks on olla vahelüli kliendi ja arendusmeeskonna vahel. Ta peab tagama esialgse projekti rahastamise ning veenduma, et seda jätkuks terveks tootearendustsükliks. Tooteomanik esindab kõiki, kes on panustanud projekti ja selle tulemusse. Projekti alguses kogub ta esialgsed nõuded ning paneb need tööde nimekirja (''Product Backlog''). Tema otsustab, millised nõuded on tähtsamad ning millises iteratsioonis neid arendama peaks hakkama. Projekti käigus kontrollib tooteomanik projekti edenemist ning kliendi vajaduste täitmist. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref><ref name="Rossberg">"Pro Visual Studio Team System Application Lifecycle Management", Joachim Rossberg, 2008, Apress</ref> | |||
''' | '''Arendusmeeskond''' vastutab toote arendamise eest. Meeskonnas pole igal liikmel kindlat rolli – nad peavad tagama selle, et tiimis oleks olemas töö teostamiseks kõik vajalikud oskused ja inimesed. Arendusmeeskond peab olema piisavalt väike, et protsessi mitte kohmakaks muuta ning piisavalt suur, et vajalike tööde teostamisega õigeaegselt hakkama saada. Keskmiselt on meeskonnas aga seitse inimest. Tüüpiliselt on seal kaks-kolm programmeerijat, kaks-kolm testijat, üks analüütik/disainer ja üks dokumenteerija. Meeskond ise otsustab, milliste nõuete realiseerimisega iga iteratsiooni jooksul tegeletakse. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref><ref name="Rossberg"></ref> | ||
''' | '''Scrumi juht''' vastutab selle eest, et töö Scrum meeskonnas vastaks Scrum teooriale, praktikale ja reeglitele. Ta peab tagama, et kõik arendusmeeskonna liikmed, tooteomanik ning teised projekti kaasatud inimesed mõistavad arendusprotsessi. Kui tekivad konfliktid, siis peab Scrumi juht need lahendama ning tagama arendusmeeskonnale rahuliku töökeskkonna koos kõige vajalikuga. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref><ref name="Rossberg"></ref> | ||
==== Töövoog ==== | ==== Töövoog ==== | ||
[[File:Scrum Framework.png|400px|thumb|right|Scrum raamistiku mudel]] | [[File:Scrum Framework.png|400px|thumb|right|Scrum raamistiku mudel]] | ||
Scrumis toimub tarkvaraarendus iteratsioonides, mida nimetatakse sprintideks. Iga sprindi | Scrumis toimub tarkvaraarendus iteratsioonides, mida nimetatakse sprintideks. Iga sprindi lõpuks, mis kestavad 1-4 nädalat, loob arendusmeeskond tarkvarast potentsiaalselt valmis versiooni, mis töötab ning mida on testitud. Sprintide ajaline kestvus on üldiselt kogu tootearenduse protsessi jooksul sama. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref> | ||
Nõuded (''Sprint Backlog''), mida soovitakse realiseerida ühe sprindi jooksul, on kirja pandud toote tööde nimekirja (''Product Backlog''), kus on kõik tarkvara nõuded järjestatud nende tähtsuse järgi. Seda, milliseid toote osi sprindi jooksul arendama hakatakse, otsustatakse sprindi planeerimise (''Sprint Planning'') koosolekul. Sellel koosolekul teavitab tooteomanik arendusmeeskonda, milliseid toote osi peaks nad sprindi jooksul arendama hakkama ning seejärel määrab meeskond ära, milliseid neist saaksid nad teostada. Sprindi ajal ei ole kellelgi sprindi tööde nimekirja muuta lubatud. | Nõuded (''Sprint Backlog''), mida soovitakse realiseerida ühe sprindi jooksul, on kirja pandud toote tööde nimekirja (''Product Backlog''), kus on kõik tarkvara nõuded järjestatud nende tähtsuse järgi. Seda, milliseid toote osi sprindi jooksul arendama hakatakse, otsustatakse sprindi planeerimise (''Sprint Planning'') koosolekul. Sellel koosolekul teavitab tooteomanik arendusmeeskonda, milliseid toote osi peaks nad sprindi jooksul arendama hakkama ning seejärel määrab meeskond ära, milliseid neist saaksid nad teostada. Sprindi ajal ei ole kellelgi sprindi tööde nimekirja muuta lubatud. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref> | ||
Iga päev algab 15-minutilise arendusmeeskonna koosolekuga (''Daily Scrum'' või ''stand-up''), kus arutatakse, milliste nõuetega tegeleti eelmisel päeval ning millega tegeletakse eelseisval päeval. Iga arendusmeeskonna liige vastab järgmistele küsimustele: | Iga päev algab 15-minutilise arendusmeeskonna koosolekuga (''Daily Scrum'' või ''stand-up''), kus arutatakse, milliste nõuetega tegeleti eelmisel päeval ning millega tegeletakse eelseisval päeval <ref>"Agile Project Management with Scrum", Ken Schwaber, 2004, Microsoft Press, https://archive.org/details/agileprojectmana0000schw</ref>. Iga arendusmeeskonna liige vastab järgmistele küsimustele <ref name="ScrumGuide"></ref>: | ||
* Mida ma tegin eile, et aidata arendusmeeskonnal sprindi eesmärki (''Sprint Goal'') täita? | * Mida ma tegin eile, et aidata arendusmeeskonnal sprindi eesmärki (''Sprint Goal'') täita? | ||
* Mida ma teen täna, et aidata arendusmeeskonnal sprindi eesmärki täita? | * Mida ma teen täna, et aidata arendusmeeskonnal sprindi eesmärki täita? | ||
* Kas ma näen enda või arendusmeeskonna töös sprindi eesmärgi täitmisel takistusi? | * Kas ma näen enda või arendusmeeskonna töös sprindi eesmärgi täitmisel takistusi? | ||
Iga sprindi lõpus korraldatakse sprindi ülevaate koosolek (''Sprint Review''), kus tutvustatakse sprindi käigus tehtud töid, tekkinud probleeme ja tehakse vajadusel parandusi toote tööde nimekirja. Koosolekul osalevad Scrum meeskond ja toote tellija/huvirühmad. Kuuajaliste sprintide puhul on koosoleku pikkuseks umbes neli tundi, lühemate sprintide puhul vähem. Lisaks toimub pärast sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist ka sprindi retrospektiiv (''Sprint Retrospective''), mis on koosolek, mille käigus Scrum meeskond analüüsib enda tööd lõppenud sprindi jooksul ning otsustab, mida järgmises sprindis paremini teha. Kuuajalise sprindi puhul kestab retrospektiiv üldjuhul umbes kolm tundi, lühemate sprintide puhul vähem. | Iga sprindi lõpus korraldatakse sprindi ülevaate koosolek (''Sprint Review''), kus tutvustatakse sprindi käigus tehtud töid, tekkinud probleeme ja tehakse vajadusel parandusi toote tööde nimekirja. Koosolekul osalevad Scrum meeskond ja toote tellija/huvirühmad. Kuuajaliste sprintide puhul on koosoleku pikkuseks umbes neli tundi, lühemate sprintide puhul vähem. Lisaks toimub pärast sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist ka sprindi retrospektiiv (''Sprint Retrospective''), mis on koosolek, mille käigus Scrum meeskond analüüsib enda tööd lõppenud sprindi jooksul ning otsustab, mida järgmises sprindis paremini teha. Kuuajalise sprindi puhul kestab retrospektiiv üldjuhul umbes kolm tundi, lühemate sprintide puhul vähem. <ref name="ScrumGuide"></ref> | ||
=== Scrumi juurutamise sotsiaalsest mõjust === | === Scrumi juurutamise sotsiaalsest mõjust === | ||
Line 168: | Line 166: | ||
On avaldatud mitmeid teadusartikleid, milles kirjeldatakse Scrumi juurutamise mõju traditsioonilistes arendusmeeskondades. Juurutamisega seoses tuuakse välja nii positiivseid aspekte kui ka probleeme. | On avaldatud mitmeid teadusartikleid, milles kirjeldatakse Scrumi juurutamise mõju traditsioonilistes arendusmeeskondades. Juurutamisega seoses tuuakse välja nii positiivseid aspekte kui ka probleeme. | ||
Ei tasu eeldada, et agiilsete metoodikate juurutamiseks arendusmeeskonnas piisaks vaid meeskonnaliikmetele vastava metoodika tutvustamisest. Juurutamisprotsess nõuab muuhulgas olulisi muudatusi tööprotseduurides, tööriistades, sidekanalites, probleemilahendamise strateegiates, arendusmeeskonna liikmete rollides ja meeskonna sotsiaalses ülesehituses. Lisaks peavad muutustega kaasa minema ka teised tiimid ja osakonnad, juhtkond ning teised töötajad. Ühtlasi on välearenduse meeskonnad sotsiaalse loomuga, mistõttu vajab juurutamisprotsess muutuseid töötajatevahelises suhtluses ja koostööviisis. | Ei tasu eeldada, et agiilsete metoodikate juurutamiseks arendusmeeskonnas piisaks vaid meeskonnaliikmetele vastava metoodika tutvustamisest. Juurutamisprotsess nõuab muuhulgas olulisi muudatusi tööprotseduurides, tööriistades, sidekanalites, probleemilahendamise strateegiates, arendusmeeskonna liikmete rollides ja meeskonna sotsiaalses ülesehituses. Lisaks peavad muutustega kaasa minema ka teised tiimid ja osakonnad, juhtkond ning teised töötajad. Ühtlasi on välearenduse meeskonnad sotsiaalse loomuga, mistõttu vajab juurutamisprotsess muutuseid töötajatevahelises suhtluses ja koostööviisis. <ref name="EspinosaCuriel">"Analysis of the changes in communication and social interactions during the transformation of a traditional team into an agile team", Ismael Edrein Espinosa‐Curiel, Josefina Rodríguez‐Jacobo, Erika Vázquez‐Alfaro, José Alberto Fernández‐Zepeda, Daniel Fajardo‐Delgado, 2018, https://onlinelibrary.wiley.com/doi/abs/10.1002/smr.1946</ref> | ||
Mitmed teadlased on rõhutanud suhtluse olulisust välearenduses. See hõlmab nii ametlikku kui mitteametlikku, suulist ja kirjalikku suhtlust. Tähtis roll on siin välearenduse praktikatel: igapäevastel koosolekutel, retrospektiividel ja sellel, et tüüpiliselt paigutatakse meeskonnad füüsiliselt üksteisele lähedale. Lisaks tuuakse välja sotsiaalse vastastikmõju kasvu, mis avaldub nii meeskonda liitvates kui ka lõhkuvates tegevustes. Sageli kerkivad traditsioonilistes arendusmeeskondades Scrumi juurutamisel esile inimeste isiklikud ja nendevahelised sotsiaalsed probleemid, mis suhtlust ja sotsiaalset vastastikmõju mõjutavad. | Mitmed teadlased on rõhutanud suhtluse olulisust välearenduses. See hõlmab nii ametlikku kui mitteametlikku, suulist ja kirjalikku suhtlust. Tähtis roll on siin välearenduse praktikatel: igapäevastel koosolekutel, retrospektiividel ja sellel, et tüüpiliselt paigutatakse meeskonnad füüsiliselt üksteisele lähedale. Lisaks tuuakse välja sotsiaalse vastastikmõju kasvu, mis avaldub nii meeskonda liitvates kui ka lõhkuvates tegevustes. Sageli kerkivad traditsioonilistes arendusmeeskondades Scrumi juurutamisel esile inimeste isiklikud ja nendevahelised sotsiaalsed probleemid, mis suhtlust ja sotsiaalset vastastikmõju mõjutavad. <ref name="EspinosaCuriel"></ref><ref name="Rasnacis">"Adaptation of Agile Project Management Methodology for Project Team", Arturs Rasnacis, Solvita Bērziša, 2015, https://www.researchgate.net/publication/293194225_Adaptation_of_Agile_Project_Management_Methodology_for_Project_Team</ref><ref name="LawCharron">"Effects of Agile Practices on Social Factors", Amy Law, Raylene Charron, 2005, https://dl.acm.org/doi/pdf/10.1145/1082983.1083115</ref> | ||
Paljud arendajad ja meeskonnad toonitavad aga Scrumi positiivseid külgi. Scrum suurendab meeskonna ühtekuuluvustunnet ja aitab liikmetes tekitada tunnet, et nende tööl ja otsustel on kaalu. Samuti suurendab see koostööd, meeskonna motivatsiooni ja vastutust, mis viib omakorda meeskonna ühise arusaamani jagatud juhtimisest, eesmärkidest, kohustustest ja ajagraafikus püsimisest. | Paljud arendajad ja meeskonnad toonitavad aga Scrumi positiivseid külgi. Scrum suurendab meeskonna ühtekuuluvustunnet ja aitab liikmetes tekitada tunnet, et nende tööl ja otsustel on kaalu. Samuti suurendab see koostööd, meeskonna motivatsiooni ja vastutust, mis viib omakorda meeskonna ühise arusaamani jagatud juhtimisest, eesmärkidest, kohustustest ja ajagraafikus püsimisest. <ref name="EspinosaCuriel"></ref><ref name="LawCharron"></ref> | ||
=== Professionaalsed aspektid === | === Professionaalsed aspektid === | ||
Line 178: | Line 176: | ||
==== Vähem dokumentatsiooni ==== | ==== Vähem dokumentatsiooni ==== | ||
Scrum vähendab märkimisväärselt arendustöö käigus loodava dokumentatsiooni hulka. Agiilsete metoodikate juures väidetakse lausa, et kood ise peaks olema dokument. Agiilsete metoodikatega rohkem harjunud arendajad lisavad pigem kommentaare koodi. Paljud arendajad aga osutavad, et vähene dokumentatsioon teeb uutel arendajatel olemasolevate projektide mõistmise ja nendele muudatuste tegemise väga keeruliseks. | Scrum vähendab märkimisväärselt arendustöö käigus loodava dokumentatsiooni hulka. Agiilsete metoodikate juures väidetakse lausa, et kood ise peaks olema dokument. Agiilsete metoodikatega rohkem harjunud arendajad lisavad pigem kommentaare koodi. Paljud arendajad aga osutavad, et vähene dokumentatsioon teeb uutel arendajatel olemasolevate projektide mõistmise ja nendele muudatuste tegemise väga keeruliseks. <ref name="IssuesChallenges"></ref><ref name="LawCharron"></ref> | ||
Dokumentatsiooni vähendamise eesmärgiks on Scrumis arendusmeeskonna sees oskusteabe jagamine ja seeläbi selles osas kõigi liikmete võrdsena hoidmine. Kui aga seda õigesti ei tehta, võib sellest tekkida suur probleem. Näiteks, kui arendusmeeskonna peamine arendaja peaks töölt lahkuma, võib ettevõttel kuluda kuid tekkinud oskusteabe lünga täitmiseks. Praktikas on selliste situatsioonide täielik vältimine aga sisuliselt võimatu. | Dokumentatsiooni vähendamise eesmärgiks on Scrumis arendusmeeskonna sees oskusteabe jagamine ja seeläbi selles osas kõigi liikmete võrdsena hoidmine. Kui aga seda õigesti ei tehta, võib sellest tekkida suur probleem. Näiteks, kui arendusmeeskonna peamine arendaja peaks töölt lahkuma, võib ettevõttel kuluda kuid tekkinud oskusteabe lünga täitmiseks. Praktikas on selliste situatsioonide täielik vältimine aga sisuliselt võimatu. <ref name="IssuesChallenges"></ref> | ||
==== Koosolekud ==== | ==== Koosolekud ==== | ||
Samuti tuleb Scrumis pidada kinni koosolekute reeglitest ja headest tavadest – nii on nendest kõige rohkem kasu. Koosolekute ajaline kestvus on ette määratud ja need ei tohiks venida pikemaks. Seoses paindliku töögraafikuga võivad tekkida probleemid ka koosolekute ajastamisega. Näiteks, kui koosolekud toimuvad hommikuti ja meeskonnaliikmed tulevad tööle erinevatel aegadel, võib koosoleku pidamine häirida nende inimeste keskendumist, kes jõudsid tööle juba varahommikul. | Samuti tuleb Scrumis pidada kinni koosolekute reeglitest ja headest tavadest – nii on nendest kõige rohkem kasu. Koosolekute ajaline kestvus on ette määratud ja need ei tohiks venida pikemaks. Seoses paindliku töögraafikuga võivad tekkida probleemid ka koosolekute ajastamisega. Näiteks, kui koosolekud toimuvad hommikuti ja meeskonnaliikmed tulevad tööle erinevatel aegadel, võib koosoleku pidamine häirida nende inimeste keskendumist, kes jõudsid tööle juba varahommikul. <ref name="IssuesChallenges"></ref> | ||
==== Klientide pühendumus ==== | ==== Klientide pühendumus ==== | ||
Scrumi, nagu ka teiste agiilsete metoodikate, puhul on oluline, et klient oleks arendusprotsessi loomulik osa alates tarkvara analüüsist kuni juurutamiseni välja. Seetõttu võib kliendi pühendumus paljudel puhkudel mängida projekti õnnestumise juures väga olulist rolli – kui kliendi esindajad ei ole altid arendusmeeskonnaga suhtlema, on suurem tõenäosus, et tulemus ei ole see, mida nad ootasid. | Scrumi, nagu ka teiste agiilsete metoodikate, puhul on oluline, et klient oleks arendusprotsessi loomulik osa alates tarkvara analüüsist kuni juurutamiseni välja. Seetõttu võib kliendi pühendumus paljudel puhkudel mängida projekti õnnestumise juures väga olulist rolli – kui kliendi esindajad ei ole altid arendusmeeskonnaga suhtlema, on suurem tõenäosus, et tulemus ei ole see, mida nad ootasid. <ref name="IssuesChallenges"></ref> | ||
==== Töökeskkond ==== | ==== Töökeskkond ==== | ||
Scrumi sotsiaalse loomu tõttu sobib protsessiks paremini avatud | Scrumi sotsiaalse loomu tõttu sobib protsessiks paremini avatud kui vaheseintega eraldatud ruum või eraldiseisvad kabinetid. See mõjub hästi meeskonna suhtlusele ja avatusele, kuid ei pruugi kõigile arendajatele sobida, sest ruumis võib olla mitmeid keskendumist segavaid faktoreid <ref name="IssuesChallenges"></ref>. Teadlased on aga uurinud ka ruumi ümberkujundamise lahendusi, et see toetaks Scrumi protsessi paremini ning annaks töötajatele võimalusi keskendumiseks ja puhkamiseks <ref>"Conceptual model of working space for Agile (Scrum) project team", Paweł Rola, Dorota Kuchta, Dominika Kopczyk, 2016, https://www.sciencedirect.com/science/article/pii/S0164121216300401</ref>. Samuti on Scrumi võimalik edukalt rakendada ka kaugtöös <ref>"Agile & Distributed Project Management: A Case Study Revealing Why Scrum is Useful", Lene Pries-Heje, Jan Pries-Heje, 2011, https://aisel.aisnet.org/ecis2011/217/</ref>. | ||
==== Mõju arendajatele ja meeskondadele ==== | ==== Mõju arendajatele ja meeskondadele ==== | ||
Scrum võib mõjuda arendajatele väga motiveerivalt, sest see toetab üksteiselt õppimist, suurendab meeskondade ja nende liikmete autonoomsust ning soodustab inimestevahelisi suhteid. Isiklikel konfliktidel võib aga motivatsioonile olla negatiivne mõju, seetõttu peaks kogu meeskond arvestama üksteise isikupäradega | Scrum võib mõjuda arendajatele väga motiveerivalt, sest see toetab üksteiselt õppimist, suurendab meeskondade ja nende liikmete autonoomsust ning soodustab inimestevahelisi suhteid. Isiklikel konfliktidel võib aga motivatsioonile olla negatiivne mõju, seetõttu peaks kogu meeskond arvestama üksteise isikupäradega <ref name="LawCharron"></ref>. Kui meeskonna ühtekuuluvustunne on madal, liikmetevahelised suhted kehvad või inimesed vähemotiveeritud, soovitatakse meeskondade ümberorganiseerimist, projektijuhi rolli kaasamist, paaristöid ja motivatsiooni tõstmise meetmeid <ref name="Rasnacis"></ref>. Lisaks võib Scrumi mudelist tulenev suurem vastutus ja mudeli enda keerukus võrreldes traditsiooniliste tarkvaraarenduse metoodikatega viia arendajate läbipõlemiseni ja avaldada mõju mudeli sobivusele pikas perspektiivis <ref name="Overhage">"Investigating the Long-Term Acceptance of Agile Methodologies: An Empirical Study of Developer Perceptions in Scrum Projects", Sven Overhage, Sebastian Schlauderer, 2012, https://ieeexplore.ieee.org/document/6149555</ref>. | ||
=== Võimalikud väljakutsed Scrumi juurutamisel === | === Võimalikud väljakutsed Scrumi juurutamisel === | ||
Scrumi juurutamise juures on välja toodud mitmeid esineda võivaid väljakutseid <ref name="EspinosaCuriel"></ref>. | |||
'''Isiklikud väljakutsed:''' | '''Isiklikud väljakutsed:''' | ||
Line 246: | Line 246: | ||
=== Võimalikud tegevused Scrumi juurutamise toetamiseks === | === Võimalikud tegevused Scrumi juurutamise toetamiseks === | ||
Traditsioonilistes tarkvaraarenduse meeskondades Scrumi juurutamise toetamiseks on mitmeid võimalusi <ref name="EspinosaCuriel"></ref>. | |||
'''Teadlikkuse suurendamine:''' | '''Teadlikkuse suurendamine:''' | ||
Line 276: | Line 278: | ||
=== Mis on Kanban? === | === Mis on Kanban? === | ||
Kanban on töövoo manageerimise meetod, mille disain aitab töö tegemist visualiseerida ning | Kanban on töövoo manageerimise meetod, mille disain aitab töö tegemist visualiseerida ning saavutada maksimaalne produktiivsus ning efektiivsus. Sõna pärineb jaapanikeelsest sõnast “kamban”, mis tähendab suurt kuulutuse plakatit (ingl.k billboard) või kaarti. Selline töömetoodika sai alguse juba möödunud sajandi keskpaigas tootmissektoris, tarkvaraarendusse jõudis see tükk maad hiljem. Tänapäeval on tegu metoodikaga, mis on kasutuses üsna mitmes eluvaldkonnas. | ||
=== Kanbani algus === | === Kanbani algus === | ||
[[File:Taiichi_Ohno.jpg|200px|thumb|left|Taiichi Ohno]] | |||
Kanban kui metoodika sai alguse 1940ndate Jaapanis, kus Toyota insener Taiichi Ohno soovis parandada autotööstuse kitsaskohti ning muuta Jaapani autotööstus efektiivsemaks ja kiiremaks kui nende Ameerika konkurentidel. Selle lahenduse, mille algne nimetus oli “just-in-time production”, eesmärk oli kontrollida ja manageerida tööd ja inventari optimaalselt igal tootmissammul – vähendada mitteolulisi tegevusi nii, et ka produktiivsus ei langeks. Tänu sellele lähenemisele suutis Toyota jõuda paindliku ja efektiivse tootmisvooni – tootmine sõltub klientide nõudlusest, aga mitte mentaliteedist toota võimalikult palju asju võimalikult kiiresti, mis oli tolle aja standardiks. <ref name="WhatIsKanbanDigite">"What is Kanban?", https://www.digite.com/kanban/what-is-kanban/ (06.05.2020)</ref> | Kanban kui metoodika sai alguse 1940ndate Jaapanis, kus Toyota insener Taiichi Ohno soovis parandada autotööstuse kitsaskohti ning muuta Jaapani autotööstus efektiivsemaks ja kiiremaks kui nende Ameerika konkurentidel. Selle lahenduse, mille algne nimetus oli “just-in-time production”, eesmärk oli kontrollida ja manageerida tööd ja inventari optimaalselt igal tootmissammul – vähendada mitteolulisi tegevusi nii, et ka produktiivsus ei langeks. Tänu sellele lähenemisele suutis Toyota jõuda paindliku ja efektiivse tootmisvooni – tootmine sõltub klientide nõudlusest, aga mitte mentaliteedist toota võimalikult palju asju võimalikult kiiresti, mis oli tolle aja standardiks. <ref name="WhatIsKanbanDigite">"What is Kanban?", https://www.digite.com/kanban/what-is-kanban/ (06.05.2020)</ref> | ||
Line 289: | Line 293: | ||
Nüüdseks on see metoodika jõudnud väga paljude IT inimeste ja ettevõtete tööprotsessi. | Nüüdseks on see metoodika jõudnud väga paljude IT inimeste ja ettevõtete tööprotsessi. | ||
Tuleb aga mainida, et kuigi kanban on ITs laialdaselt kasutusel ning seda kõrvutatakse tihti Scrumiga, ei ole selle näol tegemist tarkvaraarenduse- või projektiplaneerimise metoodikaga. Kanban ei ütle, kuidas tarkvara peaks arendama, planeerima või implementeerima. Seega pole Kanban juhtimisraamistik nagu seda on Scrum. Kanbani eesmärk on hoopis pidevalt parandada tööprotsessi kui tervikut. Seetõttu on Kanbani võimalik kasutada erinevate arendusmetoodikate raames, olgu selleks agiilsed meetodid nagu Scrum või | Tuleb aga mainida, et kuigi kanban on ITs laialdaselt kasutusel ning seda kõrvutatakse tihti Scrumiga, ei ole selle näol tegemist tarkvaraarenduse- või projektiplaneerimise metoodikaga. Kanban ei ütle, kuidas tarkvara peaks arendama, planeerima või implementeerima. Seega pole Kanban juhtimisraamistik nagu seda on Scrum. Kanbani eesmärk on hoopis pidevalt parandada tööprotsessi kui tervikut. Seetõttu on Kanbani võimalik kasutada erinevate arendusmetoodikate raames, olgu selleks agiilsed meetodid nagu Scrum või ekstreemprogrammeerimine, või traditsioonilisemad nagu waterfall – Kanbani abil saab nende kõikide tööprotsessi parandada ning töövoogu efektiivsemaks muuta. <ref name="WhatIsKanbanDigite"/> | ||
=== Kanbani eripärad === | === Kanbani eripärad === | ||
==== Visualisatsioon ==== | ==== Visualisatsioon ==== | ||
[[File:Kanban_board_example.jpg|200px|thumb|right|Näide Kanban board'ist]] | |||
Visualiseerimine on oluline osa mõistmaks töövoogu ning tööd ennast. Seega on oluline luua raam, mis: | Visualiseerimine on oluline osa mõistmaks töövoogu ning tööd ennast. Seega on oluline luua raam, mis: | ||
Line 306: | Line 312: | ||
Kanbani praktiseerimise lihtsustamiseks on loodud mitmeid tööriistu, sh [https://www.atlassian.com/software/jira Jira], [https://trello.com/ Trello] ja [https://hygger.io/ Hygger]. | Kanbani praktiseerimise lihtsustamiseks on loodud mitmeid tööriistu, sh [https://www.atlassian.com/software/jira Jira], [https://trello.com/ Trello] ja [https://hygger.io/ Hygger]. | ||
==== Töös olevad ülesanded ( | ==== Töös olevad ülesanded (WIP) ==== | ||
Kanban limiteerib tööde hulka, mis võivad olla korraga “''In progress''”, st kasutatakse ''pull'' metoodikat. ''Pull'' ja ''push'' metoodikate erinevusest arusaamiseks võib tuua näite kirjaklambritega. Kui ühendada üksteise külge mitu kirjaklambrit ning panna need lauale, siis lükates viimast kirjaklambrit esimese suunas, tekib tõenäoliselt tropp ning kirjaklambrid kuhjuvad. Samas, kui tõmmata esimest kirjaklambrit edasi, liigub kogu kirjaklambrikett vabalt ning tõrgeteta. <ref name="AspectsOfKanban"/> | Kanban limiteerib tööde hulka, mis võivad olla korraga “''In progress''”, st kasutatakse ''pull'' metoodikat. ''Pull'' ja ''push'' metoodikate erinevusest arusaamiseks võib tuua näite kirjaklambritega. Kui ühendada üksteise külge mitu kirjaklambrit ning panna need lauale, siis lükates viimast kirjaklambrit esimese suunas, tekib tõenäoliselt tropp ning kirjaklambrid kuhjuvad. Samas, kui tõmmata esimest kirjaklambrit edasi, liigub kogu kirjaklambrikett vabalt ning tõrgeteta. <ref name="AspectsOfKanban"/> | ||
Line 316: | Line 322: | ||
''Work in Progress''’i limiteerimisel on suur mõju produktiivsusele ning tiimitööle. | ''Work in Progress''’i limiteerimisel on suur mõju produktiivsusele ning tiimitööle. | ||
==== Pidev areng | ==== Pidev areng ==== | ||
Kanbani süsteemi üks suurimaid eesmärke on üleüldse Kanbani süsteemist lahti saada. See tähendab, et tiimiliikmed peaksid alati otsima võimalusi, et töö liiguks edasi, mitte hoidma ennast kogu aeg rakkes. “''Kanban is something you strive to get rid of, not be proud of''”.<ref>"The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer", Jeffrey Liker</ref> | Kanbani süsteemi üks suurimaid eesmärke on üleüldse Kanbani süsteemist lahti saada. See tähendab, et tiimiliikmed peaksid alati otsima võimalusi, et töö liiguks edasi, mitte hoidma ennast kogu aeg rakkes. “''Kanban is something you strive to get rid of, not be proud of''”.<ref>"The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer", Jeffrey Liker</ref> | ||
Line 326: | Line 332: | ||
Eesmärk on liikuda pidevalt “''Flow zone''”s. Mike Rother ja John Shook on öelnud Kanbani kohta: “''Flow where you can, pull when you must''”. <ref>"Learning to See: Value Stream Mapping to Add Value and Eliminate Muda", Mike Rother and John Shook</ref> | Eesmärk on liikuda pidevalt “''Flow zone''”s. Mike Rother ja John Shook on öelnud Kanbani kohta: “''Flow where you can, pull when you must''”. <ref>"Learning to See: Value Stream Mapping to Add Value and Eliminate Muda", Mike Rother and John Shook</ref> | ||
==== Fookus töö lõpetamisel | ==== Fookus töö lõpetamisel ==== | ||
[[File:Burn-out.jpg|250px|thumb|left|Kanbani kasutus aitab vältida läbipõlemist]] | |||
Erinevate uuringute kohaselt satub 60% IT sektoris töötavatest inimestest mingil hetkel olukorda, kus toimub läbipõlemine (''burn-out'')<ref name="BlindBurnout">"Close to 60 Percent of Surveyed Tech Workers Are Burnt Out—Credit Karma Tops the List for Most Employees Suffering From Burnout", Kyle McCarthy, https://www.teamblind.com/blog/index.php/2018/05/29/close-to-60-percent-of-surveyed-tech-workers-are-burnt-out-credit-karma-tops-the-list-for-most-employees-suffering-from-burnout/</ref>. Selle põhjuseks on suuresti see, et töötajad peavad tihti end ümber lülitama mõnd teist ülesannet tegema, mistõttu tuleb end uuesti teise konteksti seada. Gerald Weinberg on oma raamatus “''Quality Software Management: Systems Thinking''” öelnud, et 20% ajast läheb kaduma iga uue ülesande puhul<ref>"Quality Software Management: Systems Thinking", Gerald Weinberg</ref>. Seega kui ainult ühe ülesande tegemine korraga tähendab 100% ajakulu sellele ülesandele, siis kaks ülesannet korraga tähendab, et mõlema ülesande jaoks on keskmiselt 40% koguajast, kolme ülesande puhul on ühe ülesande ajakasutus 20% jne. Seega, mida vähem ülesandeid, seda väiksem ajakadu. | Erinevate uuringute kohaselt satub 60% IT sektoris töötavatest inimestest mingil hetkel olukorda, kus toimub läbipõlemine (''burn-out'')<ref name="BlindBurnout">"Close to 60 Percent of Surveyed Tech Workers Are Burnt Out—Credit Karma Tops the List for Most Employees Suffering From Burnout", Kyle McCarthy, https://www.teamblind.com/blog/index.php/2018/05/29/close-to-60-percent-of-surveyed-tech-workers-are-burnt-out-credit-karma-tops-the-list-for-most-employees-suffering-from-burnout/</ref>. Selle põhjuseks on suuresti see, et töötajad peavad tihti end ümber lülitama mõnd teist ülesannet tegema, mistõttu tuleb end uuesti teise konteksti seada. Gerald Weinberg on oma raamatus “''Quality Software Management: Systems Thinking''” öelnud, et 20% ajast läheb kaduma iga uue ülesande puhul<ref>"Quality Software Management: Systems Thinking", Gerald Weinberg</ref>. Seega kui ainult ühe ülesande tegemine korraga tähendab 100% ajakulu sellele ülesandele, siis kaks ülesannet korraga tähendab, et mõlema ülesande jaoks on keskmiselt 40% koguajast, kolme ülesande puhul on ühe ülesande ajakasutus 20% jne. Seega, mida vähem ülesandeid, seda väiksem ajakadu. | ||
Teada on, et ''multitask''imine kaugele ei vii. Lõppkokkuvõttes on ülesannete järjestikku tegemine tulemust andvam, kui nende samaaegne tegemine. | Teada on, et ''multitask''imine kaugele ei vii. Lõppkokkuvõttes on ülesannete järjestikku tegemine tulemust andvam, kui nende samaaegne tegemine. | ||
Kanbani metoodika vähendab võimalust ülesannete vahetamise tõttu läbi põleda, kuna limiteerib ülesannete hulka, mis võivad korraga olla tegemises. Seda kas üksikisiku seisukohast või kogu protsessi seisukohast. See tähendab, et töötajad saavad rohkem keskenduda käesolevale ülesandele ning viia see enne | Kanbani metoodika vähendab võimalust ülesannete vahetamise tõttu läbi põleda, kuna limiteerib ülesannete hulka, mis võivad korraga olla tegemises. Seda kas üksikisiku seisukohast või kogu protsessi seisukohast. See tähendab, et töötajad saavad rohkem keskenduda käesolevale ülesandele ning viia see lõpule enne , kui nad uut alustavad. Ühelt poolt vähendab see aega, mis kulub ülesande lõpetamisele, teiselt poolt soodustab ka tiimitööd, kuna annab võimaluse aidata teisi tiimiliikmeid, kui oma ülesanded saavad tehtud ning uusi veel võtta pole vaja. <ref name="CharacteristicsOfKanban">"Main Features and Characteristics of Successful Kanban Teams", Nikolay Tsonev, https://kanbanize.com/blog/characteristics-of-kanban/</ref> | ||
Seega Kanbani seisukohast on igal arendajal neli valikut, järjestatud prioriteetselt <ref name="AspectsOfKanban"/>: | Seega Kanbani seisukohast on igal arendajal neli valikut, järjestatud prioriteetselt <ref name="AspectsOfKanban"/>: | ||
Line 339: | Line 347: | ||
*Leia midagi muud kasulikku, mida teha | *Leia midagi muud kasulikku, mida teha | ||
==== Eneseorganiseerimine | ==== Eneseorganiseerimine ==== | ||
Projektijuhtimine ja sellega kaasas käivad nõuded on vajalikud, et saavutada projekti eesmärgid. See eeldab pidevat kontrolli projektijuhi poolt ning pidevat töötajate manageerimist. | Projektijuhtimine ja sellega kaasas käivad nõuded on vajalikud, et saavutada projekti eesmärgid. See eeldab pidevat kontrolli projektijuhi poolt ning pidevat töötajate manageerimist. | ||
Kanbani puhul on palju rõhutud sellele, et kõik tiimiliikmed | Kanbani puhul on palju rõhutud sellele, et kõik tiimiliikmed teaksid iga hetk, mida nad peaksid tegema ja millega ametis olema, ilma, et seda neile pidevalt öeldaks. Tänu sellele on tiimiliikmetel parem eneseorganiseerimise võimalus, mistõttu ollakse positiivsemalt meelestatud oma ülesannete suhtes ning lõppkasutajateni jõuab kvaliteetsem ja läbimõeldum toodang.<ref name="CharacteristicsOfKanban"/> | ||
==== Tiimi motivatsioon | ==== Tiimi motivatsioon ==== | ||
Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab | Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab töötajstel hoida ülesanne fookuses ning olla osake nö suuremast masinast. See aitab kaasa ka töötaja rahulolule, kuna ta teab, et tema tööd hinnatakse ja vaadatakse pidevalt üle. Lisaks tõstab see personaalse heaolu taset, mis omakorda võimendab heaolu ka kogu tiimis või töötajaskonnas. <ref name="CharacteristicsOfKanban"/> | ||
=== Kanban kokkuvõtvalt === | === Kanban kokkuvõtvalt === | ||
Line 366: | Line 374: | ||
Uuringuid selle kohta, kui palju kasutatakse spetsiifiliselt Kanbani tänapäeva tarkvaraarendustes, pole tehtud. Küll aga on teada, et agiilseid arendusmetoodikaid (või nende poole kallutatud metoodikaid) kasutatakse nii palju, et tõenäoliselt ületab see varsti traditsioonilisemate meetodite kasutamise <ref>"Success Rates Rise: Transforming the High Cost of Low Performance", https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf</ref>. | Uuringuid selle kohta, kui palju kasutatakse spetsiifiliselt Kanbani tänapäeva tarkvaraarendustes, pole tehtud. Küll aga on teada, et agiilseid arendusmetoodikaid (või nende poole kallutatud metoodikaid) kasutatakse nii palju, et tõenäoliselt ületab see varsti traditsioonilisemate meetodite kasutamise <ref>"Success Rates Rise: Transforming the High Cost of Low Performance", https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf</ref>. | ||
Agiilseid meetodeid, sh ka Kanbani, kasutavad mitmed suurkorporatsioonid oma IT arenduses <ref name="KanbanInIT">"Kanban in IT Operations: 5 Real-Life Examples", Pavel Naydenov, https://kanbanize.com/blog/kanban-it-operations/</ref>. Näiteks [https://www.spotify.com | Agiilseid meetodeid, sh ka Kanbani, kasutavad mitmed suurkorporatsioonid oma IT arenduses <ref name="KanbanInIT">"Kanban in IT Operations: 5 Real-Life Examples", Pavel Naydenov, https://kanbanize.com/blog/kanban-it-operations/</ref>. Näiteks [https://www.spotify.com/ Spotify], [https://www.vmware.com/ VMWare], [https://www.volvogroup.com/ Volvo IT], [https://www.autotrader.co.uk/ Auto Trader] ja [https://www.blizzardsports.com/?cc=1 Blizzard Sport]. | ||
Need ettevõtted on tõestuseks, et isegi kõige lihtsam Kanbani kasutus võib positiivselt mõjutada IT-tiimide protsesse. Ian Carrol on öelnud: “''The beauty of Kanban is that you start with what you do now.''” <ref name="KanbanInIT"/>. | Need ettevõtted on tõestuseks, et isegi kõige lihtsam Kanbani kasutus võib positiivselt mõjutada IT-tiimide protsesse. Ian Carrol on öelnud: “''The beauty of Kanban is that you start with what you do now.''” <ref name="KanbanInIT"/>. | ||
Kuigi Kanbani positiivsed küljed kaaluvad tihti üles negatiivsed küljed, siis Kanban iseenesest ei garanteeri edu. Uuringuid selle kohta, kas ja kuidas on Kanbani kasutamine mõjutanud tarkvaraarendust, on vähe. Ühes uurimistöös <ref>"Kanban in software engineering: A systematic mapping study", Muhammad Ovais Ahmad, Denis Dennehy, Kieran Conboy, Markku Oivo, https://www.sciencedirect.com/science/article/pii/S0164121217302820</ref> on kirjutatud, et Kanbani pole võimalik eraldiseisvalt õppida, vaid samal ajal tuleb õppida ka workflow, flow diagrammide, burn-down graafikute ja muu sellise kohta. Autorite poolt pakuti välja, et tulevikus võiks uurida Kanbani kasutust ka reaaleluliste andmetega töötamisel ning analüüsimisel; ja julgustati veelgi Kanbani süvitsi uurima ning selle mõju hindama. | Kuigi Kanbani positiivsed küljed kaaluvad tihti üles negatiivsed küljed, siis Kanban iseenesest ei garanteeri edu. Uuringuid selle kohta, kas ja kuidas on Kanbani kasutamine mõjutanud tarkvaraarendust, on vähe. Ühes uurimistöös <ref>"Kanban in software engineering: A systematic mapping study", Muhammad Ovais Ahmad, Denis Dennehy, Kieran Conboy, Markku Oivo, https://www.sciencedirect.com/science/article/pii/S0164121217302820</ref> on kirjutatud, et Kanbani pole võimalik eraldiseisvalt õppida, vaid samal ajal tuleb õppida ka ''workflow'', ''flow'' diagrammide, ''burn-down'' graafikute ja muu sellise kohta. Autorite poolt pakuti välja, et tulevikus võiks uurida Kanbani kasutust ka reaaleluliste andmetega töötamisel ning analüüsimisel; ja julgustati veelgi Kanbani süvitsi uurima ning selle mõju hindama. | ||
Teises uuringus <ref>"A statistical analysis of the effects of Scrum and Kanban on software development projects", Howard Lei, Farnaz Ganjeizadeh, Pradeep Kumar Jaychandran, Pinar Ozcan, https://www.sciencedirect.com/science/article/pii/S0736584515301599#s0095</ref>, milles uuriti Scrumi ja Kanbani mõju tarkvaraarenduse projektidele, leiab, et mõlemad meetodid tagavad edukaid projekte. Uuring põhines vastanute statistikal ning käsitles eelarvest kinnipidamist, riskihaldust, tulemi kvaliteeti, olemasolevate ressursside hulka, projekti skoopi ning ajagraafikust kinnipidamist. | Teises uuringus <ref>"A statistical analysis of the effects of Scrum and Kanban on software development projects", Howard Lei, Farnaz Ganjeizadeh, Pradeep Kumar Jaychandran, Pinar Ozcan, https://www.sciencedirect.com/science/article/pii/S0736584515301599#s0095</ref>, milles uuriti Scrumi ja Kanbani mõju tarkvaraarenduse projektidele, leiab, et mõlemad meetodid tagavad edukaid projekte. Uuring põhines vastanute statistikal ning käsitles eelarvest kinnipidamist, riskihaldust, tulemi kvaliteeti, olemasolevate ressursside hulka, projekti skoopi ning ajagraafikust kinnipidamist. | ||
Line 375: | Line 383: | ||
Tegemist oli siiski uuringuga pigem tehnilisest vaatepunktist ning autorid loodavad tulevikus uurida nende meetodite mõju ka tiimitööle, tööjaotusele ja läbipaistvusele. | Tegemist oli siiski uuringuga pigem tehnilisest vaatepunktist ning autorid loodavad tulevikus uurida nende meetodite mõju ka tiimitööle, tööjaotusele ja läbipaistvusele. | ||
== | ==Ekstreemprogrammeerimine== | ||
Eelmises kahes jaotises oli juttu agiilsetest metoodikatest Scrum ja Kanban. Need kaks ei välista teineteist. Vastupidi — nende kahe kooslus on küllaltki levinud nähtus ning see kannab nime [https://www.agilealliance.org/what-is-scrumban/ Scrumban]. | Eelmises kahes jaotises oli juttu agiilsetest metoodikatest Scrum ja Kanban. Need kaks ei välista teineteist. Vastupidi — nende kahe kooslus on küllaltki levinud nähtus ning see kannab nime [https://www.agilealliance.org/what-is-scrumban/ Scrumban]. Scrumban ühendab endas mõlema metoodika parimad küljed, parendamaks projektide ülalpidamist. Kanban annab võimaluse Scrumi võlusid veelgi efektiivsemalt rakendada. Scrumban on tänapäeval väga populaarne. | ||
Extreme Programming | Ekstreemprogrammeerimine (ingl. k. ''Extreme Programming'', XP) on aga teistsugune ning pakub terviklikumat ja spetsialiseeritumat lähenemist, keskendudes just programmeerimise ja arendustöö efektiivsusele. Antud arendusmetoodika puhul on tegemist ühe tervikuga. Suur osa XP kommuunist leiab, et kui kasutusel ei ole kõik XP printsiibid, siis ei ole tegemist õige XP arendusega <ref>"Extreme Programming (XP) FAQ", Brewer, J., 2001, http://www.jera.com/techinfo/xpfaq.html</ref>. | ||
=== Ajalugu === | === Ajalugu === | ||
[[File:ITSPEA_XP_Kent_Beck.jpg|200px|thumb|right|Kent Beck]] | |||
Töö ekstreemprogrammeerimise kui arendusmudeli välja töötamiseks sai alguse aastal 1996. XP väljatöötamise keskkonnaks oli Chrysler Comprehensive Compensation System (C3), mille arendus vältas aastatel 1993 kuni 1999 ning mille eestvedaja (nagu nimestki võib välja lugeda) oli ettevõte Chrysler. Võib öelda, et C3 oli XP kasvulava. C3'e arendustiimi kuulus terve rida mõjukaid tarkvarainsenere, kes olid osa XP väljakujunemisest. Kõne all oleva arendusmetoodika loojaks on Kent Beck, kes oli ka juhtiv tarkvarainsener C3's. Teiste nimedena toob viidatav allikas välja järgnevad: Ron Jeffries, Ward Cunningham, Don Wells ja Martin Fowler. Nad kõik on oma valdkonna eksperdid ning vastavates ringkondades hästi tuntud. <ref name=WIHTXPHistory>"Extreme Programming (XP): You Wouldn't Believe It Came from Chrysler - WhoIsHostingThis.com", Brenda Barron, 2019, https://www.whoishostingthis.com/resources/extreme-programming/</ref> | |||
Kent Beck liitus C3 projektiga aastal 1996. Selleks ajaks oli projekt olnud tegemisel kolm aastat, ent projekti tulemina loodav programm ei olnud veel toimiv. Projektile anti veel veidi üle kahe aasta arendusaega juurde ning sellesse investeeriti miljoneid dollareid. Lõpuks, aastal 1999, jäeti projekt katki. Sellest hoolimata oli C3 projekti algne edu see, mis andis XP-le vajaliku tõuke. Ühe suurema läbimurdena võib näha C3'e tiimi produktiivsuse ja samal ajal ka koodikvaliteedi tõusu. Sellised positiivsed muutused saavutati tööstuses kasutatavate metoodikate (nagu [https://en.wikipedia.org/wiki/Lean_manufacturing Lean tootmine]) rakendamisel tarkvaraarenduses. <ref name=WIHTXPHistory /> | |||
Martin Fowler on toonud välja, et tõsisem arendustöö C3 projekti kallal algas aastal 1995, programmeerimiskeeles [https://en.wikipedia.org/wiki/Smalltalk Smalltalk], aga kuna projekti viimine stabiilsesse seisu ebaõnnestus, tehti sellele ''restart''. Selles uuesti alustatud projektis leidsid rakendust kõik praktikad, mis on tänasel päeval tuntud ekstreemprogrammeerimise nime alla koondatult. <ref>"C3", Martin Fowler, 2004, https://www.martinfowler.com/bliki/C3.html</ref> | |||
C3 projekti liikmed jätkasid XP metoodika arendamist pärast projekti lõppemist aastal 1999. Ekstreemprogrammeerimine on viimase kahe kümnendi jooksul tasapisi kogunud populaarsust ning nüüdseks on selle meetodid ja põhimõtted võtnud omaks tarkvaraarendusjuhid üle maailma. <ref name=WIHTXPHistory /> | |||
C3 projekti liikmed jätkasid XP metoodika arendamist pärast projekti lõppemist aastal 1999. | |||
=== Lühitutvustus === | === Lühitutvustus === | ||
[[File:ITSPEA_XP_Pair_programming.jpg|200px|thumb|right|Paarisprogrammeerimine]] | |||
Ekstreemprogrammeerimine on edukas, sest see seab tähtsale kohale kliendi rahulolu. XP protsess tarnib tarkvara, mida klient vajab, ajaks, mil tal seda vaja läheb. Ekstreemprogrammeerijad on võimelised reageerima klientide muutlikele nõuetele, isegi kui need tulevad arenduse hilises faasis. <ref name=XPIntro>"Extreme Programming: A Gentle Introduction.", Don Wells, 2009, http://www.extremeprogramming.org/</ref> | |||
XP seab tähtsale kohale ka meeskonnatöö. Meeskonnaliikmeid — juhte, kliente ja arendajaid — käsitletakse võrdsete partneritena kaastööd tegevas tiimis. Vajadusel (kui ekstreemprogrammeerimine on tiimi meeskonna jaoks uus lähenemine) kaasatakse ka treener (''Coach'') <ref>"Extreme Programming - Roles - Tutorialspoint", https://www.tutorialspoint.com/extreme_programming/extreme_programming_roles.htm</ref>. XP aitab luua lihtsa, aga efektiivse keskkonna, mis aitab meeskondadel saavutada kõrge produktiivsuse <ref name=XPIntro />. | |||
Ekstreemprogrammeerimist iseloomustavad viis põhilist märksõna<ref name=XPIntro/>: | |||
# kommunikatsioon — suhtlus nii klientidega kui ka arendajate vahel; | # kommunikatsioon — suhtlus nii klientidega kui ka arendajate vahel; | ||
# lihtsus — implementatsioonid tuleb hoida lihtsa ja puhtana; | # lihtsus — implementatsioonid tuleb hoida lihtsa ja puhtana; | ||
# tagasiside — tarkvara testitakse esimesest päevast alates; klientidele tarnitakse tarkvara nii vara kui võimalik ning võetakse arvesse nende | # tagasiside — tarkvara testitakse esimesest päevast alates; klientidele tarnitakse tarkvara nii vara kui võimalik ning võetakse arvesse nende tagasisidet; | ||
# austus — kujuneb läbi iga tiimiliikme unikaalse panuse ja väikeste võitude; | # austus — kujuneb läbi iga tiimiliikme unikaalse panuse ja väikeste võitude; | ||
# julgus — eeltoodu loob vundamendi, tänu millele on võimalik julgelt reageerida muutuvatele nõuetele ja tehnoloogiatele. | # julgus — eeltoodu loob vundamendi, tänu millele on võimalik julgelt reageerida muutuvatele nõuetele ja tehnoloogiatele. | ||
Ekstreemprogrammeerimise reegleid<ref>"Extreme Programming Rules", Don Wells, 1999, http://www.extremeprogramming.org/rules.html</ref> on päris mitmeid, neid kõiki käesolevas töös välja ei tooda. Need kategoriseeritakse planeerimise (''Planning''), halduse (''Managing''), disainimise (''Designing''), koodi kirjutamise (''Coding'') ja testimise (''Testing'') alla. Siinkohal tasub välja tuua väikeste reliiside, iteratsioonideks jaotamise, avatud tööruumi, ''stand-up'''ide, TDD (''test driven development''i) ja testide katvuse olulisuse. Üks oluline XP metoodika osa on ka paarisprogrammeerimine <ref>"Pair Programming", Don Wells, 1999, http://www.extremeprogramming.org/rules/pair.html</ref>. | |||
=== Projektihaldus === | === Projektihaldus === | ||
==== Riskihaldus / väikesed reliisid ==== | ==== Riskihaldus / väikesed reliisid ==== | ||
Ekstreemprogrammeerimine kasutab ära teadmist, et väiksematel projektidel on kõrgem edutõenäosus, tükeldades kõik tarkvaraprojektid mitmeks väiksemaks reliisiks. Igaüks nendest koosneb väiksemast osast nõutavast funktsionaalsusest. Selline lähenemine võimaldab kliendil ja lõppkasutajatel arendustulemustega juba varakult tutvuda ning seeläbi anda kvaliteetsemat ja täpsemat tagasisidet. Asjakohasem tagasiside tagab parema tellija ja täitja vahelise koostöö. XP-s on soovitatavaks reliisidevaheliseks ajaks kaks kuni kaheksa nädalat, sealjuures pidades silmas, et väiksem ajavahemik on parem. Varajaste reliiside pealt avastatud probleemid aitavad õigeaegselt juhtida projekti kulgu. Reliisid eeldavad demonstreeritavat tarkvaratulemit. Isegi kui projekt peaks enneaegselt lõppema, omavad juba loodud tulemid vähemalt mingit väärtust tellivale osapoolele. | |||
<ref name=Goebel2003>Goebel, C. J. (2003). Managing software development using extreme programming. Paper presented at PMI® Global Congress 2003—North America, Baltimore, MD. Newtown Square, PA: Project Management Institute. https://www.pmi.org/learning/library/managing-software-development-using-extreme-programming-7662</ref> | <ref name=Goebel2003>Goebel, C. J. (2003). Managing software development using extreme programming. Paper presented at PMI® Global Congress 2003—North America, Baltimore, MD. Newtown Square, PA: Project Management Institute. https://www.pmi.org/learning/library/managing-software-development-using-extreme-programming-7662</ref> | ||
==== Integratsioonihaldus ==== | ==== Integratsioonihaldus ==== | ||
Ühes teadusartiklis toodi välja, et ekstreemprogrammeerimine keskendub programmeerijate tööpanusele. Mõned XP pooldajad leiavad, et tehniliste kirjutajate (''technical writers''), andmebaasihaldurite ja kvaliteedi tagamise spetsialistide panus pole vajalik. Siiski, kõne all olev metoodika ei välista nende töö integreerimist, kes ei ole tarkvaraarendajad. Eelmainitud väikesed reliisid teevad integratsioonihaldusest järjepidevama protsessi, võrreldes mõnede teiste protsessidega, mille kohaselt paigutub tarne, dokumenteerimine ja testimine ajaplaani lõppu. <ref name=Goebel2003 /> | |||
Tarkvaraarendajate suhtes on | Tarkvaraarendajate suhtes on ekstreemprogrammeerimine konkreetne — arenduses peab olema kesksel kohal pidev integratsioon (ingl. k. ''Continuous Integration'') ja see peaks toimuma igapäevaselt. Ehkki selline praktika võib nõuda arendajatelt lisatööd, võimaldab igapäevane CI tiimil tuvastada probleeme märksa varasemalt. <ref name=Goebel2003 /> | ||
==== Aja- ja skoobihaldus ==== | ==== Aja- ja skoobihaldus ==== | ||
Ekstreemprogrammeerimise puhul läheb põhiline planeerimistöö hästi läbimõeldud tööjaotusstruktuuri (Work Breakdown Structure) ja selle juurde kuuluvate tööpakkide (Work Packages) välja töötamisele. XP ei räägi tööjaotusstruktuurist ja tööpakkidest otse, ent uurides ekstreemprogrammeerimises kasutatavaid Story Card'e, võib täheldada nende suurt sarnasust tööpakkidega. <ref name=Goebel2003 /> | |||
===== Planeerimismäng ===== | ===== Planeerimismäng ===== | ||
Tööpakid pannakse kirja käsitsi kirjutatud kirjeldustena kasutajat | Tööpakid pannakse kirja käsitsi kirjutatud kirjeldustena ning nende skoop on kasutajat puudutav funktsionaalsus. Nagu eelmises lõigus mainitud, on nende kaartide nimeks Story Card'id. Antud nimi tuletab projekti osalistele meelde, et need peavad kirjeldama lugu, mida kasutaja võib soovitavast funktsionaalsusest rääkida; need ei peaks kirjeldama tehnilist funktsionaalsust arendaja vaatepunktist. Story Card'e kasutatakse, et töötada välja hinnanguid, koostada tarkvara ehitamise ajakavasid, autoriseerida arendajate tööd, juhtida testimist ning raporteerida staatust. <ref name=Goebel2003 /> | ||
Ekstreemprogrammeerimises on planeerimise poolel olulisel kohal töö autoriseerimised. Neid tehakse iga iteratsiooni juures, üldiselt iga kahe nädala tagant. Iga iteratsiooni alguses annavad arendajad meeskonnana hinnangu kõikidele olemasolevatele Story Card'idele. Kui Story Card läheb mahult liiga suureks (ületab iteratsiooni kestust), siis tükeldatakse see kaheks või enamaks väiksemaks Story Card'iks, mis kollektiivselt vastavad esialgse kaardi funktsionaalsusele. Nendele uutele Story Card'idele (teisisõnu tööpakkidele) antakse samuti hinnangud. <ref name=Goebel2003 /> | |||
Kui lood (''stories'') on hinnatud, siis need grupeeritakse kasulikku funktsionaalsust | Kui lood (''stories'') on hinnatud, siis need grupeeritakse kasulikku funktsionaalsust sisaldavatesse reliisidesse. Nagu eelnevalt mainitud, kaasab XP kliendi arendusprotsessi juba varakult. Reliisid aitavad kliendil ja arendajatel jõuda üksmeeleni selle osas, kas projekt liigub soovitud suunas. Reliisid omakorda tükeldatakse kahenädalasteks arendusiteratsioonideks. Lood paigutatakse iteratsioonidesse eelkõige ärilist väärtust ning kuluhinnanguid arvestades; arendusefektiivsus on siinkohal pigem teisejärguline. <ref name=Goebel2003 /> | ||
Käesoleva iteratsiooni lood tükeldatakse arendajate ühisarutelu käigus lihtsamateks arendusülesanneteks või tegevusteks, mis jaotatakse üksteise vahel. Pärast seda algab töö. Kui mingi lugu või ülesanne saab valmis, siis märgitakse see tehtuks kõigile nähtaval viisil. Nagu eelnevalt mainitud, on XP-s oluline koht töö autoriseerimisel. Arendajad tohivad tööd teha ainult autoriseeritud lugude kallal. Kui arendajad soovivad muuta arendusstrateegiat, siis tuleb Story Card'id ümber kirjutada, uuesti hinnata ja ajastada. <ref name=Goebel2003 /> | Käesoleva iteratsiooni lood tükeldatakse arendajate ühisarutelu käigus lihtsamateks arendusülesanneteks või tegevusteks, mis jaotatakse üksteise vahel. Pärast seda algab töö. Kui mingi lugu või ülesanne saab valmis, siis märgitakse see tehtuks kõigile nähtaval viisil. Nagu eelnevalt mainitud, on XP-s oluline koht töö autoriseerimisel. Arendajad tohivad tööd teha ainult autoriseeritud lugude kallal. Kui arendajad soovivad muuta arendusstrateegiat, siis tuleb Story Card'id ümber kirjutada, uuesti hinnata ja ajastada. <ref name=Goebel2003 /> | ||
Iga iteratsiooni kohta arvutatakse mõõdikud. Kaks nendest on Kiirus (Velocity) ja Eilne Ilm (Yesterday's Weather). Kiiruse arvutamiseks liidetakse kokku iteratsiooni käigus valmis saadud kasutajalugude hinnangud, samuti ülesannete hinnangud <ref>"Project Velocity", Don Wells, 1999, http://www.extremeprogramming.org/rules/velocity.html</ref>. Mõõdik Eilne Ilm põhineb metafooril, et tänane ilm on tõenäoliselt sama, mis eile. Üle kantuna tähendab on antud mõõdiku tähendus, et praeguse (sprindi) olukorra hindamiseks tasub olla teadlik sellest, mis toimus varasemalt. Olukorra hindamine on oluline, et vältida | Iga iteratsiooni kohta arvutatakse mõõdikud. Kaks nendest on Kiirus (Velocity) ja Eilne Ilm (Yesterday's Weather). Kiiruse arvutamiseks liidetakse kokku iteratsiooni käigus valmis saadud kasutajalugude hinnangud, samuti ülesannete hinnangud <ref>"Project Velocity", Don Wells, 1999, http://www.extremeprogramming.org/rules/velocity.html</ref>. Mõõdik Eilne Ilm põhineb metafooril, et tänane ilm on tõenäoliselt sama, mis eile. Üle kantuna tähendab on antud mõõdiku tähendus, et praeguse (sprindi) olukorra hindamiseks tasub olla teadlik sellest, mis toimus varasemalt. Olukorra hindamine on oluline, et vältida arendajate ülekoormust <ref>"Yesterdays Weather", Jonathan Rasmusson, http://www.agilenutshell.com/yesterdays_weather</ref>. Ekstreemprogrammeerimises eelistatakse muutuvate tarnimiskuupäevade asemel ujuvat skoopi. <ref name=Goebel2003 /> | ||
==== Kvaliteedihaldus ==== | ==== Kvaliteedihaldus ==== | ||
Töötulemi kvaliteedi hoidmine võib | Töötulemi kvaliteedi hoidmine võib ekstreemprogrammeerimise puhul osutuda keeruliseks, kuna programmeerijad liiguvad nii ühelt tööautoriseerimiselt teisele kui ka erinevate koodiosade vahel. Seetõttu nõuab XP kõrgelt distsiplineeritud lähenemist, saavutamaks vabaduse ressursside määramisel ilma kvaliteedis allahindlusi tegemata. <ref name=Goebel2003 /> | ||
===== Lihtne disain, refaktoreerimine ===== | ===== Lihtne disain, refaktoreerimine ===== | ||
Esimene oluline põhimõte, mis aitab saavutada ja hoida kvaliteeti, on lihtsale disainile fokusseerumine. Selle asemel, et püüda saavutada ülipaindlikku koodi, mis sobituks potentsiaalsete uuendustega tulevikus, keskendub | Esimene oluline põhimõte, mis aitab saavutada ja hoida kvaliteeti, on lihtsale disainile fokusseerumine. Selle asemel, et püüda saavutada ülipaindlikku koodi, mis sobituks potentsiaalsete uuendustega tulevikus, keskendub ekstreemprogrammeerimine koodile, mis vastab praegustele autoriseeritud tööpakkidele. Tulevaste featuuride ja lugude implementeerimiseks täiustatakse ja parendatakse koodi pidevalt. Seda praktikat nimetatakse refaktoreerimiseks. Refaktoreerimine toimub samm-sammu haaval ning selle hõlbustamiseks on vajalik automatiseeritud kvaliteedikontroll. Järgmise refaktoriseerimissammu juurde ei minda enne, kui ollakse veendunud, et kõik toimib endiselt. <ref name=Goebel2003 /> | ||
===== Testimine ===== | ===== Testimine ===== | ||
Line 447: | Line 455: | ||
===== Paarisprogrammeerimine ===== | ===== Paarisprogrammeerimine ===== | ||
Ekstreemprogrammeerimise kohaselt toimub produktsioonikoodi kirjutamine ainult paarides — kaks arendajat istuvad ühe arvuti taga. Paarisprogrammeerimine viib ellu kollektiivomandi (''collective ownership'') põhimõtet palju paremini kui koodiülevaatamised (code review). Kahekesi programmeerides võidavad tüüpiliselt mõlemad osapooled ning see aitab tõsta ka tiimitunnetust. Paarisprogrammeerimise partnerid ei taha teineteist alt vedada — vastupidi, nad näevad eraldi vaeva, et järgida tiimis kehtestatud kokkuleppeid ja tavasid. Paaride liikmete vahetamise teel saavutatakse värskus ning informatsiooni liikumine. <ref name=Goebel2003 /> | |||
=== Kasutus hariduslikus keskkonnas === | === Kasutus hariduslikus keskkonnas === | ||
Ekstreemprogrammeerimine sobib meeskondadele, kus on kuni 12-15 tiimiliiget<ref>"Extreme Programming Explained: Embrace Change", Kent Beck, Addison-Wesley, 1999</ref>. Käesolevas peatükis on kasutatud teadusartiklit, mis leiab, et sama meeskonnaliikmete maksimumarv on kasulik lõpuaasta Tarkvaratehnika bakalaureuse õppekava projektide jaoks. Seetõttu leiavad artikli autorid, et XP kasutamine on antud tudengiprojektide puhul teostatav. <ref name=XPEdu>"eXtreme Programming––helpful or harmful in educating undergraduates?", Jean-Guy Schneider, Lorraine Johnston, 2005, https://www.sciencedirect.com/science/article/pii/S0164121203002929</ref> | |||
Mõned XP printsiibid on tudengite poolt olnud üsna leigelt vastu võetud. Nendeks on näiteks testimise olulisus (eriti just testide kirjutamine enne koodi kirjutamist), fookus kvaliteetse tarkvara kirjutamisel algusest peale, koodikirjutamis-standardite ja konfiguratsioonihalduse olulisus. XP printsiibid ei ole tegelikkuses midagi niivõrd uut, ent antud arendusmudel on | Mõned XP printsiibid on tudengite poolt olnud üsna leigelt vastu võetud. Nendeks on näiteks testimise olulisus (eriti just testide kirjutamine enne koodi kirjutamist), fookus kvaliteetse tarkvara kirjutamisel algusest peale, koodikirjutamis-standardite ja konfiguratsioonihalduse olulisus. XP printsiibid ei ole tegelikkuses midagi niivõrd uut, ent antud arendusmudel on muutnud paljud nendest trendikateks, mida varasemalt peeti tülikaks. <ref name=XPEdu /> | ||
Artikkel toob välja, et üks agiilse liikumise | Artikkel toob välja, et üks agiilse liikumise eestvedaja Alistair Cockburn leiab, et ekstreemprogrammeerimine on rakendatav ainult käputäie projektitüüpide jaoks: projektid, mille elluviimisega on seotud kuni 15 inimest ning mis on kuni keskmise kriitilisusega. Artikkel märgib ka, et just sellised projektid sobivad tudengite poolt tegemiseks. Projektid, mis lähevad nendest piiridest üle, ei ole õppimise jaoks ei praktiliselt ega eetiliselt otstarbekad. XP tundub siinkohal seega mõistlik valik. <ref name=XPEdu /> | ||
Tarkvaratehnika tudengitele on oluline teooria ja praktika kaudu anda edasi järgnevad tõsiasjad<ref name=XPEdu />: | Tarkvaratehnika tudengitele on oluline teooria ja praktika kaudu anda edasi järgnevad tõsiasjad<ref name=XPEdu />: | ||
Line 464: | Line 472: | ||
==== Kvaliteedi tagamine ==== | ==== Kvaliteedi tagamine ==== | ||
Kvaliteedi tagamine on üheks suuremaks väljakutseks enamike tarkvaraarendusprojektide jaoks. | Kvaliteedi tagamine on üheks suuremaks väljakutseks enamike tarkvaraarendusprojektide jaoks. Ekstreemprogrammeerimine sisaldab endas 12 praktikat<ref>"Extreme Programming (XP): Values, Principles, and Practices | AltexSoft", 2018, https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/</ref>, enamik neist aitavad kaasa kvaliteedi tagamisele moel või teisel. Lähemal uurimisel selgub, et XP keskendub kõige enam koodi kvaliteedi tagamisele. Väiksem fookus on arenduseelsel nõuete valideerimisel ja nendega arvestamisel. Selliste aspektide katmine on iga üksiku tiimi enda ülesanne. See nõuab tiimi, kus on vähemalt mõni suurema kogemusega arendaja. Tudengiprojektide tiimides selliseid arendajaid tihtipeale paraku ei ole. Sestap peavad tudengitiimid toetuma välisele, enamasti tuutori või töötaja, abile. Nii jääb aga tudengitele vähem manageerimist ja seeläbi jääb õppekogemus väiksemaks. <ref name=XPEdu /> | ||
Artikli autorid leiavad, et refaktoreerimine on teine praktika, millega esineb hariduslikus keskkonnas probleeme. Kogenud arendaja paneb tähele, kui "kood haiseb". Väiksema kogemusega arendaja ei ole aga piisavalt koodi näinud ega kirjutanud, et sellist asja täheldada. See omakorda tähendab, et tudengitelt ei saa eeldada efektiivset koodi refaktoreerimise oskust. Samas XP toetub just refaktoreerimisele, et hoida projekti kood puhas. <ref name=XPEdu /> | Artikli autorid leiavad, et refaktoreerimine on teine praktika, millega esineb hariduslikus keskkonnas probleeme. Kogenud arendaja paneb tähele, kui "kood haiseb". Väiksema kogemusega arendaja ei ole aga piisavalt koodi näinud ega kirjutanud, et sellist asja täheldada. See omakorda tähendab, et tudengitelt ei saa eeldada efektiivset koodi refaktoreerimise oskust. Samas XP toetub just refaktoreerimisele, et hoida projekti kood puhas. <ref name=XPEdu /> | ||
Kasutajakeskne protsess võib aidata saavutada vajalikku funktsionaalsust ja kasutatavust. On ka teine lähenemine, mille kohaselt peaks rakendatama hoopis kasutuskeskset disaini — kasutaja roll on tihtipeale olulisem kui konkreetne isik. Tarkvara peab toetama | Kasutajakeskne protsess võib aidata saavutada vajalikku funktsionaalsust ja kasutatavust. On ka teine lähenemine, mille kohaselt peaks rakendatama hoopis kasutuskeskset disaini — kasutaja roll on tihtipeale olulisem kui konkreetne isik. Tarkvara peab toetama seda, kes iganes juhtub asjassepuutuvat ülesannet täitma. XP näeb ette, et kasutaja on töökohal olemas ning temaga saab tekkivaid küsimusi pidevalt arutada. Tegelikkuses ei suuda üks "kasutaja" lõpuni välja esindada suure tarkvaraprojekti kõikide huvituvate osapoolte huve. <ref name=XPEdu /> | ||
Artikli autorid leiavad, | Artikli autorid leiavad, ekstreemprogrammeerimise praktikad ei kata kvaliteedi tagamisel tekkida võivaid probleeme piisaval määral. Sisse tuleb tuua teisi praktikaid, mis ei ole XP projekti kontekstis koheselt ilmsed, ent mis võivad olla selgemalt vajalikud suuremas ja/või kriitilisemas projektis. Kui õppekeskkonnas need teised praktikad välja jätta, siis võib tudengitele jääda ekslik mulje, et kvaliteedi tagab pelgalt hästi kirjutatud kood. <ref name=XPEdu /> | ||
==== Koos töötamine ==== | ==== Koos töötamine ==== | ||
Üks olulisemaid asju, mida tarkvaraarendust õppivad tudengid peaksid selgeks saama, on tiimina koos töötamine. Tarkvaraarendus on harva vaid ühe inimese töö. Sestap peaksid tudengid saama tiimis töötamise kogemust erinevatel õppetasemetel, seda nii väiksemates kui ka suuremates meeskondades. Oluline on ka see, et tudengid saaksid läbi proovida erinevaid rolle, mis esinevad suuremates tiimides, eriti just töö organiseerimist ja juhtimist | Üks olulisemaid asju, mida tarkvaraarendust õppivad tudengid peaksid selgeks saama, on tiimina koos töötamine. Tarkvaraarendus on harva vaid ühe inimese töö. Sestap peaksid tudengid saama tiimis töötamise kogemust erinevatel õppetasemetel, seda nii väiksemates kui ka suuremates meeskondades. Oluline on ka see, et tudengid saaksid läbi proovida erinevaid rolle, mis esinevad suuremates tiimides, eriti just neid, mis puudutavad töö organiseerimist ja juhtimist. <ref name=XPEdu /> | ||
Ekstreemprogrammeerimine paneb suurt rõhku tiimitööle. Isegi nii suurel määral, et XP ei toimi ilma kogu arendust läbiva koostööta. Arendusmudel toob välja, et tööd teeb üks meeskond, mitte mitu koostööd tegevat väiksemat alam-meeskonda. Neid asjaolusid arvesse võttes võib järeldada, et meeskonnatöö poole pealt on XP lähenemised väga kasulikud. <ref name=XPEdu /> | |||
XP üks oluline osa on paarisprogrammeerimine ning see eeldab, et kõik arendusmeeskonna liikmed omavad vähemalt mõistlikul tasemel programmeerimise oskust, on võimelised ja tahavad paarides tööd teha. Paarisprogrammeerimise juures on taseme-erinevuste eksisteerimise korral soovitatav panna koos programmeerima vähem ja rohkem kogenud arendajad — nii on võimalik aidata kaasa vähemkogenud arendajate taseme tõusule. Samuti on soovitatav paare tihti vahetada. <ref name=XPEdu /> | XP üks oluline osa on paarisprogrammeerimine ning see eeldab, et kõik arendusmeeskonna liikmed omavad vähemalt mõistlikul tasemel programmeerimise oskust, on võimelised ja tahavad paarides tööd teha. Paarisprogrammeerimise juures on taseme-erinevuste eksisteerimise korral soovitatav panna koos programmeerima vähem ja rohkem kogenud arendajad — nii on võimalik aidata kaasa vähemkogenud arendajate taseme tõusule. Samuti on soovitatav paare tihti vahetada. <ref name=XPEdu /> | ||
Koolikeskkonnas on paarisprogrammeerimine andnud vastakaid tulemusi. Ühes uuringus leiti, et paarisprogrammeerimine tõstab tudengite edukust õppeaines, enesekindlust oma lahenduste osas ning selline programmeerimine pakub rohkem rõõmu. Teisalt, | Koolikeskkonnas on paarisprogrammeerimine andnud vastakaid tulemusi. Ühes uuringus<ref>"The impact of pair programming on student performance, perception and persistence", C. McDowell, L. Werner, H.E. Bullock, J. Fernald, Proceedings ICSE 2003, Portland, Oregon, May 2003, IEEE Computer Society Press (2003), pp. 602-607</ref> leiti, et paarisprogrammeerimine tõstab tudengite edukust õppeaines, enesekindlust oma lahenduste osas ning selline programmeerimine pakub rohkem rõõmu. Teisalt, käesolevas peatükis kasutatava teadusartikli üks autor oli seotud paarisprogrammeerimise kasutuselevõtuga ühes suures (~500 tudengit) esimese aasta Tarkvaratehnika tudengite aines. Eesmärgiks oli tõsta tudengite üldist programmeerimise taset, arvates, et arenduse käigus toimuv arutelu aitab sellele kaasa. Paraku tegi paari tugevam liige põhilise osa tööst ning nõrgemad kippusid eksamitel läbi kukkuma. Paaride puhul, mille mõlemad liikmed olid võrdsel tasemel, täheldati, et liige, kes parasjagu koodi ei kirjutanud, kippus istuma jõude ning mõtlema muudele asjadele kui käesolevale ülesandele. Pandi tähele, et erinevad isiksused sobituvad paarisprogrammeerimisega erinevalt. <ref name=XPEdu /> | ||
Kui õppetingimustes rakendada paarisprogrammeerimist, siis võidaksegi piirduda kaheliikmeliste tiimidega, kuid päriselus moodustuvad paarid suuremast tiimist. Sestap tasuks suurema haridusliku kasu nimel varieerida tiimi suurusi. Nii saavad tudengid paremini kogeda, mida tiimitöö ning tiimiviisiline probleemide lahendamine tegelikult tähendavad. <ref name=XPEdu /> | Kui õppetingimustes rakendada paarisprogrammeerimist, siis võidaksegi piirduda kaheliikmeliste tiimidega, kuid päriselus moodustuvad paarid suuremast tiimist. Sestap tasuks suurema haridusliku kasu nimel varieerida tiimi suurusi. Nii saavad tudengid paremini kogeda, mida tiimitöö ning tiimiviisiline probleemide lahendamine tegelikult tähendavad. <ref name=XPEdu /> | ||
Paarides töötavad tudengid peavad olema suutlikud pidama isiklikke hindamistulemusi vähemolulisemaks kui paari üldist edu. Tudengitel võib olla selleni raske jõuda, sest kaasprogrammeerija aitamisest tulenev kasu ei pruugi neile olla nii selge. <ref name=XPEdu /> | Paarides töötavad tudengid peavad olema suutlikud pidama isiklikke hindamistulemusi vähemolulisemaks kui paari üldist edu. Paremini hakkama saavad tudengid võivad tahta lihtsalt asja ära teha ilma, et nad pingutaksid vähemkogenud paariliikme arengu nimel. Tudengitel võib olla selleni raske jõuda, sest kaasprogrammeerija aitamisest tulenev kasu ei pruugi neile olla nii selge. <ref name=XPEdu /> | ||
==== Projektitulemid ==== | ==== Projektitulemid ==== | ||
Agiilse tarkvaraarenduse manifesti<ref>"Manifesto for Agile Software Development", http://agilemanifesto.org/</ref> kohaselt on töötav tarkvara kõige olulisem projektitulem. Ent selline suhtumine võib tudengite silmis jätta varju mõned teised tulemid, mis on samuti vajalikud. Üheks selliseks tulemiks on projekti tegemise käigus saadud õppetunnid, mida võib hariduslikus kontekstis pidada oluliseks. Paraku toimub tõhus õppeprotsess enamasti ainult läbi vigade tegemise, probleemide analüüsi ning nende parandamise | Agiilse tarkvaraarenduse manifesti<ref>"Manifesto for Agile Software Development", http://agilemanifesto.org/</ref> kohaselt on töötav tarkvara kõige olulisem projektitulem. Ent selline suhtumine võib tudengite silmis jätta varju mõned teised tulemid, mis on samuti vajalikud. Üheks selliseks tulemiks on projekti tegemise käigus saadud õppetunnid, mida võib hariduslikus kontekstis pidada oluliseks. Paraku toimub tõhus õppeprotsess enamasti ainult läbi vigade tegemise, probleemide analüüsi ning nende parandamise. Selle kõige vältel ei ole võimalik tagada töötava tulemi olemasolu, mille pealt töö kulgu hinnata. <ref name=XPEdu /> | ||
Teadusartikli autorid leiavad, et koodi käsitlemine põhilise tulemina tekitab tudengites valesid arusaamu. Suuremates projektides on tihtipeale vaja enamat kui töötavat tarkvara, näiteks dokumentatsiooni. Tudengid ei pruugi lisaks koodile tekkivate tulemite vajadust mõista. Eraldi probleemiks on tudengite panuse hindamine (sealhulgas isiklik initsiatiiv, pühendumus kvaliteetsele tööle jms), sest XP ei paku selleks otsest võimalust. <ref name=XPEdu /> | |||
==== Suhtlus kliendiga ==== | ==== Suhtlus kliendiga ==== | ||
Ekstreemprogrammeerimises on suhtlus kliendiga olulisel kohal. Ideaalis peaks olema klient arendajatele pidevalt kättesaadav, parimal juhul oleks klient isegi arendajatega samas ruumis. Töökeskkonnas on seda raske saavutada, rääkimata hariduslikust keskkonnast. <ref name=XPEdu /> | |||
Kliendid ei pruugi lõpuni mõista pideva arendaja ja kliendi vahelise suhtluse kasusid. Neile | Kliendid ei pruugi lõpuni mõista pideva arendaja ja kliendi vahelise suhtluse kasusid. Neile võib tunduda see tülikas. Tudengid tajuvad seda ning ei taha omakorda klienti pidevalt tülitada väikeste või triviaalsete probleemidega, ent XPs on just selline suhtlus projekti edu saavutamiseks hädavajalik. Frustratsiooni tekitavad probleemid ilmnevad siis, kui tudengid jõuavad lahenduse mingisuguse aspektiga perfektsuseni, aga klient annab selle peale negatiivset tagasisidet. <ref name=XPEdu /> | ||
Teadusartikli autorid leiavad, et kohapealse kliendi olemasolu vajadus on pigem teisene. Hoopis olulisem on, et tudengid kogevad tagasiside väärtust. Tudengite juhendajad peaksid nägema vaeva, et valida välja sellised projektid, mille kliendid saavad aru tagasiside vajalikkusest ja on võimelised seda pakkuma. <ref name=XPEdu /> | Teadusartikli autorid leiavad, et kohapealse kliendi olemasolu vajadus on pigem teisene. Hoopis olulisem on, et tudengid kogevad tagasiside väärtust. Tudengite juhendajad peaksid nägema vaeva, et valida välja sellised projektid, mille kliendid saavad aru tagasiside vajalikkusest ja on võimelised seda pakkuma. <ref name=XPEdu /> | ||
Line 511: | Line 519: | ||
Artikkel ilmus 2005. aastal ning selleks ajaks oli olnud vähe kogemust agiilsete metoodikate rakendamisel hariduslikus kontekstis. Huvi agiilsete metoodikate vastu oli arendusmaailmas aga juba toona suur ning üha enam taheti tuua neid uusi metoodikaid kolmanda astme haridusse. <ref name=XPEdu /> | Artikkel ilmus 2005. aastal ning selleks ajaks oli olnud vähe kogemust agiilsete metoodikate rakendamisel hariduslikus kontekstis. Huvi agiilsete metoodikate vastu oli arendusmaailmas aga juba toona suur ning üha enam taheti tuua neid uusi metoodikaid kolmanda astme haridusse. <ref name=XPEdu /> | ||
Kokkuvõttes leiavad artikli autorid, et | Kokkuvõttes leiavad artikli autorid, et ekstreemprogrammeerimine kui ühtne tervik ei sobi ülikooliõppes rakendamiseks. Teisalt võivad valitud ekstreemprogrammeerimise praktikad olla kasulikud õpetamaks väiksema mastaabi tarkvaraarendust. Paarisprogrammeerimise rakendamist soovitatakse edasi uurida. <ref name=XPEdu /> | ||
==Kokkuvõte== | |||
Tarkvara arendamise meetodid saab jagada üldiselt kaheks: traditsiooniline ja väle- ehk agiilne arendus. Mõlemal meetodirühmal on oma tugevused ja nõrkused. Traditsiooniline lähenemine sobib eelkõige suurematele ja keerukamatele projektidele, millel on kindel skoop, eelarve ning on teada, mida loodavalt tarkvaralt oodatakse. Sellegipoolest võib ka selle lähenemisega sattuda lõhkiste eelarvete ja ajagraafikute küüsi. | |||
Välearendused üritavad neid nõrkusi leevendada ning võtavad muudatusi projekti osana. Välearenduse üks põhilisi fookuseid on inimesed — tööjõud, kes reaalselt projektiga tegeleb. Selline metoodika sobib eelkõige väiksematele või keskmise suurusega projektidele, mille nõuded võivad muutuda. Eeldatakse, et klient on kättesaadav kogu projekti vältel ning on võimeline andma tagasisidet tehtud tööle. Üldiselt jagatakse agiilsete meetodite puhul töö etappideks, kusjuures iga valminud etapp peab olema presenteeritav kliendile. | |||
Agiilseid arendusmetoodikaid on mitmeid. Antud töös keskenduti Scrumile, Kanbanile ning Ekstreemprogrammeerimisele. Need kõik esindavad agiilses arenduses erinevaid seisukohti. Antud välearenduse metoodikad on ülevaatlikult toodud järgnevas tabelis. | |||
{| class="wikitable" | {| class="wikitable" | ||
! Arendusmudel | ! Arendusmudel | ||
! Scrum | ! Scrum | ||
Line 534: | Line 547: | ||
! Võtmeväärtused / märksõnad | ! Võtmeväärtused / märksõnad | ||
| | | | ||
* läbipaistvus | * läbipaistvus | ||
* kontroll | * kontroll | ||
* kohanemine | * kohanemine | ||
| | | | ||
* | * töös olevad ülesanded | ||
* | * pidev areng | ||
* | * fookus töö lõpetamisel | ||
* | * eneseorganiseerimine | ||
* tiimi motivatsioon | |||
| | | | ||
* kommunikatsioon | * kommunikatsioon | ||
Line 554: | Line 568: | ||
* arendusmeeskond | * arendusmeeskond | ||
* Scrum'i juht | * Scrum'i juht | ||
| | | Kanban ei defineeri meeskonna rolle | ||
| Põhiliselt: | | Põhiliselt: | ||
* juht | * juht | ||
Line 563: | Line 577: | ||
! Meeskonna suurus | ! Meeskonna suurus | ||
| Kuni 10 liiget | | Kuni 10 liiget | ||
| | | Kanban ei defineeri meeskonna suurust | ||
| Kuni 12-15 liiget | | Kuni 12-15 liiget | ||
|- | |- | ||
Line 573: | Line 587: | ||
! Tööjaotus | ! Tööjaotus | ||
| Sprindid kestusega 1 kuni 4 nädalat. Kestus püsib kogu tootearenduse protsessei vältel üldiselt sama. | | Sprindid kestusega 1 kuni 4 nädalat. Kestus püsib kogu tootearenduse protsessei vältel üldiselt sama. | ||
| | | Soovituslikud on iteratiivsed arendused (tihti kasutatakse koos Scrumiga, kus on tööjaotus konkreetsem) | ||
| Iteratsioonid, tüüpiliselt kestusega 1 kuni 2 nädalat<ref>"Differences Between Scrum and Extreme Programming", Mike Cohn, 2007, https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming</ref> | | Iteratsioonid, tüüpiliselt kestusega 1 kuni 2 nädalat<ref>"Differences Between Scrum and Extreme Programming", Mike Cohn, 2007, https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming</ref> | ||
|- | |- | ||
Line 580: | Line 594: | ||
Iga Sprindi lõpus Sprint Review. | Iga Sprindi lõpus Sprint Review. | ||
Pärast Sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist retrospektiiv | Pärast Sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist retrospektiiv | ||
| - | | Soovituslik: retrospektiiv, stand-up'id | ||
| Iteratsiooni plaanimise koosolek <ref>"Planning and Running an XP Iteration", Martin Fowler, 2001, https://martinfowler.com/articles/planningXpIteration.html#id267165</ref>, Igapäevane Stand-up <ref>"Daily Stand up meeting", Don Wells, 1999, http://www.extremeprogramming.org/rules/standupmeeting.html</ref> | | Iteratsiooni plaanimise koosolek <ref>"Planning and Running an XP Iteration", Martin Fowler, 2001, https://martinfowler.com/articles/planningXpIteration.html#id267165</ref>, Igapäevane Stand-up <ref>"Daily Stand up meeting", Don Wells, 1999, http://www.extremeprogramming.org/rules/standupmeeting.html</ref> | ||
|- | |- | ||
! Töö limiteerimine | ! Töö limiteerimine | ||
| | | Tööde maht pannakse paika sprindi nõuete nimekirjaga (''Sprint Backlog'') <ref name="ScrumGuide"></ref> | ||
| Samal ajal töös olevate tööde hulk on piiratud | | Samal ajal töös olevate tööde hulk on piiratud | ||
| Töömahu planeerimist ja limiteerimist aitavad otsustada mõõdikud | | Töömahu planeerimist ja limiteerimist aitavad otsustada mõõdikud | ||
|- | |- | ||
! Eksklusiivsus | ! Eksklusiivsus | ||
| | | Ei välista teiste arendusmetoodikate kasutust | ||
| Ei välista teiste arendusmetoodikate kasutust | | Ei välista teiste arendusmetoodikate kasutust | ||
| XP on terviklahendus ja seega pigem teisi lahendus välistavam | | XP on terviklahendus ja seega pigem teisi lahendus välistavam | ||
Line 595: | Line 609: | ||
! Programmeerimisele spetsialiseeritud? | ! Programmeerimisele spetsialiseeritud? | ||
| Tavapäraselt kasutatakse programmeerimist hõlmavate projektide puhul<ref>"Scrum - what it is, how it works, and why it's awesome", https://www.atlassian.com/agile/scrum</ref> | | Tavapäraselt kasutatakse programmeerimist hõlmavate projektide puhul<ref>"Scrum - what it is, how it works, and why it's awesome", https://www.atlassian.com/agile/scrum</ref> | ||
| Ei ole | | Ei ole programmeerimisele spetsialiseeritud | ||
| Tugevalt spetsialiseeritud programmeerimisele | | Tugevalt spetsialiseeritud programmeerimisele | ||
|- | |- | ||
! Millistele projektidele sobib paremini? | ! Millistele projektidele sobib paremini? | ||
| | | Scrum on hästiskaleeruv, kuid on pigem välja töötatud väiksemate projektide jaoks <ref name="Rossberg"></ref><ref>"Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies", Jeff Sutherland, 2001, http://jeffsutherland.com/papers/scrum/Sutherland2001AgileCanScaleCutter.pdf</ref> | ||
| | | Väiksemaks osadeks hästi tükeldatavad projektid | ||
| Kuni keskmise kriitilisusega projektid | | Kuni keskmise kriitilisusega projektid | ||
|- | |- | ||
Line 607: | Line 621: | ||
| Sobib kaugtööks<ref>"Kanban for Remote Team Leadership | Applied Frameworks", https://appliedframeworks.com/kanban-for-remote-team-leadership/</ref> | | Sobib kaugtööks<ref>"Kanban for Remote Team Leadership | Applied Frameworks", https://appliedframeworks.com/kanban-for-remote-team-leadership/</ref> | ||
| Kaugtöö võib tekitada probleeme paarisprogrammeerimise ja muude XP põhimõtete osas, kuid on võimalik | | Kaugtöö võib tekitada probleeme paarisprogrammeerimise ja muude XP põhimõtete osas, kuid on võimalik | ||
|- | |||
!Nõrgad kohad | |||
| | |||
* Suurem vastutus võib viia arendusmeeskonna liikmete läbipõlemiseni <ref name="Overhage"></ref> | |||
* Mudeli enda suurem keerukus võib muutuda arendajatele väsitavaks <ref name="Overhage"></ref> | |||
* Toetub olulisel määral meeskonnaliikmete pidevale suhtlusele ja heale läbisaamisele <ref name="EspinosaCuriel"></ref><ref name="Rasnacis"></ref><ref name="LawCharron"></ref> | |||
| | |||
* Võib kiiresti laguneda | |||
* Tingib vajaduse pidevaks tööks | |||
* Puuduvad ajalised piirangud | |||
* Kõrgema prioriteediga tööd võivad jääda tagaplaanile | |||
| | |||
* Liiga suur fookus koodil, mis võib jätta ülejäänud aspektid unarusse<ref name=HyggerXP>"Advantages and disadvantages of Extreme Programming (XP)", | |||
Pavel Kukhnavets, 2018, https://hygger.io/blog/disadvantages-and-advantages-of-extreme-programming/</ref> | |||
* Ei mõõda koodi kvaliteeti<ref name=HyggerXP /> | |||
* 2005. aasta teadusartikkel leiab, et XP'd ei ole mõistlik kasutada hariduskeskkonnas.<ref name=XPEdu /> | |||
|} | |} | ||
Väledaid metoodikaid saab omavahel üsna hõlpsasti kombineerida, heaks näiteks on Scrumi ja Kanbani ühismeetod Scrumban. Samas on näha, et ekstreemprogrammeerimine on pigem eraldiseisev metoodika. Samuti, Scrumi ja Kanbani sobib kasutada ka kaugtöös. Ekstreemprogrammeerimine aga eeldab näost näkku suhtlust, seda peamiselt paarisprogrammeerimise seisukohast. | |||
Kui Scrum ja ekstreemprogrammeerimine on arendusmetoodikad, siis Kanban seda pole. Kanban ei kirjelda, kuidas tarkvara peaks arendama. Seetõttu on näha, et kui Scrumi ja ekstreemprogrammeerimise puhul on üldiselt kindlaksmääratud meeskonna suurus ning meeskonnas sisalduvad rollid, siis Kanban neid ei defineeri, muutes selle kasutamise võimalikuks ka muudes eluvaldkondades. | |||
Artiklis toodud metoodikate ühiseks tunnuseks on aga pidev suhtlus ning regulaarsed koosolekud tiimiga. See on vastavuses ka agiilsete tarkvaraarenduste põhiprintsiipidega, kus pannakse suurt rõhku meeskonnale ning selle arengule. Just inimeste omavaheline pidev suhtlus on peamine faktor, miks paljud tarkvaraarendajad just väledaid metoodikaid eelistavad. | |||
==Kasutatud materjalid== | ==Kasutatud materjalid== | ||
<references /> | <references /> |
Latest revision as of 11:16, 8 May 2020
Sissejuhatus
Välearendus on kiire tarkvaraarendus, kus kasutatakse agiilseid metoodikaid. Agiilsete metoodikate väljatöötamine sai alguse 1990. aastatel, kui tarkvaraarendajad mõistsid, et traditsioonilised tarkvaraarenduse meetodid paljude projektide jaoks ei sobi.
Traditsioonilised tarkvaraarenduse meetodid (nt kosemudel ja spiraalmeetod) panevad rõhku hoolikale projektiplaneerimisele, rohkele dokumentatsioonile ja süsteemidisainile enne arendustöö algust. Kuigi neid meetodeid on aja jooksul märkimisväärselt edasi arendatud, pole muudatused saanud jagu traditsiooniliste mudelite peamistest nõrkustest, milleks on lõhkised eelarved, võimetus ajagraafikus püsida ja vigased tooted – ühesõnaga ebaõnnestunud projektid. Samuti pole edasiarendused oluliselt tõstnud tootlikkust, usaldusväärsust ega mudelite lihtsust.[1]
Välearenduse puhul eeldatakse, et projektides tuleb muutusi ette niikuinii ning neid tuleb hallata, mitte vältida [2]. Välearendus seab fookusesse inimesed, kes tarkvaraarendust teostavad ja kuidas nad koos töötavad. Lahendused valmivad iseorganiseeruvate ja polüfunktsionaalsete meeskondade koostöö tulemusena [3]. Lähemalt võrreldakse traditsioonilist ja väledat tarkvaraarendust alljärgnevas tabelis [4].
Kategooria | Traditsiooniline tarkvaraarendus | Väle tarkvaraarendus |
---|---|---|
Juhtimisstiil | Käskiv ja kontrolliv | Koostööl põhinev |
Suhtlus kliendiga | Ametlik | Mitteametlik |
Arendusmudel | Elutsükli mudel (tarkvara spetsifitseerimine, arendamine, testimine toimub eraldi tsüklitena) | Evolutsiooniline mudel (arendamist, testimist tehakse kogu aeg, pidevalt) |
Organisatsiooniline korraldus | Mehhaaniline, suunatud suurtele projektidele | Orgaaniline, suunatud väikestele ja keskmistele projektidele |
Kvaliteedi tagamine | Keerukas planeerimine ja range kontroll | Nõuete, disaini ja lahenduste pidev kontroll |
Arenduse suunitlus | Kindlalt määratletud | Kergesti muudetav |
Kliendi kaasatus | Madal, klient näeb toodet siis, kui rakendus on valmis | Kõrge, klient on osa arendajate meeskonnast ning näeb tulemust pärast iga muudatust |
Testimine | Pärast koodi valmimist | Arenduse käigus, pidevalt |
Täiendavad nõudmised arendajatele | Pole | Suhtlemisoskus ja põhiteadmised kliendi äriloogikast |
Projekti sobiv suurus | Suuremad projektid | Väiksemad ja keskmised projektid |
Nõuded | Stabiilsed, projekti alguses teada | Pidevalt muutuvad |
Esmane eesmärk | Kõrge turvalisus | Kiire tulemus |
Meeskonna suurus | Suur | Väike |
Esmalt käsitleb käesolev artikkel välearendust üldisemalt ning seejärel tutvustab lähemalt kolme tuntumat agiilset metoodikat: Scrum’i, Kanban’i ja ekstreemprogrammeerimist, seades fookuse nende professionaalsetele ja sotsiaalsetele aspektidele.
Välearenduse põhimõtted ja -printsiibid
2001. aastal sõnastas grupp tarkvaraarendajaid välearenduse põhimõtted ja -printsiibid, millele agiilsed metoodikad peaksid toetuma. [1]
Agiilse tarkvaraarenduse põhimõtted
Tarkvara luues hinnatakse alljärgnevas tabelis vasakpoolses tulbas olevaid tegureid kõrgemalt, teadvustades samas ka parempoolse tulba tegurite väärtust [5].
Rohkem hinnatakse | Vähem hinnatakse |
---|---|
Inimesi ja nendevahelist suhtlust | Protsesse ja arendusvahendeid |
Töötavat tarkvara | Kõikehõlmavat dokumentatsiooni |
Koostööd kliendiga | Läbirääkimisi lepingute üle |
Reageerimist muutunud oludele | Algse plaani järgimist |
Agiilse tarkvaraarenduse põhiprintsiibid
Agiilse tarkvaraarenduse 12 põhiprintsiipi on järgmised [6]:
- Kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti.
- Mõistame muutuvaid olusid, isegi kui need ilmnevad arenduse lõppjärgus. Agiilsed meetodid pööravad sellised muutused meie kliendi konkurentsieeliseks.
- Tarnime tarkvara nii tihti kui võimalik, soovitavalt iga paari nädala kuni paari kuu tagant.
- Valdkonna spetsialistid ja tarkvaraarendajad peavad töötama igapäevaselt koos kogu projekti vältel.
- Projekti edukuse aluseks on motiveeritud inimesed. Loo neile meeldiv ja toetav töökeskkond ning nad saavad iseseisvalt tööga hakkama.
- Kõige tõhusam ja tulemuslikum viis info jagamiseks arendusmeeskonnas on näost näkku vestlus.
- Edu peamiseks mõõdupuuks on töötav tarkvara.
- Agiilse tarkvaraarenduse protsessid soodustavad jätkusuutlikku arendust. See tähendab, et projektiga saab samas tempos jätkata määramata aja jooksul.
- Tehnilist täiuslikkust ja head disaini pideva tähelepanu all hoides tagatakse tarkvaraarenduse kiirus ja paindlikkus.
- Lihtsus - ebavajaliku töö tegematajätmise kunst - on väga oluline.
- Parimad arhitektuurilised lahendused, nõuded ja disain tekivad iseorganiseeruvates meeskondades.
- Meeskond otsib regulaarselt võimalusi saamaks veelgi tõhusamaks ja muudab end vastavalt vajadusele.
Scrum
![](/images/thumb/e/e9/Ken_Schwaber.jpg/200px-Ken_Schwaber.jpg)
![](/images/thumb/3/31/Jeff_Sutherland.jpg/200px-Jeff_Sutherland.jpg)
![](/images/thumb/3/34/Hirotaka_Takeuchi.jpg/200px-Hirotaka_Takeuchi.jpg)
Ajalugu
Scrumi esitleti avalikkusele esmakordselt aastal 1995 Jeff Sutherlandi ja Ken Schwaberi poolt. Samas on mudeli autorid öelnud, et tegemist pole mingi enneolematu lähenemisega – sarnaseid praktikaid on kasutatud ka varem. Nii Sutherlandi kui Schwaberi jaoks oli Scrumi lõplik mudel aastatepikkuse kogemuste ja õppimise tulemus. [7]
Mudeli mõlemad autorid osalesid aastatel 1967-1975 Vietnami sõjas. Sellel perioodil oli riskide hindamine meestele igapäevaelu loomulikuks osaks ning mõjutas ilmselt nende mõttelaadi ka tulevikus. Pärast sõda asusid mõlemad tööle tarkvaraarenduses ning hoidsid teineteisega kontakti. [7]
Ken Schwaber
Ken Schwaber asutas pärast kümneaastast tarkvaraettevõttes töötamise kogemust 1985. aastal omaenda firma. Ta on öelnud, et ettevõttes töötamine tekitas temas palju stressi ning ta ei saanud aru, miks projektide õigeaegne ja edukas elluviimine ning inimeste meeskonnana tööle panemine oli niivõrd raske. Tollal lõppesid edukalt ligi 45% projektidest, mille kallal ta töötas. Inimestele ei meeldinud nende töö ja nad kippusid liikuma teistesse ettevõtetesse lootuses sealt midagi paremat eest leida. [7]
Schwaber oli kosemudeli entusiast ning üritas seda oma projektides edutult rakendada. See pani teda mõistma, et tarkvaratööstus vajab muudatust. Ta on hiljem kirjutanud, et kosemudeli puhul eeldatakse, et tarkvaraarendus on protsessina lihtsasti hoomatav ning ootamatute tagajärgede ja probleemideta, kuid nii see tegelikkuses ei ole – tarkvaraarendus on paljudel põhjustel väga etteaimamatu. [7]
Jeff Sutherland
Jeff Sutherland sai 1986. aastal ettevõttes Saddlebrook Corporation vastutavaks sularahaautomaatidega tegeleva osakonna eest. Seal seisis ta silmitsi traditsioonilise projektihalduse probleemidega, kus ei suudetud tähtaegadest kinni pidada ning kasutajate rahulolu ja kvaliteet olid madalad. Sutherland tahtis nendele probleemidele lahenduse leida ja seda ta ka tegi. Ta muutis sularahaautomaatide osakonna ettevõttes kõige probleemsemast ja vähem kasumlikumast üksusest kuue kuuga kõige edukamaks. [7]
Sutherland õpetas oma meeskonda protsessi paremini juhtima, võrreldes seda lennuki maandamisega. Piloodil tuleb pikkamisi allapoole laskuda, täites ülesande ülesande haaval ja maanduda lõpuks edukalt lennurajale. Selle protsessi juures pidas ta oluliseks kolme aspekti: meeskonnaliikmete töö tulemused peavad olema kõigi jaoks nähtavad, iga liige peab vastutama talle määratud ülesannete eest ning meeskond peab suutma oma tööd ise ümber korraldada. See kogemus näitas Sutherlandile, et on olemas vajadus uue arendusmetoodika järgi, mis sobiks paremini nii arendajatele kui ka klientidele ning aitaks projektidel õigeaegselt valmis saada. [7]
Nendele kogemustele tuginedes töötasid Schwaber ja Sutherland 4-5 aastat välja uut arendusmudelit, mis oleks paindlikum, annaks liikmetele protsessi üle rohkem kontrolli, aitaks kaasa loomingulisusele ning võimaldaks paremini hallata riske ja kulutusi. [7]
The New New Product Development Game
Ülimalt oluliseks ideede allikaks uue tarkvaraarendusmetoodika kujundamisel oli 1986. aastal Hirotaka Takeuchi ja Ikujiro Nonaka poolt avaldatud artikkel „The New New Product Development Game“. See käsitles mõnes Jaapani ja USA firmas kasutatavat uudset ja holistilist tootearenduse lähenemist, mis muutis protsessi kiiremaks ja paindlikumaks ning aitas ettevõttes muutuseid läbi suruda. Need praktikad pärinesid tollastelt edukatelt firmadelt nagu Xerox, Canon, Honda ja Hewlett-Packard. Tootearenduse meeskonna tegevust võrdlesid Takeuchi ja Nonaka ragbitiimiga, mis liikus ühtse üksusena lõppeesmärgi saavutamiseks edasi, tegutsedes koos tekkinud takistuste ületamisega [8]. Samast artiklist pärineb ka Scrumi nimetus – ragbis nimetatakse scrumiks palli mängupanemise momenti, kus meeskondade ründajad palli oma tiimile võitmiseks rüselevad [9].
Takeuchi ja Nonaka tõid oma artiklis näite uue auto väljatöötamisest Toyotas. Töötajad said korralduse valmistada auto, mille kütusekulu oleks varasematest kaks korda väiksem ja saada auto valmis kaks korda kiiremini kui senised mudelid. Traditsioonilisi meetodeid kasutades olnuks selle ülesande täitmine võimatu, kuid arendusmeeskond suurendas koostööd ja muutus iseorganiseeruvaks, et kogu protsessi kiirendada. [8]
Sutherland leidis, et samasugust lähenemist tuleb rakendada ka tarkvaraarenduses. Eriti oluliseks pidas ta meeskondade autonoomsust, üksteiselt õppimist ja ühist eesmärkide poole liikumist, toetudes meeskonnaliikmete kirglikkusele. 1994. aastal alustas Sutherlandi osavõtul tööd esimene Scrum tarkvaraarendustiim. Järgmisel aastal avaldasid Sutherland ja Schwaber Scrumi tutvustava artikli. Mõlemad olid tegevad ka välearenduse põhimõtete („Manifesto for Agile Software Development“) kirjapanekul 2001. aastal [7] . Kuigi Sutherland ja Schwaber sõnastasid esimesena Scrumi raamistiku tarkvaraarenduse kontekstis, peavad paljud Takeuchi ja Nonaka mõju sedavõrd oluliseks, et nimetavad neid Scrumi loojateks ka tarkvaramaailmas [10][11].
Sisu
Võtmeväärtused
Scrum rajaneb empiirikale, mis tähendab, et teadmised tulenevad kogemustest ja otsuste langetamine teadaolevatest faktidest. Mudel on iteratiivse ja järk-järgulise lähenemisega, tehes nii projektiga seotud prognoositavuse ja riskide haldamise lihtsamaks. [12]
Scrum tugineb kolmele põhiväärtusele [12]:
- läbipaistvus – protsessi olulised aspektid peavad olema kõigile meeskonna liikmetele nähtavad
- kontroll – vigade vältimiseks tuleb aeg-ajalt kontrollida tehtud töö vastavust soovitud eesmärgile
- kohanemine – vigade eemaldamine ja ebasoovitavate aspektide parandamine tuleb edasiste probleemide vältimiseks teha võimalikult vara
Scrum meeskond
Scrum meeskond koosneb tooteomanikust, arendusmeeskonnast ja Scrumi juhist (Scrum Master). Scrum meeskonnad on iseorganiseeruvad ja polüfunktsionaalsed. See tähendab, et meeskond ise otsustab, kuidas neile seatud ülesannet täita ning nad ei vaja töö teostamiseks abi teistelt väljaspool tiimi – kogu vajalik kompetents on meeskonnas endas olemas. [12]
Tooteomanik on isik, kes vastutab nende ees, kes on toote tellinud. Tema ülesandeks on olla vahelüli kliendi ja arendusmeeskonna vahel. Ta peab tagama esialgse projekti rahastamise ning veenduma, et seda jätkuks terveks tootearendustsükliks. Tooteomanik esindab kõiki, kes on panustanud projekti ja selle tulemusse. Projekti alguses kogub ta esialgsed nõuded ning paneb need tööde nimekirja (Product Backlog). Tema otsustab, millised nõuded on tähtsamad ning millises iteratsioonis neid arendama peaks hakkama. Projekti käigus kontrollib tooteomanik projekti edenemist ning kliendi vajaduste täitmist. [12][4][13]
Arendusmeeskond vastutab toote arendamise eest. Meeskonnas pole igal liikmel kindlat rolli – nad peavad tagama selle, et tiimis oleks olemas töö teostamiseks kõik vajalikud oskused ja inimesed. Arendusmeeskond peab olema piisavalt väike, et protsessi mitte kohmakaks muuta ning piisavalt suur, et vajalike tööde teostamisega õigeaegselt hakkama saada. Keskmiselt on meeskonnas aga seitse inimest. Tüüpiliselt on seal kaks-kolm programmeerijat, kaks-kolm testijat, üks analüütik/disainer ja üks dokumenteerija. Meeskond ise otsustab, milliste nõuete realiseerimisega iga iteratsiooni jooksul tegeletakse. [12][4][13]
Scrumi juht vastutab selle eest, et töö Scrum meeskonnas vastaks Scrum teooriale, praktikale ja reeglitele. Ta peab tagama, et kõik arendusmeeskonna liikmed, tooteomanik ning teised projekti kaasatud inimesed mõistavad arendusprotsessi. Kui tekivad konfliktid, siis peab Scrumi juht need lahendama ning tagama arendusmeeskonnale rahuliku töökeskkonna koos kõige vajalikuga. [12][4][13]
Töövoog
![](/images/thumb/d/df/Scrum_Framework.png/400px-Scrum_Framework.png)
Scrumis toimub tarkvaraarendus iteratsioonides, mida nimetatakse sprintideks. Iga sprindi lõpuks, mis kestavad 1-4 nädalat, loob arendusmeeskond tarkvarast potentsiaalselt valmis versiooni, mis töötab ning mida on testitud. Sprintide ajaline kestvus on üldiselt kogu tootearenduse protsessi jooksul sama. [12][4]
Nõuded (Sprint Backlog), mida soovitakse realiseerida ühe sprindi jooksul, on kirja pandud toote tööde nimekirja (Product Backlog), kus on kõik tarkvara nõuded järjestatud nende tähtsuse järgi. Seda, milliseid toote osi sprindi jooksul arendama hakatakse, otsustatakse sprindi planeerimise (Sprint Planning) koosolekul. Sellel koosolekul teavitab tooteomanik arendusmeeskonda, milliseid toote osi peaks nad sprindi jooksul arendama hakkama ning seejärel määrab meeskond ära, milliseid neist saaksid nad teostada. Sprindi ajal ei ole kellelgi sprindi tööde nimekirja muuta lubatud. [12][4]
Iga päev algab 15-minutilise arendusmeeskonna koosolekuga (Daily Scrum või stand-up), kus arutatakse, milliste nõuetega tegeleti eelmisel päeval ning millega tegeletakse eelseisval päeval [14]. Iga arendusmeeskonna liige vastab järgmistele küsimustele [12]:
- Mida ma tegin eile, et aidata arendusmeeskonnal sprindi eesmärki (Sprint Goal) täita?
- Mida ma teen täna, et aidata arendusmeeskonnal sprindi eesmärki täita?
- Kas ma näen enda või arendusmeeskonna töös sprindi eesmärgi täitmisel takistusi?
Iga sprindi lõpus korraldatakse sprindi ülevaate koosolek (Sprint Review), kus tutvustatakse sprindi käigus tehtud töid, tekkinud probleeme ja tehakse vajadusel parandusi toote tööde nimekirja. Koosolekul osalevad Scrum meeskond ja toote tellija/huvirühmad. Kuuajaliste sprintide puhul on koosoleku pikkuseks umbes neli tundi, lühemate sprintide puhul vähem. Lisaks toimub pärast sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist ka sprindi retrospektiiv (Sprint Retrospective), mis on koosolek, mille käigus Scrum meeskond analüüsib enda tööd lõppenud sprindi jooksul ning otsustab, mida järgmises sprindis paremini teha. Kuuajalise sprindi puhul kestab retrospektiiv üldjuhul umbes kolm tundi, lühemate sprintide puhul vähem. [12]
Scrumi juurutamise sotsiaalsest mõjust
On avaldatud mitmeid teadusartikleid, milles kirjeldatakse Scrumi juurutamise mõju traditsioonilistes arendusmeeskondades. Juurutamisega seoses tuuakse välja nii positiivseid aspekte kui ka probleeme.
Ei tasu eeldada, et agiilsete metoodikate juurutamiseks arendusmeeskonnas piisaks vaid meeskonnaliikmetele vastava metoodika tutvustamisest. Juurutamisprotsess nõuab muuhulgas olulisi muudatusi tööprotseduurides, tööriistades, sidekanalites, probleemilahendamise strateegiates, arendusmeeskonna liikmete rollides ja meeskonna sotsiaalses ülesehituses. Lisaks peavad muutustega kaasa minema ka teised tiimid ja osakonnad, juhtkond ning teised töötajad. Ühtlasi on välearenduse meeskonnad sotsiaalse loomuga, mistõttu vajab juurutamisprotsess muutuseid töötajatevahelises suhtluses ja koostööviisis. [15]
Mitmed teadlased on rõhutanud suhtluse olulisust välearenduses. See hõlmab nii ametlikku kui mitteametlikku, suulist ja kirjalikku suhtlust. Tähtis roll on siin välearenduse praktikatel: igapäevastel koosolekutel, retrospektiividel ja sellel, et tüüpiliselt paigutatakse meeskonnad füüsiliselt üksteisele lähedale. Lisaks tuuakse välja sotsiaalse vastastikmõju kasvu, mis avaldub nii meeskonda liitvates kui ka lõhkuvates tegevustes. Sageli kerkivad traditsioonilistes arendusmeeskondades Scrumi juurutamisel esile inimeste isiklikud ja nendevahelised sotsiaalsed probleemid, mis suhtlust ja sotsiaalset vastastikmõju mõjutavad. [15][16][17]
Paljud arendajad ja meeskonnad toonitavad aga Scrumi positiivseid külgi. Scrum suurendab meeskonna ühtekuuluvustunnet ja aitab liikmetes tekitada tunnet, et nende tööl ja otsustel on kaalu. Samuti suurendab see koostööd, meeskonna motivatsiooni ja vastutust, mis viib omakorda meeskonna ühise arusaamani jagatud juhtimisest, eesmärkidest, kohustustest ja ajagraafikus püsimisest. [15][17]
Professionaalsed aspektid
Vähem dokumentatsiooni
Scrum vähendab märkimisväärselt arendustöö käigus loodava dokumentatsiooni hulka. Agiilsete metoodikate juures väidetakse lausa, et kood ise peaks olema dokument. Agiilsete metoodikatega rohkem harjunud arendajad lisavad pigem kommentaare koodi. Paljud arendajad aga osutavad, et vähene dokumentatsioon teeb uutel arendajatel olemasolevate projektide mõistmise ja nendele muudatuste tegemise väga keeruliseks. [1][17]
Dokumentatsiooni vähendamise eesmärgiks on Scrumis arendusmeeskonna sees oskusteabe jagamine ja seeläbi selles osas kõigi liikmete võrdsena hoidmine. Kui aga seda õigesti ei tehta, võib sellest tekkida suur probleem. Näiteks, kui arendusmeeskonna peamine arendaja peaks töölt lahkuma, võib ettevõttel kuluda kuid tekkinud oskusteabe lünga täitmiseks. Praktikas on selliste situatsioonide täielik vältimine aga sisuliselt võimatu. [1]
Koosolekud
Samuti tuleb Scrumis pidada kinni koosolekute reeglitest ja headest tavadest – nii on nendest kõige rohkem kasu. Koosolekute ajaline kestvus on ette määratud ja need ei tohiks venida pikemaks. Seoses paindliku töögraafikuga võivad tekkida probleemid ka koosolekute ajastamisega. Näiteks, kui koosolekud toimuvad hommikuti ja meeskonnaliikmed tulevad tööle erinevatel aegadel, võib koosoleku pidamine häirida nende inimeste keskendumist, kes jõudsid tööle juba varahommikul. [1]
Klientide pühendumus
Scrumi, nagu ka teiste agiilsete metoodikate, puhul on oluline, et klient oleks arendusprotsessi loomulik osa alates tarkvara analüüsist kuni juurutamiseni välja. Seetõttu võib kliendi pühendumus paljudel puhkudel mängida projekti õnnestumise juures väga olulist rolli – kui kliendi esindajad ei ole altid arendusmeeskonnaga suhtlema, on suurem tõenäosus, et tulemus ei ole see, mida nad ootasid. [1]
Töökeskkond
Scrumi sotsiaalse loomu tõttu sobib protsessiks paremini avatud kui vaheseintega eraldatud ruum või eraldiseisvad kabinetid. See mõjub hästi meeskonna suhtlusele ja avatusele, kuid ei pruugi kõigile arendajatele sobida, sest ruumis võib olla mitmeid keskendumist segavaid faktoreid [1]. Teadlased on aga uurinud ka ruumi ümberkujundamise lahendusi, et see toetaks Scrumi protsessi paremini ning annaks töötajatele võimalusi keskendumiseks ja puhkamiseks [18]. Samuti on Scrumi võimalik edukalt rakendada ka kaugtöös [19].
Mõju arendajatele ja meeskondadele
Scrum võib mõjuda arendajatele väga motiveerivalt, sest see toetab üksteiselt õppimist, suurendab meeskondade ja nende liikmete autonoomsust ning soodustab inimestevahelisi suhteid. Isiklikel konfliktidel võib aga motivatsioonile olla negatiivne mõju, seetõttu peaks kogu meeskond arvestama üksteise isikupäradega [17]. Kui meeskonna ühtekuuluvustunne on madal, liikmetevahelised suhted kehvad või inimesed vähemotiveeritud, soovitatakse meeskondade ümberorganiseerimist, projektijuhi rolli kaasamist, paaristöid ja motivatsiooni tõstmise meetmeid [16]. Lisaks võib Scrumi mudelist tulenev suurem vastutus ja mudeli enda keerukus võrreldes traditsiooniliste tarkvaraarenduse metoodikatega viia arendajate läbipõlemiseni ja avaldada mõju mudeli sobivusele pikas perspektiivis [20].
Võimalikud väljakutsed Scrumi juurutamisel
Scrumi juurutamise juures on välja toodud mitmeid esineda võivaid väljakutseid [15].
Isiklikud väljakutsed:
- Töötajate suhtumise ja mõttemaailma muutmine
- Vajadus eriti andekate töötajate järele
- Töötajate vähene motiveeritus ja pühendumus
- Liialt entusiastlikud töötajad
- Välearenduse kogemuse puudumine
- Laiemate oskustega arendajate vähesus
- Kokkupuude väheste oskustega töötajatega
- Ebapiisav õppimisvõime
- Sotsiaalselt aktiivne olemisega kaasnev stress
- Meeskonnatööoskuse efektiivsus
Sotsiaalsed väljakutsed:
- Avatus ja teistesse töötajatesse suhtumine
- Vähene suhtlemine
- Vähene koostöö
- Usaldus ja ühised mõttemudelid
- Ühine juhtimine
- Ühine õppimine koos meeskonnaga
Väljakutsed juhtkonnale:
- Juhtimine mikrotasandil
- Juhtkonna suhtumine
- Organisatsiooni mõju ja kontroll
- Jagatud inimressursid
Organisatsioonilised väljakutsed:
- Kultuur
- Struktuur
- Muutuste juhtimine
- Teadmiste juhtimine
- Premeerimissüsteem
- Vananenud otsustusmudelid
- Spetsialistide kultuur
- Logistilised probleemid
- Välearenduse teostamise hindamine
Projektidega seotud väljakutsed:
- Projekti teostamine
- Progressi jälgimine
- Tehtud töö nähtavus teiste jaoks
- Kliendi panus
- Töö sünkroniseerimine
- Vähene arusaam äriloogikast
Võimalikud tegevused Scrumi juurutamise toetamiseks
Traditsioonilistes tarkvaraarenduse meeskondades Scrumi juurutamise toetamiseks on mitmeid võimalusi [15].
Teadlikkuse suurendamine:
- Töötajate, meeskonna ja organisatsiooni probleemide kindlaks tegemine
- Töötajatele arvamuste, tunnete, kahtluste ja hirmude väljendamiseks võimaluse loomine
- Toimepandavatele muudatustele osutatava eeldatava vastupanu vähendamine
- Töötajate motiveerimine
- Toimepandavate muudatuste kohta info jagamine
Organisatsioonipoolne sekkumine:
- Juurutamisprotsessi suunamine ja tekkivate probleemidega tegelemine
- Avatud õhkkonna loomine arvamuste, ettepanekute ja tagasiside esitamiseks
- Konfliktide lahendamine ja toimepandavatele muudatustele soodsa pinnase loomine
- Ametlike suhtlusmehhanismide ja tööprotsesside määratlemine
- Töötajate jaoks organisatsiooni väärtuste omaksvõtmise hõlbustamine
Meeskonnatöö:
- Töötajate arengu hõlbustamine ja inimestevaheliste sotsiaalsete võimete arendamine
- Meeskonnatöökultuuri loomine
- Töötajate sotsiaalsete võimete arendamine (usaldus, empaatiavõime, avatus tagasisidele, muutustega kohanemine, oskusteabe jagamine jms)
- Töötajate isejuhtimisvõimete arendamine
Muu:
- Tööruumi muutmine meeskonnatöö ja suhtlemise parandamiseks
- Scrumi olemuse, rollide ja tegevuste selgitamine
- Scrumi praktikate juurutamine, uute väärtuste omaksvõtt ja koostöötegevuste rakendamine
Kanban
Mis on Kanban?
Kanban on töövoo manageerimise meetod, mille disain aitab töö tegemist visualiseerida ning saavutada maksimaalne produktiivsus ning efektiivsus. Sõna pärineb jaapanikeelsest sõnast “kamban”, mis tähendab suurt kuulutuse plakatit (ingl.k billboard) või kaarti. Selline töömetoodika sai alguse juba möödunud sajandi keskpaigas tootmissektoris, tarkvaraarendusse jõudis see tükk maad hiljem. Tänapäeval on tegu metoodikaga, mis on kasutuses üsna mitmes eluvaldkonnas.
Kanbani algus
![](/images/thumb/c/cd/Taiichi_Ohno.jpg/200px-Taiichi_Ohno.jpg)
Kanban kui metoodika sai alguse 1940ndate Jaapanis, kus Toyota insener Taiichi Ohno soovis parandada autotööstuse kitsaskohti ning muuta Jaapani autotööstus efektiivsemaks ja kiiremaks kui nende Ameerika konkurentidel. Selle lahenduse, mille algne nimetus oli “just-in-time production”, eesmärk oli kontrollida ja manageerida tööd ja inventari optimaalselt igal tootmissammul – vähendada mitteolulisi tegevusi nii, et ka produktiivsus ei langeks. Tänu sellele lähenemisele suutis Toyota jõuda paindliku ja efektiivse tootmisvooni – tootmine sõltub klientide nõudlusest, aga mitte mentaliteedist toota võimalikult palju asju võimalikult kiiresti, mis oli tolle aja standardiks. [21]
Ohno on öelnud: “The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.". [22] Seega tuleb Kanbani puhul vaadata kogu süsteemi. Ideaalses süsteemis on kontrolli all kogu tootmisahel alates tooraine saamisest kuni lõppkasutajateni jõudmiseni. Tänu sellele on võimalik vältida toorainete ülejääki, kuid samas pakkuda klientide nõudluse vastava hulga lõpptooteid. See tähendab, et kogu tööl tuleb hoida silma peal ning erilist tähelepanu tuleb pöörata olukordadele, mis võivad saada nö pudelikaelaks tootmises. [21] Aja jooksul on selline mõtteviis jõudnud Jaapanist kaugemalegi.
IT sektorisse jõudis antud metoodika alles käesoleva sajandi alguses, kui David Anderson seda 2004. aastal Microsoftis tutvustas. Selle eesmärk oli limiteerida samal ajal töös olevate tööde hulka ning kasutada nö pull approach’i. See tähendas seda, et vastupidiselt sellele, et arendajatele söödetakse järjest ette ülesandeid, millega kohe tegelema peab hakkama, saab arendaja alustada uue taskiga, kui eelmine on lõpetatud.[23] Nüüdseks on see metoodika jõudnud väga paljude IT inimeste ja ettevõtete tööprotsessi.
Tuleb aga mainida, et kuigi kanban on ITs laialdaselt kasutusel ning seda kõrvutatakse tihti Scrumiga, ei ole selle näol tegemist tarkvaraarenduse- või projektiplaneerimise metoodikaga. Kanban ei ütle, kuidas tarkvara peaks arendama, planeerima või implementeerima. Seega pole Kanban juhtimisraamistik nagu seda on Scrum. Kanbani eesmärk on hoopis pidevalt parandada tööprotsessi kui tervikut. Seetõttu on Kanbani võimalik kasutada erinevate arendusmetoodikate raames, olgu selleks agiilsed meetodid nagu Scrum või ekstreemprogrammeerimine, või traditsioonilisemad nagu waterfall – Kanbani abil saab nende kõikide tööprotsessi parandada ning töövoogu efektiivsemaks muuta. [21]
Kanbani eripärad
Visualisatsioon
![](/images/thumb/f/f5/Kanban_board_example.jpg/200px-Kanban_board_example.jpg)
Visualiseerimine on oluline osa mõistmaks töövoogu ning tööd ennast. Seega on oluline luua raam, mis:
- On ühine kõikidele asjassepuutuvatele inimestele
- On eritähenduslik erinevatele inimestele
Üheks selliseks vahendiks/raamiks on Kanbanis ilmselt kõige tuntum Kanban board ehk vahend, millega märkida ära töövoog, ülesanded ning nende staatused.
Sõltuvalt ettevõttest ja board’i loojast, saab tahvlit kujundada erinevate värvide, kujundite ja materjalidega. Tarkvaraarenduses jaguneb tahvel tavaliselt mitmeks tulbaks, mis kujutavad endas ülesannete staatusi. Iga ülesannetega tegeleja peab hoidma tahvlit ajakohasena ning liigutama enda ülesandeid vastavalt staatusele järgmistesse tulpadesse.
Kanban board’i kasutamise tulemusena on võimalik märgata töövoos tekkinud probleeme (nt pudelikaelad, blokaatorid jne) kiiremini, tagades selle, et tiimil on võimalik sujuvamalt liikuda oma eesmärkide poole. Samuti on võimalik märgata probleeme, mis võivad potentsiaalselt kogu protsessi kulgu aeglustada – riskide manageerimine ja ohuolukordade avastamine on mugavam. [24]
Kanbani praktiseerimise lihtsustamiseks on loodud mitmeid tööriistu, sh Jira, Trello ja Hygger.
Töös olevad ülesanded (WIP)
Kanban limiteerib tööde hulka, mis võivad olla korraga “In progress”, st kasutatakse pull metoodikat. Pull ja push metoodikate erinevusest arusaamiseks võib tuua näite kirjaklambritega. Kui ühendada üksteise külge mitu kirjaklambrit ning panna need lauale, siis lükates viimast kirjaklambrit esimese suunas, tekib tõenäoliselt tropp ning kirjaklambrid kuhjuvad. Samas, kui tõmmata esimest kirjaklambrit edasi, liigub kogu kirjaklambrikett vabalt ning tõrgeteta. [24]
“In a pull system, work is processed through being signalled, rather than being scheduled.” [24]
Tarkvaraarenduses tähendab pull süsteem seda, et kuigi ülesandeid võib tulla juurde, on see tiimiliikme ülesanne otsustada, kas ta saab seda sel hetkel teha või mitte. Mida rohkem võetakse ülesandeid, seda rohkem saab neid juurde luua. Kui aga ülesandeid kiiresti ei võeta, on see signaal, et uusi ülesandeid juurde luua pole mõtet, et vältida ülesannete kuhjumist. Push süsteem tähendaks aga, et ülesandeid loodaks juurde hoolimata sellest, kas on ressurssi neid lahendada või mitte.[25]
Work in Progress’i limiteerimisel on suur mõju produktiivsusele ning tiimitööle.
Pidev areng
Kanbani süsteemi üks suurimaid eesmärke on üleüldse Kanbani süsteemist lahti saada. See tähendab, et tiimiliikmed peaksid alati otsima võimalusi, et töö liiguks edasi, mitte hoidma ennast kogu aeg rakkes. “Kanban is something you strive to get rid of, not be proud of”.[26]
Ühe võimaluse selleks annab WIP limiitide vähendamine. Kui piiravama limiidiga (st korraga võib laual olla vähe ülesandeid) töövoog paistab sujuvalt edasi liikuvat, võib suurendada "In progress" ülesannete arvu, et tuua välja järgmised kitsaskohad ja pudelikaelad. [24]
Vajadust limiidi muutmisele aitab leida retrospektiiv, kus tiimiliikmeid saavad arutada, kas tööd on liiga palju või vastupidi. Kui on pigem vähe, saab suurendada "In progress" ülesannete arvu ning pakkuda tiimiliikmetele rohkemate ülesannete näol uut arengut. [24]
Eesmärk on liikuda pidevalt “Flow zone”s. Mike Rother ja John Shook on öelnud Kanbani kohta: “Flow where you can, pull when you must”. [27]
Fookus töö lõpetamisel
![](/images/thumb/a/a5/Burn-out.jpg/250px-Burn-out.jpg)
Erinevate uuringute kohaselt satub 60% IT sektoris töötavatest inimestest mingil hetkel olukorda, kus toimub läbipõlemine (burn-out)[28]. Selle põhjuseks on suuresti see, et töötajad peavad tihti end ümber lülitama mõnd teist ülesannet tegema, mistõttu tuleb end uuesti teise konteksti seada. Gerald Weinberg on oma raamatus “Quality Software Management: Systems Thinking” öelnud, et 20% ajast läheb kaduma iga uue ülesande puhul[29]. Seega kui ainult ühe ülesande tegemine korraga tähendab 100% ajakulu sellele ülesandele, siis kaks ülesannet korraga tähendab, et mõlema ülesande jaoks on keskmiselt 40% koguajast, kolme ülesande puhul on ühe ülesande ajakasutus 20% jne. Seega, mida vähem ülesandeid, seda väiksem ajakadu. Teada on, et multitaskimine kaugele ei vii. Lõppkokkuvõttes on ülesannete järjestikku tegemine tulemust andvam, kui nende samaaegne tegemine.
Kanbani metoodika vähendab võimalust ülesannete vahetamise tõttu läbi põleda, kuna limiteerib ülesannete hulka, mis võivad korraga olla tegemises. Seda kas üksikisiku seisukohast või kogu protsessi seisukohast. See tähendab, et töötajad saavad rohkem keskenduda käesolevale ülesandele ning viia see lõpule enne , kui nad uut alustavad. Ühelt poolt vähendab see aega, mis kulub ülesande lõpetamisele, teiselt poolt soodustab ka tiimitööd, kuna annab võimaluse aidata teisi tiimiliikmeid, kui oma ülesanded saavad tehtud ning uusi veel võtta pole vaja. [30]
Seega Kanbani seisukohast on igal arendajal neli valikut, järjestatud prioriteetselt [24]:
- Tööta edasi ülesande kallal, mille oled endale võtnud
- Aita tiimiliikmeid, et vältida pudelikaela efekti
- Alusta mõne uue ülesandega, kui on ülesandeid, mida teha
- Leia midagi muud kasulikku, mida teha
Eneseorganiseerimine
Projektijuhtimine ja sellega kaasas käivad nõuded on vajalikud, et saavutada projekti eesmärgid. See eeldab pidevat kontrolli projektijuhi poolt ning pidevat töötajate manageerimist. Kanbani puhul on palju rõhutud sellele, et kõik tiimiliikmed teaksid iga hetk, mida nad peaksid tegema ja millega ametis olema, ilma, et seda neile pidevalt öeldaks. Tänu sellele on tiimiliikmetel parem eneseorganiseerimise võimalus, mistõttu ollakse positiivsemalt meelestatud oma ülesannete suhtes ning lõppkasutajateni jõuab kvaliteetsem ja läbimõeldum toodang.[30]
Tiimi motivatsioon
Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab töötajstel hoida ülesanne fookuses ning olla osake nö suuremast masinast. See aitab kaasa ka töötaja rahulolule, kuna ta teab, et tema tööd hinnatakse ja vaadatakse pidevalt üle. Lisaks tõstab see personaalse heaolu taset, mis omakorda võimendab heaolu ka kogu tiimis või töötajaskonnas. [30]
Kanban kokkuvõtvalt
Kokkuvõtvalt võib öelda, et Kanbanil on palju eeliseid, mis teevad projekti manageerimise efektiivsemaks. Kanbani tugevused on [31]:
- Suurenenud läbilaskevõime – Kuna tiimiliikmed ei pea ootama, kuni neile ülesanne kätte antakse, vaid saavad ise olemasolevate hulgast valida, vähendab Kanbani kasutus jõude istumise aega.
- Parem suhtlus – Tiimiliikmed näevad ülevaatlikult kõikide ülesannete staatuseid Kanban board’ilt. Kanbani üks põhimõtetest on ka igapäevaste stand-up’ide tegemine, mis sunnib tiimiliikmeid oma tööst igapäevaselt aru andma, mis omakorda annab teistele tiimiliikmetele selgema pildi kogu olukorrast. See on heaks võimaluseks leida ka kitsaskohti ning üksteist ülesannetes aidata.
- Paindlikkus – Kanban on üsna paindlik raamistik, kuna võimaldab ülesandeid lisada ja eemaldada mistahes hetkel (kui need ei ole juba töös). Kanbani rakendamisel puuduvad piiravad reeglid, mistõttu on raamistikku võimalik kasutada igas valdkonnas. Samuti puuduvad kindlad rollid, mis tiimis peavad olema, mis võimaldab raamistikku juurutada mistahes tiimide sees.
- Vähendatud ressursikulu – Kuna tiimiliikmed teevad tööd efektiivselt, vähendab see nende tegevuste hulka, mis pole otseselt ülesannetega seotud. See tõstab valmis saadud ülesannete hulka märgatavalt. Kanbani kasutajate hulgas on see tugevus üheks määravamaks, miks neile Kanbani kasutada meeldib.
Kuigi Kanbanil on hulganisti projekti käekäigu sujuvust ja kvaliteeti soodustavaid mõjureid, pole siiski tegemist ideaalse metoodikaga. Kanbani nõrkadeks külgedeks võib pidada [31]:
- Võib kiiresti laguneda – Kanbanil on kaks tegurit, millest ühe puudumisel võib kogu protsessimajandus kokku kukkuda: hästi defineeritud protsess ning tiimi teadlikkus protsessidest ja oma rollist nendes. Kui juba üks tiimi liige ei tea päris täpselt, mida temalt oodatakse, võib see doominoefektina mõjutada ka teisi tiimiliikmeid ning kogu tööd.
- Tingib vajaduse pidevaks tööks – Vajalik on tiimi pidev töö. Kui tekib tööta olemise olukordi, annab see tunda järgmistes etappides, kus töö maht on suurem.
- Puuduvad ajalised piirangud – Kuna Kanban ei määra ülesannetele ajalist raamistikku, võib ajakavas püsimine osutuda keeruliseks (eriti, kui paralleelselt ei kasutata mõnda arendusraamistikku, nt Scrumi). Tiim peaks oskama ennustada tööks kuluvat aega ning see võiks olla märgitud ka ülesannete juurde.
- Kõrgema prioriteediga tööd võivad jääda tagaplaanile – Kuna tiimi liikmetel on vaba voli valida endale ülesandeid, mida järgmisena teha, võivad kõrgema prioriteediga ülesanded jääda tähelepanuta. Seetõttu tuleks tiimis kokku leppida ülesannete prioriteedid ning võimaluse korral lahendada enne need, mis on ärile olulisemad.
Kasutajaskond
Uuringuid selle kohta, kui palju kasutatakse spetsiifiliselt Kanbani tänapäeva tarkvaraarendustes, pole tehtud. Küll aga on teada, et agiilseid arendusmetoodikaid (või nende poole kallutatud metoodikaid) kasutatakse nii palju, et tõenäoliselt ületab see varsti traditsioonilisemate meetodite kasutamise [32].
Agiilseid meetodeid, sh ka Kanbani, kasutavad mitmed suurkorporatsioonid oma IT arenduses [33]. Näiteks Spotify, VMWare, Volvo IT, Auto Trader ja Blizzard Sport. Need ettevõtted on tõestuseks, et isegi kõige lihtsam Kanbani kasutus võib positiivselt mõjutada IT-tiimide protsesse. Ian Carrol on öelnud: “The beauty of Kanban is that you start with what you do now.” [33].
Kuigi Kanbani positiivsed küljed kaaluvad tihti üles negatiivsed küljed, siis Kanban iseenesest ei garanteeri edu. Uuringuid selle kohta, kas ja kuidas on Kanbani kasutamine mõjutanud tarkvaraarendust, on vähe. Ühes uurimistöös [34] on kirjutatud, et Kanbani pole võimalik eraldiseisvalt õppida, vaid samal ajal tuleb õppida ka workflow, flow diagrammide, burn-down graafikute ja muu sellise kohta. Autorite poolt pakuti välja, et tulevikus võiks uurida Kanbani kasutust ka reaaleluliste andmetega töötamisel ning analüüsimisel; ja julgustati veelgi Kanbani süvitsi uurima ning selle mõju hindama.
Teises uuringus [35], milles uuriti Scrumi ja Kanbani mõju tarkvaraarenduse projektidele, leiab, et mõlemad meetodid tagavad edukaid projekte. Uuring põhines vastanute statistikal ning käsitles eelarvest kinnipidamist, riskihaldust, tulemi kvaliteeti, olemasolevate ressursside hulka, projekti skoopi ning ajagraafikust kinnipidamist. Kuigi vastustest ei selgunud, kumb metoodika on neid aspekte silmas pidades oluliselt parem, leiti, et ajagraafikus püsimise koha pealt on Kanban parem kui Scrum. Tegemist oli siiski uuringuga pigem tehnilisest vaatepunktist ning autorid loodavad tulevikus uurida nende meetodite mõju ka tiimitööle, tööjaotusele ja läbipaistvusele.
Ekstreemprogrammeerimine
Eelmises kahes jaotises oli juttu agiilsetest metoodikatest Scrum ja Kanban. Need kaks ei välista teineteist. Vastupidi — nende kahe kooslus on küllaltki levinud nähtus ning see kannab nime Scrumban. Scrumban ühendab endas mõlema metoodika parimad küljed, parendamaks projektide ülalpidamist. Kanban annab võimaluse Scrumi võlusid veelgi efektiivsemalt rakendada. Scrumban on tänapäeval väga populaarne.
Ekstreemprogrammeerimine (ingl. k. Extreme Programming, XP) on aga teistsugune ning pakub terviklikumat ja spetsialiseeritumat lähenemist, keskendudes just programmeerimise ja arendustöö efektiivsusele. Antud arendusmetoodika puhul on tegemist ühe tervikuga. Suur osa XP kommuunist leiab, et kui kasutusel ei ole kõik XP printsiibid, siis ei ole tegemist õige XP arendusega [36].
Ajalugu
![](/images/thumb/4/49/ITSPEA_XP_Kent_Beck.jpg/200px-ITSPEA_XP_Kent_Beck.jpg)
Töö ekstreemprogrammeerimise kui arendusmudeli välja töötamiseks sai alguse aastal 1996. XP väljatöötamise keskkonnaks oli Chrysler Comprehensive Compensation System (C3), mille arendus vältas aastatel 1993 kuni 1999 ning mille eestvedaja (nagu nimestki võib välja lugeda) oli ettevõte Chrysler. Võib öelda, et C3 oli XP kasvulava. C3'e arendustiimi kuulus terve rida mõjukaid tarkvarainsenere, kes olid osa XP väljakujunemisest. Kõne all oleva arendusmetoodika loojaks on Kent Beck, kes oli ka juhtiv tarkvarainsener C3's. Teiste nimedena toob viidatav allikas välja järgnevad: Ron Jeffries, Ward Cunningham, Don Wells ja Martin Fowler. Nad kõik on oma valdkonna eksperdid ning vastavates ringkondades hästi tuntud. [37]
Kent Beck liitus C3 projektiga aastal 1996. Selleks ajaks oli projekt olnud tegemisel kolm aastat, ent projekti tulemina loodav programm ei olnud veel toimiv. Projektile anti veel veidi üle kahe aasta arendusaega juurde ning sellesse investeeriti miljoneid dollareid. Lõpuks, aastal 1999, jäeti projekt katki. Sellest hoolimata oli C3 projekti algne edu see, mis andis XP-le vajaliku tõuke. Ühe suurema läbimurdena võib näha C3'e tiimi produktiivsuse ja samal ajal ka koodikvaliteedi tõusu. Sellised positiivsed muutused saavutati tööstuses kasutatavate metoodikate (nagu Lean tootmine) rakendamisel tarkvaraarenduses. [37]
Martin Fowler on toonud välja, et tõsisem arendustöö C3 projekti kallal algas aastal 1995, programmeerimiskeeles Smalltalk, aga kuna projekti viimine stabiilsesse seisu ebaõnnestus, tehti sellele restart. Selles uuesti alustatud projektis leidsid rakendust kõik praktikad, mis on tänasel päeval tuntud ekstreemprogrammeerimise nime alla koondatult. [38]
C3 projekti liikmed jätkasid XP metoodika arendamist pärast projekti lõppemist aastal 1999. Ekstreemprogrammeerimine on viimase kahe kümnendi jooksul tasapisi kogunud populaarsust ning nüüdseks on selle meetodid ja põhimõtted võtnud omaks tarkvaraarendusjuhid üle maailma. [37]
Lühitutvustus
![](/images/thumb/6/63/ITSPEA_XP_Pair_programming.jpg/200px-ITSPEA_XP_Pair_programming.jpg)
Ekstreemprogrammeerimine on edukas, sest see seab tähtsale kohale kliendi rahulolu. XP protsess tarnib tarkvara, mida klient vajab, ajaks, mil tal seda vaja läheb. Ekstreemprogrammeerijad on võimelised reageerima klientide muutlikele nõuetele, isegi kui need tulevad arenduse hilises faasis. [39]
XP seab tähtsale kohale ka meeskonnatöö. Meeskonnaliikmeid — juhte, kliente ja arendajaid — käsitletakse võrdsete partneritena kaastööd tegevas tiimis. Vajadusel (kui ekstreemprogrammeerimine on tiimi meeskonna jaoks uus lähenemine) kaasatakse ka treener (Coach) [40]. XP aitab luua lihtsa, aga efektiivse keskkonna, mis aitab meeskondadel saavutada kõrge produktiivsuse [39].
Ekstreemprogrammeerimist iseloomustavad viis põhilist märksõna[39]:
- kommunikatsioon — suhtlus nii klientidega kui ka arendajate vahel;
- lihtsus — implementatsioonid tuleb hoida lihtsa ja puhtana;
- tagasiside — tarkvara testitakse esimesest päevast alates; klientidele tarnitakse tarkvara nii vara kui võimalik ning võetakse arvesse nende tagasisidet;
- austus — kujuneb läbi iga tiimiliikme unikaalse panuse ja väikeste võitude;
- julgus — eeltoodu loob vundamendi, tänu millele on võimalik julgelt reageerida muutuvatele nõuetele ja tehnoloogiatele.
Ekstreemprogrammeerimise reegleid[41] on päris mitmeid, neid kõiki käesolevas töös välja ei tooda. Need kategoriseeritakse planeerimise (Planning), halduse (Managing), disainimise (Designing), koodi kirjutamise (Coding) ja testimise (Testing) alla. Siinkohal tasub välja tuua väikeste reliiside, iteratsioonideks jaotamise, avatud tööruumi, stand-up'ide, TDD (test driven developmenti) ja testide katvuse olulisuse. Üks oluline XP metoodika osa on ka paarisprogrammeerimine [42].
Projektihaldus
Riskihaldus / väikesed reliisid
Ekstreemprogrammeerimine kasutab ära teadmist, et väiksematel projektidel on kõrgem edutõenäosus, tükeldades kõik tarkvaraprojektid mitmeks väiksemaks reliisiks. Igaüks nendest koosneb väiksemast osast nõutavast funktsionaalsusest. Selline lähenemine võimaldab kliendil ja lõppkasutajatel arendustulemustega juba varakult tutvuda ning seeläbi anda kvaliteetsemat ja täpsemat tagasisidet. Asjakohasem tagasiside tagab parema tellija ja täitja vahelise koostöö. XP-s on soovitatavaks reliisidevaheliseks ajaks kaks kuni kaheksa nädalat, sealjuures pidades silmas, et väiksem ajavahemik on parem. Varajaste reliiside pealt avastatud probleemid aitavad õigeaegselt juhtida projekti kulgu. Reliisid eeldavad demonstreeritavat tarkvaratulemit. Isegi kui projekt peaks enneaegselt lõppema, omavad juba loodud tulemid vähemalt mingit väärtust tellivale osapoolele. [43]
Integratsioonihaldus
Ühes teadusartiklis toodi välja, et ekstreemprogrammeerimine keskendub programmeerijate tööpanusele. Mõned XP pooldajad leiavad, et tehniliste kirjutajate (technical writers), andmebaasihaldurite ja kvaliteedi tagamise spetsialistide panus pole vajalik. Siiski, kõne all olev metoodika ei välista nende töö integreerimist, kes ei ole tarkvaraarendajad. Eelmainitud väikesed reliisid teevad integratsioonihaldusest järjepidevama protsessi, võrreldes mõnede teiste protsessidega, mille kohaselt paigutub tarne, dokumenteerimine ja testimine ajaplaani lõppu. [43]
Tarkvaraarendajate suhtes on ekstreemprogrammeerimine konkreetne — arenduses peab olema kesksel kohal pidev integratsioon (ingl. k. Continuous Integration) ja see peaks toimuma igapäevaselt. Ehkki selline praktika võib nõuda arendajatelt lisatööd, võimaldab igapäevane CI tiimil tuvastada probleeme märksa varasemalt. [43]
Aja- ja skoobihaldus
Ekstreemprogrammeerimise puhul läheb põhiline planeerimistöö hästi läbimõeldud tööjaotusstruktuuri (Work Breakdown Structure) ja selle juurde kuuluvate tööpakkide (Work Packages) välja töötamisele. XP ei räägi tööjaotusstruktuurist ja tööpakkidest otse, ent uurides ekstreemprogrammeerimises kasutatavaid Story Card'e, võib täheldada nende suurt sarnasust tööpakkidega. [43]
Planeerimismäng
Tööpakid pannakse kirja käsitsi kirjutatud kirjeldustena ning nende skoop on kasutajat puudutav funktsionaalsus. Nagu eelmises lõigus mainitud, on nende kaartide nimeks Story Card'id. Antud nimi tuletab projekti osalistele meelde, et need peavad kirjeldama lugu, mida kasutaja võib soovitavast funktsionaalsusest rääkida; need ei peaks kirjeldama tehnilist funktsionaalsust arendaja vaatepunktist. Story Card'e kasutatakse, et töötada välja hinnanguid, koostada tarkvara ehitamise ajakavasid, autoriseerida arendajate tööd, juhtida testimist ning raporteerida staatust. [43]
Ekstreemprogrammeerimises on planeerimise poolel olulisel kohal töö autoriseerimised. Neid tehakse iga iteratsiooni juures, üldiselt iga kahe nädala tagant. Iga iteratsiooni alguses annavad arendajad meeskonnana hinnangu kõikidele olemasolevatele Story Card'idele. Kui Story Card läheb mahult liiga suureks (ületab iteratsiooni kestust), siis tükeldatakse see kaheks või enamaks väiksemaks Story Card'iks, mis kollektiivselt vastavad esialgse kaardi funktsionaalsusele. Nendele uutele Story Card'idele (teisisõnu tööpakkidele) antakse samuti hinnangud. [43]
Kui lood (stories) on hinnatud, siis need grupeeritakse kasulikku funktsionaalsust sisaldavatesse reliisidesse. Nagu eelnevalt mainitud, kaasab XP kliendi arendusprotsessi juba varakult. Reliisid aitavad kliendil ja arendajatel jõuda üksmeeleni selle osas, kas projekt liigub soovitud suunas. Reliisid omakorda tükeldatakse kahenädalasteks arendusiteratsioonideks. Lood paigutatakse iteratsioonidesse eelkõige ärilist väärtust ning kuluhinnanguid arvestades; arendusefektiivsus on siinkohal pigem teisejärguline. [43]
Käesoleva iteratsiooni lood tükeldatakse arendajate ühisarutelu käigus lihtsamateks arendusülesanneteks või tegevusteks, mis jaotatakse üksteise vahel. Pärast seda algab töö. Kui mingi lugu või ülesanne saab valmis, siis märgitakse see tehtuks kõigile nähtaval viisil. Nagu eelnevalt mainitud, on XP-s oluline koht töö autoriseerimisel. Arendajad tohivad tööd teha ainult autoriseeritud lugude kallal. Kui arendajad soovivad muuta arendusstrateegiat, siis tuleb Story Card'id ümber kirjutada, uuesti hinnata ja ajastada. [43]
Iga iteratsiooni kohta arvutatakse mõõdikud. Kaks nendest on Kiirus (Velocity) ja Eilne Ilm (Yesterday's Weather). Kiiruse arvutamiseks liidetakse kokku iteratsiooni käigus valmis saadud kasutajalugude hinnangud, samuti ülesannete hinnangud [44]. Mõõdik Eilne Ilm põhineb metafooril, et tänane ilm on tõenäoliselt sama, mis eile. Üle kantuna tähendab on antud mõõdiku tähendus, et praeguse (sprindi) olukorra hindamiseks tasub olla teadlik sellest, mis toimus varasemalt. Olukorra hindamine on oluline, et vältida arendajate ülekoormust [45]. Ekstreemprogrammeerimises eelistatakse muutuvate tarnimiskuupäevade asemel ujuvat skoopi. [43]
Kvaliteedihaldus
Töötulemi kvaliteedi hoidmine võib ekstreemprogrammeerimise puhul osutuda keeruliseks, kuna programmeerijad liiguvad nii ühelt tööautoriseerimiselt teisele kui ka erinevate koodiosade vahel. Seetõttu nõuab XP kõrgelt distsiplineeritud lähenemist, saavutamaks vabaduse ressursside määramisel ilma kvaliteedis allahindlusi tegemata. [43]
Lihtne disain, refaktoreerimine
Esimene oluline põhimõte, mis aitab saavutada ja hoida kvaliteeti, on lihtsale disainile fokusseerumine. Selle asemel, et püüda saavutada ülipaindlikku koodi, mis sobituks potentsiaalsete uuendustega tulevikus, keskendub ekstreemprogrammeerimine koodile, mis vastab praegustele autoriseeritud tööpakkidele. Tulevaste featuuride ja lugude implementeerimiseks täiustatakse ja parendatakse koodi pidevalt. Seda praktikat nimetatakse refaktoreerimiseks. Refaktoreerimine toimub samm-sammu haaval ning selle hõlbustamiseks on vajalik automatiseeritud kvaliteedikontroll. Järgmise refaktoriseerimissammu juurde ei minda enne, kui ollakse veendunud, et kõik toimib endiselt. [43]
Testimine
Automatiseeritud testimine on vajalik, et oleks võimalik praktikas saavutada sajaprotsendiline kvaliteedikontrolli testide läbivus pärast igat järk-järgulist programmeerimissammu. Igal avalikul meetodil ja funktsioonil peab olema spetsifikatsioon automatiseeritud testide näol. XP-s on nõutud, et ühiktestid peavad olema loodud enne koodi, mis peab neid teste läbima. Sellise programmaatilise spetsifikatsiooni selge eelis tuleneb asjaolust, et arvuti saab automaatselt verifitseerida koodi vastavust nõuetele. [43]
Paarisprogrammeerimine
Ekstreemprogrammeerimise kohaselt toimub produktsioonikoodi kirjutamine ainult paarides — kaks arendajat istuvad ühe arvuti taga. Paarisprogrammeerimine viib ellu kollektiivomandi (collective ownership) põhimõtet palju paremini kui koodiülevaatamised (code review). Kahekesi programmeerides võidavad tüüpiliselt mõlemad osapooled ning see aitab tõsta ka tiimitunnetust. Paarisprogrammeerimise partnerid ei taha teineteist alt vedada — vastupidi, nad näevad eraldi vaeva, et järgida tiimis kehtestatud kokkuleppeid ja tavasid. Paaride liikmete vahetamise teel saavutatakse värskus ning informatsiooni liikumine. [43]
Kasutus hariduslikus keskkonnas
Ekstreemprogrammeerimine sobib meeskondadele, kus on kuni 12-15 tiimiliiget[46]. Käesolevas peatükis on kasutatud teadusartiklit, mis leiab, et sama meeskonnaliikmete maksimumarv on kasulik lõpuaasta Tarkvaratehnika bakalaureuse õppekava projektide jaoks. Seetõttu leiavad artikli autorid, et XP kasutamine on antud tudengiprojektide puhul teostatav. [47]
Mõned XP printsiibid on tudengite poolt olnud üsna leigelt vastu võetud. Nendeks on näiteks testimise olulisus (eriti just testide kirjutamine enne koodi kirjutamist), fookus kvaliteetse tarkvara kirjutamisel algusest peale, koodikirjutamis-standardite ja konfiguratsioonihalduse olulisus. XP printsiibid ei ole tegelikkuses midagi niivõrd uut, ent antud arendusmudel on muutnud paljud nendest trendikateks, mida varasemalt peeti tülikaks. [47]
Artikkel toob välja, et üks agiilse liikumise eestvedaja Alistair Cockburn leiab, et ekstreemprogrammeerimine on rakendatav ainult käputäie projektitüüpide jaoks: projektid, mille elluviimisega on seotud kuni 15 inimest ning mis on kuni keskmise kriitilisusega. Artikkel märgib ka, et just sellised projektid sobivad tudengite poolt tegemiseks. Projektid, mis lähevad nendest piiridest üle, ei ole õppimise jaoks ei praktiliselt ega eetiliselt otstarbekad. XP tundub siinkohal seega mõistlik valik. [47]
Tarkvaratehnika tudengitele on oluline teooria ja praktika kaudu anda edasi järgnevad tõsiasjad[47]:
- Ei ole olemas metoodikat, mis sobiks mistahes projektile.
- Mõned tarkvaraarenduse tehnikad sobivad hästi arvestades projekti piiranguid, teised vähem.
- Tarkvaraarendus on enamat kui lihtsalt programmeerimine, seda tuleks võtta kui inseneritegevust.
Kvaliteedi tagamine
Kvaliteedi tagamine on üheks suuremaks väljakutseks enamike tarkvaraarendusprojektide jaoks. Ekstreemprogrammeerimine sisaldab endas 12 praktikat[48], enamik neist aitavad kaasa kvaliteedi tagamisele moel või teisel. Lähemal uurimisel selgub, et XP keskendub kõige enam koodi kvaliteedi tagamisele. Väiksem fookus on arenduseelsel nõuete valideerimisel ja nendega arvestamisel. Selliste aspektide katmine on iga üksiku tiimi enda ülesanne. See nõuab tiimi, kus on vähemalt mõni suurema kogemusega arendaja. Tudengiprojektide tiimides selliseid arendajaid tihtipeale paraku ei ole. Sestap peavad tudengitiimid toetuma välisele, enamasti tuutori või töötaja, abile. Nii jääb aga tudengitele vähem manageerimist ja seeläbi jääb õppekogemus väiksemaks. [47]
Artikli autorid leiavad, et refaktoreerimine on teine praktika, millega esineb hariduslikus keskkonnas probleeme. Kogenud arendaja paneb tähele, kui "kood haiseb". Väiksema kogemusega arendaja ei ole aga piisavalt koodi näinud ega kirjutanud, et sellist asja täheldada. See omakorda tähendab, et tudengitelt ei saa eeldada efektiivset koodi refaktoreerimise oskust. Samas XP toetub just refaktoreerimisele, et hoida projekti kood puhas. [47]
Kasutajakeskne protsess võib aidata saavutada vajalikku funktsionaalsust ja kasutatavust. On ka teine lähenemine, mille kohaselt peaks rakendatama hoopis kasutuskeskset disaini — kasutaja roll on tihtipeale olulisem kui konkreetne isik. Tarkvara peab toetama seda, kes iganes juhtub asjassepuutuvat ülesannet täitma. XP näeb ette, et kasutaja on töökohal olemas ning temaga saab tekkivaid küsimusi pidevalt arutada. Tegelikkuses ei suuda üks "kasutaja" lõpuni välja esindada suure tarkvaraprojekti kõikide huvituvate osapoolte huve. [47]
Artikli autorid leiavad, ekstreemprogrammeerimise praktikad ei kata kvaliteedi tagamisel tekkida võivaid probleeme piisaval määral. Sisse tuleb tuua teisi praktikaid, mis ei ole XP projekti kontekstis koheselt ilmsed, ent mis võivad olla selgemalt vajalikud suuremas ja/või kriitilisemas projektis. Kui õppekeskkonnas need teised praktikad välja jätta, siis võib tudengitele jääda ekslik mulje, et kvaliteedi tagab pelgalt hästi kirjutatud kood. [47]
Koos töötamine
Üks olulisemaid asju, mida tarkvaraarendust õppivad tudengid peaksid selgeks saama, on tiimina koos töötamine. Tarkvaraarendus on harva vaid ühe inimese töö. Sestap peaksid tudengid saama tiimis töötamise kogemust erinevatel õppetasemetel, seda nii väiksemates kui ka suuremates meeskondades. Oluline on ka see, et tudengid saaksid läbi proovida erinevaid rolle, mis esinevad suuremates tiimides, eriti just neid, mis puudutavad töö organiseerimist ja juhtimist. [47]
Ekstreemprogrammeerimine paneb suurt rõhku tiimitööle. Isegi nii suurel määral, et XP ei toimi ilma kogu arendust läbiva koostööta. Arendusmudel toob välja, et tööd teeb üks meeskond, mitte mitu koostööd tegevat väiksemat alam-meeskonda. Neid asjaolusid arvesse võttes võib järeldada, et meeskonnatöö poole pealt on XP lähenemised väga kasulikud. [47]
XP üks oluline osa on paarisprogrammeerimine ning see eeldab, et kõik arendusmeeskonna liikmed omavad vähemalt mõistlikul tasemel programmeerimise oskust, on võimelised ja tahavad paarides tööd teha. Paarisprogrammeerimise juures on taseme-erinevuste eksisteerimise korral soovitatav panna koos programmeerima vähem ja rohkem kogenud arendajad — nii on võimalik aidata kaasa vähemkogenud arendajate taseme tõusule. Samuti on soovitatav paare tihti vahetada. [47]
Koolikeskkonnas on paarisprogrammeerimine andnud vastakaid tulemusi. Ühes uuringus[49] leiti, et paarisprogrammeerimine tõstab tudengite edukust õppeaines, enesekindlust oma lahenduste osas ning selline programmeerimine pakub rohkem rõõmu. Teisalt, käesolevas peatükis kasutatava teadusartikli üks autor oli seotud paarisprogrammeerimise kasutuselevõtuga ühes suures (~500 tudengit) esimese aasta Tarkvaratehnika tudengite aines. Eesmärgiks oli tõsta tudengite üldist programmeerimise taset, arvates, et arenduse käigus toimuv arutelu aitab sellele kaasa. Paraku tegi paari tugevam liige põhilise osa tööst ning nõrgemad kippusid eksamitel läbi kukkuma. Paaride puhul, mille mõlemad liikmed olid võrdsel tasemel, täheldati, et liige, kes parasjagu koodi ei kirjutanud, kippus istuma jõude ning mõtlema muudele asjadele kui käesolevale ülesandele. Pandi tähele, et erinevad isiksused sobituvad paarisprogrammeerimisega erinevalt. [47]
Kui õppetingimustes rakendada paarisprogrammeerimist, siis võidaksegi piirduda kaheliikmeliste tiimidega, kuid päriselus moodustuvad paarid suuremast tiimist. Sestap tasuks suurema haridusliku kasu nimel varieerida tiimi suurusi. Nii saavad tudengid paremini kogeda, mida tiimitöö ning tiimiviisiline probleemide lahendamine tegelikult tähendavad. [47]
Paarides töötavad tudengid peavad olema suutlikud pidama isiklikke hindamistulemusi vähemolulisemaks kui paari üldist edu. Paremini hakkama saavad tudengid võivad tahta lihtsalt asja ära teha ilma, et nad pingutaksid vähemkogenud paariliikme arengu nimel. Tudengitel võib olla selleni raske jõuda, sest kaasprogrammeerija aitamisest tulenev kasu ei pruugi neile olla nii selge. [47]
Projektitulemid
Agiilse tarkvaraarenduse manifesti[50] kohaselt on töötav tarkvara kõige olulisem projektitulem. Ent selline suhtumine võib tudengite silmis jätta varju mõned teised tulemid, mis on samuti vajalikud. Üheks selliseks tulemiks on projekti tegemise käigus saadud õppetunnid, mida võib hariduslikus kontekstis pidada oluliseks. Paraku toimub tõhus õppeprotsess enamasti ainult läbi vigade tegemise, probleemide analüüsi ning nende parandamise. Selle kõige vältel ei ole võimalik tagada töötava tulemi olemasolu, mille pealt töö kulgu hinnata. [47]
Teadusartikli autorid leiavad, et koodi käsitlemine põhilise tulemina tekitab tudengites valesid arusaamu. Suuremates projektides on tihtipeale vaja enamat kui töötavat tarkvara, näiteks dokumentatsiooni. Tudengid ei pruugi lisaks koodile tekkivate tulemite vajadust mõista. Eraldi probleemiks on tudengite panuse hindamine (sealhulgas isiklik initsiatiiv, pühendumus kvaliteetsele tööle jms), sest XP ei paku selleks otsest võimalust. [47]
Suhtlus kliendiga
Ekstreemprogrammeerimises on suhtlus kliendiga olulisel kohal. Ideaalis peaks olema klient arendajatele pidevalt kättesaadav, parimal juhul oleks klient isegi arendajatega samas ruumis. Töökeskkonnas on seda raske saavutada, rääkimata hariduslikust keskkonnast. [47]
Kliendid ei pruugi lõpuni mõista pideva arendaja ja kliendi vahelise suhtluse kasusid. Neile võib tunduda see tülikas. Tudengid tajuvad seda ning ei taha omakorda klienti pidevalt tülitada väikeste või triviaalsete probleemidega, ent XPs on just selline suhtlus projekti edu saavutamiseks hädavajalik. Frustratsiooni tekitavad probleemid ilmnevad siis, kui tudengid jõuavad lahenduse mingisuguse aspektiga perfektsuseni, aga klient annab selle peale negatiivset tagasisidet. [47]
Teadusartikli autorid leiavad, et kohapealse kliendi olemasolu vajadus on pigem teisene. Hoopis olulisem on, et tudengid kogevad tagasiside väärtust. Tudengite juhendajad peaksid nägema vaeva, et valida välja sellised projektid, mille kliendid saavad aru tagasiside vajalikkusest ja on võimelised seda pakkuma. [47]
Muud probleemid
Artikkel toob välja veel probleeme [47]:
- 40-tunnise töönädala printsiip on hariduskeskkonnast raskesti järgitav.
- Eelnevast tingitud on vajadus muuta XP arendustsükleid, muutes nende skoopi.
- Tudengitele ei meeldi protsessid, distsipliin meeldib neile isegi vähem.
Teadusartikli kokkuvõte
Artikkel ilmus 2005. aastal ning selleks ajaks oli olnud vähe kogemust agiilsete metoodikate rakendamisel hariduslikus kontekstis. Huvi agiilsete metoodikate vastu oli arendusmaailmas aga juba toona suur ning üha enam taheti tuua neid uusi metoodikaid kolmanda astme haridusse. [47]
Kokkuvõttes leiavad artikli autorid, et ekstreemprogrammeerimine kui ühtne tervik ei sobi ülikooliõppes rakendamiseks. Teisalt võivad valitud ekstreemprogrammeerimise praktikad olla kasulikud õpetamaks väiksema mastaabi tarkvaraarendust. Paarisprogrammeerimise rakendamist soovitatakse edasi uurida. [47]
Kokkuvõte
Tarkvara arendamise meetodid saab jagada üldiselt kaheks: traditsiooniline ja väle- ehk agiilne arendus. Mõlemal meetodirühmal on oma tugevused ja nõrkused. Traditsiooniline lähenemine sobib eelkõige suurematele ja keerukamatele projektidele, millel on kindel skoop, eelarve ning on teada, mida loodavalt tarkvaralt oodatakse. Sellegipoolest võib ka selle lähenemisega sattuda lõhkiste eelarvete ja ajagraafikute küüsi.
Välearendused üritavad neid nõrkusi leevendada ning võtavad muudatusi projekti osana. Välearenduse üks põhilisi fookuseid on inimesed — tööjõud, kes reaalselt projektiga tegeleb. Selline metoodika sobib eelkõige väiksematele või keskmise suurusega projektidele, mille nõuded võivad muutuda. Eeldatakse, et klient on kättesaadav kogu projekti vältel ning on võimeline andma tagasisidet tehtud tööle. Üldiselt jagatakse agiilsete meetodite puhul töö etappideks, kusjuures iga valminud etapp peab olema presenteeritav kliendile.
Agiilseid arendusmetoodikaid on mitmeid. Antud töös keskenduti Scrumile, Kanbanile ning Ekstreemprogrammeerimisele. Need kõik esindavad agiilses arenduses erinevaid seisukohti. Antud välearenduse metoodikad on ülevaatlikult toodud järgnevas tabelis.
Arendusmudel | Scrum | Kanban | Extreme Programming |
---|---|---|---|
Millal loodud? | 1995 | 1940ndad | Loomisprotsess algas 1996, avalikustati 1999 |
Põhilised autorid | Jeff Sutherland ja Ken Schwaber | Toyota insener Taiichi Ohno | Kent Beck |
Võtmeväärtused / märksõnad |
|
|
|
Rollid |
|
Kanban ei defineeri meeskonna rolle | Põhiliselt:
Vajadusel ka treener (coach) |
Meeskonna suurus | Kuni 10 liiget | Kanban ei defineeri meeskonna suurust | Kuni 12-15 liiget |
Aja- ja skoobihaldus | Aeg on hallatud läbi sprindi kestuse, sprindi skoobi paneb paika Sprint Backlog | Work In Progress töö limiteerimine aitab aega ja skoopi hallata | Planeerimismäng, sealhulgas Story Card'id ja töö autoriseerimine |
Tööjaotus | Sprindid kestusega 1 kuni 4 nädalat. Kestus püsib kogu tootearenduse protsessei vältel üldiselt sama. | Soovituslikud on iteratiivsed arendused (tihti kasutatakse koos Scrumiga, kus on tööjaotus konkreetsem) | Iteratsioonid, tüüpiliselt kestusega 1 kuni 2 nädalat[51] |
Koosolekud | Iga päev 15-minutiline Daily Scrum või stand-up.
Iga Sprindi lõpus Sprint Review. Pärast Sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist retrospektiiv |
Soovituslik: retrospektiiv, stand-up'id | Iteratsiooni plaanimise koosolek [52], Igapäevane Stand-up [53] |
Töö limiteerimine | Tööde maht pannakse paika sprindi nõuete nimekirjaga (Sprint Backlog) [12] | Samal ajal töös olevate tööde hulk on piiratud | Töömahu planeerimist ja limiteerimist aitavad otsustada mõõdikud |
Eksklusiivsus | Ei välista teiste arendusmetoodikate kasutust | Ei välista teiste arendusmetoodikate kasutust | XP on terviklahendus ja seega pigem teisi lahendus välistavam |
Programmeerimisele spetsialiseeritud? | Tavapäraselt kasutatakse programmeerimist hõlmavate projektide puhul[54] | Ei ole programmeerimisele spetsialiseeritud | Tugevalt spetsialiseeritud programmeerimisele |
Millistele projektidele sobib paremini? | Scrum on hästiskaleeruv, kuid on pigem välja töötatud väiksemate projektide jaoks [13][55] | Väiksemaks osadeks hästi tükeldatavad projektid | Kuni keskmise kriitilisusega projektid |
Kaugtöö toetus | Kaugtöö edukalt rakendatav | Sobib kaugtööks[56] | Kaugtöö võib tekitada probleeme paarisprogrammeerimise ja muude XP põhimõtete osas, kuid on võimalik |
Nõrgad kohad |
|
Väledaid metoodikaid saab omavahel üsna hõlpsasti kombineerida, heaks näiteks on Scrumi ja Kanbani ühismeetod Scrumban. Samas on näha, et ekstreemprogrammeerimine on pigem eraldiseisev metoodika. Samuti, Scrumi ja Kanbani sobib kasutada ka kaugtöös. Ekstreemprogrammeerimine aga eeldab näost näkku suhtlust, seda peamiselt paarisprogrammeerimise seisukohast. Kui Scrum ja ekstreemprogrammeerimine on arendusmetoodikad, siis Kanban seda pole. Kanban ei kirjelda, kuidas tarkvara peaks arendama. Seetõttu on näha, et kui Scrumi ja ekstreemprogrammeerimise puhul on üldiselt kindlaksmääratud meeskonna suurus ning meeskonnas sisalduvad rollid, siis Kanban neid ei defineeri, muutes selle kasutamise võimalikuks ka muudes eluvaldkondades. Artiklis toodud metoodikate ühiseks tunnuseks on aga pidev suhtlus ning regulaarsed koosolekud tiimiga. See on vastavuses ka agiilsete tarkvaraarenduste põhiprintsiipidega, kus pannakse suurt rõhku meeskonnale ning selle arengule. Just inimeste omavaheline pidev suhtlus on peamine faktor, miks paljud tarkvaraarendajad just väledaid metoodikaid eelistavad.
Kasutatud materjalid
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 "Issues and Challenges of Agile Software Development with Scrum", Juyun Cho, https://iacis.org/iis/2008/S2008_950.pdf
- ↑ "Extreme Programming Explained", Kent Beck, 2000, Reading, MA: Addison Wesley
- ↑ "Agile 101", https://www.agilealliance.org/agile101/
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 "Agiilsete tarkvaraarendusmeetodite võrdlus", Kristen Kivimaa, 2014, http://www.cs.tlu.ee/teemaderegister/get_file.php?id=326
- ↑ "Agiilse tarkvaraarenduse manifest", 2001, https://agilemanifesto.org/iso/et/manifesto.html (06.05.2020)
- ↑ "Agiilse tarkvaraarenduse manifesti põhimõtted", 2001, https://agilemanifesto.org/iso/et/principles.html (06.05.2020)
- ↑ 7.0 7.1 7.2 7.3 7.4 7.5 7.6 7.7 "The History of Scrum: How, when and WHY", https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/ (06.05.2020)
- ↑ 8.0 8.1 "New New Product Development Game", Hirotaka Takeuchi, Ikujiro Nonaka, 1986, Harvard Business Review, https://hbsp.harvard.edu/product/86116-PDF-ENG
- ↑ "Scrum", https://www.lexico.com/definition/scrum (06.05.2020)
- ↑ "The Role of the Product Owner in Scrum-comparison between Theory and Practices", Hrafnhildur Sif Sverrisdottir, Helgi Thor Ingason, Haukur Ingi Jonasson, 2014, https://www.sciencedirect.com/science/article/pii/S1877042814021211
- ↑ "Why Scrum works ", Lene Pries-Heje, Jan Pries-Heje, 2011, https://www.researchgate.net/publication/224256381_Why_Scrum_Works_A_Case_Study_from_an_Agile_Distributed_Project_in_Denmark_and_India
- ↑ 12.00 12.01 12.02 12.03 12.04 12.05 12.06 12.07 12.08 12.09 12.10 "The Scrum Guide", Ken Schwaber, Jeff Sutherland, 2016, https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
- ↑ 13.0 13.1 13.2 13.3 "Pro Visual Studio Team System Application Lifecycle Management", Joachim Rossberg, 2008, Apress
- ↑ "Agile Project Management with Scrum", Ken Schwaber, 2004, Microsoft Press, https://archive.org/details/agileprojectmana0000schw
- ↑ 15.0 15.1 15.2 15.3 15.4 15.5 "Analysis of the changes in communication and social interactions during the transformation of a traditional team into an agile team", Ismael Edrein Espinosa‐Curiel, Josefina Rodríguez‐Jacobo, Erika Vázquez‐Alfaro, José Alberto Fernández‐Zepeda, Daniel Fajardo‐Delgado, 2018, https://onlinelibrary.wiley.com/doi/abs/10.1002/smr.1946
- ↑ 16.0 16.1 16.2 "Adaptation of Agile Project Management Methodology for Project Team", Arturs Rasnacis, Solvita Bērziša, 2015, https://www.researchgate.net/publication/293194225_Adaptation_of_Agile_Project_Management_Methodology_for_Project_Team
- ↑ 17.0 17.1 17.2 17.3 17.4 "Effects of Agile Practices on Social Factors", Amy Law, Raylene Charron, 2005, https://dl.acm.org/doi/pdf/10.1145/1082983.1083115
- ↑ "Conceptual model of working space for Agile (Scrum) project team", Paweł Rola, Dorota Kuchta, Dominika Kopczyk, 2016, https://www.sciencedirect.com/science/article/pii/S0164121216300401
- ↑ "Agile & Distributed Project Management: A Case Study Revealing Why Scrum is Useful", Lene Pries-Heje, Jan Pries-Heje, 2011, https://aisel.aisnet.org/ecis2011/217/
- ↑ 20.0 20.1 20.2 "Investigating the Long-Term Acceptance of Agile Methodologies: An Empirical Study of Developer Perceptions in Scrum Projects", Sven Overhage, Sebastian Schlauderer, 2012, https://ieeexplore.ieee.org/document/6149555
- ↑ 21.0 21.1 21.2 "What is Kanban?", https://www.digite.com/kanban/what-is-kanban/ (06.05.2020)
- ↑ "Toyota Production System: Beyond Large-scale Production", Taiichi Ohno
- ↑ "Insights into the Perceived Benefits of Kanban in Software Companies: Practitioners’ Views", Muhammad Ovais Ahmad, Jouni Markkula, Markku Oivo, https://link.springer.com/chapter/10.1007/978-3-319-33515-5_13
- ↑ 24.0 24.1 24.2 24.3 24.4 24.5 "Aspects of Kanban", Karl Scotland, https://www.methodsandtools.com/archive/archive.php?id=104
- ↑ "Push vs. Pull Manufacturing: Is a Kanban Pull System Right for Your Company?", Plex, https://www.industryweek.com/cloud-computing/article/22023873/push-vs-pull-manufacturing-is-a-kanban-pull-system-right-for-your-company
- ↑ "The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer", Jeffrey Liker
- ↑ "Learning to See: Value Stream Mapping to Add Value and Eliminate Muda", Mike Rother and John Shook
- ↑ "Close to 60 Percent of Surveyed Tech Workers Are Burnt Out—Credit Karma Tops the List for Most Employees Suffering From Burnout", Kyle McCarthy, https://www.teamblind.com/blog/index.php/2018/05/29/close-to-60-percent-of-surveyed-tech-workers-are-burnt-out-credit-karma-tops-the-list-for-most-employees-suffering-from-burnout/
- ↑ "Quality Software Management: Systems Thinking", Gerald Weinberg
- ↑ 30.0 30.1 30.2 "Main Features and Characteristics of Successful Kanban Teams", Nikolay Tsonev, https://kanbanize.com/blog/characteristics-of-kanban/
- ↑ 31.0 31.1 "Kanban vs. Scrum: Which is Right for Your Small Business?", Roberto Izquierdo, https://www.fool.com/the-blueprint/kanban-vs-scrum/
- ↑ "Success Rates Rise: Transforming the High Cost of Low Performance", https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf
- ↑ 33.0 33.1 "Kanban in IT Operations: 5 Real-Life Examples", Pavel Naydenov, https://kanbanize.com/blog/kanban-it-operations/
- ↑ "Kanban in software engineering: A systematic mapping study", Muhammad Ovais Ahmad, Denis Dennehy, Kieran Conboy, Markku Oivo, https://www.sciencedirect.com/science/article/pii/S0164121217302820
- ↑ "A statistical analysis of the effects of Scrum and Kanban on software development projects", Howard Lei, Farnaz Ganjeizadeh, Pradeep Kumar Jaychandran, Pinar Ozcan, https://www.sciencedirect.com/science/article/pii/S0736584515301599#s0095
- ↑ "Extreme Programming (XP) FAQ", Brewer, J., 2001, http://www.jera.com/techinfo/xpfaq.html
- ↑ 37.0 37.1 37.2 "Extreme Programming (XP): You Wouldn't Believe It Came from Chrysler - WhoIsHostingThis.com", Brenda Barron, 2019, https://www.whoishostingthis.com/resources/extreme-programming/
- ↑ "C3", Martin Fowler, 2004, https://www.martinfowler.com/bliki/C3.html
- ↑ 39.0 39.1 39.2 "Extreme Programming: A Gentle Introduction.", Don Wells, 2009, http://www.extremeprogramming.org/
- ↑ "Extreme Programming - Roles - Tutorialspoint", https://www.tutorialspoint.com/extreme_programming/extreme_programming_roles.htm
- ↑ "Extreme Programming Rules", Don Wells, 1999, http://www.extremeprogramming.org/rules.html
- ↑ "Pair Programming", Don Wells, 1999, http://www.extremeprogramming.org/rules/pair.html
- ↑ 43.00 43.01 43.02 43.03 43.04 43.05 43.06 43.07 43.08 43.09 43.10 43.11 43.12 Goebel, C. J. (2003). Managing software development using extreme programming. Paper presented at PMI® Global Congress 2003—North America, Baltimore, MD. Newtown Square, PA: Project Management Institute. https://www.pmi.org/learning/library/managing-software-development-using-extreme-programming-7662
- ↑ "Project Velocity", Don Wells, 1999, http://www.extremeprogramming.org/rules/velocity.html
- ↑ "Yesterdays Weather", Jonathan Rasmusson, http://www.agilenutshell.com/yesterdays_weather
- ↑ "Extreme Programming Explained: Embrace Change", Kent Beck, Addison-Wesley, 1999
- ↑ 47.00 47.01 47.02 47.03 47.04 47.05 47.06 47.07 47.08 47.09 47.10 47.11 47.12 47.13 47.14 47.15 47.16 47.17 47.18 47.19 47.20 47.21 47.22 "eXtreme Programming––helpful or harmful in educating undergraduates?", Jean-Guy Schneider, Lorraine Johnston, 2005, https://www.sciencedirect.com/science/article/pii/S0164121203002929
- ↑ "Extreme Programming (XP): Values, Principles, and Practices | AltexSoft", 2018, https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/
- ↑ "The impact of pair programming on student performance, perception and persistence", C. McDowell, L. Werner, H.E. Bullock, J. Fernald, Proceedings ICSE 2003, Portland, Oregon, May 2003, IEEE Computer Society Press (2003), pp. 602-607
- ↑ "Manifesto for Agile Software Development", http://agilemanifesto.org/
- ↑ "Differences Between Scrum and Extreme Programming", Mike Cohn, 2007, https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
- ↑ "Planning and Running an XP Iteration", Martin Fowler, 2001, https://martinfowler.com/articles/planningXpIteration.html#id267165
- ↑ "Daily Stand up meeting", Don Wells, 1999, http://www.extremeprogramming.org/rules/standupmeeting.html
- ↑ "Scrum - what it is, how it works, and why it's awesome", https://www.atlassian.com/agile/scrum
- ↑ "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies", Jeff Sutherland, 2001, http://jeffsutherland.com/papers/scrum/Sutherland2001AgileCanScaleCutter.pdf
- ↑ "Kanban for Remote Team Leadership | Applied Frameworks", https://appliedframeworks.com/kanban-for-remote-team-leadership/
- ↑ 57.0 57.1 "Advantages and disadvantages of Extreme Programming (XP)", Pavel Kukhnavets, 2018, https://hygger.io/blog/disadvantages-and-advantages-of-extreme-programming/