Miten Kirjoittaa hyväksymiskriteerit: Esimerkkejä ja Parhaita Käytäntöjä

Täällä Mobindustry, toimimme joustavalla lähestymistavalla. Se tarkoittaa, että käytämme ketteriä komponentteja, kuten käyttäjätarinoita ja hyväksymiskriteereitä. Tehokkaat tiimit ja organisaatiot ovat nämä komponentit niiden tuote viivästyksiä, ja he tietävät, miten luoda niitä ja käyttää niitä tehokkaasti.

Jos tuotekirjauksestasi puuttuu käyttäjätarinoita ja hyväksymiskriteerit — tai jos niitä ei ole määritelty selkeästi — vaarannat, että odotuksesi eivät vastaa todellisuutta., Käyttäjän tarinoita ja hyväksymiskriteerit ovat vastuussa eli miten loppukäyttäjä käyttää app ja miten kehitystiimin tulee suorittaa kunkin kehityksen tehtävä. Kun alamme työstää uutta tuotetta, tiimimme tekee yhteistyötä asiakkaan kanssa käyttäjien tarinoiden määrittelemiseksi.

käyttäjän tarina on lyhyt, yksinkertainen kuvaus tuotteen ominaisuudesta henkilön näkökulmasta, joka haluaa käyttää kyseistä ominaisuutta. Käyttäjätarinoita käytetään määrittelemään tuoteperhe ketterässä kehitystyössä.,

tuotteen kehitysjono on pohjimmiltaan kokoelma käyttäjien tarinoita, joka kertoo toiminnallinen määrittely ja kehittäminen ominaisuudet tietyn tuotteen tai palvelun. Käyttäjä tarinat koostuvat kolmesta osasta: persona käyttäjän tarina on kirjoitettu kuvaus-ominaisuus, käyttäjä vaaditaan, sekä selvitys tarpeesta ominaisuus täyttää.

Tässä on, miten kirjoittaa käyttäjätarina:

Kuten (käyttäjä) haluan (ominaisuus), niin en voi (tyydyttää tarpeen).

katsotaanpa, miltä käyttäjätarina saattaa näyttää., Esimerkkinä otetaan Airbnb. Kuvitellaan, miten tyypillinen käyttäjätarina voisi etsiä Airbnb: n kaltaista tuotetta.

”käyttäjänä haluan etsiä kohteen, jotta voin varata majoituksen vieraaseen kaupunkiin.”

Määritelmä hyväksymiskriteerit

– Nyt meidän täytyy varmistaa, että käyttäjä tarinat ovat täytetty oikein ja vastaamaan asiakkaan vaatimuksia.

hyväksymiskriteerit ovat ehtoja, jotka ohjelmistotuotteen on täytettävä, jotta käyttäjä, asiakas tai järjestelmätason toimivuuden osalta kuluttava järjestelmä voi hyväksyä sen.,

hyväksymiskriteerit on esitetty joukko väittämiä, joista jokaisella on selkeä pass/fail-tulos, joka voidaan mitata ja määrittää sekä toiminnallisia ja ei-toiminnallisia vaatimuksia.

Kirjoittaminen hyväksymiskriteerit on tärkeää paitsi luoda, mitä asiakas odottaa tuotteen, mutta kehitysprosessia. Luonnollisesti eri ihmiset näkevät saman ongelman eri näkökulmista. Hyvin määritellyt hyväksymiskriteerit tarjoavat yhtenäisen kuvan toiminnallisuudesta, jonka aiot toteuttaa.,

kuka tahansa olisi voinut kävellä Scrum board, napata tuotteen kehitysjonon kohdan, lue hyväksymiskriteerit, ja selvästi nähdä kaiken, joka on suorittanut kyseisen kohde siirretään done-sarakkeeseen. Hyväksymiskriteerit kertovat, mitä on tehtävä, jotta tietty osa tuotteesta saadaan valmiiksi.

