Kako napisati dobre agilne korisničke priče

Jedan od prvih koraka u isporuci kvalitetnog proizvoda je pisanje dobrih korisničkih priča. U ovom postu opisujemo kako pisati dobre korisničke priče i što treba uključiti.

Korisnička priča mjesto je za hvatanje funkcionalnosti proizvoda, a kao što i samo ime govori, korisničke priče opisuju kako će kupac ili korisnik koristiti proizvod.

Korisnička priča predstavlja mali dio funkcionalnosti koji ima poslovnu vrijednost koju tim može pružiti u sprintu. Razlika između korisničke priče i tradicionalnog dokumenta sa zahtjevima je razina detalja.

Dokumenti sa zahtjevima obično sadrže puno teksta i vrlo su detaljni, dok se korisničke priče uglavnom temelje na razgovorima.

Strukturu korisničke priče možemo razbiti na sljedeći način:

  • Kratki opis potrebe
  • Razgovori koji se događaju tijekom dotjerivanja zaostalih predmeta i planiranja sprinta kako bi se učvrstili detalji
  • Testovi prihvaćanja koji potvrđuju zadovoljavajući završetak priče

Pri pisanju korisničkih priča važno je imati na umu da su napisane iz perspektive korisnika koji će u konačnici koristiti proizvod, stoga je važno da prilikom pisanja korisničkih priča jasno odredimo tko je taj korisnik.



Kako napisati dobre korisničke priče

U pravilu, dobra korisnička priča trebala bi se pridržavati kratice INVEST:

Ja neovisno - korisničke priče ne bi trebale ovisiti jedna o drugoj kako bi se mogle razvijati u bilo kojem redoslijedu.

N egotiable - izbjegavajte previše detalja; neka budu fleksibilni kako bi tim mogao prilagoditi koliki dio priče treba implementirati.

V dostupno - priča bi trebala pružiti neku vrijednost svojim korisnicima.

JE stimable - tim mora biti u stanju procijeniti priču.

S trgovački centar - korisničke priče trebale bi biti dovoljno male da stanu u sprint; velike je priče teško procijeniti i planirati.

T estable - osigurati da se ono što se razvija može provjeriti i testirati na odgovarajući način.

Koji se format koristi za pisanje korisničkih priča?

Korisničke priče uglavnom imaju sljedeći format:

_Kao što, želim to učiniti.

Primjer: Kao a kupac od abc.com, želim prijaviti se funkcionalnost tako da mogu pristupiti mojim podacima o računu na mreži .

Kao što je ranije spomenuto, obratite posebnu pozornost na to tko je korisnik proizvoda i izbjegavajte generičku ulogu 'Korisnika'. Ako ne znate tko su korisnici i kupci i zašto bi željeli koristiti proizvod, tada biste trebali ne napiši bilo koje korisničke priče.

Pripovijest

  • Prvi dio korisničke priče je Pripovijest. 2-3 rečenice koje se koriste za opis namjere priče. To je samo sažetak namjere.

Razgovori

  • Najvažniji aspekt korisničke priče su razgovori koji bi se trebali kontinuirano odvijati između razvojnog tima, kupca, vlasnika proizvoda i ostalih dionika kako bi se učvrstili detalji korisničke priče.

Kriteriji prihvatljivosti

  • Kriteriji prihvaćanja predstavljaju uvjete zadovoljstva koji se zapisuju kao scenariji, obično u formatu Gherkin (dato, kada, tada). Kriteriji prihvaćanja također daju definiciju Gotovo za priču.

Tko bi trebao pisati korisničke priče?

U većini slučajeva korisničke priče piše a Vlasnik proizvoda ili Poslovni analitičar i prioritet u zaostatku proizvoda. Međutim, to ne znači da je samo vlasnik proizvoda odgovoran za pisanje korisničkih priča. U stvari, bilo koji član tima može pisati korisničke priče, ali odgovornost vlasnika proizvoda je osigurati da postoji zaostatak korisničkih priča koji su prioritet.

Ono što je važno jesu korisničke priče ne bi trebao biti tretirani kao dokument sa zahtjevima koji će se kad se napišu predati razvojnom timu na provedbu.

Priče korisnika treba gledati kao sredstvo za poticanje razgovora između vlasnika proizvoda i razvojnog tima, pa ih stoga treba pisati u suradnji tijekom sesija dotjerivanja zaostalih proizvoda.

Prednost uključivanja razvojnog tima u pisanje korisničkih priča je ta što se, ako postoje neka tehnička ograničenja, mogu istaknuti unaprijed. Ispitivači mogu posebno dodati vrijednost u stvaranju učinkovitih kriterija prihvaćanja i unaprijed planirati što i kako treba testirati.

Koliko detaljne trebaju biti korisničke priče?

Korisničke priče usredotočene su na vrijednost kupca.

Osnovna razlika između korisničkih priča i ostalih oblika specifikacije zahtjeva je razina detalja. Korisnička priča je metafora posla koji se obavlja, a ne cjelovit opis djela. Stvarni posao koji se radi razotkriva se suradnjom koja se vrti oko korisničke priče kako razvoj sustava napreduje.

Ako opis postane predugačak (više od onoga što stane na indeksnu karticu), trebali biste ponovno posjetiti korisničku priču. Vjerojatno pokušavate uključiti previše detalja.

Ne zaboravite da je svrha korisničke priče poticanje suradnje. Nije namijenjen dokumentiranju svakog aspekta rada, kao što je to obično slučaj u tradicionalnim izjavama o zahtjevima.

Štoviše, previše podataka u opisu može dovesti do toga da nedostaju informacije u kriterijima prihvaćanja.

Prije nego što pristane raditi na priči, tim mora razumjeti kriterije prihvaćanja. To je neophodno za poznavanje onoga što treba učiniti kako bi se zadovoljila korisnička priča. Kriteriji prihvaćanja trebali bi biti dovoljno detaljni da definiraju kada je korisnička priča zadovoljna, ali ne toliko detaljni da ukida suradnju.

Uobičajene pogreške pri pisanju korisničkih priča


  • Previše formalno ili previše detalja. Vlasnici proizvoda s dobrom namjerom često pokušavaju napisati izuzetno detaljne korisničke priče. Ako tim pri planiranju iteracije vidi priču koja izgleda kao dokument sa zahtjevima IEEE-a, često pretpostavljaju da su svi detalji tamo i preskočit će detaljan razgovor.


  • Pisanje korisničkih priča za tehničke zadatke. Velik dio snage Agile dolazi od toga da radni prirast softvera bude na kraju svake iteracije. Ako su vaše priče zapravo samo tehnički zadaci, na kraju svake iteracije često ne završite s radnim softverom i gubite fleksibilnost u određivanju prioriteta.


  • Preskakanje razgovora. Priče su namjerno nejasne prije planiranja ponavljanja. Ako preskočite razgovor o kriterijima prihvaćanja, riskirat ćete u pogrešnom smjeru, propustiti nedostatke slučajeva ili previdjeti potrebe kupaca.

Imate li savjete koji se mogu dodati gornjim informacijama za pisanje dobrih korisničkih priča? Slobodno ih stavljajte u komentare.