Анатацыя
Кніга гэта расказаны алгарытм правядзення працэсу распрацоўкі ад ідэі да ўкаранення з ужываннем тэхнік agile. Працэс раскладваецца па кроках і на кожным кроку паказваюцца метады для кроку працэсу. Аўтар паказвае, што большая частка метадаў не арыгінальная, не прэтэндуючы на арыгінальнасць. Але добры стыль выкладу і некаторая цэласнасць працэсу робяць кнігу вельмі карыснай.
Ключавая тэхніка карты карыстацкіх гісторый - гэта структурацыя ідэй і пастаноўкі па ходзе праходжання працэсу карыстальнікам.
Пры гэтым выкладаць праходжанне працэсу можна па-рознаму. Можна выбудаваць крокі па меры дасягнення ключавой каштоўнасці, а можна проста ўзяць і ўявіць працоўны дзень карыстальнікаў, як ён праходзіць з выкарыстаннем сістэмы. Аўтар факусуюць на тое, што працэсы трэба выкладаць, прамаўляць у выглядзе гісторыі карыстальніка на карце працэсу, што і паслужыла назвай карта карыстацкіх гісторый.
Каму гэта трэба
Для ІТ-аналітыкаў і кіраўнікоў праектаў. Абавязкова да чытання. Чытаецца лёгка і прыемна, кніга сярэдняя па памеры.
Водгук
У самым простым выглядзе, як гэта працуе.
Наведвальнік прыходзіць у кавярню, выбірае стравы, робіць заказ, атрымлівае ежу, есць, расплачваецца.
Можна пісаць патрабаванні, што мы жадаем ад сістэмы на кожным этапе.
Сістэма павінна паказваць спіс страў, у кожнай стравы склад, вага і кошт і мець магчымасць дадаць у кошык. Чаму мы ўпэўненыя ў гэтых патрабаванняў? У "стандартным" апісанні патрабаванняў гэта не апісана і гэта спараджае рызыкі.
Выканаўцы, якія не разумеюць навошта гэта трэба, звычайна робяць не тое, што трэба. Выканаўцы не ўцягнутыя ў працэс стварэння ідэі, не ўцягнуты і ў вынік. Agile кажа, дык давайце факусавацца перш за ўсё не на сістэме, а на людзях, на спажыўцах, іх задачах і мэтах.
Які робіцца персоны, для эмпатыі надаем ім дэталі і са боку персон пачынаем выкладаць гісторыі.
Офісны супрацоўнік Захар пайшоў на абед і хоча хутка перакусіць. Што яму трэба? Ідэя - напэўна ён хоча бізнес ланч. Яшчэ ідэя ён хоча, каб сістэма памятала яго перавагі, таму што ён сядзіць на дыеце. Яшчэ ідэя. Ён хоча, каб яму адразу прынеслі каву, таму што ён прывык піць каву перад абедам.
А ёсць яшчэ бізнэс (аргсанаж - персанаж, які прадстаўляе інтарэсы нейкай арганізацыі). Бізнес хоча павялічыць сярэдні чэк, павялічыць частату пакупкі, павялічыць прыбытак. Ідэя - а давайце прапаноўваць незвычайныя стравы нейкай кухні. Яшчэ ідэя - а давайце ўвядзем сняданкі.
Ідэі можна і трэба канкрэтызаваць, пераўтвараць і аформіць у выглядзе user story. Як супрацоўнік бізнес-цэнтра Захар, я хачу, каб сістэма апазнала мяне, каб я атрымліваў меню з улікам маіх пераваг. Як афіцыянт я хачу, каб сістэма апавяшчала мяне калі падысці да століка, каб кліент быў задаволены хуткім абслугоўваннем. І гэтак далей.
Дзесяткі гісторый. Далей прыярытызацыя і бэклог? Джэф паказвае на якія ўзнікаюць праблемы: увязанне ў дробных дэталях і страта канцэптуальнага разумення плюс прыярытызацыя функцыяналу стварае ірваную карціну з-за няўзгодненасці мэтам.
Шлях аўтара: Прыярытэзуем не функцыянал, а вынік = тое, што карыстач атрымлівае ў выніку.
Відавочны невідавочны пункт: сесія прыярытызацыі праходзіць не ўсёй камандай, бо неэфектыўна, а трыма людзьмі. Першы адказвае за бізнэс, другі за карыстацкі досвед і трэці за рэалізацыю.
Вылучым мінімум для рашэння адной задачы карыстальніка (мінімальнае жыццяздольнае рашэнне),.
Дэталізуем ідэі першага прыярытэту з дапамогай user story, накідаў дызайну, абмежаванняў і бізнес правілаў на карце карыстацкіх гісторый шляхам апавядання і абмеркавання з камандай што трэба персонам і стэйкхолдэрам на кожным кроку працэсу. Астатнія ідэі пакідаем не разабранымі, у беклогу магчымасцяў.
Працэс пішацца ў выглядзе картак злева направа, а ідэі на картках пад крокамі працэсу. Абавязкова шлях праходжання ўсёй гісторыі трэба прагаворваць разам з супрацоўнікамі каманды для з'яўлення паразумення.
Прапрацоўка такім спосабам стварае цэласнасць адпаведнасці працэсам.
Атрыманыя ідэі трэба праверыць. Ня чалец каманды апранае капялюш персоны і пражывае ў галаве дзень персоны, вырашаючы яго задачу. Магчымы варыянт, калі ён не бачыць напрацовак, ствараючы карткі нанава, а каманда адчыняе для сябе альтэрнатывы.
Затым адбываецца дэталізацыя для адзнакі. Для гэтага дастаткова трох людзей. Адказны за карыстацкі досвед, распрацоўшчык, тэсціроўшчык з любімым пытаннем: “А што калі…”.
На кожным этапе, абмеркаванне ідзе па карце працэсаў гісторыі карыстальніка, што дазваляе трымаючы ў галаве задачу карыстальніка ствараць цэласнасць разумення.
Ці патрэбная дакументацыя на думку аўтара? Так, патрэбна. Але як нататкі, якія дазваляюць успомніць аб чым дамовіліся. Уцягванне чалавека з боку зноў патрабуе абмеркавання.
Аўтар не паглыбляецца ў тэму дастатковасці дакументацыі, робячы асноўны ўпор на неабходнасці абмеркаванняў. (Так, дакументацыя патрэбная, як бы гэта не сцвярджалі людзі, неглыбокія ў разуменні agile). Гэтак жа прапрацоўка толькі часткі магчымасцяў можа прывесці да неабходнасці поўнай пераробкі ўсёй сістэмы. Аўтар паказвае на рызыку залішняй прапрацоўкі ў выпадку, калі не адгадалі з ідэяй.
Для зняцця рызык неабходна хутка атрымліваць зваротную сувязь па ствараемым прадукце для мінімізацыі шкоды стварэння "не таго" прадукта. Зрабілі малюнак ідэі – валідзіравалі ў карыстача, накід прататыпаў інтэрфейсу – валідавалі ў карыстача і да т.п. (Асобна крыху паказваецца як валідаваць прататыпы праграм). Мэты стварэння ПА, асабліва на пачатковай стадыі - навучанне праз атрыманне хуткай зваротнай сувязі, адпаведна першы створаны прадукт гэта накіды якія ў стане даказаць або абвергнуць гіпотэзу. (Аўтар абапіраецца на працу Эрыка Райса "Стартап па метадалогіі Lean").
Карта гісторый дапамагае наладзіць камунікацыі, калі рэалізацыя забяспечваецца некалькімі камандамі. Што павінна быць на мапе? Тое, што трэба для падтрымкі размовы. Не толькі user story (хто, што, чаму), а ідэі, факты, накіды інтэрфейсаў і інш.
Падзяляючы карткі на карце гісторыі на некалькі гарызантальных ліній можна падзяліць працы на рэлізы - вылучыць самы мінімум, пласт нарошчвання функцыяналу і банцікі.
Прагаворваем гісторыі на карце працэсу.
Супрацоўнік прыйшоў на абед.
Што ён хоча? Хуткасці абслугоўвання. Каб яго абед ужо чакаў яго на стале ці хаця б на падносе. Опа - прапушчаны крок: супрацоўнік захацеў паесці. Ён зайшоў у сістэму і абраў варыянт бізнес-ланчу. Ён убачыў каларыйнасць і адпаведнасць пажыўнай каштоўнасці, каб выконваць дыету і не таўсцець. Ён убачыў карцінкі стравы, каб прыняць рашэнне ці будзе ён ёсць у гэтым месцы ці не.
Далей ён пойдзе атрымліваць ланч і абедаць? А можа, яму даставяць ланч у офіс? Тады крок працэсу - выбар месца ежы. Ён жадае бачыць тэрмін калі яму даставяць і колькі гэта будзе каштаваць, каб абраць куды выдаткаваць час і сілы - на спуск уніз або на працу. Ён хоча бачыць загружанасць кавярні, каб не штурхацца ў чэргах.
Далей супрацоўнік прыйшоў у кавярню. Ён хоча ўбачыць свой паднос, каб узяць яго і адразу пайсці абедаць. Кафэ хоча прыняць грошы, каб зарабіць на абслугоўванні. Супрацоўнік хоча страціць мінімум часу на разліках з кафэ, каб не марнаваць каштоўны час без карысці. Як гэта зрабіць? Аплачваць загадзя ці наадварот пасля абслугоўвання выдалена. Або аплачваць у момант з дапамогай кіёска. Што з гэтага самае галоўнае? Як шмат людзей гатовы аплачваць банкаўскай картай абед? Як шмат людзей давераць захоўванне нумара карты для паўторных аплат гэтай сталовай? Без палявога даследавання незразумела, трэба тэсціраванне.
На кожным кроку працэсу трэба хоць неяк забяспечыць функцыянал, для гэтага трэба ўзяць за аснову нейкую персону і абраць што важней яму (тая самая тройка выбіральнікаў). Прайшлі гісторыю да канца = зрабілі жыццяздольнае рашэнне.
Далей ідзе дэталізацыя. Кліент хоча бачыць загружанасць кафэ, каб не штурхацца ў чэргах. Што канкрэтна ён жадае?
Глядзець прагноз колькі будзе людзей праз 15 хвілін, калі ён туды падыдзе
Глядзець сярэдні час абслугоўвання ў кафэ і яго дынаміку на паўгадзіны наперад
Глядзець сітуацыю і дынаміку занятасці столікаў
А што, калі сістэма прагназавання дае незразумелы вынік ці перастане працаваць?
Глядзець праз відэа чэргі ў кафэ, а таксама занятасць столікаў. Хм, а чаму б не зрабіць гэта ў першую чаргу?!
Аўтар паказвае на невялікае практыкаванне для адпрацоўкі практыкі: паспрабуйце ўявіць сабе што вы робіце раніцай пасля абуджэння. Адна картка = адно дзеянне. Узбуйніце карткі (замест намалоць каву - выпіць узбадзёрвальны напой), каб прыбраць індывідуальныя дэталі, беручы ў фокус не спосаб рэалізацыі, а мэта.
Для каго гэтая кніга - для ІТ-аналітыкаў і кіраўнікоў праектаў. Абавязкова да чытання.
Прыкладання
Дыскусія і прыняцце рашэнняў эфектыўныя ў групах ад 3-х да 5 чалавек.
Напішы на першай картцы тое, што трэба распрацоўваць, на другой - выправіць тое, што зрабілі ў першай, у трэцяй - выправіць тое, што зроблена ў першай і другой.
Рыхтуйце гісторыі, як тарты - не выпісваючы рэцэпт выраба, а пазнаючы каму, з якой нагоды, на колькі чалавек торт. Калі разбіваць рэалізацыю, то не на выраб каржоў, крэму і да т.п., а на выраб маленькіх гатовых торцікаў.
Распрацоўка ПЗ падобная на стварэнне фільма, калі трэба старанна распрацаваць і вылізаць сцэнар, арганізаваць сцэну, акцёраў і інш перад пачаткам здымак.
Рэсурсаў заўсёды будзе не хапаць.
20% намаганняў даюць адчувальны вынік, 60% даюць незразумела што, 20% намаганняў ідуць на шкоду - вось чаму важна сфакусавацца на навучанні і не адчайвацца ў выпадку негатыўнага выніку.
Майце зносіны з карыстальнікам напрамую, адчуйце сябе ў яго шкуры. Факусуйцеся на некаторых праблемах.
Дэталізацыя і прапрацоўка гісторыі для ацэнкі - самая моташная частка scrum, зрабіце абмеркаванні стаялымі ў рэжыме акварыум (каля дошкі абмяркоўваюць 3-4 чалавекі, калі хтосьці хоча ўдзельнічаць, ён замяняе кагосьці).
Крыніца: habr.com