Kako pisati gibčne uporabniške zgodbe: 7 smernic

V bistvu so agilne zgodbe uporabnikov kratka, enostavna orodja za dokumentiranje enega samega dejanja ali namere, ki jo želi ciljni uporabnik za dosego cilja. Najpreprostejše uporabniške zgodbe imajo obliko »Kot a tip uporabnika ali vloga, Hočem dejanje ali namentako da razlog ali korist«, Ki odgovarja na vsaj tri preprosta vprašanja o tem, kdo, kaj in zakaj je zgodba v čakalni vrsti.

Ko ekipe dozorijo in organizacije uporabljajo gibčnost v več skupinah in pobudah, gibčne uporabniške zgodbe pogosto dobijo veliko več opredelitev in struktur, da se zagotovi skupno razumevanje namere in osnovnih zahtev.

Začetek pisanja gibčnih uporabniških zgodb

Obstaja veliko virov za pomoč lastnikom novih izdelkov, poslovnim analitikom, mojstrom scrumov in tehničnim vodičem za razumevanje osnov pisanja uporabniških zgodb. Nekatera mesta za začetek vključujejo članke iz Atlassian, FreeCodeCamp, Agile Modeling in teh 200 primerov uporabniških zgodb. Eden bolj popolnih zapisov je v najboljši agilni uporabniški zgodbi Alexandra Cowana. Obstajajo knjige o pisanju zgodb, tudi Mapiranje uporabniške zgodbeavtorja Jeff Paton in Peter Economy in Uporabljene zgodbe uporabnikovavtor Mike Cohn. Udeležite se lahko tudi tečajev pisanja zgodb pri Udemy, Learning Tree, VersionOne in Lynda.

Eno temeljnih načel, ki jih je najprej delil Bill Wake, je: vlagajte v dobre zgodbe. Naložitepomeni „neodvisen, dogovoren, dragocen, ocenljiv, majhen in preizkušen“, ki je dober kontrolni seznam za gibčne pisce zgodb. Članek, ki razlaga, kako se prijaviti, je "Vodnik agilnega vodje za pisanje uporabniških zgodb" vlagatinačel.

Osnove so razmeroma enostavne, vendar pogosto slišim in sem priča odklonom med deležniki, lastniki izdelkov, razvijalci in preizkuševalci glede kakovosti zahtev ali tega, ali je zgodba resnično narejena. Včasih obstajajo nasprotujoča si stališča glede zahtevane ravni podrobnosti, kje se uvrstiti v tehnične zahteve in katere artefakte je treba ustvariti z uporabniškimi zgodbami.

Ob upoštevanju teh vprašanj je tu sedem izjemno osnovnih navodil za pisanje gibčnih uporabniških zgodb.

1. Napišite občinstvo za občinstvo, ki jih bo uporabljalo

Pred pisanjem zgodb ne pozabite, da so zgodbe namenjene branju in razumevanju ljudi, ki sodelujejo v razvojnem procesu z različnimi potrebami in odgovornostmi. Pisci zgodb in sodelavci bi morali imeti občinstvo v mislih in pripraviti zgodbe, da bi zadovoljili skupne potrebe:

• Zgodbe morda ne pišejo lastniki izdelkov, zlasti če vaša organizacija to funkcijo dodeli poslovnim analitikom ali če je v pisanje zgodb vpletenih več ljudi. Lastniki izdelkov želijo zagotoviti, da zgodba v celoti zajema potrebe in namere uporabnikov. Prebrati bi morali podrobna merila sprejemljivosti, ni pa nujno, da jih zataknejo podrobnosti o tehnični izvedbi. Lastniki izdelkov bi morali tudi razumeti, kako je zgodba usklajena s širšo sliko, zato se morajo aktivno zanimati, kako so definirani epi in značilnosti ter kako so jim zgodbe dodeljene.
• Zainteresirane strani ne bodo prebrale podrobnosti zgodbe, ampak se bodo podrobneje seznanile z epiki in prebrale povzetek zgodbe. Če imate veliko zainteresiranih strani, razmislite o uporabi opisne oblike povzetkov in premikanju gumba »Kot a tip uporabnika ali vloga"Opis na začetek opisa uporabniške zgodbe.
• Tehnični voditelji so pogosto prva oseba iz ekipe, ki pregleda zgodbe in preuči zahteve, da ugotovi, ali je zgodba prevelika in ali jo je treba razdeliti na več zgodb, ali pa mora zgodba potrebovati nekaj predhodnega tehničnega dela, da se določi najboljši rešitev.
• Prejemnik je posameznik, ki je odgovoren za pregled podrobnosti in poročanje o napredku na dnevnih sestankih standup. Prejemniki bi morali pregledati zgodbe o odvisnostih, ki bi lahko postale bloki med šprintom.
• Člani ekipe pogosto pregledajo vse zgodbe, da bi razumeli njihove dodeljene zgodbe v kontekstu drugih zgodb, dodeljenih šprintu.
• Preizkuševalci ugotovijo, ali obstajajo vrzeli ali tveganja, ki niso opredeljena v merilih za sprejem, in nato preučijo, kako jih je najbolje uporabiti v avtomatiziranih preskusnih okvirih.
• Analitik ekipe, ki je lahko vodja programa ali član pisarne za upravljanje projektov, želi, da so zgodbe v celoti označene in kategorizirane, tako da se lahko iz zaostanka izvlečejo pomembne meritve.

