Kuinka monta kertaa olet nähnyt kehittäjien ja testaajien kiistelevän siitä, miten jonkin tietyn ominaisuuden pitäisi toimia? Entä kehittäjien hämmentyneet ilmeet, kun he eivät ole olleet varmoja, miten pyytämäsi ominaisuus pitäisi rakentaa? Molemmat ovat melko yleisiä ongelmia ohjelmistomaailmassa, ja onneksi sinulla on tehokas työkalu niiden ratkaisemiseen – hyväksymiskriteerit.
Tässä oppaassa erittelen tämän vaatimusten kirjaamistavan luonnetta, selitän sen roolin tuotehallinnassa ja näytän, miten kirjoitetaan hyviä hyväksymiskriteerejä.
Sisällysluettelo
Mitä hyväksymiskriteerit ovat?
Mikä on hyväksymiskriteerien kirjoittamisen tarkoitus?
Miltä hyvin kirjoitettujen hyväksymiskriteerien pitäisi näyttää?
Yleiset hyväksymiskriteerien muodot
Mitä hyväksymiskriteerit ovat
(ja mihin ne sijoittuvat ketterässä kehityksessä ja Scrumissa?)
Ketterän kehityksen menetelmässä hyväksymiskriteeri on pienin toiminnallisen tai suunnitteluun liittyvän vaatimuksen yksikkö, jonka ketterän tuotehallinnan asiantuntijat (tai liiketoiminta-analyytikot) lisäävät käyttäjätarinoihinsa viestiäkseen selkeästi niiden ominaisuuksien eri tiloista ja toiminnasta, joita tiimi suunnittelee rakentavansa.
Teknisesti ottaen voit käyttää hyväksymiskriteerejä missä tahansa. Perinteisesti ne ovat kuitenkin osa käyttäjätarinoita, jotka ovat ketterän kehityksen eeposten osia.
Ymmärtääksemme hyväksymiskriteerejä paremmin palautetaan ensin mieleen tämän hierarkian osat ja käydään läpi, mihin kutakin niistä käytetään.
Eepokset
Eepokset ovat tehtäviä, jotka sisältävät suuren ominaisuuden tai toisiinsa liittyvien ominaisuuksien ryhmän korkean tason toiminnalliset ja ei-toiminnalliset vaatimukset. Yleensä eepos kattaa kokonaisen käyttötapauksen asiakkaillesi ja sisältää kaikki taustalla olevat ominaisuudet ja toiminnot, jotka sinun on toteutettava kyseisen käyttötapauksen kattamiseksi.
Kuvitellaan, että kuuluisit Spotifyn tuotetiimiin ja haluaisit laajentaa sovelluksen käyttöä lisäämällä uuden käyttötapauksen liikkeellä oleville ihmisille, joilla ei ole internetyhteyttä.
Tämän käyttötapauksen kattamiseksi voisit harkita uuden suuren ominaisuuden, nimeltään ”Spotifyn offline-tila”, lisäämistä. Siitä voisi tulla tuotteen työjonoon eepos, joka sisältää kaikki yleiset vaatimukset sille, että käyttäjät voivat kuunnella musiikkia ilman verkkoyhteyttä, sekä useita käyttäjätarinoita tämän ominaisuuden tiettyjä osia koskevine vaatimuksineen.
Käyttäjätarinat
Käyttäjätarinat ovat kooltaan pienempiä ja edustavat yhtä selkeästi rajattua toiminnallisuuden osaa eepoksen sisällä. Ne ovat pieniksi pilkottuja työtehtäviä, jotka ketterä tiimi voi sitoutua toimittamaan yhden iteraation aikana.
Yksi käyttäjätarinan tärkeimmistä ominaisuuksista on, että sen edustaman toiminnallisuuden pitäisi olla valmis ja mahdollisesti käyttökelpoinen.
Jos esimerkiksi rakennat verkkopohjaista tiedostojen tallennussovellusta ja haluat antaa käyttäjillesi mahdollisuuden nimetä lataamansa tiedostot uudelleen, sinun on tehtävä työtä sekä käyttöliittymässä (uudelleennimeämisen käyttöliittymässä ja käyttökokemuksessa) että taustajärjestelmässä (uuden nimen tallentamisessa).
Jotta ominaisuus olisi valmis ja käyttökelpoinen, sinun on saatettava molemmat tehtävät loppuun ja yhdistettävä käyttöliittymän ja taustajärjestelmän osat toisiinsa. Tiimisi tekisi kaiken tämän yhden käyttäjätarinan puitteissa.
Jos tekisit ainoastaan taustajärjestelmää koskevan työn, sitä koskeva tehtävä ei olisi varsinainen käyttäjätarina, koska sen lopputulos ei olisi valmis eikä käyttökelpoinen.
Jotta kehitystiimi tietäisi, miltä ominaisuuden pitäisi näyttää ja miten sen tulisi toimia, tuoteomistajat kirjoittavat kyseiselle käyttäjätarinalle hyväksymiskriteerit.
Have an account? Log In
Käyttäjätarinan hyväksymiskriteerit
Lopuksi hierarkiamme pienimpiä ohjelmistotuotteen vaatimusten osia ovat hyväksymiskriteerit. Ne edustavat kyseisen toiminnallisuuden yksittäisiä käyttöskenaarioita tai tietoja, joita suunnittelutiimi pitää tärkeinä käyttäjätarinaa toteuttaessaan.
Edellä mainitussa esimerkissä hyväksymiskriteerinä voisi olla tekstikentän avaaminen niin, että tiedoston nimi on täytetty siihen valmiiksi, jos käyttäjä napsauttaa lataamansa tiedoston kohdalla ✏️Nimeä uudelleen -painiketta.
Valmiin työn määritelmä (kyllä, se eroaa hyväksymiskriteereistä!)
Joskus tuoteomistajat (erityisesti ne, jotka ovat melko uusia tässä Scrum-roolissa) sekoittavat valmiin työn määritelmän ja hyväksymiskriteerit keskenään.
Myönnän, että tämä oli aluksi melko hämmentävää myös minulle, koska molemmat ovat ”kriteerejä sen tarkistamiseksi, onko ominaisuus valmis.”
Ainoa ero on siinä, että valmiin määritelmä edustaa täydellisyyttä tiimin kehitysprosessien näkökulmasta.
Hyväksymiskriteerit puolestaan edustavat toiminnallisia vaatimuksia (sitä, miltä ominaisuuden tulisi näyttää ja miten sen tulisi toimia).
Tämä tarkoittaa, että valmiin määritelmä pysyy samana kaikissa tiimin toteuttamissa käyttäjätarinoissa, ellei tiimi päätä muuttaa sitä retrospektiiveissä. Hyväksymiskriteerit puolestaan ovat ainutlaatuisia jokaiselle käyttäjätarinalle, sillä ne kuvaavat, miten kyseisen ominaisuuden tulisi toimia.
Huomautus: Joissakin tuotehallintatyökaluissa voit määrittää käyttäjätarinoille sekä valmiin määritelmän että hyväksymiskriteerit.
Kun nyt muistamme, mistä eepoksissa ja käyttäjätarinoissa on kyse ja miten hyväksymiskriteerit liittyvät niihin, siirrytään ymmärtämään, miksi tuotepäälliköt kirjoittavat hyväksymiskriteerejä ylipäätään.
Mikä on hyväksymiskriteerien kirjoittamisen tarkoitus?
Voinko vain kirjoittaa käyttäjätarinan kuvauksen haluamallani tavalla ilman, että sisällytän siihen hyväksymiskriteerejä? Mitä hyötyä hyväksymiskriteerien kirjoittamisesta oikeastaan on?
Tietenkin voit kirjoittaa käyttäjätarinasi haluamallasi tavalla. Suosittelen kuitenkin käyttämään hyväksymiskriteerejä vaatimustesi muotoiluun, sillä tähän muotoon liittyy monenlaisia etuja. Tässä on muutama huomioitava etu.
Ne kannustavat käyttäytymislähtöiseen ajatteluun
Jos valitset hyväksymiskriteereille BDD-muodon (palaamme siihen myöhemmin), hyväksymiskriteerit kuvaavat asiakkaidesi etenemistä heidän käyttäessään kyseistä ominaisuutta.
Tämän lähestymistavan hienous on siinä, että siirrät ajattelusi pois kuivista teknisistä vaatimuksista ja alat tarkastella ominaisuutta käyttäjän näkökulmasta. Näin pystyt hahmottamaan, mitä käyttäjä kokee ja tuntee ollessaan vuorovaikutuksessa ominaisuutesi kanssa.
On hyvin tavallista, että tuotepäällikkö ymmärtää suunnittelemansa toiminnallisuuden olevan kaikkea muuta kuin paras mahdollinen, kun hän tarkastelee sitä käyttäjiensä näkökulmasta.
Olen kokenut tämän itsekin useita kertoja. Esimerkiksi kun laadin vaatimuksia matemaattiselle kaavamuokkaimelle (se oli osa talousanalyysiin tarkoitettua SaaS-tuotetta, jota rakensimme tuolloin), halusin muokkausprosessin näyttävän tältä:
- Muokkauspainike kaavan vieressä.
- Muokkauspainikkeen napsauttaminen tekisi kaavakentästä muokattavan ja näyttäisi painikkeet ✅ Tallenna ja ❎ Peruuta .
- Kumman tahansa painikkeen napsauttaminen poistaisi muokkaustilan käytöstä, ja valitusta painikkeesta riippuen kaavan uusi tallennettu versio tai vanha versio ilmestyisi kenttään.
Tämä toimintatapa vaikuttaa loogiselta, eikö?
No, ei ennen kuin aloin kirjoittaa käyttöskenaarioita analyytikoista ja löysin merkittävän käytettävyysongelman. Analyytikot yleensä muokkaavat kaavaa tekemällä siihen pieniä muutoksia ja tarkastelemalla laskennan tulosta, kunnes he saavuttavat haluamansa kaavan.
Suunnittelemani muokkaustapa olisi ollut kohdekäyttäjilleni äärimmäisen ärsyttävä, sillä heidän olisi täytynyt siirtyä muokkaustilaan ja poistua siitä peräkkäin 20–30 kertaa. Niinpä heti kun ymmärsin virheeni, muutin nopeasti hyväksymiskriteerejä ja pyysin rakentamaan kaavamuokkaimen, jossa muutoksia voisi tehdä reaaliaikaisesti.
Ne auttavat luomaan yhden totuuden lähteen
”Nuorena” tuotepäällikkönä suurin haasteeni oli tuotevaatimusten viestiminen eri ammattiryhmiin tai jopa eri tiimeihin kuuluville ihmisille. Ongelmana oli se, että jokainen heistä ymmärsi vaatimukset eri tavalla, ja heidän keskinäinen viestintänsä muuttui epäselväksi sekasotkuksi.
Tällöin kokenut tuotepäällikkö ehdotti, että soveltaisin yhden totuuden lähteen periaatetta muotoilemalla tuotevaatimukseni erittäin selkeästi (tässä tekoäly vaatimusten keräämisessä voi auttaa), viestimällä ne kaikille ja pyytämällä heitä perustamaan työnsä ainoastaan siihen, mitä niissä on kirjoitettu.
Se oli valtava menestys, sillä kaikilla oli sama käsitys siitä, miten ominaisuuden tulisi toimia, ja jos erimielisyyksiä ilmeni, he palasivat tarkastelemaan vaatimusta.
Hyväksymiskriteerit ovat erinomainen tapa luoda yksi totuuden lähde, sillä ne kuvaavat ominaisuuden selkeästi ja helposti luettavalla tavalla ja ovat hyvin yksityiskohtaisia (kuten niiden tuleekin olla, koska niiden pitäisi kattaa kaikki ominaisuuden tärkeimmät yksityiskohdat).
Ne parantavat hyväksyntätestauksen laatua
Ohjelmistoinsinööreille hyväksymiskriteerit toimivat tuotevaatimuksina, joita he noudattavat ominaisuutta rakentaessaan. Laadunvarmistustiimillesi hyväksymiskriteereillä on puolestaan muutama lisäominaisuus:
Ne auttavat priorisoimaan testitapaukset. Jos ohjelmiston testaustiimilläsi on paljon kyseiseen ominaisuuteen liittyviä testitapauksia eikä kaikkien läpikäyntiin ole riittävästi aikaa, he priorisoivat ja suorittavat ensin ne testausskenaariot, jotka vastaavat hyväksymiskriteerejä, koska ne kuvaavat kriittisimpiä käyttäjäpolkuja.
Ne toimivat hyväksymisen tarkistuslistana. Tämä koskee sekä laadunvarmistustiimejä että tuoteomistajia, joiden on hyväksyttävä ominaisuus. Hyväksymiskriteerit toimivat nimensä mukaisesti tarkistuslistana, jonka avulla päätetään, hyväksytäänkö ominaisuus vai hylätäänkö se. Jos yksi tai useampi hyväksymiskriteeri ei täyty, laadunvarmistustiimi avaa käyttäjätarinan uudelleen ja pyytää suunnittelutiimiä lisäämään puuttuvan toiminnallisuuden.
Yhteenvetona voidaan todeta, että hyväksymiskriteerit ovat tuoteomistajien käsissä korvaamattomia työkaluja tuotevaatimusten asianmukaiseen viestimiseen. Mutta miten kirjoitetaan hyvät hyväksymiskriteerit? Autan sinua siinä seuraavaksi.
Miltä hyvin kirjoitettujen hyväksymiskriteerien tulisi näyttää?
Kirjoittamiesi hyväksymiskriteerien laatu vaikuttaa suoraan tiimisi toimittamien ominaisuuksien laatuun. Kun tiimisi ymmärtää selkeästi, mitä rakennetaan ja miten sitä testataan, se rakentaa ominaisuuden visiosi mukaisesti mahdollisimman vähin ongelmin.
Jotta onnistuisit hyväksymiskriteerien kirjoittamisessa, sinun on kiinnitettävä huomiota seuraaviin asioihin.
Selkeys
#1 synti, jonka tuoteomistaja voi tehdä, on epäselvien ja epämääräisten hyväksymiskriteerien kirjoittaminen. Voit unohtaa ajatuksen yhteisestä ymmärryksestä, jos ihmiset voivat tulkita kirjoittamasi asian monella eri tavalla.
Jotta näkisit, kuinka suuren eron sillä on, näytän sinulle esimerkin.
Mitä ymmärsit tästä lauseesta? Osaatko kertoa, miten pankkiautomaatti käyttää kortin tyyppiä päättääkseen, tunnistaako se käyttäjän vai ei? Tunnistaako pankkiautomaatti käyttäjän, jos kaikki nämä kriteerit täyttyvät samanaikaisesti, vai riittääkö vain yhden niistä täyttyminen?
Jos annat tämän hyväksymiskriteerin insinööreillesi, he hukuttavat sinut kysymyksiin ja pyytävät sinua täsmentämään vaatimuksiasi. Tehdään siitä nyt parempi.
Näyttää paljon paremmalta, eikö vain? Tällä hyväksymiskriteerillä annoimme myös vastaukset kaikkiin edellä esitettyihin kysymyksiin. Pankkiautomaatin on tuettava käyttäjän syöttämän kortin tyyppiä, ja kaikkien kolmen kriteerin on täytyttävä samanaikaisesti, jotta pankkiautomaatti voi tunnistaa käyttäjän.
Ammattilaisvinkki: Tee hyväksymiskriteereistäsi SMART-kriteerit (täsmällisiä, mitattavia, saavutettavia, olennaisia ja testattavia). Kyllä, muutin viimeisen kohdan testattavaksi, koska se on tehokkaiden hyväksymiskriteerien tärkeä ominaisuus.
Luettavuus
Sen lisäksi, että vältät epämääräisyyttä hyväksymiskriteereissäsi, sinun tulisi pitää ne yksinkertaisina ja välttää hienostelevia ilmauksia tai monimutkaista kieltä.
Olen varma, että sinulla on erittäin koulutettujen huippuosaajien tiimi, joka pystyy helposti lukemaan ja ymmärtämään englannin kielen hienoimmat ja monimutkaisimmat sanat ja ilmaukset, mutta et varmasti halua tuhlata heidän ajattelukapasiteettiaan tekstiesi tulkitsemiseen.
Joten tämän sijaan.
Sano näin.
Oletan, ettet edes vaivautunut lukemaan ensimmäistä hyväksymiskriteeriä kokonaan, koska et halunnut tuhlata aikaasi ja ajattelukapasiteettiasi!
Tapausten kattavuus
Paholainen piilee yksityiskohdissa. Joskus huomaat jääneesi paitsi jostakin ikävästä tapauksesta ominaisuudessasi vasta hyvin myöhäisessä kehitysvaiheessa, jolloin sinun täytyy avata sitä varten jatkokehitystehtävä tai jopa tehdä koko asia uudelleen.
Kuulostaako tutulta?
Mitä useampia tapauksia otat huomioon hyväksymiskriteereissäsi alusta alkaen, sitä pienempi on todennäköisyys, että joudut kohtaamaan kyseisen tilanteen työlistasi kohteissa.
Katsotaanpa nyt alla olevia hyväksymiskriteerejä.
Huomaatko tässä jotain outoa? Ensi silmäyksellä vaatimus on selkeä: lisäät sähköpostiosoitteen, napsautat Lähetä-painiketta ja henkilö saa käyttöoikeuden. Todellisuudessa emme ole ottaneet tässä huomioon monia tapauksia:
- Jos sähköpostiosoite on jo niiden käyttäjien luettelossa, joilla on käyttöoikeus asiakirjaan, sinun pitäisi ehkä näyttää virheilmoitus, joka kertoo asiasta käyttäjälle.
- Lähetät käyttäjälle kutsusähköpostin, joten ehkä jaetussa luettelossa kannattaisi näyttää, onko hän hyväksynyt kutsun vai ei.
- Jos hän ei ole hyväksynyt kutsua, ehkä olisi hyvä lisätä Lähetä kutsu uudelleen -painike.
On myös kielteisiä tapauksia, joissa täsmennät ominaisuutesi toiminnan silloin, kun jokin on tyhjää tai tapahtuu virhe.
Visuaalisten apuvälineiden aktiivinen käyttö
Olivatko edellä jakamani hyväksymiskriteerit täysin selkeitä sinulle? Kun puhuin ”Lisää henkilöitä ja ryhmiä” -kentästä, ymmärsitkö selkeästi, mistä oli kyse?
Joskus sanat eivät riitä selkeyttämään vaatimuksia tiimillesi, ja on parempi näyttää asiat kuin kertoa niistä. Parannetaanpa nyt näitä hyväksymiskriteerejä hieman.
Olenko oikeassa olettaessani, että olisit helposti ymmärtänyt, mistä puhuin näissä hyväksymiskriteereissä, jos olisit tarkastellut kuvaa ja kommenttejani rinnakkain? Uskon, että olisit.
Siinä olivat hyväksymiskriteerien ”hyväksymiskriteerit” – keskustellaan nyt erilaisista tyypeistä ja muodoista, joita tuotetiimit käyttävät niiden laatimiseen.
Yleiset hyväksymiskriteerien muodot
Sanon tämän suoraan: käytän harvoin samaa muotoa kaikissa käyttäjätarinoissani. Syynä on se, että erilaiset hyväksymiskriteerien muodot sopivat erilaisiin käyttötapauksiin, eikä ole aina paras ajatus pakottaa itseään käyttämään jatkuvasti samaa muotoa.
Siksi valitsen muodon tarinan ja sen perusteella, millaista tietoa haluan kirjoittaa sen hyväksymiskriteereihin.
Katsotaan nyt joitakin yleisiä muotoja ja niitä vastaavia hyväksymiskriteeriesimerkkejä.
BDD-muoto
BDD on lyhenne sanoista käyttäytymislähtöinen kehitys, ja se on viitekehys, joka kannustaa ohjelmistokehityksen ja tuotetiimien jäseniä määrittelemään vaatimukset sen perusteella, miten loppukäyttäjät ovat vuorovaikutuksessa ominaisuuden kanssa.
Käyttäytymiseen perustuvana vaatimusten kirjoittamisen tapana BDD:n hyväksymiskriteerit noudattavat tätä erityistä mallia:
Oletus: Käyttäjän toiminnan tietyn tilanteen esiehto.
Kun: Käyttäjän suorittama toiminto.
Silloin: Toiminnon tulos.
Jos siis haluaisit selittää, miten pankkiautomaatin rahan nostamisen ominaisuus toimii, hyväksymiskriteerisi näyttäisivät tältä:
Oletus/Kun/Silloin-tyyppiset hyväksymiskriteerit ovat hyödyllisiä, kun haluat luoda tiimissäsi empatiaa käyttäjien tarpeita kohtaan korostamalla käyttäjän näkökulmaa.
More Articles
Tarkistuslistamuoto
Toisin kuin BDD-muoto (eli ”skenaariokeskeinen” muoto), tämä ei tuo esiin loppukäyttäjän näkökulmaa. Sen sijaan siinä selitetään enemmänkin tiettyjä sääntöjä, joita ominaisuuden liiketoimintalogiikan tulisi noudattaa (tämän muodon vaihtoehtoinen nimi on ”sääntökeskeinen”). Tältä ne näyttävät.
Tämä muoto sopii sinulle parhaiten silloin, kun selitettävä logiikka on monimutkaista, sillä sen avulla voit pilkkoa sen useiksi pieniksi säännöiksi, jotka on helpompi ymmärtää ja toteuttaa.
Vuokaaviomuoto
Tämä on todennäköisesti muoto, jota käytän eniten.
Kulun esitysmuoto muistuttaa BDD-muotoa, sillä siinäkin esitetään käyttäjän näkökulma. Toisin kuin BDD, se ei kuitenkaan edellytä tiukkaa rakennetta (Oletetaan/Kun/Silloin). Voit siis kuvata käyttäjän suorittamat vaiheet haluamallasi tavalla.
Tältä rekisteröitymisprosessi näyttäisi tätä muotoa käytettäessä.
Kulun esitysmuoto on paras vaihtoehtosi, jos haluat auttaa lukijaa asettumaan käyttäjän asemaan (kuten BDD:n avulla), mutta et oikeastaan halua noudattaa tiukkaa rakennetta.
Pidä kaikki samalla sivulla hyväksymiskriteerien avulla
Hyväksymiskriteerit ovat tuoteomistajien käsissä tehokkaita työkaluja, joiden avulla he voivat luoda yhden totuuden lähteen ja pitää tiimikaverinsa linjassa kyseistä ominaisuutta koskevan visionsa kanssa.
Jos haluat lisää tämän kaltaisia oppaita ja muita loistavia resursseja tuotealan ihmisille, tilaa uutiskirjeemme!
