Būtībā veiklie lietotāju stāsti ir īsi, vienkārši rīki, lai dokumentētu vienu darbību vai nodomu, ko mērķa lietotājs vēlas, lai sasniegtu mērķi. Visvienkāršākajiem lietotāju stāstiem ir formāts: “Kā a lietotāja tips vai loma, ES gribu darbība vai nodomstā ka iemesls vai ieguvums”, Kas atbild vismaz uz trim vienkāršiem jautājumiem par to, kas, ko un kāpēc stāsts atrodas neizpildīto rindā.
Kad komandas nobriest un organizācijas izmanto veiklību vairākās komandās un iniciatīvās, veiklu lietotāju stāsti bieži iegūst daudz lielāku definīciju un struktūru, lai nodrošinātu kopīgu izpratni par nodomu un pamatprasībām.
Darba sākšana ar veiklu lietotāju stāstu rakstīšanu
Ir daudz resursu, lai palīdzētu jauno produktu īpašniekiem, biznesa analītiķiem, skrāpju meistariem un tehniskiem jautājumiem izprast lietotāju stāstu rakstīšanas pamatus. Dažās vietās, kur sākt, ir iekļauti raksti no Atlassian, FreeCodeCamp, Agile Modeling un šie 200 lietotāju stāstu piemēri. Viens no pilnīgākiem rakstiem ir Aleksandra Kovana labākajā veiklā lietotāja stāstā. Ir grāmatas par stāstu rakstīšanu, ieskaitot Lietotāju stāstu kartēšanaDžefs Patons un Pīters Ekonomika un Lietotie lietotāju stāstiautors Maiks Kohns. Jūs varat arī iziet stāstu rakstīšanas kursus no Udemy, Learning Tree, VersionOne un Lynda.
Viens no pamatprincipiem, kuru pirmo reizi dalīja Bils Veiks, ir: ieguldi labos stāstos. Ieguldītnozīmē “neatkarīgs, apspriežams, vērtīgs, novērtējams, mazs un pārbaudāms”, kas ir labs kontrolsaraksts veikliem stāstu rakstītājiem. “Veikls līdera ceļvedis lietotāju stāstu rakstīšanai” ir viens raksts, kurā paskaidrots, kā pieteikties ieguldītprincipi.
Pamatinformācija ir samērā vienkārša, tomēr es bieži dzirdu un esmu liecinieks ieinteresēto pušu, produktu īpašnieku, izstrādātāju un testētāju atvienošanai par prasību kvalitāti vai to, vai stāsts ir patiešām paveikts. Dažreiz ir pretrunīgi viedokļi par nepieciešamo detalizācijas pakāpi, kur iekļauties tehniskajās prasībās un kādi artefakti būtu jāizveido ar lietotāju stāstiem.
Ņemot vērā šos jautājumus, šeit ir septiņas pamatnostādnes par veiklu lietotāju stāstu rakstīšanu.
1. Uzrakstiet stāstus auditorijai, kas tos izmantos
Pirms stāstu rakstīšanas paturiet prātā, ka stāsti ir domāti lasīšanai un izpratnei cilvēkiem, kas piedalās attīstības procesā ar dažādām vajadzībām un pienākumiem. Stāstu rakstītājiem un līdzautoriem jāpatur prātā auditorija un jāizstrādā stāstu projekti, lai apmierinātu kopējās vajadzības:
- Varbūt produktu īpašnieki nav tie, kas raksta stāstus, it īpaši, ja jūsu organizācija deleģē šo funkciju biznesa analītiķiem vai ja stāstu rakstīšanā ir iesaistīti vairāki cilvēki. Produktu īpašnieki vēlas pārliecināties, ka stāsts pilnībā atspoguļo lietotāju vajadzības un nodomus. Viņiem ir jāizlasa detalizēti pieņemšanas kritēriji, taču viņi ne vienmēr vēlas, lai viņos būtu detalizēta informācija par tehnisko ieviešanu. Produktu īpašniekiem būtu arī jāsaprot, kā stāsts tiek saskaņots ar kopējo ainu, tāpēc viņiem aktīvi jāinteresējas par to, kā tiek definētas epikas un funkcijas un kā viņiem tiek piešķirti stāsti.
- Ieinteresētās personas nelasīs stāsta detaļas, bet izpētīs epikas un izlasīs stāsta kopsavilkumu. Ja jums ir daudz ieinteresēto personu, apsveriet iespēju izmantot aprakstošu formātu kopsavilkumiem un pārvietot sadaļu “Kā a lietotāja tips vai loma”Apraksts līdz lietotāja stāsta apraksta sākumam.
- Tehniskie klienti bieži ir pirmā persona no komandas, kas pārskata stāstus, un viņi izpētīs prasības, lai redzētu, vai stāsts ir pārāk liels un vai tas būtu jāsadala vairākos stāstos, vai arī redzēs, vai stāstam ir nepieciešams sākotnējs tehnisks darbs, lai noteiktu labāko risinājums.
- Piešķīrējs ir persona, kas ikdienas sagatavošanās sanāksmēs ir jāpārskata informācija un jāziņo par progresu. Piešķirtajiem vajadzētu pārskatīt stāstus par atkarībām, kas sprinta laikā var kļūt par blokiem.
- Komandas locekļi bieži pārskata visus stāstus, lai saprastu viņu piešķirtos stāstus citu sprintam piešķirto stāstu kontekstā.
- Testētāji nosaka, vai ir nepilnības vai riski, kas nav identificēti pieņemšanas kritērijos, un pēc tam apsver, kā tos vislabāk ieviest automatizētajā testēšanas sistēmā.
- Komandas analītiķis, kurš var būt programmas vadītājs vai projekta vadības biroja loceklis, vēlas, lai stāsti būtu pilnībā apzīmēti un kategorizēti, lai no neizpildītā laika varētu iegūt nozīmīgu metriku.
2. Sāciet, domājot par lietotāju
Lai gan veikliem lietotāju stāstiem var būt nepieciešama detalizēta informācija, ir ļoti svarīgi sākt ar lietotāju. Stāstam vajadzētu būt definētam kasdarbība vai nodoms, ko lietotājs vēlas veikt, un kāpēctas attiecas uz vajadzību, pamatvērtību vai mērķi, kas iegūts no pieredzes.
Sarežģītākām lietojumprogrammām dažādu lietotāju personu noteikšana, kas ilustrē dažādu lietotāju veidu vajadzības, vērtības un lietošanas modeļus, ir svarīga disciplīna un var uzlabot stāstu rakstīšanu. Romānā Pihlers rakstā “10 padomi labu lietotāju stāstu rakstīšanai” iesaka, ka “personas mērķi palīdz jums atklāt pareizos stāstus. Pajautājiet sev, kāda funkcionalitāte produktam jānodrošina, lai sasniegtu personības mērķus. ” Personu izmantošana lietotāja mērķu nostiprināšanai nodrošina valodas bagātāku nozīmi kāpēcstāsts ir svarīgs un palīdz noteikt neizpildītās prioritātes.
3. Atbildiet, kāpēc stāsts ir svarīgs
Lietotāju vajadzību vai lietotāja personu mērķu izpratne, dokumentēšana un apspriešana ir tikai viena dimensija kāpēcprodukta īpašnieks prioritizē stāstus. Stāstam vajadzētu arī nodrošināt biznesa vērtību, kaut ko grūti noteikt, bet var būt kvalificējamsstāsta, iezīmes, episkā vai izlaiduma līmenī.
Atbildot kāpēcvar būt svarīgi izstrādātājiem, kad viņiem tiek dotas iespējas piedāvāt dažādas ieviešanas iespējas. Piemēram, funkcija, kas uzlabo lietotāju pieteikšanās pieredzi, var nākt par labu arī biznesam, ja jaunā pieredze rada arī labākus klientu datus. Izstrādātājs var pārdomāt šo pievienoto biznesa vērtību un optimizēt šī mērķa ieviešanu, pat ja stāsta pieņemšanas kritēriji nav īpaši saistīti ar šo prasību.
4. Definējiet pieņemšanas kritērijus, nenorādot risinājumu
Nozīmīgākā disciplīna, kurai jāpievērš uzmanība stāstu rakstīšanā, ir pieņemšanas kritēriju izstrāde. Tie bieži ir aizzīmju saraksti ar īsiem pases vai kļūdas paziņojumiem, kas dokumentē prasības, ierobežojumus, metriku un cerības. Šie pieņemšanas kritēriji bieži tiek izmantoti vairākos veidos:
- Tehniskie klienti un komandas tos izmanto, lai novērtētu sižeta punktus, pamatojoties uz sarežģītību un piepūli.
- Izstrādātāji sašaurina ieviešanas iespējas līdz tām, kas atbilst pieņemšanas kritērijiem.
- Produktu īpašnieki var samazināt pieņemšanas kritēriju apjomu vai sarežģītību, lai veicinātu ieviešanu ar zemākām aplēsēm.
- Piešķīrējs standups laikā paziņo blokus vai jautājumus, kas atbilst sarežģītiem kritērijiem.
- Kvalitātes nodrošināšanas inženieri izmanto pieņemšanas kritērijus, lai izstrādātu automatizētus testus.
- Produkta īpašnieks veiklās demonstrācijas laikā pārskata galvenos kritērijus, lai pārliecinātos, ka stāsts ir izdarīts.
Pieņemšanas kritēriju rakstīšana nav mazsvarīga. Pieņemšanas kritēriju pieņemšanas kritēriji izceļ dažus jautājumus, piemēram, pārāk daudz kritēriju noteikšana, pārāk neskaidru kritēriju noteikšana vai sarežģītu kritēriju dokumentēšana, kurus nav viegli pārbaudīt. Daži autori izmanto pieņemšanas kritēriju veidnes, kas definē īsu, atomu un pārbaudāmu kritēriju struktūru.
5. Izmantojiet stāstus, lai definētu, kas un kāpēc; definēt uzdevumus, kā to īstenot
Viena no kritiskajām kļūdām, ko es redzu komandām saistībā ar stāstu rakstīšanu, ir būt daudznozīmīgai un konkrētai attiecībā uz ieviešanu. Šie slikti uzrakstītie stāsti iegulda daudz pūļu, lai aprakstītu kāīstenot bieži uz aprakstīšanas rēķina kaslietotāja vajadzībām, kāpēctas attiecas uz viņu mērķiem, un kurtas veicina biznesa vērtību.
Tam var būt daži iemesli.
Nepieredzējuši produktu īpašnieki var izmantot stāstus, lai uzzīmētu savas ieviešanas vīzijas. Citiem vārdiem sakot, viņi var pārāk precizēt lietotāja dizainu un funkcionālās ieviešanas iespējas, nevis dalīties mērķa lietotāja pieredzē un ieguvumos. Daži produktu īpašnieki sajauc savu konceptualizāciju par to, kā kaut kas varenībadarbs (process, kurā viņi saprot prasības) ar to vajadzētudarbu, nejauši pārvēršot iekšējās ieviešanas piemēru par ārējās ieviešanas specifikāciju.
Citi produktu īpašnieki var pārkāpt savas robežas, lūdzot komandu “izveidot man šo”. Tā ir viena no manām 20 sliktajām produktu īpašnieku uzvedībām, par kurām man ir ieteikumi produktu īpašniekiem sadarboties ar komandu risinājumu izstrādē.
Otrs iemesls, kāpēc stāsti var būt pārblīvēti ar ieviešanas detaļām, ir tas, ka dažas komandas un tehnoloģiju vadītāji vēlas šo detalizācijas pakāpi. Jaunizveidotās tehniskās komandas, kas strādā, lai uzlabotu esošās lietojumprogrammas, varētu vēlēties šo detalizācijas pakāpi, līdz viņi labāk izprot lietojumprogrammas darbību un pilnībā izprot lietotāju vajadzības. Dažas izplatītās komandas, kas strādā ar ārzonas izstrādātājiem vai ārštata darbiniekiem, var arī vēlēties dokumentēt ieviešanas detaļas, lai nodrošinātu, ka šie dalībnieki saprot viņu pienākumus.
Šādām komandām labākais, kas jādara, ir saistīt ar ieviešanas diagrammām un dokumentēt, kas un kā dara, kā uzdevumus, kas saistīti ar stāstu. Lielākā daļa veiklo pārvaldības rīku ļauj veikt uzdevumus vai apakšuzdevumus, un šis detalizācijas līmenis parasti tiek nodalīts no stāsta pamatteksta. Šī ziņojuma diagramma ir labs darbs, kas ilustrē šo svarīgo principu, kā izmantot veiklus stāstus, lai sadalītu lietotāju pieredzi un biznesa procesus, un pievienojot uzdevumus, lai noteiktu ieviešanu atsevišķiem darbiem.
6. Atzīmējiet savus stāstus, lai veicinātu analīzi un prakses uzlabojumus
Kad stāsti ir uzrakstīti, izstrādāti un pabeigti, daudzas komandas vēlas iegūt metriku un veikt analīzi, kas var veicināt procesa uzlabošanos vai ko izmanto uzņēmējdarbības veikšanai, lai iegūtu papildu ieguldījumu.
Šeit ir daži piemēri:
- Iezīmējiet stāstus kā tehnisko parādu, lai noteiktu parāda lielumu, komandas ātruma procentus, kas izmantots tā novēršanai, un kopējo parādu, kas pabeigts ar katru atbrīvošanu.
- Definējiet funkcionālos un tehniskos stāstus par eksperimentiem un inovācijām, pēc tam ziņojiet par to, kur tas ietekmē uzņēmējdarbību.
- Ja jūsu komanda novērtē veiklus lietotāju stāstus, palūdziet komandai atzīmēt stāstus sprinta beigās, lai norādītu, vai tie ir pārvērtējuši vai novērtējuši par zemu, lai uzlabotu aprēķinu precizitāti.
- Izmantojiet iezīmes, komponentus un pielāgotus laukus, lai palīdzētu meklēt neizpildītajā vēsturē esošo informāciju vai metriku. Piemēram, zinot, kādi stāsti ietekmēja API vai kādas prasības izraisīja pēdējos funkcionālos uzlabojumus noteiktā lietojumprogrammas apgabalā, var izdarīt, kad stāsti tiek marķēti uz funkcionālajiem un tehniskajiem komponentiem.
- Atzīmējiet stāstus, kas vāc vai apstrādā sensitīvu informāciju, piemēram, personu identificējošu informāciju (PII), e-komercijas darījumus, vai nozares regulētus datus, piemēram, HIPAA datus, lai varētu veikt drošības un atbilstības pārskatus.
- Sniedziet atsauksmes produkta īpašniekam un komandai. Papildus stāsta iezīmēšanai izdarīts, produkta īpašnieks varētu sniegt komandai arī atsauksmes, piemēram, atzīt a lielisks darbs. Līdzīgi komanda var sniegt atsauksmes produkta īpašniekam par lietotāja stāsta vispārējo kvalitāti un interpretējamību.
7. Definējiet veiklu stāstu veidnes un stila rokasgrāmatas
Lielākas organizācijas, kas strādā ar vairākām veiklām komandām un produktu īpašniekiem, varētu vēlēties izstrādāt standartus un stila rokasgrāmatas stāstu rakstīšanai. Konsekvence palīdz jauno produktu īpašniekiem ātrāk apgūt rakstīšanas prasmes, kā arī uzlabo komandas locekļu efektivitāti informācijas patērēšanā.
Vēl viens iemesls sižetu veidņu noformēšanai ir tas, ka dažāda veida izstrādājumi un lietojumprogrammas tiek izmantotas dažādu lietotāju stāstu izteiksmēm un artefaktiem. Daži piemēri:
- Biznesa procesu stāstos var būt nepieciešamas saites uz darbplūsmas diagrammām, kā arī norādītas lomas un atļaujas.
- Uz klientiem vērstiem lietojumprogrammu stāstiem jābūt saitēm uz stiepļu rāmjiem un tajos jāiekļauj veiktspējas kritēriji.
- API stāstiem vajadzētu dokumentēt paredzamos lietošanas modeļus un metriku.
- Biznesa inteliģences un datu vizualizācijas stāstiem jāsniedz norādījumi par to, kādi lauki un informācija nepieciešama pieprasītajai analīzei.
Veidnes palīdz veidot saikni starp komandām un produktu īpašniekiem par to, kam jāpievērš uzmanība, rakstot veiklus stāstus.
Un vai tas nav veiklu stāstu jēga? Veiklas stāstu rakstīšanas prakses, vadlīnijas un principi ir paredzēti, lai palīdzētu komandām uzzināt, kas ir svarīgi lietotājiem un biznesam, pirms tiek apsvērts, kā tos ieviest.
