b'\n_START_ARTICLE_\nScrum\n_START_PARAGRAPH_\nScrum on  projektinhallinnan viitekehys, jota k\xc3\xa4ytet\xc3\xa4\xc3\xa4n yleisesti ketter\xc3\xa4ss\xc3\xa4 ohjelmistokehityksess\xc3\xa4. Vaikka Scrum on kehitetty erityisesti ohjelmistoprojektien hallintaan, sit\xc3\xa4 voidaan soveltaa my\xc3\xb6s yleisesti projektinhallinnassa. Ensimm\xc3\xa4isin\xc3\xa4 idean scrumin kehitysprosessista kuvasivat 1986 Hirotaka Takeuchi ja Ikujiro Nonaka. Teoksessaan Takeuchi ja Nonaka kuvaavat uudenlaisen, holistisen l\xc3\xa4hestymistavan tuotekehitykseen, jossa yksi ainoa monitaitoinen (engl. cross-functional) ryhm\xc3\xa4 suorittaa kehitysprosessin alusta loppuun vaiheistuksella, joka on vahvasti lomittunut. Ryhm\xc3\xa4n toimintaa verrataan rugby-joukkueeseen, jossa koko ryhm\xc3\xa4 pyrkii etenem\xc3\xa4\xc3\xa4n yksikk\xc3\xb6n\xc3\xa4 ja toimimaan tiiviiss\xc3\xa4 yhteisty\xc3\xb6ss\xc3\xa4. My\xc3\xb6s menetelm\xc3\xa4n nimi (engl. scrum) viittaa rugbyn erikoistilanneryhmitykseen. Nimi on my\xc3\xb6s sittemmin j\xc3\xa4\xc3\xa4nyt k\xc3\xa4ytt\xc3\xb6\xc3\xb6n johtuen menetelm\xc3\xa4n yht\xc3\xa4l\xc3\xa4isyyksist\xc3\xa4 rugby-joukkueeseen ja sen toimintaan; molemmat ovat erilaisiin tilanteisiin sopeutuvaisia, nopeita ja itseohjautuvia._NEWLINE_Varsinaisen scrum-viitekehyksen kehitt\xc3\xa4jin\xc3\xa4 pidet\xc3\xa4\xc3\xa4n Jeff Sutherlandia, Ken Schwaberia, John Scumniotalesia ja Jeff McKennaa.\n_START_SECTION_\nTy\xc3\xb6skentelytapa\n_START_PARAGRAPH_\nScrumissa ty\xc3\xb6skennell\xc3\xa4\xc3\xa4n toistavasti ja lis\xc3\xa4\xc3\xa4v\xc3\xa4sti (engl. iterative-incremental) ennustettavuuden optimoimiseksi ja riskien kontrolloimiseksi. Tavoitteena oleva tuote kehittyy pikkuhiljaa t\xc3\xa4ydellisemm\xc3\xa4ksi ja valmiimmaksi useiden kehitysjaksojen aikana. Kehitysjaksoa kutsutaan sprintiksi (engl. Sprint). Sprintti on 1-4 viikon mittainen aikaraja, jonka sis\xc3\xa4ll\xc3\xa4 tuotetaan \xe2\x80\x9cvalmiin\xe2\x80\x9d m\xc3\xa4\xc3\xa4ritelm\xc3\xa4n t\xc3\xa4ytt\xc3\xa4v\xc3\xa4, k\xc3\xa4ytt\xc3\xb6kelpoinen ja potentiaalisesti julkaisukelpoinen tuoteversio. Jokaisen sprintin sis\xc3\xa4lt\xc3\xb6 sovitaan sprintin suunnittelupalaverissa ennen sprintin aloitusta, ja toteutettaviksi valitaan sellaisia tuotteen kehitysjonon kohtia, joilla on sill\xc3\xa4 hetkell\xc3\xa4 suurin merkitys projektin onnistumiselle. Sprintin lopuksi j\xc3\xa4rjestet\xc3\xa4\xc3\xa4n sprinttikatselmus, jossa kehitystiimi esittelee sprintin konkreettiset saavutukset (esim. ohjelmiston uusimman version) tuoteomistajalle sek\xc3\xa4 mahdollisille sidosryhmien edustajille palautteen saamiseksi ja ymm\xc3\xa4rryksen lis\xc3\xa4\xc3\xa4miseksi kehityksen tilasta. Ennen seuraavan sprintin aloittamista pidet\xc3\xa4\xc3\xa4n viel\xc3\xa4 sprintin retrospektiivi, jossa tarkastellaan prosessin n\xc3\xa4k\xc3\xb6kulmasta mik\xc3\xa4 sprintin aikana sujui hyvin ja mit\xc3\xa4 voitaisiin parantaa seuraavassa sprintiss\xc3\xa4.\n_START_SECTION_\nScrumin roolit\n_START_PARAGRAPH_\nScrum-kehityksess\xc3\xa4 k\xc3\xa4ytet\xc3\xa4\xc3\xa4n yht\xc3\xa4 tai useampaa scrumtiimi\xc3\xa4 (engl. Scrum Team). Scrumtiimi koostuu tuoteomistajasta, scrummasterista ja kehitystiimist\xc3\xa4.  Scrumtiimi p\xc3\xa4\xc3\xa4tt\xc3\xa4\xc3\xa4 kunkin sprintin tavoitteet ja teht\xc3\xa4v\xc3\xa4t, ja vastaa yhdess\xc3\xa4 siit\xc3\xa4, ett\xc3\xa4 asetettuihin tavoitteisiin p\xc3\xa4\xc3\xa4st\xc3\xa4\xc3\xa4n. Scrumtiimi on itseohjautuva ja monitaitoinen, ja sill\xc3\xa4 on valta p\xc3\xa4\xc3\xa4tt\xc3\xa4\xc3\xa4 omista ty\xc3\xb6menetelmist\xc3\xa4\xc3\xa4n. _NEWLINE_Yksi scrumtiimin j\xc3\xa4sen toimii tuotteen omistajana (engl. Product Owner). Tuoteomistaja vastaa tuotteen arvon ja kehitystiimin ty\xc3\xb6n arvon maksimoimisesta. K\xc3\xa4yt\xc3\xa4nn\xc3\xb6ss\xc3\xa4 t\xc3\xa4m\xc3\xa4 tapahtuu m\xc3\xa4\xc3\xa4rittelem\xc3\xa4ll\xc3\xa4 tuotteen vaatimukset sek\xc3\xa4 j\xc3\xa4rjest\xc3\xa4m\xc3\xa4ll\xc3\xa4 tuotteen kehitysjono yhteisty\xc3\xb6ss\xc3\xa4 scrumtiimin kanssa. Tuoteomistaja on yksi henkil\xc3\xb6, ei komitea. Tuoteomistaja voi hy\xc3\xb6dynt\xc3\xa4\xc3\xa4 komiteoita tai edustaa sellaisen toiveita tuotteen kehitysjonon kautta, mutta tuotteen kehitysjonon j\xc3\xa4rjestyksen muuttamiseksi tulee aina ensin vakuuttaa tuoteomistaja. Tuoteomistaja tuntee tuotteen liiketoimintaa ja edustaa asiakkaita ja k\xc3\xa4ytt\xc3\xa4ji\xc3\xa4. Tuoteomistajan toiminta maksimoi tuotekehitykseen sijoitetun p\xc3\xa4\xc3\xa4oman tuottoprosentin (ROI) ja varmistaa, ett\xc3\xa4 scrumtiimi toteuttaa jokaisessa sprintiss\xc3\xa4 sellaisia vaatimuksia, jotka ovat tuotteen onnistumisen kannalta keskeisimpi\xc3\xa4. Tuoteomistaja hyv\xc3\xa4ksyy sprinttikatselmuksessa edellisen sprintin tuoteversion ja osallistuu sprintin suunnittelupalaveriin varmistaakseen, ett\xc3\xa4 kehitystiimi ymm\xc3\xa4rt\xc3\xa4\xc3\xa4 sprinttiin valittavat tuotteen kehitysjonon kohdat riitt\xc3\xa4v\xc3\xa4ll\xc3\xa4 tarkkuudella. Tuoteomistaja my\xc3\xb6s auttaa kehitystiimi\xc3\xa4 ymm\xc3\xa4rt\xc3\xa4m\xc3\xa4\xc3\xa4n vaatimuksia ja tarvittaessa tarkentaa sprinttiin valittujen vaatimusten toteutustapaa sprintin aikana._NEWLINE_Toinen scrumtiimin rooleista on kehitystiimi (engl. Development Team). Kehitystiimi koostuu ammattilaisista, jotka muuttavat sprinttiin valitun tuotteen kehitysjonon sis\xc3\xa4ll\xc3\xb6n potentiaalisesti julkaisukelpoiseksi \xe2\x80\x9cvalmiiksi\xe2\x80\x9d tuoteversioksi jokaisessa sprintiss\xc3\xa4. Ainoastaan kehitystiimin j\xc3\xa4senet osallistuvat tuoteversion kehitykseen. Kehitystiimit ovat monitaitoisia sis\xc3\xa4lt\xc3\xa4en kaiken tarvittavan osaamisen potentiaalisesti julkaisukelpoisen tuoteversion kehitt\xc3\xa4miseksi. Kehitystiimin j\xc3\xa4senill\xc3\xa4 voi olla erityist\xc3\xa4 osaamista tai erilaisia ty\xc3\xb6n painopisteit\xc3\xa4, mutta vastuu kehityksest\xc3\xa4 kuuluu koko kehitystiimille yhdess\xc3\xa4._NEWLINE_Kolmas scrumtiimin rooli on scrummaster (engl. Scrum Master). Scrummaster vastaa siit\xc3\xa4, ett\xc3\xa4 kaikki ymm\xc3\xa4rt\xc3\xa4v\xc3\xa4t ja k\xc3\xa4ytt\xc3\xa4v\xc3\xa4t Scrumia. Scrummasterit tekev\xc3\xa4t t\xc3\xa4m\xc3\xa4n varmistamalla, ett\xc3\xa4 scrumtiimit pit\xc3\xa4ytyv\xc3\xa4t Scrumin teoriassa, k\xc3\xa4yt\xc3\xa4nn\xc3\xb6iss\xc3\xa4 ja s\xc3\xa4\xc3\xa4nn\xc3\xb6iss\xc3\xa4. Scrummaster on scrumtiimin palveleva johtaja. Toisin kuin perinteisell\xc3\xa4 esimiehell\xc3\xa4, scrummasterilla ei ole scrumtiimin j\xc3\xa4seniin suoraa m\xc3\xa4\xc3\xa4r\xc3\xa4ysvaltaa, vaan h\xc3\xa4n vaikuttaa scrumtiimiin Scrum-prosessin kautta. Scrummasterin teht\xc3\xa4v\xc3\xa4t koostuvat suurelta osin ryhm\xc3\xa4n ty\xc3\xb6skentely\xc3\xa4 haittaavien esteiden poistamisesta ja ryhm\xc3\xa4n valmentamisesta itseohjautuvuuteen. Scrummaster vastaa siit\xc3\xa4, ett\xc3\xa4 scrumtiimin p\xc3\xa4ivitt\xc3\xa4inen ty\xc3\xb6skentely on tuottavaa ja Scrumin pelis\xc3\xa4\xc3\xa4nt\xc3\xb6j\xc3\xa4 noudatetaan. H\xc3\xa4n tarkkailee ty\xc3\xb6n etenemist\xc3\xa4, ja jos sprintin tavoitteiden saavuttaminen alkaa n\xc3\xa4ytt\xc3\xa4\xc3\xa4 ep\xc3\xa4todenn\xc3\xa4k\xc3\xb6iselt\xc3\xa4, h\xc3\xa4n kommunikoi kehitystiimin ja tuoteomistajan kanssa tilanteen korjaamiseksi tai sprintin sis\xc3\xa4ll\xc3\xb6n kaventamiseksi. Scrummaster my\xc3\xb6s suojaa tiimi\xc3\xa4 ulkopuoliselta h\xc3\xa4lylt\xc3\xa4, kuten sprintin aikana pyydetyilt\xc3\xa4 uusilta vaatimuksilta, ja tekee kaikkensa turvatakseen tiimilleen ty\xc3\xb6rauhan.\n_START_SECTION_\nScrum-ban\n_START_PARAGRAPH_\nScrum-ban on ohjelmistotuotannon malli, joka perustuu Scrum- ja Kanban-menetelmiin. Scrum-ban soveltuu erityisesti yll\xc3\xa4pitoprojekteihin tai (j\xc3\xa4rjestelm\xc3\xa4)projekteihin, joissa vaatimuksia tai ohjelmistovirheit\xc3\xa4 tulee jatkuvasti ja yll\xc3\xa4tt\xc3\xa4en. T\xc3\xa4ll\xc3\xb6in Scrumin aikarajoitteisista sprinteist\xc3\xa4 ei ole mainittavaa hy\xc3\xb6ty\xc3\xa4. Sen sijaan Scrumin p\xc3\xa4ivitt\xc3\xa4isi\xc3\xa4 kokouksia ja muita k\xc3\xa4yt\xc3\xa4nt\xc3\xb6j\xc3\xa4 voidaan soveltaa tiimist\xc3\xa4 ja tarpeesta riippuen. Kanban-menetelm\xc3\xa4st\xc3\xa4 tuttua on ty\xc3\xb6vaiheiden visualisointi sek\xc3\xa4 rajoitteet sille, montako k\xc3\xa4ytt\xc3\xa4j\xc3\xa4tarinaa tai korjausta voi kussakin ty\xc3\xb6vaiheessa olla kesken (engl. Work In Progress (WIP)). N\xc3\xa4iden avulla ohjataan kehitystiimin tekemist\xc3\xa4 niin, ett\xc3\xa4 k\xc3\xa4ytt\xc3\xa4j\xc3\xa4tarinan tai korjauksen l\xc3\xa4pimenoaika on mahdollisimman lyhyt ja toisaalta tiimin j\xc3\xa4senet ovat sopivasti ty\xc3\xb6llistettyj\xc3\xa4. _NEWLINE_Ty\xc3\xb6vaiheiden havainnollistamiseksi samassa tilassa olevat tiimit k\xc3\xa4ytt\xc3\xa4v\xc3\xa4t yleens\xc3\xa4 post-it -lappuja ja isoa taulua. Hajautettujen tiimien tapauksessa ty\xc3\xb6vaiheiden visualisoinnin tarjoavat ohjelmistot ovat k\xc3\xa4yt\xc3\xa4nn\xc3\xb6llisi\xc3\xa4. Mm. ScrumWorks sek\xc3\xa4 JIRA+GreenHopper n\xc3\xa4ytt\xc3\xa4v\xc3\xa4t kehitystiimin k\xc3\xa4ytt\xc3\xa4j\xc3\xa4tarinat, ohjelmistovirheet tai teht\xc3\xa4v\xc3\xa4t jaoteltuna eri vaiheisiin._NEWLINE_Ty\xc3\xb6vaiheet ovat yksinkertaisimmillaan: aloittamattomat, k\xc3\xa4ynniss\xc3\xa4 olevat sek\xc3\xa4 tehdyt teht\xc3\xa4v\xc3\xa4t tai k\xc3\xa4ytt\xc3\xa4j\xc3\xa4tarinat. Kehitystiimit voivat kuitenkin halutessaan lis\xc3\xa4t\xc3\xa4 vaiheita (esim. m\xc3\xa4\xc3\xa4ritelty, suunniteltu, testattu, toimitettu). Ylim\xc3\xa4\xc3\xa4r\xc3\xa4iset vaiheet voivat auttaa jos joku vaihe muodostuu pullonkaulaksi eik\xc3\xa4 keskener\xc3\xa4isen ty\xc3\xb6n raja-arvoja haluta nostaa. Tarkempi vaihejaottelu mahdollistaa paremmin my\xc3\xb6s kehitt\xc3\xa4jien erikoistumisen tiettyihin ty\xc3\xb6vaiheisiin.  _NEWLINE_Keskener\xc3\xa4iselle ty\xc3\xb6lle ei ole olemassa m\xc3\xa4\xc3\xa4riteltyj\xc3\xa4 raja-arvoja, vaan jokaisen tiimin t\xc3\xa4ytyy ne m\xc3\xa4\xc3\xa4ritell\xc3\xa4 itse kokeilun ja erehdyksen kautta. Liian pieni raja-arvo aiheuttaa tiimin j\xc3\xa4senten odottamista, koska ty\xc3\xb6t\xc3\xa4 ei tule seuraavaan vaiheeseen tarpeeksi nopeasti. Toisaalta liian suuret raja-arvot ker\xc3\xa4\xc3\xa4v\xc3\xa4t suuren keskener\xc3\xa4isen ty\xc3\xb6n varaston, mik\xc3\xa4 hidastaa l\xc3\xa4pimenoaikaa. Yhten\xc3\xa4 nyrkkis\xc3\xa4\xc3\xa4nt\xc3\xb6n\xc3\xa4 voidaan kuitenkin pit\xc3\xa4\xc3\xa4, ett\xc3\xa4 kenell\xc3\xa4k\xc3\xa4\xc3\xa4n tiimin j\xc3\xa4senell\xc3\xa4 ei pit\xc3\xa4isi olla valittuna enemp\xc3\xa4\xc3\xa4 kuin kaksi teht\xc3\xa4v\xc3\xa4\xc3\xa4 kerrallaan ja toisaalta kaikilla tiimin j\xc3\xa4senill\xc3\xa4 ei saisi olla samanaikaisesti kahta teht\xc3\xa4v\xc3\xa4\xc3\xa4.  _NEWLINE_Scrumin ja Kanbanin suurin ero on siin\xc3\xa4, ett\xc3\xa4 Scrumissa sprintit ovat aikarajattuja, kun taas Kanbanissa ty\xc3\xb6skenteleminen on jatkuvaa. T\xc3\xa4m\xc3\xa4 n\xc3\xa4kyy ty\xc3\xb6vaihetauluissa, jotka Scrumissa tyhjennet\xc3\xa4\xc3\xa4n sprintin j\xc3\xa4lkeen. Kanbanissa teht\xc3\xa4v\xc3\xa4t taas liikkuvat jatkuvasti samalla taululla. Scrum painottaa monitaitoisia tiimej\xc3\xa4, jotka pystyv\xc3\xa4t itsen\xc3\xa4isesti kehitt\xc3\xa4m\xc3\xa4\xc3\xa4n potentiaalisesti julkaistavan tuoteversion. Kanban taas mahdollistaa erikoistuneet, toiminnalliset tiimit._NEWLINE_Koska Scrum-ban on menetelm\xc3\xa4n\xc3\xa4 suhteellisen uusi, sen k\xc3\xa4yt\xc3\xb6st\xc3\xa4 ei ole olemassa juurikaan artikkeleita. Sen sijaan Kanbania on sovellettu ohjelmistotuotannossa ainakin Microsoftilla sek\xc3\xa4 Corbiksella.'