Miksi me tarvitsemme hyväksymiskriteerit?,

• rajojen määrittely. Hyväksymiskriteerit auttavat kehitystiimiä määrittelemään käyttäjätarinan rajat. Ne toimivat vahvistuksena siitä, että sovellus toimii odotetusti, eli käyttäjätarina on valmis.
• yksimielisyyteen pääseminen. Hyväksymiskriteerit mahdollistavat sen, että kehitystiimi on samalla sivulla asiakkaan kanssa. Ne tiedottavat kehitystiimille tarkalleen, mitä ehtoja tulee täyttää ja varmistavat, että asiakas tietää, mitä hakemukselta odottaa.
• sujuvoittaa hyväksymistestausta., Hyväksymiskriteerit ovat käyttäjätarinan hyväksymistestauksen perusta. Jokainen hyväksymisrajat tulisi testata itsenäisesti ja on selvää, skenaarioita, joiden onnistuminen tai epäonnistuminen.
• suunnittelu ja arviointi. Hyväksymiskriteerien avulla voit jakaa käyttäjien tarinoita eri tehtäviin, joten ne arvioidaan ja ajoitetaan asianmukaisesti.
• negatiivisten skenaarioiden kuvaaminen. Hyväksymiskriteerit voivat vaatia järjestelmää tunnistamaan heikon salasanan ja estämään esimerkiksi käyttäjän jatkumisen., Väärän salasanamuodon syöttäminen on esimerkki negatiivisesta skenaariosta, jossa käyttäjä syöttää virheellistä tietoa tai käyttäytyy odottamatta. Hyväksymiskriteerit yksilöivät nämä skenaariot ja selittävät, miten järjestelmän olisi vastattava niihin.

kuka kirjoittaa hyväksymiskriteerit?,

Kirjoittaminen hyväksymiskriteerit auttaa luomaan yhteisen ymmärryksen tuotteen omistaja ja kehitystiimi osalta ratkaisemaan asiakkaan ongelma tai luoda tuotteen ominaisuuksia. Koska hyväksymiskriteerit liittyvät asiakkaaseen ja tiimiin, ne on kirjoitettava joko asiakkaan tai tiimin jäsenen toimesta.

Mobindustryssä yritysanalyytikkomme kirjoittavat kaikki käyttäjien tarinoiden hyväksymiskriteerit. Yritysanalyytikot ymmärtävät asiakkaan tarpeet ja sen, mitä kehittäjien on tiedettävä täyttääkseen projektin vaatimukset.,

hyväksymiskriteerit dokumentoidaan ja vahvistetaan ennen projektin alkua, sillä tiimin ja asiakkaan on sovittava, mitkä tulokset täyttävät asiakkaan vaatimukset.

Esimerkkejä käyttäjän tarinoita hyväksymiskriteerit

Nyt sinulla on selkeä käsitys siitä, mitä käyttäjän tarinoita ja hyväksymiskriteerit ovat, katsotaanpa katsomaan joitakin esimerkkejä.,

Esimerkki 1

Käyttäjätarina: käyttäjänä haluan pystyä rekisteröitymään palveluun, jotta voin aloittaa ostokset verkossa.

hyväksymiskriteerit:

• Käyttäjät voivat vain lähettää lomakkeen täyttämällä kaikki pakolliset kentät.
• käyttäjän tarjoamaa sähköpostia ei saa antaa ilmaisella sähköpostipalvelulla.
• samalta TUTKIMUSAJANJAKSOLTA saadut huomautukset voidaan tehdä vain kolme kertaa 30 minuutin kuluessa.
• käyttäjät saavat ilmoitussähköposteja onnistuneen rekisteröitymisen jälkeen.,

Esimerkki 2:

Käyttäjän tarina: käyttäjä, en voi käyttää ilmoituksen laitteen välittömästi saatuaan sen.

hyväksymiskriteerit:

