6.6.2013

Ketteryys haltuun: Scrum pähkinänkuoressa

Ketteryys haltuun -artikkelisarjassa julkaistut muut osat:
Osa 1: Ketterän kehityksen yleiset periaatteet
Osa 2: Yleisimmät ketterät käytännöt
Osa 4: Ketteryys haltuun: Miten ostan ketteriä IT-projekteja?

Ketteryys haltuun -artikkelisarjassa kerrotaan ketterän kehittämisen periaatteista ja käytännön menetelmistä. Ketterä kehittäminen on kerännyt paljon huomiota, mutta ilmiö ei ole lainkaan yksiselitteinen eikä ketterän kehittämisen soveltaminen käytännössä ole aina yksinkertaista. Tämän artikkelisarjan tavoitteena on avata peruskäsitteitä ja auttaa ymmärtämään mitä ketteryys ohjelmistokehityksessä tarkoittaa.

Sarjan kolmannessa osassa tarkastellaan Suomessa yleisintä ketterän kehityksen menetelmää, Scrumia. Artikkelissa esitellään Scrumin keskeiset toiminnot ja käsitteet. Näiden ymmärtäminen on hyödyllistä erityisesti asiakkaille jotka ovat ostamassa ketterää projektia tai aloittamassa tekemään projektia ketterillä menetelmillä. Etenkin Scrumista on käytössä eri toimijoilla erilaisia sovellutuksia ja hyvin harvoin Scrumia noudetaan kovin tarkasti. Monia Scrumin elementtejä on alettu käyttämään myös monissa ei-niin-ketterissä-projektimalleissa, esimerkiksi tuotteen työlista ja päiväpalaverit.

Scrum pähkinänkuoressa

Scrum tarjoaa sovelluskehitykseen mallin, jonka mukaan projektia ohjataan. Scrum ei ota kantaa matalan tason insinöörikäytäntöihin, vaan keskittyy ennen muuta projektin vaiheistamiseen ja jatkuvaan kontrolliin projektin etenemisestä. Näin Scrum soveltuu etenkin asiakkaille hyväksi johdannoksi ketterien menetelmien maailmaan.

Scrum – kuten kaikki muutkin ketterät mallit – näkee ohjelmistokehityksen rakentuvan erimittaisten syklien ympärille. Tärkeimmät syklit ovat sprintti ja päivä. Sprintillä tarkoitetaan yhtä kehitysjaksoa, jonka jälkeen tuote on ainakin periaatteessa julkaisuvalmis. Tyypillisesti sprintin kesto on kuukausi, mutta sen pituus vaihtelee organisaation tarpeiden mukaan viikosta kahteen kuukauteen.

Roolit

Vesiputousmallin mukaisissa projekteissa on yleensä ainakin määrittelijä, suunnittelija, ohjelmoija, testaaja ja projektipäällikkö. Projektipäällikköä lukuunottamatta kussakin roolissa voi olla useampia henkilöitä ja toisaalta yksi henkilö voi joissain tapauksissa kuulua useampaankin rooliin.

Scrum-projektissa esiintyy vain kolme eri roolia: Tuotteen omistaja, Scrum-mestari ja tiimi.

Tuotteen omistaja

Tuotteen omistaja (Product Owner) on henkilö, joka viime kädessä vastaa tuotteen ominaisuuksista, siis “omistaa” tuotteen. Tuotekehitysprojekteissa omistaja on tyypillisesti tuotepäällikkö, asiakasprojekteissa se voi olla asiakkaan edustaja tai toimittajan tekninen projektipäällikkö. Tuotteen omistajan tehtävänä on tehdä kaikki päätökset tuotteen ominaisuuksista ja toiminnallisuuksiin vaikuttavista seikoista. Asiakkaan näkökulmasta Scrum on tässä kohtaa kovin vaativa, koska Scrum haluaa projektilla olevan vain yhdet kasvot asiakkaan puolella. Käytännössä tämä tarkoittaa usein sitä, että asiakkaan organisaatiossa projektin omistajan ja projektipäällikön tulisi olla sama henkilö. Jos näin ei voida tehdä, niin ainakin asiakkaan puolella projektipäällikkönä toimivalle tulisi voida antaa selkeät toimintavaltuudet tehdä päätöksiä.

