Hyväksymiskriteerien kirjoittaminen Jirassa – käytännön esimerkkejä

”Asiakkaat voivat muuttaa ilmoitusasetuksiaan” kuulostaa selkeältä Jira-tehtävältä, kunnes joku alkaa rakentaa sitä. Tallentuuko muutos heti? Mitä tapahtuu tallennuksen epäonnistuessa? Onko asetus tallessa vielä huomenna? Mitä sähköposteja se koskee?

Hyväksymiskriteerit muuttavat avoimet kysymykset sovituiksi, havaittaviksi tuloksiksi. Ne auttavat muutoksen tilaajia, rakentajia ja tarkistajia työskentelemään samoista odotuksista.

Tässä oppaassa laadimme kriteerit kuvitteelliselle asiakasportaalitoiminnolle, parannamme epämääräisiä vaatimuksia ja lisäämme käytännön listan Power Packin Definition of Done & AC -työkaluun. Aloittamiseen ei tarvita erityistä kirjoitusmuotoa. Selkeät ehdot ja tulokset riittävät.

Mitä hyväksymiskriteerit ovat?

Hyväksymiskriteerit kuvaavat ehdot, jotka tietyn työn täytyy täyttää tullakseen hyväksytyksi. Ne keskittyvät kyseisen tehtävän odotettuun tulokseen. Atlassian erottaa ne Definition of Donesta, joka kuvaa valmiin työn laajempaa laatustandardia. Katso Atlassianin hyväksymiskriteeriopas.

Esimerkissämme ”Tallennettu ilmoitusvalinta säilyy valittuna asiakkaan kirjautuessa uudelleen” on hyväksymiskriteeri. ”Toteutus on katselmoitu” kuuluu yhteiseen Definition of Doneen.

Ero pitää molemmat listat hyödyllisinä. Hyväksymiskriteerit kertovat, tekeekö toiminto sen, mitä tiimi sopi. Definition of Done kertoo, täyttääkö työ tiimin laajemman valmistumisen standardin.

Kummankaan listan ei tarvitse sisältää jokaista toteutusvaihetta. ”Luo tietokantakenttä” voi olla tarpeellinen kehitystehtävä, mutta se ei kerro asiakkaalle tai tarkistajalle, toimiiko asetus oikein.

Aloita yhdestä asiakastuloksesta

Kuvitteellisen tehtävämme nimi on ”Anna asiakkaan hallita viikoittaista koostesähköpostia”. Tavoitteena on, että kirjautunut asiakas voi valita viikkokoosteen vastaanoton muuttamatta välttämättömiä tiliviestejä.

Ennen kriteerien kirjoittamista tiimi sopii muutamista rajauksista. Asetuksella on erillinen Save-painike. Asiakas muuttaa vain omaa asetustaan. Asetus vaikuttaa koosteisiin, joita ei ole vielä jonotettu. Jo jonotetut viestit jäävät tämän tehtävän toimitussäännön ulkopuolelle.

Yksityiskohdat on keksitty esimerkkiä varten. Oman tiimisi pitäisi sopia todellinen toiminta eikä kopioida niitä tuotevaatimuksiksi.

Lyhyt rajausmerkintä voi estää pitkää listaa kantamasta kaikkea taustatietoa. Jira-kuvaukseen kirjataan, että tehtävä koskee yhtä tiliasetussivun asetusta. Toimituspäivien valinta, sähköpostiosoitteen vaihtaminen ja muiden asiakkaiden asetusten hallinta ovat erillistä työtä.

Nyt kriteerit voivat keskittyä tuloksiin, jotka osoittavat juuri tämän muutoksen toimivuuden.

Kirjoita ensin normaali käyttötapaus

Aloita kokemuksesta, jonka odotat useimpien asiakkaiden käyvän läpi. Kuvaa alkutilanne, toiminta ja havaittava tulos tavallisella kielellä.

Esimerkiksi: ”Kun kirjautunut asiakas poistaa viikkokoosteet käytöstä ja tallentaa onnistuneesti, uudelleen avatut tiliasetukset näyttävät koosteet pois käytöstä.” Tarkistaja voi luoda alkutilanteen, suorittaa toiminnon ja tutkia tuloksen.

Lause on hyödyllisempi kuin ”Asetukset tallentuvat oikein”. Se määrittää muuttuvan asetuksen, muutoksen voimaantulon ja tarkistustavan.

Tiimi tarvitsee myös vastakkaisen suunnan. Valinta, joka poistaa koosteet käytöstä mutta ei pysty ottamaan niitä käyttöön, on keskeneräinen. Kirjoita erillinen kriteeri, jos vastakkainen toiminta ansaitsee oman varmistuksensa.

