Як пісаць добрыя гнуткія гісторыі карыстальнікаў
Адным з першых крокаў у пастаўцы якаснага прадукту з'яўляецца напісанне добрых гісторый карыстальнікаў. У гэтым пасце мы апісваем, як пісаць добрыя гісторыі карыстальнікаў і што трэба ўключыць.
Гісторыя карыстальніка - гэта месца для захавання функцыянальнасці прадукту, і, як вынікае з назвы, гісторыі карыстальніка апісваюць, як кліент альбо карыстальнік будзе выкарыстоўваць гэты прадукт.
Гісторыя карыстальніка ўяўляе сабой невялікую частку функцыянальнасці, якая мае бізнес-каштоўнасць, якую каманда можа прадставіць у спрынце. Розніца паміж гісторыяй карыстальніка і традыцыйным дакументам патрабаванняў заключаецца ва ўзроўні дэталізацыі.
Патрабавальныя дакументы, як правіла, утрымліваюць шмат тэксту і вельмі падрабязна, тады як гісторыі карыстальнікаў у асноўным грунтуюцца на размовах.
Мы можам разбіць структуру гісторыі карыстальніка так:
- Кароткае апісанне патрэбы
- Размовы, якія адбываюцца падчас дагляду за плячамі і планавання спрынту, каб замацаваць дэталі
- Прыёмныя тэсты, якія пацвярджаюць здавальняючае завяршэнне гісторыі
Важна мець на ўвазе, калі пішаце гісторыі карыстальнікаў, гэта тое, што яны пішуцца з пункту гледжання карыстальніка, які ў канчатковым рахунку скарыстаецца прадуктам, таму важна, каб мы дакладна вызначалі, хто з'яўляецца карыстальнікам, калі пішаце гісторыі карыстальніка.
Як пісаць добрыя гісторыі карыстальніка
Як правіла, добрая гісторыя карыстальніка павінна прытрымлівацца абрэвіятуры INVEST:
Я незалежныя - гісторыі карыстальнікаў не павінны залежаць адна ад адной, таму іх можна распрацоўваць у любым парадку.
N дагаворны - пазбягайце занадта шмат дэталяў; захавайце іх гнуткасцю, каб каманда магла наладзіць, якую частку гісторыі трэба рэалізаваць.
V даступны - гісторыя павінна даваць пэўную каштоўнасць для карыстальнікаў.
ЁСЦЬ слаба - каманда павінна мець магчымасць ацаніць гісторыю.
S гандлёвы цэнтр - гісторыі карыстальнікаў павінны быць дастаткова маленькімі, каб змясціцца ў спрынце; вялікія гісторыі складана ацаніць і спланаваць.
Т. estable - забяспечце праверку і адэкватную праверку таго, што распрацоўваецца.
Які фармат выкарыстоўваецца для напісання гісторый карыстальнікаў?
Гісторыі карыстальнікаў звычайна маюць наступны фармат:
_Як я хачу, каб ._
Прыклад: Як кліент abc.com, я хачу увайсці функцыянальнасць, каб я мог атрымаць доступ да дадзеных майго рахунку ў Інтэрнэце .
Як ужо згадвалася раней, звярніце асаблівую ўвагу на тое, хто з'яўляецца карыстальнікам прадукту, і пазбягайце агульнай ролі 'Карыстальніка'. Калі вы не ведаеце, хто такія карыстальнікі і кліенты і чаму яны хочуць выкарыстоўваць прадукт, вам варта не пісаць любыя гісторыі карыстальнікаў.
Апавяданне
- Першая частка гісторыі карыстальніка - Апавяданне. 2-3 фразы, якія выкарыстоўваюцца для апісання намеру гісторыі. Гэта проста рэзюмэ намеру.
Размовы
- Самым важным аспектам гісторыі карыстальніка з'яўляюцца размовы, якія павінны бесперапынна адбывацца паміж камандай распрацоўшчыкаў, кліентам, уладальнікам прадукту і іншымі зацікаўленымі бакамі, каб замацаваць падрабязнасці гісторыі карыстальніка.
Крытэрыі прыёмкі
- Крытэрыі прыняцця ўяўляюць умовы задавальнення, якія запісваюцца ў выглядзе сцэнарыяў, звычайна ў фармаце Карнішона (дадзена, калі, потым). Крытэрыі прыняцця таксама даюць Вызначэнне 'Гатова' для гісторыі.
Хто павінен пісаць гісторыі карыстальніка?
У большасці выпадкаў гісторыі карыстальнікаў пішуць Уладальнік прадукту або бізнес-аналітык і аддае прыярытэты ў адставанні прадуктаў. Аднак гэта не азначае, што пісаць гісторыі карыстальнікаў нясе толькі ўладальнік прадукту. На самай справе любы карыстальнік можа пісаць гісторыі карыстальнікаў, але ўладальнік прадукту абавязаны забяспечыць наяўнасць адставанняў гісторый карыстальнікаў, якія маюць прыярытэт.
Важна тое, што гісторыі карыстальнікаў не павінна будуць разглядацца як дакументы з патрабаваннямі, якія пры напісанні перададуць камандзе распрацоўшчыкаў на рэалізацыю.
Гісторыі карыстальнікаў павінны разглядацца як сродак заахвочвання размоў паміж уладальнікам прадукту і камандай распрацоўшчыкаў, і, такім чынам, іх трэба пісаць сумесна падчас сеансаў сыходу за прадуктамі.
Перавагай удзелу каманды распрацоўшчыкаў у напісанні гісторый карыстальнікаў з'яўляецца тое, што пры наяўнасці якіх-небудзь тэхнічных абмежаванняў іх можна вылучыць загадзя. Тэстары могуць асабліва дадаць каштоўнасць пры пабудове эфектыўных крытэрыяў прыняцця і загадзя спланаваць, што і як трэба праверыць.
Наколькі падрабязнымі павінны быць гісторыі карыстальніка?
Гісторыі карыстальнікаў засяроджваюцца на кошце кліента.
Асноўнае адрозненне паміж гісторыямі карыстальнікаў і іншымі формамі спецыфікацыі патрабаванняў - узровень дэталізацыі. Гісторыя карыстальніка - гэта метафара выкананай працы, а не поўнае апісанне працы. Фактычная праца, якая праводзіцца, даводзіцца да канца дзякуючы супрацоўніцтву, якое круціцца вакол гісторыі карыстальніка па меры развіцця сістэмы.
Калі апісанне становіцца занадта доўгім (больш, чым тое, што змяшчаецца на паказальнай карце), вам варта перагледзець гісторыю карыстальніка. Цалкам верагодна, што вы спрабуеце ўключыць занадта шмат дэталяў.
Памятаеце, што мэта гісторыі карыстальніка - стымуляваць супрацоўніцтва. Ён не прызначаны для дакументавання ўсіх аспектаў працы, як гэта звычайна бывае ў традыцыйных заявах аб патрабаваннях.
Больш за тое, занадта шмат інфармацыі ў апісанні можа прывесці да адсутнічання інфармацыі ў крытэрах прыняцця.
Перш чым пагадзіцца працаваць над гісторыяй, каманда павінна зразумець крытэрыі прыняцця. Яны неабходныя для таго, каб ведаць, што трэба зрабіць, каб задаволіць гісторыю карыстальніка. Крытэрыі прыняцця павінны быць дастаткова падрабязнымі, каб вызначыць, калі гісторыя карыстальніка задаволена, але не настолькі падрабязнымі, каб спыніць супрацоўніцтва.
Тыповыя памылкі пры напісанні карыстальніцкіх гісторый
Занадта фармальна альбо занадта шмат дэталяў. Уладальнікі прадуктаў з добрымі намерамі часта спрабуюць пісаць надзвычай падрабязныя гісторыі карыстальнікаў. Калі каманда бачыць гісторыю планавання ітэрацыі, якая выглядае як дакумент патрабаванняў IEEE, яны часта мяркуюць, што ўсе дэталі ёсць, і прапускаюць падрабязную размову.
Напісанне апавяданняў для тэхнічных задач. Большая частка магутнасці Agile паходзіць ад таго, што працоўны прырост праграмнага забеспячэння ў канцы кожнай ітэрацыі. Калі вашы гісторыі сапраўды толькі тэхнічныя задачы, вы часта не атрымліваеце працуючае праграмнае забеспячэнне ў канцы кожнай ітэрацыі, і вы губляеце гнуткасць пры вызначэнні прыярытэтаў.
Прапускаючы размову. Гісторыі наўмысна расплывістыя перад планаваннем ітэрацыі. Калі вы прапусціце размову аб крытэрах прыняцця, вы рызыкуеце рухацца ў няправільным кірунку, прапусціўшы крайнія выпадкі альбо не ўлічваючы патрэбы кліента.
Ці ёсць у вас парады, якія можна дадаць да вышэйзгаданай інфармацыі для напісання добрых гісторый карыстальнікаў? Не саромейцеся размяшчаць іх у каментарыях.
