Työn etenemisnopeuden tunteminen on ollut tärkeää jo vuosituhansia; maataloustyöt on pitänyt pystyä tekemään ajallaan tai jää sato saamatta. Myöhemmin aikatauluvaatimukset ovat laajentuneet lähes kaikkialle: kuljetuksiin, rakentamiseen, tuotteiden valmistamiseen, viihde-esityksiin, opetukseen, ja jopa ruokailuun. Yhä tarkemmin halutaan tietää mitä tapahtuu missäkin ajassa. Taustatalla yleensä on halu tehostaa asioita, poistaa turhia työvaiheita ja joutokäyntiä, varmistaa että energia laitetaan oikeisiin asioihin ja että asiat tehdään oikein. Tässä kirjoituksessa tiimien paremmuutta tarkastellaan nimenomaan tehokkuuden ja tehostamisen näkökulmasta. Toiminnan optimointi ei ole mahdollista ilman luotettavaa mittaamista.

Minne päästään perinteisillä menetelmillä?

Perinteinen tapa arvioida mitata etenemistä on verrata kehittämisen tilaa suunniteltuun: ollaanko saatu tavoitteen mukaiset tulokset suunnitellussa aikataulussa ja suunnitellulla budjetilla. Tämä ns. rautakolmio (aika-raha-tavoitteet) on perinteinen projektin arviointi- ja mittausmalli, joka on peritty ohjelmistotuotantoon perinteisemmiltä teollisuuden aloilta. Ohjelmistotuotannossa, toisin kuin perinteisemmissä toimialoissa, kuten esim. laivanrakennuksessa, kattavan vaatimusmäärityksen tekeminen ja täydellinen suunnittelu ei välttämättä ole aina mahdollista. Tämä tulee hyvin näkyviin Standish Groupin Chaos raportissa (2015), jossa suurten suunnitelmaohjattujen (vesiputous) projektien onnistumistodennäköisyydeksi on arvioitu 3%, kun pienempien onnistumistodennäköisyys on 44% (Standish Group, 2015). Toki, toisin kuin laivanrakennuksessa, ohjelmistoprojektissa kaikkea ei tarvitse tehdä kerralla valmiiksi: asioita voi pilkkoa ja ottaa käyttöön pienemmissä erissä.

Perinteinen rautakolmioon perustuva etenemisen seuranta sopii kiinteähintaisiin hankintoihin, joissa pystytään tekemään riittävän kattava vaatimusmääritys ja toteuttamissuunnitelma ennen projektin aloittamista. Läheskään aina näin ei ole. Ei välttämättä tiedetä tarkalleen mitkä kaikki ominaisuudet kehitettävään sovellukseen tarvitaan, mikä niiden tärkeysjärjestys on ja nouseeko kehittämisen aikana esiin uusia tarpeita. Lisäksi, vaikka vaatimukset tunnettaisiinkin tarkalleen, on hyvin haastavaa arvioida kuinka paljon aikaa niiden toteuttamiseen toimivaksi ohjelmistoksi menee: eri tekniikat mahdollistavat erilaisia ratkaisuja, jotkin asiat ovat tekijöille tuttuja ja osa vieraampia ja ohjelmoinnissa tiimikohtainen mittaaminen huomattavasti hankalampaa kuin esim. ojankaivuussa: sen minkä yksi tekee viikossa voi toinen tehdä päivässä tai nopeammin.

Haasteet ketterässä

Ketterä kehittäminen on yksi ratkaisu vaatimustenhallinnan haasteisiin, mutta sekään ei automaattisesti ratkaise etenemisen mittaamisongelmaa. Toki ketterässä kehittämisessäkin mitataan. Hyvin yleisesti käytössä ovat tarinapisteet (story points), joiden avulla tiimi voi esim. suunnittelupokerin (planning poker) avulla arvioida eri ominaisuuksien (käytännössä käyttäjätarinoiden) toteuttamisen työmäärää. Kun kehitysjaksolla (sprintissä) valmistuneiden käyttäjätarinoiden tarinapisteet lasketaan yhteen, voidaan arvioida tiimin nopeutta (tarinapistettä/sprintti). Tämä on jonkinlainen mittari sekä tiimin sisäiseen työn seurantaan, että uusien (pisteytettyjen) ominaisuuksien valmistumisen arviointiin. Yleensä tämän mittarin arviointitarkkuus myös paranee kehittämistyön edetessä.

