Lukeminen aika: 7 minuuttia

Onnistumisen hanke riippuu kyvystä kehitys tiimi vastaamaan asiakkaansa tarpeisiin. Asiakkaan ja kehitystiimin välisellä viestinnällä on keskeinen rooli tuotevaatimuksiin ja markkinavaatimuksiin sopivan ratkaisun aikaansaamisessa., Ongelmia syntyy, jos asiakkaat selittävät tarpeitaan liian epämääräisesti ja tiimi ei ymmärrä selkeitä vaatimuksia ja lopulta taustalla olevaa liiketoimintaongelmaa. Kuvittele, että pyydät tiimiäsi antamaan käyttäjille mahdollisuuden etsiä tuotetta Online-kirjakaupasta luokittain. Odotat, että sinulla on selkeä käyttöliittymä kategorialinkkejä klikkaa niitä (esim. Fantasia, tietokirjallisuus, Historiallinen, jne.) Kahden viikon kehitystyön jälkeen saat hakupalkin ominaisuuden, jossa käyttäjien on kirjoitettava haluamaansa luokkaan valmiiksi lueteltujen luokkien selaamisen sijaan., Vaikka tämä myös toimii, alkuperäinen tavoite oli paljastaa kaikki saatavilla olevat luokat ja antaa käyttäjien tutkia edelleen.

tällöin laadukas ohjelmistodokumentaatio voisi auttaa välttämään ongelman. Käyttäjätarinat ja hyväksymiskriteerit (AC) dokumentointivaatimusten pääasiallisina muotoina. Käyttäjätarina on luonnollinen kielenkuvaus ominaisuudesta. Siihen liittyy yleensä hyväksymiskriteerit.

hyväksymiskriteerit (AC) ovat ehtoja, jotka ohjelmistotuotteen on täytettävä, jotta käyttäjä, asiakas tai muu järjestelmä hyväksyy sen., Ne ovat ainutlaatuisia jokaiselle käyttäjätarinalle ja määrittelevät ominaisuuskäyttäytymisen loppukäyttäjän näkökulmasta. Hyvin kirjoitettu hyväksymiskriteerit auttaa välttää odottamattomia tuloksia lopussa kehitysvaiheessa ja varmistaa, että kaikki sidosryhmät ja käyttäjät ovat tyytyväisiä, mitä he saavat.

hyväksymiskriteerit ovat alimman tason toiminnalliset vaatimukset

hyväksymiskriteerit päätavoitetta

Selvennetään sidosryhmien vaatimukset on korkean tason tavoite. Jotta AC: n tarkoitukset olisivat selkeämmät, hajotetaan ne.,

Feature scope detalisation. AC määrittelee käyttäjien tarinoiden rajat. Ne antavat tarkkoja yksityiskohtia toiminnallisuudesta, jotka auttavat tiimiä ymmärtämään, onko tarina valmis ja toimii odotetusti.

negatiivisten skenaarioiden kuvaaminen. Yor AC saattaa vaatia järjestelmää tunnistamaan turvattomat salasanatulot ja estämään käyttäjää etenemästä pidemmälle. Virheellinen salasanamuoto on esimerkki niin sanotusta negatiivisesta skenaariosta, kun käyttäjä tekee virheellisiä syötteitä tai käyttäytyy odottamatta. AC määrittelee nämä skenaariot ja selittää, miten järjestelmän on reagoitava niihin.

asetus viestintä., Hyväksymiskriteerit synkronoivat asiakkaan ja kehitystiimin visiot. Ne varmistavat, että kaikilla on yhteinen käsitys vaatimukset: Kehittäjät tietävät tarkalleen, millaista käyttäytymistä ominaisuus on osoitettava, kun sidosryhmät ja asiakas ymmärtää, mitä on odotettavissa ominaisuus.

