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