Scrum
Scrum on projektinhallinnan viitekehys, jota käytetään yleisesti ketterässä ohjelmistokehityksessä. Vaikka Scrum on kehitetty erityisesti ohjelmistoprojektien hallintaan, sitä voidaan soveltaa myös yleisesti projektinhallinnassa. Ensimmäisinä idean scrumin kehitysprosessista kuvasivat 1986 Hirotaka Takeuchi ja Ikujiro Nonaka. Teoksessaan Takeuchi ja Nonaka kuvaavat uudenlaisen, holistisen lähestymistavan tuotekehitykseen, jossa yksi ainoa monitaitoinen () ryhmä suorittaa kehitysprosessin alusta loppuun vaiheistuksella, joka on vahvasti lomittunut. Ryhmän toimintaa verrataan rugby-joukkueeseen, jossa koko ryhmä pyrkii etenemään yksikkönä ja toimimaan tiiviissä yhteistyössä. Myös menetelmän nimi () viittaa rugbyn aloitusryhmitykseen. Nimi on myös sittemmin jäänyt käyttöön johtuen menetelmän yhtäläisyyksistä rugby-joukkueeseen ja sen toimintaan; molemmat ovat erilaisiin tilanteisiin sopeutuvaisia, nopeita ja itseohjautuvia.
Varsinaisen scrum-viitekehyksen kehittäjinä pidetään Jeff Sutherlandia, Ken Schwaberia, John Scumniotalesia ja Jeff McKennaa.
Scrumissa työskennellään toistavasti ja lisäävästi () ennustettavuuden optimoimiseksi ja riskien kontrolloimiseksi. Tavoitteena oleva tuote kehittyy pikkuhiljaa täydellisemmäksi ja valmiimmaksi useiden kehitysjaksojen aikana. Kehitysjaksoa kutsutaan sprintiksi (). Sprintti on 1-4 viikon mittainen aikaraja, jonka sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti julkaisukelpoinen tuoteversio. Jokaisen sprintin sisältö sovitaan sprintin suunnittelupalaverissa ennen sprintin aloitusta, ja toteutettaviksi valitaan sellaisia tuotteen kehitysjonon kohtia, joilla on sillä hetkellä suurin merkitys projektin onnistumiselle. Sprintin lopuksi järjestetään sprinttikatselmus, jossa kehitystiimi esittelee sprintin konkreettiset saavutukset (esim. ohjelmiston uusimman version) tuoteomistajalle sekä mahdollisille sidosryhmien edustajille palautteen saamiseksi ja ymmärryksen lisäämiseksi kehityksen tilasta. Ennen seuraavan sprintin aloittamista pidetään vielä sprintin retrospektiivi, jossa tarkastellaan prosessin näkökulmasta mikä sprintin aikana sujui hyvin ja mitä voitaisiin parantaa seuraavassa sprintissä.
Scrum-kehityksessä käytetään yhtä tai useampaa scrumtiimiä (). Scrumtiimi koostuu tuoteomistajasta, scrummasterista ja kehitystiimistä. Scrumtiimi päättää kunkin sprintin tavoitteet ja tehtävät, ja vastaa yhdessä siitä, että asetettuihin tavoitteisiin päästään. Scrumtiimi on itseohjautuva ja monitaitoinen, ja sillä on valta päättää omista työmenetelmistään.
Yksi scrumtiimin jäsen toimii tuotteen omistajana (). Tuoteomistaja vastaa tuotteen arvon ja kehitystiimin työn arvon maksimoimisesta. Käytännössä tämä tapahtuu määrittelemällä tuotteen vaatimukset sekä järjestämällä tuotteen kehitysjono yhteistyössä scrumtiimin kanssa. Tuoteomistaja on yksi henkilö, ei komitea. Tuoteomistaja voi hyödyntää komiteoita tai edustaa sellaisen toiveita tuotteen kehitysjonon kautta, mutta tuotteen kehitysjonon järjestyksen muuttamiseksi tulee aina ensin vakuuttaa tuoteomistaja. Tuoteomistaja tuntee tuotteen liiketoimintaa ja edustaa asiakkaita ja käyttäjiä. Tuoteomistajan toiminta maksimoi tuotekehitykseen sijoitetun pääoman tuottoprosentin (ROI) ja varmistaa, että scrumtiimi toteuttaa jokaisessa sprintissä sellaisia vaatimuksia, jotka ovat tuotteen onnistumisen kannalta keskeisimpiä. Tuoteomistaja hyväksyy sprinttikatselmuksessa edellisen sprintin tuoteversion ja osallistuu sprintin suunnittelupalaveriin varmistaakseen, että kehitystiimi ymmärtää sprinttiin valittavat tuotteen kehitysjonon kohdat riittävällä tarkkuudella. Tuoteomistaja myös auttaa kehitystiimiä ymmärtämään vaatimuksia ja tarvittaessa tarkentaa sprinttiin valittujen vaatimusten toteutustapaa sprintin aikana.
Toinen scrumtiimin rooleista on kehitystiimi (). Kehitystiimi koostuu ammattilaisista, jotka muuttavat sprinttiin valitun tuotteen kehitysjonon sisällön potentiaalisesti julkaisukelpoiseksi “valmiiksi” tuoteversioksi jokaisessa sprintissä. Ainoastaan kehitystiimin jäsenet osallistuvat tuoteversion kehitykseen. Kehitystiimit ovat monitaitoisia sisältäen kaiken tarvittavan osaamisen potentiaalisesti julkaisukelpoisen tuoteversion kehittämiseksi. Kehitystiimin jäsenillä voi olla erityistä osaamista tai erilaisia työn painopisteitä, mutta vastuu kehityksestä kuuluu koko kehitystiimille yhdessä.
Kolmas scrumtiimin rooli on scrummaster (). Scrummaster vastaa siitä, että kaikki ymmärtävät ja käyttävät Scrumia. Scrummasterit tekevät tämän varmistamalla, että scrumtiimit pitäytyvät Scrumin teoriassa, käytännöissä ja säännöissä. Scrummaster on scrumtiimin palveleva johtaja. Toisin kuin perinteisellä esimiehellä, scrummasterilla ei ole scrumtiimin jäseniin suoraa määräysvaltaa, vaan hän vaikuttaa scrumtiimiin Scrum-prosessin kautta. Scrummasterin tehtävät koostuvat suurelta osin ryhmän työskentelyä haittaavien esteiden poistamisesta ja ryhmän valmentamisesta itseohjautuvuuteen. Scrummaster vastaa siitä, että scrumtiimin päivittäinen työskentely on tuottavaa ja Scrumin pelisääntöjä noudatetaan. Hän tarkkailee työn etenemistä, ja jos sprintin tavoitteiden saavuttaminen alkaa näyttää epätodennäköiseltä, hän kommunikoi kehitystiimin ja tuoteomistajan kanssa tilanteen korjaamiseksi tai sprintin sisällön kaventamiseksi. Scrummaster myös suojaa tiimiä ulkopuoliselta hälyltä, kuten sprintin aikana pyydetyiltä uusilta vaatimuksilta, ja tekee kaikkensa turvatakseen tiimilleen työrauhan.
Scrumin tuotokset kuvaavat työtä tai lisäarvoa tavoilla, jotka lisäävät läpinäkyvyyttä ja tilaisuuksia tarkastelulle ja sopeuttamiselle. Scrumin tuotokset on suunniteltu erityisesti maksimoimaan läpinäkyvyyden niille keskeisille tiedoille, jotka auttavat scrumtiimejä onnistuneesti toimittamaan “valmiin” tuoteversion.Scrumissa käytetään ennaltasovittuja tapahtumia luomaan säännöllisyyttä ja minimoimaan muiden kuin Scrum-­palavereiden tarve. Scrumin tapahtumat ovat aikarajattuja eli jokaisella niistä on maksimipituus. Tämä varmistaa sen, että suunnittelulle varataan riittävästi aikaa, mutta suunnitteluprosessissa ei pääse syntymään hukkaa.
Scrum-ban on ohjelmistotuotannon malli, joka perustuu Scrum- ja Kanban-menetelmiin. Scrum-ban soveltuu erityisesti ylläpitoprojekteihin tai (järjestelmä)projekteihin, joissa vaatimuksia tai ohjelmistovirheitä tulee jatkuvasti ja yllättäen. Tällöin Scrumin aikarajoitteisista sprinteistä ei ole mainittavaa hyötyä. Sen sijaan Scrumin päivittäisiä kokouksia ja muita käytäntöjä voidaan soveltaa tiimistä ja tarpeesta riippuen. Kanban-menetelmästä tuttua on työvaiheiden visualisointi sekä rajoitteet sille, montako käyttäjätarinaa tai korjausta voi kussakin työvaiheessa olla kesken (). Näiden avulla ohjataan kehitystiimin tekemistä niin, että käyttäjätarinan tai korjauksen läpimenoaika on mahdollisimman lyhyt ja toisaalta tiimin jäsenet ovat sopivasti työllistettyjä.
Työvaiheiden havainnollistamiseksi samassa tilassa olevat tiimit käyttävät yleensä post-it -lappuja ja isoa taulua. Hajautettujen tiimien tapauksessa työvaiheiden visualisoinnin tarjoavat ohjelmistot ovat käytännöllisiä. Mm. ScrumWorks sekä JIRA+GreenHopper näyttävät kehitystiimin käyttäjätarinat, ohjelmistovirheet tai tehtävät jaoteltuna eri vaiheisiin.
Työvaiheet ovat yksinkertaisimmillaan: aloittamattomat, käynnissä olevat sekä tehdyt tehtävät tai käyttäjätarinat. Kehitystiimit voivat kuitenkin halutessaan lisätä vaiheita (esim. määritelty, suunniteltu, testattu, toimitettu). Ylimääräiset vaiheet voivat auttaa jos joku vaihe muodostuu pullonkaulaksi eikä keskeneräisen työn raja-arvoja haluta nostaa. Tarkempi vaihejaottelu mahdollistaa paremmin myös kehittäjien erikoistumisen tiettyihin työvaiheisiin.
Keskeneräiselle työlle ei ole olemassa määriteltyjä raja-arvoja, vaan jokaisen tiimin täytyy ne määritellä itse kokeilun ja erehdyksen kautta. Liian pieni raja-arvo aiheuttaa tiimin jäsenten odottamista, koska työtä ei tule seuraavaan vaiheeseen tarpeeksi nopeasti. Toisaalta liian suuret raja-arvot keräävät suuren keskeneräisen työn varaston, mikä hidastaa läpimenoaikaa. Yhtenä nyrkkisääntönä voidaan kuitenkin pitää, että kenelläkään tiimin jäsenellä ei pitäisi olla valittuna enempää kuin kaksi tehtävää kerrallaan ja toisaalta kaikilla tiimin jäsenillä ei saisi olla samanaikaisesti kahta tehtävää.
Scrumin ja Kanbanin suurin ero on siinä, että Scrumissa sprintit ovat aikarajattuja, kun taas Kanbanissa työskenteleminen on jatkuvaa. Tämä näkyy työvaihetauluissa, jotka Scrumissa tyhjennetään sprintin jälkeen. Kanbanissa tehtävät taas liikkuvat jatkuvasti samalla taululla. Scrum painottaa monitaitoisia tiimejä, jotka pystyvät itsenäisesti kehittämään potentiaalisesti julkaistavan tuoteversion. Kanban taas mahdollistaa erikoistuneet, toiminnalliset tiimit.
Koska Scrum-ban on menetelmänä suhteellisen uusi, sen käytöstä ei ole olemassa juurikaan artikkeleita. Sen sijaan Kanbania on sovellettu ohjelmistotuotannossa ainakin Microsoftilla sekä Corbiksella.