Pri razvoju programske opreme in upravljanja produktov je zgodovina po meri neformalni opis v naravnem jeziku ene ali več funkcij sistema programske opreme. Primeri uporabniške zgodbe so pogosto napisani z vidika končnega uporabnika ali uporabnika sistema. Pogosto se zabeležijo na kartici računa, v opombah Post-it ali v programski opremi za upravljanje projektov. Odvisno od projekta lahko uporabniške zgodbe napišejo različne zainteresirane strani, vključno z odjemalci, menedžerji ali oblikovalci skupin.

Razlaga

Prilagojene zgodbe so vrsta mejnega objekta. Prispevajo k razvoju pomena in komunikacije, to pomeni, da pomagajo skupinam razvijalcev sistematizirati svoje razumevanje sistema in njegovega konteksta.


Primeri uporabniške zgodbe se pogosto zamenjujejo s sistemskimi zahtevami. Zahteva je formalni opis potrebe; zgodovina po meri je neformalni opis funkcije.

Ustvarjanje

Leta 1998 je Alistair Cockburn obiskal projekt Chrysler v Detroitu, C3 pa je ustvaril izraz "Zgodovina uporabnikov je obljuba za pogovor". Z ekstremnim programiranjem (XP) so uporabniške zgodbe postale del načrtovalne igre.

Zahteve

Kako narediti dobro uporabniško zgodbo? Leta 2001 je Ron Jeffries predlagal formulo "Tri Cs" za ustvarjanje zgodb po meri:

Zemljevid (ali pogosto opomba) je materialni fizični žeton za shranjevanje konceptov.

Pogovor poteka med zadevnimi strankami (stranke,uporabniki, razvijalci, preizkuševalci itd.). Je ustna in jo pogosto dopolnjuje dokumentacija.

Potrditev zagotavlja, da je bil namen pogovora dosežen. Tako je zapisano v primerih in predlogah zemljevidov za uporabnike v angleškem jeziku.

V nekaterih skupinah je produktni vodja (ali lastnik izdelka v Scrumu) odgovoren predvsem za oblikovanje uporabniških zgodb in njihovo organiziranje v portfelj izdelkov. V drugih skupinah lahko vsakdo napiše zgodovino uporabnika. Primeri uporabniške zgodbe so napisani za uporabnike ali odjemalce, da vplivajo na funkcionalnost razvitega sistema. Prilagojene zgodbe je mogoče razviti z razpravo z deležniki, na podlagi oseb ali preprosto zbranih. Tako je zapisano v uradnem vodniku Kako narediti uporabniško zgodbo kartiranje.

Metode

Kot osrednji del številnih prilagodljivih metodologij, kot je načrtovanje iger XP, lastne zgodbe določajo, kaj bi bilo treba vdelati v projekt programske opreme. Uporabniške zgodbe temeljijo na prioritetah strank (ali lastniku izdelka v Scrumu), da navedejo, katere so najpomembnejše za sistem in bodo razčlenjene na naloge in jih bodo razvijalci ocenili. Eden od načinov za ocenjevanje je na Fibonaccijevi lestvici. To bo pravi primer dobre "uporabniške strani"! Ko se uvedejo vaše lastne zgodbe, morajo razvijalci imeti možnost, da o tem govorijo s stranko. Kratke zgodbe so lahko težko razlagati, morda zahtevajo osnovno znanje ali pa so se zahteve po pisanju zgodovine spremenile.
Vsakemu uporabniku zgodovine je treba na neki točki priložiti enega ali več preskusov sprejemljivosti, ki razvijalcu omogoča, da preveri, kdaj je pripravljen, in omogoči stranki, da ga preveri. Brez natančnega besedila zahtev so lahko dolgi nekonstruktivni argumenti, ko je treba izdelek dostaviti.

Sporni status

Ni prepričljivih dokazov, da uporaba zgodb po meri povečuje uspešnost programske opreme ali produktivnosti razvijalcev. Kljub temu pa njihove lastne zgodbe olajšujejo iskanje pomena brez pretiranega strukturiranja problemov, povezanih z uspehom. Omejitve uporabniških zgodb vključujejo:

Problem skaliranja.

Težko je ohraniti zgodbe po meri, napisane na majhnih fizičnih zemljevidih, ki jih je težko povečati za velike projekte in so problematične za geografsko razporejene skupine.

Nejasen, neformalen in nepopoln sklop pravil.

Komunikacijska vrednost

