Valmiin työn määritelmä: mikä se on ja miten sitä käytetään

Tehokkaan valmiin työn määritelmän keskeiset ominaisuudet ovat seuraavat:

• Avoimuus: Kaikki tiimin jäsenet ja keskeiset sidosryhmät voivat nähdä sen, lukea sen ja käyttää sitä viitteenä milloin tahansa.
• Mitattavuus: Jokainen kriteeri on kaksijakoinen. Työ joko täyttää sen tai ei täytä sitä, mutta määrällisten kriteerien raja-arvot on valittava harkiten. 80 prosentin koodikattavuustavoite on valvonnan kannalta kaksijakoinen, mutta 80 prosentin valitseminen 70 tai 90 prosentin sijaan on harkinnanvarainen päätös, joka kannattaa tehdä tietoisesti.
• Yleisesti ymmärretty: Jokaisen Scrum-tiimin jäsenen on pystyttävä tulkitsemaan jokainen kohta samalla tavalla.
• Johdonmukaisesti sovellettu: Samaa tarkistuslistaa on sovellettava jokaiseen toimitettavaan kokonaisuuteen ja tuotejonokohteeseen. 
• Saavutettavissa sprintin aikana: Kriteerien tulee olla riittävän realistisia, jotta tiimi voi täyttää ne yhden sprintin tai iteraation aikana.

Ohjelmistokehitysprojekteissa kehittäjät yleensä omistavat valmiin työn määritelmän, koska he ovat vastuussa sen noudattamisesta. Tuoteomistajan ja Scrum Masterin tulisi kuitenkin osallistua sen laatimiseen.

Jos organisaatiollasi on omat valmiin työn määritelmää koskevat standardinsa, jokaisen Scrum-tiimin on noudatettava niitä vähimmäistasona. Tiimit voivat aina lisätä niiden päälle tiukempia kriteerejä, mutta ne eivät voi alittaa organisaation asettamaa vähimmäistasoa.

Miksi valmiin työn määritelmällä on merkitystä?

Selkeä valmiin työn määritelmä on tärkeä, koska se estää osittain tehdyn työn päätymisen läpi huomaamatta ja tarjoaa yhteisen laatustandardin.

Seuraavassa on lisää syitä siihen, miksi yhteisellä valmiin työn määritelmällä on merkitystä:

• Toimii sisäänrakennettuna laatukynnyksenä: Jokaisen kohteen on täytettävä sama vaatimustaso ennen kuin se voidaan todeta valmiiksi. Tämä estää keskeneräistä työtä ujuttautumasta tuoteinkrementtiin ja kasaantumasta tekniseksi velaksi.
• Poistaa epäselvyyksiä: Kun tiimillä on yksi yhteinen määritelmä, ette joudu tilanteisiin, joissa ristiriitaiset määritelmät vaikuttavat työn nopeuteen tai laatuun. Yhteinen valmiin työn määritelmä tarkoittaa vähemmän ristiriitoja, vähemmän yllätyksiä ja sujuvampia esittelyjä.
• Parantaa ennustamista: Kun ”valmis” tarkoittaa samaa jokaisessa sprintissä, voit ennustaa työskentelynopeutta luottavaisin mielin ja suunnitella julkaisuja ilman, että arvioihin tarvitsee lisätä ylimääräistä aikaa uudelleentyön varalta.
• Rakentaa sidosryhmien luottamusta: Kun tuoteomistajat, johto ja ulkoiset sidosryhmät näkevät tiimisi noudattavan selkeää laatustandardia, he luottavat tuotoksiisi. 
• Ehkäisee integroinnin kaaosta: Jos työskentelet tavalla, joka edellyttää tiimiltä työnsä integroimista yhteiseen inkrementtiin, yhteinen ymmärrys valmiin työn määritelmästä muodostaa perustan johdonmukaisille ja julkaistavissa oleville inkrementeille. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

Kuinka luoda valmiin työn määritelmä?

Seuraavassa ovat valmiin työn määritelmän luomisprosessin keskeiset vaiheet.

