Valmiin määritelmä
Pohjat:
- Ominaisuuden valmiin määritelmä -pohja (Trello)
- Tuoteversion valmiin määritelmä -pohja (Trello)
Mikä on valmiin määritelmä
Ketterässä kehityksessä syntyy jatkuvasti iteraatioina potentiaalisesti julkaistavissa olevia tuoteversioita. Tuoteversioiden laadullisesti hallittuun kehittämiseen, testaamiseen ja katselmointiin (review) tarvitaan yhteinen kriteeristö eli valmiin määritelmä (definiton of done). Se kertoo ne laatuvaatimukset, jotka jokaisen toteutettavan järjestelmän osan tulee täyttää, ennen kuin se voidaan hyväksyä valmiiksi. Valmiin määritelmä perustuu johtoryhmän asettamiin reunaehtoihin, jotka periytyvät selvitys- ja kokeiluvaiheessa tunnistetuista kriittisimmistä laatuvaatimuksista.
Valmiin määritelmä on ketterän toteutuksen tärkein laadunhallinnan väline.
Betavaihe on ketterän kehityksen ensimmäinen vaihe, jossa valmiin määritelmää tarvitaan - alfavaiheessa on kehitetty prototyyppiä, jolla ei vielä ole laatuvaatimuksia.
Ominaisuus vs. tuoteversio
Valmiin määritelmiä on hyvä olla kaksi erilaista. Ensinnäkin tarvitaan valmiin määritelmä jokaiselle valmistuvalle ominaisuudelle. Ominaisuudella tarkoitetaan jokaista palveluun toteutettavaa toiminnallisuutta eli kehitystehtävää.
Toiseksi tarvitaan valmiin määritelmä sille, millä kriteereillä tuoteversio on valmis julkaistavaksi. Tuoteversiolla tarkoitetaan jokaista palvelun toimivaa julkaisukelpoista kehitysversiota.
Valmiin määritelmässä sovitaan seuraavat asiat:
Ominaisuuden valmiin määritelmä
Jos kyse on käyttäjäkokemuksesta:
- Onko käyttäjäkokemus kuvattu – miten toimii?
- Käyttöliittymä- ja päätelaitevaatimukset
Jos koodaamista:
- Onko testattu (yksikkö-, järjestelmä-, integraatiotestit)?
- Onko arkkitehtuurin mukainen?
- Onko tietoturva- ja tietosuojarajoitteiden mukainen?
- Onko julkaistu testiympäristöön
- Dokumentointiin liittyvät vaatimukset (koodin dokumentointi)
Tuoteversion valmiin määritelmä
Jos kyse on käyttäjäkokemuksesta:
- Onko käyttäjätestattu?
- Onko käyttäjäpalaute kerätty ja analysoitu?
- Onko käyttäjäpalautteen pohjalta käyttäjäkokemus haluttu?
- Muotoiluperiaatteiden ja visuaalisen ohjeen päivittäminen
Jos tuotteeseen liittyy toimintaa tai prosesseja:
- Onko prosessi kuvattu?
- Onko prosessi testattu?
- Onko prosessi tietoturva- ja tietosuojarajoitteiden mukainen?
- Onko prosessi jalkautettu?
- Arkkitehtuurin dokumentointiin liittyvät kriteerit
Jos koodaamista:
- Onko tuoteversio julkaistu?
- Onko koodi julkaistu version-/koodinhallintajärjestelmään?
- Onko tietoturva- ja tietosuojatestattu?
- Varmuuskopiointiin liittyvät kriteerit
- Suorituskykytestaukseen liittyvät kriteerit
- Käyttö- tai ylläpito-ohjeiden dokumentointiin liittyvät vaatimukset
- Tyylikirjastojen päivittämiseen liittyvät kriteerit
Toteutuuko valmiin määritelmä?
Jotta valmiin määritelmä ei rapautuisi kehityshankkeen arjessa, sen toteutumista on tarkasteltava tiimin kesken säännöllisesti. Oikea paikka tälle on sprintin retrospektiivit, joissa muutenkin käydään läpi tiimin jatkuvaa oppimista ja työtapoja.
Haasteet
Valmiin määritelmiä sovittaessa perusongelmana on usein optimistisuus. Valmiin määritelmään listataan kaikki asiat, joita tilaaja periaatteessa edellyttää, ilman, että kukaan pystyy täsmentämään vaatimuksia saati varmistamaan, että ne täyttyvät. Tällöin ongelmaksi muodostuu usein se, että valmiin määritelmä jää kuolleeksi kirjaimeksi, eikä kokonaislaadusta lopulta ole yhteistä käsitystä.
Valmiin määritelmä kannattaa siksi pitää vaatimattomana. Sillä varmistetaan se, että kehitystiimi myös pystyy toteuttamaan sen. Myöhemmin, kun tiimi saa kehityskäytännöt toimimaan sujuvasti, voidaan myös valmiin määritelmää tarkentaa kunnianhimoisemmaksi. Valmiin määritelmää kasvatettaessa on samalla sovittava, mitä tehdään aiemmin kehitettyjen tuotteen osien laatuvelalle suhteessa uuteen valmiin määritelmään.