Mikä on Käyttäjän Tarina ja hyväksymiskriteerit (Esimerkkejä)

Täydellinen Opas käyttäjätarinan hyväksymiskriteerit tosielämän skenaarioita:

Ohjelmiston Kehittäminen teollisuuden, sana ”Vaatimus” määrittelee, mitä tavoitteenamme on, mitä asiakkaat tarkalleen tulee ja mitä tekee meidän yritys kasvattaa liiketoimintaansa.

On se tuote, yritys, joka tekee ohjelmistoja, tuotteita tai palveluja yritys, joka tarjoaa palveluita eri-ohjelmisto kentät, prime base heille kaikille on vaatimus ja menestys määritellään sen mukaan, miten hyvin vaatimukset täyttyvät.,

termillä ”vaatimus” on eri nimet eri projektimenetelmissä.

Vesiputous, se on nimitystä ’Vaatimus/Specification Document’, Agile tai SCRUM se kutsutaan ’Eeppinen’, ’User Story’.

Alle Vesiputous malli, Vaatimus asiakirjat ovat valtava docs 200 tai enemmän sivuja kuin koko tuote on toteutettu yksi vaihe. Agile/Scrumin kohdalla näin ei kuitenkaan ole, sillä näissä menetelmissä vaatimukset on annettu pienille toiminnallisuuksille tai ominaisuuksille, sillä tuote valmistetaan vaiheittain.,

tässä artikkelissa, olen yrittänyt parhaani jakaa kaikki minun 4 vuotta kokemusta työskentelystä Käyttäjän tarinoita ja niiden hyväksymiskriteerit sekä helppo ja yksinkertainen tosielämän skenaarioita paremmin.

käydäänpä fundamentalistit uudelleen ensin.

mikä on käyttäjän tarina?

käyttäjä tarina on vaatimus tahansa toiminnallisuus tai ominaisuus, joka on kirjoitettu yksi tai kaksi riviä ja max 5 riviä. Käyttäjä tarina on yleensä yksinkertaisin mahdollinen vaatimus ja on noin yksi ja vain yksi toiminnallisuus (tai ominaisuus).,

yleisimmin käytetty standardi muodossa Käyttäjälle, Tarina luominen on esitetty alla:

Koska <käyttäjän rooli/asiakas, Haluan < tavoite voidaan toteuttaa>, niin voin <syy, tavoite>.

Esimerkki:

Kuten WhatsApp-käyttäjä, haluan kameran kuvaketta kirjoittaa chat-ruutuun kaapata ja lähettää kuvia niin, että en voi klikata ja jakaa kuvia samanaikaisesti kaikkien ystävieni kanssa.

mikä on hyväksymiskriteeri?,

hyväksymisperuste on joukko hyväksyttyjä ehtoja tai liiketoimintasääntöjä, jotka toiminnallisuuden tai ominaisuuden olisi täytettävä ja jotka tuotteen omistajan/sidosryhmien olisi hyväksyttävä.

Tämä on erittäin tärkeä osa käyttäjän tarina loppuun ja se olisi tutkittu Tuotteen Omistaja ja Liiketoiminnan Analyytikko erittäin huolellisesti, koska puuttuu yksi kriteeri voi maksaa paljon. Tämä on yksinkertainen numeroitu tai luodattu luettelo.

sen muoto on seuraava:

”koska jokin edellytys on, kun teen jotain toimintaa niin odotan tulosta”.

Example (v. r.,t edellä user story):

• mietitään, että olen jutteleminen ystävän kanssa ja minun pitäisi pystyä kaapata kuvan.
• kun napsautan kuvaa, minun pitäisi pystyä lisäämään kuvateksti kuvaan ennen sen lähettämistä.
• Jos siellä on jokin ongelma alkaa puhelimeni kamera, virhe viesti, kuten Kameraa ei voitu käynnistää’. jne., on osoitettava sen mukaisesti.

Näin ollen, Käyttäjä tarina määritellään vaatimus tahansa toiminnallisuus tai ominaisuus, kun hyväksymiskriteerit määritellään ’Definition of done’ käyttäjän tarina tai vaatimus.,

Kuten QA se on erittäin tärkeää ymmärtää käyttäjän tarina ja sen hyväksymiskriteerit syvällisesti kanssa ei edes yhden epäilystäkään jäljellä ’aloita testaus’. Eteenpäin mennään ymmärtämään, miksi käyttäjien tarinoissa ja hyväksymiskriteereissä on erittäin tärkeää kaivaa ”syvää”.

Kaivaa syvälle Käyttäjän tarinoita

aluksi, tehkäämme ensin ymmärtää, että on tärkeää perusteellisen tutkimus on perus-ja olennainen asia eli Käyttäjän Tarinoita.

seuraavat tapaukset ovat omia todellisia kokemuksia.,

Case #1:

Ennen kuin 3 vuotta, olin työskennellyt mobiilisovellus, Projekti ja tuote on sovellus, joka oli suunniteltu toimitus ihmiset.