1. Tarkasta nykyinen työnkulku: Kuvaa jokainen vaihe, jonka työsi käy jo läpi ennen tuotantoon päätymistä. Keskustele kehittäjien, testaajien, suunnittelijoiden ja kaikkien muiden työhön osallistuvien kanssa. Löydät epävirallisia laadunvarmistusvaiheita, jotka tulisi virallistaa.
2. Tunnista ehdottomat laatukriteerit: Päätä, mitkä toimet on suoritettava jokaisen työtehtävän yhteydessä. Näitä ovat yleensä koodin tarkistus, automaattinen testaus, dokumentaation päivitykset ja tietoturvatarkistukset. Ole rehellinen sen suhteen, mitä tällä hetkellä jätätte väliin.
3. Laadi tarkistuslista yhteistyössä: Kokoa koko tiimi yhteen ja käykää asia läpi taululla tai jaetussa asiakirjassa, jossa kaikki voivat lisätä, haastaa ja tarkentaa kohtia reaaliajassa. Yhteisymmärryksessä hyväksytty valmiin työn määritelmä kestää paineen alla paljon paremmin kuin sellainen, joka on hyväksytty vastalauseista huolimatta äänestämällä.
4. Varmista vastaavuus organisaation standardien kanssa: Vertaa luonnostasi kaikkiin organisaationlaajuisiin laatukäytäntöihin, sääntelyvaatimuksiin tai alan standardeihin, jotka tuotteenne on täytettävä. Jos organisaatiollasi on jo valmiin työn perusmääritelmä, aloita siitä ja kehitä sitä eteenpäin.
5. Tee se näkyväksi: Esitä valmiin työn määritelmä paikassa, jossa tiimisi työskentelee päivittäin. Se voi tarkoittaa seinällä olevaa julistetta, Slackiin kiinnitettyä viestiä tai projektinhallintatyökalussa olevaa paneelia.
6. Sitoudu sen noudattamiseen: Määräaikojen lähestyessä ohitettava valmiin työn määritelmä on pahempi kuin se, ettei määritelmää olisi lainkaan, koska se luo vääränlaisen laadun tunteen. 

Valmiin työn määritelmän esimerkkejä

Tässä on muutamia esimerkkejä eri projektityyppien valmiin työn määritelmistä:

Ohjelmistokehitysprojektien valmiin työn määritelmä

Ohjelmistoprojekteihin liittyy monenlaisia laaturiskejä: virheitä, tietoturva-aukkoja, suorituskyvyn heikkenemistä ja integraatio-ongelmia. Ohjelmistotiimin valmiin työn määritelmän on katettava koko matka koodista julkaistavaan tilaan.

Se voisi näyttää tältä:

• Kaikki koodi on kirjoitettu ja vähintään yksi toinen kehittäjä on tarkistanut sen
• Yksikkötestit läpäisty sovitun kattavuuskynnyksen mukaisesti
• Integraatiotestit läpäisty CI/CD-putkessa
• Yhtään kriittisen tai vakavan tason avointa virhettä ei ole
• Tekninen dokumentaatio päivitetty muutosten mukaisesti
• Koodi yhdistetty päähaaraan
• Tuoteomistaja on tarkistanut ja hyväksynyt työn
• Suorituskyvyn vertailuarvot täyttävät sovitut kynnysarvot

Markkinointiprojektien valmiin työn määritelmä 

Markkinointityöhön liittyy usein vaatimustenmukaisuuteen, brändiin ja mittaamiseen liittyviä näkökulmia, jotka poikkeavat ohjelmistotyöstä. 

Markkinointiprojektin valmiin työn määritelmä voisi näyttää tältä:

• Lakitiimi on tarkistanut ja hyväksynyt sisällön
• Hakukoneoptimoinnin tarkistuslista on käyty läpi, mukaan lukien metakuvaukset, vaihtoehtoiset tekstit ja sisäiset linkit
• Kaikki aineistot on ladattu sisällönhallintajärjestelmään ja muotoiltu oikein
• Analytiikan seuranta on määritetty ja varmennettu testiympäristössä
• Toinen tiimin jäsen on oikolukenut lopullisen tekstin
• Tiiminvetäjä on hyväksynyt kampanjan julkaisun tarkistuslistan

Suunnitteluprojektien valmiin työn määritelmä 

Suunnittelutiimit tarvitsevat valmiin työn määritelmän yhdistämään luovan tavoitteen ja teknisen luovutuksen. Ilman sitä suunnitelmat siirtyvät kehitykseen keskeneräisinä: määrityksiä puuttuu, responsiivista toimintaa ei ole validoitu tai saavutettavuudessa on puutteita, jotka havaitaan liian myöhään.

Tässä on esimerkki suunnitteluprojektin valmiin työn määritelmästä:

• Suunnitelma on tarkistettu WCAG 2.2:n saavutettavuusstandardien mukaisesti
• Luovutustiedosto on valmisteltu sovitulla työkalulla, ja se sisältää kaikki määritykset, aineistot ja merkinnät
• Sidosryhmien hyväksyntä on saatu ja dokumentoitu
• Suunnittelujärjestelmän komponentit on päivitetty, jos käyttöön on otettu uusia malleja
• Responsiivinen toiminta on validoitu sovituilla rajakohdilla

Valmiin työn määritelmä ja hyväksymiskriteerit

Valmiin työn määritelmä on tiimitason laatustandardi, kun taas hyväksymiskriteerit ovat ominaisuustason toiminnallisia vaatimuksia.

