1 Tämän dokumentin tuottamisen vaiheet

2 Johdanto

3 Roolit ja tiimin autonomisuus

4 Kertomukset

5 Täsmälliset aikarajat

6 Käytännön irtoseikkoja

7 Demo

8 Linkkejä

9 Itsearvionti

1  Tämän dokumentin tuottamisen vaiheet

Päivä 1 (tiistai):

• Valitsen aiheen ja kerään tusinan verran aiheeseen liittyvää ensivaikutelman pohjalta mielenkiintoiselta vaikuttavaa materiaalia – myöhemmin tarkasteltavaksi. Luon arvion siitä milloin työ olisi valmis (lauantaina), mutta en suunnittele ennalta miten sen käytännössä toteuttaisin.

Päivä 2 (keskiviikko, torstai, perjantai):

• PDF-muotoisen kirjan (ks. linkit) lukeminen kolmessa osassa (osa per päivä), poimien kirjasta olennaisempia seikkoja talteen word-dokumenttiin (käytetään pelkästään muistiinpalauttamisessa).

Päivä 3 (lauantai):

• Ilman luettuun kirjaan tai muistiinpanoihin palaamista kirjaan kolmelle seinään sinitarralla kiinnitetylle A4-kokoiselle paperille ylös kaikki mitä tulee mieleeni luetusta kirjasta, seisten.
• Kirjoitan tietokoneen näppäimistöllä, edelleen seisten, ilman keskeytyksiä ja yhtenäisen kirjoituksen muotoon kaikki mitä kirjoitin paperille ylös ja kaiken muun, mitä kirjoittamisen keston aikana aiheesta mieleeni tulee.
• Luen läpi muistiinpanoni ja aluksi kerätyt lähdemateriaalit, josko jotain olennaista unohtui, mutta en tee tekstiin korjauksia (opettaa tekemään ensin kerran paremmin, kuten Scrumissakin).
• Lisään tekstiin yhden kuvan ja linkit muutamalle nettisivulle, sekä teen lyhyen itsearvoinnin.

Päivä 4 (sunnuntai):

• Asetan kirjoituksen esille ja arvioitavaksi (sisältää konversion Word-dokumentista HTML-tiedostoksi).

 

2  Johdanto

Scrum on eräs ketteristä ohjelmistotuotannon metodeista. Toisin kuin sellaisissa metodeissa, joissa käydään kertaalleen tai esim. spiraalimaisesti samojen tuotannon vaiheiden (määrittely, suunnittelu, toteutus, testaus, jne.) kautta, iteraatio iteraatiolta (yksi kokonainen kierros) kulkien, Scrumin ketteryys tulee esiin erityisesti siinä, kuinka tuotannon suuntaa voi vaihtaa, ilman että on tullut tehtyä kovin paljon ylimääräistä työtä ja siinä kuinka usein asiakkaalle on jotain uutta ja valmista demottavaa. Tämä tulee sitä selvemmin esiin, mitä laajemmasta tuotannosta on kyse. Scrumissa iteraatiokierrosta vastaa omalla tavallaan termi sprint. Sprintti on aina kestoltaan n. 2 – 4 viikkoa, kulloisenkin seuraavan sprintin keston ja tarkan päättymispäivän määrittyessä jokaista sprinttiä ennen läpikäytävässä sprint planning -tapaamisessa. Ketteräksi ohjelmistuotannoksi Scrumin tekee sekin, että mahdolliset ongelmat ovat yleensä tiedostettavissa hyvissä ajoin ja täten suunnanvaihdon tarve on nähtävissä aiemmin.

 

 

3  Roolit ja tiimin autonomisuus

Scrumissa ei ole monia roolinimikkeitä, niitä ollen vain product master ja scrum master, sekä näiden lisäksi yksittäiset tiimiläiset. Tiimiläisten työkuva ei määräydy niinkään sen mukaan miten he ovat esim. kouluttautuneet, vaan heidän kulloisenkin kompetenssinsa, osaamisensa mukaan eli käytännössä kaikki tekevät sitä mitä parhaiten osaavat tai missä parhaiten tulisivat kehittymään. Tiimillä on vahva kollektiivinen itsemääräämisoikeus, mikä näkyy esim. siinä kuinka he ja vain he ovat oikeutettuja esittämään arvioita siitä kuinka kauan aikaa jokin suoritus tulee kestämään.