Scrum-mestari

Scrum-mestarin (Scrum Master) tehtävänä on huolehtia siitä, että tiimi voi tehdä työtään optimaalisella tavalla. Tiimiläiset raportoivat päivittäin ongelmista, jotka hidastavat töiden etenemistä ja mestarin tehtävänä on ratkoa nämä ongelmat. Tämän lisäksi hän johtaa päivittäiset aamupalaverit ja vastaa siitä, että Scrumia noudatetaan oikein.

Tiimi

Tiimiin kuuluvat kaikki henkilöt, jotka projektia ovat tekemässä. Tiimin sisältä ei erikseen nimitetä arkkitehteja, ohjelmoijia, testaajia tai käyttöliittymäsuunnittelijoita, vaan tiimiin kasataan henkilöitä, joilla on tarvittava osaaminen. Sitten tiimi yhdessä rakentaa tuotteen. Tällä halutaan korostaa kunkin tiimiläisen olevan projektin kannalta yhtä tärkeä ja että tiimi yhdessä vastaa tuotteen kaikista puolista, ei koskaan yksittäinen henkilö.

Tiimin sisällä kaikki tekevät kaikkensa projektin edistämiseksi. Käytännössä eri ihmiset osaavat luonnollisesti eri asioita, ja on järkevää, että kukin tekee sitä, minkä osaa parhaiten. Olennaista kuitenkin on, että tiimi vastaa itse yhteisöllisesti tehtävien jaosta, jolloin työtehtäviä ei ajauduta pompottelemaan henkilöltä toiselle tyyliin ”Tämä ei kuulu minulle”, ”tuo on koodarin homma” tai ”dokumentoija paikalle, koodini on valmis”.

Aktiviteetit

Visiointi

Ennen projektin aloittamista luodaan korkean tason visio siitä, mitä projektilta halutaan. Visio vastaa kysymyksiin ”miksi projekti tehdään” ja ”mitä projektin lopputuotteena saadaan”.

Tuotteen työlistan muodostaminen

Vision jälkeen muodostetaan alustava tuotteen työlista (Product Backlog), eli lista tuotteeseen tarvittavista ominaisuuksista. Ennen toteutuksen aloittamista tuotteen omistajan on priorisoitava ominaisuuslista.

Sprintin suunnittelu 

Sprintin aikana tiimi toteuttaa sprinttiin kuuluviksi valittuja toiminnallisuuksia. Sprintin aikana vaatimusten muuttaminen on kiellettyä, ja tiimillä on täysi vapaus tehdä tarpeelliseksi katsomiaan toimenpiteitä, jotta sovittu sprintin päämäärä voidaan saavuttaa. Tiimi organisoi itsensä parhaaksi katsomallaan tavalla.

Sprintti

Sprintin aikana tiimi toteuttaa sprinttiin kuuluviksi valittuja toiminnallisuuksia. Sprintin aikana vaatimusten muuttaminen on kiellettyä, ja tiimillä on täysi vapaus tehdä tarpeelliseksi katsomiaan toimenpiteitä, jotta sovittu sprintin päämäärä voidaan saavuttaa. Tiimi organisoi itsensä parhaaksi katsomallaan tavalla.

Päiväpalaveri (daily scrum)

Joka päivä tiimi kokoontuu yhteen lyhyeen tilannepalaveriin, jossa kukin tiimin jäsen vastaa kolmeen kysymykseen:

  • Mitä teit edellisen päivän aikana?
  • Mitä aiot tehdä seuraavan päivän aikana?
  • Mitkä tekijät estävät (tai hidastavat) sinua saavuttamasta sprintin tavoitteita?

Palaveriin osallistuvat ainakin kaikki tiimin jäsenet ja scrum-mestari. Palaveri on myös avoin kaikille muille, jotka ovat jollain tavalla projektista kiinnostuneita. Vain tiimiläiset saavat kuitenkin puhua. Tapahtuman tarkoitus on nimenomaisesti tarjota kaikille tieto siitä, missä projekti menee ja mitä ongelmia sillä on.