olisit nähnyt toimituspaikkaasi tulevan toimitushenkilön. Ja heillä on matkapuhelin, jossa he pyytävät sinua antamaan allekirjoituksesi toimituksen jälkeen. Tämä allekirjoitus heijastuu kuriiripalvelujen tarjoajien kuten DDC: n, Fedexin jne.portaaliin.

kuvitellaan, että mobiilisovellus on juuri lanseerattu ja niiden portaalit ovat jo olemassa ja ylhäällä.,

Ongelma: Sprintti Tuotteen omistaja on käyttäjä tarina tämä mobiili sovellus, joka ”, Kuten Portal Admin, minun pitäisi pystyä tarkastelemaan allekirjoitus ottanut toimitus henkilö toimitusaika”. Tässä portaalia (web app) muutetaan ja päivitetään vastaavasti vastaamaan allekirjoitusta.

QA: na sinun on tarkistettava, heijastuuko mobiilisovellukseen tallentunut allekirjoitus portaalin odotetusti.,

Jos katsot tämän käyttäjän tarina, se näyttää yksinkertainen, mutta siellä on piilotettu vaatimus täällä, että ”historiallisista toimitukset, ei allekirjoitus pohdintaa toiminnallisuutta, joten mitä pitäisi tapahtua, jos portaalin kaverit tarkastella historiallisia toimitukset?”Pitäisikö historialliset tiedot pyyhkiä pois? Pitäisikö meidän sallia kaatumisia tai virheitä tällaisia tietoja?

ei tietenkään ollenkaan, tämä pitäisi hoitaa armollisesti.,

Ratkaisu: Kun kunkin DB taulukoita päivitetään, jos haluat lisätä uuden sarakkeen Allekirjoitus paikka, vanhat tiedot pitäisi olla NULL tai 0 arvo, joka pitäisi olla tarkastettu ja viestin, jossa ’N allekirjoitus olemassa’ pitäisi näkyä.

tätä voi kutsua tuotteen omistajan tai yritysanalyytikon missiksi, mutta tämä on tehtävä. Toteuttaminen yksi ominaisuus onnistuneesti, mutta rikkoa jotain yhdessä se ei ole toivottavaa asiakkaiden. Tämä pitää tehdä saman käyttäjätarinan ohella ja samassa sprintissä.,

Case #2

6 vuotta sitten, olin työskennellyt Eläke-Suunnittelu Rahoitus Sovellus (ilman BA), joka oli maailmanlaajuinen sovellus, jossa Rahoitus ihmiset, kuten CA -, Rahoitus Neuvonantajat voivat käyttää sitä eri valuutoissa hankkeen investointi suunnitelmia, säästöt, jne., yli suuren ajan asiakkailleen.

Ongelma: Tuotteen Omistaja antaa Käyttäjän Tarina, että ”Neuvonantajana, haluan tarkastella raporttia minun asiakas perustuvat taloudelliset tiedot”.,

Täällä oli 2 piilotettu vaatimukset ja kutsuisin sitä epätäydellinen tarina, koska:

a] raportit pitäisi harkita päivittäistä valuutan muuntokurssi ja ole historiallisia kuin viimeksi katseltu raportti ja

b], Jos valuutta on muuttunut sen jälkeen, kun antaa asiakkaan taloudelliset tiedot, raportit pitäisi näkyä muuttunut valuutassa.

ratkaisu: nostin tämän huolen suoraan Tuoteomistajallemme ja tein hänelle selväksi, että molemmat on tehtävä mahdollisimman pian. Hän oli kanssani samaa mieltä ja loi 2 eri tarinoita tulevista kiri ensisijaisesti.,

Take Away: nämä jäivät kiinni, koska olimme kaikki hyvin tietoisia tuotteista, niiden suunnittelusta, rakenteesta jne. Tällaista tietoa voidaan saavuttaa vain ymmärtämällä tuotteen täysin, ymmärtämällä yhteentoimivuutta ja tutkimalla käyttäjän tarina perusteellisesti, vaikka se on 2 linjaliikennettä.

tekee muistiinpanoja asioiden helpottamiseksi ja keskustelee BA: n ja kehittäjien kanssa heidän ajattelustaan.,

Syvällistä tarkastella hyväksymiskriteerit

Ymmärtäminen hyväksymiskriteerit ja kaikki muut olosuhteet& säännöt tyhjentävästi on jopa tärkeämpää kuin vähättelemällä käyttäjän tarina. Koska jos vaatimus on puutteellinen tai epämääräinen, se voidaan ottaa seuraavan sprintin mutta jos hyväksymisraja on jäänyt, niin käyttäjä itse tarina voi olla julkaissut.

kai me kaikki olisi käyttänyt verkkopankin jossain vaiheessa, ja useimmat meistä käyttävät sitä päivittäin ja lataan minun historiallisia lausumia paljon., Jos tarkkailet sitä huolellisesti, on olemassa tiettyjä erityisiä vaihtoehtoja niiden lataamiseen.

tiliotteen lataamiseen on mahdollisuus valita tiedostotyyppi. On mahdollisuus valita, jos haluat ladata vain Krediitit / Debit / molemmat.