On tärkeää, että tiimillä on työrauha ja heidät on tuotu toistensa läheisyyteen työskentelemään eli eri työhuoneissa työskentely ei yksinkertaisesti käy. Läheisyyden tunnetta rikkovat myös sermit, sillä yhteyden pitää toimia sekä näkö-, että kuuloaistin osalta. Kun tiimi saa itse ohjata itseään, eikä kukaan pomota sprintin aikana, tiimi saa luotua toimintaansa vahvemman flown virtauksen.

Scrum master on henkilö, jonka tehtävänä on tehdä tiimin kulloinkin kulkemat reitit kepeämmäksi kulkea esim. järjestämällä heidän käyttöönsä tarpeellisia resursseja tai lisätietoa. Hän ei itse osallistu varsinaiseen ohjelmistotuotantoon, eikä hänellä ole määräysvaltaa tiimin toimintaan, mutta hänen tehtävänään on mm. tarkkailla, että tiimin suorituskyky pysyy riittävän tasaisena ja edistyminen on jouhevaa.

Product master on henkilö, joka voi olla esim. henkilö ohjelmiston tuottavan yrityksen markkinointiosastolta. Hän tarkastelee tuotetta businessnäkökulmasta ja toimii lähimpänä asiakkaita, heidän kanssaan kommunikoiden ja heitä tuotannon edistymisestä informoiden, sekä asiakkaan kanssa tehdyssä sopimuksessa pysymisestä aktiivisesti huolehtien.

 

4  Kertomukset

Kertomukset, joita kukin tiimiläinen osaltaan työstää, eivät välttämättä ole selkeästi rajattuja komponentteja tai moduuleja, vaan kokonaisuuksia, jotka voivat pitää sisällään käyttöliittymän toteuttamisen, toiminnallisuuden sille, sekä yhteyden tietokantaan asti. Näitä kertomuksia sijoitetaan kahteen eri backlogiin, joista kattavampi on product backlog ja suppeampi sprint-kohtainen sprint backlog. Ensin mainittukaan ei pysy koko tuotannon ajan muuttumattomana, vaan tarpeen mukaan se saa lisää kertomuksia, siitä poistuu kertomuksia, siinä olevat kertomukset yhdistyvät ja siinä olevat kertomuksia pilkotaan pienemmiksi. Tämä tapahtuu sprint planning -tapaamisissa, ei sprinttien aikana. Alkavaan sprinttiin valittavat kertomukset valitsee tiimi.

Tiimi asettaa kullekin kertomukselle story pointit eli arvot, jotka kuvaavat sitä, kuinka monta normaalia henkilötyöpäivää, tarkennettuna tarkennusarvolla (en. focus factor), kyseinen kertomus vienee. Lasketaan kaavasta:

storypoint = yksi täysi henkilötyöpäivä * tarkennusarvo

Tarkannusarvo on luku välillä ]0.00, 1.00] ja sen avulla on tarkoitus ottaa huomioon mahdollisten ongelmien ilmaantuminen asettamalla sille arvoksi jotain ykköstä pienempää (esim. 0,70). Tarkennusarvoon vaikuttaa myös se, jos tiimiin tulee uusi jäsen, sillä häntä täytyy alussa opastaa pääsemään kyseiseen tuotantoon sisään. Kun arviot on tehty huolella, ei koskaan ajauduta siihen, että työntekijät joutuvat jäämään ylitöihin ja täten nipsaisemaan aikaa omasta vapaa-ajastaan. Tämäkin osaltaan saa tiimiläisen miettimään entistä harkitummin tiiminsä vauhtikyvykkyyttä (en. velocity) eli sitä kuinka monta kertomusta se luulee suorittavansa alkavan sprintin aikana. Liian löysää aikataulua ei kuitenkaan ole fiksua pitää, sillä siten saa vain asiakkaat karkotettua. Tämän tiedostaminen on tärkeää.