Jos jostain asiasta pitää keskustella tarkemmin, sitä varten pidetään oma palaverinsa, jossa ovat läsnä vain ne henkilöt, joita asia koskettaa. Päiväpalaverin suositeltava kesto on 15 minuuttia ja usein palaverin venähtämisen ehkäisemiseksi se pidetään seisten.

Sprintin katselmointi

Jokaisen sprintin lopuksi tiimi esittelee valmista tuotetta tuotteen omistajalle. Sprintin lopuksi tuotteen siis pitäisi olla periaatteessa käyttöönotettavissa: se on toteutettu, testattu, dokumentoitu, käyttöliittymä on valmis ja niin edelleen. Näin omistaja voi päättää joko seuraavan sprintin tekemisestä tai tuotteen käyttöönottamisesta.

Tähän tapahtumaan saa osallistua kuka tahansa, joka on projektista kiinnostunut.

Sprintin jälkitarkastelu

Kunkin sprintin lopuksi tiimi, scrum-mestari ja omistaja tarkastelevat päättynyttä sprinttiä. Kukin tiimin jäsen kertoo omasta näkökulmastaan, mikä sprintissä meni hyvin ja mitä voisi parantaa. Lopuksi tiimi yhdessä priorisoi kehityskohteet ja pyrkii toteuttamaan muutokset seuraavan sprintin aikana.

Sprintin jälkitarkastelun jälkeen kierros alkaa alusta uuden sprintin suunnittelulla. Tässä vaiheessa omistaja voi jälleen vapaasti muuttaa tuotteen työlistaa, ja tiimi arvioi taas uudelleen, minkä ominaisuuksien toteuttamiseen se voi sitoutua.

Scrumin arvot

Scrum ei rakennu valikoidusta joukosta käytäntöjä vaan pohjautuu muutamaan arvoon. Nämä arvot ovat kaikkien Scrumin periaatteiden ja aktiviteettien taustalla.

Sitoutuminen

Tiimin tehtävä on sitoutua yhteiseen päämäärään. Tiimi on oikeutettu saamaan kaiken tuen, jotta he voivat saavuttaa sitoumuksensa.

Perinteisissä menetelmissä tiimille usein vain annetaan ulkoa käsin työtehtäviä ja pahimmillaan vielä määrätään, miten työ on tehtävä. Scrumissa tiimi itse sitoutuu toimittamaan seuraavan sprintin aikana määrätyt toiminnallisuudet. Samalla tiimi saa sprintin aikana vapauden toimia parhaaksi katsomallaan tavalla. Scrum-mestari ja ympäröivä organisaatio omalta osaltaan sitoutuvat tukemaan tiimiä poistamalla heitä häiritseviä tekijöitä.

Jotta tiimi voi sitoutua johonkin tavoitteeseen, on tämän tavoitteen oltava niin selkeä, että sprintin jälkeen voidaan todeta, onko tiimi onnistunut vai ei.

Keskittyminen

Tee työsi hyvin. Keskity vain siihen, minkä olet luvannut tehdä äläkä huolehdi muusta. Jokaiselle sprintille asetetaan selkeä tavoite. Tämän tavoitteen saavuttaminen on tiimin tärkein tehtävä. Kaikki muut oheisaktiviteetit ovat toissijaisia.

Avoimuus

On tärkeää, että kaikki projektiin liittyvät tiedot ovat näkyviä kaikille. Scrumissa kaikki on avointa: projektin ja sprintin työlistat ovat julkisia, ja myös päivittäiskokous on avoinna kaikille kiinnostuneille (joskin vain tiimiin kuuluvat saavat puhua). Myös jokaisen sprintin tulokset esitellään julkisesti.

Kunnioitus