• Pyyhkäisemällä/napauttamalla ilmoitusta vie käyttäjän suoraan viestiin.
• Katso näyttää keskustelun — jos Uusi viesti oli vastaus, niin se näkyy alkuperäisen yläpuolella.
• viestimäärä päivitetään.
• viesti merkitään luettavaksi sen näytettyä.

7 vinkkiä hyvien hyväksymiskriteerien kirjoittamiseen

Hyväksymiskriteereitä ei ole helppo kirjoittaa., Yksinkertaisesta formaatista huolimatta tekstin kirjoittaminen on haastavaa. Tässä seitsemän vinkkiä, joiden avulla voit välttää yleisiä virheitä kirjoittaessasi hyväksymiskriteereitä tai arvioidessasi tiimisi jäsenen kirjoittamia kriteerejä.

• Dokumenttikriteerit ennen kehittämisprosessin alkua. Näin joukkue saa helpommin kiinni kaikki asiakkaan tarpeet etukäteen. Aluksi riittää, että asetetaan kriteerit pienelle määrälle käyttäjätarinoita kahden sprintin taustajoukkojen täydentämiseksi. Dokumentoidut hyväksymiskriteerit ovat sitten kehittäjien käytössä teknisen prosessin suunnittelussa.,
• eivät tee hyväksymiskriteereistä liian kapeita. Liian tarkat hyväksymiskriteerit jättävät kehittäjille vähän liikkumavaraa. Tämän välttämiseksi on muistettava, että hyväksymiskriteerien pitäisi olla tahallisuuden ilmaus, ei lopullinen päätös. Suppeissa hyväksymiskriteereissä ei myöskään saa ottaa huomioon kaikkia käyttäjän toimia.
• Pidä kriteerit saavutettavissa. Tehokkaat hyväksymiskriteerit määrittelevät kohtuullisen vähimmäismäärän toimintoja, joita voit tarjota. Mutta jos jatkat pienten yksityiskohtien kuvaamista, vaarana on, että tiimisi jumittuu satoihin pieniin tehtäviin.,
• vältä liian laajoja hyväksymiskriteereitä. Laajat hyväksymiskriteerit tekevät käyttäjäkertomuksesta epämääräisen. Tehokkaissa hyväksymiskriteereissä on hahmoteltava työn laajuus, jotta kehittäjät voivat suunnitella ja arvioida toimiaan asianmukaisesti.
• vältä teknisiä yksityiskohtia. Hyväksymiskriteerit olisi kirjoitettava selkokielellä. Sidosryhmät ja johtajat voi olla tekninen tausta, joten käyttämällä selkeää kieltä tekee perusteet ymmärrettävää kaikille.
• Reach consensus., Sama ongelma voidaan ratkaista eri tavoin tiimin jäsenten ja sidosryhmien näkökulmasta riippuen. Varmista, että ilmoitat hyväksymiskriteerisi sidosryhmille ja tiimin jäsenille ja saavutat yhteisymmärryksen.
• Kirjoita testattavat hyväksymiskriteerit. Tämä antaa testaajille mahdollisuuden varmistaa, että kaikki vaatimukset täyttyvät ja antaa kehittäjille mahdollisuuden tietää, onko käyttäjän tarina valmis.,

Miten kirjoittaa hyväksymiskriteerit

Tässä on viisi yleisiä sääntöjä, jotka auttavat sinua ratkaisemaan ongelmia sanamuoto hyväksymiskriteerit. Näillä säännöillä voit säästää arvokasta aikaa ja luoda yhteisymmärryksen tuotteen omistajan ja kehitystiimin välillä.

Sääntö #1: Vältä ”ei”

”Ei” tarkoittaa ”ei missään tapauksessa”, ja siksi ei ole aikaa, riittää noudattamisen todentamiseksi tällainen ehto., Jos kirjoittaa, että vaatimus ilman ”ei”, se on selkeämpi ja, mikä tärkeintä, todennettavissa.