Zgodbe po meri se štejejo za začetek pogovora. Ker so neformalne, so odprte za številne interpretacije. Skratka, ne vsebujejo vseh podrobnosti, potrebnih za izvajanje funkcije. Zato zgodbe niso primerne za formalne sporazume ali pisanje pravnih pogodb.

Pomanjkanje nefunkcionalnih zahtev

Poročila po meri redko vključujejo zahteve glede zmogljivosti ali funkcionalnosti, zato se lahko opustijo nefunkcionalni preskusi (kot so odzivni časi).
Mnogi konteksti uporabljajo lastne zgodbe, ki so prav tako združene zaradi pomena in organizacijskih razlogov. Različne uporabe so odvisne od stališča, na primer s stališča uporabnika kot lastnika izdelka glede na funkcije ali z vidika podjetja v zvezi z organizacijo nalog.

Oznake

Medtem ko nekateri predlagajo uporabo epskih in tematskih oznak za vsako možno vrsto združevanja zgodovine uporabnikov, jih vodstvo organizacije želi uporabiti za močno strukturiranje in združevanje delovnih obremenitev. Jira, na primer, zdi, da uporablja hierarhično urejen seznam primerov, v katerih so imenovali prvo stopnjo uporabniških nalog, drugo epsko skupino (združevanje uporabniških zgodb) in tretjo raven "pobude" (združevanje epov). Vendar pa pobude niso vedno prisotne v razvoju upravljanja izdelkov in preprosto dodajo še eno raven podrobnosti. Jira ima "teme" (za sledenje), ki omogočajo povezovanje presekov in elementov skupine različnih delov fiksne hierarhije. V tej uporabi Jira spremeni pomen teme v smislu organizacije: na primer, koliko časa smo porabili za razvoj teme xyz. Druga definicija teme pa je niz zgodb, epov, funkcij itd. Za uporabnika, ki ustvari skupno semantično enoto ali namen, verjetno ni splošne definicije, ker obstajajo različni pristopi k različnim slogom oblikovanja in oblikovanja izdelka. V tem smislu nekateri tudi predlagajo, da se ne uporabljavse toge skupine in hierarhije.

Epic

Velike zgodbe ali zgodbe več uporabnikov, ki so zelo tesno povezane, so povzete kot epske. Splošna razlaga za epic je zgodovina po meri, ki je prevelika za sprint. Mnogo epov ali zgodb, razvrščenih hierarhično, so večinoma znane iz Jire.

Zemljevid uporabniške zgodbe: opis

Zemljevid zgodovine je grafična dvodimenzionalna vizualizacija zaostankov izdelka. Na vrhu zemljevida so naslovi, ki združujejo zgodbe, ki se ponavadi imenujejo "epi" (velike grobe uporabniške zgodbe), "teme" (zbirke povezanih uporabniških zgodb) ali "dejanja". Določajo se z usmerjanjem uporabnikovega poteka dela ali "v vrstnem redu, v katerem bi razložili obnašanje sistema." Navpično pod epskim primeri dejanskih uporabniških zgodb so razvrščeni in razvrščeni po prioriteti. Prva vodoravna vrstica predstavlja "skelet hoje" in spodaj, ki predstavlja večjo kompleksnost. Tako je mogoče opisati celo velike sisteme, ne da bi izgubili splošno sliko. Mnenja uporabnikov o uporabniški zgodbi so omejena na interaktivnost in zabavo tega razreda, ki je zelo prijeten za ljudi. Zahtevajo prednosti take programske opreme. To je predvsem, da olajšujejo ocenjevanje nalog.
Primeri uporabniške zgodbe so del prožnega pristopa, ki omogoča preusmeritev poudarka na pisne zahteve za njihovo razpravo. Vse prilagodljive uporabniške zgodbe vsebujejo eno ali dve pisni stavkiin, kar je še pomembneje, vrsto pogovorov o želeni funkcionalnosti.

Predloga

Kaj naj povem o primerih uporabniškega zemljevida? Custom zgodbe so kratki, preprosti opisi funkcij, z vidika osebe, ki želi dobiti novo priložnost. To je ponavadi uporabnik ali sistemski odjemalec. Običajno sledijo preprosti predlogi: želim, ker. To je odgovor na vprašanje, kako zgraditi zemljevid zgodovine kartiranja zgodb uporabnika. Prilagojene zgodbe so pogosto napisane na karticah ali zapiskih, shranjenih v škatli za čevlje in postavljene na stene ali mize, da se olajša načrtovanje in razprava. Kot taki, močno preusmerijo poudarek na funkcije pisanja, da bi jih razpravljali. Dejansko so te razprave pomembnejše od pisnega besedila. Za slednje lahko uporabite zgoraj opisane uporabniške zgodbe.