Ihmisiä käsitellään yksilöinä heidän taustojensa ja kokemusten mukaan. On tärkeää kunnioittaa kutakin tiimin jäsentä juuri sellaisena kuin hän on. Tiimin itseorganisoituvuutta ja työrauhaa on myös kunnioitettava. Jokaisen tiimiläisen on kunnioitettava muita tekemällä jatkuvasti parhaansa, ja odotettava samaa myös muilta.

Rohkeus

Ole rohkea sitoutumaan, toimimaan, olemaan avoin ja odota muilta kunnioitusta. Keskittyneesti ja avoimesti toimiminen voi joissain tilanteissa vaatia rohkeutta. Esimerkiksi omat virheet on myönnettävä heti ja äänekkäästi, jotta niistä voidaan oppia. Usein tiimi itse tietää, miten joku ongelma kannattaa ratkaista, mutta joku ulkopuolinen taho on eri mieltä. Tällöin vaatii suurta rohkeutta toimia, mahdollisesti jopa vastoin yrityksen virallisista toimintatapaa. Tätä ei kuitenkaan pidä sotkea vastuuttomuuteen.

Säännöt

Sprintin suunnittelukokous

Sprintin suunnittelukokous on yhden päivän mittainen työpaja, minkä ensimmäisellä puoliskolla valitaan tuotteen työlistasta seuraavan sprintin vaatimukset ja toinen puoli käytetän seuraavan sprintin valmisteluun.

  • Kokoukseen osallistuvat Scrum-mestari, tuotteen omistaja ja tiimi. Ulkopuolisia asiantuntijoita voidaan pyytää konsultoimaan joissain erityistietämystä vaativissa toimenpiteissä. Ulkopuolisia kuunteluoppilaita kokoukseen ei päästetä.
  • Tuotteen omistajan on priorisoitava tuotteen työlista ennen kokousta. Mikäli tuotteen työlista tai tuotteen omistajaa ei ole saatavilla kokoukseen, Scrum-mestarin on edustettava tuotteen omistajaa.
  • Tiimi päättää kuinka suuri osa tuotteen työlistasta voidaan valita seuraavaan sprinttiin.
    Tuotteen työlistan analysointiin ei voida käyttää enemmän aikaa kuin kokouksen ensimmäinen on puolisko. Mikäli jotkut kohdat vaativat selvitystä, se on tehtävä sprintin aikana.
  • Suunnittelukokousta ei voida jakaa useammalle päivälle, eikä puoliskojen välissä pidetä mitään erityistä taukoa.
  • Työpajan jälkipuoliskolla tuotteen omistajan on henkilökohtaisesti oltava paikalla vastaamassa tiimin kysymyksiin.
  • Tiimi vastaa itsenäisesti siitä, miten sprintin työlistaksi valitut vaatimukset muutetaan julkaistavissa olevaksi tuotteen osaksi.
  • Työpajan lopputuotteena on seuraavan sprintin työlista. Työlistan ei tarvitse olla lopullinen, mutta sen on oltava riittävän hyvä, jotta sprintin toteuttaminen voidaan aloittaa.

Päiväpalaveri

Päiväpalaverin kesto on rajattu 15 minuuttin riippumatta tiimin koosta.

Päiväpalaveri on pidettävä samassa paikassa ja samaan aikaan jokaisena työpäivänä.
Jokaisen tiimiläisen on oltava läsnä. Mikäli tämä ei ole fyysisesti mahdollista, tiimiläinen voi osallistua joko puhelimitse tai pyytää toista tiimiläistä vastaamaan hänen puolestaan.
Tiimiläisten on oltava ajoissa. Scrum-mestari aloittaa päiväpalaverin sovittuna aikana riippumatta keitä on paikalla. Jokainen myöhässä oleva tiimiläinen maksaa euron Scrum-mestarille.
Scrum-mestari aloittaa kokouksen vasemmalla puolellaan olevasta henkilöstä ja jatkaa vastapäivään kunnes kaikki ovat raportoineet tilanteensa.

Kukin tiimiläinen vastaa kolmeen kysymykseen:

  • Mitä olet tehnyt edellisen päiväpalaverin jälkeen?
  • Mitä aiot tehdä ennen seuraavaa päiväpalaveria?
  • Mitkä seikat estävät sinua pääsemästä tavoitteeseesi?

