Väledad tarkvaraarenduse mudelid - Revision history

Mimann at 08:16, 8 May 2020

2020-05-08T08:16:01Z

← Older revision		Revision as of 11:16, 8 May 2020
Line 117:		Line 117:
	==== The New New Product Development Game ====		==== The New New Product Development Game ====

	[[File:Scrum Rugby.JPG\|250px\|thumb\|~~left~~\|Scrum ragbis]]		[[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>.		Ü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>.

Mimann: /* Scrum */

2020-05-08T08:14:45Z

Scrum

← Older revision		Revision as of 11:14, 8 May 2020
Line 97:		Line 97:
	=== Ajalugu ===		=== Ajalugu ===

	Scrumi esitleti avalikkusele esmakordselt aastal 1995 Jeff ~~Sutherland’i~~ ja Ken ~~Schwaber’i~~ poolt. Samas on mudeli autorid öelnud, et tegemist pole mingi enneolematu lähenemisega – sarnaseid praktikaid on kasutatud ka varem. Nii ~~Sutherland’i~~ kui ~~Schwaber’i~~ 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>		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. <ref name="ScrumDeskHistory"></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. <ref name="ScrumDeskHistory"></ref>
Line 111:		Line 111:
	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>		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’ile~~, et on olemas vajadus uue arendusmetoodika järgi, mis sobiks paremini nii arendajatele kui klientidele ning aitaks projektidel õigeaegselt valmis saada. <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 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. <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. <ref name="ScrumDeskHistory"></ref>

	==== The New New Product Development Game ====		==== The New New Product Development Game ====

			[[File:Scrum Rugby.JPG\|250px\|thumb\|left\|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>.		Ü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 ~~Toyota’s~~. 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>		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’i~~ 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>		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>.		. 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>.

Line 136:		Line 138:

	==== Scrum meeskond ====		==== Scrum meeskond ====

	~~[[File:Scrum Rugby.JPG\|250px\|thumb\|right\|Scrum ragbis]]~~

	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>		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>
Line 151:		Line 151:
	[[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 ~~ajal~~, 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>		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. <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. <ref name="ScrumGuide"></ref><ref name="Kivimaa"></ref>
Line 190:		Line 190:
	==== Töökeskkond ====		==== Töökeskkond ====

	Scrumi sotsiaalse loomu tõttu sobib protsessiks paremini avatud ~~ruum~~ 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>.		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 ====

Mimann: /* Sissejuhatus */

2020-05-08T08:02:36Z

Sissejuhatus

← Older revision		Revision as of 11:02, 8 May 2020
Line 3:		Line 3:
	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 ~~need~~ 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>		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 <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>.		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>.

Mateek: /* Kokkuvõte */

2020-05-08T07:38:55Z

Kokkuvõte

← Older revision		Revision as of 10:38, 8 May 2020
Line 547:		Line 547:
	! Võtmeväärtused / märksõnad		! Võtmeväärtused / märksõnad
	\|		\|
	* läbipaistvus,		* läbipaistvus
	* kontroll,		* kontroll
	* kohanemine		* kohanemine
	\|		\|

Mateek: /* Kokkuvõte */ Uuendasin Kanbani võtmeväärtused

2020-05-08T07:38:26Z

Kokkuvõte: Uuendasin Kanbani võtmeväärtused

← Older revision		Revision as of 10:38, 8 May 2020
Line 551:		Line 551:
	* kohanemine		* kohanemine
	\|		\|
	* ~~suurenenud läbilaskevõime~~		* töös olevad ülesanded
	* ~~parem suhtlus~~		* pidev areng
	* ~~paindlikkus~~		* fookus töö lõpetamisel
	* ~~vähenenud jäätmed~~		* eneseorganiseerimine
			* tiimi motivatsioon
	\|		\|
	* kommunikatsioon		* kommunikatsioon

Mirpaj: /* Kanban */

2020-05-08T07:14:35Z

Kanban

← Older revision		Revision as of 10:14, 8 May 2020
Line 278:		Line 278:
	=== Mis on Kanban? ===		=== Mis on Kanban? ===

	Kanban on töövoo manageerimise meetod, mille disain aitab töö tegemist visualiseerida ning ~~kasutada maksimaalselt produktiivsust~~ ning ~~efektiivsust~~. 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.		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 ===
Line 293:		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 ~~Ekstreemprogrammeerimine~~, või traditsioonilisemad nagu waterfall – Kanbani abil saab nende kõikide tööprotsessi parandada ning töövoogu efektiivsemaks muuta. <ref name="WhatIsKanbanDigite"/>		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 ===
Line 339:		Line 339:
	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 ~~lõpule~~, 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>		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 350:		Line 350:

	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 ~~teavad~~ 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"/>		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 ~~töötajaid~~ hoida ~~ülesande~~ 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"/>		Ü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 374:		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~~/ee~~/ 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].		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.

Mateek: /* Lühitutvustus */ Italicud

2020-05-08T07:11:53Z

Lühitutvustus: Italicud

← Older revision		Revision as of 10:11, 8 May 2020
Line 403:		Line 403:
	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>		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 />.		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/>:		Ekstreemprogrammeerimist iseloomustavad viis põhilist märksõna<ref name=XPIntro/>:
Line 412:		Line 412:
	# 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 ~~developmenti~~) 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>.		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 ===

Mirpaj at 19:18, 7 May 2020

2020-05-07T19:18:10Z

← Older revision		Revision as of 22:18, 7 May 2020
Line 1:		Line 1:
	~~==LEHT ON VALMIMISEL==~~


	== Sissejuhatus ==		== Sissejuhatus ==

Line 644:		Line 641:
	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.		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.		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 />

Mirpaj: /* Kanban */

2020-05-07T19:16:32Z

Kanban

← Older revision		Revision as of 22:16, 7 May 2020
Line 315:		Line 315:
	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 (~~''Work In Progress'' e~~ WIP) ====		==== 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 325:		Line 325:
	''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 ~~(''Continuous Improvement'')~~ ====		==== 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 335:		Line 335:
	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 ~~(''Focus on Completing Instead of Starting Work'')~~ ====		==== 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.
Line 348:		Line 350:
	*Leia midagi muud kasulikku, mida teha		*Leia midagi muud kasulikku, mida teha

	==== Eneseorganiseerimine ~~(''Higher Rate of Self-Organization'')~~ ====		==== 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 teavad 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"/>		Kanbani puhul on palju rõhutud sellele, et kõik tiimiliikmed teavad 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 ~~(''Team Morale Improvement'')~~ ====		==== Tiimi motivatsioon ====

	Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab töötajaid hoida ülesande 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"/>		Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab töötajaid hoida ülesande 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"/>

Mirpaj at 19:04, 7 May 2020

2020-05-07T19:04:40Z

← Older revision		Revision as of 22:04, 7 May 2020
Line 642:		Line 642:
	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.		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.		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.

	~~==Kokkuvõte==~~
	~~täitja: Mirjam~~


	==Kasutatud materjalid==		==Kasutatud materjalid==
	<references />		<references />