Koristi

Ena od prednosti prilagodljivih zgodb po meri je, da jih je mogoče zapisati z različnimi stopnjami podrobnosti. Mi lahko napišemo svojo zgodbo, da pokrijemo veliko število funkcionalnosti. Te velike zgodbe uporabnikov so ponavadi znane kot epske. Tukaj je primer epske prilagodljive zgodovine uporabnikov iz rezervnega izdelka v pc. Kot uporabnik lahko varnostno kopirate celoten trdi disk. Ker je epski zapis ponavadi prevelik za prilagodljiv ukaz za njegovo dokončanje v eni ponovitvi, je razdeljen na več zgodb majhnih uporabnikov, preden je razširjen. Epski prikaz, ki je prikazan zgoraj, lahko razdelimo na desetine (ali,morda stotine). Kot napredni uporabnik lahko določite datoteke ali mape za varnostno kopiranje na podlagi velikosti datoteke, datuma izdelave in datuma spremembe. Kot uporabnik lahko oseba določi mape brez varnostne kopije, tako da disk z varnostno kopijo ni napolnjen s stvarmi, ki jih ni treba shraniti. Kako se dodajajo podrobnosti v uporabniške zgodbe? Podrobnosti lahko dodate na dva načina:

Delite svojo zgodbo na več manjših.

Dodajanje zadovoljstva. "

Kadar je razmeroma velika zgodba razdeljena na več majhnih, prilagodljivih uporabniških zgodb, je naravno, da domnevamo, da so bile podrobnosti dodane, in še več je bilo napisanih.

Pogoji zadovoljstva

Preizkus sprejem na visoki ravni, ki bo veljal po zaključku fleksibilnega uporabnika zgodovine. Upoštevajmo naslednje kot še en primerek prilagodljivega uporabnika zgodovine:

Kot podpredsednik marketinga želim izbrati počitniško sezono, ki bo uporabljena za oceno učinkovitosti preteklosti ogroženosti oglaševalskih kampanj, tako da lahko ugotovim donosnost.

V tem primeru uporabniške zgodovine lahko dodate podrobnosti tako, da dodate naslednje pogoje zadovoljstva:

Prepričajte se, da deluje z velikimi maloprodajnimi počitnicami: Božič, Velika noč, Predsedniški dan, Materinski dan, Očetov dan, Praznik dela, Novo leto.

Podpora za dopuste, ki zajemajo dve koledarski leti (nobena od treh).

​​

Počitniške sezone je mogoče nastaviti od enega počitnice do drugega (npr. Zahvalni danpred božičem)

Zdravilišča se lahko ustanovijo nekaj dni pred prazniki.

Vsakdo lahko napiše zgodovino uporabnika. Lastnik izdelka mora zagotoviti, da obstaja veliko nedokončanih uporabniških zgodb, vendar to ne pomeni, da je avtor lastnika izdelka. Za dober fleksibilen projekt morate pričakovati, da ima vsak uporabnik primere uporabniških zgodb. Upoštevajte tudi, da je oseba, ki piše zgodovino uporabnika, veliko manj pomembna od tiste, ki sodeluje v razpravi.

Vrednosti za projekte

Poročila po meri so napisana skozi prilagodljiv projekt. Ponavadi poteka pisanje na začetku. Vsi v ekipi sodelujejo pri izdelavi dnevnika čakanja na izdelek, ki v celoti opisuje funkcionalnost, ki bo dodana med projektom ali v roku treh do šestih mesecev od izdaje. Primeri tega so v veliki zbirki Primer uporabnega zemljevida. Nekatere od teh prilagodljivih uporabniških zgodb bodo nedvomno epske. Kasneje bodo epske pesmi razširjene v manjše zgodbe, ki se bodo lažje ujemale v eno ponovitev. Poleg tega se lahko kadarkoli in kdor koli zapiše nove zgodbe, ki se lahko dodajo v portfelj izdelkov. Agilni projekti, zlasti Scrum, uporabljajo backend izdelka, ki je prednostni seznam funkcionalnosti, ki bodo razvite v izdelku ali storitvi. Kljub dejstvu, da so elementi dela v teku lahko po želji skupine, so njihove lastne zgodbe postale boljše.najbolj priljubljena oblika dela.