Em. kysymyksiin vastaamisen lisäksi muuta keskustelua ei sallita. Scrum-mestari vastaa siitä että puheenvuoro siirtyy tiimiläiseltä toiselle joutuisasti.

Vain yksi henkilö puhuu kerrallaan.

Jos joku tiimiläinen kertoo jotain, mikä aiheuttaa erityistä kiinnostusta muissa, tai kaipaa apua omien tehtäviensä suorittamiseen, kuka tahansa tiimiläisistä voi järjestää erillisen kokouksen päiväpalaverin jälkeen.

Sprintti

Sprintin pituus on rajattu 30:een kalenteripäivään. Tämä on sellainen aika, jossa tiimin on ehdittävä toteuttaa jotain merkittävää, mikä on julkaistavissa olevaa laatua. Tätä pidemmät työrupeamat alkavat jo vaatia tarkempaa suunnittelua ja dokumentaatiota työn tueksi. Myöskään tuotteen omistaja ja muut sidosryhmät eivät useinkaan halua odottaa tätä kauempaa ilman että näkevät todellista edistymistä projektissa.

  • Tiimi voi etsiä ulkopuolista apua sprintin aikana.
  • Kukaan ei saa tyrkyttää tukeaan tiimille, eikä kommentoida tiimin tekemisiä sprintin aikana. Tiimi on täysin itseohjautuva.
  • Tiimi sitoutuu tuotteen työlistaan sprintin suunnittelukokouksessa. Sprintin aikana tuotteen työlistan muuttaminen on kiellettyä.
  • Jos ilmenee että sprintti ei ole toteuttamiskelpoinen, Scrum-mestari voi keskeyttää sen koska tahansa ja aloittaa uuden sprintin suunnittelukokouksen. Scrum-mestari voi tehdä tämän omasta aloitteestaan tai jos tiimi tai tuotteen omistaja pyytää sitä. Tyypillisiä syitä sprintin keskeyttämiselle on valitun teknologian osoittautuminen käyttökelvottomaksi, odottamattomat muutokset liiketoimintaympäristössä tai mikäli joku ulkopuolinen tekijä on häirinnyt tiimiä.
  • Jos tiimi totetaa ettei kykene suoriutumaan sprintistä, se voi neuvotella tuotteen omistajan kanssa, mitkä ominaisuudet voidaan siirtää seuraaviin sprintteihin. Jos liian suuri osa sprintistä näyttää jäävän valmistumatta, Scrum-mestari voi keskeyttää sprintin edellä kuvatusti.
  • Jos tiimi toteaa että se ehtisi toteuttamaan enemmän kuin mihin oli sitoutunut, se voi neuvotella tuotteen omistajan kanssa mitä ominaisuuksia sprinttiin voidaan lisätä.
  • Tiimiläisillä on kaksi hallinnollista velvollisuutta sprintin aikana: heidän on osallistuttava päiväpalaveriin ja pidettävä sprintin työlista ajan tasalla. Sprintin työlistan on oltava julkisesti nähtävillä ja arviot jäljellä olevasta työmäärästä on päivitettävä päivittäin.

Sprintin katselmointi