Älä pakota toisistaan riippumattomia tuloksia yhteen kohtaan. Tallennus, näppäimistökäyttö, sähköpostitoimitus ja virheenkäsittely voivat kaikki olla tärkeitä, mutta yksi valtava kriteeri vaikeuttaa keskeneräisen osan osoittamista.

Lisää virhe- ja rajatapaukset

Normaalitapaus olettaa tallennuksen onnistuvan. Kysy, mitä asiakkaan pitäisi nähdä oletuksen ollessa väärä.

Tiimimme valitsee tämän säännön: jos tallennuspyyntö epäonnistuu, sivu näyttää virheen eikä onnistumisvahvistusta. Sivun avaaminen uudelleen näyttää aiemmin tallennetun asetuksen. Tämä antaa tarkistajalle konkreettisen virhetapauksen kokeiltavaksi tiimin testiympäristössä.

Tarkista seuraavaksi toiminnon rajat. Viikkokoosteasetus ei saa estää salasanan palautusviestiä. Asiakkaan valinnan täytyy myös säilyä uuteen kirjautumisistuntoon. Nämä ovat eri asioita, joten ne saavat erilliset kriteerit.

Älä kirjoita ”Kaikki rajatapaukset käsitelty”. Nimeä tärkeät tapaukset. Hyödyllinen keskustelu alkaa usein kolmella kysymyksellä: mikä voi epäonnistua, minkä täytyy säilyä ennallaan ja mitä tapahtuu myöhemmin?

Jos tiimi ei pysty sopimaan odotettua tulosta, kirjaa avoin päätös ennen toteutuksen etenemistä liian pitkälle. Vastaamaton kysymys ei muutu käyttökelpoiseksi kriteeriksi pelkästään listalle lisäämällä.

Kokonainen hyväksymiskriteerilista

Tässä on kuvitteellisen tehtävän ensimmäinen valmis luonnos. Jokainen kohta kuvaa erikseen varmistettavan tuloksen.

• Tiliasetusten avaaminen näyttää asiakkaan nykyisen tallennetun viikkokoosteasetuksen.
• Kun viikkokoosteet poistetaan käytöstä ja tallennetaan onnistuneesti, uudelleen avatut tiliasetukset näyttävät asetuksen pois käytöstä.
• Kun viikkokoosteet otetaan käyttöön ja tallennetaan onnistuneesti, uudelleen avatut tiliasetukset näyttävät asetuksen käytössä.
• Onnistuneen tallennuksen jälkeen uloskirjautuminen ja uusi sisäänkirjautuminen säilyttävät tallennetun asetuksen.
• Jos tallennus epäonnistuu, virhe näytetään, onnistumisvahvistusta ei näytetä ja asetusten uudelleen avaaminen näyttää aiemmin tallennetun asetuksen.
• Asiakas, jonka asetus on pois käytöstä, ei saa yhtään onnistuneen tallennuksen jälkeen jonotettua viikkokoostetta.
• Asiakas, jonka asetus on käytössä, voi edelleen saada seuraavan viikkokoosteen olemassa olevien ajastussääntöjen mukaisesti.
• Viikkokoosteiden poistaminen käytöstä ei estä asiakasta saamasta pyytämäänsä salasanan palautusviestiä.

Toimituskohdat riippuvat jonotettuja viestejä koskevasta rajauspäätöksestä. Tiimi kirjaa tämän taustan tehtävän yhteyteen, jotta tarkistaja ei oleta asetuksen peruuttavan jo lähetettäviä sähköposteja.

Kriteerit tarvitsevat myös toimivan varmistustavan. Toimitustoiminnan osalta tiimi määrittää, miten kooste käynnistetään tai havaitaan testiympäristössä. Kriteeri voi olla selkeästi kirjoitettu mutta vaikea varmistaa, jos kenelläkään ei ole pääsyä tarvittavaan tiliin tai toimitusnäyttöön.

Paranna epämääräisiä kriteerejä ennen lisäämistä

Nopea sanamuotojen tarkistus ehkäisee usein pidempiä erimielisyyksiä myöhemmin. Lue jokainen kohta ja kysy, voisiko kaksi ihmistä tulkita onnistumisen eri tavoin.

Viimeinen esimerkki ei yksin todista käytettävyyttä. Se korvaa yhden epämääräisen lauseen yhdellä hyödyllisellä, rajatulla tarkistuksella. Laajemmat käytettävyystavoitteet voivat vaatia tutkimusta tai useita sovittuja havaintoja.

