абстрактен
Книгата е разказан алгоритъм за извършване на процеса на разработка от идея до реализация с помощта на гъвкави техники. Процесът е изложен на стъпки и на всяка стъпка са посочени методите за стъпката на процеса. Авторът посочва, че повечето методи не са оригинални, без да претендира за оригиналност. Но добрият стил на писане и известна почтеност на процеса правят книгата много полезна.
Ключова техника за картографиране на потребителски истории е структурирането на идеи и изпълнения, докато потребителят преминава през процеса.
В същото време процесът може да бъде описан по различни начини. Можете да изграждате стъпки, докато се постига ключовата стойност, или можете просто да вземете и да си представите работния ден на потребителите, докато минава през системата. Авторът се фокусира върху факта, че процесите трябва да бъдат очертани, изречени под формата на потребителска история върху карта на процеса, което ни даде името карта на потребителската история.
Кой има нужда
За ИТ анализатори и ръководители на проекти. Трябва да се прочете. Чете се лесно и приятно, книгата е средна по размер.
Преглед
В най-простата си форма, това е как работи.
Посетител идва в кафене, избира ястия, прави поръчка, получава храна, яде и плаща.
Можем да напишем изисквания какво искаме от системата на всеки етап.
Системата трябва да показва списък с ястия, всяко ястие да има състав, тегло и цена и да може да се добавя в количката. Защо сме уверени в тези изисквания? Това не е описано в „стандартното“ описание на изискванията и това създава рискове.
Изпълнителите, които не разбират защо е необходимо това, обикновено постъпват погрешно. Изпълнителите, които не участват в процеса на създаване на идея, не участват в резултата. Agile казва, нека се фокусираме основно не върху системата, а върху хората, върху потребителите, техните задачи и цели.
Създаваме персони, даваме им подробности за съчувствие и започваме да разказваме истории от страната на персоната.
Служителят в офиса Захар отиде на обяд и иска да хапне набързо. Какво му трябва? Идеята е, че той вероятно иска бизнес обяд. Друга идея е, че иска системата да запомни предпочитанията му, защото е на диета. Още една идея. Иска веднага да му донесат кафе, защото е свикнал да пие кафе преди обяд.
Има и бизнес (организационен характер е характер, представляващ интересите на организация). Бизнесът иска да увеличи средния чек, да увеличи честотата на покупките и да увеличи печалбите. Идеята е - нека предложим необичайни ястия от някоя кухня. Още една идея – да въведем закуската.
Идеите могат и трябва да бъдат конкретизирани, трансформирани и представени под формата на потребителска история. Като служител на бизнес център Захар искам системата да ме разпознае, за да мога да получа меню според моите предпочитания. Като сервитьор искам системата да ме уведомява кога да се приближа до масата, за да остане клиентът доволен от бързото обслужване. И така нататък.
Десетки истории. Следва приоритизиране и изоставане? Джеф посочва проблемите, които възникват: затъването в дребни детайли и загубата на концептуално разбиране, плюс приоритизирането на функционалността създава накъсана картина поради несъответствие с целите.
Пътят на автора: Приоритизираме не функционалността, а резултата = това, което потребителят получава в крайна сметка.
Очевиден неочевиден момент: сесията за приоритизиране не се извършва от целия екип, защото е неефективна, а от трима души. Първият отговаря за бизнеса, вторият за потребителското изживяване, а третият за внедряването.
Нека изберем минимума за решаване на един потребителски проблем (минимално жизнеспособно решение).
Ние детайлизираме идеите с първи приоритет, като използваме потребителски истории, дизайнерски скици, ограничения и бизнес правила върху картата на потребителските истории, като казваме и обсъждаме с екипа от какво се нуждаят хората и заинтересованите страни на всяка стъпка от процеса. Оставяме останалите идеи неразгледани в натрупаните възможности.
Процесът е написан на карти отляво надясно, с идеи на карти под стъпките на процеса. Наложително е пътят през цялата история да бъде обсъден заедно с членовете на екипа, за да се осигури взаимно разбиране.
Разработката по този начин създава цялост в съответствие с процесите.
Получените идеи трябва да бъдат тествани. Човек, който не е член на екипа, слага шапката на човека и живее деня на човека в главата му, решавайки неговия проблем. Възможно е той да не вижда развитието, създавайки отново карти и екипът да открие алтернативи за себе си.
След това има детайлизиране за оценка. Трима души са достатъчни за това. Отговаря за потребителското изживяване, разработчик, тестер с любим въпрос: „Ами ако...“.
На всеки етап дискусията следва карта на процеса на историята на потребителя, което позволява да се има предвид задачата на потребителя, за да се създаде съгласувано разбиране.
Необходима ли е документация според автора? Да, трябва ми. Но като бележки, които ви позволяват да запомните какво сте се договорили. Включването на външен човек отново изисква дискусия.
Авторът не навлиза в темата за достатъчността на документацията, като се фокусира върху необходимостта от дискусия. (Да, необходима е документация, колкото и да твърдят хора, които не разбират дълбоко от agile). Също така, разработването само на част от възможностите може да доведе до необходимостта от цялостна преработка на цялата система. Авторът посочва риска от прекомерно уточняване в случай, че идеята е грешна.
За да се елиминират рисковете, е необходимо бързо да се получи обратна връзка за създавания продукт, за да се минимизират щетите от създаването на „грешен“ продукт. Направихме скица на идея - валидирахме я с потребителя, скицирахме прототипи на интерфейс - валидирахме я с потребителя и т.н. (Отделно има малко информация как да валидирате прототипи на програми). Целите на създаването на софтуер, особено в началния етап, са обучение чрез получаване на бърза обратна връзка; съответно първият създаден продукт са скици, които могат да докажат или опровергаят дадена хипотеза. (Авторът разчита на работата на Eric Ries „Startup using Lean methodology”).
Картата на историята помага за подобряване на комуникацията, когато внедряването се извършва в множество екипи. Какво трябва да има на картата? Какво ви трябва, за да поддържате разговора. Не само потребителска история (кой, какво, защо), но идеи, факти, интерфейсни скици и т.н.
Като разделите картите на картата на историята на няколко хоризонтални линии, можете да разделите работата на издания - подчертайте минимума, слоя с нарастваща функционалност и лъкове.
Разказваме истории на картата на процеса.
Един служител дойде за обяд.
Какво иска той? Скорости на обслужване. Така че обядът му вече го чака на масата или поне на поднос. Ами сега - пропусната стъпка: служителят искаше да яде. Той влезе и избра опцията за бизнес обяд. Той видя съдържанието на калории и хранителното съдържание, за да му помогне да спазва диета и да не наддава на тегло. Той видя снимки на ястието, за да реши дали ще яде на това място или не.
След това ще отиде ли да вземе обяд и вечеря? Или може би обядът ще бъде доставен в офиса му? След това стъпката от процеса е изборът на място за хранене. Той иска да види кога ще му бъде доставена и колко ще струва, за да може да избере къде да изразходва времето и енергията си - да слезе долу или да отиде на работа. Иска да види колко е натоварено кафенето, за да не се блъска по опашки.
След това служителят дойде в кафенето. Той иска да види подноса си, за да може да го вземе и да отиде направо на вечеря. Кафенето иска да приема пари, за да прави пари от обслужване. Служителят иска да загуби минимум време за разплащане с кафенето, за да не губи безполезно ценно време. Как да го направим? Плащане предварително или обратно след обслужване от разстояние. Или платете на място с помощта на павилион. Какво е най-важното в случая? Колко хора са готови да платят обяд с банкова карта? Колко хора биха се доверили на тази столова да съхранява номера на картата им за повторни плащания? Без теренни изследвания е неясно, необходимо е тестване.
На всяка стъпка от процеса трябва по някакъв начин да осигурите функционалност; за това трябва да вземете някой човек като основа и да изберете какво е по-важно за него (същите три селектора). Проследих историята до края = направих жизнеспособно решение.
Следва детайлизирането. Клиентът иска да види колко е натоварено кафенето, за да не се блъска по опашки. Какво точно иска?
Вижте прогнозата колко хора ще има след 15 минути, когато той стигне
Вижте средното време за обслужване в кафене и неговата динамика половин час предварително
Вижте ситуацията и динамиката на заетостта на масата
Ами ако системата за прогнозиране даде неясен резултат или спре да работи?
Гледайте във видео опашките в кафенето, както и заетостта на масите. Хм, защо не направите това първо?!
Авторът посочва малко упражнение, което да практикувате: опитайте се да си представите какво правите сутрин, след като се събудите. Една карта = едно действие. Увеличете картите (вместо да смилате кафе, изпийте ободряваща напитка), за да премахнете отделни детайли, като се фокусирате не върху метода на изпълнение, а върху целта.
За кого е тази книга: ИТ анализатори и ръководители на проекти. Трябва да се прочете.
Apps
Дискусията и вземането на решения са ефективни в групи от 3 до 5 души.
Напишете на първата карта какво трябва да се развие, на втората - коригирайте това, което сте направили в първата, на третата - коригирайте това, което сте направили в първата и втората.
Приготвяйте истории като торти - не като напишете рецепта, а като разберете за кого, за какъв повод и за колко души е тортата. Ако разбием продажбите, то това ще бъде не в производството на торти, кремове и т.н., а в производството на малки готови торти.
Разработването на софтуер е подобно на правенето на филм, когато трябва внимателно да разработите и излъскате сценария, да организирате сцената, актьорите и т.н., преди да започнете снимките.
Винаги ще има недостиг на ресурси.
20% от усилията дават осезаеми резултати, 60% дават неразбираеми резултати, 20% от усилията са вредни - затова е важно да се съсредоточите върху ученето и да не се отчайвате в случай на отрицателен резултат.
Комуникирайте директно с потребителя, почувствайте се на негово място. Съсредоточете се върху някои проблеми.
Детайлизирането и разработването на историята за оценка е най-мрачната част от схватката, направете дискусиите в режим на аквариум (3-4 души обсъждат на дъската, ако някой иска да участва, той замества някого).
Източник: www.habr.com