U razvoju softvera i upravljanja proizvodima, prilagođena povijest je neformalni opis na prirodnom jeziku jedne ili više funkcija softverskog sustava. Primjeri korisničkih priča često se pišu s gledišta krajnjeg korisnika ili korisnika sustava. Često se bilježe na karticama računa, u Post-it notes ili u softveru za upravljanje projektima. Ovisno o projektu, korisničke priče mogu pisati različiti dionici, uključujući klijente, menadžere ili dizajnere timova.
Objašnjenje
Prilagođene priče su vrsta graničnog objekta. Oni pridonose razvoju značenja i komunikacije, odnosno pomažu timovima programera da sistematiziraju svoje razumijevanje sustava i njegovog konteksta.
Primjeri korisničkih priča često se brkaju sa zahtjevima sustava. Zahtjev je formalni opis potrebe; prilagođena povijest je neformalni opis funkcije.
Stvaranje
Godine 1998, Alistair Cockburn je posjetio Chrysler projekt u Detroitu, a C3 je smislio izraz "Povijest korisnika je obećanje za razgovor". S ekstremnim programiranjem (XP), korisničke priče postale su dio igre planiranja.
Zahtjevi
Kako napraviti dobru korisničku priču? Godine 2001. Ron Jeffries je predložio formulu "Tri Cs" za stvaranje prilagođenih priča:
Karta (ili često napomena) je materijalna čvrsta fizička oznaka za pohranjivanje koncepata.
Razgovor se vodi između zainteresiranih strana (klijenti,korisnicima, programerima, testerima itd.). To je usmeno i često se nadopunjuje dokumentacijom.
Potvrda osigurava da je svrha razgovora postignuta. Tako je to napisano u primjerima i predlošcima karata korisničke priče na engleskom jeziku.
U nekim timovima, voditelj proizvoda (ili vlasnik proizvoda u Scrumu) je prvenstveno odgovoran za formuliranje korisničkih priča i njihovo organiziranje u portfelj proizvoda. U drugim timovima svatko može napisati povijest korisnika. Primjeri korisničke priče napisani su ili za korisnike ili klijente kako bi utjecali na funkcionalnost sustava koji se razvija. Prilagođene priče mogu se razviti raspravom s dionicima, na temelju osoba ili jednostavno sastavljenih. Tako je napisano u službenom vodiču Kako napraviti mapiranje korisničke priče.
Metode
Kao središnji dio mnogih fleksibilnih metodologija, kao što je XP raspoređivanje igara, vlastite priče određuju što bi trebalo ugraditi u projektni projekt. Prilagođene priče temelje se na prioritetima korisnika (ili vlasniku proizvoda u Scrumu) kako bi se naznačilo koje su najvažnije za sustav te će se podijeliti na zadatke i procijeniti od strane razvojnih inženjera. Jedan od načina ocjenjivanja je Fibonacci ljestvica. Ovo će biti pravi primjer dobre "korisničke stranice"! Kada se implementiraju vaše vlastite priče, programeri bi trebali imati priliku razgovarati o tome s klijentom. Kratke priče mogu biti teško interpretirati, mogu zahtijevati neka osnovna znanja, ili su se zahtjevi možda promijenili od pisanja povijesti. Jedan ili više testova prihvaćanja moraju biti priključeni svakom korisniku povijesti u nekom trenutku, omogućujući programeru da provjeri kada je spreman i dopusti mu da ga potvrdi. Bez preciznog formuliranja zahtjeva, mogu postojati duge nekonstruktivne argumente kada se proizvod mora dostaviti.
Kontroverzni status
Ne postoji uvjerljiv dokaz da korištenje prilagođenih priča povećava uspjeh softverske ili razvojne produktivnosti. Ipak, vlastite priče olakšavaju potragu za smislom bez pretjeranog strukturiranja problema povezanih s uspjehom. Ograničenja priča korisnika uključuju:
Problem skaliranja.
Teško je održavati prilagođene priče napisane na malim fizičkim kartama koje je teško proširiti za velike projekte i problematične su za geografski raspoređene timove.
Nejasan, neformalan i nepotpun skup pravila.
Komunikativna vrijednost
Prilagođene priče smatraju se početkom razgovora. Budući da su neformalni, otvoreni su za mnoga tumačenja. Ukratko, oni ne sadrže sve detalje potrebne za provedbu funkcije. Stoga priče nisu prikladne za formalne sporazume ili pisanje pravnih ugovora.
Nedostatak nefunkcionalnih zahtjeva
Prilagođene priče rijetko uključuju zahtjeve izvedbe ili funkcionalne zahtjeve, tako da se nefunkcionalna ispitivanja (kao što su vremena odziva) mogu izostaviti.Mnogi konteksti koriste vlastite priče, koje su također grupirane u smislu značenja i organizacijskih razloga. Različite namjene ovise o gledištu, na primjer, s gledišta korisnika kao vlasnika proizvoda u odnosu na funkcije, ili sa stajališta tvrtke u odnosu na organizaciju zadataka.
Oznake
Dok neki predlažu korištenje epa i teme kao oznaka za bilo koju zamislivu vrstu grupiranja korisničke povijesti, vodstvo organizacije nastoji ih koristiti za snažno strukturiranje i agregiranje radnih opterećenja. Primjerice, čini se da Jira koristi hijerarhijski organizirani popis slučajeva u kojima su nazvali prvu razinu zadataka korisnika, drugi epovi (grupiranje korisničkih priča) i treću razinu "inicijative" (grupiranje epova). Međutim, inicijative nisu uvijek prisutne u razvoju upravljanja proizvodima i jednostavno dodaju još jednu razinu detalja. Jira ima "teme" (za potrebe praćenja) koje omogućuju povezivanje presjeka i elemenata grupa različitih dijelova fiksne hijerarhije. U tom korištenju, Jira mijenja značenje teme u smislu organizacije: na primjer, koliko vremena smo potrošili na razvoj teme xyz. No, druga definicija teme je skup priča, epova, funkcija itd. Za korisnika koji generira zajedničku semantičku jedinicu ili svrhu, vjerojatno ne postoji opća definicija jer postoje različiti pristupi različitim stilovima dizajna i dizajna proizvoda. U tom smislu, neki također predlažu da se ne koristibilo koje krute skupine i hijerarhije.
Epic
Velike priče ili priče nekoliko korisnika koji su vrlo blisko povezani, sabrani su kao ep. Opće objašnjenje za ep je prilagođena povijest koja je prevelika za sprint. Mnogi epovi ili priče, grupirani hijerarhijski, uglavnom su poznati iz Jira.
Karta priče korisnika: opis
Karta povijesti je grafička dvodimenzionalna vizualizacija zaostataka proizvoda. Na vrhu karte nalaze se naslovi koji grupiraju priče, koje se obično nazivaju "epovi" (velike grube korisničke priče), "teme" (zbirke povezanih korisničkih priča) ili "akcije". Određuju se usmjeravanjem korisničkog tijeka rada ili "redoslijedom kojim biste objasnili ponašanje sustava". Vertikalno ispod epskog, stvarni primjeri korisničkih karata rangirani su i rangirani po prioritetu. Prvi horizontalni red predstavlja "kostur hodanja" i ispod, koji predstavlja sve veću složenost.
Dakle, moguće je opisati čak i velike sustave bez gubitka cjelokupne slike. Recenzije o karti korisnika, napisane od strane korisnika, svedene su na interaktivnost i zabavu ove klase, što je vrlo ugodno za ljude. Tvrde prednosti takvog softvera. To, prije svega, olakšava procjenu zadataka. Primjeri korisničke priče dio su fleksibilnog pristupa koji omogućuje prebacivanje naglaska na pisanje zahtjeva za njihovu raspravu. Sve fleksibilne korisničke priče uključuju jednu ili dvije pisane rečenicei, još važnije, niz razgovora o željenoj funkcionalnosti.
Predložak
Što mogu reći o primjerima karte korisničkih priča? Prilagođene priče su kratki, jednostavni opisi funkcija, sa stajališta osobe koja želi dobiti novu priliku. To je obično korisnik ili klijent sustava. Obično slijede jednostavan predložak: Želim ga jer. To je odgovor na pitanje kako izgraditi mapu povijesti mapiranja korisničkih priča. Prilagođene priče često se pišu na karticama ili bilješkama, pohranjuju u kutiju za cipele i postavljaju na zidove ili stolove kako bi se olakšalo planiranje i raspravljanje. Kao takvi, oni uvelike pomiču naglasak na funkcije pisanja kako bi ih raspravljali. Zapravo, te su rasprave važnije od bilo kojeg pisanog teksta. A za potonje možete upotrijebiti gore navedene primjere korisničkih priča.
Prednosti
Jedna od prednosti fleksibilnih prilagođenih priča je da se mogu pisati s različitim stupnjevima detalja. Možemo napisati vlastitu priču kako bismo pokrili veliki broj funkcionalnosti. Ove velike korisničke priče obično se nazivaju ep. Evo primjera epske fleksibilne korisničke povijesti iz sigurnosne kopije proizvoda na računalo. Kao korisnik možete kopirati cijeli tvrdi disk. Budući da je ep je obično prevelik za fleksibilnu naredbu da se dovrši u jednoj iteraciji, podijeljen je na nekoliko malih korisničkih priča prije nego što se proširi. Epski prikaz, prikazan gore, može se podijeliti na desetke (ilimožda stotine
Kao napredni korisnik možete odrediti datoteke ili mape za izradu sigurnosne kopije na temelju veličine datoteke, datuma izrade i datuma promjene. Kao korisnik, osoba može odrediti mape bez sigurnosne kopije tako da sigurnosna kopija diska nije ispunjena stvarima koje nije potrebno spremiti. Kako se detalji dodaju korisničkim pričama? Detalji se mogu dodati na dva načina:
Podijelite svoju priču na nekoliko manjih.
Dodavanje zadovoljstva. "
Kada je relativno velika priča podijeljena na nekoliko malih, fleksibilnih korisničkih priča, prirodno je pretpostaviti da su dodane pojedinosti. Konačno, više je napisano.
Uvjeti zadovoljstva samo test na visokoj razini koji će vrijediti nakon dovršetka fleksibilnog korisnika povijesti. Razmotrimo sljedeće kao još jedan primjer fleksibilnog korisnika povijesti:
Kao potpredsjednik marketinga, želim odabrati sezonu odmora koja će se koristiti za procjenu učinkovitosti prošlosti nedostaci reklamnih kampanja tako da mogu identificirati profitabilne.
U ovom primjeru povijesti korisnika, možete dodati detalje dodavanjem sljedećih uvjeta zadovoljstva:
Provjerite radi li se o velikim maloprodajnim praznicima: Božić, Uskrs, Predsjednički dan, Majčin dan, Dan očeva, Dan rada, Nova godina.
Podrška za praznike koji obuhvaćaju dvije kalendarske godine (nijedna ne pokriva tri).
Godišnja doba odmora mogu se postaviti od jednog odmora do drugog (na primjer, Dan zahvalnostiprije Božića)
Spa-sezone mogu se postaviti nekoliko dana prije blagdana.
Svatko može pisati povijest korisnika. Vlasnik proizvoda mora se uvjeriti da ima mnogo nedovršenih korisničkih priča, ali to ne znači da su oni autor vlasnika proizvoda. Za dobar fleksibilan projekt trebali biste očekivati da svaki korisnik ima primjere korisničkih priča. Također, imajte na umu da je osoba koja piše povijest korisnika daleko manje važna od osobe koja sudjeluje u raspravi.
Vrijednosti za projekte
Prilagođene priče napisane su kroz fleksibilan projekt. Obično se na početku održava radionica pisanja. Svi u timu sudjeluju u kreiranju dnevnika čekanja proizvoda koji u potpunosti opisuje funkcionalnost koja će biti dodana tijekom projekta ili u roku od tri do šest mjeseci od objavljivanja. Primjeri za to su u velikoj zbirci Primjer karte za korisničke priče. Neke od tih fleksibilnih korisničkih priča nesumnjivo će biti epske. Kasnije će se epovi proširiti na manje priče, koje će se lakše uklopiti u jednu iteraciju. Osim toga, nove se priče mogu pisati i dodavati u portfelj proizvoda u bilo koje vrijeme i bilo tko. Agilni projekti, posebno Scrum, koriste pozadinu proizvoda, koja je prioritetni popis funkcionalnosti koje će se razvijati u proizvodu ili usluzi. Unatoč činjenici da elementi rada u tijeku mogu biti po želji tima, njihove su priče postale bolje.i najpopularniji oblik rada u tijeku.
Dok se zaostajanje proizvoda može promatrati kao zamjena zahtjevima dokumenta tradicionalnog projekta, važno je zapamtiti da je pisani dio fleksibilnog korisnika povijesti ("Kao što želim korisniku") nepotpun za raspravu o toj priči. Tako je napisano u Priručniku za mapiranje američkih korisničkih priča i kako ga koristiti. Često je bolje uzeti u obzir pisani dio kao pokazivač na stvarni zahtjev. Prilagođene priče mogu ukazivati na dijagram koji prikazuje tijek rada, proračunsku tablicu koja pokazuje kako izvesti izračun ili bilo koji drugi artefakt koji vlasnik proizvoda ili tim želi.
Dok se zaostajanje proizvoda može promatrati kao zamjena zahtjevima dokumenta tradicionalnog projekta, važno je zapamtiti da je pisani dio fleksibilnog korisnika povijesti ("Kao što želim korisniku") nepotpun za raspravu o toj priči. Tako je napisano u Priručniku za mapiranje američkih korisničkih priča i kako ga koristiti. Često je bolje uzeti u obzir pisani dio kao pokazivač na stvarni zahtjev. Prilagođene priče mogu ukazivati na dijagram koji prikazuje tijek rada, proračunsku tablicu koja pokazuje kako izvesti izračun ili bilo koji drugi artefakt koji vlasnik proizvoda ili tim želi.