Esimerkki:

Käyttäjä > Tarina

Älä: Koska käyttäjä, en halua syöttää salasanaa aina, kun voin käyttää tiliäni.
Do: käyttäjänä haluan, että salasanani muistetaan ja täytetään automaattisesti, jotta voin käyttää tiliäni kirjoittamatta salasanaani uudelleen.

hyväksymiskriteerit

Älä: järjestelmä ei saa epäonnistua.
Do: järjestelmän käytettävyyden pitäisi olla vähintään 90 prosenttia.,

Ottamatta

Voit käyttää ”ei” hyväksymiskriteerit esitellä looginen väite, kuten ”kirjautuminen lomake ei saa olla punainen.”Useimmissa tapauksissa tämä koskee ei-toiminnallisia vaatimuksia. Tässä esimerkissä, me muotoilla rajoitus, joka voidaan helposti todentaa, jos valikoima sävyjä punainen on selkeästi määritelty (esimerkiksi määritelty RGB-muodossa).,

Sääntö #2: Käytä aktiivinen ääni

Aktiivinen ääni on, kun aihe lauseessa on esiintyjä toimintaa. Jos yhteisö on vastuussa täytäntöönpanosta toiminta ei ole selvästi merkitty, se on epäselvää, kuka tai mikä pitäisi suorittaa toimia, ja se tulee olemaan vaikeaa, voit tarkistaa, onko vaatimus on täytetty.,

esimerkki:

Käyttäjätarina

älä: verkkokauppana haluan, että suodattimia käytetään niin, että löydän mitä haluan.
Do: käyttäjänä haluan käyttää hakusuodattimia, jotta löydän kohteita.

hyväksymiskriteerit

Älä: asiakkaan henkilöllisyys olisi vahvistettava. (On epäselvää, kuka tai mikä on vastuussa asiakkaan henkilöllisyyden vahvistamisesta.)
Do: Tilin_system pitäisi vahvistaa Customer_Indentity. (Huomaa, että sanastoon on lisättävä termien ”Accounting_System” ja ”Customer_Indentity” määritelmät.,)

Sääntö #3: älä käytä pronomineja (varsinkin määrittelemätön niistä)

Käytä substantiiveja sijaan pronomineja viitatessaan kohteita viitataan muut vaatimukset. Pronomineja tulee välttää, koska ne saattavat aiheuttaa epäselvyyttä.,

Tämä on erityisen tärkeää silloin, kun hyväksymiskriteerit tallennetaan vaatimus hallinnan välineitä (kuten Jira) kuin erilliset lausunnot, jotka eivät ole välttämättä järjestetty. Käytä aina substantiiveja pronominien sijaan ja vältät tämän ongelman.

esimerkki:

Käyttäjätarina

älä: sivuston jäsenenä haluan jakaa tietoa itsestäni, jotta muut näkevät sen.
Do: sivuston jäsenenä haluan lisätä profiilikuvauksen, jotta muut voivat oppia minusta.

hyväksymiskriteerit

Älä: rekisterinpitäjän olisi lähettää driver matkareitti päivä., Se tulee toimittaa vähintään 8 tuntia ennen vuoroa.
Do: ohjaimen pitäisi lähettää Driver_Itinerary päiväksi kuljettajalle vähintään 8 tuntia ennen Driver_shiftiä.

Sääntö 4: Vältä konjunktiot

Konjunktiot ovat sanoja ja lauseita, kuten ”ja”, ”tai”, ”mutta” ja ”sekä” se yhdistää yksinkertaisia lauseita monimutkainen niistä., Niiden käyttö vaatimuksissa on yleensä merkki siitä, että vaatimus voidaan jakaa useisiin erillisiin vaatimuksiin.

Esimerkki:

Käyttäjä > tarina

