Blogi

Definition of Done – On tärkeää määritellä konkreettisesti, mitä valmis tarkoittaa

Tämä on kolmas osa blogisarjaa, jossa pureudutaan aiheeseen ”Aikataulutus ketterässä projektissa: milloin tämä on valmis?” Jokainen osa esittelee yhden edellytyksen ketterälle aikataulutukselle. Aiemmissa osissa on käsitelty erilaisista näkökulmista, miten IT-projektissa voidaan keskittyä tekemään olennaista (”build the right thing”) ja miten nämä oikeat asiat ovat tunnistettavissa. Nyt keskustellaan siitä, miten päätetyt asiat viedään maaliin laadukkaasti.

Valmiuden määritelmä (Definition of Done) nousee monissa ketterissä menetelmissä avainasemaan — ja syystäkin. Scrumissa viitataan yleensä siihen, että tehtävälle pitää kirjata selkeät valmiuskriteerit, jotka voivat pitää sisällään toteutuksen lisäksi esimerkiksi dokumentointia tai laatumääreitä.

Monessa muussakin asiassa kannattaa kiinnittää huomiota valmiuden määrittelyyn, esimerkiksi:

  • Definition of Ready viittaa toteutusta kuvaavan tarinan kypsyyskriteereitä — mitä asioita pitää yksikäsitteisesti määritellä, ennen kuin tehtävä otetaan työn alle.
  • Testauksessa määritellään erilaisia kriteereitä, joiden täyttyminen validoidaan. Testitapaukset voivat olla hyvinkin erilaisia ja testata eri asioita, mutta niiden tulee pääsääntöisesti olla hyvin määriteltyjä ja yksiselitteisiä.
  • SMART-kriteerit esiintyvät useammassa eri muodossa tavoitteiden kuvaamistapana, korostaen tarvetta tehdä tehtävästä spesifinen, mitattava, henkilölle osoitettava, realistinen ja aikaan sidottu.

Kunkin tuotoksen valmius on hyvä määritellä konkreettisesti ja mitattavalla tavalla, panostaen selkeyteen, konkretiaan, kokonaisuuden hahmottamiseen ja tulkinnanvaran minimoimiseen. Tämä myös omalla tavallaan pakottaa pilkkomaan tehtäväkokonaisuudet pienemmiksi, mikä helpottaa seurantaa.

Jos tehtävät ovat tarkkuustasolla ”julkaise koulutusmateriaalit”, on vaikea sanoa, milloin tehtävä on tehty. Herää kysymyksiä: mitä julkaistaan, kenelle julkaistaan, mitä tarkoitusta varten, missä muodossa, minne, milloin ja kaikki materiaalit yhdessä vai erikseen? Epäselvyys hidastaa etenemistä ja huonossa tapauksessa palataan useampaan kertaan asiaan, miettien että olikohan tämä nyt tehty. Pahimmillaan tehtävä on niin yleistasoinen, että sitä ei voida sanoa kokonaisuudessaan suoritetuksi ennen kuin koko projekti suljetaan.

Määrittelemällä valmiudelle kriteereitä voidaan sanoa suuremmalla varmuudella, missä projektissa mennään. Tällöin vanhat tehtävät eivät tule kummittelemaan puutteellisen toteutuksen tai laatupoikkeamien kautta, eikä asioita jätetä roikkumaan ja viemään kapasiteettia turhaan. Myös heikkoudet ja puutteet on helpompi paikallistaa, kun asiat käsitellään systemaattisesti.

Näin menettelemällä vältetään kommunikaatio-ongelmia ja väärinymmärryksiä. Kun systemaattisesti kirjataan, mitä ollaan tekemässä, jää harmaita alueita vähemmän. Tällöin vastaus kysymykseen ”Milloin tämä on valmis?” on ”Kun tehtävälista on tyhjä”.

Blogikirjoitusten loppuyhteenvetona voitaneen todeta: Jos on kyetty yhdessä määrittelemään, mikä on arvokasta ja toteuttamisen arvoista, tehty sen pohjalta MVP-toteutus, jossa on kaikkien osa-alueiden valmiuden kriteerit määritelty, voidaan tehdä oletus, että IT-projektilla on keskimääräistä parempi mahdollisuus onnistua.

Asiantuntijakirjoittajana Project-IT:n konsultti Miikka Lötjönen

Jaa artikkeli:

Lataa IT-ostamisen ABC -opas!

Asiantuntijoiden kanssa yhteistyössä kirjoitettu IT-ostamisen ABC pitää sisällään paljon käytännönläheisiä ohjeita IT-ostamiseen.

  • Kenttä on validointitarkoituksiin ja tulee jättää koskemattomaksi.