Iš esmės judrios vartotojo istorijos yra trumpos, paprastos priemonės, skirtos dokumentuoti vieną tikslinio vartotojo norimą veiksmą ar ketinimą tikslui pasiekti. Paprasčiausių vartotojų istorijų formatas yra „Kaip a vartotojo tipas ar vaidmuo, Aš noriu veiksmas ar tyčiataip kad priežastis ar nauda“, Kuris atsako į bent tris paprastus klausimus, kas, ką ir kodėl istorija yra atsilikusių asmenų eilėje.
Kai komandos subręsta, o organizacijos naudojasi judriomis kelioms komandoms ir iniciatyvoms, judrios vartotojų istorijos dažnai įgauna daug daugiau apibrėžimo ir struktūros, kad būtų užtikrintas bendras supratimas apie ketinimus ir pagrindinius reikalavimus.
Pradžia rašyti judrius vartotojo pasakojimus
Yra daugybė išteklių, padėsiančių naujų produktų savininkams, verslo analitikams, „scrum“ meistrams ir techniniams vadovams suprasti vartotojo istorijų rašymo pagrindus. Keletas vietų, į kurias reikia pradėti, yra straipsniai iš „Atlassian“, „FreeCodeCamp“, „Agile Modeling“ ir šie 200 vartotojo istorijos pavyzdžių. Vienas iš išsamesnių rašymų yra geriausiame Aleksandro Cowano judrioje vartotojo istorijoje. Yra knygų apie istorijų rašymą, įskaitant Vartotojo istorijos žemėlapispateikė Jeffas Patonas ir Peteris Economy bei Taikomos naudotojų istorijospateikė Mike'as Cohnas. Taip pat galite išklausyti istorijų rašymo kursus iš „Udemy“, „Learning Tree“, „VersionOne“ ir „Lynda“.
Vienas pagrindinių principų, kurį pirmiausia pasidalijo Billas Wake'as, yra investuok į geras istorijas. Investuokreiškia „nepriklausomą, derėtiną, vertingą, įvertinamą, mažą ir išbandomą“, kuris yra geras kontrolinis sąrašas judrių istorijų rašytojams. „Vikrus lyderio vartotojo istorijų rašymo vadovas“ yra vienas straipsnis, kuriame paaiškinta, kaip kreiptis investuokprincipus.
Pagrindai yra gana lengvi, tačiau dažnai girdžiu ir stebiu, kaip tarp suinteresuotųjų šalių, produktų savininkų, kūrėjų ir bandytojų neatsiranda reikalavimų kokybė ar ar istorija tikrai sukurta. Kartais yra prieštaringų nuomonių dėl reikalaujamo detalumo lygio, kur derėti prie techninių reikalavimų ir kokie artefaktai turėtų būti sukurti su vartotojo istorijomis.
Turint omenyje šiuos klausimus, pateikiame septynias pagrindines gaires, kaip rašyti judrius vartotojo pasakojimus.
1. Parašykite istorijas auditorijoms, kurios jas naudos
Prieš rašydami istorijas, nepamirškite, kad pasakojimai skirti skaityti ir suprasti žmonėms, dalyvaujantiems kūrimo procese, turintiems skirtingų poreikių ir atsakomybės. Istorijų rašytojai ir bendraautoriai turėtų atsižvelgti į auditoriją ir rengti istorijas, kad patenkintų kolektyvinius poreikius:
- Produktų savininkai gali būti ne tie, kurie rašo istorijas, ypač jei jūsų organizacija šią funkciją paveda verslo analitikams arba jei istoriją rašo keli žmonės. Produktų savininkai nori įsitikinti, kad istorija visiškai atspindi vartotojo poreikius ir ketinimus. Jie turėtų perskaityti išsamius priėmimo kriterijus, tačiau nebūtinai nori, kad jiems nebūtų pateikiama techninio įgyvendinimo informacija. Produktų savininkai taip pat turėtų suprasti, kaip istorija sutapatinta su didesniu vaizdu, todėl jie turi aktyviai domėtis, kaip apibrėžiami epai ir ypatybės bei kaip jiems priskiriamos istorijos.
- Suinteresuotosios šalys neskaitys istorijos detalių, bet gilinsis iš epų ir perskaitys istorijos santrauką. Jei turite daug suinteresuotųjų šalių, apsvarstykite galimybę naudoti aprašomąjį santraukų formatą ir perkelti „Kaip a vartotojo tipas ar vaidmuo“Aprašymas iki vartotojo istorijos aprašymo pradžios.
- Techniniai vadovai dažnai yra pirmasis komandos narys, kuris peržiūri istorijas, ir jie išnagrinės reikalavimus, kad sužinotų, ar istorija yra per didelė ir turėtų būti padalinta į kelias istorijas, ar išsiaiškins, ar istorijai reikia išankstinio techninio darbo, kad būtų galima nustatyti geriausią sprendimas.
- Paskyrėjas yra asmuo, atsakingas už išsamią informaciją ir pažangos ataskaitų pateikimą kasdieniuose atsarginiuose susitikimuose. Paskirtieji turėtų peržiūrėti istorijas dėl priklausomybių, kurios sprinto metu gali tapti blokais.
- Komandos nariai dažnai peržiūri visas istorijas, kad suprastų jiems paskirtas istorijas kitų sprintui priskirtų istorijų kontekste.
- Testuotojai nustato, ar yra spragų ar pavojų, nenurodytų priėmimo kriterijuose, ir tada apsvarsto, kaip juos geriausia įgyvendinti automatizuotose testavimo sistemose.
- Komandos analitikas, kuris gali būti programos vadovas ar projektų valdymo biuro narys, nori, kad istorijos būtų visiškai paženklintos ir suskirstytos į kategorijas, kad iš atsilikimo būtų galima išgauti prasmingą metriką.
2. Pradėkite galvodami apie vartotoją
Nors judrioms vartotojų istorijoms gali prireikti daug informacijos, labai svarbu pradėti galvoti apie vartotoją. Istorija turėtų būti apibrėžianti kąveiksmas ar ketinimas, kurį vartotojas nori atlikti, ir kodėltai nukreipta į poreikį, pagrindinę vertę ar tikslą, gautą iš patirties.
Sudėtingesnėms programoms nustatyti skirtingas vartotojų asmenybes, iliustruojančias skirtingų tipų vartotojų poreikius, vertybes ir naudojimo modelius, yra svarbi disciplina ir gali pagerinti pasakojimų rašymą. „10 patarimų, kaip rašyti geras vartotojų istorijas“ Romanas Pichleris siūlo, kad „asmens tikslai padės atrasti tinkamas istorijas. Paklauskite savęs, kokį funkcionalumą produktas turėtų suteikti, kad pasiektų asmenybių tikslus “. Naudojant asmenis, siekiant sustiprinti vartotojo tikslus, suteikiama turtingesnė prasmė kodėlistorija yra svarbi ir padeda nustatyti pirmenybę atsilikimui.
3. Atsakykite, kodėl istorija svarbi
Vartotojo poreikių ar vartotojo asmeninių tikslų supratimas, dokumentavimas ir aptarimas yra tik vienas aspektas kodėlprodukto savininkas teikia pirmenybę istorijoms. Istorija taip pat turėtų suteikti verslo vertę, o tai sunku įvertinti, bet gali būti kvalifikuotinasistorijos, vaidmens, epo ar leidimo lygiu.
Atsakymas kodėlgali būti svarbu kūrėjams, kai jie turi teisę siūlyti įvairias diegimo parinktis. Pvz., Funkcija, pagerinanti vartotojų prisijungimo patirtį, taip pat gali būti naudinga verslui, jei naujoji patirtis taip pat sukuria geresnius klientų duomenis. Kūrėjas gali apmąstyti šią pridėtinę verslo vertę ir optimizuoti šio tikslo įgyvendinimą, net jei pasakojimo priėmimo kriterijai nėra konkretūs dėl šio reikalavimo.
4. Apibrėžkite priėmimo kriterijus nenurodydami sprendimo
Svarbiausia disciplina, į kurią reikia atkreipti dėmesį rašant istoriją, yra rengiant priėmimo kriterijus. Tai dažnai yra ženklelių sąrašas, kuriame pateikiami trumpi „perduoti arba nepavykti“ teiginiai, kuriuose nurodomi reikalavimai, apribojimai, metrika ir lūkesčiai. Šie priėmimo kriterijai dažnai naudojami keliais būdais:
- Techniniai vadovai ir komandos juos naudoja, norėdami įvertinti istorijos taškus, atsižvelgdami į sudėtingumą ir pastangas.
- Kūrėjai susiaurina įgyvendinimo galimybes, kad atitiktų priėmimo kriterijus.
- Produktų savininkai gali sumažinti priimtinumo kriterijų taikymo sritį arba sudėtingumą, kad paskatintų diegimą su mažesniais įvertinimais.
- Asignavimų metu perėmėjas perduoda blokus ar klausimus, atitinkančius sudėtingus kriterijus.
- Kokybės užtikrinimo inžinieriai naudoja priėmimo kriterijus kurdami automatinius testus.
- Produkto savininkas peržiūri pagrindinius kriterijus per greitą demonstracinę versiją, kad įsitikintų, jog istorija yra padaryta.
Parašyti priėmimo kriterijus nėra trivialu. Priėmimo kriterijų priėmimo kriterijai išryškina kai kuriuos klausimus, pavyzdžiui, pateikia per daug kriterijų, nustato pernelyg neaiškius kriterijus arba dokumentuoja sudėtingus kriterijus, kurių negalima lengvai patikrinti. Kai kurie rašytojai naudoja priėmimo kriterijų šablonus, apibrėžiančius trumpų, atomų ir testuojamų kriterijų struktūrą.
5. Naudokite istorijas, kad apibrėžtumėte kas ir kodėl; apibrėžti užduotis, kaip įgyvendinti
Viena iš kritinių klaidų, kurią, matau, daro komandos, rašydamos istorijas, yra išsamios ir konkrečios apie įgyvendinimą. Šios prastai parašytos istorijos labai stengiasi aprašyti kaipįgyvendinti dažnai aprašymo sąskaita kąvartotojo poreikius, kodėljuo siekiama jų tikslų ir kurtai lemia verslo vertę.
Tai gali nutikti dėl kelių priežasčių.
Nepatyrę produktų savininkai gali naudoti istorijas, norėdami nupiešti jų įgyvendinimo vizijas. Kitaip tariant, jie gali pernelyg nurodyti vartotojo dizainą ir funkcinius įgyvendinimus, užuot dalinęsi tikslinio vartotojo patirtimi ir pranašumais. Kai kurie produktų savininkai painioja savo konceptualizavimą, kaip kažkas galidarbas (procesas, kurio metu jie supranta reikalavimus), kaip jis turėtųdarbas, netyčia paverčiant vidinį diegimo pavyzdį į išorinio diegimo specifikaciją.
Kiti produktų savininkai gali peržengti ribas, paprašydami komandos „pastatyti man tai“. Tai yra vienas iš mano 20 blogo produktų savininkų elgesio, dėl kurio turiu rekomendacijų produktų savininkams bendradarbiauti su sprendimų komanda.
Kita priežastis, dėl kurios istorijos gali būti perpildytos įgyvendinimo detalėmis, yra ta, kad kai kurios komandos ir technologijų lyderiai nori tokio išsamumo. Naujai suformuotos techninės komandos, siekiančios tobulinti esamas programas, gali pageidauti tokio išsamumo lygio, kol jos geriau supranta, kaip veikia programa, ir visiškai supras vartotojų poreikius. Kai kurios paskirstytos komandos, dirbančios su ofšoriniais kūrėjais ar laisvai samdomais darbuotojais, taip pat gali norėti dokumentuoti išsamią įgyvendinimo informaciją, kad šie nariai suprastų savo atsakomybę.
Geriausiai tokioms komandoms reikia susieti su įgyvendinimo schemomis ir dokumentuoti, kas ir kaip daro užduotis, susijusias su istorija. Daugelis judrių valdymo įrankių leidžia atlikti užduotis ar užduotis, o šis išsamumo lygis paprastai yra atskiriamas nuo istorijos pagrindo. Šiame įraše pateikiama schema yra geras darbas, iliustruojantis šį svarbų judrių istorijų naudojimo principą, siekiant suskaidyti vartotojo patirtį ir verslo procesus, ir pridėti užduotis, apibrėžiančias įgyvendinimą atskiriems darbams.
6. Pažymėkite savo istorijas, kad paskatintumėte analizę ir praktiką
Parašius, padirbėjus ir užbaigus istorijas, daugelis komandų siekia surinkti metriką ir atlikti analizę, kuri galėtų paskatinti procesą tobulinti arba panaudoti kuriant verslo atvejus, kad būtų galima papildomai investuoti.
Štai keletas pavyzdžių:
- Pažymėkite istorijas kaip techninę skolą, kad apskaičiuotumėte skolos dydį, komandos greičio procentą, naudojamą jai spręsti, ir bendrą skolą, įvykdytą kiekvieną kartą išleidus.
- Apibrėžkite funkcines ir technines istorijas, kad paskatintumėte eksperimentus ir naujoves, tada praneškite apie tai, kur tai daro įtaką verslui.
- Jei jūsų komanda vertina judrius vartotojų pasakojimus, paprašykite komandos žymėti istorijas sprinto pabaigoje, kad parodytumėte, ar jos pervertino, ar nepakankamai įvertino, kad pagerintų įvertinimų tikslumą.
- Naudokite etiketes, komponentus ir pasirinktinius laukus, kad galėtumėte ieškoti atsilikimo istorinių supratimų ar metrikos. Pavyzdžiui, žinoti, kokios istorijos paveikė API arba kokie reikalavimai lėmė paskutinius funkcinius patobulinimus konkrečioje programos srityje, galima padaryti, kai istorijos žymimos prie funkcinių ir techninių komponentų.
- Pažymėkite istorijas, kuriose renkama ar apdorojama neskelbtina informacija, pvz., Asmens identifikavimo informacija (AII), el. Prekybos operacijos arba pramonės reguliuojami duomenys, pvz., HIPAA duomenys, kad būtų galima atlikti saugumo ir atitikties peržiūrą.
- Pateikite atsiliepimą produkto savininkui ir komandai. Už istorijos žymėjimo padarytaprodukto savininkas taip pat galėtų pateikti atsiliepimų komandai, pavyzdžiui, patvirtinti puikus darbas. Panašiai komanda gali pateikti produkto savininkui atsiliepimus apie bendrą vartotojo istorijos kokybę ir aiškinamumą.
7. Apibrėžkite judrių pasakojimų šablonus ir stiliaus vadovus
Didesnės organizacijos, dirbančios su keliomis judriomis komandomis ir produktų savininkais, gali parengti istorijų rašymo standartus ir stiliaus vadovus. Nuoseklumas padeda naujų produktų savininkams greičiau išmokti rašymo įgūdžių, taip pat pagerina komandos narių efektyvumą vartojant informaciją.
Kita priežastis kurti šablonus yra ta, kad skirtingų tipų gaminiai ir programos tinka skirtingoms vartotojo pasakojimų išraiškoms ir artefaktams. Keletas pavyzdžių:
- Verslo procesų istorijoms gali prireikti nuorodų į darbo eigos diagramas, taip pat nurodyti vaidmenis ir teises.
- Klientams skirtose programų istorijose turėtų būti nuorodos į laidinius rėmus ir jose turėtų būti nurodyti našumo kriterijai.
- API istorijos turėtų dokumentuoti numatomus naudojimo modelius ir metriką.
- Verslo intelektas ir duomenų vizualizavimo istorijos turėtų pateikti gaires, kokie laukai ir informacija reikalinga norint atlikti analizę.
Šablonai padeda užmegzti ryšį tarp komandų ir produktų savininkų, į ką sutelkti dėmesį rašant judrius pasakojimus.
Ir ar tai nėra judrių istorijų esmė? Vikri pasakojimų rašymo praktika, gairės ir principai yra padėti komandoms žinoti, kas svarbu vartotojams ir verslui, prieš svarstant, kaip tai įgyvendinti.