virtaviivaistaa hyväksymistestausta. AC on käyttäjätarinan hyväksymistestauksen perusta. Kunkin hyväksymiskriteerin on oltava itsenäisesti testattavissa, ja sen on siten oltava selkeä läpimeno-tai epäonnistumisskenaario. Niitä voidaan käyttää myös tarinan todentamiseen automatisoiduilla testeillä.

Ominaisuusarvio., Hyväksymiskriteerit määrittelevät, mitä joukkueen on tarkalleen kehitettävä. Kun tiimillä on tarkat vaatimukset, he voivat jakaa käyttäjien tarinoita tehtäviin, jotka voidaan arvioida oikein.

hyväksymiskriteerit tyypit ja rakenteet

AC voidaan kirjoittaa eri muodoissa. On olemassa kaksi yleisintä, ja kolmas vaihtoehto on suunnitella oma muoto:

• skenaario-suuntautunut (Koska/Kun/Sitten)
• sääntö-orientoitunut (tarkistuslista)
• custom muodot

Koska ensimmäinen ja toinen muodoista on hyvin erityisiä rakenteita, me enimmäkseen keskittyä niihin., Saatat kuitenkin huomata, että muut formaatit sopivat tuotteeseesi paremmin, joten käsittelemme niitä myös lyhyesti.

Skenaario-suuntautunut hyväksymiskriteerit

Skenaario-suuntautunut muodossa kirjallisesti AC tunnetaan Koska/Kun/Sitten (GWT) tyyppi.

• Koska jotkut edellytys
• Kun teen jotain toimintaa
• – odotettavissa on joitakin tulos

Tämä lähestymistapa oli perinyt behavior-driven development (BDD) ja tarjoaa johdonmukaisen rakenteen, joka auttaa testaajia määrittää, milloin aloittaa ja lopettaa testaus tietty ominaisuus., Se myös vähentää testitapausten kirjoittamiseen kuluvaa aikaa, Kun järjestelmän käyttäytymistä kuvataan etukäteen.,

Jokainen hyväksymiskriteerit kirjoitettu tässä muodossa on seuraavat lausunnot:

1. Skenaario – nimi käyttäytymistä, joka kuvataan
2. Koska – alusta valtion skenaario
3. Kun – erityiset toimet, jotka käyttäjä tekee
4. Sitten – toiminnan tulokset vuonna ”, Kun”
5. Ja käytetään edelleen kaikista kolmen edellisen lausunnot

Kun yhdistetään nämä lausunnot kattavat kaikki toimet, jotka käyttäjä tekee tehtävän suorittamiseen ja kokemuksen tulos.

Katsotaanpa joitakin esimerkkejä.,

Esimerkki 1

Käyttäjän tarina: käyttäjänä haluan voida palauttaa salasanan tililleni, niin että voin käyttää tiliäni jos unohdin salasanan.,igated kirjautumissivulle

Kun: käyttäjä on valinnut forgot salasana vaihtoehto

Ja: Tuli voimassa oleva sähköpostiosoitteesi, niin saat linkin salasanan palautus

Sitten: järjestelmä lähettää linkin tuli sähköposti

Koska: käyttäjä sai linkin kautta sähköposti

Kun: Käyttäjä suunnistaa linkin kautta saanut sähköpostia

Sitten: järjestelmän avulla käyttäjä voi asettaa uuden salasanan

Esimerkki 2:

Käyttäjän tarina: käyttäjänä haluan pystyä pyytämään rahaa tililtäni ATM niin, että en voi saada rahaa minun tilille nopeasti ja eri paikoissa.,kansi

Ja: annostelija sisältää rahaa

Kun: asiakas pyytää rahaa

Sitten: on varmistettava, että tiliä on veloitettu

Ja: varmistaa, käteisellä annostellaan

Ja: varmista, että kortti palautetaan

hyväksymiskriteerit 2:

Koska: että tili on miinuksella

Ja: kortti on voimassa

Kun: asiakas pyytää rahaa

Sitten: varmista, että hylkääminen viesti näkyy,

Ja: varmista, että rahaa ei ole luopua