Sprintin katselmointi kestää enintään neljä tuntia.

  • Tiimi voi käyttää enintään yhden tunnin katselmointiin valmistautumiseen.
  • Katselmoinnin tarkoitus on esitellä tuotteen omistajalle ja muille sidosryhmille sprintin tuloksia.
  • Keskeneräisiä tuotoksia ei saa esitellä
  • Tuotoksia, jotka eivät ole julkaistavissa olevaa toiminnallisuutta, ei voida esitellä muutoin kuin tukemaan toiminnallisuuden esittelyä. Dokumentteja yms ei voida esitellä varsinaisina työn tuloksina.
  • Toiminnallisuus on esiteltävä jonkun tiimiläisen koneelta ja sovelluksen on toimittava mahdollisimman hyvin tuotantoympäristöä vastaavassa ympäristössä.
  • Katselmointi alkaa siten, että joku tiimiläisistä esittelee sprintin tavoitteen, tuotteen työlistan johon tiimi sitoutui ja työlistan jossa näkyy toteutetut toiminnot. Muut tiimiläiset voivat esittää kommentteja, mikä meni hyvin ja mikä ei.
  • Suurin osa katselmoinnista on käytettävä siihen, että tiimiläiset esittelevät toteutettuja toiminnallisuuksia ja vastaavat sidosryhmäläisten kysymyksiin.
  • Esittelyn jälkeen kultakin katselmoijalta kysytään mielipidettä sprintin onnistumisesta sekä tuotteeseen tarvittavista muutoksista ja niiden tärkeydestä.
  • Tuotteen omistaja keskustelee katselmoijien ja tiimin kanssa tuotteen työlistaan tarvittavista muutoksista.
  • Katselmoijat voivat koska tahansa esittää kommentteja, kysymyksiä ja kritiikkiä koskien julkaistavissa olevaa tuotteen osaa.
  • Katselmoijat voivat esittää toimintoja, joita ei olla toteutettu lainkaan tai ei ole toteutettu odotetulla tavalla ja vaatia näiden toimintoje sijoittaa uudelleen työlistalle.
  • Katselmoijat voivat koska tahansa esittää vaatimuksia uusista toiminnoista, jotka pitää lisätä tuotteen työlistalle priorisoitavaksi.
  • Scrum-mestarin on arvioitava katselmointiin osallistuvien henkilöiden määrä ja varmistettava että katselmointi voidaan viedä läpi asiaankuuluvalla tavalla.
  • Katselmoinnin lopuksi Scrum-mestari ilmoittaa missä jamilloin pidetään seuraava sprintin katselmointi.

Sprintin jälkitarkastelu

Sprintin jälkitarkastelu kestää kolme tuntia.

  • Jälkitarkasteluun osallistuu vain tiimi, Scrum-mestari ja tuotteen omistaja niin halutessaan.
  • Kokous alkaa siten, että jokainen osallistuja vastaa seuraaviin kysymyksiin
  • Mikä edellisessä sprintissä meni hyvin
  • Mitä voitaisiin tehdä paremmin seuraavassa sprintissä
  • Scrum-mestari kirjaa ylös tiimiläisten havainnot ja tekee niistä koosteen
  • Tiimi valitsee missä järjestyksessä se haluaa keskustella mahdollisista parannusehdotuksista.
  • Scrum-mestarin tehtävänä ei ole vastata kaikkiin mahdollisiin kysymyksiin vaan auttaa tiimiä löytämään parempia tapoja hyödyntää Scrumia
  • Selkeät muutosehdotukset on sijoitettava seuraavan sprintin työlistalle korkean prioriteetin tehtävinä. Jälkitarkastelut, joista ei aiheudu muutoksia, ovat tylsiä ja turhia.

Artikkeli pohjautuu Sinisen Meteoriitin menetelmäarkkitehti Sami Poimalan tuottamiin koulutusmateriaaleihin ja artikkeleihin. Artikkelin on julkaistuun muotoon viimeistellyt ja täydentänyt Perttu Tolvanen.

Sami Poimala on kokenut menetelmäarkkitehti ja ohjelmistokehittäjä. Sami on työskennellyt vuosia ketterän kehittämisen parissa Sinisessä Meteoriitissa ja myös kouluttanut paljon esimerkiksi Sinisen Meteoriitin henkilökuntaa ketterän kehittämisen saloihin. Sami Poimala työskentelee nykyisin omassa yrityksessään Offbeat Solutionsissa, jossa hän konsultoi asiakkaita ketterien ohjelmistoprojektien toteutuksessa, erityisesti Microsoft-teknologioiden maailmassa.

Sininen Meteoriitti on SharePoint-toteutuksiin erikoistunut ohjelmistoyritys, jonka projekteissa on hyödynnetty ketteriä menetelmiä jo vuosia. Artikkelisarja ketteristä menetelmistä jatkuu seuraavaksi aiheella “Miten ostan ketteriä it-projekteja?”.