2. Začnite z mislijo na uporabnika

Čeprav lahko agilne uporabniške zgodbe zahtevajo veliko podrobnosti, je zelo pomembno, da začnete z mislijo na uporabnika. Zgodba bi morala biti odločilna kajdejanje ali namen, ki ga želi uporabnik izvesti in zakajto obravnava potrebo, temeljno vrednoto ali cilj, ki izhaja iz izkušenj.

Za bolj zapletene aplikacije je definiranje različnih uporabniških oseb, ki ponazarjajo potrebe, vrednote in vzorce uporabe različnih vrst uporabnikov, pomembna disciplina in lahko izboljša pisanje zgodb. V "10 nasvetih za pisanje dobrih uporabniških zgodb" Roman Pichler predlaga, da "vam osebni cilji pomagajo odkriti prave zgodbe. Vprašajte se, kakšno funkcionalnost bi moral imeti izdelek, da izpolni cilje oseb. " Uporaba oseb za krepitev uporabniških ciljev ponuja bogatejši pomen zakajzgodba je pomembna in pomaga pri določanju zaostankov.

3. Odgovorite, zakaj je zgodba pomembna

Razumevanje, dokumentiranje in razpravljanje o potrebah uporabnika ali ciljih uporabnikove osebnosti je le ena dimenzija zakajlastnik izdelka daje prednost zgodbam. Zgodba bi morala zagotavljati tudi poslovno vrednost, nekaj, kar je težko količinsko opredeliti, lahko pa je kvalificiranona ravni zgodbe, celovečerca, epa ali izdaje.

Odgovarjam zakajje lahko pomemben za razvijalce, ko so pooblaščeni, da predlagajo različne možnosti izvedbe. Funkcija, ki izboljša prijavo uporabnikov na primer, lahko na primer koristi tudi podjetju, če nova izkušnja ustvari tudi boljše podatke o strankah. Razvijalec lahko razmisli o tej dodani poslovni vrednosti in optimizira izvajanje za ta cilj, tudi če merila za sprejem zgodbe niso natančno določena glede te zahteve.

4. Določite merila sprejemljivosti brez predpisovanja rešitve

Najpomembnejša disciplina, na katero se je treba osredotočiti pri pisanju zgodb, je priprava meril za sprejem. To so pogosto označeni seznami kratkih izjav pass-or-fail, ki dokumentirajo zahteve, omejitve, meritve in pričakovanja. Ta merila sprejemljivosti se pogosto uporabljajo na več načinov:

• Tehnični vodje in ekipe jih uporabljajo za ocenjevanje zgodb glede na zapletenost in napor.
• Razvijalci možnosti izvedbe zožijo na tiste, ki izpolnjujejo merila sprejemljivosti.
• Lastniki izdelkov lahko zmanjšajo obseg ali zapletenost meril za sprejem, da spodbujajo izvedbe z nižjimi ocenami.
• Prejemnik vstopi sporoča bloke ali težave, ki izpolnjujejo težka merila.
• Inženirji za zagotavljanje kakovosti uporabljajo merila sprejemljivosti za razvoj avtomatiziranih testov.
• Lastnik izdelka med agilnim predstavitvijo pregleda ključne kriterije, da bi zagotovil zgodbo Končano.

Pisanje kriterijev sprejemljivosti ni nepomembno. Merila sprejemljivosti za merila sprejemljivosti izpostavljajo nekatera vprašanja, na primer zagotavljanje preveč meril, določanje preveč nejasnih meril ali dokumentiranje zapletenih meril, ki jih ni mogoče enostavno preveriti. Nekateri pisci uporabljajo predloge meril za sprejem, ki opredeljujejo strukturo za kratka, atomska in preverljiva merila.

5. Z zgodbami določite, kaj in zakaj; opredeliti naloge, kako jih izvesti

Ena izmed kritičnih napak, ki se mi zdijo ekipe pri pisanju zgodb, je biti natančen in natančen glede izvedbe. Te slabo napisane zgodbe vlagajo veliko truda v opisovanje kakoizvajati pogosto na račun opisovanja kajuporabnik potrebuje, zakajobravnava njihove cilje in kjevodi poslovno vrednost.

Obstaja nekaj razlogov, da se to lahko zgodi.

Neizkušeni lastniki izdelkov lahko z zgodbami oblikujejo svoje izvedbene vizije. Z drugimi besedami, morda preveč določajo uporabniško zasnovo in funkcionalne izvedbe, namesto da bi delili ciljno uporabniško izkušnjo in koristi. Nekateri lastniki izdelkov zamenjajo svojo konceptualizacijo tega, kako kaj mordadelo (postopek, s katerim razumejo zahteve) s tem, kako to bi moralidelo, pri čemer je primer notranje izvedbe nenamerno spremenil v zunanjo specifikacijo izvedbe.