Sääntö-suuntautunut hyväksymiskriteerit-muodossa

joissakin tapauksissa, se on vaikea sovittaa hyväksymiskriteerit osaksi Koska/Kun/Sitten rakenne., Esimerkiksi, GWT tuskin olisi hyödyllistä seuraavissa tapauksissa:

• Olet työskennellyt käyttäjän tarinoita, jotka kuvaavat järjestelmän tason toiminnallisuus, joka tarvitsee muita menetelmiä laadunvarmistukseen.
• kohderyhmä hyväksymiskriteerit ei tarvitse tarkkoja yksityiskohtia testaustilanteisiin.
• GWT skenaariot eivät sovi kuvataan suunnittelu-ja käyttökokemusta rajoitteet ominaisuus. Kehittäjät voivat olla huomaamatta useita kriittisiä yksityiskohtia.

näihin tapauksiin voi puuttua sääntölähtöisellä AC-formaatilla.,

sääntökeskeinen muoto tarkoittaa, että on olemassa joukko sääntöjä, jotka kuvaavat järjestelmän käyttäytymistä. Näiden sääntöjen perusteella voit piirtää erityisiä skenaarioita.

yleensä tällä lomakkeella laaditut kriteerit näyttävät yksinkertaiselta luotilistalta. Katsotaanpa esimerkkiä.

Esimerkki

Käyttäjän tarina: käyttäjä, haluan käyttää haku-kenttä ja kirjoita kaupungin nimi tai kadulla, niin että voisin löytää matching hotelli vaihtoehtoja.,

Basic search interface hyväksymiskriteerit

• haku-kenttään on sijoitettu top bar
• Haku käynnistyy, kun käyttäjä napsauttaa ”Etsi”
• – kenttä sisältää paikkamerkki, jossa on harmaa-värillinen teksti: ”Minne olet menossa?”
• placeholder katoaa, kun käyttäjä aloittaa kirjoittamalla
• – Haku suoritetaan, jos käyttäjä on kaupunki, hotellin nimi, street, tai kaikki yhdessä
• Haku on englanti, ranskan, saksan ja ukrainan
• käyttäjä voi kirjoittaa yli 200 symboleja
• haku ei tue erikoismerkkejä (merkkiä)., Jos käyttäjä on kirjoittanut erityisen symbolin, Näytä varoitusviesti: ”hakutulo ei voi sisältää erityisiä symboleja.”

muut formaatit

useimmat käyttäjätarinat voidaan peittää kahdella edellä mainitulla formaatilla. Kuitenkin, voit keksiä oman hyväksymiskriteerit koska ne palvelevat niiden tarkoituksiin, ovat kirjoitettu selkeästi plain englanti, ja voi olla väärin. Jotkut joukkueet käyttävät jopa pelkkää tekstiä.,

Joskus, teidän kriteerit voidaan määritellä esimerkiksi järjestelmän käyttäytymistä:

yksinkertaisia AC vahvoja salasanoja Mark Levison varten agilepainpainrelief.com

Tämä lähestymistapa tarjoaa selkeät suuntaviivat salasana ominaisuus testaus.

Roolit vastuussa ja miten hyväksymiskriteerit luodaan

Jotkut kriteerit on määritelty ja kirjoitettu tuotteen omistaja, kun hän tai hän luo tuotteen kehitysjonoon. Ja muut voi tarkemmin eritellä tiimin aikana käyttäjien tarinoita keskusteluja jälkeen sprint suunnittelu., Kriteerien kirjoittamisesta vastaavan henkilön valintaan ei ole tiukkoja suosituksia. Asiakas voi dokumentoida ne, jos hänellä on runsaasti teknistä ja tuotedokumentaatiotietoa. Tällöin asiakas neuvottelee kriteerit tiimin kanssa keskinäisten väärinkäsitysten välttämiseksi. Muutoin kriteerit luovat tuotteen omistaja, liiketoiminta-analyytikko, vaatimusten analyytikko tai projektipäällikkö.,