Tiimi on myös se, joka tekee ja tarvittaessa muuttaa sprintin aikanakin kertomuksien kestojen (story points) arvioita. Kestojen arvioita ei sprint planning -tapaamisessa analysoida loputtomiin, vaan ymmärretään tehdyn arvion todellakin olevan vain arvio – mielellään tietysti hyvä sellainen. Arvioita voi perustaa aiempiin sprintteihin tai tuntemuksiin tiimin kompetensseistä, mutta uuden tiimin ja uuden tuotannon osalta voidaan joskus olla siinäkin tilanteessa, että on vain tehtävä karkea arvaus ja korjattava tätä arvioita sitten myöhemmin. Kertomukset vaativat usein usean henkilön työpanoksen, mikä on otettava keston arvioinnissa huomioon.

Kertomuksille on asetettu myös tärkeysjärjestys, joka ilmaistaan numeroiden avulla. Tämän tärkeysjärjestyksen määrittää product master. Numeroiden absoluuttiset arvot ei ole niinkään merkityksellisiä, mutta kertomuksien tärkeysarvotuksien välisillä suhteilla on. Jos product owner korottaa jonkin alemman tärkeysasteen kertomuksen tärkeimmäksi, tiimi on pakotettu ottamaan se seuraavaan sprinttiin mukaan. Vaihtoehtoisesti kertomus voidaan rajata toisin, osa siitä voidaan sulauttaa toiseen kertomukseen; neuvottelukysymyksiä, mutta tehtävä sprintin suunnittelun aikana.

Sprint planning on myös se hetki, jolloin tehdään kaikilla osallisille (product master, scrum master ja tiimiläiset) selväksi mitä mikin kertomus tarkoittaa ja mihin sille pyritään, jottei käy niin, että tapaamisen jälkeen jollain on eriävä käsitys jostain kertomuksesta, mutta hän ei sitä itse tiedä. On myös tärkeää määrittää missä muodossa jokin kertomus voidaan katsoa valmiiksi, jottei se jää vajaaksi tai sitä tulla ylityöstetyksi.

 

5  Täsmälliset aikarajat

Vaikka sprint planning on koko päivän kestävä strukturoitu ajatusriihi, sitäkään ei venytetä kestoltaan, vaan product master voi keskeyttää sen ennalta annetun aikataulun mukaisesti, jolloin sprintti alkaa seuraavana päivänä tai sitten sovitaan seuraavaksi päiväksi uusi tapaaminen ja vasta sen jälkeen sprintti alkaa.

Sprinttiin kuuluu jokaiselle työpäivällä päivittäinen tapaaminen, daily scrum, jonka ei tarvitse olla ihan ensimmäinen asia aamulla, mutta mielellään melko pian sen jälkeen kun kaikki ovat saapuneet töihin. Tässä päivittäisessä tapaamisessa kukin tiimiläinen kertoo, mitä on viimeeksi saanut aikaan ja mitä aikoo tänään tehdä. Ulkopuolisetkin (asiakkaiden edustajat? muu talon väki?) saavat seurata näitä tapaamisia, jos kokevan heille olevan tarpeellista olla tietoisia missä ns. mennään, mutta he eivät saa osallistua keskusteluun. Nämä tapaamiset tavataan pitää seisten, jotteivat ne venyisi pitkiksi. Niille on määritelty tarkka ajankohta ja kesto, joista ei jousteta.

Scrumille on ominaista se, että määritetyistä ajoista ei  lipsuta. Käytännössä tämä tarkoittaa sitä, että jos sprintti on lopuillaan ja pitäisi olla jotain näytettävää demoa asiakkaalle, niin demon esittelyaikaa ei muuteta, vaan tiimin kollektiivinen ego ottaa mahdollisesti osakseen yhden kolhaisun, kestää sen ja suoriutuu seuraavalla sprintillä paremmin. Tämä opettaa tiimiä tekemään parempia arvioita yksittäisten kertomuksien kestoille eli ajoittamaan oikein valmiin ja demottavan toiminnon valmistumisen. Sprinttien pituus on sillä tapaa joustava, että kukin sprintti voi olla oman mittaisensa, kunhan se pysyttelee tietyissä rajoissa.

Sprinttien välillä on hyödyllistä pitää pari välipäivää, sekä muistelusessio jossain rauhallisessa paikassa, jossa kerätään ja vertaillaan kokemuksia siitä mitä olisi voitu tehdä toisin, missä onnistuttiin ja missä meni pahasti pieleen.

 