Drugi lastniki izdelkov lahko presežejo svoje meje, tako da ekipo prosijo, naj mi "to zgradi." To je eno izmed mojih 20 slabih vedenj lastnikov izdelkov, za katere imam lastnikom izdelkov priporočila za sodelovanje s skupino okoli rešitev.

Drugi razlog, da lahko zgodbe postanejo natrpane s podrobnostmi o izvedbi, je, da nekatere ekipe in tehnološki voditelji želijo to stopnjo podrobnosti. Novo oblikovane tehnične skupine, ki si prizadevajo za izboljšanje obstoječih aplikacij, bodo morda želele to stopnjo podrobnosti, dokler ne bodo bolje razumele, kako aplikacija deluje, in popolnoma razumele potrebe uporabnikov. Nekatere porazdeljene ekipe, ki sodelujejo z zunanjimi razvijalci ali samostojnimi podjetji, bodo morda želele dokumentirati podrobnosti izvedbe, da bodo člani razumeli svoje odgovornosti.

Za takšne ekipe je najbolje, da se kot naloge, povezane z zgodbo, povežejo z izvedbenimi diagrami in dokumentirajo, kdo kaj in kako počne. Večina gibčnih orodij za upravljanje omogoča naloge ali podopravila, ta raven podrobnosti pa je običajno ločena od telesa zgodbe. Diagram v tej objavi dobro ilustrira to pomembno načelo uporabe agilnih zgodb za razčlenitev uporabniških izkušenj in poslovnih procesov ter dodajanje nalog za opredelitev izvajanja posameznih del.

6. Označite svoje zgodbe za spodbujanje analitike in vadite izboljšave

Ko so zgodbe napisane, obdelane in dokončane, številne ekipe poskušajo zajeti metrike in izvesti analitiko, ki lahko spodbudi izboljšanje procesov ali se uporablja za oblikovanje poslovnih primerov za dodatne naložbe.

Tu je nekaj primerov:

• Zgodbe označite kot tehnični dolg za količinsko določitev velikosti dolga, odstotek hitrosti ekipe, ki se je uporabljala za njegovo reševanje, in skupni dolg, izpolnjen z vsako objavo.
• Opredelite funkcionalne in tehnične zgodbe, ki spodbujajo eksperimentiranje in inovacije, nato poročajte o tem, kje to vpliva na poslovanje.
• Če vaša ekipa ocenjuje gibčne uporabniške zgodbe, prosite ekipo, naj na koncu sprinta označi zgodbe, da sporoči, ali so bile precenjene ali podcenjene, da bi izboljšali natančnost ocen.
• Uporabite nalepke, komponente in polja po meri za lažje iskanje zaostankov glede zgodovinskih razumevanj ali meritev. Na primer, če vemo, katere zgodbe so vplivale na API-je ali katere zahteve so privedle do zadnjih funkcionalnih izboljšav na določenem področju aplikacije, lahko zgodbe označimo na funkcionalne in tehnične komponente.
• Zgodbe o označevanju zbirajte ali obdelujte občutljive podatke, kot so osebno določljivi podatki (PII), transakcije e-trgovine ali industrijsko regulirani podatki, kot so podatki HIPAA, da omogočite preglede varnosti in skladnosti.
• Pošljite povratne informacije lastniku izdelka in skupini. Poleg označevanja zgodbe Končano, lahko lastnik izdelka skupini posreduje tudi povratne informacije, na primer potrditev a odlično opravljeno. Podobno lahko skupina lastniku izdelka posreduje povratne informacije o splošni kakovosti in razložljivosti uporabniške zgodbe.

7. Opredelite gibčne predloge zgodb in vodnike po slogu

Večje organizacije, ki sodelujejo z več agilnimi skupinami in lastniki izdelkov, bodo morda želele pripraviti standarde in vodnike po slogu za pisanje zgodb. Doslednost pomaga lastnikom novih izdelkov, da se hitreje naučijo pisanja, in tudi izboljša učinkovitost članov pri porabi informacij.

Drug razlog za oblikovanje predlog zgodb je, da se različne vrste izdelkov in aplikacij podrejajo različnim izrazom in artefaktom uporabniške zgodbe. Nekaj ​​primerov:

• Zgodbe o poslovnih procesih lahko zahtevajo povezave do diagramov poteka dela ter določajo tudi vloge in dovoljenja.
• Zgodbe o aplikacijah, namenjene strankam, bi morale imeti povezave do žičnih okvirjev in vključevati merila uspešnosti.
• Zgodbe API morajo dokumentirati pričakovane vzorce uporabe in meritve.
• Zgodbe o poslovni inteligenci in vizualizaciji podatkov bi morale vsebovati smernice o tem, katera polja in informacije so potrebne za zahtevano analizo.

Predloge pomagajo povezati komunikacijo med skupinami in lastniki izdelkov o tem, na kaj se je treba osredotočiti pri pisanju gibčnih zgodb.

In ni to bistvo gibčnih zgodb? Agilne prakse pisanja zgodb, smernice in načela pomagajo skupinam, da vedo, kaj je pomembno za uporabnike in podjetje, preden se odločijo, kako to izvesti.