Älä: Kun UI suunnittelija, haluan luoda ja tarkastella asiaa niin, että tiedän, mitä testata.
Do: KÄYTTÖLIITTYMÄSUUNNITTELIJANA haluan luoda ongelman, jotta tiedän, mitä testata. / KÄYTTÖLIITTYMÄSUUNNITTELIJANA haluan tarkastella asiaa niin, että tiedän, mitä testata.

hyväksymiskriteerit

älä: käyttäjään pitäisi joko luottaa tai ei.
Do: Security_System-järjestelmän tulisi luokitella jokainen käyttäjä joko luotetuksi tai Not_rustetuksi.,

Ottamatta

”Ja”, ”tai” ja ”ei” voidaan käyttää kuvaamaan loogisia ehtoja ja lisätä karsinnat.

Sääntö #5: Älä saavuttamaton absoluutin

absoluuttinen (kuten 100% saatavuus) on saavuttamaton. Mieti, miten tarkistaa indikaattori: onko mahdollista todistaa, että taso järjestelmän saatavuus on täsmälleen 100%?, Ja vaikka tällainen järjestelmä voitaisiin luoda, onko sinulla varaa siihen?

Vältä sanoja ”kaikki”, ”aina” ja ”ei koskaan”, sillä tällaisten absoluuttisten vaatimusten tarkistaminen vaatii äärettömän määrän testejä.

Esimerkki:

Käyttäjä > tarina

Älä: matkailija, haluan tietää oma tarkka sijainti, päivitetty reaaliajassa niin, että en eksy. (”Reaaliaikaa” voidaan tulkita eri tavoin. Se voidaan nähdä esimerkiksi absoluuttisena (viiveen puuttuminen), jota ei voida saavuttaa ja jota ei voida todentaa.,)
Do:matkailijana haluan tietää tarkan sijaintini, päivittää joka sekunti, jotta en eksy.

hyväksymiskriteerit

Älä: järjestelmän pitäisi olla 100% saatavuus. (100% on absoluuttinen, jota ei voida saavuttaa, eikä sitä voida todentaa.)
Do: järjestelmän käytettävyyden pitäisi olla vähintään 98 prosenttia.

Nopea yhteenveto hyväksymiskriteerit

toivomme, että tämä artikkeli on valottaa maailman hyväksymiskriteerit ja käyttäjän tarinoita., Tässä ovat keskeisiä noutoruokapaikkoja:

• hyväksymiskriteerit ovat ehtoja ohjelmisto tuotteen on täytettävä hyväksytty käyttäjä, asiakas, tai tässä tapauksessa järjestelmä-tason toiminnallisuus, kuluttaa järjestelmän.
• hyväksymiskriteerit on dokumentoitava ja täytettävä ennen projektin aloittamista, sillä tiimin ja asiakkaan on sovittava, mitkä tulokset täyttävät asiakkaan vaatimukset.
• Muista, että hyväksymiskriteerit pitäisi olla tahdonilmaisuun, ei lopullinen päätös.
• tehokkaat hyväksymiskriteerit määrittelevät kohtuullisen vähimmäismäärän toiminnallisuutta.,
• hyvien hyväksymiskriteerien on hahmoteltava työn laajuus, jotta kehittäjät voivat suunnitella ja arvioida toimiaan asianmukaisesti.
• hyväksymiskriteerit tulee kirjoittaa selkokielellä.
• varmista, että ilmoitat hyväksymiskriteerisi sidosryhmille ja tiimin jäsenille ja saavutat yhteisymmärryksen.
• kun kirjoitat hyväksymiskriteereitä, vältä” ei ” – konjunktioita ja saavuttamattomia absoluutteja. Muotoile lauseita aktiivisella äänellä.,

Jos haluat luoda hyväksymiskriteerit ja käyttäjän tarinoita oman mobile app tai jos sinulla on kysyttävää tästä aiheesta, ota yhteyttä Mobindustry vapaa kuuleminen.