Ajattele valmiuden määritelmää perustasona, jota sovelletaan kaikkialla, ja hyväksymiskriteerejä yksittäiseen sprintin kehitysjono- tai tuotteen kehitysjonon kohteeseen liittyvinä ainutlaatuisina vaatimuksina. Tuotteen kehitysjonon kohde on valmis, kun se täyttää sekä hyväksymiskriteerinsä että tiimin valmiuden määritelmän.

Näkökulma	Valmiuden määritelmä	Hyväksymiskriteerit
Laajuus	Koskee jokaista tuotteen kehitysjonon kohdetta ja inkrementtiä	Kohtainen yksittäiselle käyttäjätarinalle tai tuotteen kehitysjonon kohteelle
Vastuu	Kehittäjien vastuulla, koko Scrum-tiimin osallistumisella	Tuoteomistajan laatimat tai hänen kanssaan laaditut
Yksityiskohtaisuus	Kaikkea työtä koskevat yleiset laatustandardit	Yksityiskohtaiset toiminnalliset vaatimukset yhdelle työtehtävälle
Muuttumistiheys	Muuttuu harvoin; päivitetään sprintin retrospektiiveissä	Muuttuu jokaisen uuden käyttäjätarinan yhteydessä
Valvontapiste	Tarkistetaan ennen kuin kohde merkitään valmiiksi	Varmennetaan tarinan katselmoinnin tai hyväksymistestauksen aikana

Yleiset sudenkuopat ja virheet

Seuraavassa on yleisiä virheitä, joita kannattaa välttää valmiuden määritelmiä luotaessa:

• Kohtien ohittaminen nopeamman etenemisen vuoksi: Tiimit jättävät aikapaineen alla usein pois esimerkiksi tietoturvatarkastuksen, saavutettavuustestauksen tai dokumentoinnin kaltaisia kriteerejä. Tämä synnyttää piilevää teknistä velkaa, joka tulee myöhemmin esiin virheinä, uudelleentyönä tai vaatimustenmukaisuusongelmina.
• Tarkistuslistan tekeminen liian yksityiskohtaiseksi: Liian yksityiskohtaisesta valmiuden määritelmästä tulee byrokraattinen velvollisuus. Jos tarkistuslistassasi on 30 kohtaa ja kehittäjät käyttävät enemmän aikaa ruutujen merkitsemiseen kuin ohjelmiston rakentamiseen, olet mennyt liian pitkälle. Ole riittävän täsmällinen, jotta määritelmä on merkityksellinen, mutta riittävän yleinen, jotta se pysyy käytännöllisenä.
• Valmiuden määritelmän muuttaminen tarinakohtaisesti: Valmiuden määritelmän koko tarkoitus on johdonmukaisuus. Toiminnallisuuskohtaiset ehdot kuuluvat hyväksymiskriteereihin, kuten given-when-then-hyväksymiskriteereihin, eivät valmiuden määritelmään.
• Sen tarkistamatta jättäminen: Valmiuden määritelmän tulisi kehittyä käytäntöjen kypsyessä, työkalujen muuttuessa tai tuotteen kasvaessa. Suosittelen tarkistamaan sen retrospektiivien aikana vähintään kerran vuosineljänneksessä ja tekemään muutoksia, kun tiimi havaitsee puutteita tai kitkaa.
• Sen noudattamatta jättäminen: Määritelmä, josta joustetaan aina jonkun vaikutusvaltaisen henkilön pyytäessä, on hyödytön. Scrum-masterin tehtävä on suojella määritelmää silloinkin, kun sidosryhmän edustaja haluaa julkaista jotain, joka ei täytä vaatimustasoa. Jos kriteerit ohitetaan jatkuvasti, tiimi menettää luottamuksensa standardiin eikä enää suhtaudu siihen vakavasti.
• ”Valmiin” sekoittaminen julkaistuun: Valmiuden määritelmä ohjaa sitä, voidaanko inkrementti julkaista, ei sitä, onko se julkaistu. Tuotteen kehitysjonon kohde voi olla valmis ilman käyttöönottoa. Älä lisää ”tuotantoon otettu” -kohtaa valmiuden määritelmään, ellei tiimisi todella vastaa koko julkaisuprosessista alusta loppuun.
• Sen tarkistamiseen viittaamatta jättäminen: Monilla tiimeillä on teknisesti valmiuden määritelmä, mutta jos kukaan ei ole tarkastellut sitä sen jälkeen, kun se luotiin kuusi kuukautta sitten, se ei toimi laatustandardina.

Mitä seuraavaksi?

Vie ketteriä prosessejasi ja työskentelytapojasi eteenpäin käytännöllisten työkalujen, mallien ja asiantuntijanäkemysten avulla liittymällä maksuttomaan DPM-jäsenyyteen ja vahvista järjestelmiä, jotka auttavat tiimejä tuottamaan laadukasta työtä johdonmukaisesti.