prosessi alkaa käyttäjän tarina priorisointi ja päättyy neuvottelee yksityiskohdista koko joukkue

suurimmat haasteet ja parhaat käytännöt kirjallisesti hyväksymiskriteerit

hyväksymiskriteerit näyttää siltä, että ne ovat erittäin helppo kirjoittaa. Pelkistetyistä formaateistaan huolimatta kirjoittaminen on monelle joukkueelle haaste. Katsotaanpa tarkemmin parhaita käytäntöjä, jotka auttavat välttämään yleisiä virheitä.

Dokumenttikriteerit ennen kehittämistä. Hyväksymiskriteerit on dokumentoitava ennen varsinaisen kehityksen alkua., Näin tiimi todennäköisesti ottaa talteen kaikki asiakkaiden tarpeet etukäteen. Alussa, se riittää asettaa kriteerit, pieni määrä käyttäjän tarinoita täyttää viivästyksiä kaksi sprintissä (jos käytäntö Scrum tai vastaava menetelmä). Molempien osapuolten on sovittava niistä. Sitten dokumentoidut hyväksymiskriteerit käytetään kehittäjien suunnittelemaan teknistä prosessia.

älä tee AC: sta liian kapeaa. Hyväksymiskriteerit voivat olla aivan liian spesifejä eläviä vähän eikä liikkumavaraa vaihtoehtoja kehittäjille. Tämän välttämiseksi on muistettava, että AC: n on välitettävä aikomus, mutta ei lopullista ratkaisua., Lisäksi kapea AC voi olla vailla useita käyttäjän käyttäytymistä, jotka eivät kuulu.

pidä kriteerit saavutettavissa. Tämä kohta risteää läheisesti edellisen kanssa. Tehokkaat hyväksymiskriteerit määrittelevät kohtuullisen vähimmäistoiminnon, jonka pystyt toimittamaan. Mutta jos sorrut kuvailemaan kaikkia pieniä yksityiskohtia, on olemassa riski, että tiimisi jumittuu satojen pienten tehtävien kanssa.

pitää AC: n mitattavissa eikä liian leveänä. 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 ponnistelunsa asianmukaisesti.

vältä teknisiä yksityiskohtia. Kuten mainitsimme, hyväksymiskriteerit on kirjoitettava selkokielellä. Tämä tekee niistä kaikille selkeitä ja helposti ymmärrettäviä: sidosryhmillänne tai johtajillanne ei välttämättä ole teknistä taustaa.

Reach consensus. Tiimi ja sidosryhmät voivat ratkaista saman ongelman eri tavalla näköalapaikastaan riippuen. Varmista, että olet ilmoittanut AC sidosryhmille ja saavuttanut yhteisen sopimuksen., Sama koskee joukkueen jäseniä. Jokaisen on tarkistettava AC ja vahvistaa, että he ymmärtävät ja ovat samaa mieltä kunkin linjan kanssa.

Kirjoita testattava AC. Näin testaajat voivat tarkistaa, että kaikki vaatimukset täyttyivät. Muuten, kehittäjät eivät ymmärrä, jos käyttäjä tarina on valmis.

Lopullinen

Älä laiminlyödä hyväksymiskriteerit, koska ne – on yksinkertainen ja helposti lähestyttävissä – ratkaista useita ongelmia kerralla., He dokumentoida asiakkaan odotukset, tarjoavat loppukäyttäjän näkökulmasta, selventää vaatimuksia ja epäselvyyksien välttämiseksi, ja lopulta auttaa laadunvarmistus tarkistaa, jos kehityksen tavoitteet täyttyivät. Riippumatta siitä, käytätkö ketteriä menetelmiä vai et, muista valita paras muoto tai kokeilla omia. Erityyppiset käyttäjätarinat ja lopulta ominaisuudet voivat vaatia erilaisiat ja uusien testaaminen, jotka toimivat sinulle, on hyvä käytäntö.