Nyt kuvitella, että Tuotteen Omistaja antaa sinulle tämän Käyttäjän tarina ”asiakkaana haluan ladata tiliote niin, että voin katsoa kaikki liiketoimet tehdään tietyn ajan”.,

seuraavat hyväksymiskriteerit:

• Ottaen huomioon, että olen Ladata Historiallinen Selvitys Sivu, minun pitäisi valitse ajanjakso, jonka haluan ladata julkilausuman.
• ottaen huomioon, että olen Download Historical Statement-sivulla, minun pitäisi valita tili, jolle haluan ladata lausunnon.
• Ottaen huomioon, että olen Ladata Historiallinen Selvitys Sivu, en saisi ladata selvitys tulevaisuuden ” Ja ” päivämäärä.,
• ottaen huomioon, että olen Download Historical Statement-sivulla, minun ei pitäisi sallia valita ”alkaen” päivämäärä 10 vuotta aikaisemmin.
• ottaen huomioon, että lataan lausuntoni, minun pitäisi pystyä katsomaan ladattu tiedosto.
• ottaen huomioon, että olen Download Historical Statement-sivulla, minun pitäisi pystyä lataamaan lausuntoni doc -, excel-ja pdf-muodoissa.

Jos käy läpi tämän hyväksynnän, on 3 asiaa, jotka puuttuvat täältä:

• ladattavan tiedostonimen nimi ja muoto.,
• mitä tietoja (Sarakenimiä) tiedostossa näytetään.
• valinnat-luettelosta ja valitse, millainen kaupan asiakas haluaa eli vain debet tai hyvitys vain tai molemmat.

Tällaiset tapaukset voi tapahtua silloin tällöin, kuitenkin vielä opiskella hyvin kunkin hyväksymiskriteerit ja yrittää visualisoida se viittaus käyttäjän tarina. Mitä enemmän tutkit syvällisesti edellytykset ja liiketoiminnan sääntöjä, sitä enemmän tulee tietoa ominaisuus.

Bugeja löytynyt alkuvaiheessa kustannus ei ole mitään verrattuna siihen, mitä se voi maksaa ’testaus’ vaiheessa.,

Tärkeää löytää Eroja käyttäjätarina/hyväksymiskriteerit

Se on aina tärkeää tehdä syvä sukellus käyttäjän tarinoita ja hyväksymiskriteerit varhaisessa vaiheessa, jopa ennen kuin kehitys tai testaus alkaa.

Koska se liittyy:

#1) Tuhlausta Aikaa:

Jos poikkeamia tai virheitä käyttäjä tarina/hyväksymiskriteerit löytyvät, kun kehitys on menossa tai testaus on menossa, niin paljon työstämistä voi olla tarpeen tehdä loput sprintin ajan.,

Se ei tapahdu, että vaikka Tuotteen Omistaja jäi muutamia asioita, he siirtyvät käyttäjän tarina tulossa sprint. 95% mahdollisuudet ovat, että he pyytävät joukkue tehdä tarvittavat täytäntöönpanoa ja vapauttaa sen samassa sprintissä.

siksi siitä tulee joukkueelle painajainen, kun he joutuvat viettämään ylimääräistä aikaa, tulemaan viikonloppuisin tai työskentelemään myöhään illalla. Tämä voidaan välttää tutkimalla ja keskustelemalla käyttäjän tarina/hyväksymiskriteerit mahdollisimman varhaisessa vaiheessa.

#2) ponnistelujen tuhlaus:

kehittäjien ja LAADUNVARMISTUSKOMITEAN on tarkasteltava uudelleen toteutettuja koodeja ja testitapauksia., Päivittäminen, lisääminen ja poistaminen per vaatimus ei ole helppo tehtävä. Siitä tulee liian tuskallista, koska on jo paineita toimittaa ajoissa.

tällaisessa tilanteessa kehitys-tai testausvaiheessa on virheiden mahdollisuus. Jos törmäät tällaiseen tilanteeseen mennä ’DevQA pariksi’. Kakun kuorrutuksena ylimääräisestä työstä ei välttämättä saa korvausta.

päätelmä

syvä ymmärrys käyttäjän tarinasta ja hyväksymiskriteereistä voidaan saavuttaa vain kuluttamalla valtavasti aikaa sen tutkimiseen.,

ei ole erityisiä työkalu tai tietysti saatavilla markkinoilla voit tehdä tämän sinulle, koska tämä on kaikki siitä, loogista ajattelua, kokemusta ja tietoa tuotteen.

osallistu Pre-suunnitelma kokous aktiivisesti, puhua BA, opiskelu oman voi vain auttaa sinua saavuttamaan tämän. Mitä enemmän ponnistelee, sitä enemmän oppii ja kasvaa.

olipa kyseessä QA: n tai kehittäjien, kaikkien on oltava samalla sivulla käyttäjien tarinoista ja niiden hyväksymiskriteereistä, vain silloin asiakkaan odotukset voidaan saavuttaa onnistuneesti.,

Onko sinulla jotain uutta kerrottavaa kokemuksistasi käyttäjien tarinoiden parissa työskentelyssä? Ilmaise ajatuksesi alla!!