Ongelmaksi tarinapisteiden käytössä nousee niiden subjektiivisuus: ne ovat täysin tiimikohtaisia. Jokainen tiimi määrittelee tarinapisteensä itse, ja tarinapisteestä muodostuu tiimin sisäinen vakio, jolla ei ole mitään tarkkaa vertailukohtaa tiimin ulkopuolella. Jos yhden tiimin nopeus on 35 tarinapistettä/sprintti ja toisen 45, ei mistään voida tietää kumpi tiimeistä on tehokkaampi, tai onko kumpikaan tiimi tehokas ylipäätään. Ketterässä kehittämisessä ei myöskään voida palata rautakolmiomalliin, koska kehittämiselle ei ole lukkoon lyötyjä tavoitteita, aikataulua eikä välttämättä edes budjettia.

Jotta ketterää kehittämistä voidaan tehostaa ja optimoida, pitää sitä voida mitata objektiivisesti, tulosten pitää olla vertailukelpoisia ja mittaajasta riippumattomia. Tarinapisteet muodostetaan aika pitkälti tiimin mututuntuman perusteella, keskustelemalla ja vertailemalla jo tehtyihin ratkaisuihin. Yksi vaihtoehto olisi laatia ”vaihtokursseja”: tiimin A tarinapisteet ovat 1,2 * tiimin B tarinapisteet ja 0,78* tiimin C tarinapisteet. Käytännössä tällainen ”vaihtokurssipörssi” olisi toivottoman vaikea käyttää ja hirvittävän työläs ylläpitää: jokaisen tiimin pitäisi arvioida omien käyttäjätarinoidensa lisäksi myös muiden tiimien käyttäjätarinoita, jotta kertoimet saataisiin laskettua ja ylläpidettyä.

Standardeihin perustuva mittaaminen ratkaisee ongelman

Paljon yksinkertaisempi malli on sopia yhteiset pelisäännöt miten toiminnallisuuksia pisteytetään. Tarvitaan yksinkertainen, standardoitu malli, jolla kaikissa projekteissa toiminnallisuuksille lasketut pisteet ovat keskenään vertailukelpoisia, riippumatta tiimistä, asiakkaasta tai kehittävästä organisaatiosta. Yhteismitallisten pisteiden avulla voidaan yhä seurata tiimin nopeutta, mutta voidaan myös verrata tiimejä toisiinsa, sekä myös projekteja toisiinsa. Luotettava mittaus mahdollistaa toiminnan jatkuvan kehittämisen, kehittämistoimien vaikutuksen arvioimisen, sekä myös oikeasti hyvin suoriutuneiden palkitsemisen ja lisäosaamista tarvitsevien kouluttamisen.

Miten tämä sitten pystyttäisiin toteuttamaan? Yksinkertaisinta on ottaa käyttöön jokin jo olemassa oleva toimintopistemenetelmä, ja joko kouluttaa kehitystiimin jäseniä sen käyttäjiksi, tai nimetä erillinen scope manager, joka avustaa tuoteomistajaa edistymisen mittaamisessa. Kehitystiimi on yleensä osa ulkoista kehittäjäorganisaatiota, eikä tilaajan kannalta välttämättä ole optimaalista jättää etenemisen mittaamista täysin kehitystiimin vastuulle. Scope manager on parhaimmillaan ulkopuolinen puolueeton toimija, esim. asiakkaan palkkaama ulkoinen konsultti. Toki vertailukelpoinen data on myös kehittäjäorganisaatioiden etu pitkällä tähtäimellä, mutta ketterässä kehittämisessä tiimien tehokas työskentely, projektin edistyminen ja kustannusten kurissa pitäminen on ensisijaisesti asiakkaan etu.

Erilaisia toimintopistestandardeja on useita, ISO sertifioituja ovat:

  *   FiSMA (ISO/IEC 29881)
  *   COSMIC (ISO/IEC 19761)
  *   IFPUG (ISO/IEC 20926)
  *   Mk II (ISO/IEC 20968) ja
  *   NESMA (ISO/IEC 24570)

Näistä, niiden soveltamisesta ja kehittämisen mittaamisesta laajemminkin kannattaa keskustella FiSMA ry:n kanssa, jonka ydintavoitteena on toimia puolueettomana tahona parantamassa ohjelmistokehityksen mittaamisen käytäntöjä.

Muita FiSMAn Blogeja