6  Käytännön irtoseikkoja

Yksittäisen kertomuksen kuvauksen ei pitäisi keskittyä teknillisiin seikkoihin, vaan product backlog -taulukon sarakkeessa (joita voi itsekin keksiä ja kokeilla, mitkä parhaiten toimivat) ”nimike”, on vain jokin lyhyt liiketoimintanäkökulmainen kuvaus. Sarakkeessa ”huomioita” voi sitten olla esim. teksti: ”tämän voisi toteuttaa siten että..” Hyödylliseksi voi osoittautua myös kirjata johonkin sarakkeeseen kuinka kertomusta voi demota. Joitakin kertomuksia ei voi demota graafisesti, mutta raporttien ja tiiviiden sanallisten selitysten avulla kylläkin.

Product backlog voi sijaita vaikka Excel-tiedostossa, mutta sprint backlogin osalta voi todennäköisemmin osoittautua kätevämmäksi sijoittaa se jollakin seinustalle, jossa yksittäiset kertomukset lapuille kirjoitettuna ovat helposti liikuteltavissa lähtöruudustaan sarakkeisiin ”checked out” ja ”ready”.

Product master ei ole majoittunut samaan tilaan tiimin kanssa, mutta hänen täytyy kuitenkin olla jossain lähettyvillä. Tiimi informoi häntä mm. vauhtiarvioissa tapahtuvista muutoksista, sekä voi tarvittaessa käydä esittämässä hänelle kysymyksiä ja huolensa.

 

7  Demo

Kun asiakkaalle esitetään demoja, on tärkeämpää keskittyä ”silmäkarkin” sijaan liiketoiminnallisiin ominaisuuksiin, sekä pitää demoesittely temmoltaan ja sanalliselta selvitykseltään tiiviinä ja mielenkiintoisena. Riippuu tietenkin asiakkaasta, kuinka läheinen suhde toimittavalla yrityksellä siihen/häneen on ja kuinka kiinnostunut tämä on esim. teknisistä nyansseista. Valmis kokeiltava demo on myös siitä kätevä, että asiakas voi aistia toiminnallisuuden suoraan, eikä hänen tarvitse apprikoida niin paljon mielessään.

Scrum-metodin hyviin puoliin voi lukea senkin, että asiakkaan saadessa nopeammalla tahdilla nähtävilleen jotain valmista, hänen on mahdollista aloittaa mahdolliset markkinointi- ja kampanjavalmistelut, johon ohjelmistotuote osaltaan ehkä liittyy, paljon aikaisemmin ja erityisesti vähemmällä riskillä; asiakkaan on helpompi hahmottaa ennalta, josko sittenkin olisi tarpeen muuttaa tuotetta jollain tapaa. Ketteryys ei täten ole rajoitu vain ohjelmistoa tuottavan osapuolen toimintaan.

8  Linkkejä

Kuvallinen esimerkki Product Backlogista:
http://www.mountaingoatsoftware.com/product-backlog

Kuvallinen esimerkki Sprint Backlogista:
http://www.agile-software-development.com/2009/03/power-of-whiteboard.html

Excel-muotoisia esimerkkejä backlogeista:
http://www.odd-e.com/home_page/html_files/bl_example.html

Kustomoitu Backlog-työkalu:
http://devblog.petrellyn.com/?tag=sprint-backlog-item

Kniberg, Henrikin kirja: Scrum and XP from the Trenches – How we do Scrum (PDF)
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

9  Itsearvionti

Asioita, jotka olisin voinut tehdä paremmin

Olisi pitänyt mainita ainakin:

• optimaalinen tiimin koostumus on alle kymmenen hengen tiimi ja minimissään kolme henkeä
• release backlog
• samaa tuotetta voi työstää useampikin tiimi
• ensimmäisestä tapaamisesta asiakkaan kanssa ja asiakkaan halujen/tarpeiden kartoittamisesta

Asioita, jotka tein hyvin

• muistin olennaisimpia asioita ja yksityiskohtia runsaasti, sekä tulin ohessa kokeilleeksi opiskelutekniikkaa, jota en koskaan aiemmin ollut kokeillut – ja se toimi.