Varo myös keksittyä täsmällisyyttä. Kahden sekunnin vastevaatimus kuulostaa mitattavalta, mutta luo todellisen sitoumuksen. Sovi suorituskykyrajan olosuhteet ja peruste ennen sen lisäämistä.

Vie kriteerit Power Packiin

Avaa Jira-tehtävä ja etsi Definition of Done & AC -kortti. Valitse Acceptance Criteria -välilehti. Sen lista on erillään Definition of Done -välilehdestä, joten tarkista valinta ennen sisällön syöttämistä.

Lisää yksi kriteeri kirjoittamalla otsikko ja valitsemalla Add tai painamalla Enter. Käytä tiiviitä otsikoita, jotka säilyttävät odotetun tuloksen. Jos kriteeri tarvitsee laajaa taustaa, pidä se Jira-kuvauksessa tai tiimin linkitetyssä dokumentaatiossa.

Lisää useita kohtia valitsemalla Bulk Import ja liittämällä Markdown-luettelo. Voit kopioida yllä olevat esimerkit ja lisätä kunkin eteen yhdysmerkin ja välilyönnin. Myös Markdown-valintaruutulistoja tuetaan.

Tarkista kohdat tuonnin jälkeen. Toiminto lisää nykyiseen listaan, joten saman listan uudelleentuonti voi luoda jo olemassa olevia kohtia. Valitut Markdown-valintaruudut saapuvat valmiiksi merkittyinä; aloita merkitsemättömistä kohdista, ellei nykyisen tehtävän tuloksia ole todella varmistettu.

Jos kohta on väärä, käsittele korvaava sanamuoto tiimin kanssa, lisää korjattu kohta ja poista vanhentunut vahvistuskehotteen kautta. Pidä tehtävän taustakeskustelu selkeänä, jos muutos vaikuttaa sovittuun rajaukseen.

Tarkista tulokset ennen valmiiksi merkitsemistä

Pyydä ennen toteutusta varmistukseen osallistuvaa henkilöä käymään ehdotetut kriteerit läpi. Hän voi havaita puuttuvia alkuehtoja tai tuloksen, jota nykyinen testiympäristö ei mahdollista havaitsemaan.

Varmista toteutuksen jälkeen jokainen tulos ja kirjaa näyttö tiimin normaalin Jira- tai dokumentointiprosessin kautta. Valitse kohdan Done-painike, kun sovittu tulos on läpäisty. Uusi valinta palauttaa kohdan tekemättömäksi, jos myöhempi havainto avaa tarkistuksen uudelleen.

Asetus saattaa esimerkiksi säilyä sivun latauksessa mutta nollautua uuden kirjautumisen jälkeen. Sivun uudelleenavaamisen kriteeri voi täyttyä, vaikka istuntojen välisen säilymisen kriteeri on kesken. Erilliset kohdat säilyttävät tämän hyödyllisen eron.

Power Pack seuraa listan valmistumista; se ei suorita testejä eikä automaattisesti määritä niiden tarkistajaa. Jos arviointi vaatii nimetyn varmistajan tai päivätyn tuloksen, kirjaa tiedot nimenomaisesti tavallisessa prosessissa.

Käytä molempia lukumääriä sekoittamatta niitä todisteeseen

Acceptance Criteria ja Definition of Done näyttävät kumpikin omat valmiiden ja kaikkien kohtien määränsä. Valmiusilmaisin näyttää Ready for Release vain, kun molemmat listat sisältävät kohtia ja jokainen kohta on valmis. Muulloin se näyttää In Verification.

Se on yhteenveto syötettyjen listojen tilasta. Se ei osoita kriteerien kattavan kaikkea tärkeää toimintaa tai näytön olevan luotettavaa. Se ei myöskään valvo Jiran työnkulkusiirtymiä tai estä yhdistämisiä.

Ilmoitustehtävässämme kaikki kahdeksan hyväksymiskriteeriä voivat olla valmiita, vaikka tukiohje on yhä kesken Definition of Done -listalla. Toiminnon tulokset on varmistettu, mutta tiimin laajemmassa valmistumissopimuksessa on avoin kohta.

Aloita yhdestä tulevasta Jira-tehtävästä. Kirjoita asiakastulos, sovi olennaiset ehdot ja tulokset ja lisää kriteerit Power Packiin yhteisen Definition of Donen rinnalle. Tarkista lista muutoksen rakentajien ja varmistajien kanssa. Hyötynä on vähemmän oletuksia aluksi ilmeiseltä kuulostaneen lauseen takana.

• Atlassian — Mitä hyväksymiskriteerit ovat?